DEVS standardization: some thoughts Hans Vangheluwe Juan de Lara, - PowerPoint PPT Presentation

DEVS Standards Group meeting Winter Simulation Conference 2001 Washington, DC December 11, 2001 DEVS standardization: some thoughts Hans Vangheluwe Juan de Lara, Jean-S´ ebastien Bolduc, Ernesto Posse Modelling, Simulation and Design Lab (MSDL) School of Computer Science McGill University Montr´ eal, Canada hv@cs.mcgill.ca http://moncs.cs.mcgill.ca Winter 2001, December 11, Washington DC Hans Vangheluwe DEVS standardization: some thoughts 1/27

� � Presentation Overview 1. Previous experiences with Modelling/Simulation/Standardization 2. Standardizing . . . what ? (a) The DEVS formalisms (b) The DEVS model representation (c) The DEVS model-solver interface (d) The DEVS model libraries 3. Meta-modelling Architecture: modelling formalism syntax and semantics Examples of Meta-modelling in AToM 3 4. Meta-modelling syntax and semantics of xyz-DEVS Winter 2001, December 11, Washington DC Hans Vangheluwe DEVS standardization: some thoughts 2/27

� � � � � � Previous experiences with Modelling/Simulation/Standardization Formalism – Modelling Language – Simulation Model – Libraries DAE++ – Modelica – DSblock – Modelica Standard Library PDE + DAE – MSL-USER – MSL-EXEC – WEST++ model library PDE + ODE + ALG – OOCSMP – Java – OOCSMP library Python-(classic)DEVS (with ports) Meta-modelling syntax and semantics of Causal Block Diagrams Winter 2001, December 11, Washington DC Hans Vangheluwe DEVS standardization: some thoughts 3/27

Standardizing . . . what ? 1. The DEVS formalisms 2. The DEVS model representation 3. The DEVS model-solver interface 4. The DEVS model libraries Winter 2001, December 11, Washington DC Hans Vangheluwe DEVS standardization: some thoughts 4/27

� � Standardizing the DEVS formalisms Relationships between different variants of DEVS 1. Inheritance (specialization) – caveat: inheritance is also a transformation 2. Transformation ( e.g., onto Classic DEVS) Reasons for transformation: conceptual: insight, proof of “equivalence” (morphism) avoid building a new simulator. Automatically transform to formalism for which a (efficient) simulator exists. Winter 2001, December 11, Washington DC Hans Vangheluwe DEVS standardization: some thoughts 5/27

Standardizing the DEVS model representation For exchange and re-use 1. Between programs, agents, machines, . . . Needs to be platform neutral, efficiently machine readable and writable. Suggestion: XML. 2. Between humans Needs to be readable, expressive, compact. Suggestions: graphical (composition), textual (expressions, loops, scoping, inheritance). 3. Storage of large amounts of data models (trajectory formalism) Needs to be compact. Suggestions: binary (XDR, dbase). Least important issue. Winter 2001, December 11, Washington DC Hans Vangheluwe DEVS standardization: some thoughts 6/27

� � OO Modelling in Modelica everything is a class inheritance hierarchy: from generic to specific Winter 2001, December 11, Washington DC Hans Vangheluwe DEVS standardization: some thoughts 7/27

Electrical example: Modelica vs. Matlab/Simulink Winter 2001, December 11, Washington DC Hans Vangheluwe DEVS standardization: some thoughts 8/27

Electrical Types type Time = Real (final quantity="Time", final unit="s"); type ElectricPotential = Real (final quantity="ElectricPotential", final unit="V"); type Voltage = ElectricPotential; type ElectricCurrent = Real (final quantity="ElectricCurrent", final unit="A"); type Current = ElectricCurrent; Winter 2001, December 11, Washington DC Hans Vangheluwe DEVS standardization: some thoughts 9/27

Electrical Pin Interface connector PositivePin "Positive pin of an electric component" Voltage v "Potential at the pin"; flow Current i "Current flowing into the pin"; end PositivePin; Winter 2001, December 11, Washington DC Hans Vangheluwe DEVS standardization: some thoughts 10/27

Electrical Port partial model OnePort "Component with two electrical pins p and n and current i from p to n" Voltage v "Voltage drop between the two pins (= p.v - n.v)"; Current i "Current flowing from pin p to pin n"; PositivePin p; NegativePin n; equation v = p.v - n.v; 0 = p.i + n.i; i = p.i; end OnePort; Winter 2001, December 11, Washington DC Hans Vangheluwe DEVS standardization: some thoughts 11/27

