Abstract
Based on multiDEVS formalism, we introduce multiPDEVS, a parallel and nonmodular formalism for discrete event system specification. This formalism provides combined advantages of PDEVS and multiDEVS approaches, such as excellent simulation capabilities for simultaneously scheduled events and components able to influence each other using exclusively their state transitions. We next show the soundness of the formalism by giving a construction showing that any multiPDEVS model is equivalent to a PDEVS atomic model. We then present the simulation procedure associated, usually called abstract simulator. As a welladapted formalism to express cellular automata, we finally propose to compare an implementation of multiPDEVS formalism with a more classical CellDEVS implementation through a fire spread application.
1. Introduction
An important concept of general system theory is that of decomposition, which allows a system to be broken down into smaller subsystems to tackle its complexity, following a topdown approach. Conversely, interacting components may be coupled together resulting in a larger system following a bottomup approach [1].
Zeigler et al. [2] introduced the Theory of Modeling and Simulation (TMS), based on general system theory. Besides a framework which offers a precise description of the various entities involved in the modeling and simulation process, TMS provides a specification language for the modeling step called discrete event system specification commonly known as DEVS. DEVS handles well modular and nonmodular composition. With DEVS, modular systems interact through I/O ports, whereas nonmodular ones influence each other directly. While the former yields higher level of specification since it allows hierarchical construction, the latter remains interesting when modeling complex systems from bottomup.
In order to facilitate even more the modeling process TMS has saw emergence of multiple DEVSbased formalism. Most of them have been established for a modular and hierarchical approach, such as FDDEVS for model with finite state space [3], CellDEVS for cellular automata [4], RTDEVS for realtime modeling [5], and STDEVS for stochastic modeling [6]. For nonmodular approach, Zeigler et al. introduced another DEVSbased formalism, named multiDEVS [2].
Despite good extensibility properties, classic DEVS formalism has its own limitations. As with all other event scheduling approaches, it is up to the modeler to understand interactions between models and manage collisions that can occur between events. Consequently, the behavior of the model can easily deviate from the expected one if such collisions are not properly managed [7]. This issue prompted Chow and Zeigler to propose PDEVS, which includes entities dedicated to event collision handling, but only for the modular approach.
In this context, we propose a new formalism bringing effective management of event conflicts as was initially proposed within PDEVS, combined with the multiDEVS modeling approach. We propose a construction of equivalence with the PDEVS formalism and provide the associated abstract simulator. We call this formalism multiPDEVS.
multiPDEVS was initially created for a specific work, where an existing set of PDEVS models had to be coupled with nonmodular approach. However, this paper is fully dedicated to the formalism itself, and a simple example to help each knowledge level, from beginner to the expert in DEVS formalisms. This formalism is well adapted to problem classes similar to cellular automata [9, 10] and could be used in problems such as circulation management, robot path planning, physical propagation, or crowd modeling. Unlike specialized formalisms such as CellDEVS [4] where functions and structures are integrated to facilitate the specification process (e.g., the delay function of CellDEVS formalism), multiPDEVS does not integrate such specificities, which means that multiPDEVS is intended to be more generic and could be adapted to other classes of problems.
The next section gives a review of the PDEVS and multiDEVS formalisms where limitations and advantages of such formalisms are discussed. Section 2 presents recent applications of the multicomponent approach. Then, a third section gives a detailed description of the multiPDEVS formalism. Section 4 describes an example to illustrate the use of the formalism. Section 5 gives a clear overview of pros and cons of multiPDEVS from a modeling perspective, but also from a simulation perspective. The last section gives conclusions and perspectives.
2. Related Works
As far as we know, there are few works which explicitly use the multiDEVS formalism despite decades of existence [2].
We can cite Innocenti et al. [11] and Muzy et al. [12] where the nonmodular multicomponent is explicitly used. Based on multiDTSS (multicomponent Discrete Time System Specification) [2], the authors extend this formalism with the Active function (AmultiDTSS) to focus on activated cells of cellular forest fire propagation models in order to increase simulation performances. They agree that a nonmodular multicomponent based approach helps in reducing modeling and simulation complexity for cellular systems compared to a conventional modular approach as proposed by the DEVS formalism. Indeed, the feature of influencer/influencee offered by the multicomponent approach allows avoiding many messages exchanges, which permits increasing the simulation speed.
We can observe an equivalent message reduction principle within the flattening process of DEVS models where simulation speed improvement has been studied [13–15]. However, the flattening process must be clearly distinguished from multicomponent modeling. The flattening process of PDEVS model can be considered as a modeling transformation, where multicomponent approach must be considered as a modeling process. As given by Chen and Vangheluwe [16], the flattening of DEVS model consists of two steps: direct connection step where the coupled model is transformed to a coupled model of depth one, and flattening step where the coupled model of depth one is transformed in an atomic model, for the sole purpose of improving simulation performance. As we will see in detail subsequently, multiPDEVS is dedicated to nonmodular modeling process.
As introduced in the previous section, we believe that the multiDEVS formalism as initially proposed does not allow proper management of conflicts. Recent works of Shiginah and Zeigler [17] confirm our idea that the multicomponent approach is an interesting modeling approach but is somewhat neglected due to lack of efficient conflict management system. The authors offer a new specification for cellular DEVS models to increase performances of cell space simulations [17]. As a perspective, the authors recall an alternative consisting in the modification of multiDEVS, such that it becomes equivalent to the PDEVS formalism.
In this section, we make a review of necessary background, namely, multiDEVS formalism and PDEVS formalism as introduced by Zeigler et al. [2]. We also briefly introduce the new version of CellSpace DEVS formalism as proposed by Shiginah and Zeigler [17] to give the opportunity to the reader to understand the advantages of both formalisms.
2.1. The Original Multicomponent DEVS Formalism
There are two types of DEVS models, atomic and coupled. An atomic model describes the behavior of a system, while a coupled model describes a system as a network of components coupled together. These models are in the modular form, which means their interactions are restricted to happen through identified ports whose connection is preestablished. The multiDEVS formalism, which is based on classic DEVS, introduces a nonmodular way to couple components together where components can interact with each other by accessing and influencing other components states directly via state transition functions. As an illustration, we can take the cellular automaton example as proposed by Muzy et al. [12]:
In a nonmodular cellular automaton, simple neighboring rules can be implemented for every cell as: If my neighboring cell is alive, then I become alive. In a modular cellular automaton, the specification is different. It would be: If the message received from my neighboring cell indicates that it is alive, then I become alive.
For readers already acquainted with classic DEVS mechanism (but not necessarily with multicomponent approach), we should warn that the multiDEVS formalism can look forbidding at a first look.
In a multicomponent system, a component has its own set of states and state transition functions. Each component also has a set of influencers components from which it may be influenced and a set of influencees that it may influence through its state transition functions. Those interacting components form the overall system. An input to the system may influence all components and each component may contribute to the output of the system. Components are not considered standalone system specifications since they are devoid of an input and output interface.
In the hierarchy of system specifications, the multicomponent system specification lies in a lower level compared to a modular coupled network of systems such as a DEVS coupled model. Although both specifications allow the composition of interacting components to form a new system, components in the former are coupled nonmodularly since they influence each other directly, while, in a coupled network of systems, components modularly interact only through their I/O interfaces. If a modular approach is considered a more abstract level of specification, particular models of systems may be more suitable to be described in a nonmodular way. Systems such as cellular automata, individualbased models, or some kinds of multiagent systems environments (cellular models) might be good examples. In contrast, systems with structural constraints that may be encountered in systems engineering will be best modeled using a modular compositional approach. We should emphasize that both approaches may exist within the same modeled system. Indeed, a multicomponent DEVS system can be coupled together with other DEVS models. Another advantage of using multicomponent DEVS is that since components do not interact through I/O interfaces, the implementation cost of message routing is reduced leading to better performances [13, 14].
Figure 1 illustrates this principle with a simple case using three components: . In this example, , , and will have the opportunity to directly change the state of through its own state transition functions (, , and are considered as the set of influencers of ). Notice that there is no reciprocity between influencers and influencees. That means it is essential to make the distinction between them. Let us consider the relation between and (Figure 1). declares as an influencer whereas does not mention as one of these possible influencees. This means that can consult states to take decisions, but is not able to directly change the state of . Note that components could have direct interactions with interfaces of the system () through specific functions (see and in following paragraph).
A multicomponent DEVS is a structure:where and are the input and output event sets such aswith being the set of all possible values for the input port and being the set of all possible values for the output port .
is the set of component references and is a tiebreaking function employed to arbitrate in case of simultaneous events:
For each , component is defined bywhere is the set of sequential states of , is the set of components influencing , and is the set of influenced components by . A pair represents a total state that includes , the time elapsed since the last transition, and is the set of total states:Each component of a multiDEVS schedules the time of its next internal event based on total states of its influencers using the time advance function:When an internal event occurs in one of the components, state changes occur through the internal transition function that takes the total state set of the influencers and maps them into new total states for the influencees:This means that an internal event occurring in is able to change states of other components and may result in rescheduling their events. If this behavior is not desired because a component should only be allowed to change its own state, then should be defined as a unit set whose unique element is .
Eventually, output events may be generated for the multiDEVS through the output function:The output of the multiDEVS is defined by the output event of the component selected over imminent components. When events in different components are imminent, the function is used to arbitrate among them. External events at the multiDEVS’s input interface can be handled by any of the external state transition functions of the component :However, a component may not react to external inputs if its external state transition function is not defined and, similarly, can be left undefined if the component is not expected to produce output events.
As Chow and Zeigler [7] stated, when a DEVS model is constructed by coupling components together, such model behavior may deviate from the expected one since multiple state transitions can happen at the same simulation time. Two kinds of such transition collisions are distinguished:(i)collisions, which occur when a scheduled internal event overlaps with one or more external events;(ii)simultaneous events, which occur when several external events occur at the same time.
The classic DEVS and multicomponent DEVS solutions to transition collisions are not satisfactory since the behavior of a coupled model is established through the tiebreaker function. Concerning collisions as defined above, the priority of internal versus external events depends on the priority imposed by the function over imminent components (components with simultaneous scheduled internal events). Among those imminent components, the internal event is always preferred to the external ones for the first favored component. For the remaining components, external events might occur before the internal one since the output event of a first activated component always takes over the internal event of another imminent component. Regarding simultaneous events, the order at which one arrives is also a result of the priority given by . For the same simulation time, the external transition is sequentially activated each time an external event arrives. Consequently, if a state depends on two external events, the modeler must consider a transitory state. DEVS imposed serialization solution to transition collisions we just described is a weakness because it can be extremely difficult for the modeler to choose the sequence of internal events corresponding to the overall expected behavior of the model, especially if there is a lot of mutually influencing components. Furthermore, it prevents taking advantage of event simultaneity by parallelizing their process. For those reasons, Chow and Zeigler [7] introduced the parallel DEVS (PDEVS) specification which facilitates handling both kinds of transition collisions.
2.2. Parallel DEVS
In contrast to the classical DEVS formalism, the parallel form, namely, PDEVS [7], allows the modeler to properly handle collisions and simultaneous events at the component level. PDEVS makes several changes to the structures of atomic models and coupled models, as well as the abstract simulators. A demonstration that PDEVS preserves the closure under coupling property is given in Chow and Zeigler [7] by constructing the resultant of a coupled model as a welldefined PDEVS atomic model.
In order to provide a solution to transition collisions that might occur during a simulation (cf. Section 2.1), PDEVS suggests the following structure for an atomic model:where and are the input and output event sets and is the set of sequential states as defined in the multiDEVS specification. The pair form a total state where represents the time elapsed since the last transition and is the set of total states:
The time advance function determines the interval during which the current state remains valid, unless an external event occurs:When the time elapsed , the current state expires. Before calculating its new state, the model may produce a set of outputs for the current state through the output function:A new state is then calculated using the internal transition function:However, an external event that occurs on any input port will beget a new state calculated using the external transition function:In contrast to DEVS, the function is given a bag of input events instead of a single input event. This modification allows the modeler to properly handle simultaneous events we discussed in Section 2.1, since all simultaneous inputs intended for this model are available in a single transition.
In order to handle collisions (cf. Section 2.1), PDEVS introduces the confluent transition function , allowing to explicitly manage them rather than serializing model behavior at collision times:The modeler has complete control if any collision is to occur. He can choose what serialization to use (either the sequential activation of and of or the other way around) or a specific behavior.
The DEVS and PDEVS formalisms allow describing systems in a modular and hierarchical way as a network of coupled components, where components are atomic or coupled models. PDEVS defines such network aswhere and are the input and output event sets, is the set of component references, and, for each , is a PDEVS atomic model as defined above or another coupled model as defined here.
Couplings between components are represented with the help of a set , where, for each , represent the set of components influencing, formally defined asAlong with , couplings are given by the output to input function . Thus, for each and for each ,
The PDEVS coupled model structure is near identical to a DEVS coupled model. Only the tiebreaker function which originally allows the modeler to prioritize an atomic model among the set of imminent components () disappears. In PDEVS semantics, the activation of components scheduled at the same simulation time is not serialized as in DEVS, so becomes unnecessary. Instead, a twophase approach is employed: collect all imminent components outputs and perform appropriate transitions which are internal transitions for all imminent components, external transitions for components about to receive inputs given the collected outputs in the first phase, and confluent transitions for imminent components which also receives inputs.
In addition to providing a specification which facilitates handling transition collisions, PDEVS semantics benefits from the intrinsic parallelism that imminent components in a network of models offers. Each time an internal event occurs, each phase of the simulation protocol as described above can be easily parallelized among components, with a sync barrier between the two phases.
2.3. CellSpace DEVS Specification
As introduced previously, Shiginah and Zeigler [17] present a new cell space DEVS specification for faster model development and simulation efficiency based on their previous work [18]. This new specification offers a significant improvement in simulation speed by providing effective management of active cells and a strong limitation of the number of intercell messages.
Usually, a cellular system is described using an atomic DEVS model for each cell (CellDEVS [4]). To reduce intercell messages, authors integrate all the cells in a single atomic model called atomic CellSpace. To get there, and it is here where our works meet, authors transform the modular description of the system to a nonmodular version using a restricted version of the influencer/influencee principle described in multiDEVS (cf. Section 2.1). In contrast to multiDEVS, they decide to protect the cell integrity and do not allow to write the state variables of other cells (read only). This is expressed in our formalism as a restriction of all influenced components () of a component to the component itself. Formally, is restricted to the singleton , . Perfectly acceptable for their application to cellular automata, this restriction allows authors to easily manage state changes in cells with a classical storage of the current state of all cells. In our case, the proposed formalism aims to be more generic and this restriction is no longer suitable. This will force us to integrate a new state collision management mechanism, as presented in the next section.
3. A Parallel Multicomponent DEVS Formalism
To our knowledge, the multicomponent approach as defined by Zeigler et al. [2] never benefited from the refinements provided by the PDEVS formalism concerning transition collisions management. We propose an attempt to bring those refinements to the multicomponent approach along with a way to handle another kind of collisions, specific to the nonmodular approach, which we call state collisions. Such state collisions simply happen when multiple transitions occur at the same simulation time. They are related to the way components interact in multicomponent systems (directly changing state variables of other components through state transitions).
Because components are allowed to access and write on each other’s state, we can consider each transition as a violation of other components autonomy in the sense that they do not evolve having full control over their states and, thus, their behavior. In contrast, a PDEVS atomic model ensures autonomy through modularity because the only way to influence it externally is through an external event. We believe this property is essential for proper modeling of a given system and should be taken into consideration for the multicomponent approach.
In the multiDEVS abstract simulator [2], as we explained in Section 2.1, all imminent components scheduled for the next simulation time are serialized and prioritized via the function. As with DEVS, for the same simulation time, the order at which components are activated may produce a behavior that is not the intended one in the first place and that is difficult to tackle down. As an example, consider a multicomponent system composed of three components , , and as illustrated in Figure 1. Figure 2 illustrates a particular scenario where the of components and is equal to 0, which means an internal event is due for both of them at the same simulation time (step (a)). It means that the internal transition of both components and will sequentially be activated following the priority given at the multicomponent level by the function (step (b)). Here, priority is first given to component , which means it may write directly on the state of component . Consequences of this particular choice may result in different possible scenarios from here. The state change made in could result in another internal event due for the same simulation time (in that case the two imminent components remaining are and ). Another possibility is that remains the only imminent component and its internal transition is finally activated (which also may write on the state of and could lead to overwrite changes made by on state). In our opinion, there is two kinds of difficulties in modeling such system: the behavior becomes quickly difficult to anticipate and direct changes on components states are conceptually arguable.
Recall semantics of PDEVS, which carries outputs of all imminent components, and then all appropriate transitions for the same simulation time. In order to apply PDEVS semantics to the multicomponent approach, we have to apply the same solutions concerning collisions and simultaneous events as long as a solution to state collisions exists. Simultaneous transitions in a multicomponent system may imply multiple states generated for a given component at the same simulation time. Rather than serializing those states, we take the same path as PDEVS that is leaving the decision to the modeler. This way, one can decide which state change to apply in a particular order or how to compose those multiple states into a new one. Not only does it allow solving state collisions but also it provides a way to introduce component autonomy in nonmodular systems: the component is fully responsible for its state at any moment.
In this section, we present our proposal of a formal multicomponent approach using PDEVS semantics as introduced above, called multiPDEVS. We also present the construction of equivalence of multiPDEVS with a PDEVS atomic model and, finally, the abstract simulator following PDEVS protocol is given.
3.1. multiPDEVS
In order to propose a parallel multicomponent system specification, we argued in the above discussion that we need to apply PDEVS semantics to the nonmodular approach alongside a way to manage state collisions.
In the multicomponent DEVS specification, components are not provided with their own I/O interface. Still, they remain able to communicate with other modular components via the interface of their parent, the multiPDEVS itself. When an external event occurs at the multiPDEVS level, all components that defined an external transition function receive this event. Similarly, all components that defined an output function are able to produce outputs at the multiPDEVS level. To be equivalent with PDEVS, we introduce in the component structure the set of bags of inputs over elements in allowing the modeler to handle simultaneous events and also introduce the confluent transition function , allowing the modeler to explicitly define the collision behavior. To manage state collisions, we propose the reaction transition function, , which gives the modeler a chance to explicitly define state collisions behavior. That implies modifying other state transition functions, so that , , and do not give new states to influencees but suggest them instead. The reaction transition is given as an argument a bag whose elements include all states suggested by components able to influence this particular component for the same simulation time. Each suggested state is accompanied with the identity of the component that produced it. We note as the set of bag of proposed partial states over elements in .
The structure of the multicomponent parallel DEVS iswhere , , and are defined as in multiDEVS. Note that the function, as in PDEVS, disappears from the multiPDEVS definition. It becomes useless since all imminent components are handled simultaneously rather than being serialized.
For each , a component is defined by the structurewhere is the set of sequential states of , is the set of total states with the time elapsed since the last transition, is the set of influencing components, and is the set of influenced components. Components schedule the time of their next internal event based on total states of their influencers using the time advance function:
When , the component may generate a set of outputs for the multiPDEVS output interface via the output function (which can be left undefined):Then, the internal event being due, its internal transition function is activated. It takes the total state set of the influencers and maps them into suggested states for the set of influencees:
If one or several new states are produced through state transitions of components able to influence , then the reaction transition function is activated in order to let the modeler explicitly define the state collision behavior. For instance, if two components each suggest a new state for component where a particular variable is incremented, then should be able to produce a new state where the variable value depends on the two suggested states and the current state of . To allow this, the function is given the bag of suggested states and the current state of the component:whereThe tuple is a suggested state for produced by component , where , and the set of bag of suggested states for over elements in is noted .
This function takes the bag of states produced by other components including in their set of influencees alongside its current total state in order to produce its new valid total state. The reason we use only instead of the crossproduct of all influencers states () is to ensure coherence of states. If we allow this, we have to ensure that all reads on are performed on current states and not on new ones produced by their own function, which can happen if proposed states have been produced at the same simulation time by components for components included in .
When external events occur at the multiPDEVS level, its components may receive them if they define their corresponding external transition function:
As in PDEVS (in contrast to DEVS and multiDEVS), is given a bag of inputs that contains all simultaneous external events instead of a single input event. If an internal event is due simultaneously with one or several external events, a collision is to be managed. The confluent transition function, originally introduced in PDEVS, allows explicitly managing the collision behavior:
Note that, similarly to the internal transition function, and generate a set of proposed states () for the influencees instead of directly updating their states.
The semantics of multiPDEVS are illustrated in Figure 3 using the same scenario we presented in Section 3 with Figure 2. Components and are imminent. Both of them perform their internal state transition ( and ) generating simultaneously new states for component , which is a state collision (step (a)). is given complete control over its future state via the function, whose behavior may consist in choosing what state to apply or composing a new one (step (b)).
A multiPDEVS works in the following way. As in PDEVS, the activation of imminent components is done simultaneously using a twophase approach. In the first phase, the outputs of all components that defined a function are collected. We divide the second phase in three other microsteps: in the first microstep, appropriate state transitions are performed and their outputs (the state bags) are temporarily saved for the second microstep. For components that defined , external transitions are activated when external events occur on the input interface of the multiPDEVS. For all imminent components, when there is also inputs available at the multiPDEVS level, confluent transitions are activated for components who defined ; otherwise their is activated. If there are no inputs, internal transitions are activated for all imminent components. The second microstep consists of activating the reaction transition function for all components that have a bag of states generated during the first microstep. Finally, the third microstep consists in calculating the time of next events of each influenced component using the time advance function. Such semantics can be integrated in a PDEVS atomic model, which allows integrating multiPDEVS in a larger PDEVS simulation.
3.2. Construction of Equivalence with PDEVS
In this section, we give proof of multiPDEVS equivalence with PDEVS by constructing the multiPDEVS resultant as a welldefined atomic PDEVS. This construction ensures that a multiPDEVS model may be coupled with other PDEVS models within a coupled model.
A multiPDEVS defines a PDEVS as follows.
Given a multiPDEVS as defined earlier, we associatewhere .
We definewith as the remaining time until the next scheduled event in .
We define the set of imminent components as
We define, for each , , the set of suggested states produced by and and the set of suggested states and their producers for each influenced component .
Given that andwithwhere
the resultant internal transition function contains two kinds of component transitions. For components influenced by imminent ones, function is called. The state transition function of each imminent is executed, where is the state vector of the influencing components , which produces a set of proposed states for all influenced components . In order to fill the incoming bag of proposed states () of each , each suggested state produced for will result in a tuple composed of the state and its corresponding producer. For components having their bag of proposed states empty (), the elapsed time is simply updated.
The output of the system is defined by
The external transition function upon occurrence of an input bag of events is defined by the crossproduct of the external state transition functions of all components . We define the overall external transition function bywithwhere
With a similar mechanism, the incoming bag of proposed states () of each influenced component is built using function. As previously mentioned, in other components where the bag of proposed states is an empty set (), the elapsed time is simply updated.
The confluent transition function is defined bywithwhere
Finally, the incoming bag of proposed states () dedicated to the resultant confluent transition function is composed using three different contributions: from imminent components where function is undefined (influence comes from ), from imminent components where a function is defined (influence comes from ), and finally from nonimminent components where a function is defined (influence comes from ).
Note that such proof ensures that multiPDEVS models can be transformed to atomic PDEVS models and used asis with a PDEVS simulator. A preferable solution is to avoid any transformation of the multiPDEVS model, using the DEVS bus principle to simulate the multiPDEVS in its original form, which we detail in the following section.
3.3. multiPDEVS Abstract Simulator
Among the benefits of DEVS formalisms, model/simulator distinction is one of the key elements. This leads to a clear separation of concerns. It helps to dissociate what is related to the model, from what is related to how it is executed. This makes DEVS models easier to reuse and exchange [19].
In order to integrate the multiPDEVS approach into a PDEVSbased simulation environment, we use the DEVS bus concept by wrapping multiPDEVS into a PDEVS form along with its own dedicated simulator. This allows multiPDEVS models to be modularly coupled with other models and executed through a PDEVS coordinator. The multiPDEVS formalism presented in Section 3.1 is compatible asis with a PDEVS since we provide an I/O interface (ports at the multiPDEVS level) and associated functions (, , and at the component level). The simulator we define here sticks to the simulation mechanism of PDEVS by following its communication protocol as defined in Chow et al. [20] as illustrated in Figure 4.
Abstract simulators, or simulation processors, associated with PDEVS models come in two forms, simulator and coordinator. While a simulator role is to execute the atomic model functions, a coordinator role is to carry out and manage output events of its children as long as their scheduling.
We intentionally omit the root coordinator, but we note that it oversees the whole simulation process and initializes the simulation time () with the min of its children.
The simulator we present in the following assumes both simulator and coordinator roles since it realizes its own event handling for the model components. Listing 1 gives the variables declaration block along with the initialization procedure of all components ( message).

