Les systèmes embarqués - Nouveaux défis scientifiques pour l'informatique

Transcription

1 Les systèmes embarqués - Nouveaux défis scientifiques pour l'informatique Joseph Sifakis Laboratoire VERIMAG Grenoble 7 avril 2010

2 The Evolution of Informatics Scientific Computing Defence Applications Convergence between Computing and Telecommunications Graphic Interfaces, Mouse WEB Information Society Multi-core Systems Foundations - Alan Turing, Kurt Gödel Embedded Systems: Computing + Physicality Seamless revolution 95% of chips are embedded Information Systems: Commercial Applications Integrated circuits The Internet of Things: Convergence between Embedded Systems and the Web Informatics is a young discipline, driven by exponential growth of components and their applications.

3 Embedded Systems Embedded Systems Design Verification Research Challenges O V E R V I E W Marry Physicality and Computation Encompass Heterogeneity - Components Cope with Complexity - Compositionality Cope with Uncertainty - Predictability Discussion 3

4 Embedded Systems An Embedded System integrates software and hardware jointly and specifically designed to provide given functionalities, which are often critical. 4

5 The Embedded Systems Explosion Exploding annual microprocessor + shipments the fast growing market for embedded systems 14,000 # Millions 12,000 world population Microprocessors + 10,000 PCs 8,000 6,000 4,000 2,000 0 '80 '82 '84 '86 '88 '90 '92 '94 '98 '02 Source: Royal Philips Electronics Year

6 Embedded systems - Trends Embedded systems break with traditional Computing Systems Engineering. It is hard to jointly meet technical requirements such as: Reactivity: responding within known and guaranteed delay Ex : flight controller Autonomy: provide continuous service without human intervention Ex : no manual start, optimal power management Robustness: guaranteed minimal service in any case Ex : attacks, hardware failures, software execution errors Scaleability: at runtime or evolutionary growth (linear performance increase with resources) Ex : reconfiguration, scalable services...and also take into account economic requirements for optimal cost/quality Technological challenge : Capacity to build systems of guaranteed functionality and quality, at an acceptable cost 6

7 Embedded Systems - State of the Art We master at a high cost two types of systems which are difficult to integrate: TOMORROW TODAY Critical systems of low complexity Flight controller Complex «best effort» systems Telecommunication systems We need: Affordable critical systems Ex : transport, health, energy management Successful integration of heterogeneous systems of systems Convergence web/embedded systems (internet of things) Automated Highways New generation air traffic control «Ambient Intelligence»

8 Air Traffic Control the Next Generation Is it attainable? 8

10 System design Physics Informatics Theory for building artifacts with predictable behavior Lack of results allowing constructivity Suggested by T. Henzinger: T. Henzinger, J. Sifakis The Embedded Systems Design Challenge FM06

11 System Design a long way to go Design of Large IT systems Designing microprocessors, mobile telecommunication platforms, web application platforms is a risky undertaking, mobilizing hundreds of engineers over several years. Difficulties Complexity mainly for building systems by reusing existing components Requirements are often incomplete, and ambiguous (specified in natural language) Design approaches are empirical and based on the expertise and experience of teams reuse/extend/improve solutions that have proved to be efficient and robust Consequences Large IT projects are often over budget, over time, and deliver poor quality. Of these, 40% fail, 30% partially succeed, 30% succeed.

12 System Design a long way to go There is an (increasing) gap between: Our technological capabilities for treating and transmitting information Our know-how in computing systems engineering "It has long been my personal view that the separation of practical and theoretical work is artificial and injurious. Much of the practical work done in computing, both in software and in hardware design, is unsound and clumsy because the people who do it have not any clear understanding of the fundamental design principles of their work. Most of the abstract mathematical and theoretical work is sterile because it has no point of contact with real computing. Christopher Strachey ( )

13 System design Types of Systems n fact fact(n) Transformational systems Compute a function (must terminate) thermostat room on,off heater Reactive systems Continuously interact with an environment e.g. real-time controllers, protocols, games Compute outputs - reactions to inputs depending on their state Systems must meet given requirements e.g. For all integer n the program terminates and delivers fact(n) The temperature is always between 18 and 22

