The Embedded Systems Design Challenge

Tom Henzinger Joseph Sifakis EPFL Verimag Formal Methods: A Tale of Two Cultures

Engineering Computer Science

Differential Equations Logic Linear Algebra Discrete Structures Probability Theory Automata Theory

So how are we doing?

Uptime: 123 years What went wrong?

Engineering Computer Science

Differential Equations Logic Linear Algebra Discrete Structures Probability Theory Automata Theory What went wrong?

Engineering Computer Science

Differential Equations Logic Linear Algebra Discrete Structures Probability Theory Automata Theory

Mature Promising What went wrong?

Engineering Computer Science

Differential Equations Logic Linear Algebra Discrete Structures Probability Theory Automata Theory

Mature Promising? What went wrong?

Engineering Computer Science

Theories of estimation Theories of correctness Theories of robustness

Temptation: “Programs are mathematical objects.” What went wrong?

Engineering Computer Science

Theories of estimation Theories of correctness Theories of robustness R B Maybe we went too far?

Engineering Computer Science

R B Maybe we went too far?

Engineering Computer Science

Embedded Systems are a perfect playground to readjust the pendulum. R B Physicality Computation The Challenge

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

We need a new formal foundation for computational systems, which systematically and even-handedly re-marries performance and robustness.

What is being computed? How does the performance At what cost? change under disturbances? (change of context; change of resources; failures; attacks) Execution constraints CPU speed power failure rates Computation Embedded algorithms System protocols reuse Reaction constraints deadlines throughput jitter Embedded System Design is generalized hardware design Execution (e.g. System C) constraints CPU speed power failure rates Computation Embedded algorithms System protocols reuse Reaction constraints deadlines throughput jitter Execution constraints CPU speed power failure rates Computation Embedded algorithms System protocols reuse Reaction constraints deadlines throughput Embedded System Design is jitter generalized control design (e.g. Mathlab Simulink) Current State of Affairs

50 years of computer science are largely ignored in embedded systems design: it is as if there were no choice between automatically synthesizing code on one hand, and assembly coding on the other hand. Software is often the most costly and least flexible part of an embedded system. Embedded System Design should Execution not be left to electrical engineers constraints CPU speed power failure rates Computation Embedded algorithms System protocols reuse Reaction constraints deadlines throughput jitter Embedded System Design should Execution not be left to electrical engineers constraints CPU speed power failure rates Computation Embedded algorithms System protocols reuse Reaction constraints deadlines throughput jitter BUT: we need to revisit and revise our most basic paradigms to include methods from EE Subchallenge 1: Integrate Analytical and Computational Modeling

Engineering Computer Science Component model: transfer function Component model: subroutine Composition: parallel Composition: sequential Connection: data flow Connection: control flow

Analytical Models Computational Models Defined by equations Defined by programs Deterministic or probabilistic Executable by abstract machines Analytical Models Computational Models Defined by equations Defined by programs Deterministic or probabilistic Executable by abstract machines Strengths: Concurrency Dynamic change Real time Complexity theory Quantitative constraints (power, Nondeterminism (abstraction QoS, mean-time-to-failure) hierarchies, partial specifications) Analytical Models Computational Models Defined by equations Defined by programs Deterministic or probabilistic Executable by abstract machines Strengths: Concurrency Dynamic change Real time Complexity theory Quantitative constraints (power, Nondeterminism (abstraction QoS, mean-time-to-failure) hierarchies, partial specifications) Tool support: Average-case analysis Worst-case analysis Optimization Constraint satisfaction Continuous mathematics Discrete mathematics (logic, (differential equations, combinatorics) stochastic processes) Analytical Models Computational Models Defined by equations Defined by programs Deterministic or probabilistic Executable by abstract machines Strengths: Concurrency Dynamic change Real time Complexity theory Quantitative constraints (power, Nondeterminism (abstraction QoS, mean-time-to-failure) hierarchies, partial specifications) Tool support: Average-case analysis Worst-case analysis Optimization Constraint satisfaction Continuous mathematics Discrete mathematics (logic, (differential equations, combinatorics) stochastic processes) Main paradigm: Synthesis Verification N Analytical Models Computational Models IG Defined by equations S Defined by programs Deterministic or probabilisticE Executable by abstract maT chines R D Strengths: O S Concurrency M Dynamic change FF Real time E Complexity theoryE N T - Quantitative constraints (power, Nondeterminism (abstractionIG S D QoS, mean-time-to-failure) hierarchies, partial specifications)S Y E Tool support: E TE D T S Average-case analysis Worst-caseN analysisS R A Optimization Constraint satisfactionM ContinuousO mathematics DiscreteR mathematics (logic, A (differentialFF equations, combinatorics)TE stochasticE processes) U S G Y MainT- paradigm: S S SynthesisE Verification B Subchallenge 1: Integrate Analytical and Computational Modeling

