1. CHARON modeling language
2/8/2006

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

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

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

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

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

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

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

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

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

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

12. CHARON Domain-independent Inspired by embedded/control applications
switch-centric
both requirements- and design-level models
Strongly typed
Has compositional semantics
2/8/2006

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

45. Locally acyclic dependency graphs
Dependency graph is acyclic in every reachable global mode
2/8/2006

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

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

48. Charon toolset: visual editor
2/8/2006

49. Charon toolset: visual editor
2/8/2006

50. Charon toolset: control panel
2/8/2006

51. Charon toolset: simulation
2/8/2006

52. Charon toolset: simulation
2/8/2006