Ping-pong game

Fig. 1: FD-DEVS coupled diagram for ping-pong game

Consider a single ping-pong match in which there are two players. Each player can be modeled by FD-DEVS such that the player model has an input event ?receive and an output event !send, and it has two states: Send and Wait. Once the player gets into "Send", it will generates "!send" and go back to "Wait" after the sending time which is 0.1 time unit. When staying at "Wait" and if it gets "?receive", it changes into "Send" again. In other words, the player model stays at "Wait" forever unless it gets "?receive".

To make a complete ping-pong match, one player starts as an offender whose initial state is "Send" and the other starts as a defender whose initial state is "Wait". Thus in Fig. 1. Player A is the initial offender and Player B is the initial defender. In addition, to make the game continue, each player's "?send" event should be coupled to the other player's "?receive" as shown in Fig. 1.

Two-slot toaster

Fig. 2: (a) Two-slot toaster (b) FD-DEVS coupled diagram for two-slot toaster

Consider a toaster in which there are two slots that have their own start knobs as shown in Fig. 2(a). Each slot has the identical functionality except their toasting time. Initially, the knob is not pushed, but if one pushes the knob, the associated slot starts toasting for its toasting time: 20 seconds for the left slot, 40 seconds for the right slot. After the toasting time, each slot and its knobs pop up. Notice that even though one tries to push a knob when its associated slot is toasting, nothing happens.

One can model it with FD-DEVS as shown in Fig. 2(b). Two slots are modeled as atomic FD-DEVS whose input event is "?push" and output event is "!pop", states are "Idle" (I) and "Toast" (T) with the initial state is "idle". When it is "Idle" and receives "?push" (because one pushes the knob), its state changes to "Toast". In other words, it stays at "Idle" forever unless it receives "?push" event. 20 (res. 40) seconds later the left (res. right) slot returns to "Idle".

Formal Definition

$${\displaystyle M=<X,Y,S,s_{0},\tau ,\delta _{x},\delta _{y}>}$$

where

