1 / 48

Designing Predictable and Robust Systems

Designing Predictable and Robust Systems. Tom Henzinger UC Berkeley and EPFL. Complexity Management in System Design. Bridge Aircraft Software etc. System.

gay-calhoun
Download Presentation

Designing Predictable and Robust Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

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

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

  8. 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.

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

  10. 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

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

  12. 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

  13. 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).

  14. 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).

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

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

  17. 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]

  18. 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].

  19. 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)

  20. 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

  21. Subchallenge 1: Build Predictable Software

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

  23. 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

  24. 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

  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 invisible invisible invisible deterministic

  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 visible a: x := x+1 b: x := 2x

  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 Alternatives to threads: actor models; transactional memory invisible invisible invisible deterministic visible less nondeterministic

  28. 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

  29. 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

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

  31. Portability 50% CPU speedup

  32. Composability Task 1 Task 2

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

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

  35. Contrast LET with Standard Practice data race

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

  37. 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.]

  38. Subchallenge 2: Build Robust Software

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

  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. -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

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

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

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

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

  45. 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 ...

  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 ... We need system preference metrics in addition to boolean correctness criteria. [A Discounted Theory of Systems: de Alfaro et al.]

  47. 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.

More Related