System Design Research Lab University of Pennylvania 2/8/2006 CHARON modeling language

System Design Research Lab University of Pennylvania 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

System Design Research Lab University of Pennylvania 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

System Design Research Lab University of Pennylvania 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

System Design Research Lab University of Pennylvania 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

System Design Research Lab University of Pennylvania 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

System Design Research Lab University of Pennylvania 2/8/2006 What’s more important? Switch-centric Flow-centric d(x)=k*x x>10x<10 k-510

System Design Research Lab University of Pennylvania 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

System Design Research Lab University of Pennylvania 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?

System Design Research Lab University of Pennylvania 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

System Design Research Lab University of Pennylvania 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

System Design Research Lab University of Pennylvania 2/8/2006 CHARON Domain-independent Inspired by embedded/control applications –switch-centric –both requirements- and design-level models Strongly typed Has compositional semantics

System Design Research Lab University of Pennylvania 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

System Design Research Lab University of Pennylvania 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

System Design Research Lab University of Pennylvania 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 Hole leak private analog real leak level inflow LTank Pump level flow

System Design Research Lab University of Pennylvania 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

System Design Research Lab University of Pennylvania 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( ); }

System Design Research Lab University of Pennylvania 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

System Design Research Lab University of Pennylvania 2/8/2006 Modes: behavior + discrete control Composite modes have multiple submodes and discrete transitions between them PumpModeprivate analog real clock diff { d(clock) == 1 } start return Compute Maintain onturnOff offadjust inv { clock <= 1 } clock >= 1 {clock = 0}

System Design Research Lab University of Pennylvania 2/8/2006 Modes: behavior + discrete control Modes have variable declarations, same as agents PumpModeprivate analog real clock diff { d(clock) == 1 } start return Compute Maintain onturnOff offadjust inv { clock <= 1 } clock >= 1 {clock = 0}

System Design Research Lab University of Pennylvania 2/8/2006 Modes: behavior + discrete control Modes can have constraints at any level PumpModeprivate analog real clock diff { d(clock) == 1 } start return Compute Maintain onturnOff offadjust inv { clock <= 1 } clock >= 1 {clock = 0}

System Design Research Lab University of Pennylvania 2/8/2006 Modes: behavior + discrete control Transitions are instantaneous Transitions have guards and actions PumpModeprivate analog real clock diff { d(clock) == 1 } start return Compute Maintain onturnOff offadjust inv { clock <= 1 } clock >= 1 {clock = 0}

System Design Research Lab University of Pennylvania 2/8/2006 Modes: behavior + discrete control Transition can happen when its guard is true Transition must happen when invariant is false PumpModeprivate analog real clock diff { d(clock) == 1 } start return Compute Maintain onturnOff offadjust inv { clock <= 1 } clock >= 1 {clock = 0}

System Design Research Lab University of Pennylvania 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

System Design Research Lab University of Pennylvania 2/8/2006 Named vs. default control points Default control points allow: –preemption –history start return Compute Maintain onturnOff offadjust inv { clock <= 1 } clock >= 1 {clock = 0}

System Design Research Lab University of Pennylvania 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 } }

System Design Research Lab University of Pennylvania 2/8/2006 Computational modes Useful for modeling software components –Do not have continuous behavior –Instantaneous execution –Internal structure defines control flow delta = level-past return rate = 0 start delta > 0 rate = -delta delta <= 0 Compute past = level

System Design Research Lab University of Pennylvania 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

System Design Research Lab University of Pennylvania 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 onturnOff offadjust inv { clock <= 1 } clock >= 1 {clock = 0}

System Design Research Lab University of Pennylvania 2/8/2006 Active modes and history If a mode is preempted, its active submode should be restored upon return start return Compute Maintain onturnOff offadjust inv { clock <= 1 } clock >= 1 {clock = 0}

