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
Whats more important?

• Switch-centric
• Flow-centric d(x)kx

xgt10 xlt10
k -5 10
8
Modeling styles

• High-level models
• System requirements
• Primarily captures behavior

• Low-level models
• System design
• Behavior structure
• Software vs. nature
• Code generation

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

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

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 lt level and level lt 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 gt 1
start
on
turnOff
clock 0
Compute
off
adjust
return
inv clock lt 1
diff d(clock) 1
20
Modes behavior discrete control

• Modes have variable declarations, same as agents

PumpMode
private analog real clock
Maintain
clock gt 1
start
on
turnOff
clock 0
Compute
off
adjust
return
inv clock lt 1
diff d(clock) 1
21
Modes behavior discrete control

• Modes can have constraints at any level

PumpMode
private analog real clock
Maintain
clock gt 1
start
on
turnOff
clock 0
Compute
off
adjust
return
inv clock lt 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 gt 1
start
on
turnOff
clock 0
Compute
off
adjust
return
inv clock lt 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 gt 1
start
on
turnOff
clock 0
Compute
off
adjust
return
inv clock lt 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
set25
set65
fast
alge speed set
crash
25
Named vs. default control points

• Default control points allow
• preemption
• history

Maintain
clock gt 1
start
on
turnOff
clock 0
Compute
off
adjust
return
inv clock lt 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 gt 1 do
  clock 0
• trans from c.return to m when true do
  
• diff d(clock) 1

27
Computational modes

• Useful for modeling software components
• Do not have continuous behavior
• Instantaneous execution
• Internal structure defines control flow

Compute
delta lt 0
return
rate -delta
start
delta level-past
delta gt 0
past level
rate 0
28
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
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 gt 1
start
on
turnOff
clock 0
Compute
off
adjust
return
inv clock lt 1
30
Active modes and history

• If a mode is preempted, its active submode should
  be restored upon return

Maintain
clock gt 1
start
on
turnOff
clock 0
Compute
off
adjust
return
inv clock lt 1
31
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 gt 1
hMturnOff
start
on
turnOff
clock 0, hCompute
C1
hCC1
hCC2
hMoff
hMon
C2
hCe
off
adjust
return
hMaintain
inv clock lt 1
32
Mode semantics

• State of a mode
• Type-correct valuation of all variables
• Variables of the mode and its submodesVVg
  Vp, VpVl VlSM
• Continuous steps
• Given by flows
• Discrete steps
• Entry, exit and internal steps

33
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
v20
x2
e2
M11
M21
M1
M2
34
Discrete steps

• Internal steps RD
• M1 ltv1,v2,M11gt?ltv1,v2,M11gt 2 RD
• M ltv1,v2,M1,M11,egt?ltv1,0,M2,e,M21gt 2 RD
• Entry steps Re for each entry exit e
• M2 ltv1,v2,egt?ltv1,0,M21gt 2 Re2

e1
x1
v20
x2
e2
M11
M21
M1
M2
35
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

)
e1
x1
v20
x2
e2
M11
M21
M1
M2
36
Asynchrony its 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
37
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
Example event counter
x
x 1
x 0
y y 1
y
x 1
39
Example event counter

• Adding invariant does not help!

x
x 1
x 0
y y 1
y
x 1
40
Example event counter

• Model is more complex
• Code generation is problematic

x
x 1
x 0
x 0
y y 1, z false
z false
z true
y
z true
x 1
x 0
z
41
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
42
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
Dependencies in agents

• Algebraic and discrete instantaneous
• Differential dependencies not instantaneous
• Circular instantaneous dependencies lead to
  semantic problems

44
Dependency graph

• Graph of dependencies between variables
• Projected on the agents that control the variables

45
Acyclic dependency graphs

• Easy to check and enforce
• Fairly restrictive
• Same evaluation order throughout execution

46
Locally acyclic dependency graphs

• Dependency graph is acyclic in every reachable
  global mode

47
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
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
Charon toolset visual editor
50
Charon toolset visual editor
51
Charon toolset control panel
52
Charon toolset simulation
53
Charon toolset simulation
54
DEMO
55
How to obtain and use Charon

• Download Charon from
• http//www.cis.upenn.edu/mobies/charon/implementat
  ion.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