trol: is the augmented state observable to an external decision-maker? In other words: will it be possible to re-use the results known for Markov or semi-Markov decision processes in order to control GSMPs with action choice? Will we have a guarantee of an optimal Markov policy? We leave this question for the next chapter but already underline the fact that in most practical cases, only the natural state of the process is observable and the clocks are generally unknown. A simple example to illustrate this fact is the “roads crossing” example: suppose the agent is a car driver arriving at a multiple crossing with traffic lights, he can observe the current natural state of the process (the lights) but cannot predict which one will turn green first because he cannot observe the individual processes’ clocks.
Figure 11.2: Hard to predict which will turn green first.(Picture credit: http://www.greenwichup.org.uk)
Finally, GMSPs seem to be an elegant, compact and efficient way of describing the complexity of temporal stochastic processes, especially if we include time as an observable continuous state variable. We will focus on this last point in the next chapter also, as we will introduce time and action choice alltogether in the problem. For now, we remain in the discrete event dynamic systems modeling problematic and try to make a link between GSMPs and the general DEVS modeling framework.
11.3
DEVS modeling
11.3.1 Five levels of Discrete Events Systems Specification
In [Zeigler, 1976], B. P. Zeigler proposes to describe the notion of system through a formal specification. This formal specification depends on the level of refinement in the system’s description. He describes five levels of description going from uninterpreted input-output system specification to a complete specification of the system dynamics through the notions of internal state, internal transition function, external transition function and model cou- pling. These levels of specification rely heavily on the notion of discrete event system. He applies the fifth (and most detailed) level of specification to isolate the core components of a discrete event system and design the Discrete EVent system Specification (DEVS) framework
Chapter 11. Concurrency: an origin for complexity
which is built to capture the modeling of any discrete event system.
Discrete event systems find an expression through different formalisms such as finite au- tomata, Petri nets, state charts, cellular automata or stochastic processes for instance. Many of these formalisms have been studied and mapped to the DEVS framework. This makes DEVS more than a high-level description of the behaviour of discrete event systems: it cap- tures the notion of consistent multi-modeling and of models integration. Consequently, it provides a sound theoretical basis for the study of discrete event systems modeling, coupling and simulation.
We use this section to introduce the basic notions of DEVS modeling in order to write GSMPs as DEVS models in the next section. This presentation is a pragmatic view of DEVS modeling, for a more formal presentation and a more detailed description, please see [Zeigler, 1976] and [Zeigler et al., 2000].
11.3.2 Atomic models
DEVS models are composed of atomic models describing independent processes, eventually coupled together through a hierarchical notion of coupled models. The idea of DEVS mod- eling is to capture the basic elements of a discrete event system’s behaviour through the minimal concepts of evolution functions and variables. The atomic DEVS model builds on the idea of the black box having input and output ports.
Definition (Atomic DEVS model, [Zeigler, 1976]). An atomic DEVS model is described by the 8-tuplehX, Y, S, δext, δint, δcon, λ, tai:
• X, a set of input ports and their associated value domains, • Y , a set of output ports and values,
• S, a set of internal states,
• δext : S × X → S, an external transition function, describing the evolution of the
model’s internal state when an external event occurs on one of the input ports, • δint : S → S, an internal transition function, describing the natural evolution of the
model’s internal state,
• δcon : S × X → S, a transition conflict function, specifying the behaviour in case of a
conflict between an internal and an external event (usually chooses to useδint or δext), • λ : S → Y , an output function, updating the values on the output ports,
• ta : S → R+, a “time advance” function, used to schedule the time of the next transi-
tion to a new internal state.
A port-based DEVS model can be represented as on figure 11.3.
It is important to lift the terminology ambiguity between DEVS external and internal events and GSMP events. DEVS internal events correspond to changes inside an atomic model. DEVS external events can be seen as messages, travelling between DEVS models.
11.3. DEVS modeling
model M
pin n, vnin . . . pin 0 , v0inX
M pout m , vmout . . . pout 0 , v0outY
MFigure 11.3: DEVS atomic model with ports
They are events that are emitted towards the other models, thus allowing model coupling. Hence, these events correspond to changes on the input ports of connected models. GSMP events are somehow a miscalling: they point to distinct processes triggering the discrete events that condition the evolution of the global system.
The temporal execution of a DEVS model can be described as follows. Initially, model M is in an internal state s ∈ SM. The ta function is called to determine how long the system
should remain in this state. If no external event arrives on an input port, at time ta(s), the δintfunction is called and the system evolves to state s0 = δint(s). Then the output function
λ is called and the output ports Y are set to the value of λ(s). ta is called again to find the next undisturbed transition date ta(s0). If an exogenous event with a vector v of values
occurs in XM before time ta(s0), then the model’s state changes according to δext. The next
state is s00= δext(s0, v). The output function is not called since there was no internal transi-
tion and the ta function is immediately called to get the new undisturbed transition time for the model ta(s00). If no other exogenous event has occurred at ta(s00), then, as previously, δint
determines the next step of the process, λ sets the output ports’ values and ta is called again. Since DEVS models are event-driven models, they do not rely on a notion of synchroniza- tion on a common time. Therefore, there is no notion of time step and the models evolutions are asynchronous (they are simply coupled through the emission and reception of events). However, in order to define a sound behaviour, one has to plan the possibility of an external event arriving exactly at the transition time specified by ta. In this case, the δcon function
resolves the conflict: δcon(s, v) determines the new state (usually by choosing to call either
δint or δext)1. Similarly to δext, when δcon is called, the output function is not called (this
behaviour can be regained by introducing intermediate volatile states).
This describes the individual behaviour of an atomic DEVS model. But the DEVS framework is also meant to authorize the parallel execution and interaction of several dif- ferent models. This is where the multimodeling problematic arises: sometimes one needs to represent the discrete event process resulting from different processes where each can be specified in a different formalism (for instance, one could be described as a Petri net, an- other as a discrete time differential equation and a third as a cellular automata). Interfacing all these models in the DEVS framework corresponds to introducing the notion of coupling between models.
1It is important to note that defining the δ
con function as a function of the internal state s and the input
port values v allows to consider several external events and one internal event occurring at the same time, thus guaranteeing the behaviour’s consistency even with multiple concurrent DEVS events. The same remark holds for δext.
Chapter 11. Concurrency: an origin for complexity
11.3.3 Coupled models
A coupled DEVS model defines how individual models are coupled together in order to form a high-level macro-model. This macro-model can itself be part of a coupled model, etc.
In a coupled model (also called “network of models”), there is no additional notion of state than the abstract aggregate state of all individual models and these states remain pri- vate to each model. We provide a general definition of a coupled DEVS model. For a more formal definition, see [Zeigler et al., 2000].
Definition (Coupled DEVS model, [Zeigler et al., 2000]). A coupled DEVS model is given by:
• a set of models,
• a set of input ports collecting incoming external events, • a set of output ports emitting events,
• a set of connections between the coupled model’s input and output ports and the indi- vidual model’s input and output ports.
Graphically, one can represent a coupled model as on figure 11.4.
in out1 out2 A in1 in2 out B in out
Figure 11.4: Coupled DEVS model
A lot of extensions to DEVS modeling have been developed during the last thirty years as, for instance, Cell-DEVS, which establishes a direct mapping from cellular automata to DEVS models, or DS-DEVS, allowing dynamic structure change in coupled DEVS models.
One can make a strong parallel between DEVS modeling and discrete-time asynchronous multi-agent modeling since an atomic DEVS model can be seen as an autonomous entity, owning a private state and sharing information with other models through events in a network of local connections between models. This actually highlights the main feature that will be problematic in the next section: a model’s state is internal to the model and cannot be shared without emitting events, even for coupled models.