CHARON modeling language

1. CHARON modeling language

2. 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. Languages for hybrid systems • Design decisions • domain-specific vs. domain-independent • modeling style • typed vs. untyped • choice of type system • compositionality vs. structuring

4. 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. 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. 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. What’s more important? • Switch-centric • Flow-centric d(x)=k*x

8. High-level models System requirements Primarily captures behavior Low-level models System design Behavior + structure Software vs. nature Code generation Modeling styles

9. 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. 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. 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. CHARON • Domain-independent • Inspired by embedded/control applications • switch-centric • both requirements- and design-level models • Strongly typed • Has compositional semantics

13. 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. 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. 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 Pump LTank private analog real leak level level Tank level Hole leak leak flow inflow inflow flow

16. definition instantiation parameterized instantiation 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 ) }

17. 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. 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. Modes: behavior + discrete control • Composite modes have multiple submodes and discrete transitions between them PumpMode private analog real clock Maintain clock >= 1 start on turnOff {clock = 0} Compute adjust off return inv { clock <= 1 } diff { d(clock) == 1 }

20. Modes: behavior + discrete control • Modes have variable declarations, same as agents PumpMode private analog real clock Maintain clock >= 1 start on turnOff {clock = 0} Compute adjust off return inv { clock <= 1 } diff { d(clock) == 1 }

21. Modes: behavior + discrete control • Modes can have constraints at any level PumpMode private analog real clock Maintain clock >= 1 start on turnOff {clock = 0} Compute adjust off return inv { clock <= 1 } diff { d(clock) == 1 }

22. Modes: behavior + discrete control • Transitions are instantaneous • Transitions have guards and actions PumpMode private analog real clock Maintain clock >= 1 start on turnOff {clock = 0} Compute adjust off return inv { clock <= 1 } diff { d(clock) == 1 }

23. Modes: behavior + discrete control • Transition can happen when its guard is true • Transition must happen when invariant is false PumpMode private analog real clock Maintain clock >= 1 start on turnOff {clock = 0} Compute adjust off return inv { clock <= 1 } diff { d(clock) == 1 }

24. 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 stop slow set=25 set=65 fast alge { speed == set } crash

25. Named vs. default control points • Default control points allow: • preemption • history Maintain clock >= 1 start on turnOff {clock = 0} Compute adjust off return inv { clock <= 1 }

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

28. 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 Maintain clock >= 1 start on turnOff {clock = 0} Compute adjust off return inv { clock <= 1 }

29. Active modes and history • If a mode is preempted, its active submode should be restored upon return Maintain clock >= 1 start on turnOff {clock = 0} Compute adjust off return inv { clock <= 1 }

30. Active modes and history • A new private variable in each mode M: hM • Values for history variable: • Transition actions manipulate history variables • Default exits keep h, non-default reset to e Maintain Compute clock >= 1 {hM=turnOff} start on turnOff {clock = 0, h=Compute} C1 {hC=C1} {hC=C2} {hM=on} {hM=off} {hC=e} C2 adjust off return {h=Maintain} inv { clock <= 1 }

31. Mode semantics • State of a mode: • Type-correct valuation of all variables • Variables of the mode and its submodesV*=Vg]Vp*, Vp*=Vl]Vl*SM • Continuous steps • Given by flows • Discrete steps • Entry, exit and internal steps

32. • • { v1 = g(v2) } { v1 = f(v2) } 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 e1 x1 v2:=0 x2 e2 M11 M21 M1 M2

33. • • { v1 = g(v2) } { v1 = f(v2) } Discrete steps • Internal steps: RD • M1: <v1,v2,M11>→<v1,v2,M11> 2 RD • M: <v1,v2,M1,M11,e>→<v1,0,M2,e,M21> 2 RD • Entry steps: Re for each entry exit e • M2: <v1,v2,e>→<v1,0,M21> 2 Re2 e1 x1 v2:=0 x2 e2 M11 M21 M1 M2

34. Exit step of a submode M1: q1→q22 Rx2 Transition of the mode M: q2→q32 T Entry step of another submode M2: q3→q4 2 Re2 Internal step of the mode M: q1→q42 RD • • { v1 = g(v2) } { v1 = f(v2) } Anatomy of an internal step ) e1 x1 v2:=0 x2 e2 M11 M21 M1 M2

35. 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 Pass time Agent 2

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

37. Example: event counter x x == 1 {x = 0} {y = y + 1} y {x = 1}

38. Example: event counter • Adding invariant does not help! x x == 1 {x = 0} {y = y + 1} y {x = 1}

39. Example: event counter • Model is more complex • Code generation is problematic x x == 1 {x == 0} {x = 0} z == false {y = y + 1, z = false} {z = true} z == true y {x = 1} x == 0 z

40. 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 Pass time Agent 2

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

42. X X Dependencies in agents • Algebraic and discrete: instantaneous • Differential dependencies: not instantaneous • Circular instantaneous dependencies lead to semantic problems

43. Dependency graph • Graph of dependencies between variables • Projected on the agents that control the variables

44. Acyclic dependency graphs • Easy to check and enforce • Fairly restrictive • Same evaluation order throughout execution

45. Locally acyclic dependency graphs • Dependency graph is acyclic in every reachable global mode

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

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

48. Charon toolset: visual editor

49. Charon toolset: visual editor

50. Charon toolset: control panel