Electrical Resistor model Resistor "Ideal linear electrical resistor" extends OnePort; parameter Resistance R=1 "Resistance"; equation R*i = v; end Resistor; Winter 2001, December 11, Washington DC Hans Vangheluwe DEVS standardization: some thoughts 12/27

The circuit model circuit Resistor R1(R=10); Capacitor C(C=0.01); Resistor R2(R=100); Inductor L(L=0.1); VsourceAC AC; Ground G; equation connect(AC.p, R1.p); connect(R1.n, C.p); connect(C.n, AC.n); connect(R1.p, R2.p); connect(R2.n, L.p); connect(L.n, C.n); connect(AC.n, G.p); end circuit; Winter 2001, December 11, Washington DC Hans Vangheluwe DEVS standardization: some thoughts 13/27

✂ ✁ � ✂ � ✄ Standardizing the DEVS model representation ability to reason about, manipulate model model is not code 2 ) language (C++, Java, . . . ) independent ( x y z Winter 2001, December 11, Washington DC Hans Vangheluwe DEVS standardization: some thoughts 14/27

Standardizing the DEVS model-solver interface SIMULATOR = solver + model MODEL dynamics experimentation environment (e.g., parameter SOLVER(s) input, visulisation) MODEL symbolic or information simulator "bus" (e.g., HLA) or Winter 2001, December 11, Washington DC Hans Vangheluwe DEVS standardization: some thoughts 15/27

� � � Standardizing the DEVS model-solver interface Only the interface (API) is defined This allows for multiple language bindings Does the simulator correctly implement the formalism’s semantics ? How to verify ? – formal proof (starting from an implementation): hard ! – compare with automatically generated (from formal specification) reference implementation. Winter 2001, December 11, Washington DC Hans Vangheluwe DEVS standardization: some thoughts 16/27

� � � Standardizing the DEVS model libraries success of language/standard depends on availability of standard libraries (in different application domains). success increases if re-use mechanisms are good (inheritance) Modelica, Extend, C++ vs. Java, . . . Winter 2001, December 11, Washington DC Hans Vangheluwe DEVS standardization: some thoughts 17/27

� � � � What is Meta-modelling ? A meta-model is a model of a modelling formalism A meta-model is itself a model. Its syntax and semantics are governed by the formalism it is described in. That formalism can be modelled in a meta-meta-model. As a meta-model is a model, we can reason about it, manipulate it, . . . In particular, properties of (all models in) a formalism can be formally proven. Formalism-specific modelling and simulation tools can automatically be generated from a meta-model (AToM 3 ). Winter 2001, December 11, Washington DC Hans Vangheluwe DEVS standardization: some thoughts 18/27

� � Formalisms can be tailored to specific needs by modifying the meta-model (possibly through inheritance if specializing). Semantics of new formalisms through extension or transformation (multi-formalism). Winter 2001, December 11, Washington DC Hans Vangheluwe DEVS standardization: some thoughts 19/27

Meta-modelling architecture: syntax MMF (ER) meta-meta a model of a class of models (the formalism MF) model semantics within formalism MMF describes: structure and constraints MF (ER) user meta-model meta-model a model in formalism MF input processor -create a model of a class of models (the formalism F) -delete semantics within formalism MF -verify (local, global) describes: structure and constraints F (FSA) user meta-model a model in formalism F model input processor -create -delete -verify (local, global) Winter 2001, December 11, Washington DC Hans Vangheluwe DEVS standardization: some thoughts 20/27

Meta-modelling architecture: transformation MF (ER) MF (GGR) MF (ER) meta-model a model in formalism ER transformation meta-model a model in formalism MF meta-model a model of a class of models a model of a class of models (the formalism F) (the formalism NFA) semantics within formalism MF semantics within formalism ER describes: structure and constraints meta-model meta-model processor processor user user input input -create -create -delete -delete -verify (local, global) -verify (local, global) F (NFA) F (FSA) (multi-formalism) model model model transformer a model in formalism NFA = a model in formalism FSA meta-model processor Winter 2001, December 11, Washington DC Hans Vangheluwe DEVS standardization: some thoughts 21/27

Examples of Meta-modelling in AToM 3 1. Petri Net Meta-model (syntax) 2. Petri Net Graph Grammar (operational semantics) 3. Petri Net Modelling and Simulation tool (reference implementation) 4. GPSS modelling environment (syntax only, semantics through code generation for existing, efficient GPSS simulator) 5. Other examples: NFA to DFA, Causal Block Diagrams, Data Flow Diagrams to Structure Diagrams, . . . Winter 2001, December 11, Washington DC Hans Vangheluwe DEVS standardization: some thoughts 22/27