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

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

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

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

5. Uptime: 125 years

7. Why can’t we do Software?

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

9. 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. Why can’t we do Software?

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

11. B EngineeringComputer Science Embedded Systems are a perfect playground to readjust the pendulum. R PhysicalityComputation The CHESS Premise: The pendulum has swung too far

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

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

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

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

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

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

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. 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 CHESS Results: Integration of the Two Cultures Engineers must understand both complexities and trade-offs [EECS 20].

20. We need a new formal foundation for computational systems, which systematically and even-handedly re-marries performance and robustness. The Cyber-Physical Challenge 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. We need a new formal foundation for computational systems, which systematically and even-handedly re-marries performance and robustness. The Cyber-Physical Challenge Subchallenge 1: build predictable software Subchallenge 2: build robust software

22. Subchallenge 1: Build Predictable Software

23. 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 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 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 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 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 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 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 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 read sensor input at time t write actuator output at time t+d, for specified d

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

32. 50% CPU speedup Portability

33. Task 2 Task 1 Composability

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

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

36. data race Contrast LET with Standard Practice

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. 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 kbfilter.c 12,000 lines of code r

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 1.We need high-level programming models for building deterministic systems from nondeterministic parts. 2.We need system preference metrics for building continuous systems from noncontinuous parts.