SP-DEVS


SP-DEVS

SP-DEVS abbreviating ``Schedule-Preserving Discrete Event System Specification`` is a formalism for modeling and analyzing discrete event systems in both simulation and verification ways. SP-DEVS also provides modular and hierarchical modeling features which have been inherited from the Classic 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:
# finiteness of event sets and state set,
# the lifespan of a state can be scheduled by a rational number or infinity, and
# 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

;System RequirementsLet'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 the some timing constraints.

To initilize 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.

;Controller DesignTo 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. Initillay, 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.

Atomic SP-DEVS

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 M=

where


* X is "a finite set of input events";
* Y is "a finite set of output events";
* S is "a finite set of states";
* s_0 in S is "the initial state";
* au: S ightarrow mathbb{Q}_{ [0,infty] } is "the time advanced function" which defines the lifespan of a state where mathbb{Q}_{ [0,infty] } is the set of non-negative rational numbers plus infinity.
* delta_x: S imes X ightarrow S is "the external transition function" which defines how an input event changes a state of the system.
* delta_y: S ightarrow Y^phi imes S is "the output and internal transition function" where Y^phi = Y cup {phi} and phi otin 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 [ delta_y can be divided into two functions: lambda: S ightarrow Y^phi and delta_{int}:S ightarrow S as in [SP-DEVS#References| [ZKP00] .] .

;Formal Representation of Crosswalk Controller The above controller shown in Fig. 2 can be written as M= where X={?p}; Y={!g:0, !g:1, !w:0, !w:1}; S={BG, BW, G, GR, R, W, D}; s_0=BG, au(BG)=0.5, au(BW)=0.5, au(G)=30, au(GR)=30, au(R)=2, au(W)=26, au(D)=2; delta_x(G,?p)=GR, delta_x(s,?p)=s if s eqG; delta_y(BG)=(!g:1, BW), delta_y(BW)=(!w:0, G),delta_y(G)=( phi, G), delta_y(GR)=(!g:0, R), delta_y(R)=(!w:1, W), delta_y(W)=(!w:0, D), delta_y(D)=(!g:1, G);

Total State Transition

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 in mathbb{Q}_{ [0,infty] } be the lifespan which is not continuously increasing but set by when a discrete event happens. Let t_e in [0, infty] 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 in 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.

; Formal Definition of Total State TransitionAs mentioned above, to described the timed behavior of SP-DEVS we need to introduced two variables of associated with time: the lifespan t_s of a state and the elapsed time t_e since the last schedule update. As mentioned earlier, the output and internal state transition delta_y can be executed when the elapsed time becomes to be equal to the lifespan of a state, i.e. t_e = t_s . That means, the execution of delta_y is impossible when t_e e t_s .

Let Q_p={(s, t_s, t_e)| s in S, t_s in mathbb{Q}_{ [0, infty] }, t_e in [0, t_s] } be "the legal state set" while Q_{imp}={(imp, infty, t_e)| imp otin S, t_e in [0, infty) } be the "the illegal state set". Let Q = Q_p cup Q_{imp} denote the "total state set". and Z = X cup Y^phi denote the "total event set".

Then the total state transition is defined as a function delta: Q imes Z ightarrow Q such that for q=(s, t_s, t_e) in Q and z in Z ,
delta(q, z) =egin{cases} (s', t_s, t_e) & extrm{if } s in S, z in X, delta_x (s, z) = s' \ (s', au(s), 0) & extrm{if } s in S, z in Y^phi, t_e = t_s, delta_y (s) = (z, s') \ (imp, infty, t_s) & extrm{otherwise }end{cases}

Advantages

* Applicability of Time-Line AbstractionThe 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 [SP-DEVS#References| [Hwang05] , [SP-DEVS#References| [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.

* Decidablility of Safety 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 [SP-DEVS#References| [Hwang05] .

* Decidablility of LivenessAs 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 [SP-DEVS#References| [Sedgewick02] , and (3) checking if a vertex of KDAG contains a state transition cycle which contains a set of liveness states [SP-DEVS#References| [Hwang05] .

* Decidablility of Min/Max Processing Time BoundsAs 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 [SP-DEVS#References| [HCZF07] .

Disadvantages

* Less Expressiveness: OPNA problem Let a total state (s,t_s,t_e) of a SP-DEVS model be "passive" if t_s = infty ; 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 phenomena was found first at [SP-DEVS#References| [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.

Footnotes

References

* [Hwang05] M. H. Hwang, ``Tutorial: Verification of Real-time System Based on Schedule-Preserved DEVS``, Proceedings of 2005 DEVS Symposium, San Diego, Apr. 2-8, 2005, ISBN 1-56555-290-8 (Available at http://www.u.arizona.edu/~mhhwang)
* [Hwang05b] M. H. Hwang, ``Generating Finite-State Global Behavior of Reconfigurable Automation Systems: DEVS Approach``, "Proceedings of 2005 IEEE-CASE", Edmonton, Canada, Aug. 1-2, 2005 (Available at http://www.u.arizona.edu/~mhhwang)
* [HCZF07] M. H. Hwang, S.K. Cho, B.P. Zeigler, and F. Lin, ``Processing Time Bounds of Schedule-Preserving DEVS``, ACIMS Technical Report, 2007, (Available at http://www.acims.arizona.edu and http://moonho.hwang.googlepages.com/publications)
* [Sedgewick02] , R. Sedgewick, "Algorithms in C++, Part 5 Graph Algorithm", Addison Wesley, Boston, third edition
* [ZKP00] cite book|author = Bernard Zeigler, Tag Gon Kim, Herbert Praehofer| year = 2000| title = Theory of Modeling and Simulation| publisher = Academic Press, New York | id= ISBN 978-0127784557 |edition=second


Wikimedia Foundation. 2010.

Look at other dictionaries:

  • DEVS — abbreviating Discrete Event System Specification is a modular and hierarchical formalism for modeling and analyzing general systems that can be discrete event systems which might be described by state transition tables, and continuous state… …   Wikipedia

  • DEVS — Saltar a navegación, búsqueda DEVS es un acrónimo del inglés para referirse a Discrete Event System Specification (Especificación de Sistemas de Eventos Discretos). El término es ahora estándar en el campo de la Simulación para referirse a un… …   Wikipedia Español

  • Devs Fidivs — DEVS FIDIVS, sieh Fidius …   Gründliches mythologisches Lexikon

  • DEVS — Discrete Event System Specification DEVS (de l anglais Discrete Event System Specification) est un formalisme modulaire et hiérarchique pour la modélisation, la simulation et l analyse de systèmes complexes qui peuvent être des systèmes à… …   Wikipédia en Français

  • Devs Iratvs — Infobox Album | Name = Devs Iratvs Type = Album Artist = Arthemesia Released = 2001 Recorded = Genre = Melodic black metal Length = 46:56 Label = Native North Records Producer = Reviews = Last album = The Archaic Dreamer (1999) This album = Devs… …   Wikipedia

  • Devs — Div Pour les articles homonymes, voir DIV. Un div est un esprit maléfique de la mythologie iranienne qui aime causer la douleur et la destruction. Le terme signifie littéralement démon . Leur chef est Ahriman. Leurs opposants sont les Izeds ou… …   Wikipédia en Français

  • DEVS — Ziynet etmek, süslemek. * Bir şeyi ayağı ile basıp çiğnemek …   Yeni Lügat Türkçe Sözlük

  • DEVŞ — Fâsid olmak …   Yeni Lügat Türkçe Sözlük

  • Behavior of DEVS — Behaviors of a given DEVS model is a set of sequences of timed events including null events, called event segments which make the model move one state to another within a set of legal states. To define this way, the concept of a set of illegal… …   Wikipedia

  • Bonvs Devs — BONVS DEVS, Gr. Ἀγαθὸς δεὸς, ου, war ein Gott der Arkadier, dessen Tempel am Wege nach dem Berge Mänalus zu stund. Pausan. Arcad. 26 …   Gründliches mythologisches Lexikon