System Design Research Lab University of Pennylvania 2/8/2006 Active modes and history A new private variable in each mode M: h M Values for history variable: Transition actions manipulate history variables Default exits keep h, non-default reset to  start return Compute Maintain onturnOff offadjust inv { clock <= 1 } clock >= 1 {clock = 0, h=Compute} {h=Maintain} {h M =off}{h M =on} {h M =turnOff} C1C1 C2C2 {h C =C 1 } {h C =C 2 } {h C =  }

System Design Research Lab University of Pennylvania 2/8/2006 Mode semantics State of a mode: –Type-correct valuation of all variables –Variables of the mode and its submodes V * =V g ] V p*, V p* =V l ] V l* SM Continuous steps –Given by flows Discrete steps –Entry, exit and internal steps

System Design Research Lab University of Pennylvania 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 x2x2 e2e2 x1x1 e1e1 { v 1 = g(v 2 ) } { v 1 = f(v 2 ) } v 2 :=0 M1M1 M 11 M 21 M2M2

System Design Research Lab University of Pennylvania 2/8/2006 Discrete steps Internal steps: R D –M 1 : → 2 R D –M: → 2 R D Entry steps: Re for each entry exit e –M 2 : → 2 R e2 x2x2 e2e2 x1x1 e1e1 { v 1 = g(v 2 ) } { v 1 = f(v 2 ) } v 2 :=0 M1M1 M 11 M 21 M2M2

System Design Research Lab University of Pennylvania 2/8/2006 Anatomy of an internal step Exit step of a submode M 1 : q 1 → q 2 2 R x2 Transition of the mode M: q 2 → q 3 2 T Entry step of another submode M 2 : q3 → q4 2 R e2 Internal step of the mode M: q 1 → q 4 2 R D x2x2 e2e2 x1x1 e1e1 { v 1 = g(v 2 ) } { v 1 = f(v 2 ) } v 2 :=0 M1M1 M 11 M 21 M2M2 )

System Design Research Lab University of Pennylvania 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

System Design Research Lab University of Pennylvania 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

System Design Research Lab University of Pennylvania 2/8/2006 Example: event counter {x = 0} {x = 1} x y x == 1 {y = y + 1}

System Design Research Lab University of Pennylvania 2/8/2006 Example: event counter Adding invariant does not help! {x = 0} {x = 1} x y x == 1 {y = y + 1}

System Design Research Lab University of Pennylvania 2/8/2006 Example: event counter 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}

System Design Research Lab University of Pennylvania 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

System Design Research Lab University of Pennylvania 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

System Design Research Lab University of Pennylvania 2/8/2006 Dependencies in agents Algebraic and discrete: instantaneous Differential dependencies: not instantaneous Circular instantaneous dependencies lead to semantic problems X X

System Design Research Lab University of Pennylvania 2/8/2006 Dependency graph Graph of dependencies between variables Projected on the agents that control the variables

System Design Research Lab University of Pennylvania 2/8/2006 Acyclic dependency graphs Easy to check and enforce Fairly restrictive Same evaluation order throughout execution

System Design Research Lab University of Pennylvania 2/8/2006 Locally acyclic dependency graphs Dependency graph is acyclic in every reachable global mode

System Design Research Lab University of Pennylvania 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

System Design Research Lab University of Pennylvania 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

System Design Research Lab University of Pennylvania 2/8/2006 Charon toolset: visual editor

System Design Research Lab University of Pennylvania 2/8/2006 Charon toolset: visual editor

System Design Research Lab University of Pennylvania 2/8/2006 Charon toolset: control panel

System Design Research Lab University of Pennylvania 2/8/2006 Charon toolset: simulation

System Design Research Lab University of Pennylvania 2/8/2006 Charon toolset: simulation

System Design Research Lab University of Pennylvania 2/8/2006 DEMO

System Design Research Lab University of Pennylvania 2/8/2006 How to obtain and use Charon Download Charon from: –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