Designing Predictable and Robust Systems Tom Henzinger UC Berkeley and EPFL

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

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

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

Uptime: 125 years

Why can’t we do Software?

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

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?

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

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

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

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

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

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

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

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

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]

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

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)

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

Subchallenge 1: Build Predictable Software

Predictable = Deterministic A system is deterministic if for every input behavior, the output behavior is unique.

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

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

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

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

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

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

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

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

50% CPU speedup Portability

Task 2 Task 1 Composability

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

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

data race Contrast LET with Standard Practice

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

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

Subchallenge 2: Build Robust Software

Robust = Continuous A system is continuous if for all real-valued quantities, small input changes cause small output changes.

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

A Program kbfilter.c 12,000 lines of code

A Program kbfilter.c 12,000 lines of code

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

An Error Trace In general, programs are not continuous.

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

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

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.