The Embedded Systems Design Challenge. EPFL Verimag

Transcription

1 The Embedded Systems Design Challenge Tom Henzinger Joseph Sifakis EPFL Verimag

2 Formal Methods: A Tale of Two Cultures Engineering Computer Science Differential Equations Linear Algebra Probability Theory Logic Discrete Structures Automata Theory

3

4 So how are we doing? Uptime: 123 years

5 What went wrong? Engineering Computer Science Differential Equations Linear Algebra Probability Theory Logic Discrete Structures Automata Theory

6 What went wrong? Engineering Computer Science Differential Equations Linear Algebra Probability Theory Logic Discrete Structures Automata Theory Mature Promising

7 What went wrong? Engineering Computer Science Differential Equations Linear Algebra Probability Theory Logic Discrete Structures Automata Theory Mature? Promising

8 What went wrong? Engineering Computer Science Theories of estimation Theories of robustness Theories of correctness Temptation: Programs are mathematical objects.

9 What went wrong? Engineering Computer Science Theories of estimation Theories of robustness Theories of correctness R B

10 Maybe we went too far? Engineering Computer Science R B

11 Maybe we went too far? Engineering Computer Science Embedded Systems are a perfect playground to readjust the pendulum. R Physicality B Computation

12 The Challenge We need a new formal foundation for embedded systems, which systematically and even-handedly re-marries computation and physicality.

13 The Challenge We need a new formal foundation for computational systems, which systematically and even-handedly re-marries performance and robustness. What is being computed? At what cost? How does the performance change under disturbances? (change of context; change of resources; failures; attacks)

14 Execution constraints CPU speed power failure rates Reaction constraints deadlines throughput jitter Embedded System Computation algorithms protocols reuse

15 Execution constraints CPU speed power failure rates Reaction constraints deadlines throughput jitter Embedded System Embedded System Design is generalized hardware design (e.g. System C) Computation algorithms protocols reuse

16 Execution constraints CPU speed power failure rates Reaction constraints deadlines throughput jitter Embedded System Computation algorithms protocols reuse Embedded System Design is generalized control design (e.g. Mathlab Simulink)

17 Current State of Affairs 50 years of computer science are largely ignored in embedded systems design: it is as if there were no choice between automatically synthesizing code on one hand, and assembly coding on the other hand. Software is often the most costly and least flexible part of an embedded system.

18 Execution constraints CPU speed power failure rates Reaction constraints deadlines throughput jitter Embedded System Design should not be left to electrical engineers Embedded System Computation algorithms protocols reuse

19 Execution constraints CPU speed power failure rates Reaction constraints deadlines throughput jitter Embedded System Design should not be left to electrical engineers Embedded System Computation algorithms protocols reuse BUT: we need to revisit and revise our most basic paradigms to include methods from EE

20 Subchallenge 1: Integrate Analytical and Computational Modeling Engineering Component model: transfer function Composition: parallel Connection: data flow Computer Science Component model: subroutine Composition: sequential Connection: control flow

21

22

23 Analytical Models Defined by equations Deterministic or probabilistic Computational Models Defined by programs Executable by abstract machines

24 Analytical Models Defined by equations Deterministic or probabilistic Strengths: Concurrency Real time Quantitative constraints (power, QoS, mean-time-to-failure) Computational Models Defined by programs Executable by abstract machines Dynamic change Complexity theory Nondeterminism (abstraction hierarchies, partial specifications)

25 Analytical Models Defined by equations Deterministic or probabilistic Strengths: Concurrency Real time Quantitative constraints (power, QoS, mean-time-to-failure) Tool support: Average-case analysis Optimization Continuous mathematics (differential equations, stochastic processes) Computational Models Defined by programs Executable by abstract machines Dynamic change Complexity theory Nondeterminism (abstraction hierarchies, partial specifications) Worst-case analysis Constraint satisfaction Discrete mathematics (logic, combinatorics)

26 Analytical Models Defined by equations Deterministic or probabilistic Strengths: Concurrency Real time Quantitative constraints (power, QoS, mean-time-to-failure) Tool support: Average-case analysis Optimization Continuous mathematics (differential equations, stochastic processes) Main paradigm: Synthesis Computational Models Defined by programs Executable by abstract machines Dynamic change Complexity theory Nondeterminism (abstraction hierarchies, partial specifications) Worst-case analysis Constraint satisfaction Discrete mathematics (logic, combinatorics) Verification

