From Hybrid Models to Embedded Software

1. From Hybrid Modelsto Embedded Software Rajeev Alur System Design Research Lab University of Pennsylvania www.cis.upenn.edu/~alur/ Workshop on Robustness, Abstractions, and Computation Philadelphia, March 2004

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 Past Research: Formal verification using counter-example guided predicate abstraction and reachability analysis using polyhedral approximations

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? Can continuous-time semantics be a useful programming abstraction? 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 scheduling and code generation (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) { if x > 25 error; if (x >= 20) {M=down; u=-1} } 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) { if x > 25 error; if (x >= 20) {M=down; u=-1} } 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 • Relative complexity 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) • Solution: Using ideas from theory of non-preemptive scheduling

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