DEVS-based formalism for the modeling of routing processes

Abstract

The Discrete Event System Specification (DEVS) is a modular and hierarchical Modeling and Simulation (M&S) formalism based on systems theory that provides a general methodology for the construction of reusable models. Well-defined M&S structures have a positive impact when building simulation models because they can be applied systematically. However, even when DEVS can be used to model routing situations, the structures that emerge from this kind of problem are significant due to the handling of the flow of events. Often, the modeler ends with a lot of simulation models that refer to variants of the same component. The goal of this paper is to analyze the routing process domain from a conceptual modeling perspective through the use of a new DEVS extension called Routed DEVS (RDEVS). The RDEVS formalism is conceptually defined as a subclass of DEVS that manages a set of identified events inside a model network where each node combines a behavioral description with a routing policy. In particular, we study the modeling effort required to solve the M&S of routing problems scenarios employing a comparison between RDEVS modeling solutions and DEVS modeling strategies. Such a comparison is based on measures that promote the capture of the behavioral complexity of the final models. The results obtained highlight the modeling benefits of the RDEVS formalism as a constructor of routing processes. The proposed solution reduces the modeling effort involved in DEVS by specifying the event routing process directly in the RDEVS models using design patterns. The novel contribution is an advance in the understanding of how DEVS as a system modeling formalism supports best practices of software engineering in general and conceptual modeling in particular. The reusability and flexibility of the final simulation models, along with designs with low coupling and high cohesion, are the main benefits of the proposal that improve the M&S task applying a conceptual modeling perspective.

Appendices

Appendix A

1.1 RDEVS closure under coupling

1.1.1 RDEVS network model to RDEVS routing model

The Network Model

$$N = < X, Y, D, \{ R_{d} \} , \{ I_{d} \} , \{ Z_{i,d} \} , T_{{{\text{in}}}} , T_{{{\text{out}}}} , {\text{Select}} >$$

where each d Є D refers to a Routing Model defined as R_d that is structured as

$$R_{d} = < \omega_{d} , E_{d} , M_{d } >$$

defines an equivalent Routing Model

$$R = < \omega , E, M >$$

in which:

• ω = (u, W, δ_r) = (0, ø, δ_r) | δ_r: S_M → T_OUT ˄ T_OUT = ø ≡ routing policy to be used in R. The equivalent model uses zero value as its identifier and an empty set of entities to represent the models from which input events are allowed. These settings enable Clause #3 of the external transition function detailed in the Routing Model definition. Then, R processes all input events that arrive. Moreover, by setting the routing function into an empty set value for any possible combination of T_OUT, all the output events of R will be sent everywhere (therefore, their processing depends on the receptor model configuration). Both behaviors are equivalent to the one expected of N since all input events that arrive at the Network Model are received but, also, all the output events created are sent.

