CHARON modeling language 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 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 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 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 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 2/8/2006

What’s more important? Switch-centric Flow-centric d(x)=k*x x>10 -5 10 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 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? 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 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 2/8/2006

CHARON Domain-independent Inspired by embedded/control applications switch-centric both requirements- and design-level models Strongly typed Has compositional semantics 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 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 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 Pump LTank private analog real leak level level Tank level Hole leak leak flow inflow inflow flow 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 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( ); } 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 2/8/2006

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 } 2/8/2006

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 } 2/8/2006

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 } 2/8/2006

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 } 2/8/2006

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 } 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 stop slow set=25 set=65 fast alge { speed == set } crash 2/8/2006

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 } 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 } } 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 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 Maintain clock >= 1 start on turnOff {clock = 0} Compute adjust off return inv { clock <= 1 } 2/8/2006

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 } 2/8/2006

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 } 2/8/2006

Mode semantics State of a mode: Type-correct valuation of all variables Variables of the mode and its submodes V*=Vg ] Vp*, Vp*=Vl ] Vl*SM Continuous steps Given by flows Discrete steps Entry, exit and internal steps 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 { v1 = f(v2) } • e1 { v1 = g(v2) } • x1 x2 e2 v2:=0 M11 M21 M1 M2 2/8/2006

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

Anatomy of an internal step Exit step of a submode M1: q1→q2 2 Rx2 Transition of the mode M: q2→q3 2 T Entry step of another submode M2: q3→q4 2 Re2 Internal step of the mode M: q1→q4 2 RD ) { v1 = f(v2) } • e1 { v1 = g(v2) } • x1 x2 e2 v2:=0 M11 M21 M1 M2 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 Pass time Agent 2 2/8/2006

Asynchrony: pros and cons Fits shared variable model well Very easy to implement Cons: Can be used to implement other communication mechanisms Model becomes cumbersome 2/8/2006

Example: event counter {y = y + 1} y {x = 1} 2/8/2006

Example: event counter Adding invariant does not help! x x == 1 {x = 0} {y = y + 1} y {x = 1} 2/8/2006

Example: event counter Model is more complex Code generation is problematic x {x == 0} x == 1 {x = 0} z == false {y = y + 1, z = false} {z = true} z == true y {x = 1} x == 0 z 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 Pass time Agent 2 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 2/8/2006

Dependencies in agents Algebraic and discrete: instantaneous Differential dependencies: not instantaneous Circular instantaneous dependencies lead to semantic problems X X 2/8/2006

Dependency graph Graph of dependencies between variables Projected on the agents that control the variables 2/8/2006

Acyclic dependency graphs Easy to check and enforce Fairly restrictive Same evaluation order throughout execution 2/8/2006

Locally acyclic dependency graphs Dependency graph is acyclic in every reachable global mode 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 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 2/8/2006

Charon toolset: visual editor 2/8/2006

Charon toolset: visual editor 2/8/2006

Charon toolset: control panel 2/8/2006

Charon toolset: simulation 2/8/2006

Charon toolset: simulation 2/8/2006