Designing Predictable and Robust Systems

1. Designing Predictable and Robust Systems Tom Henzinger UC Berkeley and EPFL

2. Complexity Management in System Design Bridge Aircraft Software etc. System Build & test

3. Complexity Management in System Design Applied Mathematics Model Calculate Predict Abstract Bridge Aircraft Software etc. System Build & test

4. Mathematical Modeling: A Tale of Two Cultures Engineering Differential Equations Linear Algebra Probability Theory Computer Science Logic Discrete Structures Automata Theory

5. Uptime: 125 years

7. Why can’t we do Software? Uptime: 125 years

8. Why can’t we do Software? Engineering Theories of estimation. Theories of robustness. Computer Science Theories of correctness. R B

9. Why can’t we do Software? Engineering Theories of estimation. Theories of robustness. Goal: build reliable systems. Computer Science Theories of correctness. Temptation: programs are mathematical objects; hence we want to prove them correct.

10. The CHESS Premise: The pendulum has swung too far Engineering Computer Science R B

11. The CHESS Premise: The pendulum has swung too far Engineering Computer Science Embedded Systems are a perfect playground to readjust the pendulum. R B Physicality Computation

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

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

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

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

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

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

18. CHESS Results: Integration of the Two Cultures Engineering Component model: transfer function Composition: parallel Connection: data flow Computer Science Component model: subroutine Composition: sequential Connection: control flow [Hybrid Systems; Ptolemy; Metropolis; Metamodels]

19. CHESS Results: Integration of the Two Cultures Equational Models Strengths: Concurrency Quantitative constraints (time, power, QoS) Tool support: Best-effort design Optimization Abstract-Machine Models Dynamic change Complexity theory Worst-case analysis Constraint satisfaction Engineers must understand both complexities and trade-offs [EECS 20].

20. The Cyber-Physical 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? (wrong assumptions; change of environment; change of resources; failures; attacks)

21. The Cyber-Physical Challenge We need a new formal foundation for computational systems, which systematically and even-handedly re-marries performance and robustness. Subchallenge 1: build predictable software Subchallenge 2: build robust software

22. Subchallenge 1: Build Predictable Software

23. Subchallenge 1: Build Predictable Software Predictable = Deterministic A system is deterministic if for every input behavior, the output behavior is unique.

24. Subchallenge 1: Build Predictable Software Predictable = Deterministic A system is deterministic if for every input behavior, the output behavior is unique. -internal (invisible) behavior need not be unique -behavior includes all nonfunctional aspects of interest: for real-time systems, behavior includes time stamps

25. Nondeterminism Central to complexity theory: P v. NP Central to abstraction: -high-level programming languages: e.g. memory management -algorithm design: as long as there exists an 0·i<n such that a[i]>a[i+1], swap a[i] and a[i+1] -don’t cares: if input=0, then output=? Central to concurrency: a||b = ab + ba

26. Nondeterminism Central to complexity theory: P v. NP Central to abstraction: -high-level programming languages: e.g. memory management -algorithm design: as long as there exists an 0·i<n such that a[i]>a[i+1], swap a[i] and a[i+1] -don’t cares: if input=0, then output=? Central to concurrency: a||b = ab + ba invisible invisible invisible deterministic

27. Nondeterminism Central to complexity theory: P v. NP Central to abstraction: -high-level programming languages: e.g. memory management -algorithm design: as long as there exists an 0·i<n such that a[i]>a[i+1], swap a[i] and a[i+1] -don’t cares: if input=0, then output=? Central to concurrency: a||b = ab + ba invisible invisible invisible deterministic visible a: x := x+1 b: x := 2x

28. Nondeterminism Central to complexity theory: P v. NP Central to abstraction: -high-level programming languages: e.g. memory management -algorithm design: as long as there exists an 0·i<n such that a[i]>a[i+1], swap a[i] and a[i+1] -don’t cares: if input=0, then output=? Central to concurrency: a||b = ab + ba Alternatives to threads: actor models; transactional memory invisible invisible invisible deterministic visible less nondeterministic

29. Can we build a real-time programming language that treats time in the way in which high-level languages treat memory? -programmer specifies the time of outputs -programmer assumes the platform offers sufficient performance -compiler generates a suitable schedule or throws an exception

30. The LET (Logical Execution Time) Programming Model Software Task write actuator output at time t+d, for specified d read sensor input at time t

31. The LET (Logical Execution Time) Programming Model time t time t+d real execution on CPU buffer output

32. Portability 50% CPU speedup

33. Composability Task 1 Task 2

34. Determinism Timing predictability: minimal jitter Function predictability: no race conditions

35. Contrast LET with Standard Practice make output available as soon as ready

36. Contrast LET with Standard Practice data race

37. But what about performance? The Giotto project at UC Berkeley.

38. Can we build a programming language that treats reliability in the way in which high-level languages treat memory? -programmer specifies the mean-time to failure for outputs -programmer assumes the platform offers sufficient reliability -compiler generates a task replication mapping or rejects the program [HTL project: Chatterjee et al.]

39. Subchallenge 2: Build Robust Software

40. Subchallenge 2: Build Robust Software Robust = Continuous A system is continuous if for all real-valued quantities, small input changes cause small output changes.

41. Subchallenge 2: Build Robust Software Robust = Continuous A system is continuous if for all real-valued quantities, small input changes cause small output changes. -8 >0. 9 >0. input-change · ) output-change ·  -can apply only to real-valued quantities: sensor readings and actuator settings; input and output time stamps

42. A Program kbfilter.c 12,000 lines of code

43. A Program kbfilter.c 12,000 lines of code

44. A Program r kbfilter.c 12,000 lines of code

45. An Error Trace In general, programs are not continuous.

46. More continuous: read sensor value x at time t; compute “continuous” function y = f(x); write output value y at time t+d; Less continuous: read sensor value x; if x · c then ... else ...

47. More continuous: read sensor value x at time t; compute “continuous” function y = f(x); write output value y at time t+d; Less continuous: read sensor value x; if x · c then ... else ... We need system preference metrics in addition to boolean correctness criteria. [A Discounted Theory of Systems: de Alfaro et al.]

48. Summary • We need high-level programming models for building deterministic systems from nondeterministic parts. • We need system preference metrics for building continuous systems from noncontinuous parts.