14 System Design Requirements Functional requirements characterize the services ensured for potential users. These are independent of the resources of the execution platform, e.g.: The program terminates and computes fact(n) The temperature is always between 18 and 20 When train crosses the gate is down When the lift is moving the door is closed Extra-functional requirements characterize the quality of the services. These take into account the resources of the execution platform: Performance Throughput is not less than 100 Mb/s (for a network) Power needed is less than 2mW (for a circuit) Image quality is optimal (for an encoder) Security: Resistance to attacks (for a cryptographic protocol) Safety: Resistance to failures (for a flight controller)

15 System design Simplified View Design is the process of deriving from given requirements, an executable model from which a system can be generated (more or less automatically). Requirements The expected behavior of the system to be designed with respect to its potential users and its environment Program Executable model meeting the requirements SW HW System composed of HW and SW the HW platform may be given

16 System design Correctness Program satisfies Functional Requirements satisfies SW HW satisfies Extra-functional Requirements Correctness The system is correct if it meets its requirements Requirements are formulas (propositions) of a logic The meaning of programs and HW/SW systems are models

17 System design Achieving Correctness Achieving correctness By construction: algorithms, architectures By Checking Physical prototypes e.g. testing Models (Virtual SW Prototypes) Ad hoc models e.g. SystemC simulation Formal models - Verification (exhaustivity)

19 Verification Model Requirements Should be: faithful e.g. whatever property is satisfied for the model holds for the real system generated automatically from system descriptions Verification Method YES, NO, DON T KNOW Should be: consistent e.g. there exists some model satisfying them complete e.g. they tightly characterize the system s behavior As a rule, for infinite state models all non trivial properties are undecidable e.g. bounded memory Intrinsically high complexity for finite state models (state explosion problem)

20 Verification - Models The meaning of a system (HW, SW, HW/SW) is a model defined as a transition relation on states (valuations of state variables): reset +1 x=0 x=1 +1 x=2 +1 x=3 +1 Modulo 4 counter =18 ON 15 min =22 ON turnoff =22 OFF 45min =18 OFF turnoff Thermostat (partial model) A model is characterized by its set of execution sequences

21 Verification - Requirements Specification For a given model, requirements are formulas of a temporal logic defined by: atomic formulas are state predicates e.g. 0 x 4, 18 22, f, fg, fg are formulas if f, g are formulas possible(f), inevitable(f), always(f) are formulas, if f is a formula Meaning of modalities for a given model with a state s s satisfies possible(f) if sequence state s s satisfies f s satisfies inevitable(f), if sequence state s s satisfies f s satisfies always(f) if sequence state s s satisfies f s s satisfies possible(green) inevitable(blue) always(blackbluegreen)

22 Verification - Requirements Specification Thermostat always (18 22) inevitable () Lift always (door_open moving) always (request_for[i] inevitable (elevator_at[i]) ) forall i Mutual exclusion always (write(a,m) write(b,m)) Deadlock-freedom always possible (exec(a)) Starvation-freedom always inevitable(exec(a)) Factorial y=n z=1 always (y=0 z=fact(n)) y=n z=1 inevitable (y=0 z=fact(n)) deadlock=not enough resources for allowing the progress of all tasks starvation=the resource allocation policy is not fair

23 Verification - Requirements Specification Temporal logic was a breakthrough in understanding and formalizing requirements for concurrent systems. Writing rigorous specifications in temporal logic is not trivial. However, the declarative style is not always easy to master and understand - Moving towards a less declarative style. f1 f2 f3 Much needs to be done for extra-functional requirements characterizing: security (e.g. confidentiality properties, electronic voting) reconfigurability (e.g. non interference of features) quality of service (e.g. performance).

24 Verification - Building Models For hardware, it is easy to get faithful logical finite state models represented as systems of boolean equations HW MODEL v u x y z semantics v= u=.. x= y= z= xy

25 Verification - Building Models For software this may be much harder. PROGRAM if. while valid do if x<0 then z:=x else z:=-x; while semantics SEMANTIC MODEL x<0 z:=x valid valid x>=0 z:=-x ABSTRACT MODEL b z:=b valid valid b z:= b abstraction

26 Verification - Building Models For mixed Software / Hardware systems: there are no faithful modeling techniques as we have a poor understanding of how software and the underlying platform interact, validation by testing physical prototypes or by simulation of ad hoc models. APPLICATION Tasks Command Handlers Event Handlers SW EXECUTION PLATFORM Task Scheduler Event Scheduler Sensors Timers Antenna