27 Analytical Models Defined by equations Deterministic or probabilistic Strengths: Concurrency Real time Quantitative constraints (power, QoS, mean-time-to-failure) Tool support: Average-case analysis Optimization Continuous mathematics (differential equations, stochastic processes) Main paradigm: Synthesis BEST-EFFORT SYSTEMS DESIGN Computational Models Defined by programs Executable by abstract machines Dynamic change Complexity theory Nondeterminism (abstraction hierarchies, partial specifications) Worst-case analysis Constraint satisfaction Discrete mathematics (logic, combinatorics) GUARANTEED-EFFORT Verification SYSTEMS DESIGN

28 Subchallenge 1: Integrate Analytical and Computational Modeling Best-Effort Systems Design Guaranteed-Effort Systems Design We need both. We need to be able to intelligently trade off costs and risks. We need effective model transformations.

29 Subchallenge 1: Integrate Analytical and Computational Modeling Best-Effort Systems Design Guaranteed-Effort Systems Design We need both. We need to be able to intelligently trade off costs and risks. We need effective model transformations. We need engineers that understand both complexities.

30 Subchallenge 2: Balance the Opposing Demands of Heterogeneity and Constructivity

31 Subchallenge 2: Balance the Opposing Demands of Heterogeneity and Constructivity Sources of heterogeneity Components Levels of abstraction Views (aspects) Operating contexts Degrees of constructivity 1 Synthesis / compilation 2 Correctness by design disciplines 3 Automatic verifiability 4 Formal verifiability

32 Difficulties Models and methods need to be compositional in order to scale. Whenever possible: noninterference

33 Model-based Design Requirements Verification ideally automatic (model checking) Model Environment Implementation ideally automatic (compilation) Resources

34 Model-based Design Requirements Verification Component Component Implementation Resources

35 Noninterference Requirements Verification no change necessary Component Composition Component Implementation no change necessary Resources

36 Noninterference Requirements (time, fault tolerance, etc.) Verification no change necessary Component Composition Component Implementation no change necessary Resources

37 Difficulties Models and methods need to be compositional in order to scale. Whenever possible: Next best solution: noninterference check interface compatibility

38 Difficulties Models and methods need to be compositional in order to scale. Whenever possible: Next best solution: noninterference check interface compatibility Models and methods need to support robustness in addition to functionality. Whenever possible: continuity

39 Difficulties Models and methods need to be compositional in order to scale. Whenever possible: Next best solution: noninterference check interface compatibility Models and methods need to support robustness in addition to functionality. Whenever possible: Next best solution: continuity quantify overengineering

40 Some Examples 1 Heterogeneity through hybrid automata 2 Continuity through discounting 3 Noninterference through fixed logical execution times 4 Compositionality through automaton interfaces

41 Continuous Dynamical Systems State space: R n Dynamics: initial condition + differential equations x Room temperature: x(0) = x 0 x (t) = -K x(t) x 0 t Analytic complexity.

42 Discrete Transition Systems State space: B m Dynamics: initial condition + transition relation heat Heater: off on off on t Combinatorial complexity.

43 Hybrid Automata State space: B m R n Dynamics: initial condition + transition relation + differential equations x 0 off on Thermostat: t off x = -K x x L x l x u on x = K (H-x) x U

44 Some Examples 1 Heterogeneity through hybrid automata 2 Continuity through discounting 3 Noninterference through fixed logical execution times 4 Compositionality through automaton interfaces

45 (Non)Robustness Hybrid Automaton Property slightly perturbed automaton

46 (Non)Robustness Hybrid Automaton x = 3 Safe

47 (Non)Robustness Hybrid Automaton x = 3+ε Unsafe

48 A Continuous Theory of Systems value(model,property): States B value(model,property): States R

49 A Continuous Theory of Systems value(model,property): States B value(m, T) = (μx) (T pre(x)) discountedvalue(model,property): States R discountedvalue(m, T) = (μx) max(t, λ pre(x)) discount factor 0<λ<1

