7.3 Node-Level Software Platforms 247
In the rest of the chapter, we give several examples of sensor
network software design platforms. We discuss them in terms of
both design methodologies and design platforms. A design methodo-
logy implies a conceptual model for programmers, with associated
techniques for problem decomposition for the software designers.
For example, does the programmer think in terms of events, message
passing, and synchronization, or does he/she focus more on informa-
tion architecture and data semantics? A design platform supports a
design methodology by providing design-time (precompile time) lan-
guage constructs and restrictions, and run-time (postcompile time)
There is no single universal design methodology for all applica-
tions. Depending on the speciﬁc tasks of a sensor network and the
way the sensor nodes are organized, certain methodologies and plat-
forms may be better choices than others. For example, if the network
is used for monitoring a small set of phenomena and the sensor nodes
are organized in a simple star topology, then a client-server software
model would be sufﬁcient. If the network is used for monitoring a
large area from a single access point (i.e., the base station), and if user
queries can be decoupled into aggregations of sensor readings from a
subset of sensor nodes, then a tree structure that is rooted at the base
station is a better choice. However, if the phenomena to be moni-
tored are moving targets, as in the target tracking examples discussed
in Chapter 2, then neither the simple client-server model nor the tree
organization is optimal. More sophisticated design methodologies
and platforms are required.
7.3 Node-Level Software Platforms
Most design methodologies for sensor network software are node-
centric, where programmers think in terms of how a node should
behave in the environment. A node-level platform can be a node-
centric operating system, which provides hardware and networking
abstractions of a sensor node to programmers, or it can be a language
platform, which provides a library of components to programmers.
248 Chapter 7 Sensor Network Platforms and Tools
A typical operating system abstracts the hardware platform by pro-
viding a set of services for applications, including ﬁle management,
memory allocation, task scheduling, peripheral device drivers, and
networking. For embedded systems, due to their highly specialized
applications and limited resources, their operating systems make dif-
ferent trade-offs when providing these services. For example, if there
is no ﬁle management requirement, then a ﬁle system is obviously
not needed. If there is no dynamic memory allocation, then mem-
ory management can be simpliﬁed. If prioritization among tasks is
critical, then a more elaborate priority scheduling mechanism may
TinyOS  and TinyGALS  are two representative examples of
node-level programming tools that we will cover in detail in this sec-
tion. Other related software platforms include Maté , a virtual
machine for the Berkeley motes. Observing that operations such as
polling sensors and accessing internal states are common to all sen-
sor network application, Maté deﬁnes virtual machine instructions
to abstract those operations. When a new hardware platform is intro-
duced with support for the virtual machine, software written in the
Maté instruction set does not have to be rewritten.
7.3.1 Operating System: TinyOS
TinyOS aims at supporting sensor network applications on resource-
constrained hardware platforms, such as the Berkeley motes.
To ensure that an application code has an extremely small foot-
print, TinyOS chooses to have no ﬁle system, supports only static
memory allocation, implements a simple task model, and provides
minimal device and networking abstractions. Furthermore, it takes a
language-based application development approach, to be discussed
later, so that only the necessary parts of the operating system are
compiled with the application. To a certain extent, each TinyOS
application is built into the operating system.
Like many operating systems, TinyOS organizes components
into layers. Intuitively, the lower a layer is, the “closer” it is to the
hardware; the higher a layer is, the “closer” it is to the application.
7.3 Node-Level Software Platforms 249
In addition to the layers, TinyOS has a unique component architec-
ture and provides as a library a set of system software components.
A component speciﬁcation is independent of the component
implementation. Although most components encapsulate software
functionalities, some are just thin wrappers around hardware. An
application, typically developed in the nesC language covered
in the next section, wires these components together with other
Let us consider a TinyOS application example—FieldMonitor,
where all nodes in a sensor ﬁeld periodically send their temperature
and photo sensor readings to a base station via an ad hoc routing
mechanism. A diagram of the FieldMonitor application is shown in
Figure 7.5, where blocks represent TinyOS components and arrows
represent function calls among them. The directions of the arrows
are from callers to callees.
Figure 7.5 The FieldMonitor application for sensing and sending measurements.