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 well-adapted formalism to express cellular automata, we finally propose to compare an implementation of multiPDEVS formalism with a more classical Cell-DEVS 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 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 bottom-up.
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 real-time 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 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 Cell-DEVS [4] where functions and structures are integrated to facilitate the specification process (e.g., the delay function of Cell-DEVS 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 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 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 tie-breaking 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 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.
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 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: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 tie-breaker 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 two-phase 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 (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.
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 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 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 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 , 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 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.
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 cross-product 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 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.
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 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 (, , 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, 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
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 cm2.
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 two-dimensional 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 “dot-notation,” 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 (, ). 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.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The 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 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–13).
The 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 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.
(a)
(b)
(c)
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.
5. 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.
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 ) 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 . 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 . 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 a +1 (if it empty) but that leaves open which neighbor is the sender. If it chooses one (by some rules), it must inform the neighbors so they will adjust their states accordingly. Currently, this feedback to maintain consistency will require a second complete simulation phase. Now, multiPDEVS introduced the set (whose elements are tuples composed of suggested states and of the identity of the component that sent it), specifically for this purpose, so that a component can choose its new state depending on the identity of the sender (which is not necessarily present in its set of influencers ). In the particle example described using multiPDEVS, each component would be responsible for adjusting its neighbors’ states to ensure that no particle is lost in the system. This also means that a state described by is not sufficient, since the component has to store information about particles to be sent back through the classical function and a . At this moment, it seems that such an issue is best tackled using a modeling approach (which involves use of = 0 loops) rather than expand the formalism itself. Nevertheless, an extension of multiPDEVS formalism might be to allow some kind of built-in reverse propagation of selection information and this can be considered as a source of further research.
6. Conclusion
TMS provides a DEVS specialization dedicated to nonmodular modeling, named multiDEVS. As DEVS, multiDEVS formalism comes with a lack of expressiveness to properly manage collisions between events. PDEVS formalism has been proposed to fill this gap for the modular approach. Hence, we propose multiPDEVS, which furnishes an effective management of events conflicts as proposed in PDEVS, to multiDEVS. The multiPDEVS formalism supports concepts as introduced by PDEVS, such as the bag concept to combine simultaneous event into a single one, and the confluent transition function to combine internal and external transition function when they occur at the same simulation time. In contrast to PDEVS, multiPDEVS handles an additional kind of conflict dictated by the nonmodular approach, which we call state collisions. Such state collisions appear when multiple components execute state transitions function at the same simulation time, resulting in a possible violation of other components autonomy. We are convinced that autonomy of components is a necessary property for a proper modeling process. To keep such property, multiPDEVS provides new concepts around function. These new concepts give modelers the possibility of collecting state collisions in a bag of states () and then managing them explicitly at component level through the reaction function (). The multiPDEVS formalism offers to facilitate the modeling process for nonmodular approaches without increasing message exchanges. The multiPDEVS formalism is proved to be equivalent to a well-defined atomic PDEVS model. Such property involves the possibility of integrating multiPDEVS in a larger PDEVS simulation.
The multiPDEVS formalism has been compared to other nonmodular formalisms such as CellSpace. We show that CellSpace can be considered as a restriction of multiPDEVS. Finally, the multiPDEVS formalism has been implemented using Quartz and allowed us to test its performances against a Cell-DEVS approach using a cellular automaton. This performance speedup added to good modeling abilities comforted us in its significance for highly communicative models with tight coupling but also for modeling paradigms falling under bottom-up approaches.
Definition of the multiPDEVS formalism opens many perspectives, from both an utility and an extensibility point of view. Future works include use of the multiPDEVS formalism to describe MAS environments as cellular models since multiPDEVS is well-suited to represent spatially explicit models. Individual-based models (IBM) are also good candidates to be defined using multiPDEVS, where individuals are represented with components interacting with each other. Besides, we predict a simulation speedup using multiPDEVS rather than PDEVS both for representing MAS environments and IBM for the same reason we obtained better results representing a cellular automaton using multiPDEVS, which is the reduction of message exchange between models during simulation.
Finally, Section 5 discusses benefits and drawbacks of using the multiPDEVS formalism, from both a modeling perspective and a simulation perspective.
Currently in full-scale testing in a fisheries management project, the multiPDEVS formalism should allow efficient modeling of fishing areas and interactions between them. As for the future of the multiPDEVS formalism we consider many perspectives of evolution. We plan to define alternative abstract simulators following other simulation strategies, known as world views (cf. Section 3.3). We also consider as a further research the definition of a parallel and distributed version of the abstract simulator. Another interesting property applied to multiPDEVS would be that of dynamic structure, which DEVS and PDEVS benefit from via DS-DEVS [26] or dynDEVS [29] extensions. For completeness, we also consider definition of a multicomponent parallel discrete time system, multiPDTSS, along with its abstract simulator. Given that discrete time is a special case of discrete event systems, multiPDTSS would allow to explicitly combine discrete time systems with discrete event systems within the same framework.
As mentioned previously, there are other possible approaches, especially HFSS [28]. It would be very interesting to make a deeper comparison with it, especially on the ergonomic aspect of modeling and performance.
Conflicts of Interest
The authors declare that there are no conflicts of interest regarding the publication of this paper.
Acknowledgments
This work is carried out within the framework of the MoonFish research project supported by the Corsican region (CTC) and the European Union (EU) through the po-FEDER regional programs.