Upload
nguyenkhuong
View
242
Download
1
Embed Size (px)
Citation preview
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
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)