50 Reachability T 1 a b c c λ c undiscounted property discounted property

51 Reachability (F Ç pre(t)) = T T 1 a b c c λ c undiscounted property discounted property

52 Reachability (F Ç pre(t)) = T T max(0, λ pre(1)) = λ 1 a b c c λ c undiscounted property discounted property

53 Reachability (F Ç pre(t)) = T T max(0, λ pre(1)) = λ 1 T λ 2 a c λ c b undiscounted property discounted property c

54 A Continuous Theory of Systems Robustness Theorem [de Alfaro, H, Majumdar]: If discountedbisimilarity(m 1,m 2 ) > 1 - ε, then discountedvalue(m 1,p) - discountedvalue(m 2,p) < f(ε).

55 A Continuous Theory of Systems Robustness Theorem [de Alfaro, H, Majumdar]: If discountedbisimilarity(m 1,m 2 ) > 1 - ε, then discountedvalue(m 1,p) - discountedvalue(m 2,p) < f(ε). Further advantages of discounting: -approximability because of geometric convergence (avoids non-termination of verification algorithms) -applies also to probabilistic systems and to games (enables reasoning under uncertainty, and control)

56 Some Examples 1 Heterogeneity through hybrid automata 2 Continuity through discounting 3 Noninterference through fixed logical execution times 4 Compositionality through automaton interfaces

57 Compositionality Requirements (time, fault tolerance, etc.) Verification no change necessary Component Composition Component Implementation no change necessary Resources

58 Compositionality Requirements (time, fault tolerance, etc.) Verification FET model no change necessary Component Composition Component Implementation E machine no change necessary Resources

59 The FET (Fixed Execution Time) Assumption Software Task read sensor input at time t write actuator output at time t+d, for fixed d

60 The FET (Fixed Execution Time) Assumption Software Task read sensor input at time t d>0 is the task's fixed execution time" write actuator output at time t+d, for fixed d

61 The FET Programming Model The programmer specifies d (could be any event) to solve the problem at hand. The compiler ensures that d is met on a given platform (hardware performance and utilization); otherwise it rejects the program.

62 The FET (Fixed Execution Time) Assumption time t time t+d real execution on CPU buffer output

63 Portability 50% CPU speedup

64 Composability Task 1 Task 2

65 Verifiability through Predictability (Internal Determinism) Timing predictability: minimal jitter Function predictability: no race conditions

66 Contrast FET with Standard Practice make output available as soon as ready

67 Contrast FET with Standard Practice Race

68 Some Examples 1 Heterogeneity through hybrid automata 2 Continuity through discounting 3 Noninterference through fixed logical execution times 4 Compositionality through automaton interfaces

69 A Signature Interface This interface constrains the client s data. E.g. typed programming languages. int bool is_prime

70 Signature Interface Compatibility client int bool int bool is_prime

71 An Assertional Interface This interface still constrains the client s data. E.g. extended static checking. x: int y: int; y 0 real divide_by

72 Assertional Interface Compatibility a: int x: int client b: int; b > 0 y: int; y 0 divide_by real 8 b,y. (b > 0 Æ y = b ) y 0)

73 Assertional Interface Compatibility a: int x: int client b: int; b > 0 y: int; y 0 divide_by real 8 b,y. (b > 0 Æ y = b ) y 0) Preconditions are assumptions on the input. Postconditions are guarantees on the output.

74 An Automaton Interface open file This interface constrains the client s control. close read open? read? close? data! data

75 Automaton Interface Compatibility open file open! close open? close? close! data? read! read read? data! Client data

76 Automaton Interface Incompatibility open file open! close open? close? open! read read? data! Client data

77 Automaton Interface Incompatibility open file open! close open? close? open! read read? data! Client data

78 Summary Verifying properties is not an end but a mean. The end is designing reliable systems. The challenge is to come up with a formal foundation for systems design that lets us quantify how the effort spent during design relates to the quality (functionality, performance, robustness) of the product.

79 Credits Hybrid Automata: R. Alur, P.-H. Ho, J. Sifakis, et al. Discounting: L. de Alfaro, R. Majumdar, et al. Giotto: B. Horowitz, C. Kirsch, et al. Interfaces: A. Chakrabarti, L. de Alfaro, et al.