1. System Design Research Lab University of Pennylvania 2/8/2006 CHARON modeling language

2. System Design Research Lab University of Pennylvania 2/8/2006 Outline Languages for hybrid systems –Overview of design decisions –Context for CHARON CHARON language: the user perspective –Overview of language features –CHARON by example –Semantics CHARON toolset

3. System Design Research Lab University of Pennylvania 2/8/2006 Languages for hybrid systems Design decisions –domain-specific vs. domain-independent –modeling style –typed vs. untyped choice of type system –compositionality vs. structuring

4. System Design Research Lab University of Pennylvania 2/8/2006 Application domains Hybrid systems describe a variety of domains –Control systems controllers, plants, sensors and actuators; feedback –Electrical systems voltage and current; capacitors, transistors, etc. –Mechanical systems mass and moment; rigid bodies, friction –Biological systems species and reactions; promoters and inhibitors; concentrations and rate laws

5. System Design Research Lab University of Pennylvania 2/8/2006 Domain-specific languages Domain-specific languages use concepts of the application domain –Translated to mathematical models internally Domain-independent languages offer modeling in terms of mathematical concepts directly Differential equations Switching conditions Reset maps

6. System Design Research Lab University of Pennylvania 2/8/2006 Advantages and disadvantages Domain-specific languages –are more intuitive to use –easier to understand models – fewer errors –may support domain-specific analysis Domain-independent languages –usually more expressive –wider applicability –easier to extend

7. System Design Research Lab University of Pennylvania 2/8/2006 What’s more important? Switch-centric Flow-centric d(x)=k*x x>10x<10 k-510

8. System Design Research Lab University of Pennylvania 2/8/2006 Modeling styles High-level models –System requirements –Primarily captures behavior Low-level models –System design –Behavior + structure –Software vs. nature –Code generation

9. System Design Research Lab University of Pennylvania 2/8/2006 Types for hybrid systems A common programming language concept –helps avoid common simple mistakes –helps compiler produce executable Common elements of type systems –type of stored value –distinguish between input and output Types specific to hybrid systems –is the variable updated continuously? –can the variable be reset?

10. System Design Research Lab University of Pennylvania 2/8/2006 Hierarchical modeling Construct system from components –Composite components consist of primitive components or other composite components Advantages: –capture the structure of the problem –hide details –reuse components

11. System Design Research Lab University of Pennylvania 2/8/2006 Structuring and compositionality Hierarchy may be syntactic or semantic Syntactic hierarchy provides structuring and modularization –means to store large models in small chunks –ensures that sub-models have compatible inputs and outputs Compositional semantics for hierarchy allows to compute behavior of the model from behaviors of its sub-models

12. System Design Research Lab University of Pennylvania 2/8/2006 CHARON Domain-independent Inspired by embedded/control applications –switch-centric –both requirements- and design-level models Strongly typed Has compositional semantics

13. System Design Research Lab University of Pennylvania 2/8/2006 Language features: hierarchy Architectural hierarchy –Autonomous agents can contain subagents –Agents execute concurrently –Communication via shared variables Behavioral hierarchy –Each agent is described as a state machine modes and transitions –Modes can contain submodes

14. System Design Research Lab University of Pennylvania 2/8/2006 Language features: modularity Encapsulation –Local (private) variables restrict communication and hide details of behavior Instantiation –An agent or mode defined in the model can be instantiated multiple times –Agents and modes can have parameters that are given values at instantiation

15. System Design Research Lab University of Pennylvania 2/8/2006 Agents: architecture and data flow Agents are autonomous concurrent components in the model An agent consists of variable definitions and may contain sub-agents Agent interfaces are global variables Tank Hole leak private analog real leak level inflow LTank Pump level flow

16. System Design Research Lab University of Pennylvania 2/8/2006 Agents: definition and instantiation // the tank agent with a hidden leak agent LTank() { private analog real leak; agent tank = Tank(); agent hole = Hole(); } // a leaky tank controlled by a pump agent LeakyTank() { private analog real level, flow; agent tank = LTank( ) [ inflow := flow ] agent pump = Pump( 5, 10 ) } definition instantiation parameterized instantiation

17. System Design Research Lab University of Pennylvania 2/8/2006 Primitive agents A primitive agent does not have concurrent structure –single thread of control Behavior is given by a mode agent Tank() { write analog real level; init { level = 6; } mode top = TankMode( ); }

18. System Design Research Lab University of Pennylvania 2/8/2006 Modes: behavior A mode is a hierarchical hybrid state machine A primitive mode is a single-state machine Behavior is given by constraints mode TankMode() { read analog real inflow; read analog real leak; write analog real level; diff { d(level) == inflow-leak } inv { 0 <= level and level <= 15 } } inflow leak