Best-Effort Guaranteed-Effort Systems Design Systems Design

We need both. We need to be able to intelligently trade off costs and risks. We need effective model transformations. Subchallenge 1: Integrate Analytical and Computational Modeling

Best-Effort Guaranteed-Effort Systems Design Systems Design

We need both. We need to be able to intelligently trade off costs and risks. We need effective model transformations. We need engineers that understand both complexities. Subchallenge 2: Balance the Opposing Demands of Heterogeneity and Constructivity Subchallenge 2: Balance the Opposing Demands of Heterogeneity and Constructivity

Sources of heterogeneity Degrees of constructivity Components 1 Synthesis / compilation Levels of abstraction 2 Correctness by design disciplines Views (aspects) 3 Automatic verifiability Operating contexts 4 Formal verifiability Difficulties

Models and methods need to be compositional in order to scale. Whenever possible: noninterference Model-based Design

Requirements

Verification ideally automatic (model checking)

Model Environment

Implementation ideally automatic (compilation)

Resources Model-based Design

Requirements

Verification

Component Component

Implementation

Resources Noninterference

Requirements

no change Verification necessary Composition Component Component

no change Implementation necessary

Resources Noninterference

Requirements (time, fault tolerance, etc.)

no change Verification necessary Composition Component Component

no change Implementation necessary

Resources Difficulties

Models and methods need to be compositional in order to scale. Whenever possible: noninterference Next best solution: check interface compatibility Difficulties

Models and methods need to be compositional in order to scale. Whenever possible: noninterference Next best solution: check interface compatibility

Models and methods need to support robustness in addition to functionality. Whenever possible: continuity Difficulties

Models and methods need to be compositional in order to scale. Whenever possible: noninterference Next best solution: check interface compatibility

Models and methods need to support robustness in addition to functionality. Whenever possible: continuity Next best solution: quantify overengineering Some Examples

1 Heterogeneity through hybrid automata 2 Continuity through discounting 3 Noninterference through fixed logical execution times 4 Compositionality through automaton interfaces Continuous Dynamical Systems

State space: Rn Dynamics: initial condition + differential equations

Room temperature: x(0) = x0 x x’(t) = -K·x(t)

x0

t

Analytic complexity. Discrete Transition Systems

State space: Bm Dynamics: initial condition + transition relation

Heater: heat off on

off

on t Combinatorial complexity. Hybrid Automata

State space: Bm × Rn Dynamics: initial condition + transition relation + differential equations

Thermostat: off x’ = -K·x x0 x ≥ L x ≤ l x ≥ u

off on x’ = K·(H-x) x ≤ U on t Some Examples

1 Heterogeneity through hybrid automata 2 Continuity through discounting 3 Noninterference through fixed logical execution times 4 Compositionality through automaton interfaces (Non)Robustness

Hybrid Automaton Property

slightly perturbed automaton (Non)Robustness

Hybrid Automaton

Safe x = 3 (Non)Robustness

Hybrid Automaton

Unsafe x = 3+ε A Continuous Theory of Systems

value(Model,Property): States → B

value(Model,Property): States → R A Continuous Theory of Systems

value(Model,Property): States → B value(m,‘T) = (μX) (T ∨ pre(X))

discountedValue(Model,Property): States → R discountedValue(m,‘T) = (μX) max(T, λ⋅pre(X))

discount factor 0<λ<1 Reachability

T 1 a b c

‘ c … undiscounted property

