TU Wien. From Embedded Systems to System of Systems. Outline 01/09/14. H.Kopetz September 2014

Transcription

1 TU Wien From Embedded Systems to System of Systems H.Kopetz September 2014 Work supported by EU FP 7 Project AMADEOS grant agreement Outline IntroducJon CharacterisJcs of an SoS Key Issues in SoS Design The Relied upon Interface An Example from the Smart Grid Conclusion 1

2 Embedded System An embedded system consists of a physical device and an integrated computer system that controls the funcjons of the physical device acjng in the physical environment (Cyber- Physical System, CPS). Most of today s machines and appliances, e.g., automojve engines, washing machines, medical devices, mobile phones or even consumer products, such as an electric toothbrush, are controlled by an embedded computer system. Measured by the numbers, the embedded system market is by far the largest market for the computer industry. Embedded Systems: Cyber World meets Physical World C C-System RT- CommunicaJon System C(Cyber)-System Controlled by Computer Programs Execution Time P-System Event in the P System CPS: Cyber-Physical System P(Physical)-System Controlled by the Natural Laws of Physics Physical Time 2

3 Embedded System Market World-wide Revenue by Major Industry in Billion Euros Industry AutomoJve Industrial Healthcare Energy CommunicaJon Consumer Total Hardware, Software and Services, including Telecom Market. Source IDC Study: Design of Future Embedded Systems Toward Systems of Systems. May 15, 2012 ICT Developments in the next few Years (1) Hardware Technology costs are dropping further: Significant reduc9on of ultra- mass- produced hardware (FPGAs, Logic, Cloud memory, MEMS sensors and actuators) and ubiquitous low- cost communicajon (wire- less, wire- bound, Internet). (2) Breakthrough in CogniPve CompuPng: Computers will be able to sense (hear, see, smell), reason about their environment and support a higher level of funcjonality and of man- machine interacjon (speech, gesture, etc.). (3) Increasing InterconnecPon of Systems will lead to more systems- of- systems, a further increase in system complexity, already a bo`leneck in many large systems of today. (4) Security and Safety: Security and safety concerns and related technologies will play a dominant role in the further deployment of ICT systems. 3

4 Embedded Systems get Interconnected The global availability of communicajon services makes it possible to connect independently developed embedded systems to each other and to the cloud to provide new synergisjc services and more efficient economic processes. Examples: Remote Medical Systems to hospitals and doctors ProducJon systems in different companies Consumer appliances (smart home) Smart grid According to IDC, by 2020 there will be more than 30 billion intelligent devices connected in one way or another. As a consequence Systems- of- systems of enormous complexity are emerging. The Hyped Vision: The Internet of Things Consumer Cloud Computing Production Machine Internet Consumer Product Fog Computing MEMS Sensors 4

5 Fog CompuPng What is Fog CompuPng? A paradigm that extends cloud compujng to the edge of the network a computer capability close to the end user. Provides real- Jme guarantees to cyber- physical applicajons. Produces refined data from the enormous raw sensor data. Challenging requirements w.r.t reliability and maintainability. Is under the control of a single organizajon Example: A computer- system in the home that integrates all sensor informajon and provides local services, such as energy management, security management, medical monitoring, etc. System of Systems (SoS) An SoS is an integrapon of a finite number of autonomous cons=tuent systems (CS) e.g., embedded systems, which are independent and operable, and which are networked together for a period of Pme to achieve a certain higher goal (refer to Jamshidi, 2009, T- Area SoS). An autonomous consjtuent embedded system (CS) encompasses a computer system, a physical object and a human operator its behavior is non- determinis9c. 5

6 CharacterisPcs of an Embedded System vs. SoS CharacterisPc Scope of System Clock synchronizajon Structure Requirements and Spec. EvoluJon TesJng ImplementaJon Technology Faults (Physical, Design) Control Emergence System development Embedded System Fixed (known) Internal Hierarchical Fixed Version control Test phases Given and fixed ExcepJonal Central Insignificant Process model SoS Not known External (GPS) Networked Changing Uncoordinated ConJnuous Unknown Normal Autonomous Important??? Key Issues in SoS Design Global Time InformaJon RepresentaJon EvoluJon Emergent Phenomena Dependability (Security and Safety) Cogni9ve Complexity 6

7 Global Time A proper model of global (physical) 9me provides the backbone of the temporal infrastructure of an SOS. It is needed to Interpret the Jme- stamps across the diverse CSs Control the dura9ons of physical processes. Specify the temporal proper9es of interfaces Synchronize observajons Synchronize output acjons Allocate resources conflict- free (e.g, in communicajon, scheduling) Detect errors promptly Strengthen security protocols The Global Time Base must be Sparse Because of the discrete digital Jme base and the impossibility to synchronize clocks precisely the system- wide consistent temporal order of events can only be achieved if the events occur in the acjvity intervals of a sparse Jme base: Time π Δ π Δ π Events are only allowed to occur at subintervals of the timeline 7

8 Models of Time in a CPS Dense Physics A B Discrete Central Computer Sparse Distributed Computer Real Time Real Time Real Time Models of Time in a CPS Dense Physics A B Discrete Central Computer Sparse Distributed Computer Real Time Real Time Precision of the Global Time Real Time 8

9 Events outside the SoC: Agreement Protocols If the occurrence of events is restricted to some acjve intervals with durajon π with an interval of silence of durajon Δ between any two acjve intervals, then we call the Jme base π/δ- sparse, or sparse for short. Non-sparse event Time π Δ π Δ π Events are only allowed to occur at subintervals of the timeline Handling of Simultaneity A Fundamental Problem In the hardware : meta-stability In operating systems: mutual exclusion In communication systems: order of messages A two-step solution: (i) Provide consistent view of simultaneity distinguish between events that are in the sphere of control (SoC) of the system and events that are outside the SoC--difficult (ii) Order simultaneous events according to some a priori established criterion--easy 9

10 InformaPon RepresentaPon An Informa=on Item (Itom) is a 9med proposi9on about some state or behavior of the world. An Itom consists of (dynamic) data and a (stajc) explana=on of the data. In cyber- space, data is represented by a bit- pahern. While the data is carried explicitly in a message, the explana9on is oken implied by context. In a large SoS the context of the sender can be different from the context of the receiver. If this is the case, then a message that carries data without an explanajon can be interpreted differently by the sender and the receiver. Example: 86 o F means the same as 30 o C Further Examples: Loss of the 125 Mio $ NASA MARS Orbiter on Sept. 23, 1999 was caused by a mismatch between English Units and Metric Units. The crash of an airplane on Jan 20, 2002 was caused the misinterpreta9on of the rate of descent into an airport - - Controlled Flight Into Terrain Accident (CFIT). 10

11 ExplanaPon of Data Human Context: The explana9on must refer to concepts that can be linked to the conceptual landscape of the intended user. Machine Context: The explana9on must specify how the data must be manipulated by a machine the explanajon is integrated in the program that processes the data and in the design of the machine. Conceptual Landscape of an Observer The totality of concepts and rela9ons among the concepts in the mind of the observer. Acquired by gene9c traits and sensory inputs over the lifejme of the observer. Can be parjjoned into two (overlapping) data bases RaJonal database: causal relajons among concepts Example: axioms and theorems IntuiJve database: associa9ve relajons among concepts Example: faces, episodes Strongly influenced by cultural environment of the observer. 11

12 ConPnuous EvoluPon There are many SoSs that are conjnuously evolving. The system boundaries are indeterminable e.g., car2car. There exists no authoritajve specificajon or final acceptance test of the system as a whole. The interfaces between the SoS and its external environment are subject to the evolujon of the external world. This evolujon is out of control of the cyber- system. Example : ATM System Client Bank ATM Owning Bank Client Bank CommunicaJon Network RUMI: Relied Upon Message Interface 12

13 Example : ATM System (2) The world- wide ATM system has evolved over the last fiky years with more than two million terminals installed changing every day. The are a number of standardized internal Relied Upon Message Interfaces (RUMI) among the CSs: ATM Card to ATM Machine Interface ATM- Machine- Client Bank Interface ATM- Machine owning Bank interface Emergent ProperPes The interacjons of the CSs of an SoS can lead to the appearance of novel properjes, called emergent proper9es at the SoS level that cannot be a`ributed to any of properjes of the CSs. Emergent properjes are irreducible, holisjc and of a new kind they disappear when the system is parjjoned into its subsystem. Emergent properjes can be unexpected or expected, they can be explained (weak emergence) or they can be unexplainable (strong emergence). Example: The appearance of deadlock in a distributed computer system. 13

