Principles of embedded computation

Principles of Embedded Computation

Rajeev Alur

University of Pennsylvania www.cis.upenn.edu/~alur/

Faculty Research Seminar, September 2005

Theory of Discrete Computation

Typical programming examples: Sorting, pattern search, graph algorithms…

Program is a function from inputs to outputs Finite-state computation

Automata theory, regular languages Limits of computability

Turing machines Correctness

Assertions, pre/post conditions Tools: Program analysis, type systems, model checking…

Efficiency and resources: complexity theory

Embedded Computation Typical embedded program: cruise control

LoopRead the sensors;Compute speed;Compute pressure for brake pedal / accelerator;Transmit the outputs to actuators;

Discrete theory of computation not enough Program has (non-terminating) interaction

with the outside world: Reactive computation Correctness depends on real-time response

(does the car brake fast enough?) Analysis of correctness requires modeling of

the dynamics of the car

Embedded Software Systems Software embedded in an engineering product

Automobiles, avionics, robots, cell phones, medical devices, smart appliances

Two research thrusts in embedded systems Resource constraints (low power, small memory) Control systems interacting with physical world

Embedded systems industry is realizing the importance of software

Majority of innovations in cars are in software Software getting complex, source of errors Research challenge: how to program/design embedded systems?

Emerging as a new academic sub-discipline Control theory, Formal methods, Real-time scheduling, Sensor networks, Power-aware computing … New SIG in ACM: SIGBED www.acm.org/sigbed/

Hybrid ModelingState machines

offon

+ Dynamical systems

dx/dt=kxx<70

dx/dt=-k’xx>60

x>68

x<63

Automotive Robotics AnimationSystemsBiology

CoordinationProtocols

Timed Languages Recall basics of formal language theory:

A word over is a sequence of symbols A language L is a set of words A language is regular if there is a finite automaton that accepts/generates L Rich and well-studied theory of regular languages

A timed word over is a sequence (a0,t0),(a1,t1)…(ak,tk) with ai in , ti in R, and t0<=t1<=…<=tk (monotonicity of time)

A timed language is a set of timed words A timed language L is timed regular if there is

a timed automaton whose timed language is L

Example

Words of the form (abcd)* such that c occurs after a delay of at least 2 wrt last b, and d occurs within 3 of last a

a,x:=0 b,y:=0

x<3,d

y>2,c

Timed AutomataAnalog of finite-state automata in discrete

case Continuous variables: Clocks increasing at rate 1 All constraints of the form: x compared to constant Can express lower and upper bounds on delays

Closure properties: Closed under union and intersection, but not complement

Decision problems: Checking emptiness is solvable, but not language inclusion

Equivalent Characterizations using timed regular expressions and logics

Applications: Timed circuits, Scheduling, Communication protocols,…

Untiming Given a timed language L over the

language Untime(L) consists of words a0,a1,…ak such that there exists a timed word (a0,t0),(a1,t1)…(ak,tk) in L

Thm: If L is timed regular, then Untime(L) is regular. proof by region construction

Region-based AnalysisFinite partitioning of state space

x1

x2

An equivalence class (i.e. a region)in fact there is only a finite number of regions!!

1 2 3

1

2

w w’ iff they satisfy the same set of constraints of the formxi < c, xi = c, xi – xj < c, xi –xj =cfor c <= largest const relevant to xi

Region equivalence is a time-abstractbisimulation, and correspondingquotient can be used for temporallogic model checking, untiming, checking emptiness …

Model-Based Design Benefits of model-based design

Detecting errors in early stages Powerful and formal analysis Reusable components Automatic code generation

Many commercial tools are available for design of embedded control systems (e.g. Simulink)

Typically, semantics is not formal Typically, only simulation-based analysis Code generation available, but precise relationship between model and code not understood

Charon Project at Penn

Programming/Modeling LanguageBased on Hybrid Automata

Libraries in Base LanguagePlatform Description

Design and Analysis ToolsSimulation, Verification, Optimization

Formal SpecificationEnvironment ModelPerformance Metrics

Executable Code onEmbedded Processor

Compiler +Scheduler

Can we formally prove safety properties of models?

Can we infer properties of code from properties of models?

CHARON Language Features Individual components described as agents

Composition, instantiation, and hiding Individual behaviors described as modes

Encapsulation, instantiation, and Scoping Support for concurrency

Shared variables as well as message passing Support for discrete and continuous

behavior Differential as well as algebraic constraints Discrete transitions can call Java routines

Compositional semantics with refinement rules

CHARON Toolkit

Model Checker

AdvantagesAutomated formal verification, Effective debugging tool

