A State-Based Programming Model for Wireless Sensor Networks
A State-Based Programming Model for Wireless Sensor Networks
A State-Based Programming Model for Wireless Sensor Networks
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
90 Chapter 5. The Object-<strong>State</strong> <strong>Model</strong><br />
5.4 Parallel Composition<br />
An important element of OSM is the support <strong>for</strong> parallel state machines. In a<br />
parallel composition of multiple flat state machines, multiple states are active at<br />
the same time, exactly one <strong>for</strong> every parallel machine. Let us consider an example<br />
of two parallel state machines, as depicted in Fig. 5.6. (This parallel machine<br />
is the flat state machine from Fig. 5.1 composed in parallel with a copy of the<br />
same machine where state and variable names are primed.) At every discrete<br />
time, this state machine can assume one out of 9 possible state constellations<br />
with two active states each—one <strong>for</strong> each parallel machine. These constellations<br />
are A|A ′ , A|B ′ , A|C ′ , B|A ′ , B|B and so <strong>for</strong>th, where A|A ′ is the initial state constellation.<br />
For simplicity we sometimes say A|A ′ is the initial state.<br />
Parallel state machines can handle events originating from independent<br />
sources. For example, independently tracked targets could be handled by parallel<br />
state machines. While events are typically triggered by real-world phenomena<br />
(e.g., a tracked object appears or disappears), events may also be emitted by<br />
the actions of a state machine to support loosely-coupled cooperation of parallel<br />
state machines.<br />
Besides this loose coupling, parallel state machines can be synchronized in the<br />
sense that state transitions of concurrent machines can occur concurrently in the<br />
discrete time model. In the real-time model, however, the state transitions and<br />
associated actions are per<strong>for</strong>med sequentially.<br />
A<br />
outA() inB()<br />
B<br />
outB() inC()<br />
int varA e int varB<br />
f<br />
A’<br />
outA’() inB’()<br />
B’<br />
outB’() inC’()<br />
int varA’ e int varB’<br />
f<br />
C<br />
int varC<br />
C’<br />
int varC’<br />
Figure 5.6: A parallel composition of two flat state machines.<br />
The parallel state machines of Fig. 5.6 are synchronized through events e and<br />
f, which trigger transitions in both concurrent machines. Fig. 5.7 shows the<br />
mapping of real-time to discrete time at discrete time t = 1. After discrete time<br />
has progressed to t = 1 on the occurrence of e, all entry actions are executed in<br />
any order. When event f arrives, all exit actions are per<strong>for</strong>med in any order.<br />
5.4.1 Concurrent Events<br />
Up to now, each event has been considered independently. However, in the<br />
discrete time model, events can occur concurrently when concurrent machines<br />
programmatically emit events in a synchronized step. For example, when parallel<br />
state machines emit events in exit actions when simultaneously progressing<br />
from time t = 1 to t = 2 (see Fig. 5.7), the emitted events have no canonical order.<br />
The event queue should preserve such unordered sets of concurrent events,<br />
rather than imposing an artificial total ordering on concurrent events by inserting<br />
them one after another into the queue. For this purpose, the event queue