Principles%20of%20Embedded%20Computation

1
Principles of Embedded Computation
Rajeev Alur University of Pennsylvania
www.cis.upenn.edu/alur/
Faculty Research Seminar, September 2005
2
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

3
Embedded Computation

• Typical embedded program cruise control
• Loop
• Read 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

4
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/

5
Hybrid Modeling
Systems Biology
Coordination Protocols
Automotive
Robotics
Animation
6
Timed Languages

• Recall basics of formal language theory
• A word over S 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 S is a sequence
  (a0,t0),(a1,t1)(ak,tk) with ai in S, ti in R,
  and t0ltt1ltlttk (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

7
Example
a,x0
b,y0
ygt2,c
xlt3,d

• 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

8
Timed Automata

• Analog 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,

9
Untiming

• Given a timed language L over S 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

10
Region-based AnalysisFinite partitioning of
state space
w _at_ w iff they satisfy the same set of
constraints of the form xi lt c, xi c, xi xj lt
c, xi xj c for c lt largest const relevant to
xi
x2
2
Region equivalence is a time-abstract bisimulation
, and corresponding quotient can be used for
temporal logic model checking, untiming,
checking emptiness
1
x1
1
2
3
An equivalence class (i.e. a region) in fact
there is only a finite number of regions!!
11
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

12
Charon Project at Penn
Can we formally prove safety properties of models?
Formal Specification Environment
Model Performance Metrics
Can we infer properties of code from properties
of models?
Programming/Modeling Language Based on Hybrid
Automata
Design and Analysis Tools Simulation,
Verification, Optimization
Libraries in Base Language
Compiler Scheduler
Platform Description
Executable Code on Embedded Processor
13
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

14
CHARON Toolkit
15
Model Checker
model
yes
temporal property
error-trace

• Advantages
• Automated formal verification, Effective
  debugging tool
• Impressive industrial success
• In-house groups Intel, Microsoft, Lucent,
  Motorola
• Commercial model checkers FormalCheck by Cadence
• Model checking for discrete systems
• Enumerative state-space search (SPIN)
• Symbolic search using Binary decision diagrams
  (SMV)
• Bounded model checking using SAT solvers

16
Symbolic Safety Verification

• Data type region to represent state-sets
• RI(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 R
• Termination may or may not be guaranteed

F
I
17
Reachability for Hybrid Systems

• Whats 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

18
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/resets
• Dynamics linear constraints among derivates
• The set of reachable states at every iteration is
  union of polyhedra
• If dynamics is dXAX, 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)

19
Walking Model Behavior and Modes
v
On Ground
Up
x
turn i
dy kv dt 1
dx dy 0
L1
j1
y0 -gt turn
j2
L2
t2
(x, y)
y
dx kv x lt str /2
dy -kv
Forward
Down
20
Code Generation Case Study

• Front-end
• Translate CHARON objects into modular C objects
• Back-end
• Map C objects to execution environment

front-end
back-end
CHARON objects
C objects
Executionenvironment
Targetplatform
agent
class agent
scheduler
mode
class mode diff() trans()
diff/alge eqn
API
transition
analog var
class var
21
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 ?

22
Code from Structured Models

• How to map control blocks to tasks?

• Many choices for code
• Two tasks C1 and C2 with their own periods
• One task Read(x)C1C2Actuate
• One task Read(x)C1Read(x)C2Actuate

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

23
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

24
From Model to Code

• 1. 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
4. Micro-schedule on TTA Fixed-size slots
Idle,Red,Blue,Idle, Blue,Red,Idle,Blue, Idle,Red,
Blue
25
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

26
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 step
• Ongoing 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)