Hybrid Systems: From Models to Code

1. Hybrid Systems: From Models to Code Tom Henzinger UC Berkeley

2. French Guyana, June 4, 1996 $800 million embedded software failure

3. Mars, December 3, 1999 Crashed due to uninitialized variable

4. $4 billion development effort 40-50% system integration & validation cost

5. Sources of Complexity -concurrency -real time -heterogeneity A hybrid system consists of multiple continuous (physical) and discrete (computational) components that interact with each other in real time.

6. No formal connection between requirements, model, and resources: expensive development cycle iterates all stages Redesign No exact correspondence between model and code: -difficult to upgrade code -difficult to reuse code Embedded Software Design: Current State Design Simulate Model (e.g., Simulink) Code generation Optimize Test Code

7. Embedded Software Design: Our Vision Design Verify Model Compilation (analysis, optimization, and code generation) Code

8. The FRESCO Project (Formal Real-Time Software Components) MASACCIO: correctness by formal verification against requirements Hybrid System Model GIOTTO: correctness by schedulability analysis against resources Time-Safe Code

9. Continuous (Euclidean) Systems n State space: R Dynamics: initial condition + differential equations Room temperature: x(0) = x0 x’(t) = -K·x(t) x x0 t Analytic complexity.

10. Discrete (Boolean) Systems m State space: B Dynamics: initial condition + transition relation Heater: off on heat off on t Combinatorial complexity.

11. The Curse of Concurrency 300,000 latches

12. 11 10 stars 11 10 stars 100,000 10 states

13. x  L x  l x  u x  U Hybrid Systems m n State space: B  R Dynamics: initial condition + transition relation + differential equations Thermostat: off x’ = -K·x x0 on off x’ = K·(H-x) on t

14. Hybrid Automata y x

15. Hybrid Automata far near x = 1000 x’[-50,-40] x’[-50,-30] app! app x  1000 x  0 exit! x = 100  x : [2000,) x = 0 exit past x’[30,50] x  100 train

16. Hybrid Automata up open y = 90 y’ = 9 y’ = 0 y  90 raise raise? lower? raise? lower down closed y = 0 y’ = -9 y’ = 0 y  0 gate lower?

17. Hybrid Automata app exit t := 0 t := 0 t’ = 1 app? exit? t’ = 1 idle t   t   lower! raise! controller lower raise

18. Requirements Safety: ( x  10  loc[gate] = closed ) Liveness:   ( loc[gate] = open ) Real time: z :=0. ( z’ = 1   ( loc[gate] = open  z  60 )) Verification and failure analysis by model checking (e.g., HyTech).

19. Two Problems with Hybrid Automata 1. Scalability Possible solutions: -hierarchy (MASACCIO) -assume-guarantee decomposition (interfaces) 2. Robustness Possible solutions: -e-variability -discounted future

20. MASACCIO MASACCIO Hierarchical Hybrid Automata

21. MASACCIO MASACCIO Hierarchical Hybrid Automata

22. MASACCIO MASACCIO Hierarchical Hybrid Automata

23. MASACCIO MASACCIO Hierarchical Hybrid Automata

24. MASACCIO MASACCIO

25. Two Problems with Hybrid Automata 1. Scalability Possible solutions: -hierarchy (MASACCIO) -assume-guarantee decomposition (interfaces) 2. Robustness Possible solutions: -e-variability -discounted future

26. slightly perturbed automaton The Robustness Problem Hybrid Automaton Property

27. The Robustness Problem Hybrid Automaton Safe x = 3

28. The Robustness Problem Hybrid Automaton Unsafe x = 3+

29. A Possible Solution of the Robustness Problem: Metrics on Traces Model Property instead of Yes or No consider -Variation

30. A More Radical Solution of the Robustness Problem: Discounting the Future value(Model,Property): States  {Yes, No} value(Model,Property): States  R