‘λ c … discounted property Reachability

(F Ç pre(T)) = T T 1 a b c

‘ c … undiscounted property

‘λ c … discounted property Reachability

(F Ç pre(T)) = T T max(0, λ¢ pre(1)) = λ 1 a b c

‘ c … undiscounted property

‘λ c … discounted property Reachability

(F Ç pre(T)) = T T max(0, λ¢ pre(1)) = λ 1

a b c T λ2 ‘ c … undiscounted property

‘λ c … discounted property A Continuous Theory of Systems

Robustness Theorem [de Alfaro, H, Majumdar]:

If discountedBisimilarity(m1,m2) > 1 - ε, then |discountedValue(m1,p) - discountedValue(m2,p)| < f(ε). A Continuous Theory of Systems

Robustness Theorem [de Alfaro, H, Majumdar]:

If discountedBisimilarity(m1,m2) > 1 - ε, then |discountedValue(m1,p) - discountedValue(m2,p)| < f(ε).

Further advantages of discounting:

-approximability because of geometric convergence (avoids non-termination of verification algorithms) -applies also to probabilistic systems and to games (enables reasoning under uncertainty, and control) Some Examples

1 Heterogeneity through hybrid automata 2 Continuity through discounting 3 Noninterference through fixed logical execution times 4 Compositionality through automaton interfaces Compositionality

Requirements (time, fault tolerance, etc.)

no change Verification necessary Composition Component Component

no change Implementation necessary

Resources Compositionality

Requirements (time, fault tolerance, etc.)

FET model no change Verification necessary Composition Component Component

no change Implementation E machine necessary

Resources The FET (Fixed Execution Time) Assumption

Software Task

write actuator read sensor output at time input at time t t+d, for fixed d The FET (Fixed Execution Time) Assumption

Software Task

d>0 is the write actuator read sensor task's “fixed output at time input at time t execution time" t+d, for fixed d The FET Programming Model

The programmer specifies d (could be any event) to solve the problem at hand. The compiler ensures that d is met on a given platform (hardware performance and utilization); otherwise it rejects the program. The FET (Fixed Execution Time) Assumption

time t time t+d

real execution on CPU buffer output Portability

50% CPU speedup Composability

Task 1

Task 2 Verifiability through Predictability (Internal Determinism)

Timing predictability: minimal jitter Function predictability: no race conditions Contrast FET with Standard Practice

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

Race Some Examples

1 Heterogeneity through hybrid automata 2 Continuity through discounting 3 Noninterference through fixed logical execution times 4 Compositionality through automaton interfaces A Signature Interface

This interface constrains the int client’s data. is_prime E.g. typed bool programming languages. Signature Interface Compatibility

int int client is_prime bool bool An Assertional Interface

This interface still constrains x: int the client’s data. y: int; y ≠ 0 divide_by E.g. extended static checking. real Assertional Interface Compatibility

a: int x: int client divide_by b: int; b > 0 y: int; y ≠ 0

real

8 b,y. (b > 0 Æ y = b ) y ≠ 0) Assertional Interface Compatibility

a: int x: int client divide_by b: int; b > 0 y: int; y ≠ 0

real

8 b,y. (b > 0 Æ y = b ) y ≠ 0)

Preconditions are assumptions on the input. Postconditions are guarantees on the output. An Automaton Interface

open file

This interface close open? close? constrains the client’s control. read read? data!

data Automaton Interface Compatibility

open file open! close open? close? close! read! read read? data! data?

data Client Automaton Interface Incompatibility

open file

close open? close? open! read open! read? data!

data Client Automaton Interface Incompatibility

open file

close open? close? open! read open! read? data!

data Client Summary

Verifying properties is not an end but a mean. The end is designing reliable systems. The challenge is to come up with a formal foundation for systems design that lets us quantify how the effort spent during design relates to the quality (functionality, performance, robustness) of the product. Credits

Hybrid Automata: R. Alur, P.-H. Ho, J. Sifakis, et al.

Discounting: L. de Alfaro, R. Majumdar, et al.

Giotto: B. Horowitz, C. Kirsch, et al.

Interfaces: A. Chakrabarti, L. de Alfaro, et al.