Software Synthesis from Hybrid Automata

1
Software Synthesis fromHybrid Automata
Rajeev Alur System Design Research
Lab University of Pennsylvania
www.cis.upenn.edu/alur/
SEES Workshop, Chicago, Sept 2003
2
Model-Based Design

• Benefits of model-based design
• Detecting errors in early stages
• Powerful analysis and formal guarantees
• 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

3
Hybrid Modeling
Modeling embedded software reacting to continuous
world Past research Verification, Control,
Compositional modeling Standardization effort
HSIF (DARPAs MoBIES program)
4
Interacting Autonomous Robots
Model-based Concurrency hybrid Strategies
Attack/defense modes Collaboration
C programming env message-driven execution
API for sensing and actuating
Platform AIBO robots MIPS microprocessor
servo-motors touch sensors camera
5
Ideal Design Environment
Can we infer code properties from model
properties?
Formal Specification Environment
Model Performance Metrics
Can we integrate task generation and scheduling?
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
6
Acknowledgements

• Thanks to the Charon group at Penn
• Generating embedded software from hierarchical
  hybrid models LCTES03, with Ivancic, Kim, Lee,
  and Sokolsky
• Integrated discretization and scheduling
  (ongoing work with C.G.Arun)
• Caution Ongoing work (more questions than
  solutions!) feedback welcome.

7
Talk Outline

• Charon Overview and Case Study
• Sample Research Issues
• From continuous-time model to discrete software
• Missed events and switching errors
• Control blocks and optimal code generation

8
CHARON Language Features

• Individual components as agents
• Composition, instantiation, and hiding
• Individual behaviors as modes
• Encapsulation, instantiation, and Scoping
• Support for concurrency
• Shared variables as well as message passing
• Discrete and continuous behavior
• Differential as well as algebraic constraints
• Discrete transitions can call Java routines

Software engineering (hierarchy,
reuse) Concurrency theory (Compositionality,
refinement) Hybrid systems theory
9
Walking Model Architecture and Agents

• Input
• touch sensors
• Output
• desired angles of each joint
• Components
• Brain control four legs
• Four legs control servo motors
• Instantiated from the same pattern

10
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
11
CHARON Toolkit
12
Programming in Charon

• Formal and modular semantics
• modes and agents have compositional semantics in
  terms of sets of observable behaviors
• Rich and high-level programming model
• Shared variables synchronous communication
• Switches can be time-triggered, event-triggered
• Verification for linear systems
• Predicate abstraction Polyhedra based approx.
• But this is just the core, many extensions
  desirable (e.g. types, interfaces, inheritence)

13
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
14
Code Generator Front-end

• Variable
• C class read and write to variables can be
  mapped to system API
• Differential equation
• Eulers method x 100 ? x 100 h
• h step size (0.008 ms in AIBO)
• Algebraic equation
• Assignment statement executed in a data
  dependency order
• x 2y y 2z ? y 2z x 2y
• Transition
• If-then statement
• Mode
• C class collection of variables, equations,
  transitions, and reference to submodes
• Agent
• C class interleave execution of each step of
  subagents

15
Code Generator Back-end

• Maps variables in the model to system API of the
  target platform
• Our approach Makefile-like script
• ltvariablegt.readwrite ltsystem variables
  listgt ltAPI callgtltsystem variablegt lttypegt ltAPI
  callgt ltincludegt

x joint(TAIL_JOINT) joint(id).write rgn
SetJointGain(rgn, id, value, newValue) TAIL_JOI
NT include def.h rgn Region
include def.h rgn FindFreeRegion()
include def.h class joint public var
public joint(int id) id(id)
virtual void write(double value)
SetJointGain(rgn, id, value, newValue)
static Region rgn private int id
x(TAIL_JOINT)
16
What did we learn?

• Mapping structured hybrid automta to code is
  feasible, in principle
• Many research questions
• Discretization
• Switching errors and non-determinism
• Task generation and scheduling
• Not addressed in this talk
• Logical to physical concurrency
• Platform specification
• Evaluation (e.g. with respect to Simulink)

17
Wagging the Tail

• Variables
• x angle (env state)
• u speed (control output)
• Non-deterministic switching
• Continuous-time semantics

dxu u1 xlt25
dxu u-1 xgt-25
18
Code Generation

• 1. Generate task
• M up, down
• sense(x)
• if (Mup)
• u 1
• if x gt 25 error
• if (x gt 20) Mdown
• else
• actuate(u)

