system design research lab university of pennylvania 2/8/2006 charon modeling language

2/8/2006

System Design Research LabUniversity of Pennylvania

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

A

C

B•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

d(x) = -5*x d(x) = 10*x

x<10

x>10

x>10

x<10

k -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

d(x) = -5*x d(x) = 10*x

x<10

x>10

x<10

x>10

k:=-5

k:=10

d(x) = k*x

k

x

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


controller plant

mcp

torque

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

mcp

torque

brakecontroller

enginecontroller

controller

brake

engine

plant

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

Tank Holeleakleak

private analog real leak

levellevel

inflowinflow

LTank

Pump level

flow

flow

2/8/2006


Agents: definition and instantiation// the tank agent with a hidden leakagent LTank() { private analog real leak; agent tank = Tank(); agent hole = Hole();}

// a leaky tank controlled by a pumpagent LeakyTank() { private analog real level, flow; agent tank = LTank( ) [ inflow := flow ] agent pump = Pump( 5, 10 )}

definition

instantiation

parameterizedinstantiation

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

diff { d(clock) == 1 }

start

return

Compute

Maintain

on turnOff

offadjust

inv { clock <= 1 }

clock >= 1

{clock = 0}

2/8/2006



• Modes have variable declarations, same as agents



start

return

Compute

Maintain

on turnOff

offadjust

inv { clock <= 1 }

clock >= 1

{clock = 0}

2/8/2006



• Modes can have constraints at any level



start

return

Compute

Maintain

on turnOff

offadjust

inv { clock <= 1 }

clock >= 1

{clock = 0}

2/8/2006



• Transitions are instantaneous• Transitions have guards and actions



start

return

Compute

Maintain

on turnOff

offadjust

inv { clock <= 1 }

clock >= 1

{clock = 0}

2/8/2006



• Transition can happen when its guard is true

• Transition must happen when invariant is falsePumpMode private analog real clock


start

return

Compute

Maintain

on turnOff

offadjust

inv { clock <= 1 }

clock >= 1

{clock = 0}

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

2/8/2006


Named vs. default control points

• Default control points allow:– preemption– history

start

return

Compute

Maintain

on turnOff

offadjust

inv { clock <= 1 }

clock >= 1

{clock = 0}

2/8/2006


PumpMode textmode 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

start

return

Compute

Maintain

on turnOff

offadjust

inv { clock <= 1 }

clock >= 1

{clock = 0}

2/8/2006



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

start

return

Compute

Maintain

on turnOff

offadjust

inv { clock <= 1 }

clock >= 1

{clock = 0}

2/8/2006



• 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

start

return

ComputeMaintain

on turnOff

offadjust

inv { clock <= 1 }

clock >= 1

{clock = 0, h=Compute}

SM

{h=Maintain}

{hM=off}{hM=on}

{hM=turnOff}

C1

C2

{hC=C1}

{hC=C2}

{hC=}

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

x2 e2

x1

e1{ v1 = g(v2) } •{ v1 = f(v2) }

•

v2:=0

M1

M11 M21

M2

2/8/2006


Discrete steps

• Internal steps: RD

– M1: <v1,v2,M11>→<v1,v2,M11> 2 RD

– M: <v1,v2,M1,M11>→<v1,0,M2,,M21> 2 RD

• Entry steps: Re for each entry exit e

– M2: <v1,v2,>→<v1,0,M21> 2 Re2

x2 e2

x1

e1{ v1 = g(v2) } •{ v1 = f(v2) }

•

v2:=0

M1

M11 M21

M2

2/8/2006


Anatomy of an internal step

• Exit step of a submodeM1: q1→q2 2 Rx2

• Transition of the modeM: q2→q3 2 T

• Entry step of another submodeM2: q3→q4 2 Re2

• Internal step of the modeM: q1→q4 2 RD

x2 e2

x1

e1{ v1 = g(v2) } •{ v1 = f(v2) }

•

v2:=0

M1

M11 M21

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

Agent 2

Pass time

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

2/8/2006


Example: event counter

{x = 0}

{x = 1}

x

y

x == 1

{y = y + 1}

2/8/2006



• Adding invariant does not help!

{x = 0}

{x = 1}

x

y

x == 1

{y = y + 1}

2/8/2006



• 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}

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

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

)(11 yfx

)(22 xfy )(12 yfx

)(21 xfy

)(

)(

1

1

yfz

yg

)(

)(

2

2

zfy

zg

x

y

z

XX

2/8/2006


Dependency graph

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

variables)(11 yfx

)(22 xfy )(12 yfx

)(21 xfy

)(

)(

1

1

yfz

yg

)(

)(

2

2

zfy

zg

x

y

z

x

y

z A1

A2

2/8/2006


Acyclic dependency graphs

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

execution

)(11 yfx

)(22 xfy )(12 yfx

)(21 xfy

)(

)(

1

1

yfz

yg

)(

)(

2

2

zfy

zg

x

y

z

2/8/2006


Locally acyclic dependency graphs

• Dependency graph is acyclic in every reachable global mode

)(11 yfx

)(22 xfy )(12 yfx

)(21 xfy

)(

)(

1

1

yfz

yg

)(

)(

2

2

zfy

zg

x

y

z

OK

)(11 yfx

)(22 xfy )(12 yfx

)(21 xfy

)(

)(

1

1

yfz

yg

)(

)(

2

2

zfy

zg

x

y

z

OK

)(11 yfx

)(22 xfy )(12 yfx

)(21 xfy

)(

)(

1

1

yfz

yg

)(

)(

2

2

zfy

zg

x

y

z

?!

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

)(11 yfx

)(22 xfy )(12 yfx

)(21 xfy

)(

)(

1

1

yfz

yg

)(

)(

2

2

zfy

zg

x

y

z

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: control panel

2/8/2006


Charon toolset: simulation

system design research lab university of pennylvania 2/8/2006 charon modeling language

Documents