Software Synthesis from Hybrid Automata Rajeev Alur System Design Research Lab University of Pennsylvania SEES Workshop, Chicago, Sept 2003

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

Hybrid Modeling State machines off on + Dynamical systems dx=kx x<70 dx=-k’x x>60 x>68 x<63 Modeling embedded software reacting to continuous world Past research: Verification, Control, Compositional modeling… Standardization effort: HSIF (DARPA’s MoBIES program)

Interacting Autonomous Robots Platform; AIBO robots MIPS microprocessor servo-motors touch sensors camera C++ programming env message-driven execution API for sensing and actuating Model-based Concurrency + hybrid Strategies Attack/defense modes Collaboration

Ideal Design Environment Programming/Modeling Language Based on Hybrid Automata Libraries in Base Language Platform Description Design and Analysis Tools Simulation, Verification, Optimization Formal Specification Environment Model Performance Metrics Executable Code on Embedded Processor Compiler + Scheduler Can we infer code properties from model properties ? Can we integrate task generation and scheduling?

Acknowledgements  Thanks to the Charon group at Penn Generating embedded software from hierarchical hybrid models; LCTES’03, 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.

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

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

 Input –touch sensors  Output –desired angles of each joint  Components –Brain: control four legs –Four legs: control servo motors Instantiated from the same pattern Walking Model: Architecture and Agents

x y j1 j2 L1 (x, y) v L2 Walking Model: Behavior and Modes dx = dy = 0 dy = kv dt = 1 dy = -kv dx = kv x < str /2 On GroundUp ForwardDown y==0 -> turn++ turn == i t==2 Shared variable Time triggered 2x==str Event triggered

CHARON Toolkit

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…)

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 objectsC++ objects Execution environment Target platform front-endback-end

Code Generator: Front-end  Variable C++ class: read and write to variables can be mapped to system API  Differential equation Euler’s 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

Code Generator: Back-end  Maps variables in the model to system API of the target platform  Our approach: “Makefile-like” script.{read|write}: : | x: joint(TAIL_JOINT) joint(id).write: rgn SetJointGain(rgn, id, value, newValue); TAIL_JOINT: #include “def.h” rgn: Region* #include “def.h” rgn = FindFreeRegion() x: joint(TAIL_JOINT) joint(id).write: rgn SetJointGain(rgn, id, value, newValue); TAIL_JOINT: #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); #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);

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)

Wagging the Tail  Variables –x: angle (env state) –u: speed (control output)  Non-deterministic switching  Continuous-time semantics dx=u u=+1 x<=25 dx=u u=-1 x>=-25 x u time

Code Generation 1. Generate task M : {up, down} sense(x); if (M==up) { u = +1; if x > 25 error; if (x >= 20) M=down; } else { … } actuate(u); dx=u u=+1 x<=25 dx=u u=-1 x>= Determine scheduling parameters - Period Delta - Deadline Delta Hopefully guided by control-theoretic analysis (e.g. sensitivity, robustness) up down

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 sense/compute/update 3. Periodic computation that takes time (predictable) SenseActuateComputeSenseActuateCompute 4. Scheduled computation (variable time)

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?

Avoiding Switching Errors Execute every Delta sec sense(x); if (M==up) { u = +1; if x > 25 error; if (x >= 20) M=down; } else { … } actuate(u); dx=u u=+1 x<=25 dx=u u=-1 x>=-25 When can we be sure to avoid error? In mode up, if x<20 holds at time T then x should not exceed 25 at time T + Delta This depends on model dynamics up down

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!

Semantics: From Model to Code Continuous SenseActuateComputeSenseActuateCompute 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 …

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

Code from Structured Designs  How 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 C1 x C2 uv

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 Initial Position Target Obstacle Estimate

Simulation Experiment  Performance metric defined wrt to continuous model Total distance travelled, or Error wrt reference trajectory  Assume d1 < d2,d3  Two reasonable choices C1;C2;C3 executed repeatedly C1;C2;C1;C3 executed repeatedly  Second choice performs better (updated position allows to change direction earlier) Initial Position Target Obstacle Estimate

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 don’t have a good solution yet  Note: tasks are platform indpendent, but schedule is dependent

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

Policy Integration for Smart Cards Java Cards Policy Installer Global Platform Compiler Analysis Policy Automata  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