down
up
dxu u1 xlt25
dxu u-1 xgt-25
2. Determine scheduling parameters - Period
Delta - Deadline Delta Hopefully guided by
control-theoretic analysis (e.g. sensitivity,
robustness)
19
Semantics From Model to Code

• 1. Continuous-time semantics Task executes
  instantaneously at every time point

Continuous

• 2. Discrete/simulation semantics Task executes
  instantaneously at fixed (periodic) discrete
  points

• 3. Periodic computation that takes time
  (predictable)

• 4. Scheduled computation (variable time)

20
Bridging the gap between 1 and 2

• Rich theory of sampled control (but mainly for
  purely continuous systems)
• Discrete-time control design
• Sampling errors
• Accurate simulation (well-studied area)
• How to choose step size
• How to choose integration methods
• Variable step size to ensure events (that
  trigger mode switches) are not missed
• How can code ensure that events are not missed?

21
Avoiding Switching Errors

• Execute every Delta sec
• sense(x)
• if (Mup)
• u 1
• if x gt 25 error
• if (x gt 20) Mdown
• else
• actuate(u)

down
up
dxu u1 xlt25
dxu u-1 xgt-25
When can we be sure to avoid error? In mode
up, if xlt20 holds at time T then x should not
exceed 25 at time T Delta This depends on model
dynamics
22
Requirement on Models

• ? look-ahead condition Given a step size ? and
  a hybrid automaton, check whether for all pairs
  of invariants I and guards g of outgoing
  transitions, Post?(I g) is a subset of I
• If the model satisfies the condition then no
  switches are missed
• For systems with linear dynamics this requirement
  can be checked automatically

Model non-determinism is necessary for
implementability!
23
Semantics From Model to Code
1
Continuous
2
3
4

• Control theory has many tools to bridge gaps
  between 2,3,4
• u(t) depends on x(t-tau)
• Robustness of controllers
• Integrating control and scheduling

Programming abstractions Synchrony hypothesis,
Giotto
24
Why use continuous-time semantics?

• There is no standardized discrete-time
  simulator (or semantics)
• Many tricks, many approaches
• This is a recurring discussion topic in HSIF
• Committing to a discretization may be pessimistic
• Continuous-time semantics has many benefits
• Composable models
• Portable models (or blocks of code)
• Powerful control design tools available

25
Code from Structured Designs

• 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

26
Simulation Experiment

• Goal Head to target while avoiding obstacle
• Only an estimate of obstacle (model based on
  sensory vision)
• Estimate improves as robot gets near the
  obstacle
• Control output Direction
• Three blocks
• C1 Sense current position
• C2 Compute obstacle estimate
• C3 Decide direction
• Blocks take d1, d2, d3 time units to execute

Target
Obstacle Estimate
Initial Position
27
Simulation Experiment

• Performance metric defined wrt to continuous
  model
• Total distance travelled, or
• Error wrt reference trajectory
• Assume d1 lt d2,d3
• Two reasonable choices
• C1C2C3 executed repeatedly
• C1C2C1C3 executed repeatedly
• Second choice performs better (updated position
  allows to change direction earlier)

Target
Obstacle Estimate
Initial Position
28
Optimal Code Generation

• Input
• Set of control tasks (including sensing and
  actuating)
• Graph of dependencies among them
• WCET estimates for all the tasks
• Some measure of dependence of state on outputs
  of individual tasks
• Output Cyclic executive schedule that optimizes
  something (error wrt continuous model)
• We dont have a good solution yet
• Note tasks are platform indpendent, but
  schedule is dependent

29
Wrap-Up

• Generating software from hybrid models with
  continuous-time semantics has many appeals
• Many theoretical research directions
• Bridging the gap between model and code
• Optimal code generation to follow reference
  trajectories
• Many engineering issues
• Platform specification for automatic compilation
• Distributed platforms
• Experimentation Penn UAV platform

30
Policy Integration for Smart Cards

• Joint work with Carl Gunter, Michael McDougall
• Java cards offer programmable API
• Goal Allow dynamic installation of new policies
• Solution allows modular policies, detects for
  conflicts and redundancy
• Formal model Policy automaton is Extended FSM
  that vote (votes are constraints in defeasible
  logic) and resolve conflicting votes

Policy Automata
Analysis
Compiler
Policy Installer Global Platform
Java Cards