Designing Predictable and Robust Systems Tom Henzinger UC Berkeley and EPFL

Download Designing Predictable and Robust Systems Tom Henzinger UC Berkeley and EPFL

Post on 21-Dec-2015

215 views

Category:

Documents

3 download

Embed Size (px)

TRANSCRIPT

<ul><li> Slide 1 </li> <li> Designing Predictable and Robust Systems Tom Henzinger UC Berkeley and EPFL </li> <li> Slide 2 </li> <li> System Build &amp; test Bridge Aircraft Software etc. Complexity Management in System Design </li> <li> Slide 3 </li> <li> System Model Calculate Build &amp; test Abstract Predict Applied Mathematics Bridge Aircraft Software etc. Complexity Management in System Design </li> <li> Slide 4 </li> <li> Engineering Differential Equations Linear Algebra Probability Theory Computer Science Logic Discrete Structures Automata Theory Mathematical Modeling: A Tale of Two Cultures </li> <li> Slide 5 </li> <li> Uptime: 125 years </li> <li> Slide 6 </li> <li> Slide 7 </li> <li> Why cant we do Software? </li> <li> Slide 8 </li> <li> Engineering Theories of estimation. Theories of robustness. Computer Science Theories of correctness. Why cant we do Software? RB </li> <li> Slide 9 </li> <li> 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 cant we do Software? </li> <li> Slide 10 </li> <li> B EngineeringComputer Science The CHESS Premise: The pendulum has swung too far R </li> <li> Slide 11 </li> <li> B EngineeringComputer Science Embedded Systems are a perfect playground to readjust the pendulum. R PhysicalityComputation The CHESS Premise: The pendulum has swung too far </li> <li> Slide 12 </li> <li> Embedded System Execution constraints CPU speed power failure rates Reaction constraints deadlines throughput jitter Computation algorithms protocols reuse </li> <li> Slide 13 </li> <li> 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). </li> <li> Slide 14 </li> <li> 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). </li> <li> Slide 15 </li> <li> 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). </li> <li> Slide 16 </li> <li> Embedded System Execution constraints CPU speed power failure rates Reaction constraints deadlines throughput jitter Computation algorithms protocols reuse CHESS </li> <li> Slide 17 </li> <li> We need a new formal foundation for embedded systems, which systematically and even-handedly re-marries computation and physicality. The CHESS Challenge </li> <li> Slide 18 </li> <li> 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] </li> <li> Slide 19 </li> <li> 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]. </li> <li> Slide 20 </li> <li> 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) </li> <li> Slide 21 </li> <li> 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 </li> <li> Slide 22 </li> <li> Subchallenge 1: Build Predictable Software </li> <li> Slide 23 </li> <li> Predictable = Deterministic A system is deterministic if for every input behavior, the output behavior is unique. </li> <li> Slide 24 </li> <li> 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 </li> <li> Slide 25 </li> <li> 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 0i a[i+1], swap a[i] and a[i+1] -dont cares: if input=0, then output=? Central to concurrency: a||b = ab + ba </li> <li> Slide 26 </li> <li> 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 0i a[i+1], swap a[i] and a[i+1] -dont cares: if input=0, then output=? Central to concurrency: a||b = ab + ba invisible deterministic </li> <li> Slide 27 </li> <li> 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 0i a[i+1], swap a[i] and a[i+1] -dont cares: if input=0, then output=? Central to concurrency: a||b = ab + ba invisible deterministic visible a: x := x+1 b: x := 2x </li> <li> Slide 28 </li> <li> 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 0i a[i+1], swap a[i] and a[i+1] -dont 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 </li> <li> Slide 29 </li> <li> 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 </li> <li> Slide 30 </li> <li> 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 </li> <li> Slide 31 </li> <li> time ttime t+d real execution on CPU buffer output The LET (Logical Execution Time) Programming Model </li> <li> Slide 32 </li> <li> 50% CPU speedup Portability </li> <li> Slide 33 </li> <li> Task 2 Task 1 Composability </li> <li> Slide 34 </li> <li> Timing predictability: minimal jitter Function predictability: no race conditions Determinism </li> <li> Slide 35 </li> <li> make output available as soon as ready Contrast LET with Standard Practice </li> <li> Slide 36 </li> <li> data race Contrast LET with Standard Practice </li> <li> Slide 37 </li> <li> But what about performance? The Giotto project at UC Berkeley. </li> <li> Slide 38 </li> <li> 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.] </li> <li> Slide 39 </li> <li> Subchallenge 2: Build Robust Software </li> <li> Slide 40 </li> <li> Robust = Continuous A system is continuous if for all real-valued quantities, small input changes cause small output changes. </li> <li> Slide 41 </li> <li> 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 &gt;0. 9 &gt;0. input-change ) output-change -can apply only to real-valued quantities: sensor readings and actuator settings; input and output time stamps </li> <li> Slide 42 </li> <li> A Program kbfilter.c 12,000 lines of code </li> <li> Slide 43 </li> <li> A Program kbfilter.c 12,000 lines of code </li> <li> Slide 44 </li> <li> A Program kbfilter.c 12,000 lines of code r </li> <li> Slide 45 </li> <li> An Error Trace In general, programs are not continuous. </li> <li> Slide 46 </li> <li> 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... </li> <li> Slide 47 </li> <li> 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.] </li> <li> Slide 48 </li> <li> 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. </li> </ul>