14 Emergence: Interac=ons within an SoS There are three types of interacjons possible among the CSs that form an SoS InteracJons within Cyber space (CS), realized by the exchange of messages (CS- interacjons). InteracJons in the Physical Space (PhS), realized by the flow of material or energy (PhS- InteracJons). InteracJons of humans with a CSs and among humans. Any consjtuent system of an SoS has only a local view of the interacjons, seeing only the interacjons with its immediate partners. An omniscient external observer, who has a global view of all interacjons, is normally not available. ClassificaPon of Emergent Behavior 14

15 Detrimental Emergent Behavior in SoS ManifestaPon: Reduced Performance OscillaJons ErraJc Behavior InterrupJon of Service Causes: Feedback Mechanisms (Control Loops) Temporal Delays Capacity Limits Cascade Effects Feature InteracJons Strategy Conflicts Dependability: Reliability, Safety and Security Many SoSs should provide a dependable service 24hours/ day, 7days/week without any interrupjon. Examples: ATM system Electric Power Grid The global access via the Internet provides ample opportunijes for security a`acks. Since embedded systems act in the physical environment, the consequences of malicious security a`acks can be catastrophic in the physical world. Inadequate security mechanisms can be show- stoppers for the deployment for large SoSs. 15

16 Faults are Normal in an SoS Due to the autonomy of the CSs and the immense size, faults (physical, design) must be expected and tolerated. The design must mijgate the consequences of these faults and provide an acceptable service despite the occurrence of faults: The system must be parjjoned into independent fault containment units (FCU). The system must must detect the failure of an FCU reflec9ve self monitoring capabili9es. Since most faults are transient, the system must recover from transient faults within a short defined recovery Jme. The system must contain mechanisms to mijgate the consequences of permanent faults. Autonomic Fault Mi=ga=on ConsideraJons about fault containment and the control of error propaga9on have a decisive influence on the placement of the Relied Upon Message Interfaces (RUMIs): A CS should form an encapsulated fault- containment unit (FCU) Error detec9on mechanisms must be provided to detect failures of a CS within a short error detecjon latency. A CS should be capable to recover from a transient fault within a defined error recovery Jme provision of appropriate recovery points as part of the design. 16