• E =  < X_E, S_E, Y_E, δ_int,E, δ_ext,E, λ_E, τ_E > ≡ essential model embedded in R in which:

  • o X_E = X ≡ set of input events of E. As R is detailed as an equivalent model of N and, the Routing Model uses the inputs of E as part of its own inputs definition, the inputs of E are defined as equals to the inputs of N.

  • p S_E =  × _iЄDQ_i | Q_i = {(s_i, e_i) | s_i Є S_M,i, 0 ≤ e_i ≤ τ_M,i(s_i), ∀i Є D ≡ set of sequential states of E detailed as the product of the Q_i sets defined for each model that compose N (these are the Routing Models). Each Q_i is defined as an ordered pair that contains the state and the elapsed time of the R_i model.

  • q Y_E = Y ≡ set of output events of E. As in the case of input events, the output events of E are defined as equals to the output events of N.

  • r δ_int,E(s) = s’ ≡ internal transition function of E that modifies the state s = (…,(s_j, e_j),…) to s’ = (…,(s’_j, e’_j),…) where {s, s’} Є S_E. Since the state of E is defined as a state combination of the models included in N, an internal transition of E may involve simultaneous internal transitions of multiple components. Then, considering that the imminent components (that is, the ones that must adjust its state) are collected according to the time value σ in a set structured as

    $${\text{IMM}}\left( s \right){\text{ }} = {\text{ }}\{ {\text{ }}i \in D{\text{ |}}\sigma _{i} = {\text{ }}\tau _{{E,i}} \left( s \right){\text{ }}\}$$

    one model i^* must be selected to execute its internal transition. The N tie-breaking function can be used to get the i^* model. So, the imminent internal transition to be executed belongs to the R_i* model where i^* = Select(IMM(s)). However, as a consequence of this transition, all external transitions of the components influenced by R_i* must be executed. So, the final state transformation from s = (…,( s_j, e_j ),…) to s’ = (…,( s’_j, e’_j ),…) is defined by

    $$s^{\prime}_{j} = \left\{ \begin{gathered} \delta _{{\text{int} ,M,j}} (s_{j} )\;\;\;\;\;\;\;\;{\text{if}}\;j = 1 \hfill \\ \delta _{{{\text{ext}},M,j}} (s_{j} ,e_{j} + \tau _{E} (s),x_{j} )\;{\text{If}}\;i^* \in I_{j} \wedge x_{j} \ne \varnothing\;{\text{with}}\;x_{j} = Z_{{i*j}} (\lambda _{{M,i*}} (s_{{i*}} )) \hfill \\ s_{j} \;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;{\text{Otherwise}} \hfill \\ \end{gathered} \right.$$
    $$e'_{j} = \left\{ \begin{gathered} 0~\;\;{\text{if}}~\left( {~j = i^{{*~}} } \right)~\lor ~(~i^{*} \in I_{j} \wedge ~x_{j} \ne {\o} ) \hfill \\ e_{j} + ~\tau _{E} \left( s \right)\;\; \text{otherwise} \hfill \\ \end{gathered} \right.~$$

  • s δ_ext,E(s, e, x) = s’ ≡ external transition function of E that modifies the set of state pairs that refers to the R_i models linked to the inputs of N. Given that the state of E is defined as S_E, the states {s, s’} Є S_E where s = (…,(s_i, e_i),…) and s’ = (…,(s’_i, e’_i),…). Considering that components are collected in a set C = { i Є D | N Є I_i ˄ x_i ≠ ø}, then

    $$s_{i}^{*} = \delta_{{{\text{ext}},M,i}} \left( {s_{i} ,e_{i} + e,x_{i} } \right){\text{with}}\; x_{i} = Z_{N,i} \left( x \right), \forall i \in C$$

    so the state transformation is defined as

    $$(s_{i}^{'} ,e_{i}^{'} )~ = ~\left\{ \begin{gathered} (s_{i}^{*} ,0)~\;\;{\text{if}}\;(~N~ \in ~I_{i} ~\wedge x_{{i~}} \ne ~{\o}) \hfill \\ (s_{d} ,~e_{d} + e)\;{\text{otherwise}}~ \hfill \\ \end{gathered} \right.$$

  • t λ_E(s): S_E → Y_E ∪ ø ≡ output function of E that generates an output event if and only if the model that is going to execute its internal transition (that is, i^* model) is linked to the outputs of N. The function is defined as

    $$\lambda_{E} (s) = \left\{ \begin{gathered} Z_{i*,N} \left( {\lambda_{M,i*} \left( {s_{i*} } \right)} \right)\;{\text{if}}\;N \in I_{i*} \hfill \\ {\varnothing} \;{\text{otherwise}} \hfill \\ \end{gathered} \right.$$

  • u τ_E: S_E → $R_{{o,\infty }}^{ + }$ ≡ time advance function of E that select the most imminent event time of all the components (that is, the routing models) included in N (i.e. finding the smallest remaining time σ until the internal transition of all the simulation models included in N). The function is defined as

    $$\tau _{E} \left( s \right){\text{ }} = {\text{ }}\min {\text{ }}\{ {\text{ }}\sigma _{i} = {\text{ }}\sigma _{{M,i}} \left( {s_{i} } \right){\text{ }}{-}{\text{ }}e_{i} |i \in D{\text{ }}\}$$

• M =  < X_M, S_M, Y_M, δ_int,M, δ_ext,M, λ_M, τ_M > ≡ DEVS atomic model that specifies the routing process of R. Given that the description of M is defined in the routing model definition and, considering that its specification uses some of the components defined in E, no considerations are required to get the equivalent model of N.

1.2 RDEVS routing model to RDEVS essential model

The Routing Model specification includes two DEVS models defined as E and M. To define an Essential Model that acts as an equivalent model of a Routing Model description, it is important to understand the difference between both models. While E determines the Component to be used as part of the Node (that is, the Essential Model that describes the behavior of the Routing Model), M defines the executable simulation model over which the routing process takes place. Then, the equivalence proof tries to find a Component with the same behavior that a Node. Moreover, it can use the Node description as part of the Component specification since both models belong to the same type (DEVS atomic model).

Then, the Routing Model described by the structure

$$R = < \omega_{R} , E_{R} , M_{R} >$$

with M_R =  < X_M,R, S_M,R, Y_M,R, δ_int,M,R, δ_ext,M,R, λ_M,R, τ_M,R > , can be described as an equivalent Essential Model structured as

$$M = < X, S, Y, \delta_{{\text{int}}} , \delta_{{{\text{ext}}}} , \lambda , \tau >$$

in which X = X_M,R, S = S_M,R, Y = Y_M,R, δ_int = δ_int,M,R, δ_ext = δ_ext.M,R, λ = λ_M,R and τ = τ_M,R. Following this equivalence, each component of M_R (that is, the executable model of the routing model description) is directly mapped to a new model that defines an Essential Model that maintains the desired behavior of the Routing Model.

Appendix B

2.1 Representation of web architectures as discrete-event simulation models

2.1.1 DEVS representation

Figures 

Fig. 15

Mapping the Web Architecture #1 into DEVS models detailed in Table 4

15 and

Fig. 16

Mapping the Web Architecture #2 into DEVS models detailed in Table 4

16 show the representation of the web-based architectures depicted in Fig. 12 as DEVS models. Each box included in the figures refer to a DEVS model detailed in Table 4. In Fig. 15, we use the models defined in the first row of Table 5 (i.e., the ones designed for Fig. 12a). Instead, in Fig. 16, we use the models defined in the second row of the table (i.e., the DEVS models detailed for the architecture depicted in Fig. 12b).

2.2 RDEVS representation

Figures 

Fig. 17

Mapping the Web Architecture #1 into RDEVS models detailed in Table 5

17 and

Fig. 18

Mapping the Web Architecture #2 into RDEVS models detailed in Table 5

18 show the representation of the web-based architectures depicted in Fig. 12 as RDEVS models. Each box included in the figures refer to a RDEVS model detailed in Table 5. In both cases, the same set of models is used.