19. System Design Research Lab University of Pennylvania 2/8/2006 Modes: behavior + discrete control Composite modes have multiple submodes and discrete transitions between them PumpModeprivate analog real clock diff { d(clock) == 1 } start return Compute Maintain onturnOff offadjust inv { clock <= 1 } clock >= 1 {clock = 0}

20. System Design Research Lab University of Pennylvania 2/8/2006 Modes: behavior + discrete control Modes have variable declarations, same as agents PumpModeprivate analog real clock diff { d(clock) == 1 } start return Compute Maintain onturnOff offadjust inv { clock <= 1 } clock >= 1 {clock = 0}

21. System Design Research Lab University of Pennylvania 2/8/2006 Modes: behavior + discrete control Modes can have constraints at any level PumpModeprivate analog real clock diff { d(clock) == 1 } start return Compute Maintain onturnOff offadjust inv { clock <= 1 } clock >= 1 {clock = 0}

22. System Design Research Lab University of Pennylvania 2/8/2006 Modes: behavior + discrete control Transitions are instantaneous Transitions have guards and actions PumpModeprivate analog real clock diff { d(clock) == 1 } start return Compute Maintain onturnOff offadjust inv { clock <= 1 } clock >= 1 {clock = 0}

23. System Design Research Lab University of Pennylvania 2/8/2006 Modes: behavior + discrete control Transition can happen when its guard is true Transition must happen when invariant is false PumpModeprivate analog real clock diff { d(clock) == 1 } start return Compute Maintain onturnOff offadjust inv { clock <= 1 } clock >= 1 {clock = 0}

24. System Design Research Lab University of Pennylvania 2/8/2006 Control points Mode interface: entry and exit points –Control enters mode via entry points and exits via exit points Different paths through a mode correspond to different qualitative behaviors slow fast set=25 set=65 alge { speed == set } crash stop

25. System Design Research Lab University of Pennylvania 2/8/2006 Named vs. default control points Default control points allow: –preemption –history start return Compute Maintain onturnOff offadjust inv { clock <= 1 } clock >= 1 {clock = 0}

26. System Design Research Lab University of Pennylvania 2/8/2006 PumpMode text mode PumpMode( int low, int high ) { private analog real clock; private discrete real rate; write analog real flow; read analog real level; mode m = Maintain( 0.1, low, high ); mode c = Compute(); trans from default to m when true do { clock = 0; rate = 0 } trans from m to c.start when clock > 1 do { clock = 0; } trans from c.return to m when true do { } diff { d(clock) == 1 } }

27. System Design Research Lab University of Pennylvania 2/8/2006 Computational modes Useful for modeling software components –Do not have continuous behavior –Instantaneous execution –Internal structure defines control flow delta = level-past return rate = 0 start delta > 0 rate = -delta delta <= 0 Compute past = level

28. System Design Research Lab University of Pennylvania 2/8/2006 CHARON Semantics Similar to hybrid automata Two main differences: –Mode hierarchy –Asynchronous vs. synchronous semantics Synchrony vs. asynchrony –asynchronous = pure interleaving –synchronous = dependency-preserving interleaving

29. System Design Research Lab University of Pennylvania 2/8/2006 Active modes and history A mode can be active or inactive If a mode is active and has submodes –One of the submodes is active start return Compute Maintain onturnOff offadjust inv { clock <= 1 } clock >= 1 {clock = 0}

30. System Design Research Lab University of Pennylvania 2/8/2006 Active modes and history If a mode is preempted, its active submode should be restored upon return start return Compute Maintain onturnOff offadjust inv { clock <= 1 } clock >= 1 {clock = 0}

31. System Design Research Lab University of Pennylvania 2/8/2006 Active modes and history A new private variable in each mode M: h M Values for history variable: Transition actions manipulate history variables Default exits keep h, non-default reset to  start return Compute Maintain onturnOff offadjust inv { clock <= 1 } clock >= 1 {clock = 0, h=Compute} {h=Maintain} {h M =off}{h M =on} {h M =turnOff} C1C1 C2C2 {h C =C 1 } {h C =C 2 } {h C =  }

32. System Design Research Lab University of Pennylvania 2/8/2006 Mode semantics State of a mode: –Type-correct valuation of all variables –Variables of the mode and its submodes V * =V g ] V p*, V p* =V l ] V l* SM Continuous steps –Given by flows Discrete steps –Entry, exit and internal steps

33. System Design Research Lab University of Pennylvania 2/8/2006 Continuous steps: all in due time Cannot let time pass at arbitrary moments: –All modes need to be properly initialized –All applicable constraints must be used Discrete steps must be “complete” –Start and end in a primitive mode x2x2 e2e2 x1x1 e1e1 { v 1 = g(v 2 ) } { v 1 = f(v 2 ) } v 2 :=0 M1M1 M 11 M 21 M2M2

