A State-Based Programming Model for Wireless Sensor Networks

6.2. OSM Language Mapping 107
Adding Entry Actions and Transitions
When incarnating a state, transitions, entry actions, exit actions, and preemption
actions can be added to the original state definition. Adding transitions and actions
to the original state definition is typically used when the program context
of the incarnation is not known at implementation time. In Prog. 6.4, A is the
incarnation of template I. In I there are no outgoing transitions defined. In I’s
incarnation A, however, a transition is added leading from A to B (line 18). Also,
an incoming action inA(u) is added to the transition from B back to A (line 17).
Adding Preemption Actions
When incarnating a state, preemption actions can be added to the original state
definition. Preemption actions can be added to react to the termination of the
incarnation’s superstate. Adding preemption actions is useful, for example, to
include an existing stand-alone program as a sub-phase of a new, more complex
program. In our example Prog. 6.4 there are no preemption actions added to the
incarnations of either states, since their common superstate P ROG_4 is never
left.
6.2 OSM Language Mapping
An OSM language mapping defines how OSM specifications are translated into
a host language. The host language is also used for specifying actions. Such a
mapping is implemented by an OSM compiler. For every host language, there
must be at least one language mapping. Yet, there may be multiple mappings
focusing on different aspects, such as optimizations of code size, RAM requirements,
execution speed, and the like. We have developed a prototypical version
of an OSM compiler that uses C as a host language. Hence, we discuss how
OSM can be mapped to C in the following sections. The main goal of our compiler
prototype is to create executable OSM programs that
• have low and predictable memory requirements and
• are executable on memory-efficient sensor-node operating systems.
In general, OSM programmers do not need to know the details of how OSM
programs are mapped to executable code. What they do need to know, however,
is how actions in OSM are mapped to functions of the host language. Programmers
need to provide implementations of all actions declared in OSM, and thus
need to know their exact signature.
Internally, and typically transparently to the developer, our compiler prototype
maps the control structure and state variables of OSM programs separately.
State variables are mapped to a static in-memory representation using
C-language structs and unions. This mapping requires no dynamic memory
management and is independent of the mapping of the control structure.
Yet it is memory efficient, as state variables with non-overlapping lifetimes are
mapped to overlapping memory regions. Also, the size of the in-memory representation
of all state variables is determined at compile time.