31. A More Radical Solution of the Robustness Problem: Discounting the Future value(Model,Property): States  {Yes, No} value(m,T) = X. (T  pre(X)) discountedValue(Model,Property): States  R discountedValue(m,T) = X. max(T, pre(X)) discount factor 0<<1

32. A More Radical Solution of the Robustness Problem: Discounting the Future Robustness Theorem: If discountedBisimilarity(m1,m2) > 1 - , then |discountedValue(m1,p) - discountedValue(m2,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)

33. The FRESCO Project (Formal Real-Time Software Components) MASACCIO: correctness by formal verification against requirements Hybrid System Model GIOTTO: correctness by schedulability analysis against resources Time-Safe Code

34. The History of Computer Science: Lifting the Level of Abstraction High-level languages: Programming to the application Requirements focused code Compilation The “assembly age”: Programming to the platform Resource focused code -Traditional high-level languages abstract time. -This abstraction is unsuitable for real-time applications, which are still programmed in terms of platform time (“priority tweaking”). -GIOTTO: Real-time programming in terms of application time.

35. GIOTTO MASACCIO Time-Triggered Programming

36. GIOTTO MASACCIO Time-Triggered Programming

37. GIOTTO MASACCIO Time-Triggered Programming 200 Hz 400 Hz 1 kHz 200 Hz

38. GIOTTO MASACCIO Time-Triggered Programming 1. Concurrent Periodic Tasks: -sensing -control law computation -actuating 2. Multiple Modes of Operation: -navigational modes (autopilot, manual, etc.) -maneuver modes (taxi, takeoff, cruise, etc.) -degraded modes (sensor, actuator, CPU failures)

39. GIOTTO MASACCIO Time-Triggered Programming Mode 1 Mode 2 Condition 1.2 Task S 400 Hz Task S 400 Hz Task C 200 Hz Task C 200 Hz Task A’ 1 kHz Task A 1 kHz Condition 2.1 Task A” 1 kHz Mode 3 Mode 4 Task S 400 Hz Task C’ 100 Hz Task C 200 Hz Task A 1 kHz Task A 2 kHz

40. GIOTTO MASACCIO Separation of Concerns Functionality. Timing and interaction. Host code e.g. C -No time. -Atomic. -Sequential. Glue code Giotto -Real time. -Reactive. -Concurrent. This kind of software is reasonably well understood. The software complexity lies in the glue code.

41. automatic (model checking) automatic (compilation) Two Opposing Forces Requirements Verification Model Environment Implementation Resources

42. Two Opposing Forces Requirements Verification Model Environment Implementation property preserving Resources

43. Composition Two Opposing Forces Requirements Verification Component Component Implementation Resources

44. Two Opposing Forces Requirements (time, fault tolerance, etc.) Verification no change Component Component Deep Compositionality Implementation no change Resources

45. Achieving Verifiability and Compositionality in GIOTTO: The FLET (Fixed Logical Execution Time) Assumption Software Task d>0 is the task's "logical execution time" write actuator output at time t+d, for fixed d read sensor input at time t

46. Embedded Programming in GIOTTO The programmer specifies sample rate d and jitter j to solve the control problem at hand. The compiler ensures that d and j are met on a given platform (hardware resources and performance); otherwise it rejects the program.

47. Implementing the FLET Assumption time t time t+d possible physical execution on CPU buffer output

48. Contrast the FLET with Standard Practice output as soon as ready

49. Advantages of the FLET and GIOTTO -predictable timing and value behavior (no internal race conditions, minimal jitter) -portable, composable code (as long as the platform offers sufficient performance)

50. Research Agenda • From Hybrid Models • -robust hybrid models (tube topologies, discounting) • -model checking for hierarchical and stochastic hybrid models • -multi-aspect assume-guarantee decomposition of hybrid models (interface theories for time, resources, fault tolerance) • To Embedded Code • -distributed schedulability analysis and code generation • -on-line code modification and fault tolerance