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. State machines + Dynamical systems x>68 off on dx=-k’x x>60 dx=kx x<70 x<63 Hybrid Modeling Modeling embedded software reacting to continuous world Past research: Verification, Control, Compositional modeling… Standardization effort: HSIF (DARPA’s 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 Compiler + Scheduler Libraries in Base Language Platform Description Executable Code on Embedded Processor

6. 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.

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. Shared variable Time triggered 2x==str Event triggered Walking Model: Behavior and Modes v On Ground Up x turn == i dy = kv dt = 1 dx = dy = 0 L1 j1 y==0 -> turn++ L2 j2 t==2 (x, y) y dx = kv x < str /2 dy = -kv Down Forward

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

15. Code Generator: Back-end • Maps variables in the model to system API of the target platform • Our approach: “Makefile-like” script <variable>.{read|write}: <system variables list> <API call><system variable>: <type> <API call> | <#include> 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);

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. 25 20 u x time -20 -25 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

18. 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); down up dx=u u=+1 x<=25 dx=u u=-1 x>=-25 2. Determine scheduling parameters - Period Delta - Deadline Delta Hopefully guided by control-theoretic analysis (e.g. sensitivity, robustness)

19. sense/compute/update sense/compute/update Sense Compute Actuate Sense Compute Actuate 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 (M==up) { u = +1; if x > 25 error; if (x >= 20) M=down; } else { … } actuate(u); down up 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

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. Sense Compute Actuate Sense Compute Actuate Semantics: From Model to Code 1 Continuous 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 2 3 4 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. u v x C1 C2 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);C1;C2;Actuate • One task: Read(x);C1;Read(x);C2;Actuate • The choice can depend on many parameters: computation times, sensitivity ox x to u and v, performance objective

26. Simulation Experiment Target • 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 Obstacle Estimate Initial Position

27. Simulation Experiment Target • 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) 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 don’t 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 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 Analysis Compiler Policy Installer Global Platform Java Cards