• ${\displaystyle X}$ is a finite set of input events;
• ${\displaystyle Y}$ is a finite set of output events;
• ${\displaystyle S}$ is a finite set of states;
• ${\displaystyle s_{0}\in S}$ is the initial state;
• ${\displaystyle \tau :S\rightarrow \mathbb {Q} _{[0,\infty ]}}$ is the time advance function which defines the lifespan of a state where ${\displaystyle \mathbb {Q} _{[0,\infty ]}}$ is the set of non-negative rational numbers plus infinity.
• ${\displaystyle \delta _{x}:S\times X\rightarrow S\times \{0,1\}}$ is the external transition function which defines how an input event changes the schedule as well as a state of the system. The internal schedule of a state ${\displaystyle s\in S}$ is updated by ${\displaystyle \tau (s')}$ if ${\displaystyle \delta _{x}(s)=(s',1)}$, otherwise(i.e., ${\displaystyle \delta _{x}(s)=(s',0)}$), the schedule is preserved.^[1]
• ${\displaystyle \delta _{y}:S\rightarrow Y^{\phi }\times S}$ is the output and internal transition function where ${\displaystyle Y^{\phi }=Y\cup \{\phi \}}$ and ${\displaystyle \phi \notin Y}$ denotes the silent event. The output and internal transition function defines how a state generates an output event, at the same time, how the state changes internally.^[2]

Formal Representation of Ping-Pong Player

The formal representation of the player in the ping-pong example shown in Fig. 1 can be given as follows. ${\displaystyle M=<X,Y,S,s_{0},\tau ,\delta _{x},\delta _{y}>}$ where ${\displaystyle X}$={?receive}; ${\displaystyle Y}$={!send}; ${\displaystyle S}$={Send, Wait}; ${\displaystyle s_{0}}$=Send for Player A, Wait for Player B; ${\displaystyle \tau }$(Send)=0.1,${\displaystyle \tau }$(Wait)=${\displaystyle \infty }$; ${\displaystyle \delta _{x}}$(Wait,?receive)=(Send,1), ${\displaystyle \delta _{x}}$(Send,?receive)=(Send,0); ${\displaystyle \delta _{y}}$(Send)=(!send, Wait), ${\displaystyle \delta _{y}}$(Wait)=(${\displaystyle \phi }$, Wait).

Formal Representation of One Slot Toaster

The formal representation of the slot of Two-slot Toaster Fig. 2(a) and (b) can be given as follows. ${\displaystyle M=<X,Y,S,s_{0},\tau ,\delta _{x},\delta _{y}>}$ where ${\displaystyle X}$={?push}; ${\displaystyle Y}$={!pop}; ${\displaystyle S}$={I, T}; ${\displaystyle s_{0}}$=I; ${\displaystyle \tau }$(T)=20 for the left slot, 40 for the right slot, ${\displaystyle \tau }$(I)=${\displaystyle \infty }$; ${\displaystyle \delta _{x}}$(I, ?push)=(T,1), ${\displaystyle \delta _{x}}$(T,?push)=(T,0); ${\displaystyle \delta _{y}}$(T)=(!pop, I), ${\displaystyle \delta _{y}}$(I)=(${\displaystyle \phi }$, I).

Formal Representation of Crosswalk Light Controller

As mentioned above, FD-DEVS is an relaxation of SP-DEVS. That means, FD-DEVS is a supper class of SP-DEVS. We would give a model of FD-DEVS of a crosswalk light controller which is used for SP-DEVS in this Wikipedia. ${\displaystyle M=<X,Y,S,s_{0},\tau ,\delta _{x},\delta _{y}>}$ where ${\displaystyle X}$={?p}; ${\displaystyle Y}$={!g:0, !g:1, !w:0, !w:1}; ${\displaystyle S}$={BG, BW, G, GR, R, W, D}; ${\displaystyle s_{0}}$=BG, ${\displaystyle \tau }$(BG)=0.5,${\displaystyle \tau }$(BW)=0.5, ${\displaystyle \tau }$(G)=30, ${\displaystyle \tau }$(GR)=30,${\displaystyle \tau }$(R)=2, ${\displaystyle \tau }$(W)=26, ${\displaystyle \tau }$(D)=2; ${\displaystyle \delta _{x}}$(G,?p)=(GR,0), ${\displaystyle \delta _{x}}$(s,?p)=(s,0) if s ${\displaystyle \neq }$G; ${\displaystyle \delta _{y}}$(BG)=(!g:1, BW), ${\displaystyle \delta _{y}}$(BW)=(!w:0, G),${\displaystyle \delta _{y}}$(G)=(${\displaystyle \phi }$, G), ${\displaystyle \delta _{y}}$(GR)=(!g:0, R), ${\displaystyle \delta _{y}}$(R)=(!w:1, W), ${\displaystyle \delta _{y}}$(W)=(!w:0, D), ${\displaystyle \delta _{y}}$(D)=(!g:1, G);

Behaviors of FD-DEVS Models

Fig. 3. an Event Segment and a State Trajectory of Player A

FD-DEVS is a sub-class of DEVS

A FD-DEVS model, ${\displaystyle M=<X,Y,S,s_{0},\tau ,\delta _{x},\delta _{y}>}$ is DEVS ${\displaystyle {\mathcal {M}}=<X,Y,S',s_{0}',ta,\delta _{ext},\delta _{int},\lambda >}$ where

• ${\displaystyle X,Y}$ of ${\displaystyle {\mathcal {M}}}$ are the same as those of ${\displaystyle M}$.
• ${\displaystyle S'=\{(s,t_{s}):s\in S,t_{s}\in \mathbb {T} ^{\infty }\}}$
• ${\displaystyle s_{0}'=(s_{0},\tau (s_{0}))}$
• Given a state ${\displaystyle (s,t_{s})\in S'}$, ${\displaystyle ta(s,t_{s})=t_{s}.}$
• Given a state ${\displaystyle (s,t_{s})\in S'}$ and an input event ${\displaystyle x\in X}$,

${\displaystyle \delta _{ext}(s,t_{s},t_{e},x)={\begin{cases}(s',t_{s}-t_{e})&{\text{if }}\delta _{x}(s,x)=(s',0)\\(s',\tau (s'))&{\text{if }}\delta _{x}(s,x)=(s',1)\\\end{cases}}}$

• Given a state ${\displaystyle (s,t_{s})\in S'}$, ${\displaystyle \delta _{int}(s,t_{s})=(s',\tau (s'))}$ if ${\displaystyle \delta _{y}(s)=(y,s').}$
• Given a state ${\displaystyle (s,t_{s})\in S'}$, ${\displaystyle \lambda (s,t_{s})=y}$ if ${\displaystyle \delta _{y}(s)=(y,s').}$

For details of DEVS behavior, the readers can refer to Behavior of Atomic DEVS

Behavior of Ping-Pong Player A

Fig. 3. shows an event segment (top) and the associated state trajectory (bottom) of Player A who plays the ping-pong game introduced in Fig. 1. In Fig. 3. the status of Player A is described as (state, lifespan, elapsed time)=(${\displaystyle s,t_{s},t_{e}}$) and the line segment of the bottom of Fig. 3. denotes the value of the elapsed time. Since the initial state of Player A is "Send" and its lifetime is 0.1 seconds, the height of (Send, 0.1, ${\displaystyle t_{e}}$) is 0.1 which is the value of ${\displaystyle t_{s}}$. After changing into (Wait, inf,^[3] 0) when ${\displaystyle t_{e}}$ is reset by 0, Player A doesn't know when ${\displaystyle t_{e}}$ becomes 0 again. However, since Player B sends back the ball to Player A 0.1 second later, Player A gets back to (Send, 0.1 0) at time 0.2. From that time, 0.1 seconds later when Player A's status becomes (Send, 0.1, 0.1), Player A sends back the ball to Player B and gets into (Wait, inf, 0). Thus, this cyclic state transitions which move "Send" to "Wait" back and forth will go forever.

Fig. 4. an Event Segment and a State Trajectory of a Toaster

Behavior of a Toaster

Fig. 4. shows an event segment (top) and the associated state trajectory (bottom) of the left slot of the two-slot toaster introduced in Fig. 2. Like Fig.3, the status of the left slot is described as (state, lifespan, elapsed time)=(${\displaystyle s,t_{s},t_{e}}$) in Fig. 4. Since the initial state of the toaster is "I" and its lifetime is infinity, the height of (Wait, inf, ${\displaystyle t_{e}}$) can be determined by when ?push occurs. Fig. 4. illustrates the case ?push happens at time 40 and the toaster changes into (T, 20, 0). From that time, 20 seconds later when its status becomes (T, 20, 20), the toaster gets back to (Wait, inf, 0) where we don't know when it gets back to "Toast" again. Fig. 4. shows the case that ?push occurs at time 90 so the toaster get into (T,20,0). Notice that even though there someone push again at time 97, that status (T, 20, 7) doesn't change at all because ${\displaystyle \delta _{x}}$(T,?push)=(T,1).

Applicability of Time-Zone Abstraction

The property of non-negative rational-valued lifespans which can be preserved or changed by input events along with finite numbers of states and events guarantees that the behavior of FD-DEVS networks can be abstracted as an equivalent finite-vertex reachability graph by abstracting the infinitely-many values of the elapsed times using the time abstracting technique introduced by Prof. D. Dill [Dill89]. An algorithm generating a finite-vertex reachability graph (RG)has been introduced in [HZ06a], [HZ07].

Reachability Graph

Fig. 5. shows the reachability graph of two-slot toaster which was shown in Fig. 2. In the reachability graph, each vertex has its own discrete state and time zone which are ranges of ${\displaystyle t_{e1},t_{e2}}$ and ${\displaystyle t_{e1}-t_{e2}}$. For example, for node (6) of Fig. 5, discrete state information is ((E,${\displaystyle \infty }$),(T,40)), and time zone is ${\displaystyle 0\leq t_{e1}\leq 40,0\leq t_{e2}\leq 40,-20\leq t_{e1}-t_{21}\leq 0}$. Each directed arch shows how its source vertex changes into the destination vertex along with an associated event and a set of reset models. For example, the transition arc (6) to (5) is triggered by push1 event. At that time, the set {1} of the arc denotes that elapsed time of 1 (that is ${\displaystyle t_{e1}}$ is reset by 0 when transition (6) to (5) occurs. For more detailed information, the reader can refer to [HZ07].

Decidability of Safety

As a qualitative property, safety of a FD-DEVS network is decidable by (1) generating RG of the given network and (2) checking whether some bad states are reachable or not [HZ06b].

Decidability of Liveness

As a qualitative property, liveness of a FD-DEVS network is decidable by (1) generating RG of the given network, (2) from RG, generating kernel directed acyclic graph (KDAG) in which a vertex is strongly connected component, and (3) checking if a vertex of KDAG contains a state transition cycle which contains a set of liveness states[HZ06b].

Weak Expressiveness for describing nondeterminism

The features that all characteristic functions,${\displaystyle \tau ,\delta _{x},\delta _{y}}$ of FD-DEVS are deterministic can be seen as somehow a limitation to model the system that has non-deterministic behaviors. For example, if a player of the ping-pong game shown in Fig. 1. has a stochastic lifespan at "Send" state, FD-DEVS doesn't capture the non-determinism effectively.

For Verification

There are two open source libraries DEVS# written in C# at http://xsy-csharp.sourceforge.net/DEVSsharp/ and XSY written in Python at https://code.google.com/p/x-s-y/ that support some reachability graph-based verification algorithms for finding safeness and liveness.

For Simulation via XML

For standardization of DEVS, especially using FDDEVS, Dr. Saurabh Mittal together with co-workers has worked on defining of XML format of FDDEVS. We can find an article at http://www.duniptechnologies.com/research/xfddevs/. This standard XML format was used for UML execution [RCMZ09] .