|
|
@@ -5,5 +5,374 @@
|
|
|
\subsection{Statechart}
|
|
|
\subsection{SCXML}
|
|
|
|
|
|
-\section{PyDEVS}
|
|
|
-\subsection{DEVS Formalism}
|
|
|
+\section{DEVS Formalism}
|
|
|
+The Discrete Event System Specification (DEVS)
|
|
|
+formalism was first introduced by Zeigler (TODO) in 1976 to provide a rigourous common basis for discrete-event modelling and
|
|
|
+simulation. For the class of formalisms denoted as discrete-event (TODO), system models are described at an abstraction
|
|
|
+level where the time base is continuous (TODO), but during a bounded time-span, only a finite number of relevant events
|
|
|
+occur. These events can cause the state of the system to change. In between events, the state of the system does not
|
|
|
+change. This is unlike continuous models in which the state of the system may change continuously over time. As an
|
|
|
+extension of Finite State Automata, the DEVS (Discrete Event Systems) formalism captures concepts from Discrete Event
|
|
|
+simulation. As such it is a sound basis for meaningful model exchange in the Discrete Event realm. (TODO: citation)
|
|
|
+
|
|
|
+The DEVS formalism fits the general structure of deterministic, causal systems in classical systems theory. DEVS allows
|
|
|
+for the description of system behaviour at two levels. At the lowest level, an atomic DEVS describes the autonomous
|
|
|
+behaviour of a discrete-event system as a sequence of deterministic transitions between sequential states as well as
|
|
|
+how it reacts to external input (events) and how it generates output (events). At the higher level, a coupled DEVS
|
|
|
+describes a system as a network of coupled components. The components can be atomic DEVS models or coupled DEVS in their
|
|
|
+own right. The connections denote how components influence each other. In particular, output events of one component
|
|
|
+can become, via a network connection, input events of another component. It is shown in [Zei84a] how the DEVS formalism
|
|
|
+is closed under coupling: for each coupled DEVS, a resultant atomic DEVS can be constructed. As such, any DEVS model,
|
|
|
+be it atomic or coupled, can be replaced by an equivalent atomic DEVS. The construction procedure of a resultant atomic
|
|
|
+DEVS is also the basis for the implementation of an abstract simulator or solver capable of simulating any DEVS model.
|
|
|
+As a coupled DEVS may have coupled DEVS components, hierarchical modelling is supported. In the following, the different
|
|
|
+aspects of the DEVS formalism are explained in more detail.
|
|
|
+
|
|
|
+\subsection{The atomic DEVS Formalism}
|
|
|
+The atomic DEVS formalism is a structure describing the different aspects of the discrete-event behaviour of a system:
|
|
|
+\begin{equation}
|
|
|
+ atomicDEVS \equiv \langle S, ta, \delta_{int}, X, \delta_{ext}, Y, \lambda \rangle
|
|
|
+\end{equation}
|
|
|
+The time base $T$ is continuous and is not mentioned explicitly
|
|
|
+\begin{equation}
|
|
|
+ T = \mathbb{R}
|
|
|
+\end{equation}
|
|
|
+The state set $S$ is the set of admissible sequential states: the DEVS dynamics consists of an ordered sequence of states
|
|
|
+from $S$. Typically, $S$ will be a structured set (a product set)
|
|
|
+\begin{equation}
|
|
|
+ S = \times_{i=1}^{n} S_i.
|
|
|
+\end{equation}
|
|
|
+This formalizes multiple (n) concurrent parts of a system. It is noted how a structured state set is often synthesized
|
|
|
+from the state sets of concurrent components in a coupled DEVS model.
|
|
|
+
|
|
|
+The time the system remains in a sequential state before making a transition to the next sequential state is modelled by
|
|
|
+the time advance function
|
|
|
+\begin{equation}
|
|
|
+ ta: S \rightarrow \mathbb{R}^+_{0, + \infty}.
|
|
|
+\end{equation}
|
|
|
+As time in the real world always advances, the image of $ta$ must be non-negative numbers. $ta = 0$ allows for the
|
|
|
+representation of instantaneous transitions: no time elapses before transition to a new state. Obviously, this is an
|
|
|
+abstraction of reality which may lead to simulation artifacts such as infinite instantaneous loops which do not correspond
|
|
|
+to real physical behaviour. If the system is to stay in an end-state $s$ forever, this is modelled by means of $ta(s) = +\infty$.
|
|
|
+
|
|
|
+The internal transition function
|
|
|
+\begin{equation}
|
|
|
+ \delta_{int}: S \rightarrow S
|
|
|
+\end{equation}
|
|
|
+models the transition from one state to the next sequential state. $\delta_{int}$ describes the behaviour of a Finite State
|
|
|
+Automaton; $ta$ adds the progression of time.
|
|
|
+
|
|
|
+It is possible to observe the system output. The output set $Y$ denotes the set of admissible outputs. Typically, $Y$ will be a
|
|
|
+structured set (a product set)
|
|
|
+\begin{equation}
|
|
|
+ Y = \times_{i=1}^l Y_i.
|
|
|
+\end{equation}
|
|
|
+This formalizes multiple ($l$) output ports. Each port is identified by its unique index $i$. In a user-oriented modelling
|
|
|
+language, the indices would be derived from unique port names.
|
|
|
+
|
|
|
+The output function
|
|
|
+\begin{equation}
|
|
|
+ \lambda : S \rightarrow Y \cup \{ \phi \}
|
|
|
+\end{equation}
|
|
|
+maps the internal state onto the output set. Output events are only generated by a DEVS model at the time of an internal
|
|
|
+transition. At that time, the state before the transition is used as input to $\lambda$. At all other times, the non-event
|
|
|
+$\phi$ is output. To describe the total state of the system at each point in time, the sequential state $s \in S$ is not
|
|
|
+sufficient. The elapsed time $e$ since the system made a transition to the current state $s$ needs also to be taken into
|
|
|
+account to construct the total state set
|
|
|
+\begin{equation}
|
|
|
+ Q = \{ (s,e) | s \in S,, 0 \leq e \leq ta(s)\}
|
|
|
+\end{equation}
|
|
|
+The elapsed time $e$ takes on values ranging from 0 (transition just made) to $ta(s)$ (about to make transition to the next
|
|
|
+sequential state). Often, the time left $\sigma$ in a state is used:
|
|
|
+\begin{equation}
|
|
|
+ \sigma = ta(s) - e
|
|
|
+\end{equation}
|
|
|
+Up to now, only an autonomous system was described: the system receives no external inputs. Hence, the input set $X$
|
|
|
+denoting all admissible input values is defined. Typically, $X$ will be a structured set (a product set)
|
|
|
+\begin{equation}
|
|
|
+ X = \times_{i=1}^m X_i
|
|
|
+\end{equation}
|
|
|
+This formalizes multiple ($m$) input ports. Each port is identified by its unique index $i$. As with the output set,
|
|
|
+port indices may denote names.
|
|
|
+
|
|
|
+The set $\Omega$ contains all admissible input segments $\omega$
|
|
|
+\begin{equation}
|
|
|
+ \omega : T \rightarrow X \cup \{ \phi \}
|
|
|
+\end{equation}
|
|
|
+In discrete-event system models, an input segment generates an input event different from the non-event $\phi$ only at a finite
|
|
|
+number of instants in a bounded time-interval. These external events, inputs $x$ from $X$, cause the system to interrupt its
|
|
|
+autonomous behaviour and react in a way prescribed by the external transition function
|
|
|
+\begin{equation}
|
|
|
+ \delta_{ext}: Q \times X \rightarrow S
|
|
|
+\end{equation}
|
|
|
+The reaction of the system to an external event depends on the sequential state the system is in, the particular input and
|
|
|
+the elapsed time. Thus, $\delta_{ext}$ allows for the description of a large class of behaviours typically found in
|
|
|
+discrete-event models (including synchronization, preemption, suspension and re-activation). When an input event $x$ to an
|
|
|
+atomic model is not listed in the $\delta_{ext}$ specification, the event is ignored.
|
|
|
+
|
|
|
+% TODO: Example of traffic light/ Starts with "In Figure 1" ...
|
|
|
+
|
|
|
+\subsection{The coupled DEVS Formalism}
|
|
|
+The coupled DEVS formalism describes a discrete-event system in terms of a network of coupled components.
|
|
|
+\begin{equation}
|
|
|
+ coupledDEVS \equiv \langle X_{self}, Y_{self}, D, \{M_i\}, \{I_i\}, \{Z_{i,j}\}, select \rangle
|
|
|
+\end{equation}
|
|
|
+The component $self$ denotes the coupled model itself. $X_{self}$ is the (possibly structured) set of allowed external inputs
|
|
|
+to the coupled model. $Y_{self}$ is the (possibly structured) set of allowed (external) outputs of the coupled model. $D$ is
|
|
|
+a set of unique component references (names). The coupled model itself is referred to by means of $self$, a unique reference
|
|
|
+not in $D$.
|
|
|
+
|
|
|
+The set of components is
|
|
|
+\begin{equation}
|
|
|
+ \{M_i | i \in D\}.
|
|
|
+\end{equation}
|
|
|
+Each of the components must be an atomic DEVS
|
|
|
+\begin{equation}
|
|
|
+ M_i = \langle S_i, ta_i, \delta_{int, i}, X_i, \delta_{ext, i}, Y_i, \lambda_i \rangle , \forall i \in D.
|
|
|
+\end{equation}
|
|
|
+The set of influences of a component, the components influenced by $i \in D \cup \{self\}$, is $I_i$. The set of all influences
|
|
|
+describes the coupling network structure
|
|
|
+\begin{equation}
|
|
|
+ \{ I_i | i \in D \cup \{self\}\}.
|
|
|
+\end{equation}
|
|
|
+For modularity reasons, a component (including $self$) may not influence components outside its scope -the coupled model-,
|
|
|
+rather only other components of the coupled model, or the coupled model $self$:
|
|
|
+\begin{equation}
|
|
|
+ \forall i \in D \cup \{self\}: I_i \subseteq D \cup \{self\}.
|
|
|
+\end{equation}
|
|
|
+This is further restricted by the requirement that none of the components (including $self$) may influence themselves directly
|
|
|
+as this could cause an instantaneous dependency cycle (in case of a 0 time advance inside such a component) akin to an algebraic
|
|
|
+loop in continuous models:
|
|
|
+\begin{equation}
|
|
|
+ \forall i \in D \cup \{self\}: i \not \in I_i.
|
|
|
+\end{equation}
|
|
|
+Note how one can always encode a self-loop ($i \in I_i$) in the internal transition function.
|
|
|
+
|
|
|
+To translate an output event of one component (such as a departure of a customer) to a corresponding input event (such as the
|
|
|
+arrival of a customer) in influencees of that component, output-to-input translation functions $Z_{i,j}$ are defined:
|
|
|
+\begin{equation}
|
|
|
+ \{ Z_{i,j} | i \in D \cup \{self\}, j \in I_i\}, \\
|
|
|
+ Z_{self, j} : X_{self} \rightarrow X_j, \forall j \in D, \\
|
|
|
+ Z_{i, self} : Y_i \rightarrow Y_{self}, \forall i \in D, \\
|
|
|
+ Z_{i, j} : Y_i \rightarrow X_j, \forall i,j \in D.
|
|
|
+\end{equation}
|
|
|
+Together, $I_i$ and $Z_i,j$ completely specify the coupling (structure and behaviour).
|
|
|
+
|
|
|
+As a result of coupling of concurrent components, multiple state transitions may occur at the same simulation time. This is
|
|
|
+an artifact of the discrete-event abstraction and may lead to behaviour not related to real-life phenomena. A logic-based
|
|
|
+foundation to study the semantics of these artifacts was introduced by Radiya and Sargent (TODO). In sequential simulation
|
|
|
+systems, such transition collisions are resolved by means of some form of selection of which of the components' transitions
|
|
|
+should be handled first. This corresponds to the introduction of priorities in some simulation languages. The coupled DEVS
|
|
|
+formalism explicitly represents a select function for tie-breaking between simultaneous events:
|
|
|
+\begin{equation}
|
|
|
+ select : 2^D \rightarrow D
|
|
|
+\end{equation}
|
|
|
+$select$ chooses a unique components from any non-empty subset E of D:
|
|
|
+\begin{equation}
|
|
|
+ select(E) \in E.
|
|
|
+\end{equation}
|
|
|
+The subset E corresponds to the set of all components having a state transition simultaneously.
|
|
|
+
|
|
|
+\subsection{Closure of DEVS under coupling}
|
|
|
+As mentioned before, it is possible to construct a resultant atomic DEVS model for each coupled DEVS. This closure under
|
|
|
+coupling of atomic DEVS models makes any coupled DEVS equivalent to an atomic DEVS. By induction, any hierarchically coupled
|
|
|
+DEVS can thus be flattened to an atomic DEVS. As a result, the requirement that each of the components of a coupled DEVS be
|
|
|
+an atomic DEVS can be relaxed to be atomic or coupled as the latter can always be replaced by an equivalent atomic DEVS.
|
|
|
+
|
|
|
+The core of the closure procedure is the selection of the most imminent (i.e., soonest to occur) event from all the components'
|
|
|
+scheduled events (TODO). In case of simultaneous events, the select function is used. In the sequel, the resultant construction
|
|
|
+is described.
|
|
|
+
|
|
|
+From the coupled DEVS
|
|
|
+\begin{equation}
|
|
|
+ \langle X_{self}, Y_{self}, D, \{M_i\}, \{I_i\}, \{Z_{i,j}\}, select \rangle
|
|
|
+\end{equation}
|
|
|
+with all components $M_i$ atomic DEVS models
|
|
|
+\begin{equation}
|
|
|
+ M_i = \langle S_i, ta_i, \delta_{int, i}, X_i, \delta_{ext, i}, Y_i, \lambda_i \rangle, \forall i \in D
|
|
|
+\end{equation}
|
|
|
+the atomic DEVS
|
|
|
+\begin{equation}
|
|
|
+ \langle S, ta, \delta_{int}, X, \delta_{ext}, Y, \lambda \rangle
|
|
|
+\end{equation}
|
|
|
+is constructed.
|
|
|
+
|
|
|
+The resultant set of sequential states is the product of the total state sets of all the components
|
|
|
+\begin{equation}
|
|
|
+ S = \times_{i \in D} Q_i
|
|
|
+\end{equation}
|
|
|
+where
|
|
|
+\begin{equation}
|
|
|
+ Q_i = \{ (s_i, e_i) | s \in S_i, 0 \leq e_i \leq ta_i(s_i) \}, \forall i \in D.
|
|
|
+\end{equation}
|
|
|
+The time advance function $ta$
|
|
|
+\begin{equation}
|
|
|
+ ta : S \rightarrow \mathbb{R}^+_{0, + \infty}
|
|
|
+\end{equation}
|
|
|
+is constructed by selecting the most imminent event time, of all components. This means, finding the smallest time remaining
|
|
|
+until internal transition, of all the components
|
|
|
+\begin{equation}
|
|
|
+ ta(s) = \min \{\sigma_i = ta_i(s_i) - e_i | i \in D \}.
|
|
|
+\end{equation}
|
|
|
+A number of imminent components may be scheduled for a simultaneous internal transition. These components are collected in a
|
|
|
+set
|
|
|
+\begin{equation}
|
|
|
+ IMM(s) = \{i \in D | \sigma_i = ta(s)\}.
|
|
|
+\end{equation}
|
|
|
+From $IMM$, a set of elements of $D$, one component $i^*$ is chosen by means of the select tie-breaking function of the coupled
|
|
|
+model
|
|
|
+\begin{equation}
|
|
|
+ select : 2^D \rightarrow D \\
|
|
|
+ IMM(s) \rightarrow i^*
|
|
|
+\end{equation}
|
|
|
+Output of the selected component is generated before it makes its internal transition. Note also how, as in a Moore machine,
|
|
|
+input does not directly influence output. In DEVS models, only an internal transition produces output. An input can only
|
|
|
+influence/generate output via an internal transition similar to the presence of memory in the form of integrating elements in
|
|
|
+continuous models. Allowing an external transition to produce output could lead to infinite instantaneous loops. This is equivalent
|
|
|
+to algebraic loops in continuous systems. The output of the component is translated into coupled model output by means of the
|
|
|
+coupling information
|
|
|
+\begin{equation}
|
|
|
+ \lambda(s) = Z_{i^*, self} (\lambda_{i^*}(s_{i^*})), \text{if} self \in I_{i^*}.
|
|
|
+\end{equation}
|
|
|
+If the output of $i^*$ is not connected to the output of the coupled model, the non-event $\phi$ can be generated as output of
|
|
|
+the coupled model. As $\phi$ literally stands for no event, the output can also be ignored without changing the meaning (but
|
|
|
+increasing performance of simulator implementations).
|
|
|
+
|
|
|
+The internal transition function transforms the different parts of the total state as follows:
|
|
|
+\begin{equation}
|
|
|
+ \delta_{int}(s) = (..., (s'_j, e'_j),...), \text{where} \\
|
|
|
+ (s'_j, e'_j) = (\delta_{int, j} (s_j), 0), \text{for} j = i^*, \\
|
|
|
+ = (\delta_{ext, j} (s_j, e_j + ta(s), Z_{i^*, j}))
|
|
|
+ % TODO: Verder doen
|
|
|
+\end{equation}
|
|
|
+The selected imminent component $i^*$ makes an internal transition to sequential state $\delta_{int, i^*} (s_i^*)$. Its elpased
|
|
|
+time is reset to 0. All the influencees of $i^*$ change their state due to an external transition prompted by an input which is
|
|
|
+the output-to-input translated output of $i^*$, with an elapsed time adjusted for the time advance $ta(s)$. The influencees'
|
|
|
+elapsed time is reset to 0. Note how $i^*$ is not allowed to be an influencee of $i^*$ in DEVS. The state of all other components
|
|
|
+is not affected and their elapsed time is merely adjusted for the time advance $ta(s)$.
|
|
|
+
|
|
|
+The external transition function transforms the different parts of the total state as follows:
|
|
|
+\begin{equation}
|
|
|
+ \delta_{ext}(s,e,x) = (..., (s'_i, e'_i), ...)
|
|
|
+ % TODO
|
|
|
+\end{equation}
|
|
|
+An incoming external event is routed, with an adjustment for elapsed time, to each of the components connected to the coupled
|
|
|
+model input (after the appropriate input-to-input translation). For all those components, the elapsed time is reset to 0. All
|
|
|
+other components are not affected and only the elapsed time is adjusted.
|
|
|
+
|
|
|
+Some limitations of DEVS are that
|
|
|
+\begin{itemize}
|
|
|
+ \item a conflict due to simultaneous internal and external events is resolved by ignoring the internal event. It should be
|
|
|
+ possible to explicitly specify behaviour in case of conflicts;
|
|
|
+ \item there is limited potential for parallel implementation;
|
|
|
+ \item the select function is an artificial legacy of the semantics of traditional sequential simulators based on an event
|
|
|
+ list;
|
|
|
+ \item it is not possible to describe variable structure.
|
|
|
+\end{itemize}
|
|
|
+Some of these are compensated for in parallel DEVS (TODO).
|
|
|
+
|
|
|
+\subsection{Implementation of a DEVS Solver}
|
|
|
+The algorithm in Figure (TODO) is based on the closure under coupling construction and can be used as a specification of a
|
|
|
+(possibly parallel) implementation of a DEVS solver or “abstract simulator” (TODO). In an atomic DEVS solver, the last event
|
|
|
+time $t_L$ as well as the local state $s$ are kept. In a coordinator, only the last event time $t_L$ is kept. The
|
|
|
+next-event-time $t_N$ is sent as output of either solver. It is possible to also keep $t_N$ in the solvers. This requires
|
|
|
+consistent (recursive) initialization of the $t_N$s. If kept, the $t_N$ allows one to check whether the solvers are
|
|
|
+appropriately synchronized. The operation of an abstract simulator involves handling four types of messages. The ($x, from, t$)
|
|
|
+message carries external input information. The ($y, from, t$) message carries external output information. The ($*, from, t$)
|
|
|
+and ($done, from, t_N$) messages are used for scheduling (synchronizing) the abstract simulators. In these messages, $t$ is the
|
|
|
+simulation time and $t_N$ is the next-event-time. The ($*, from, t$) message indicates an internal event * is due.When a
|
|
|
+coordinator receives a ($*, from, t$) message, it selects an imminent component $i^*$ by means of the tie-breaking function
|
|
|
+select specified for the coupled model and routes the message to $i^*$. Selection is necessary as there may be more than one
|
|
|
+imminent component (with minimum next remaining time).
|
|
|
+
|
|
|
+When an atomic simulator receives a ($*, from, t$) message, it generates an output message ($y, from, t$) based on the old state
|
|
|
+$s$. It then computes the new state by means of the internal transition function. Note how in DEVS, output messages are only
|
|
|
+produced while executing internal events. When a simulator outputs a ($y, from, t$) message, it is sent to its parent coordinator.
|
|
|
+The coordinator sends the output, after appropriate output-to-input translation, to each of the influencees of $i^*$ (if any). If
|
|
|
+the coupled model itself is an influencee of $i^*$, the output, after appropriate output-to-output translation, is sent to the the
|
|
|
+coupled model's parent coordinator.
|
|
|
+
|
|
|
+% TODO: Figure 3
|
|
|
+
|
|
|
+When a coordinator receives an ($x, from, t$) message from its parent coordinator, it routes the message, after appropriate
|
|
|
+input-to-input translation, to each of the affected components.
|
|
|
+
|
|
|
+When an atomic simulator receives an ($x, from, t$) message, it executes the external transition function of its associated atomic
|
|
|
+model.
|
|
|
+
|
|
|
+After processing an ($x, from, t$) or ($y, from, t$) message, a simulator sends a ($done, from, t_N$) message to its parent
|
|
|
+coordinator to prepare a new schedule. When a coordinator has received ($done, from, t_N$) messages from all its components,
|
|
|
+it sets its next-event-time $t_N$ to the minimum $t_N$ of all its components and sends a ($done, from, t_N$) message to its parent
|
|
|
+coordinator. This process is recursively applied until the top-level coordinator or root coordinator receives a ($done, from, t_N$)
|
|
|
+message.
|
|
|
+
|
|
|
+
|
|
|
+As the simulation procedure is synchronous, it does not support asynchronously arriving (real-time) external input. Rather, the
|
|
|
+environment or Experimental Frame should also be modelled as a DEVS component.
|
|
|
+
|
|
|
+To run a simulation experiment, the initial conditions $t_L$ and $s$ must first be set in all simulators of the hierarchy. If $t_N$
|
|
|
+s kept in the simulators, it must be recursively set too. Once the initial conditions are set, the main loop described in Figure
|
|
|
+(TODO) is executed.
|
|
|
+
|
|
|
+
|
|
|
+\section{The pythonDEVS (pyDEVS) simulator}
|
|
|
+In this chapter we first present an implementation of the classical formalism. An early prototype of a DEVS Modeling and Simulation
|
|
|
+Package is then introduced. The chapter then moves on to discuss a real-time execution framework. The motivation behind real-time
|
|
|
+DEVS execution is discussed as well as the implications of 0-time semantics.
|
|
|
+
|
|
|
+\subsection{Design and implementation}
|
|
|
+This version of the DEVS Modeling and Simulation Package has been implemented using Python, an interpreted, very high-level,
|
|
|
+object-oriented programming language. The package consists of two files, the first of which (DEVS.py) provides a class architecture
|
|
|
+that allows hierarchical DEVS models to be easily defined. The simulation engine (SE) itself is implemented in the second file
|
|
|
+(Simulator.py). Based on the DEVS simulator described in (TODO), it uses the same message- passing mechanism. A detailed description
|
|
|
+of both the model architecture and the SE follows.
|
|
|
+
|
|
|
+\subsubsection{Model Architecture}
|
|
|
+The model architecture implemented in DEVS.py is a canvas from which hierarchical DEVS mod- els can be easily described. It consists
|
|
|
+of a number of classes arranged to capture the essence of hierarchical DEVS. A model is described in a dedicated file by deriving
|
|
|
+coupled and/or atomic- DEVS descriptive classes from this architecture. These atomic models are then arranged hierarchically through
|
|
|
+composition. Methods and attributes form the standard interface that allows an SE, such as the one described in the next sub-section,
|
|
|
+to interact with the instantiated DEVS model. Our main concern with the architecture are twofold: remain as consistent as possible
|
|
|
+with the original hierarchical DEVS definition, and maintain a flexible approach to DEVS so as to encourage model reusability
|
|
|
+through parameterization.
|
|
|
+
|
|
|
+The class architecture is represented in Figure (TODO): BaseDEVS is the root class which provides basic functionalities common to both
|
|
|
+atomic and coupled models.
|
|
|
+
|
|
|
+Two classes are inherited from BaseDEVS to deal with the specifics of atomic and coupled DEVS formalisms (Figure (TODO)). These three
|
|
|
+classes are all abstract in that they cannot be directly instantiated. Rather, a model is described by deriving descriptive classes
|
|
|
+from either the AtomicDEVS or the CoupledDEVS class. This provides them with a suitable constructor and overrides the default
|
|
|
+interface methods. Note that the constructors at every level of the class hierarchy have an active role. Hence, a descriptive class'
|
|
|
+constructor should always start by calling the parent class' constructor.
|
|
|
+
|
|
|
+The constructor of the AtomicDEVS class merely initializes the myID attribute and provides a default initial value for the DEVS'
|
|
|
+total state, through the state and elapsed attributes. The remaining class definitions consist of default method declarations for
|
|
|
+the interface functions $\delta_{ext}$ (extTransition), $\delta_{int}$ (intTransition), $ta$ (timeAdvance) and $\lambda$ (outputFnc).
|
|
|
+These methods expect no parameter, and it is up to the modeler to be consistent with the corresponding functions' domain when overriding
|
|
|
+the methods. Except for outputFnc (which uses the poke method as described below), all the methods shall return a value compatible with
|
|
|
+the corresponding function range.
|
|
|
+
|
|
|
+Since default values are provided for both attributes and methods, the minimal atomic-DEVS descriptive class is empty:
|
|
|
+
|
|
|
+% TODO: code
|
|
|
+
|
|
|
+This atomic-DEVS is passive. It remains in its default state forever. A more interesting example is a generator, which sends a message
|
|
|
+(the integer 1 in this case) through its unique output port at a constant time interval:
|
|
|
+
|
|
|
+% TOOD: code
|
|
|
+
|
|
|
+As mentioned above, the outputFnc returns no value; instead it relies on the poke method to send message (second parameter) through the
|
|
|
+OUT output port (first parameter). The companion method, peek, returns the message on the input port that is given as a unique parameter,
|
|
|
+and is used exclusively in the extTransition function. Both poke and peek methods are defined in the AtomicDEVS class, and should not be
|
|
|
+overridden.
|
|
|
+
|
|
|
+The CoupledDEVS class only has one method to override, the tie-breaking select function. This takes a list of sub-models which are in
|
|
|
+conflict. The select function should return the sub-model instance from this list who's transition is to fire next. All a CoupledDEVS
|
|
|
+sub-models should be included by passing their instance variables to the addSubModel function.
|
|
|
+
|
|
|
+Coupling of ports is performed through the connectPorts method. Its first parameter is the source port and the second parameter is the
|
|
|
+destination port. A coupling is rejected and an error message issued if the coupling is invalid.
|
|
|
+
|
|
|
+The source and destination ports are instances of the class Port. This class defines channels where events may pass between DEVS models.
|
|
|
+These channels are defined in the Port's inLine and outLine attributes.
|
|
|
+
|
sampieters
