SP DEVS

History

SP-DEVS has been designed to support verification analysis of its networks by guaranting to obtain a finite-vertex reachability graph of the original networks, which had been an open problem of DEVS formalism for roughly 30 years. To get such a reachability graph of its networks, SP-DEVS has been imposed the three restrictions:

1. finiteness of event sets and state set,
2. the lifespan of a state can be scheduled by a rational number or infinity, and
3. preserving the internal schedule from any external events.

Thus, SP-DEVS is a sub-class of both DEVS and FD-DEVS. These three restrictions lead that SP-DEVS class is closed under coupling even though the number of states are finite. This property enables a finite-vertex graph-based verification for some qualitative properties and quantitative property, even with SP-DEVS coupled models.

Crosswalk Controller Example

Let's consider a crosswalk system. Since a red light (resp. don't-walk light) behaves the opposite way of a green light (resp. walk light), for simplicity, we consider just two lights: a green light (G) and a walk light (W); and one push button as shown in Fig. 1. We want to control two lights of G and W with a set of timing constraints.

To initialize two lights, it takes 0.5 seconds to turn G on and 0.5 seconds later, W gets off. Then, every 30 seconds, there is a chance that G becomes off and W on if someone pushed the push button. For a safety reason, W becomes on two seconds after G got off. 26 seconds later, W gets off and then two seconds later G gets back on. These behaviors repeats.

To build a controller for above requirements, we can consider one input event 'push-button' (abbreviated by ?p) and four output events 'green-on' (!g:1), 'green-off' (!g:0), 'walk-on' (!w:1) and 'walk-off (!w:0) which will be used as commands signals for the green light and the walk light. As a set of states of the controller, we considers 'booting-green' (BG), 'booting-walk' (BW), 'green-on' (G), 'green-to-red' (GR), 'red-on' (R), 'walk-on' (W), 'delay' (D). Let's design the state transitions as shown in Fig. 2. Initially, the controller starts at BG whose lifespan is 0.5 seconds. After the lifespan, it moves to BW state at this moment, it generates the 'green-on' event, too. After 0.5 seconds staying at BW, it moves to G state whose lifespan is 30 seconds. The controller can keep staying at G by looping G to G without generating any output event or can move to GR state when it receives the external input event ?p. But, the actual staying time at GR is the remaining time for looping at G. From GR, it moves to R state with generating an output event !g:0 and its R state last two seconds then it will move to W state with output event !w:1. 26 seconds later, it moves to D state with generating !w:0 and after staying 2 seconds at D, it moves back to G with output event !g:1.

Formal Definition

The above controller for crosswalk lights can be modeled by an atomic SP-DEVS model. Formally, an atomic SP-DEVS is a 7-tuple

where

The above controller shown in Fig. 2 can be written as M =< X , Y , S , s 0 , τ , δ x , δ y > where X ={?p}; Y ={!g:0, !g:1, !w:0, !w:1}; S ={BG, BW, G, GR, R, W, D}; s 0 =BG, τ (BG)=0.5, τ (BW)=0.5, τ (G)=30, τ (GR)=30, τ (R)=2, τ (W)=26, τ (D)=2; δ x (G,?p)=GR, δ x (s,?p)=s if s ≠ G; δ y (BG)=(!g:1, BW), δ y (BW)=(!w:0, G), δ y (G)=( ϕ , G), δ y (GR)=(!g:0, R), δ y (R)=(!w:1, W), δ y (W)=(!w:0, D), δ y (D)=(!g:1, G);

Behaviors of a SP-DEVS model

To captured the dynamics of an atomic SP-DEVS, we need to introduce two variables associated to time. One is the lifespan, the other is the elapsed time since the last resetting. Let t s ∈ Q [ 0 , ∞ ] be the lifespan which is not continuously increasing but set by when a discrete event happens. Let t e ∈ [ 0 , ∞ ] denote the elapsed time which is continuously increasing over time if there is no resetting.

Fig.3. shows a state trajectory associated with an event segment of the SP-DEVS model shown in Fig. 2. The top of Fig.3. shows an event trajectory in which the horizontal axis is a time axis so it shows an event occurs at a certain time, for example, !g:1 occurs at 0.5 and !w:0 at 1.0 time unit, and so on. The bottom of Fig. 3 shows the state trajectory associated with the above event segment in which the state s ∈ S is associated with its lifespan and its elapsed time in the form of ( s , t s , t e ) . For example, (G, 30, 11) denotes that the state is G, its lifespan is and the elapsed time is 11 time units. The line sgements of the buttom of Fig. 3 shows the time flow of the elapsed time which is the only one continuous variable in SP-DEVS.

One interesting feature of SF-DEVS might be the preservation of schedule the restriction (3) of SP-DEVS which is drawn at time 47 in Fig. 3. when the external event ?p happens. At this moment, even though the state can change from G to GR, the elapsed time does not change so the line segment is not broken at time 47 and t e can grow up to t e which is 30 in this example. Due to this preservation of the schedule from input events as well as the restriction of the time advance to the non-negative rational number (see restriction (2) above), the height of every saw can be a non-negative rational number or infinity (as shown in the bottom of Fig. 3.) in a SP-DEVS model.

A SP-DEVS model, M =< X , Y , S , s 0 , τ , δ x , δ y > is DEVS M =< X , Y , S ′ , s 0 ′ , t a , δ e x t , δ i n t , λ > where

Advantages

The property of non-negative rational-valued lifespans which are not changed by input events along with finite numbers of states and events guarantees that the behavior of SP-DEVS networks can be abstracted as an equivalent finite-vertex reachability graph by abstracting the infinitely-many values of the elaped times.

To abstract the infinitely-many cases of elapsed times for each components of SP-DEVS networks, a time-abstraction method, called the time-line abstraction has been introduced [Hwang05],[HCZF07] in which the orders and relative difference of schedules are preserved. By using the time-line abstraction technique, the behavior of any SP-DEVS network can be abstracted as a reachability graph whose numbers of vertices and edges are finite.

As a qualitative property, safety of a SP-DEVS network is decidable by (1) generating the finite-vertex reachability graph of the given network and (2) checking whether some bad states are reachable or not [Hwang05].

As a qualitative property, liveness of a SP-DEVS network is decidable by (1) generating the finite-vertex reachability graph (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[Hwang05].

As a quantitative property, minimum and maximum processing time bounds from two events in SP-DEVS networks can be computed by (1) generating the finite-vertex reachability graph and (2.a) by finding the shortest paths for the minimum processing time bound and (2.b) by finding the longest paths (if available) for the maximum processing time bound [HCZF07].

Disadvantages

Let a total state ( s , t s , t e ) of a SP-DEVS model be passive if t s = ∞ ; otherwise, it be active.

One of known SP-DEVS's limitation is a phenomenon that "once an SP-DEVS model becomes passive, it never returns to become active (OPNA)". This phenomenon was found first at [Hwang 05b] although it was originally called ODNR ("once it dies, it never returns."). The reason why this one happens is because of the restriction (3) above in which no input event can change the schedule so the passive state can not be awaken into the active state.

For example, the toaster models drawn in Fig. 3(b) are not SP-DEVS because the total state associated with "idle" (I), is passive but it moves to an active state, "toast" (T) whose toating time is 20 seconds or 40 seconds. Actually, the model shown in Fig. 3(b) is FD-DEVS.

Tool

There is an open source library, called DEVS# at http://xsy-csharp.sourceforge.net/DEVSsharp/, that supports some algorithms for finding safyness and liveness as well as Min/Max processing time bounds.