The MSDL's ongoing contributions to research and standardization on Bernard Zeigler's DEVS formalism are:

• A rigourous definition (in terms of Labelled Transition Systems) of DEVS operational semantics.
• The automatic transformation (theory as well as implementation) of Statecharts into behaviourally equivalent DEVS. See Spencer Borland's M.Sc. thesis.
• The comparison of subtle differences in expressivenes between variants of DEVS (e.g., how to emulate Classic DEVS behaviour in Parallel DEVS) as well as between various implementations (e.g., how not producing output before an internal transition can be modelled in Classic DEVS and how this could be incorporated into an efficient simulation kernel. Also, how efficient implementations should not route *, x, and y messages through different levels of a DEVS hierarchy).
• The implementation of PythonDEVS, a prototype DEVS modelling language with simulator.
• The introduction of new DEVS variants:
  • Nested-time DEVS: allow arbitrary levels of nesting of DEVS experiments. This work has led to the need to model DEVS simulators in DEVS which in turn allows for "mobile DEVS". This approach also allows the explicit modelling of simulation experiments (Experimental Frame): setting initial conditions, parameters, etc.
  • Multi-time DEVS: allow the coupling of models with different (but compatible) time bases. This allows for example the re-use and combination of models using hours vs. days as their time base.
  • Modal DEVS: explicitly separate "mode" states and "variable" states. This allows for easy visual modelling. Modal DEVS borrows some ideas from Statecharts.
  • Agent DEVS: an infrastructure which preserves DEVS modularity, but does allow some amount of global communication based on "neighbourhood querying".
• The development of a target-language-neutral textual modelling language for the representation of DEVS models. Currently, all known DEVS modelling and simulation implementations graft DEVS semantics onto the syntax and semantics (expressions, functions, classes, instantiation, operator overloading, ...) of exisiting object-oriented languages. For example, ADEVS and CD++ are grafted onto C++, DEVSJava is grafted onto Java, and PythonDEVS is grafted onto Python. This gives programming-language power to the DEVS modeller, but also makes it very easy to construct syntactically and semantically invalid DEVS models. In addition, symbolic analysis of DEVS models is seriously hampered. Also, not using a target-langauge-neutral modelling language makes it impossible to build libraries of re-usable components. The success of languages such as Java and Modelica can be partly attributed to the existence of well-developed libraries. Currently, we are investigating (1) Modelica syntax and static semantics and (2) DEVSlang [ pdf], a syntax dedicated to DEVS.
• The development, using meta-modelling (and the MSDL's meta-modelling environment AToM³), of a complete visual modelling environment for DEVS modelling.
• The development of state and event segment plotting tool (for teaching and debugging).

To allow for meaningful re-use and exchange of DEVS models as well as to support inter-operability of DEVS simulators (for example, for distributed simulation), it is necessary to standardize DEVS model syntax, semantics as well as simulator interfaces and implementation. It is also necessary to develop multi-platform modelling and simulation tools, and model libraries.

See the DEVS standardization group page for an international effort to standardize various aspects of DEVS.

HV's presentation at the 2001 Winter Simulation Conference DEVS Standards Group meeting introduces the MSDL views and intiatives.

PythonDEVS was developed as a lightweight tool for teaching DEVS and as a basis for research into the finer details of DEVS semantics as well as into DEVS variants.

The following are all you need to get started with PythonDEVS:

• A report [pdf] on the construction of the PythonDEVS simulator. The example in this report has been expanded and can be found in queueModel.py described below. Unless you are interested in the design of the simulator, you should go directly to the examples described below.

• The pydevs.tgz archive. It contains:

  • infinity.py: a singleton class to define the INFINITY object.
  • devs_exceptions.py: DEVS-specific exception.
  • DEVS.py: classes for modelling Atomic and Coupled DEVS.
  • simulator.py: classes for simulating DEVS models.
  • The examples/ directory contains Models and Experiment files for (1) a simple traffic light, (2) a more complex queueing system, and (3) a template which can be used as a starting point for all development.

Spencer Borland has developed a real-time version of PythonDEVS called RT-PythonDEVS. RT-PythonDEVS allows for the real-time execution of DEVS models. As such, it serves as a virtual machine for the execution of DEVS specifications. RT-PythonDEVS was developed in the context of Spencer's M.Sc. thesis in which Statechart specifications are transformed into equivalent DEVS specifications.

Bill Song used meta-modelling in AToM³ to develop DEVSenv, a visual modelling and simulation model generation environment for DEVS. Have a look at Bill's project page. Currently, PythonDEVS is generated, but soon ADEVS will be supported. Full target-language-independence will come when a neutral modelling language is completed.

Note how the visual representation of Atomic DEVS models assumes a separation between "mode" states (visualised as circles) and "variable" states (encoded as attributes). This, as well as how to visually represent external transitions, is based on Ernesto Posse's DEVS in AToM³.

Ernesto's prototype supports truly hierarchical modelling with hiding of sub-models, visual modelling of atomic DEVS' behaviour and PythonDEVS code generation. This work was presented at the 2003 SCSC [pdf].