Impressive industrial successIn-house groups: Intel, Microsoft, Lucent, Motorola…Commercial model checkers: FormalCheck by Cadence

Model checking for discrete systemsEnumerative state-space search (SPIN)Symbolic search using Binary decision diagrams (SMV)Bounded model checking using SAT solvers

model

temporalproperty

yes

error-trace

Symbolic Safety Verification

Data type: region to represent state-setsR:=I(X) /* initial set */Repeat

If R intersects target F report “violation”

Else if R contains Post(R) report “safe”Else R := R union Post(R)

Post(R): Set of successors of states in RTermination may or may not be guaranteed I

F

Reachability for Hybrid Systems

What’s a suitable representation of regions? Region: subset of Rk

Main problem: handling continuous dynamics Precise solutions available for restricted

continuous dynamics Timed automata (Uppaal, Kronos, …) Linear hybrid automata (HyTech)

Even for linear systems, over-approximations of reachable set needed

Model Checking for Hybrid Systems

Timed automata tools use matrices as a symbolic representation (all constraints are bounds on differences)

Next step: use polyhedra as a representation (HyTech)Linear hybrid automaton allows linear constraints in guards/resetsDynamics: linear constraints among derivatesThe set of reachable states at every iteration is union of polyhedra

If dynamics is dX=AX, and R is a polyhedron, Post(R) is not a polyehdron

Many approximate solutions proposed:Approximate Post(R) with enclosing convex polyhedra (Checkmate)This approximation combined with predicate abstraction and counter-example guided abstraction refinement (Charon)

x

y

j1j2

L1

(x, y)

v

L2

Walking Model: Behavior and Modes

dx = dy = 0 dy = kvdt = 1

dy = -kv dx = kvx < str /2

On Ground Up

ForwardDown

y==0->

turn++

turn == i

t==2

Shared variable

Time triggered

2x==str

Event triggered

Code Generation Case Study Front-end

Translate CHARON objects into modular C++ objects Back-end

Map C++ objects to execution environment

agent

mode

analog var

diff/alge eqn

transition

class agent

class mode diff() trans()

class var

scheduler

API

CHARON objects C++ objects Executionenvironment Target

platform

front-end back-end

Gap Between Models and Code

Rich theory of sampled control (but mainly for purely continuous systems)

Discrete-time control design Sampling errors

No theory of interacting control blocks Mapping individual blocks to periodic real-time tasks does not lead to predictability Lack of compositionality affects integration

Hybrid systems poses new challenges: How can code ensure that events are not missed ?

Code from Structured ModelsHow to map control blocks to tasks?

The choice can depend on many parameters: computation times, sensitivity ox x to u and v, performance objective

Many choices for code Two tasks: C1 and C2 with their own periods One task: Read(x);C1;C2;Actuate One task: Read(x);C1;Read(x);C2;Actuate

C1x C2u v

Quantifying the Gap (1)Appealing implementation platform:

Time-triggered architecture Time divided into fixed-size slots

Appealing programming paradigm: Fixed Logical Execution Time

Block mapped to slot i reads inputs at the beginning, computes, and outputs at the end of the slot i

Micro-schedule: Map each slot to at most one control block

Given a micro-schedule s, and a plant model, continuous-time trajectory of execution uniquely defined

From Model to Code1. Continuous-time semantics: all blocks at all times

Continuous

2. Discrete/simulation semantics: all blocks every T s

3. Periodic tasks: Red block every T1 s, Blue every T2 s

Compute all Compute all Compute all Compute all

4. Micro-schedule on TTA: Fixed-size slots

Idle,Red,Blue,Idle, Blue,Red,Idle,Blue, Idle,Red, Blue…

Quantifying the Gap (2)Define a performance metric: for two

continuous-time trajectories t1 and t2, d(t1,t2) measures the distance

Quality of a micro-schedule s is d(t*,ts), where t* is the continuous-time simulation trajectory and ts is the trajectory of code when executed according to s

For linear systems, d(t*,ts) is computable when d is, say, L2-norm, using ideas from PLTIs (Periodic linear time invariant systems)

This allows comparing micro-schedules by precisely quantifying their metrics

Wrap-Up Many application domains for hybrid

systems Embedded software: Emerging research

area Current Research:

Understanding and quantifying the gap between models and code to add rigor in the code generation stepOngoing: Stochastic hybrid systems

Embedded systems research at Penn: Lee, Pappas, Sokolsky, GRASP lab

Other Research Area: Formal Methods for hardware and software analysis (see talk in 2003 versoin of 996 seminar: Catching bugs in software)