DEVS  is a popular formalism to model system behaviour using a discrete-event abstraction. With this abstraction, only a finite number of pertinent events can occur during any bounded time interval. In reaction to events, the model’s state variable values change instantaneously. The state remains unaltered between event occurrences. The main advantages of DEVS are its rigourous and precise specification, as well as its support for modular, hierarchical model construction. DEVS frequently serves as a simulation “assembly language” to which models in other formalisms are translated, either giving meaning to new (domain-specific) languages, or reproducing semantics of existing languages . Models in different formalisms can hence be meaningfully combined by mapping them onto DEVS.
Despite the rigour of its syntax and semantics, the initialization of models is unspecified in both Classic  and Parallel DEVS [3, 4]. Initialization is important for several reasons. First, it allows for unaltered reuse of models, for example from a model library. A user should not have to know about, let alone modify, the various internal states and configurations of a reused model. Second, initialization is required when restarting a simulation run after it was interrupted, e.g., for fault tolerance reasons. The state has to be re-initialized to the last know state, from which simulation can subsequently resume as if it was never interrupted. Third, initialization is required for dynamic structure and hybrid systems, where the simulation is interrupted due to some system condition, the model is altered, re-initialized to a consistent state, and the simulation resumed.
As it is not part of the specification of the DEVS formalism, different implementations have widely varying ways of supporting initialization, impeding model reuse across simulator implementations. Additionally, realistic initial conditions can often not be expressed without adding artificial initialization behaviour to a model. In this paper, a traffic light example is used to illustrate the need for adding initialization to the DEVS formalism. The effects of the extension on both denotational (closure under coupling, or flattening) and operational semantics (the abstract simulator) are described and demonstrated using the running example. Note that this extension only specifies initialization, leaving all other aspects of DEVS untouched. Our extension is implemented in the PythonPDEVS  simulation tool, which is capable of simulating both Classic and Parallel DEVS. As the addition to both is similar, only Classic DEVS is described in detail in this paper.
The remainder of this section presents our motivating example at a conceptual level. Section 2 briefly recaps the Classic DEVS formalisms, without initialization, and models the example in it. Section 3 presents our extension to the formalism, the initial total state, and describes its influence on the specification and both of its semantics definitions. Changes are demonstrated on the running example. Section 4 presents related work, mainly referring to current methods of initialization and tool support. Section 5 concludes the paper.
1.1 Motivating Example
To illustrate the lack of initialization, and the ensuing problems, a minimal example is used throughout this paper. This running example consists of a simple traffic light which can run autonomously (i.e., alternate between red, yellow, and green) or be interrupted (i.e., be turned off). This traffic light interacts with a policeman, who alternates between “working” (while the traffic light is turned off) and “taking break” (while the traffic light is working autonomously). For the sake of readability of the behaviour traces, artificifial timings were chosen in the model shown in Figure 1. A full Classic DEVS specification is given in Section 2.
From the visual representation of the model, there is no indication in which state a simulation starts. For example, should the traffic light start autonomously or should it be turned off? And what about the policeman? This is the first problem: there is no initial state specified in the DEVS formalism.
Assuming that some initial sequential state is given, a simulation can be performed, leading to the behaviour traces shown in Figure 3444For the sake of readability, none of the figures are to scale.. There is however no flexibility in when the policeman can trigger an event. Without altering the delays in the policeman model, it is impossible for the policeman to interrupt the trafficlight at an arbitrary point in time: it must be at time or , as these are the time delays in the policaman model. In both cases, however, this coincides with the time at which the light changes from red to green: it is impossible to interrupt at any other time with this model. To allow for arbitrary times, the model needs to be modified, adding artificial states, thereby introducing accidental and unnecessary complexity. This is an indication that the formalism in its current form lacks expressiveness (or in this case, is under-specified). Furthermore, the model remains incompletely initialized for as long as even a single atomic model is still in its initialization state. Ideally, it should be possible to shift behaviour traces of component models independently with respect to one another, such that the same models can be reused unchanged, but that for example the policeman starts in between two state changes, as shown in Figure 3. The initial state of the policeman can thus be set such that the interrupt happens at any desired point in time. This is in essence the elapsed time of the atomic model: how long it has been since the last transition. This is therefore the second problem: the time that was already spent in the initial state at the start of a simulation cannot be set.
In this section, the Classic DEVS formalism is briefly presented to provide the necessary background for our extension to the formalism. The running traffic light example is subsequently specified in DEVS. Only Classic DEVS is presented here as our extension is applicable to both Classic and Parallel DEVS.
For a more detailed explanation of the Classic DEVS formalism, we refer the reader to the main DEVS reference work  (including Parallel DEVS) or our Classic DEVS tutorial . Further details of Parallel DEVS can be found in the literature as well [3, 4].
2.1 Classic DEVS
Classic DEVS comprises two types of models: Atomic DEVS models, defining behaviour, and Coupled DEVS models, defining structure.
An Atomic DEVS model is the basic building block. Its structure is shown in Specification 1.
|set of input events|
|set of output events|
|set of sequential states|
|internal transition function|
|external transition function|
|set of total states|
|output function, with the null (nothing happens) event|
Intuitively, the behavioural semantics are as follows. The system enters a sequential state and schedules an “internal” transition to state after . Before undergoing the transition, is invoked to generate an output event . If before the scheduled internal transition occurs, an external input event is received, the scheduled output generation and subsequent transition do not occur. Instead, an “external” transition is made to . Here, is the elapsed time, the time that has passed in the state since the last transition, until the event was received. No output is generated in this case. Upon arrival in the new state, either through or , the algorithm repeats.
A Coupled DEVS model is the structuring concept of DEVS, and allows various Atomic and Coupled DEVS models to be combined through parallel composition. Its structure is shown in Specification 2.
|set of input events|
|set of output events|
|set of model instance labels|
|set of submodel specifications|
|(atomic) submodel specification|
|influencee mapping (encoding connection topology)|
|set of influencees’ labels of model with label i|
Intuitively, the semantics are given as follows. The coupled DEVS model instantiates all of its submodels, which are all considered to be atomic DEVS models (as a coupled model can always be flattened to an atomic model), and keeps their references (or labels) in . The atomic DEVS submodels’ specifications are found in . Submodels can be connected and the connection topology is encoded in the influencee set , which lists for each subcomponent, all the other subcomponents that it influences (i.e., sends its output to). Upon forwarding an event to another subcomponent, the event is translated by , which can map input-to-input (for external input coupling), output-to-input (for internal coupling), and output-to-output (for external output coupling). When multiple internal events are scheduled at the same time, in different sub-models, the select function is invoked for tie-breaking.
2.1.1 Running Example
The Classic DEVS specification of the full traffic light model is given below. Note that, as per the DEVS semantics, the output function is invoked before the internal transition is taken. This explains why the produced events are non-intuitive (e.g., raise show_yellow for green). The traffic light atomic DEVS model is shown in Specification 3.
The policeman’s behaviour is simpler and is shown in Specification 4.
Finally, the atomic models are composed in a coupled DEVS model, shown in Specification 5.
From this complete DEVS specification example, it is clear that something is lacking: nowhere has been specified what is the initial state, and how long the system has already been in that state.
3 Initial Total State
After the above brief recap of the Classic DEVS formalism and the presentation of our running example in this specification, it has become clear that this model cannot be simulated as-is. Indeed, a simulator for this model has no way of knowing from which total state to start the simulation. To alleviate this problem, we propose to add an initial total state to the DEVS specification. While a minimal extension, this has repercussions on both syntax and semantics of the DEVS formalism.
3.1 Atomic DEVS Specification
In the Atomic DEVS specification, the total initial state is added. was previously described as being the set of total states , as used by the external transition function . This alters the atomic DEVS specification to the following.
The initial total state comprises the initial state and the initial elepased time .
The initial state specifies the system state in which the simulation commences. Its addition is logical, and has up to now been implemented in different simulation tools, as an implicit ad-hoc extension to the formalism. In the case of our running example, we may specify that the traffic light starts in the green state and the policeman in the break state.
The initial elapsed time specifies how long the system has been in this state, without a transition being observed. This is a less obvious addition to the initialization phase, and is ignored by several simulation tools. Nonetheless, we argue for its importance in providing flexibility to the DEVS modeller.
If only an is present in the specification, but not , it is possible to specify green and break as the initial state for the traffic light and policeman, respectively, but one is restricted to their time advances. Indeed, without , the initial elapsed time would be implicitly equal to , as was shown in Figure 3. This schedules the first internal transition of the policeman at time . The traffic light will have internal transitions at times 57 (to yellow), 60 (to red), and 120 (to green). Following this sequence, the policeman will always send its interrupt at the exact same point in time, namely when a switch is made from red to green. Therefore, it is impossible for the modeller to reproduce the real-world scenario where, for example, the policeman interrupts after the light has been in the yellow state for time units. To do this, the model itself would have to be drastically modified (e.g., adding an artificial “initialization” state to the policeman model). This severely impedes modular re-use of submodels.
What we wish to achieve is shown in Figure 4, which includes the “negative” simulation time (i.e., what hypothetically happened before simulation, given the specified model). While this figure includes the state trace from before the start of the simulation, we can only go back until the last transition, as we have no knowledge about how we ended up in that state (e.g., before time for police1). To remain consistent with the DEVS specification, it is required to alter the duration since the last event for each atomic model individually. By doing this, each individual atomic DEVS model can be shifted relatively to all others. For example, Figure 5 presents two different initial elapsed time configurations, with their effect on the simulation. Note that these additions can easily be taken over to Parallel DEVS as well, without any changes.
In our running example, we augment the models with the following initial total states. For the sake of the closure under coupling, we set the initial elapsed time of the traffic light to 10. Therefore, the light will enter yellow at time 47. To ensure that the policeman sends the external interrupt after the light has been in state yellow for , the transition has to happen at time . To achieve this, we compute its desired initial elapsed time as . Thus, the policeman will have already spent time units in break, and will transition after time units, at which point the light will have been in yellow for time units, as desired. Various configurations exist to achieve the same result, such as having the traffic light start at a different state or with a different elapsed time.
3.2 Closure Under Coupling
The atomic DEVS specification extension has its repercussions on closure under coupling, where several atomic DEVS models are flattened to a single atomic DEVS model. Indeed, the of each submodel, has to be conserved in the flattened atomic model. While several approaches exist, we have opted for a non-invasive approach, which only affects .
A definition for in terms of the ( being a submodel label) is presented which leaves the closure under coupling untouched. As , it consists of two parts: the initial state and the initial elapsed time .
First, we tackle the initial elapsed time . As closure under coupling combines all subcomponents, every independent state change of a subcomponent results in a state change of the flattened model. As a logical consequence, the initial elapsed time of the overall system is the time since the last transition of all its subcomponents, i.e., the minimum of all the subcomponents’ elapsed times.
Second, we tackle the initial state . As mentioned earlier, closure under coupling combines the states of the various subcomponents into a single state. To capture the individual elapsed times, required for the and functions, the flattened atomic DEVS model not only encodes the combination of all subcomponents’ states, but includes for each subcomponent, the current elapsed time: is defined as . Intuitively, one would define as the combination of the values of all the subcomponents, i.e., , but this is incorrect. Due to the definition of , the minimal elapsed time is already taken into account, as shown in Figure 6. Indeed, it has been time units since the last transition (to ), and therefore should not contain the elapsed times at initialization, but rather those upon reaching the initial state (i.e., time units ago). This can be done by subtracting from each in , the globally minimum value . Therefore, we define as follows.
An alternative would be to set to 0 and define as the combination of all values, but this is less intuitive for two reasons. First, the combination of is never actually “materialized” in simulators, as discrete event simulators jump from one transition time to the next, ignoring all intermediate times (this is the essence of discrete-event simulation). In many cases, no transition happens at simulation time zero, and therefore the state would never have materialized anyway. The option of altering this behaviour for the initialization seems non-intuitive. Second, to keep the definition of elapsed time consistent with that used by the simulator “in regime operation”, it must be the time since the last transition of the atomic DEVS model. Setting it to 0 it implies that the system made a transition upon initialization, which is incorrect, unless of course in some rare cases where this occurs in the system being modelled.
For our running example, using the same parameters as before, this results in the following initial total state of the flattened atomic DEVS model.
Note that these additions can easily be taken over to Parallel DEVS as well, without any changes.
3.3 Abstract Simulator
The abstract simulator is simpler to alter, as there is already a notion of initialization message, often termed . At the start of the simulation, the root coordinator first sends out the message . Each coordinator or simulator responds to this message with , where represents the earliest internal event it has scheduled. As in our extended DEVS specification, the atomic models already have the necessary initialization information stored locally, they can set the state and elapsed time upon receiving the message. Depending on these newly set values, the initial is computed, which is then sent to the parent simulator. No further changes are required.
4 Related Work
In the experimental frame approach, the initial total state can be considered as a type of input. The initial total state is thus defined in the experimental frame, and is merely passed along to the DEVS model during initialization. While this approach allows the environment to configure the model as desired, thereby offering flexibility, it is not formalized in the DEVS specification. Indeed, the DEVS semantics, whether it be denotationally using closure under coupling or operationally using the abstract simulator, don’t mention anything related to the initial total state. Most of the time, it is a logical decision to have the model itself define what is a consistent state for initialization.
Initialization is often left to tools, which implement this independent of the formalim. We consider several popular DEVS simulation tools, discussed in an earlier survey .
Adevs  considers all attributes of an atomic model to be part of the state. Therefore, the constructor is responsible for setting all attributes. The initial elapsed time cannot be set.
CD++  similarly considers all attributes to be part of the state, but provides a specific function called initFunction. This function is called upon initialization and sets the initial state and the remaining time in this state (). While this is functionally equivalent to the elapsed time, as , it diverges from the DEVS specification, as it is possible to be in an initial state which would have ordinarily been impossible to reach (e.g., for our running example). Indeed, it might be that , which will remain undetected. In contrast, if the elapsed time is given, the definition of ensures that , rendering such inconsistencies impossible.
DEVS-Suite  similarly has an initialize function which initializes the state and sets the first timeout to use, similar to CD++. As its approach is the same as that of CD++, it shares the same problems.
MS4Me  again uses the same approach, but requires the syntax to start hold in S_INIT for time REMAINING_INIT! to achieve the same result. Again, the same problems occur.
PowerDEVS  has the same approach, where the function is called init. Again, the function initializes the state and returns the remaining time until the first internal transition.
PythonPDEVS , our Classic and Parallel DEVS simulator, supports the definition of an initial total state as presented in this paper. Like all tools, it is required to specify the initial state (assign to self.state), but additionally, the elapsed time can be set (assign to self.elapsed). By specifying the elapsed time, instead of the remaining time, the timings are guaranteed to be consistent.
VLE  uses the constructor to initialize the state, as in adevs, and similarly does not present an option to specify the initial elapsed or remaining time.
X-S-Y  assigns the initial state to the self.phase attribute, but does not allow for either the elapsed or remaining time to be set.
While several tools have addressed the missing initialization in the DEVS specification, they do so in widely varying ways. Syntactical differences are found among all tools, as there is no agreed upon name or method of adding initialization information. More importantly, semantical differences exist as well: tools such as adevs, vle, and X-S-Y can not specify the initial time, and are therefore restricted in their (model reuse) flexibility. Other tools, such as CD++, DEVS-Suite, MS4Me, and PowerDEVS, allow the remaining time to be specified, though this potentially results in inconsistent situations, as there is no formal constraint on this value. Finally, PythonPDEVS implements the initial total state using the elapsed time, thereby performing consistency checking: the elapsed time is immediately compared to the time advance . In the light of DEVS standardization efforts [10, 1], it is problematic that various tools implement different methods of initialization. On this topic, a “DEVS compliance checklist” was previously introduced , and later slightly extended , to which we believe the initial total state should now be added.
DEVS has since long been acclaimed for its rigourous and precise specification for models with a discrete event abstraction. Despite its rigour being one of its main advantages, model initialization is left unspecified, leading to various implementations. This paper has presented an addition to the DEVS specification, the initial total state , which formalizes model initialization. The influence of this addition on the specification and closure under coupling was presented in detail, both at the level of the specification, and using a traffic light example. Classic DEVS was used to present our contribution, though the addition can be applied to Parallel DEVS as well.
-  Khaldoon Al-Zoubi and Gabriel Wainer. Interfacing and coordination for a DEVS simulation protocol standard. In Proceedings of the 2008 12th IEEE/ACM International Symposium on Distributed Simulation and Real-Time Applications, pages 300–307, 2008.
-  Federico Bergero and Ernesto Kofman. PowerDEVS: a tool for hybrid system modeling and real-time simulation. Simulation, 87:113–132, 2011.
-  Alex Chung Hen Chow and Bernard P. Zeigler. Parallel DEVS: a parallel, hierarchical, modular, modeling formalism. In Proceedings of the 1994 Winter Simulation Multiconference, pages 716–722, 1994.
-  Alex Chung Hen Chow, Bernard P. Zeigler, and Doo Hwan Kim. Abstract simulator for the parallel DEVS formalism. In AI, Simulation, and Planning in High Autonomy Systems, pages 157–163, 1994.
-  Moon Ho Hwang. X-S-Y. https://code.google.com/p/x-s-y/, 2012.
-  Sungung Kim, Hessam S. Sarjoughian, and Vignesh Elamvazhuthi. DEVS-Suite: a simulator supporting visual experimentation design and behavior monitoring. In Proceedings of the 2009 Spring Simulation Multiconference, pages 161:1–161:7, 2009.
-  Xiaobo Li, Hans Vangheluwe, Yonglin Lei, Hongyan Song, and Weiping Wang. A testing framework for DEVS formalism implementations. In Proceedings of the 2011 Spring Simulation Multiconference, pages 183–188, 2011.
-  James J. Nutaro. adevs. http://www.ornl.gov/~1qn/adevs/, 2015.
-  Gauthier Quesnel, Raphaël Duboz, Éric Ramat, and Mamadou K. Traoré. VLE: a multimodeling and simulation environment. In Proceedings of the 2007 Summer Simulation Multiconference, pages 367–374, 2007.
-  Hessam S. Sarjoughian and Yu Chen. Standardizing DEVS models: an endogenous standpoint. In Proceedings of the 2011 Spring Simulation Multiconference, pages 266–273, 2011.
-  Chungman Seo, Bernard P. Zeigler, Robert Coop, and Doohwan Kim. DEVS modeling and simulation methodology with MS4Me software. In Proceedings of the 2013 Spring Simulation Multiconference, pages 33:1–33:8, 2013.
-  Mamadou K. Traoré and Alexandre Muzy. Capturing the dual relationship between simulation models and their context. Simulation Modelling Practice and Theory, 14(2):126–142, 2006.
-  Yentl Van Tendeloo and Hans Vangheluwe. The modular architecture of the Python(P)DEVS simulation kernel. In Proceedings of the 2014 Spring Simulation Multiconference, pages 387–392, 2014.
-  Yentl Van Tendeloo and Hans Vangheluwe. An overview of PythonPDEVS. In Collectif Workshop RED, editor, JDF 2016 – Les Journées DEVS Francophones – Théorie et Applications, pages 59–66, 2016.
-  Yentl Van Tendeloo and Hans Vangheluwe. Classic DEVS modelling and simulation. In Proceedings of the 2017 Winter Simulation Conference, WSC 2017, pages 644 – 656. IEEE, December 2017.
-  Yentl Van Tendeloo and Hans Vangheluwe. An evaluation of DEVS simulation tools. SIMULATION, 93(2):103–121, 2017.
-  Hans Vangheluwe. DEVS as a common denominator for multi-formalism hybrid systems modelling. In IEEE International Symposium on Computer-Aided Control System Design, pages 129–134, 2000.
-  Gabriel Wainer. CD++: a toolkit to develop DEVS models. Software: Practice and Experience, 32(13):1261–1306, 2002.
-  Bernard P. Zeigler, Herbert Praehofer, and Tag Gon Kim. Theory of Modeling and Simulation. Academic Press, 2nd edition, 2000.
This work was partly funded by a PhD fellowship from the Research Foundation - Flanders (FWO). This research was also partially supported by Flanders Make vzw, the Flemish strategic research centre for the manufacturing industry. The authors wish to thank Joey De Pauw for pointing out an inconsistency between and the specification of in our lecture notes.