21.08.2013 Views

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

SHOW MORE
SHOW LESS

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!