27 Verification - Methods Deductive verification Based on sets of inference rules for reasoning on the structure of the systems General and interactive, targeting verification of infinite state systems, assisted by theorem provers Frameworks for the development of deductive proofs ex. Coq Algorithmic verification Based on the analysis of global models obtained by flattening system structure e.g. transition systems Emphasis on automation rather than generality Main representatives: model checking and abstract interpretation

28 Verification - Model-checking To check that a model (system) satisfies f compute the set of the states which satisfy f can be defined by induction on the syntax Atomic formulas represent sets of states e.g Logical connectives are interpreted as the corresponding set theoretic operations on sets of states Modal operators have a fixpoint characterization possible(f) = least x such that x=f pre(x) inevitable(f) = least x such that x=f pre(x) pre(x) always(f) = greatest x such that x=f pre(x) where pre is a function defined from the model A model satisfies a formula f if all its states satisfy formula

29 Verification Abstract Interpretation s A satisfies f A implies s satisfies f where s A is an abstraction of s for formulas f involving only universal quantification [Cousot&Cousot 79] Abstract interpretation, a general framework for computing abstractions based on the use of Galois connections. F S SA F are monotonic 2 S 2 S A Id Id Concrete properties Abstract properties F is the best approximation of F in the abstract state space

31 Marry Physicality and Computation Execution constraints CPU speed memory power failure rates EMBEDDED SYSTEM Computing algorithms protocols architectures Environment constraints Performance (deadlines, jitter, throughput) Robustness (security, safety, availability) 31

32 Marry Physicality and Computation Execution constraints CPU speed memory power failure rates Embedded System Design is generalized Hardware Design EMBEDDED SYSTEM Computing algorithms protocols architectures Environment constraints Performance (deadlines, jitter, throughput) Robustness (security, safety, availability) 32

33 Marry Physicality and Computation Execution constraints CPU speed memory power failure rates EMBEDDED SYSTEM Computing algorithms protocols architectures Environment constraints Performance (deadlines, jitter, throughput) Robustness (security, safety, availability) Embedded System Design is generalized Control Design 33

34 Marry Physicality and Computation Embedded System Design coherently integrates all these. Execution constraints CPU speed memory power failure rates EMBEDDED SYSTEM Computing algorithms protocols architectures Environment constraints Performance (deadlines, jitter, throughput) Robustness (security, safety, availability) We need to revisit and revise the most basic computing paradigms to include methods from EE and Control 34

35 Marry Physicality and Computation Physical Systems Engineering Computing Systems Engineering Analytic Models Component: transfer function Composition: parallel Connection: data flow Computational Models Component: subroutine Composition: sequential Connection: control flow f 1 f 2 inst1; inst2... instn;. instx; insty;. Instz;. insta; instb;. Inste;. 35

36 Marry Physicality and Computation Matlab/Simulink Model 36

37 UML Model (Rational Rose) Marry Physicality and Computation

39 Encompass Heterogeneity - Components Build complex systems by composing components (simpler systems). This confers numerous advantages such as productivity and correctness Build a component C satisfying given requirements f, from C 0 a set of atomic components described by their behavior GL ={gl 1,, gl i, } a set of glue operators on components gl12 gl1 c 1 c 1 gl2 c 2 c 2 satisfies f Move from frameworks based on single composition operators to frameworks based on families of composition operators

