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
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?
R B
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
Engineering Computer Science
The CHESS Premise: The pendulum has swung too far
R
B
Engineering Computer Science
Embedded Systems are a perfect playground to readjust the pendulum.
RPhysicality Computation
The CHESS Premise: The pendulum has swung too far
EmbeddedSystem
Execution constraints
CPU speed power failure rates
Reaction constraints
deadlines throughput jitter
Computation
algorithms protocols reuse
EmbeddedSystem
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).
EmbeddedSystem
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).
EmbeddedSystem
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).
EmbeddedSystem
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
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<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
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
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
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
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 t time 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
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.