17 Complexity Complex: Merriam Webster, 2013 hard to separate, analyze or solve; having many parts or aspects that are usually interrelated; On complexity in the Internet (a very large SoS): Complexity is the primary mechanism which impedes efficient scaling, and as a result is the primary driver of increases in both capital expenditures (CAPEX) and opera9onal expenditures (OPEX). Bush and Meyer, Some Internet Architectural Guidelines and Philosophy, RfC 3439, Dec Cogni=ve Complexity Complexity of a Scenario Complexity as a Property Complexity as a RelaJon Structural Complexity Dynamic Complexity CogniJve Complexity Socio PoliJcal Complexity Topological Components Links Algorithms Causality Temporal Feedback Computational Relation between a Scenario and a Human Observer Relation between a Scenario and Society 17

18 A Measure for the Cogni=ve Complexity What is a good measure for the cogni9ve complexity of a model? We are looking for a quanjty that measures the cognijve effort needed to understand a model of reality by a human observer. We consider the elapsed =me needed to understand a model by a given observer a reasonable measure for the cogni=ve effort and thus for the cogni=ve complexity of a model rela=ve to the observer. We assume that the given observer is representajve for the intended user group of the model. External vs. Internal Complexity External complexity is concerned with the service of a CS at a given relied upon interface. An Interface model explains the behavior at the service interface. Internal complexity is concerned with the design of the internals a CS. From the SoS point of view, a low external complexity of the RUMIs of the CSs should be strived for. In many cases, a low external complexity is achieved at the price of a high internal complexity. Example: A smart phone 18

19 SimplificaPon in Monolithic Systems There are a number principles known that simplify a design of a monolithic system [Kop11, p.45]: Principle of AbstracJon Principle SeparaJon of Concern Principle of Causality Principle of SegmentaJon Principle of Observability SimplificaPon in Systems- of- Systems (SoS) In addijon to the known principles for monolithic systems, SoS simplificajon principles focus on the design and placement of the relied- upon interfaces among the consjtuent systems: Sparse Global Time Classifica9on of Expected Changes Outside an SoS flexible, Inside an SoS stable Interfaces Internal CS Complexity vs. External Interface Complexity Autonomic Fault Mi9ga9on Isomorphic DecomposiJon 19