40 Encompass Heterogeneity - Components Synchronization glue The global behavior C(#s,#r) s r SENDER RECEIVER Non determinism r r sr #s=#r (strong interaction) s s 0#s- #r 2 s r true (no interaction) r r r r r r r r s s s s s s s s 0#s- #r (asynchronous interaction) Notice that # plays the role of a clock

41 Encompass heterogeneity - components Sources of heterogeneity Execution: synchronous and asynchronous components Interaction: function call, broadcast, rendezvous, monitors Abstraction levels: hardware, execution platform, application software Some problems Expressiveness of glues Meaningful (property-preserving) composition of systems with different models of computation Distributed implementation of synchronous systems We need a unified composition paradigm for describing and analyzing the coordination between components to formulate system designs in terms of tangible, well-founded and organized concepts

43 Cope with Complexity - Compositionality Today, a posteriori system verification: High development costs Limitation to medium complexity systems Tomorrow, move from a posteriori verification to compositional construction: At design time, infer properties of a composite system from properties of its components gl 43

44 Cope with Complexity Compositionality

46 Cope with Uncertainty - Predictability Systems must provide a service meeting given requirements in interaction with uncertain and unpredictable environments Uncertainty is characterized as the difference between average and a worst-case system behavior. It is drastically increasing uncertainty, due to: t Interaction with complex, non-deterministic, possibly hostile external environments Execution platforms with sophisticated HW/SW architectures (layering, caches, speculative execution, ) Two types of uncertainty: Intrinsic uncertainty, due to non determinism or abstraction hiding details at execution level; Estimated uncertainty, due to approximations necessary for coping with non computability of exact bounds.

47 Cope with Uncertainty - Predictability Distribution of ET Lower Bound BCET WCET Upper Bound Execution times Possible ET Estimated ET For simple operations WCET may be 300 BCET

48 Cope with Uncertainty - Predictability Increasing uncertainty gives rise to 2 diverging design paradigms BAD STATES ERROR STATES Critical systems engineering based on worst-case analysis and static resource reservation e.g. hard realtime approaches, massive redundancy Best effort engineering based on average case analysis e.g. soft real-time for optimization of speed, memory, bandwidth, power

49 Cope with Uncertainty - Predictability The gap between critical and best effort engineering implies increasing costs and reduced hardware reliability, e.g. increasing number of ECUs in cars. Current trend in avionics and automotive: Moving from federated to integrated architectures (both critical and non critical functions on one chip) Striving for predictability by reducing intrinsic and estimated uncertainty through: Simplification of architectures ( caches, pipelines ), predictable cache replacement policies Determinization of the observable behavior (time triggered systems) Using adaptive control techniques for the management of a global amount of resources which is enough for coping with critical situations.

50 Cope with Uncertainty: Adaptive System Adaptive Controller Learning Strategies for Managing Objectives Tactics for achieving objectives choices states Controlled System

51 Cope with Uncertainty: Adaptive System Learning Movie would have been better Managing Conflicting Objectives Go to: 1) Stadium 2) Movie 3) Restaurant Planning 51

52 Cope with Uncertainty - Adaptivity Challenge: Develop holistic adaptive design techniques combining the two paradigms: satisfaction of critical properties and efficiency y by optimal use of the globally available resources (processor, memory, power). 52

54 Discussion Embedded Systems break with traditional Informatics, which should be extended to encompass paradigms and methods from disciplines based on physics. Physics Studies the laws governing energy, matter and their relationships Studies a given «reality» Physical systems Analytic models Continuous mathematics Informatics Studies foundations of information and computation Studies created universes Computing systems Machines Discrete mathematics Logic Differential equations Estimation theory - robustness Constructivity, Predictability Mature Automata, Algorithms and Complexity Theory Verification, Test Promising 54

55 Discussion Constructivity: Constructivity Engineering of physical systems is based on tractable analysis/synthesis techniques: the laws of classical Physics are surprisingly simple and encompassable by reasonably continuous models. there exist good enough linear approximations of physical systems Computing Systems: are intrinsically non linear - there exists no linear representation of a memory element are intrinsically non robust: small changes may have large impact have intractable analytic approaches, especially general systems involving both conflicts and synchronization

56 Discussion Composition of components Engineering of Physical Systems is based on single-timeframe models: composition of behavior boils down to functional composition. system behavior is deterministic For Computing Systems: There is no built-in notion of physical time or any other physical quantity It is possible to define different abstract notions of time and resources Composition of components amounts to expressing constraints on their respective timeframes there is a large variety of composition mechanisms depending on the way component clocks are synchronized Consequently, system behavior is intrinsically non deterministic Uncertainty arises from both non determinism and our inability to build faithful models and estimate their behavior 56

57 Discussion For a System Design Discipline Informatics deals with an infinite number of possibly created universes. Limiting the focus on particular tractable universes of systems can help overcome current limitations A posteriori verification is not the only way for guaranteeing correctness. In absence of tractable analytic approaches, we should concentrate on correct-by-construction results for sub-classes of systems and properties which are operationally relevant and technically successful. This vision can contribute to the unification of the discipline, by bridging the gap between Formal Methods and Verification, and Algorithms and Complexity 57

58 MERCI 58