Академический Документы
Профессиональный Документы
Культура Документы
ABSTRACT
The technological trend in the recent years has led to the emergence of complete
systems on a single chip with integrated low power communication and transducer
capabilities. This has opened the way for wireless sensor networks: a paradigm of
hundreds or even
thousands of tiny, smart sensors with transducer and
communication capabilities. Manage such a complex network that has to work
unattended for months or years, being aware of the limited power resouces of
battery-supplied nodes is a challenging task. Attending that task requires an
adequate software platform, in other words an operating system specifically suited
for wireless sensor networks. This paper presents a brief overview of the most
known operating systems, highlighting the key challenges that have driven their
design.
Keywords: wireless sensor networks, operating systems.
INTRODUCTION
Page 1
OVERVIEW
2.1 TinyOS
TinyOS [1] is virtually the state-of-the-art of
sensor operating systems. Berkeley University
researchers based their work aiming to face two
issues: the first was to manage the concurrency
intensive nature of nodes which need to keep in
movement different flows of data simultaneously,
while the second was to develop a system with
efficient modularity but believing that hardware and
software components must snap together with little
processing and storage overhead. The purpose of
the researchers was also to develop a system that
would easily scale with the current technology
trends, supporting smaller devices as well as the
crossover of software components into hardware.
Considering power as the most precious
resource and trying to achieve high levels of
concurrency, the system was designed following an
event-based approach, which avoids reserving a
stack space for each execution context. This design
guideline was drawn from a parallelism with high
performance computing, where event-based
programming is the key to achieve high
performance in concurrency intensive applications.
www.ubicc.org
Volume 3 Number 4
Page 2
2.2 MANTIS
The MultimodAl system for NeTworks of Insitu wireless Sensors [3] was developed focusing on
two design key: the need for a small learning curve
for users and the need for flexibility. The first
objective led to fundamental choices in the
architecture of the system and the programming
language used for its implementation. In fact, to
lower the entry barrier the researchers decided to
adopt a largely diffuse design methodology, that is,
the classical structure of a multithreaded operating
system. For this reason MANTIS includes features
like multithreading, preemptive scheduling with
time slices, I/O synchronization via mutual
exclusion, and standard network stack and device
drivers. The second choice is associated with the
purpose of flattening the learning curve for users
and determinates the use of standard C as
developing language for the kernel and the API.
The choice of C language additionally entails the
cross-platform support and the reuse of a vast
legacy code base.
MANTIS
kernel
resembles
UNIX-style
schedulers providing services for a subset of
POSIX threads along with priority based scheduling.
The thread table is allocated statically, so it can be
adjusted only at compile time. The scheduler
receives notes to trigger context switches from an
hardware timer interrupt. This interrupt is the only
kind of hardware interrupt handled by the kernel: in
fact all the others interrupts are sent directly to
device drivers. Context switches are triggered not
only by timer events but also by system calls or
semaphore operations. Besides drivers and user
threads, MANTIS has a special idle, low-priority
thread created by the kernel at startup. This thread
could be used to implement power-aware
scheduling: thanks to its position, it can detect
patterns of CPU utilization and adjust kernel
parameters to conserve energy.
MANTIS researchers thought that wireless
networking management was a critical matter, so
they developed the layered network stack as a set of
user level threads. In other words, they
implemented different layers in different threads
advocating that this choice promotes flexibility to
the detriment of performance. This flexible
structure is useful in particular for dynamic
reprogramming, because it enables application
developers to reprogram network functionalities
such as routing by simply starting, stopping and
deleting user-level threads.
Drawing from the experience in WSNs, the
developers of MANTIS gave their system a set of
sophisticated features like dynamic reprogramming
of sensors nodes via wireless communication,
remote debugging and multimodal prototyping.
MANTIS prototyping environment provides a
framework for testing devices and applications
www.ubicc.org
2.3 Contiki
Contiki is an operating system based on a
lightweight event-driven kernel. It was developed
drawing from previous operating systems works
with the goal of adding features like run-time
loading and linking of libraries, programs and
device drivers, as well as support for preemptive
multithreading.
Event-based systems have shown good
performance for many kind of WSNs applications;
however, purely event-based systems have the
penalty of being unable to respond to external
events during long-lasting computations. A partial
solution to this problem is adding multithreading
support to the system, but this would cause
additional overhead. To address these problems
Contiki researchers have done the compromise of
developing
an
event-driven
kernel
and
implementing preemptive multithreading features
as a library, which is optionally linked with
programs that explicitly require it.
Contiki operating system can be divided in three
main components: an event driven kernel that
provides basic CPU multiplexing and has no
platform-specific code, a program loader and
finally a set of libraries that provide higher level
functionalities.
From a structural point of view, a system
running Contiki can be partitioned in two parts: a
core and a set of loadable programs. The core is
compiled into a single binary image and is
unmodifiable after nodes deployment. The
programs are loaded into the system by the program
loader, which may obtain the binaries either from
the communication stack (and thus from the
network) or from the systems EEPROM memory.
Shared libraries like user programs may be
replaced in deployed systems by using the dynamic
Volume 3 Number 4
Page 3
2.4 PicOS
PicOS is an operating system written in C and
specifically aimed for microcontrollers with limited
RAM on chip. In the attempt to ease the
implementation of applications with constrained
resource hardware platforms, PicOS creators leaned
towards a programming environment, which is a
collection of functions for organizing multiple
activities of reactive applications. This
environment is capable to provide services like a
flavor of multitasking and tools for inter-process
communication.
Each process is thought as a FSM that changes
its state according to the events. This approach is
very effective for reactive applications, whose
primary role is to respond to events rather than
processing data or crunching numbers. The CPU
multiplexing happens only at state boundaries: in
other words FSM states can be viewed as
checkpoints, at which PicOS processes can be
preempted. Owing the fact that processes are
preemptible at clearly defined points, potentially
problematic operations on counters and flags are
always atomic. On the other hand, such nonpreemptible character of PicOS processes makes
this system not well suitable for real time
applications. In PicOS active processes that need to
wait for some events may release the CPU by
issuing a wait request, which defines the
conditions necessary to their recovery. This way the
CPU resources could be destined to other processes.
The PicOS system is also equipped with several
advanced features, like a memory allocator capable
www.ubicc.org
2.5 MagnetOS
Applications often need to adapt not only to
external changes but also to the internal changes
initiated by the applications themselves. An
example may come from a battlefront application
that may modify its behavior switching from the
defensive to the offensive mode: this application
could change its communication pattern and
reorganize the deployed components. Focusing on
this point, researchers at the Cornell University
argued that network-wide energy management is
best provided by a distributed,
power-aware
operating system. Those researchers developed
MagnetOS aiming to the following four goals. The
first was the adaptability to resources and network
changes. The second was to follow efficient
policies in terms of power consumption. The third
goal was giving the OS general-purpose
characteristics, allowing it to execute applications
over networks of nodes with heterogeneous
capabilities and handling different hardware and
software choices. The fourth goal was providing the
system with facilities for deploying, managing and
modifying executing applications.
The result was a system providing a SSI,
namely a Single System Image. In this abstraction,
the entire network is presented to applications as a
single unified Java virtual machine. The system,
which follows the Distributed Virtual Machine
paradigm, may be partitioned in a static and in a
dynamic component. The static component rewrites
regular Java applications into objects that can be
distributed across the network. The dynamic
component provides on each node services for
application monitoring and for object creation,
invocation and migration. In order to achieve good
performance an auxiliary interface is provided by
the MagnetOS runtime that overrides the automatic
object
placement
decisions
and
allows
programmers to explicitly direct object placement.
MagnetOS uses two online power-aware
algorithms
to
reduce
application
energy
consumption and to increase system survival by
moving application components within the entire
network. In practice, these protocols try to move he
communication endpoints in order to conserve
energy. The first of them, called NetPull, works at
the physical layer whereas the second one, called
NetCenter, works at the network layer.
2.6 EYES
This operating system was developed within the
Volume 3 Number 4
Page 4
CONCLUSIONS
TinyOS
Manage concurrent data flows
Scale easily with technology
Modularity
Event-based approach
Tiny scheduler and a set of components
No blocking or polling Developed in
nesC
A byte code interpreter for non-expert
programmers
Objectives
Structure
Special
features
Objectives
Structure
Special
features
Mantis
Small learning curve
Multithreaded OS,
UNIX-style scheduler
Statically-allocated thread table
Developed in C
Specific idle task that adjusts kernel
parameters to conserve energy
Remote debugging and reprogramming
Contiki
Preemptive multithreading support
Runtime loading and linking of libraries
Lightweight event-driven kernel
Multithreading features as an optionally
linked library
Capable of changing communication layer on
the run
PicOS
Aimed for microcontrollers with tiny RAM
MagnetOS
Adaptability to resource and network changes
Manage nodes with heterogeneous
capabilities
Single System Image, the entire network is a
unified Java virtual machine
EYES
Address problems of scarce memory and
power supply
Objectives
Structure
Special
features
Event driven OS
Structured in modules executed as responses
to external events
Each task runs to completion
Two layers of abstraction with specific API
for applications and physical support
Four-step procedure to update the code
Table 2: the seven expected features of the next generation WSN operating systems.
Power-aware policies
Self organization
Easy interface to expose data
Simple way to program, update and debug
network applications
Power-aware communication protocols
Portability
Easy programming language for non-tech
users
Volume 3 Number 4
Page 5
www.ubicc.org
Volume 3 Number 4
Page 6
REFERENCES
www.ubicc.org