20 Relied Upon Interface (RUI) that connect CSs Whenever two embedded systems are connected to deliver a service from a service provider to a service requestor, a new interface must be provided at the boundary line between the two CSs. We call this new interface a Relied Upon Interface (RUI), because the provision of the services at the SoS level relies on the proper operajon of this new interface. The RUI consists of two separate interfaces, a Relied Upon Physical Interface (RUPI) that is concerned with the exchange of physical en99es across the RUI and a Relied Upon Message Interface (RUMI) that is concerned with the exchange of informa9on between the two CSs across the RUI. The Relied Upon Interface Left CS Boundary Line RUMI Right CS RUPI 20

21 The Relied Upon Physical Interface (RUPI) The Relied Upon Physical Interface (RUPI) deals with the exchange of physical en99es (material, energy) across the RUI. The transport of physical enjjes across the RUI implies also the transport of informajon we call this the intrinsic informa9on transport- - about the properjes of the physical enjjes. This intrinsic informa9on transport is linked to the presence of a physical enjty. We call the informajon about physical enjjes which is detached from the physical enjjes extrinsic informa9on. The Relied Upon Message Interface RUMI The RUMI is an SoS Internal Message interface between consjtuent systems (CS) that enables the transport of extrinsic state informa9on about the present and future state of the physical enjjes in the form of state messages without the presence of a physical enjty. With extrinsic informa9on it is possible to contemplate about and control the properjes of the physical enjjes at a future instant, without the presence of a physical enjty. Using the extrinsic informajon, we can specify the RUI service and the properjes of the RT enjjes at future points in Jme by an appropriate RUI interface model. 21

22 A RUMI should be a Stable Interface A RUMI should be a stable interface that hides the internal func9ons of a CS and the data representa9on at the interface to the environment. Changes within a CS that do not effect a RUMI are called minor changes, while those that effect the RUMI are called major changes. Since major changes can effect many CSs of an SoS, these major changes must be coordinated among all CSs of an SoS. RUMIs are owen standardized by an accepted industry consorjum or standard seqng organizajon. StandardizaJon of the Data Formats StandardizaJon of the ExplanaJon The placement and the specificapon of the RUMIs form the backbone of an SoS Architecture. Event- Triggered CommunicaPon A new message is sent, whenever a significant event occurs. Delay in the queues is unpredictable. BidirecJonal traffic needed for error detecjon. Common communicajon paradigm 22

23 Time- Triggered CommunicaPon In a Jme- triggered communicajon system, the sender and receiver(s) agree a priori on a cyclic Jme- controlled conflict- free communicajon schedule for the sending of Jme- triggered messages. In every period, a message is sent at exactly the same phase. The control and data flow is unidirecjonal. Error detecjon is in the sphere of control of the receiver, based on his a priori knowledge of the arrival instants of messages. A Jme- triggered interface is temporal firewall that eliminates control errors. Comparison: Event Message vs. State Message Event Message Event InformaJon Queues ConsumpJon on Read No Real- Time Guarantees Explicit Flow Control BidirecJonal Error DetecJon at Sender Long Error DetecJon Latency For non- real =me data State Message State InformaJon Update In Place No ConsumpJon on Read Real- Time Guarantees Implicit Flow Control UnidirecJonal (MulJcast) Error DetecJon at Receiver Short Error DetecJon Latency For real =me data 23

24 The RUMI should be based on State Messages Real- Jme state informajon that is exchanged across a RUMI should be encoded in periodic state messages. State messages report about the present or future state of a RT enjty, are self- contained and easy to understand, since they require no context. State messages are idempotent duplica9on of a state message has no effect and a lost state message is autonomously mijgated in the next cycle. State messages erect a temporal firewall and are an ideal base for the implementajon of fault tolerance. The Relied Upon Interface Left CS Boundary Line RUMI Right CS RUPI 24

