multiPDEVS: A Parallel Multicomponent System Specification Formalism

,


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 top-down approach.Conversely, interacting components may be coupled together resulting in a larger system following a bottom-up 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 DEVS-based formalism.Most of them have been established for a modular and hierarchical approach, such as FD-DEVS for model with finite state space [3], Cell-DEVS for cellular automata [4], RT-DEVS for realtime modeling [5], and ST-DEVS for stochastic modeling [6].For nonmodular approach, Zeigler et al. introduced another DEVS-based 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

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][14][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.

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 non-modular 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 stand-alone 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, individual-based 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  ext and  in following paragraph).
A multicomponent DEVS is a structure: where  and  are the input and output event sets such as with   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 tie-breaking function employed to arbitrate in case of simultaneous events: For each  ∈ , component   is defined by where   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 .

Complexity
Eventually, output events may be generated for the multi-DEVS 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  ext, 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 tie-breaker  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.

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 well-defined 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: PDEVS = (, , ,  int ,  ext ,  con , , ta) , (10) 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 ta() determines the interval during which the current state remains valid, unless an external event occurs: When the time elapsed  = ta(), 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  ext 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  con , 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  int and of  ext 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 as  = (, , , {  } , {  } , { , }) , (17) where  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 as Along 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 tie-breaker  function which originally allows the modeler to prioritize an atomic model among the set of imminent components (min{ta  (  |  ∈ )}) 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 two-phase approach is employed: (1) collect all imminent components outputs and (2) 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.

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 (Cell-DEVS [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.

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 ta 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 (1) and (2) 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.

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  con , allowing the modeler to explicitly define the collision behavior.To manage state collisions, we propose the reaction transition function,  reac , which gives the modeler a chance to explicitly define state collisions behavior.That implies modifying other state transition functions, so that  int ,  ext , and  con 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 is multiPDEVS = (, , , {  }) , where , , and  are defined as in multiDEVS.Note that the  function, as in PDEVS, disappears from the mul-tiPDEVS definition.It becomes useless since all imminent components are handled simultaneously rather than being serialized.
For each  ∈ , a component   is defined by the structure   = (  ,   ,   ,  ext, ,  int, ,  con, ,  reac, ,   , ta  ) , (21) where   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   = ta  (), 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: where The 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 cross-product 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  reac 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),  ext, 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,  ext, and  con, 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 ((1) and (2)) generating simultaneously new states for component , which is a state collision (step (a)). is given complete control over its future state via the  reac 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 two-phase 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  ext , 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  ext ; otherwise their  int 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.

Construction of Equivalence with PDEVS.
In this section, we give proof of multiPDEVS equivalence with PDEVS by constructing the multiPDEVS resultant as a well-defined 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.
We define the set of imminent components as We define, for each  ∈ ,   = {  |  ∈   ♯ }, the set of suggested states produced by  ♯ and   = {(  ,  ♯ ) |  ♯ ∈ IMM(),  ∈   ♯ } and the set of suggested states and their producers for each influenced component .
Given that  ♯ ∈ IMM() and  with where the resultant internal transition function contains two kinds of component transitions.For components influenced by imminent ones,  reac, (   , (  ,   )) function is called.The state transition function  int, ♯ of each imminent  ♯ is executed, where (. . ., (  ,   + ta()), . ..) 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  ext upon occurrence of an input bag of events   is defined by the cross-product of the external state transition functions of all components  ∈ .We define the overall external transition function by with where Finally, the incoming bag of proposed states (   ) dedicated to the resultant confluent transition function is composed using three different contributions: from imminent components where  ext, function is undefined (influence comes from  int, ), from imminent components where a  ext, function is defined (influence comes from  con, ), and finally from nonimminent components where a  ext, function is defined (influence comes from  ext, ).
Note that such proof ensures that multiPDEVS models can be transformed to atomic PDEVS models and used as-is 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.

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 PDEVS-based 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 as-is with a PDEVS since we provide an I/O interface (ports at the multiPDEVS level) and associated functions ( ext ,  con , 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 tn 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).

Complexity
As shown in Listing 1, we keep track of the time of last event tl and time of next event tn for the multiPDEVS but also for all its components (tn  and tl  ).Upon receipt of an initialization message (, ), last and next event times tl  and tn  of each component are set before sorting them into the event list.Then, the global tl and tn of the multiPDEVS are, respectively, set to the maximum tl  and to the minimum tn  .
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 tn  , if there is incoming input from the overall system and if  ext, is 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  = tn, the external transition function  ext, is applied for all components  ∈  with tn  > tn that defined  ext, .For each imminent component (tn  = tn = ), we activate the confluent transition function  con, if the external transition function  ext, is defined; otherwise we activate the internal transition function  int, .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 tn  to be updated as well as a rescheduling of the component in the event list.Finally, the global event times tl and tn 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 ta  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.

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 Reduced combustion enthalpy Vegetable surface mass  V0 (kg m −2 ) Initial vegetable surface mass (before combustion)  ig (s) Ignition time multiPDEVS specification.Finally, last subsection gives comparison with a modular formalism, namely, Cell-DEVS [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 two-dimensional 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 , =   at the boundary (44) , ≥  ig for the burning cells (45) , =   for the non-burning cells at  = 0.
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.

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 state  , of a component cell is represented by the following quintuple: where phase ∈ {inactive, warming, burning},  ∈ R + 0 is the current temperature of the cell,  prev ∈ R + 0 is the previous temperature of the cell,  neigh = (. . .,   , . ..) with  ∈   being the temperature vector of all neighbors, and, finally,  ig ∈ R + 0 holds the simulation time at which the cell is ignited.
ext,, ,  con,, , or  , are not specified since there is no overall input or overall output.

Complexity 13
Basically, for a given cell (, ), when  , −  prev,, reaches a threshold, (, ) updates for all its influencees (, ) ∈  , its corresponding temperature in the temperature vector  neigh,(,) 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  reac,, 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  neigh 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 object-oriented 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 (phase = inactive,  , =   ).This results in the following time advance function: Given that the definitions of  int,, and  reac,, are much less concise to write, we specify these functions in the pseudocode shown in Listing 4.
The  reac,, function defined in Listing 4 allows a (, ) cell to decide its new state given its current state  , and all suggested ones in   , .When iterating over suggested states (line 6), if a suggested state was produced by (, ) for itself through the  int,, function ((, ) = (, ), line 7), the next state is primarily constructed based on this suggested state.If there is no suggested state produced by (, ) (cell is inactive), the state is primarily based on the current one (line 4).For other producers of suggested states ((, ) ̸ = (, )), the cell (, ) is only interested in the temperature vector that was updated by the producer, so it constructs its new temperature vector according to all these contributions (line 10).If the cell is currently inactive while receiving nearby temperatures, the cell will pass in the warming phase (lines [11][12][13]. The  int,, function suggests new states for all its influencees.Two parts can be identified.The first (lines 21-27) corresponds to the construction of new states for neighbors.Those states are simply a copy of their current states with an update to the temperature vector so that the current temperature corresponding to ((, )) is updated.The second phase (lines 28-36) corresponds to the calculation of the new temperature for this cell, according to equations given in Section 4.1.The conditional statement allows computing the  V value depending on the macrostate of the cell, according to (43).Regarding (47), coefficients  and  corresponding to the thermal conductivity of neighbors cells are merged into  since we use the same value.This coefficient is applied to the sum of neighbors temperatures, which is computed line 21.
A new phase is then calculated using the newphase function depending on the new temperature and the current phase.Finally, if the cell phase passes from warming to burning, the ignition time is set.
We should emphasize that we modeled component cells this way as a proof of concept of state collisions handling, but such a model could be modeled the other way around using only the set of influencers  , to read neighbors states temperatures and restrict  , to the unit set {(, )} so that each cell generates a state only for itself.However, this alternative approach would require to change the time advance functions in order to keep all cells active so that they are able to poll neighbors temperatures even if they are inactive.In practice, the former approach prevents inactive cells to be activated until they are warmed up by neighbors while the latter approach keeps all cells active.

4.3.
Comparison with a Modular Formalism.We discuss here the benefits of specifying a system such as the fire spread model described earlier using multiPDEVS in comparison with a modular formalism such as PDEVS or Cell-DEVS.
From a modeling perspective, the same fire spread model specified through a network of components such as a PDEVS coupled model instead of a multiPDEVS is much more verbose to specify because all couplings between cells have to be addressed since cells are represented by atomic models.The Cell-DEVS [4] extension, on the other hand, eases the specification of cellular automata by abstracting the definition of couplings between neighbor cells while preserving modularity, since these cells are represented by atomic models.As of multiPDEVS, it is well-suited for the specification of cellular automata as-is for two reasons: neighborhood is easily represented through the influencer/influencee principle and components are able to access their neighbors states without having to anticipate variables of interest and having to send these through dedicated functions as this is the case for PDEVS or Cell-DEVS.
From a simulation perspective, using a modular approach may be less advantageous depending on the implementation since event routing is a potential source of overhead [23], although several techniques [16,24] allow managing this issue.In contrast, multiPDEVS has no communication overhead between components influencing each other since it avoids traditional event routing.
We realized an implementation of multiPDEVS using Quartz (code available at https://github.com/rumenzu/quartz.), a Crystal port of DEVS-Ruby [25], which is a simulation tool that allows specification of PDEVS models.It provides several extensions such as Cell-DEVS [4] or DSDE [26], and we extended it to integrate multiPDEVS and its simulator.To define new multiPDEVS models, Quartz provides a class MultiComponent::Model which can be modularly coupled to other models and to which may be added component models.Component models can be defined using the provided abstract class MultiComponent::Component that the modeler has to extend via inheritance.Our tool then uses the appropriate simulator according to the model type during simulation.Figure 5 illustrates execution of the fire spread model using multiPDEVS (as given in Section 4.2) on a 25 × 25 grid at different simulation times.Regarding parameters values, we used the constant temperature values described in Table 1.Also, the reduced combustion enthalpy  was set to 2.74, and the combustion time constant  was set to 0.19.Coefficients  and  from (47), which correspond to the thermal conductivity of neighbors cells, were both set to 0.0031.Coefficient , which corresponds to the thermal conductivity of the actual cell, was set to 0.98689.Finally, coefficient  was set to 0.213.
An initial hotbed exists at the center of the grid where one cell is ignited and surrounding cells are warmed (Figure 5(a)), temperature in the rest of the cell space is homogeneous  and represents the ambient temperature.This simple model allows us to test our implementation using highly interacting low computational components that remain active during the whole simulation.
In order to verify our intuition that we may obtain best execution times using multiPDEVS due to the absence of event routing, we implemented the same model using the Cell-DEVS extension of Quartz in order to compare both results.For this performance analysis, we ran ten simulations for each approach (multiPDEVS and Cell-DEVS) using the same model, the same initial conditions, and the same environment (Quartz) and measured the elapsed real time.The test environment is based on an Intel(R) Core(TM) i5-3210 M CPU @ 2.50 GHz (3 MB L2 cache), 8 GB (2x DDR3L-1600 Mhz) of RAM, and an Apple SSD SM128E hard drive, running on OSX 10.11.4.Software used is Quartz.Figure 6 shows the results of running those simulations with error bars showing average, min, and max measured times for each batch of repeated simulations and Table 2 shows average elapsed real-time results and the relative standard deviation for each experiment.
Event routing and message passing overhead in Quartz is reduced using techniques similar to Himmelspach and Uhrmacher [24] and Vicino et al. [27].Despite that, as we can appreciate on the graph, multiPDEVS yields better results than its modular counterpart for the same simulated model as we obtain an average speedup of 1.75x.Those results comfort us in multiPDEVS relevance, especially for this kind of highly communicative models with tight coupling.However, in order to extract better conclusions relative to performances, a new benchmark is necessary using a framework that performs complete flattening (as mentioned in Section 2), that is, transformation of the Cell-DEVS in a coupled model of depth one (which Quartz does) and the transformation of this coupled to an atomic model.
In this section we presented a fire spreading model cellular automaton.Cellular automata is a modeling paradigm that is well expressed using the multiPDEVS formalism and it was also the opportunity to compare its performances against a Cell-DEVS implementation.The next section discusses benefits and drawbacks of the proposed approach from modeling and simulation perspectives.

Discussion
The fire spread example shows that multiPDEVS can be used to fully specify a system.However, it is quite legitimate for the modeler to ask the following question: "When should I, or should I not use this formalism ?"MultiPDEVS can improve the modeling process in a multiformalism context, where modular and nonmodular system specification are used at the same time.We believe that the modular approach proposed by PDEVS and the nonmodular one have to be seen as complementary approaches, and in no way as competing approaches.Regularly, systems offer a clear hierarchical description coupled with elements where the system behavior will be harder to describe using modular specification formalism.In those cases, it can be more comfortable to describe the overall interaction through direct influence mechanism rather than describe the system at a higher level of specification.The modular approach will allow bringing a good intelligibility of the model, while the nonmodular multicomponent approach will allow simplifying the description of some phenomena by improving the formalism expressiveness.

Complexity
One can ask the question of the reusability of a nonmodular model and more particularly of these various components.If with the fire spread example, such question does not really arise (components are the same), it becomes legitimate for models where components differ.By nature, the influencer/influencee principle used with nonmodular approach makes components strongly dependants.Obviously it is possible to reuse or replace components of a multicomponent model; however, this must be done with caution.The modeler needs to perfectly understand interactions with influencee components and influenced components of the targeted component.Without making reusability a trivial process, the modular approach will help since more effort was previously given to express interactions between components.Reusability at the multicomponent level is equivalent to the modular approach, since a multiPDEVS model is strictly equivalent to a PDEVS atomic model.
As defined in Section 3.3, a multiPDEVS model can be integrated within a PDEVS-based simulation environment using its own dedicated simulator and can be simulated through an abstract mechanism, as originally defined in Zeigler et al. [2].The whole simulation is driven by several processors (cf. Figure 4), where coordinators are responsible for managing event routing and scheduling their children and simulators are responsible for the activation of their associated model.The multiPDEVS simulator we provide perfectly conforms to this mechanism, and, thus, allows multiPDEVS to be modularly coupled with other PDEVS models and executed by the same PDEVS coordinator.This allows reducing the difficulty of integrating multiPDEVS within a simulation environment while enriching the set of formalisms available for the user of such platform.Due to the multiPDEVS simulation protocol nature, we observe traffic messages reduction in relation to PDEVS.Such observations suggest increased simulation performances.Since an appropriate benchmark has not been done yet and some work [23] shows that proper management of messages can significantly increase performances of PDEVS, we will remain cautious in the final performance of multiPDEVS.
Regarding performances, multiPDEVS may be affected by the nature of interactions between components.In the fire spread example we used, components states have small memory requirements, but we can ask how well the formalism scales with larger memory needs.Since the sets of suggested states for each components are temporarily kept during each simulation cycle, memory allocation can be a concern.We should note that PDEVS has a similar issue at a lower extent with input messages, instead of suggested states.For example, with PDEVS, messages sent between two components can be sized according to the needs of the model.Contrariwise, to change a single value of the state of an influencee, a multiPDEVS component should construct a whole new state for its influencee.In practice, pointers techniques could help reduce this overhead, but this particular issue should be further studied to have a better idea of multiPDEVS performances.
Another element of performance improvement may appear with some types of models.If we focus on communications between components, a multiPDEVS may require fewer simulation cycles than PDEVS in some cases.Let us take two components, A and B, where B needs information provided by A. Following are PDEVS's and multiPDEVS's ways of modelizing it.Using PDEVS: B can ask A for data.Then A sends data to B (see Figure 7).Following PDEVS simulation protocol, this will therefore require at least two simulation cycles.Using multiPDEVS: B can directly read data from A (A is an influencer of B).Following the multiPDEVS protocol, a single simulation cycle will therefore be necessary.Note that such example considers only the case where B is explicitly requesting information known by A component.We intentionally forget cases where A is a data generator, where A needs computation time to provide data.An alternative to multiPDEVS and PDEVS is HFSS [28], which allows components to sample inputs from their influencers through couplings in a one-step process, similarly to multiPDEVS.Since HFSS preserves modularity through couplings, it lies at a higher level of specification than multiPDEVS.However, multiPDEVS is pertinent for cases where component states need to be directly accessible.
Further studies would be needed to target the classes of problems for which this type of property would be an added value.We are thinking for the moment of the domains where agent and cellular automata are used jointly (e.g., agent interrogating its environment modeled by several cells).
Regarding some design choices about multiPDEVS, we decided to stay as close as possible to the original multiDEVS.However, an interesting alternative regarding multiPDEVS semantics may be considered.As multiPDEVS is defined; only components that have been influenced (i.e., that updated their state via their reaction function  reac ) have a chance to update their time of next event.Since the time advance function of a component depends on all influencers states, we could also give the opportunity to all components having at least one influencer with a new state to update its tn.This would open new modeling perspectives.As an example, the case study we propose in Section 4.2 could be simplified.Basically, an inactive cell could decide if it is the appropriate moment to enter a burning state each time one of its neighbors is updated.
Generally speaking, DEVS-based formalisms where components are allowed to communicate at the same simulation time, such as PDEVS or multiPDEVS, do not offer direct mechanisms to confirm to other components the use of an information/resource which was provided to them.This can raise issues of inconsistency unique to such formalisms.To illustrate this, imagine particles that can move from one cell to a neighbor as shown in Figure 8.
The state of the model is in {0, 1}.Suppose particles in the A and C cells want to move in to the center cell B at the same time.A and C send their proposed states.Since decision is based on proposed states, the center can choose

Figure 1 :
Figure 1: A multiDEVS model: components can interact through state transition functions.

Figure 2 :
Figure 2: Illustration of state collision serialization using multi-DEVS.

Figure 3 :
Figure 3: Illustration of state collision management using multiPDEVS.

Table 2 :
Performance comparison results of multiPDEVS and Cell-DEVS showing average elapsed real time and relative standard deviation for each approach.