34. System Design Research Lab University of Pennylvania 2/8/2006 Discrete steps Internal steps: R D –M 1 : → 2 R D –M: → 2 R D Entry steps: Re for each entry exit e –M 2 : → 2 R e2 x2x2 e2e2 x1x1 e1e1 { v 1 = g(v 2 ) } { v 1 = f(v 2 ) } v 2 :=0 M1M1 M 11 M 21 M2M2

35. System Design Research Lab University of Pennylvania 2/8/2006 Anatomy of an internal step Exit step of a submode M 1 : q 1 → q 2 2 R x2 Transition of the mode M: q 2 → q 3 2 T Entry step of another submode M 2 : q3 → q4 2 R e2 Internal step of the mode M: q 1 → q 4 2 R D x2x2 e2e2 x1x1 e1e1 { v 1 = g(v 2 ) } { v 1 = f(v 2 ) } v 2 :=0 M1M1 M 11 M 21 M2M2 )

36. System Design Research Lab University of Pennylvania 2/8/2006 Asynchrony: it’s a game The choice between discrete and continuous steps is external to every component Discrete step of the system is a discrete step of one component Agent 1 Agent 2 Pass time

37. System Design Research Lab University of Pennylvania 2/8/2006 Asynchrony: pros and cons Pros: –Fits shared variable model well –Very easy to implement Cons: –Can be used to implement other communication mechanisms –Model becomes cumbersome

38. System Design Research Lab University of Pennylvania 2/8/2006 Example: event counter {x = 0} {x = 1} x y x == 1 {y = y + 1}

39. System Design Research Lab University of Pennylvania 2/8/2006 Example: event counter Adding invariant does not help! {x = 0} {x = 1} x y x == 1 {y = y + 1}

40. System Design Research Lab University of Pennylvania 2/8/2006 Example: event counter Model is more complex Code generation is problematic {x = 0} {x = 1} x y x == 1 {y = y + 1, z = false} {z = true} x == 0 z == false z == true z {x == 0}

41. System Design Research Lab University of Pennylvania 2/8/2006 Synchrony: serious matter Discrete step of the system is made of one discrete step of every component –Schedule can be chosen by the environment –Must preserve dependencies Agent 1 Agent 2 Pass time

42. System Design Research Lab University of Pennylvania 2/8/2006 Dependencies in agents Algebraic and discrete dependencies are instantaneous: x(t) = f(…, y(t),…) Differential dependencies are not instantaneous x(t) = x(t-dt)+f(…, y(t-dt),…) Circular instantaneous dependencies lead to semantic problems

43. System Design Research Lab University of Pennylvania 2/8/2006 Dependencies in agents Algebraic and discrete: instantaneous Differential dependencies: not instantaneous Circular instantaneous dependencies lead to semantic problems X X

44. System Design Research Lab University of Pennylvania 2/8/2006 Dependency graph Graph of dependencies between variables Projected on the agents that control the variables

45. System Design Research Lab University of Pennylvania 2/8/2006 Acyclic dependency graphs Easy to check and enforce Fairly restrictive Same evaluation order throughout execution

46. System Design Research Lab University of Pennylvania 2/8/2006 Locally acyclic dependency graphs Dependency graph is acyclic in every reachable global mode

47. System Design Research Lab University of Pennylvania 2/8/2006 Locally acyclic dependency graphs More models accepted More expensive execution model –Different evaluation orders in different modes One step further: –Separate dependency graphs for continuous and discrete updates Two steps further: microstep semantics

48. System Design Research Lab University of Pennylvania 2/8/2006 Back to CHARON Original semantics: asynchronous –Tools implement asynchronous communication New version: –Synchronous communication –Mode-based dependencies –Type system distinguishes shared variables and signals Shared variables are discrete, do not introduce dependencies, and allow multiple writers

49. System Design Research Lab University of Pennylvania 2/8/2006 Charon toolset: visual editor

50. System Design Research Lab University of Pennylvania 2/8/2006 Charon toolset: visual editor

51. System Design Research Lab University of Pennylvania 2/8/2006 Charon toolset: control panel

52. System Design Research Lab University of Pennylvania 2/8/2006 Charon toolset: simulation

53. System Design Research Lab University of Pennylvania 2/8/2006 Charon toolset: simulation

54. System Design Research Lab University of Pennylvania 2/8/2006 DEMO

55. System Design Research Lab University of Pennylvania 2/8/2006 How to obtain and use Charon Download Charon from: http://www.cis.upenn.edu/mobies/charon/implementation.html –both the toolkit and the visual editor are available as compressed archives –see installation instructions on the web page Running: –Charon toolkit: run-charon.sh (Solaris/Linux) or run-charon.bat (Win) in the directory CharonCP –Visual editor: run.sh (Solaris/Linux) or run.bat (Win) in the directory CharonVisual