25 The Two RUMI Interface Models The LeW- CS Interface model describes the services of the Lek CS that are provided to the Right CS. The Right- CS Interface model describes the services of the Right CS that are provided to the Lek CS. The two interface models must be based on an agreed ontology explaining the meaning of the interface variables exchanged across the RUMI and must be compajble with each other. Since the service at future points in 9me is explicated, a global Jme of proper precision among the CS is required. Service Level Agreement (SLA) Before a service can be provided at a RUMI, a Service Level Agreement between the service requester and the service provider must be established. The service level agreement contains: The descripjon of the stajc properjes of the service The specificajon of the domains of the variables that are contained in a service request. The quality of the provided service. The cost of the service. PenalJes that will apply, if a commihed service is not provided. 25

26 Request Reply Model of the RUMI We disjnguish between the request instant t r and the delivery instant t d of a service request. At t r (which must be before t d ) a service request message containing the descripjon of the requested service at t d is sent to the service provider by the service requestor. The service provider responds with a service response message, hopefully indicajng its commitment to provide the service at t d. The internal variables and algorithms used by the service provider to arrive the service response are not visible at the RUMI. At t d the service provider controls its P- system such that the requested service is delivered. An Example from the Smart Grid To further explain the concepts introduced so far, we provide an example of a RUI specificajon between a micro- grid and a ujlity: Left CS Right CS Micro- grid Controller RUMI UJlity Controller CONSUMER PRODUCER STORAGE Micro-grid Power Line RUPI Utility 26

27 The Problem: Circular Dependencies The micro- grid can be a consumer or producer of power. The Jme- dependent price of power is determined by the ujlity. The decision whether the micro- grid consumes power from the ujlity or delivers power to the ujlity during a given interval depends, among other variables, on the price paid by the ujlity. The price offered by the ujlity during a given interval depends, among other variables, on the amount of power consumed or produced by the plurality of micro- grids. This circularity is resolved by a sequenjal iterajon, where the rate of change of one iterajon to the next is limited. Flow Interface vs. Discrete Event Interface The RUPI between the smart grid and the ujlity is a flow interface, where the integral of the power flow over a 9me interval gives the energy flow in this interval. We parjjon the Jme- line in 15 minute intervals and assume that the power flow and the price over an interval is constant. The start of each 15 minute interval is the delivery instant t d. The planning horizon for the power flow is 24 hours, i.e., 96 fikeen minute intervals. The iterajon consists of state messages that are exchanged every 15 minutes. The state message from the ujlity contains the anjcipated price and the state message from the micro- grid contains the amount of power consumed/produced in each one of the 15 minute interval. 27

28 SLA between the UPlity and the Smart Grid The SLA specifies a price band for the electric energy provided or accepted by the ujlity and boundaries for the electric power consumed or produced by a micro- grid. One hour before the delivery instant t d the ujlity must commit the price for the interval that starts at t d. 45 minutes before delivery instant t d the micro- grid must commit the amount of energy consumed or produced in the interval that starts at t d for the commi`ed price. The rates of change of the energy prices and the amount of energy consumed/produced are limited. If a CS does not honor its commihed values, a penalty applies. Service DescripPon of the RUI Every 15 minutes the ujlity will send a price vector with 96 fields (the next 24 hour period) containing the prices for consumed/produced energy. Based on the ujlity prices, the micro- grid will send a consumpjon/producjon vector with 96 fields (the next 24 hour period) every 15 minutes to the ujlity containing the planned amount of energy consumed/produced. One hour before the delivery instant t d the ujlity will commit to the price and 45 minutes before the delivery instant t d the micro grid will commit to the amount of energy. StarJng at t d the micro- grid will consume/produce the commi`ed energy at the commi`ed price. 28

29 The Interface Models Le_ CS (Micro- grid): Based on the energy prices received from the ujlity, the energy needed within the micro- grid and the storage state of the ba`ery, the micro- grid will determine if the energy from the Photo- Voltaic Cells should be delivered to the ujlity or stored in the ba`eries. Right CS (UPlity): Based on the amount of energy consumed/produced by the plurality of micro- grids and the given energy prices on the spot market, the UJlity will determine the energy prices for the next 24 hour period. These procedures will be repeated iterajvely unjl one hour before the delivery interval. Conclusions Systems of systems are substanjally different from monolithic embedded systems many of the established design methods need to be revisited. The substanjal cogni9ve effort required to understand a system- of- system from the different perspecjves is the main cause for the massive engineering effort in design and operajon. It is a worthwhile goal to structure a System of System such that the cogni9ve complexity for understanding the designed arjfact is reduced. 29