A State-Based Programming Model for Wireless Sensor Networks

3.5. Overview and Examples of State-of-the-Art Operating Systems 57
ating systems and programming frameworks today. Since its introduction in
2000, TinyOS has gained significant impact, possibly because of the success in
the commercialization of its standard hardware platform, the Berkeley Motes.
The early availability of the complementary combination of the freely available
and well-supported programming framework and sensor-node hardware
has made experimentation accessible to researchers without embedded systems
background and without capabilities to develop and manufacture their own
hardware.
TinyOS targets resource-constrained sensor nodes and has been implemented
on the Berkeley Mote family as well as other sensor nodes, such as the
BTnode [78]. Its goal is to provide standard sensor-node services in a modular
and reusable fashion. TinyOS has a component-oriented architecture based
on an event-driven kernel. System services (such as multi-hop routing, sensor
access, and sensor aggregation) are implemented as a set of components with
well-defined interfaces. Application programs are also implemented as a set
of components. TinyOS components are programmed in a custom C dialect
(called nesC), requiring a special compiler for development. A simple declarative
language is used to connect these components in order to construct more
complex components or entire applications. The designers of TinyOS consider it
a static language, as it supports neither dynamic-memory allocation, nor process
concurrency or dynamic loading. (It does, however, provide static over-the-air
reprogramming).
TinyOS has an event-driven programming model. However, it has two levels
of scheduling, rather than just one, as all other event-driven programming
frameworks for sensor nodes. The scheduled entities are called tasks and events.
This terminology is highly confusing: TinyOS tasks have no similarities to tasks
in multi-tasking systems. Rather, a TinyOS task is what in event-driven systems
is commonly known as an action or event handler. TinyOS tasks are scheduled
sequentially by the scheduler and run to completion only with respect to other
TinyOS tasks. They may be interrupted, however, by TinyOS events.
A TinyOS event is not what is commonly considered an event in the eventdriven
systems (i.e., a condition triggering an action). Rather, it is a timecritical
computational function that may interrupt the regular control flow
within TinyOS tasks as well as other TinyOS events. TinyOS events have been
introduced so that a small amount of processing associated with hardware interrupts
can be performed as fast as possible, without scheduling overhead but
instead interrupting long-running tasks. TinyOS events are required to complete
as fast as possible, in order not to delay any other time-critical TinyOS events.
As such, TinyOS events are programming abstractions for interrupt service routines.
Apart from being triggered by hardware interrupts, TinyOS events can
also be invoked by regular code. Then they behave like regular functions.
Besides, TinyOS tasks and TinyOS events, TinyOS has a third programmatic
entity, called commands. TinyOS commands resemble functions of sequential
programming languages but have certain restrictions (e.g., they may not invoke
TinyOS events).
TinyOS applications can have a graph-like structure of components but are
often hierarchical. Each component has a well-defined interface that can be used
to interconnect multiple components to construct more complex components