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.