As shown in Listing 1, we keep track of the time of last event and time of next event for the multiPDEVS but also for all its components ( and ). Upon receipt of an initialization message , last and next event times and of each component are set before sorting them into the event list. Then, the global and of the multiPDEVS are, respectively, set to the maximum and to the minimum .
Since multiPDEVS allows for external and output events, we give the procedures associated with the corresponding messages in Listing 2. messages come from the parent coordinator and carry inputs for the multiPDEVS, and @messages also come from the parent coordinator to collect outputs of the multiPDEVS.

Upon receipt of an external input message , the simulator does nothing more than filling the input bag, as a PDEVS simulator does. Upon arrival of a collect message (@, ), the simulator collects all outputs from components that defined the output function and sends them back to the parent coordinator.
Finally, the procedure associated with the receipt of an internal message () is given in Listing 3.

The procedure associated with the receipt of an internal event (, ) consists in three sequential steps (Listing 3). The first step (lines 45–69) activates appropriate state transitions for components of the multiPDEVS depending on their , if there is incoming input from the overall system and if is defined. When the input bag is empty, we employ the event list and retrieve the imminent components with .
The state transition function of each imminent is executed (where is the state vector of the influencing components ) and produces a set of proposed states (ps) for all influenced components . The incoming bag of proposed states is filled by adding to each suggested state the identity of its producer.
When the input bag is not empty and , the external transition function is applied for all components with that defined . For each imminent component (), we activate the confluent transition function if the external transition function is defined; otherwise we activate the internal transition function . Note that all three state transition functions all produce an outgoing set of proposed states for all its influenced components which is then translated in order to fill their incoming bag.
The second step (lines 71–74) consists in activating the reaction transition function for all components having a nonempty bag of incoming proposed states generated by imminent components during the first step. Each component being influenced will produce a new state given all proposed states and its current total state.
The third step (lines 75–81) role is to update the time of next events for each influenced component. As a result of the second step, which update states of influenced components, a chance is given to those components to update their time advance values. This requires the to be updated as well as a rescheduling of the component in the event list. Finally, the global event times and are updated appropriately.
Note that the abstract simulator we present in this section is fully sequential. Another version that parallelizes processing of components during each microstep of the message procedure with a sync barrier between the two steps can be considered. However, locks associated with influencers states of a given component should be owned by this component each time it is susceptible of reading them. This is a potential source of deadlocks that we do not explore in this paper. Similarly, a distributed version may be considered. Same comments apply with an additional constraint: a mechanism should be provided to allow a component to access its influencers states that may be located on a different node (e.g., through the proxy design pattern).
In discrete event simulation, the dynamics of a model can be represented by different “world views,” namely, the event scheduling world view, the activity scanning world view, the three phase approach world view, and the process interaction world view. The abstract simulator we present here belongs to the first approach, where components preschedule their time of execution in the future via the function. Zeigler et al. [2] do provide two abstract simulators for the original multiDEVS formalism, one for the event scheduling world view, and another for both the activity scanning and the process interaction world views. For multiPDEVS, those alternative abstract simulators can be considered for further research but we do not present them in this paper.
This last subsection, which defines the abstract simulator, provides behavioral semantics to the structural definition of multiPDEVS given in Section 3.1. Added to the proof that a multiPDEVS may exist within a larger PDEVS simulation (cf. Section 3.2), all necessary information is given in order to realize a proper implementation of the multiPDEVS formalism.
4. Case Study: Application to Fire Spread Modeling
Based on a fire spreading model [8], this section proposes to illustrate the modeling process using a multicomponent approach. First subsection introduces the semiphysical fire spread model. Then, second subsection presents the related multiPDEVS specification. Finally, last subsection gives comparison with a modular formalism, namely, CellDEVS [4].
4.1. Semiphysical Fire Spread Model
Among the variety of mathematical models that grasps fire propagation, we focus on a semiphysical model [8]. According to Weber [21], fire spread models can be classified in three categories depending on their properties: statistical models, which do not include any physical phenomena; semiempirical models, which consider the principle of energy conservation; and, finally, physical models, being the most detailed models. The model we use is a combination of the last two categories and is described as a nonstationary twodimensional semiphysical model [8]. It is a semiempirical model transposed to integrate two dimensions and a model which considers physical properties such as heat transfer for propagation.
The model is spatialized through elementary cells holding plant mass, where each cell is described by the following partial differential equation:where
Table 1 gives the nomenclature of model parameters. The model parameters are identified by Balbi et al. [8] from experimental data of temperature versus time.
This particular model has been discretized in Muzy et al. [22] using the Finite Difference Method (FDM), which leads to the following algebraic equation:where represent the cell temperature and , , , and are coefficients that depend on the time step and mesh size considered. For our example, as in Muzy et al. [22], we consider a discrete time step of 0.01 s and uniform cells of 1 cm^{2}.
Such discretized model is well and easily expressed using a multicomponent approach since a cell can be represented by a component and its neighbors can be represented using the set of influencing components and the set of influenced components . To illustrate how such system can be modeled using multiPDEVS, we propose a detailed specification in the next subsection.
4.2. multiPDEVS Specification
In this subsection, we propose a specification of the semiphysical fire spread model using multiPDEVS to represent a cellular automaton, where each cell holds its temperature. When the automaton evolves, each cell updates its temperature according to ones of its Moore neighborhood. The multiPDEVS model represents the whole surface, which is composed of homogeneous components with identical behavior influencing each other uniformly.
The multiPDEVS can be specified as follows: and are empty sets since there is no input or output to the model. is the index set composed of twodimensional coordinates. For each , the component, which represents a cell, is specified as
The state of a component cell is represented by the following quintuple:where , is the current temperature of the cell, is the previous temperature of the cell, with being the temperature vector of all neighbors, and, finally, holds the simulation time at which the cell is ignited.
The set of influencers is defined by the Moore neighborhood and the cell itself: . Reciprocally, a cell is able to influence itself and its neighbors. Thus, the set of influencees .
, , or are not specified since there is no overall input or overall output.
Basically, for a given cell , when reaches a threshold, updates for all its influencees its corresponding temperature in the temperature vector with its current temperature . At each step, the cell also produces a new state for itself (). It means that each cell may be given nine potential states to its function (eight proposed states from its neighbors plus one suggested for itself). In this particular case, the reaction transition function composes a new state using primarily the proposed one produced by itself, but constructs the temperature vector using proposed states from other components.
Note that in order to simplify transitions functions specification of the fire spread model, we will use the “dotnotation,” conventionally used in objectoriented programming languages (e.g., the element must be understood as the temperature element of the global state of component ).
Since each cell holds a vector of nearby temperatures that is updated by neighbors themselves, it is possible to keep some cells inactive; that is, inactive cells (, ). This results in the following time advance function:
Given that the definitions of and are much less concise to write, we specify these functions in the pseudocode shown in Listing 4.
