sen sip ire
TRANSCRIPT
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
CHAPTER 1INTRODUCTION
A typical Wireless Sensor Network (WSN) consists of a large number of small-sized,
battery-powered sensor nodes that are limited in battery energy, CPU power, and communi-
cation capability. Recently, WSN has witnessed an explosive growth in both academia and
industry, attracting a great deal of research attention in the past few years. WSNs are envi-
sioned to support a variety of applications, including military surveillance, habitat monitor-
ing, and infrastructure protection, etc.
Being simple in terms of hardware, WSN applications are diverse and demanding.
The infrastructural support for such applications in the form of operating systems (OS) is be-
coming increasingly important. The basic functionalities of an OS include resource abstrac-
tions for various hardware devices, interrupt management, task scheduling, concurrency con-
trol, and networking support. Numerous applications are built on top of the OS. A sensor net-
workOS(hereafter, sensorOSfor short) bridges the gap between the hardware simplicity and
the application complexity. It plays a central role in providing a flexible
environment for building predictable and efficient services.
Over the years, we have seen various OSs emerging in the sensor network commu-
nity. While they address various challenging issues by adopting different approaches in the
design spectrum, two important issues, i.e., predictability assurance and programming flexi-
bility, are still not well addressed.
Predictability. As sensor nodes are usually deployed in inaccessible areas, operating
in an unattended manner for a long lifetime, system predictability is highly desirable. The OS
should provide mechanisms to ensure the overall system performance. First, the OS should
provide a level of separation between the OS and applications, e.g., the OS should remain re-
sponsive irrespective of the application behaviors. Second, the OS should provide a level of
separation between different tasks, e.g., a critical task should not be blocked indefinitely by
noncritical tasks or locks hold by a group of tasks.
Flexibility. Since WSN applications have diverse requirements, system flexibility to
facilitate application programming is desirable. The OS should provide many choices to meet
requirements of specific application scenarios and programmers’ preference. A hybrid model
combining both event-driven programming and multithreaded programming is highly pre-
ferred. Specific challenges should be addressed to design a hybrid system while retaining
Dept of CS&E, PESITM 1
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
predictability and efficiency at the same time.
Sensor nodes are usually equipped with low-power microcontrollers with stringent re-
source constraints. The OS should optimize CPU utilization and memory consumption for
high efficiency. Moreover, as sensor nodes are usually deployed in hostile environment in a
large scale, the OS should also support efficient network reprogramming to allow updating
the WSN software.
Dept of CS&E, PESITM 2
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
CHAPTER 2
DESIGN OF SENSPIRE OS
This section presents the design of SenSpire OS. Fig. 1 gives an overview of SenSpire
OS’s design principles.
Section 2.1 describes the two-phase interrupt servicing scheme and predictable thread
synchronization primitives for achieving system predictability. Section 2.2 details the hybrid
system design which provides a flexible model for both event-driven programming and multi-
threaded programming. Section 2.3 describes the stack sharing technique
and the modular design approach for achieving system efficiency. In addition, to facilitate
programming distributed sensor network applications, we have also designed a networking
stack and a programming language called CSpire. Section 2.4 introduces the networking ab-
straction and Section 2.5 describes the CSpire language for application programming based
on SenSpire OS.
Figure 1: A overview of SenSpire OS's Design Principle
Dept of CS&E, PESITM 3
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
2.1 Approaches for Predictability
Interrupt handling is very important for tiny embedded systems like sensor nodes. Ex-
isting sensor OSs usually take a single-phase interrupt servicing scheme. For example, in
TinyOS, interrupts are serviced by asynchronous code that is reachable from (i.e., called
from) one Interrupt Service Routine (ISR). While the OS kernel disables the interrupts only
for brief periods of time, it cannot prevent the applications from disabling interrupts, because
this is the only possible way of synchronization between tasks (i.e., synchronous code in
TinyOS) and interrupts (i.e., asynchronous code in TinyOS). Hence the interrupt latency can-
never be bounded without knowing application behaviors. SenSpire OS adopts a two-phase
interrupt servicing scheme, so that the worst-case interrupt latency can be guaranteed.
Thread synchronization is an important issue in preemptive systems. The design and
implementation of synchronization primitives, however, are overlooked in existing sensor
OSs, such as Contiki OS, Mantis OS. Without a careful design, the synchronization of threads
can lead to an indefinite period of priority inversion, during which a high priority thread waits
indefinitely for the completion of low priority threads. In order to address
this issue, SenSpire OS adopts the priority ceiling protocol to avoid unpredictable priority in-
version and the formation of deadlocks.
2.1.1 Two-Phase Interrupt Servicing
We split interrupt servicing in SenSpire OS into two phases, i.e., the top half and the bottom
half. The top half executes at interrupt time and is meant to be short enough to complete all
necessary actions at the time of the interrupt.
Dept of CS&E, PESITM 4
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
Figure 2: The sensetask application in tiny OS versus Senspire OS
It perfoms sensitive and critical tasks with all interrupts disabled. In contrast, the bot-
tom half can be deferred to a more suitable point in time to complete servicing of a prior in-
terrupt. It allows top halves to preempt its execution by enabling
interrupts.
Fig. 2 shows the code snippets for the SenseTask application for both TinyOS-1.x and
SenSpire OS (hereafter, we will use T1 to refer to TinyOS-1.x and T2 to refer to TinyOS-2.x
when different TinyOS versions matter).
The code for SenSpire OS is written in CSpire, which will be introduced in Section
2.5. In CSpire, the bh keyword is used to indicate a bottom half while thetaskkeyword is used
to indicate a run-to-completion task (a run-to-completion task cannot block or self-suspend,
e.g., TinyOS tasks are run-tocompletion). In the code for T1, the atomic keyword is used to
protect the shared data by disabling global interrupts. Hence, within the atomic section, the
OS is not responsive toany other interrupts. In contrast, in the code for SenSpire OS, the
ADC completion event is notified in the context of a bottom half, and the critical primitive is
used to protect the shared data. The critical primitive differs from the atomic primitive in that
it only defers the execution of bottom halves. Hence top halves can still be serviced immedi-
ately once interrupts trigger. Note that the critical primitive is used to protect shared data be-
tween tasks and bottom halves. To protect shared data between bottom halves and top halves,
we should use the atomic keyword (which disables all interrupts) instead. In this case, top
halves cannot interrupt the execution of bottom halves. Interrupt latency depends on the
Dept of CS&E, PESITM 5
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
length of time top halves execute and the rate of interrupts. In TinyOS, the interrupt latency
also depends on the atomic section length because the atomic keyword disables all interrupts
from execution. As the atomic keyword is exposed to application programmers, the applica-
tion code does affect the interrupt latency. On the other hand, in SenSpire OS, the critical
keyword disables bottom halves (but not top halves) and top halves can always be serviced ir-
respective of the critical section size. Hence, SenSpire OS achieves a more predictable inter-
rupt latency.
2.1.2 Predictive Thread Synchronization
A number of recent sensor OS’s support preemptive threading to ensure predictable
system performance. Synchronization primitives are important to serialize the access to
shared resources. The design and implementation of existing synchronization mechanisms are
overlooked in prior preemptive threaded sensor OSs. In fact, a direct application of traditional
synchronization primitives can lead to an indefinite period of priority inversion and a low
level of schedulability.
We consider a similar example in (shown in Fig. 3). T1, T2, and T3 are three threads
arranged in descending order of priority with T1 having the highest priority. T1 and T3 share
a data structure protected by a mutex. At time t1, T3 starts execution. At time t2, T3 locks the
mutex and executes its critical section. During the execution of T3’s critical section, T1 pre-
empts T3 at time t3. At time t4, T1 attempts to use the shared data. However, it blocks on the
mutex hold by T3. At the same time, T2 starts execution till time t5.
Dept of CS&E, PESITM 6
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
Figure 3: Example of unpredictable periods of priority inversion
In this example, we would expect that T1, being the highest priority thread, will be
blocked no longer than the time for T3 to complete its execution in the critical section, i.e.,
(t6 - t5). However, the duration of blocking is, in fact, (t6 - t5) + (t5 - t4), which is unpre-
dictable because the execution time of T2 (= t5 - t4) and any other pending intermediate
threads can be sufficiently long’
SenSpire OS hence adopts the priority ceiling protocol to address this issue. It works as
follows:
In SenSpire OS, each thread has a static priority and a dynamic priority.
Each shared resource has a static priority ceiling, which equals to the highest static
priority of the thread that uses it. Thanks to the CSpire language, we are able to obtain
the priority ceiling by program code analysis.
The dynamic priority of a thread equals the maximum of its static priority and priority
ceiling of the shared resource it currently uses.
A ready thread can preempt the current thread only when its static priority is higher
than the dynamic priority of the current thread.
It is formally proved in that the priority ceiling protocol reduces the worst-case blocking
time to at most the duration of execution of a single critical section of a lower priority thread.
In addition, it prevents the formation of deadlocks. In the example shown in Fig. 3, if the pri-
ority ceiling protocol is used, at time t4, T3 will continue because it has a higher dynamic pri-
ority than T2’s static priority.
Dept of CS&E, PESITM 7
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
2.2 Approaches for Flexibility
The debate between threads and events is a very old one. Event-driven systems have
the benefits of high system responsiveness, high performance, and low resource consumption.
On the other hand, multithreaded systems have the benefits of expressiveness and ease of use,
e.g., application programmers can reason about the series of actions taken by a thread in the
familiar way, leading to a natural programming style in which the control flow for a single
thread is apparent.
As a hybrid model combines both event-driven programming and multithreaded pro-
gramming, we therefore favor it to meet diverse application requirements. With a hybrid
model, it means that the application programmer could design parts of the application using
threads, where threads are the appropriate abstraction, and parts of the system using events,
where they are more suitable. It is flexible and gives the best of two worlds: the expressive-
ness of threads and customizability of events. While there exist a number of prior works on
the design of hybrid models, SenSpire OS’s integral design goals distinguish its hybrid sys-
tem design from existing works. The hybrid model of SenSpire OS has the following fea-
tures.
Flexibility and customizability. Existing hybrid approaches, based on legacy code-
base, make tight coupling of two subsystems, e.g., event-biased approaches require the exis-
tence of the event-driven subsystem while threadbiased approaches require the existence of
multithreaded
subsystem. By natively supporting hybrid scheduling in the kernel scheduler, SenSpire OS al-
lows decoupling of two subsystems, hence is more flexible in expressing and
customizing different scheduling policies.
Predictability and real-time performance. Existing approaches such as Protothreads,
TinyThreads, do not support priority preemption. Other approaches, such as TinyMOS, only
provide a limited number of priorities (e.g., limited to five in TinyMOS). SenSpire OS ad-
vances prior work by supporting programmer-assigned priority-based preemption, thus na-
tively supporting longrunning computations without degrading system performance.
Moreover, SenSpire OS supports event preemption, which is important to achieve pre-
dictability in the eventdriven subsystem. In addition, SenSpire OS employs the
priority ceiling protocol to achieve predictable thread synchronization (Section 2.1).
Dept of CS&E, PESITM 8
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
Memory efficiency. Existing hybrid systems, such as TOSThreads, TinyMOS, based
on legacy codebase, preclude aggressive resource optimizations in the implementation. In
contrast, by natively supporting hybrid scheduling in the kernel scheduler, SenSpire OS is
able to exploit stack sharing in order to reduce the stack memory consumption.
2.2.1 Hybrid System
Fig. 4 gives an overview of SenSpire OS’s hybrid system. In SenSpire OS, we clas-
sify tasks in two forms: event handler task (event for short) and thread task (thread for short).
Events are handled by the event-driven subsystem and threads are handled by the multi-
threaded subsystem.
Figure 4:SenSpire OS's Hybrid system
Events are scheduled by Event Schedulers (ESs) which in turn are scheduled by the
Kernel Scheduler (KS). SenSpire OS’s event-driven subsystem is different from TinyOS, in
that we can support multiple preemption levels by the use of multiple ESs. Events in different
ESs can preempt one another. In contrast, the TinyOS core has only one preemption level
within the task context. Some critical system events (e.g., packet reception) are executed in
the task context, sharing the same context as other noncritical tasks (e.g., compression).
Therefore, a critical task can be interfered by the execution of other noncritical tasks ahead of
it. The multithreaded subsystem consists of multiple threads which are directly scheduled by
our KS along with ESs. It is different from Mantis OS, in that we do not employ time-sliced
scheduling, instead, preemption occurs when a high priority thread (or ES) is ready or when
the currently running thread calls a blocking I/O or gives up its CPU cycles voluntarily by
Dept of CS&E, PESITM 9
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
calling sleep( ) or yield( ). Hence the number of context switches can be reduced. In SenSpire
OS, the event-driven subsystem takes a higher priority than the multithreaded subsystem be-
cause it is more suitable for time-sensitive operations.
We have introduced the design of SenSpire OS’s thread synchronization primitives in
Section 2.1.2. In the following section, we will describe SenSpire OS’s novel differentiated
kernel scheduling scheme which implements the hybrid model while reduces memory con-
sumption by stack sharing at the same time.
2.2.2 Differentiated Kernel Scheduling
SenSpire OS’s KS differentiates three execution contexts, i.e., ES, the primary thread
(i.e., the system startup context, denoted as T0), and nonprimary threads (denoted as T1...n).
As each ES represents a nonblocking context, they can share a common stack with one of the
blocking context. In SenSpire OS, all ESs share a common stack with the primary thread.
SenSpire OS’s stack sharing technique is inspired by TinyOS fibers [25], in which a system
stack is shared between events and one thread. SenSpire OS extends it by supporting preemp-
tive events and multiple threads. We will further discuss the issue of stack sharing in Section
2.3.1.
Context switches between ESs or between ES and the primary thread do not involve
stack switching. Stack switching is only required when switching between threads or between
ES and nonprimary threads. Note that we still need to switch the register files. Table 1 shows
the actions taken by the KS.
Dept of CS&E, PESITM 10
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
Table 1: Differentiated Kernel Scheduling
Note that, events, being run-to-completion, are not allowed to block. This means that events
cannot block on synchronization primitives such as mutexes. In order to achieve synchroniza-
tion between events of different priorities, or events and threads, we need to manually check
for the resource availability in the event, and need to repost the event if the resource is un-
available at the current time.
The KS employs preemptive scheduling in accordance with the priorities of ESs and
threads. The priorities of ESs must be different while the priorities of threads can be the
same. Within the same priority, the KS schedules threads in an FIFO manner. Each ES uses a
nonpreemptive scheduling scheme. Within each ES, events share a common execution
context and are scheduled by a certain nonpreemptive policy (e.g., FIFO, or nonpreemptive
priority based). Hence, to execute an event, two levels of scheduling are involved: first, the
KS schedules the corresponding ES (which the event is assigned to), then the ES schedules
the event to run.
The scheduling system can be viewed as a hierarchy of execution contexts . As shown
in Figure 5, the Kernel Scheduler schedules two ESs and two threads in a prioritypreemption
manner. The ES-NPPS has the highest priority. Thus any event assigned to it can preempt
other tasks. The scheduling policy is Non-Preemptive Priority Scheduling (NPPS). The ES-
FIFO has an intermediate priority. Any event assigned to it can preempt threads, but not
events assigned to ES-NPPS. It schedules events assigned to it in an FIFO manner. Two
threads have the same lowest priority and can be preempted by any events in the system.
They are scheduled by our KS in an FIFO manner.
Dept of CS&E, PESITM 11
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
2.2.3 Comparison with Prior Work
Fig. 6 compares SenSpire OS’s hybrid model with prior works in the sensor network commu-
nity. In this figure, x-axis represents the thread phase while the y-axis represents the event
phase. Early OSs, such as TinyOS (also SOS, Contiki OS core), only support nonpreemptive
events. Protothreads , built on Contiki OS, supports thread-like programming. However, it
does not maintain thread-independent data, and does not allow preemption. TinyOS fibers,
built on TinyOS, only supports one thread
Figure 5: An Example for Scheduling hierarchy
Figure 6: Comparision of existing hybrid systems
TinyThreads, also built on TinyOS, implements a cooperative thread mechanism. In
the cooperative thread model, a thread must explicitly yield the CPU to other runnable
Dept of CS&E, PESITM 12
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
threads. The problem with cooperative threads is the correctness of the system depends on
application code voluntarily yielding the CPU at specific intervals. If a thread does not relin-
quish the CPU for a long time, then other threads may be unable to make progress. The same
issue exists for event-driven systems. Therefore, TinyOS Preemptive Level Scheduler (PL)
supports preemptive events based on TinyOS, but it does not support thread-like program-
ming. The Contiki preemptive library, and TOSThreads, support true preemptive multithread-
ing on event-driven kernels; TinyMOS supports events in a multithreaded kernel (Mantis
OS). SenSpire OS advances these three works in three aspects. First, SenSpire OS supports
preemption in both event-driven subsystem and multithreaded subsystem. Event preemption
is important for ensuring system predictability in the event-driven subsystem. Second, Sen-
Spire OS supports customizing different scheduling policies with the help of the CSpire lan-
guage compiler (which will be further discussed in Section 4.5). Third, by directly supporting
hybrid scheduling in the kernel scheduler, SenSpire OS is able to employ stack sharing for
optimizing resource utilization (see Section 2.3.1).
2.3 Approaches for Efficiency
The design and implementation of a sensor OS should meet the resource constraints
of sensor nodes. In most components of SenSpire OS, we adopt cost-effective design ap-
proaches (as opposed to approaches for traditional OSs). In particular, we employ stack shar-
ing to reduce stack memory consumption in our scheduler design. In addition, the modular
extension of SenSpire OS enables energy-efficient network reprogramming. We will intro-
duce the stack sharing technique and the modular design approach in the following two sec-
tions, respectively.
2.3.1 Stack Sharing
The shared stack model not only can be applied to nonpreemptive systems, but also
preemptive systems where tasks have run-to-completion semantics and do not suspend them-
selves.
In order to see why stack sharing can be applied to our hybrid system, we analyze the
following conditions. First, all ESs can share a common stack because their execution is non-
interleaved, i.e., if ESj begins execution between the start and finish of ESi (to make it possi-
ble, ESj must have a higher priority), then ESi is not allowed to resume execution until ESj
Dept of CS&E, PESITM 13
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
has finished. Second, all ESs can share a common stack with one of the threads (primary
thread). This is because each ES’s execution cannot be preempted by threads (as ES’s priority
is higher than threads), and, once some ES preempts the execution of the primary thread, it
must run to completion before the primary thread can be resumed.
In order to see the benefits our differentiated kernel scheduling (Section 2.2.2), we an-
alyze the stack consumption of the scheduling hierarchy shown in Fig. 5 for prior
approaches (without stack sharing) and SenSpire OS’s approach (with stack sharing). With-
out stack sharing, this scheduling hierarchy will occupy the following four stacks.
1. Stack for ES-NPPS; all tasks within ES-NPPS are nonpreemptive, hence share this
common stack.
2. Stack for ES-FIFO; all tasks within ES-FIFO are nonpreemptive, hence share this
common stack.
3. Stack for thread1 (the primary thread).
4. Stack for thread2.
This is a relative costly scheme for implementing the hybrid model on resource con-
strained sensor nodes. In SenSpire OS, a common system stack is shared among ESs and the
primary thread. Considering an additional stack for thread2, the system consumes two stacks,
reducing two stacks compared to prior approaches.
2.3.2 Modular Design
Recently, SenSpireOSsupports dynamic loadable modules to enable
energy-efficient network reprogramming. Early OSs, such as TinyOS, re-
quire full image replacement to reprogram a network of sensors. This in-
curs a large amount of transmission overhead during code dissemination,
which significantly impacts energy efficiency and the lifetime of a sensor
network. A few differential-based approaches are designed for TinyOS.
The problem
therein is that they require the program layout to be exactly the same on all sensor nodes. If
sensor nodes are running different versions of their software, differential-based approaches
do not scale. SenSpire OS supports loadable modules. It uses an optimized module file for-
mat, SELF, for dissemination. The SELF loader within the OS is responsible for loading and
executing a new module. Compared to existing modular OSs, such as SOS and Contiki OS,
SenSpire OS’s modular design has two major advantages.
Dept of CS&E, PESITM 14
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
First, compared to Contiki’s CELF, SELF is even smaller. CELF only redefines long
data types to short ones (e.g., from 32 bits to 16 bits, or 16 bits to 8 bits), hence still leads to a
large amount of metadata overhead. SenSpire OS optimizes the module file format much fur-
ther. For example, with the chained reference technique, it reduces the number of relocation
entries to the number of unique references, instead of the total number of references; with a
system call jump table, it is able to prelink system calls to fixed addresses in the jump table
slots. This prelinking technique significantly reduces the overhead of kernel symbols and
their string representations.
Second, compared to SOS’s MELF, SELF is more flexible. MELF, being small in
size, has several limitations. First, it uses Position Independent Code (PIC). Not all CPU ar-
chitectures support PIC and even when supported, programs compiled to PIC typically are
subject to size restrictions, e.g., 4 KB for the AVR microcontroller. SenSpire OS does not
have this limitation by using relocatable code. Second, SOS module does not allow to define
global variables because data relocation is not performed. SenSpire OS does not have this
limitation.
2.4 Networking Abstraction
We have designed and implemented a three-layer networking stack to facilitate pro-
gramming distributed sensor applications based on SenSpire OS. Different layers abstract
different functionalities by different classes of WSN developers.
1) The radio layer provided by device driver developers. It implements device specific
MAC protocols.
2) The unified resource layer provided by OS kernel developers. It virtualizes the radio
hardware, scheduling concurrent requests. On top of it, different applications can use
the hardware radio without interfering each other.
3) The sensornet layer provided by network service developers. It implements neighbor-
hood management and link estimations, which can be shared among different upper-
layer networking routing protocols.
Dept of CS&E, PESITM 15
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
2.5 Programming Language
We have developed a programming language, CSpire, for application programming
based on SenSpire OS. CSpire partially supports object-oriented programming while tightly
integrates with the OS kernel for compile-time verifications, optimizations, and customiza-
tions. We summarize CSpire’s features as follows:
Encapsulation. CSpire forces the application code be encapsulated in classes.
Function polymorphism. CSpire allows a common name to be shared among multiple
functions as long as their signatures are different. Note that CSpire does not allow dy-
namic polymorphism as it will incur a large runtime overhead.
Object manipulation. CSpire supports invoking methods of an object. However,
CSpire does not manage object lifetime.
Support for the hybrid model. CSpire supports the keywords of task, thread, bh, etc.,
to simply programming on top of SenSpire OS’s hybrid model.
Annotations. CSpire supports specifying annotations to objects, e.g.,
task[period=1000] denotes a periodic task with a one second period.
Compile-time verification. CSpire verifies whether the application code conforms to
the requirements of SenSpire OS. For example, blocking is not allowed in events (or
bottom halves).
Compile-time optimization and customization. CSpire is able to analyze application
resource requirements and customize the OS kernel. Currently, CSpire supports for
customization of the scheduling hierarchy, e.g., the multithreaded system can be ex-
cluded if the application never uses. CSpire also supports stack size estimation by dif-
ferentiating different execution contexts and analyzing at the assembly level.
Dept of CS&E, PESITM 16
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
CHAPTER 3
IMPLEMENTATION
We have implemented SenSpire OS on three commonly deployed sensor node plat-
forms—Mica2, MicaZ, and TelosB.
Figure 7: SenSpire OS design overview
The SenSpire OS kernel is written in C. As shown in Fig. 7, The SenSpire OS mainly
consists of the following components:
Hardware drivers. They are further classified into onchip device drivers (such as hard-
ware timers, UART, and ADC) and off-chip device drivers (such as MTS300/
MTS310 sensorboards, Chipcon CC1000/ CC2420 radios). We port parts of this code
from SOS and Mantis OS.
Interrupt system. It contains the two-phase interrupt handling code.
Task scheduling system. It implements the differentiated kernel scheduling algorithm
and a set of synchronization primitives.
Dept of CS&E, PESITM 17
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
Module manager. It extends SenSpire OS for handling modules. It is responsible for
module placement, loading, and execution.
Network protocols. They include the sensornet layer and illustrative network routing
protocols such as the tree routing protocol.
Programming environment. Applications based on SenSpireOSare written in
CSpire,weexpose SenSpire OS kernel services to application programmers via the
CSpire native classes which are thin wrappers around their C implementations. We
implement the CSpire compiler with JavaCC. It compiles user applications together
with SenSpire OS native classes into C. Then it invokes the corresponding C cross-
compiler (e.g., avr-gcc or msp-gcc) to compile the converted C code into the binary
code.
The kernel scheduler is the core of SenSpire OS. The SenSpire OS kernel scheduler main-
tains a priority queue. As shown in Fig. 8, the kernel scheduler fetches the highest priority
task from the queue. If there is no task in the queue, the kernel scheduler puts the CPU into
the sleep state to
Figure 8:Pseudocode for kernel scheduler
save energy. Otherwise the kernel scheduler switches the register files. After that, the kernel
scheduler switches the stack only when necessary (according to Table 1).
Dept of CS&E, PESITM 18
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
CHAPTER 4
RELATED WORK
TinyOS, developed at UC Berkeley, is perhaps the earliest sensor OS in the literature. To en-
able a flexible architecture and a low resource consumption, TinyOS programming is based
on components which are wired together to create a single application image at design-time.
Component interactions happen at two directions, i.e., one component can use commands
provided by another component; also, one component can signal events to another compo-
nent. The execution model of TinyOS consists of interrupts and tasks. Interrupts execute at a
higher priority and can preempt the execution of tasks. Tasks execute at a lower priority and
are scheduled in a FIFO manner. Tasks in TinyOS are written in a run-to-completion manner,
and they cannot be preempted or self-suspended. For this reason, I/Os are done in splitphases,
i.e., a request is issued before a signal invokes the
start of the next task.
Contiki, developed at Swedish Institute of Computer Science, is a sensor OS that sup-
ports dynamically loadable modules. Contiki supports multithreading via libraries to address
the programming inconvenience of event-based programming (e.g., in TinyOS). Contiki also
supports a lightweight threading mechanism, i.e., protothreads .
SOS, developed at the University of California, Los Angeles, also supports dynami-
cally loadable modules. It adopts a module-based architecture which allows dynamically
loading and unloading modules. The SOS execution model is only slightly more complex
than TinyOS: SOS message handlers (similar to TinyOS tasks) are dispatched according to
three different priorities, but preemption is not allowed between two message handlers.
Mantis OS, developed at Colorado University, implements a traditional preemptive
time-sliced multithreading on sensor nodes. The Mantis kernel supports synchronous I/Os (as
opposed to split-phase I/Os), and a set of concurrency control primitives, e.g., binary sema-
phores (mutex) and counting semaphores.
Nano-RK, developed at Carnegie Mellon University, implements a reservation-based
real-time OS for WSNs. Nano-RK supports fixed-priority preemptive multitasking for guar-
anteeing that task deadlines are met. It also supports CPU and network bandwidth reserva-
Dept of CS&E, PESITM 19
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
tions, i.e., tasks can specify their resource demands and the OS provides timely, guaranteed
and controlled access to CPU cycles and network packets.
RETOS, developed at Yonsei University, Korea, is designed to improve several as-
pects of prior work. It improves system resilience by supporting dual mode operation (i.e.,
kernel mode and user mode) as well as application code checking at design-time and runtime.
It optimizes multithreading implementation and provides support for POSIX 1003.1b real-
time scheduling. It also supports loadable modules and provides multihop networking ser-
vices.
LiteOS, developed at the University of Illinois at Urbana Champaign, is designed to pro-
vide a traditional Unix-like environments for programming WSN applications. It includes:
1) A built-in hierarchical file system and a wireless shell for user interaction using Unix-
like commands.
1) Kernel support for dynamic loading native execution of multithreaded applications.
2) An object oriented programming language (LiteC++) that uses a subset of C++ as its
syntax with class library support.
Pixie OS, developed at Harvard University, is designed to enables resource-aware pro-
gramming. In Pixie, a sensor node has direct knowledge of available resources, such as
energy, radio bandwidth, and storage space, and can control resource consumption at a fine
granularity. The Pixie OS is based on a dataflow programming model based on the concept of
resource tickets, a core abstraction for representing resource availability and reservations. By
giving the system visibility and fine-grained control over resource management, a broad
range of policies can be implemented.
Aside from the basic system implementations mentioned above, there is a large body
of work devoted to improving OS capabilities in different dimensions, e.g., improving OS re-
liability (e.g., t-kernel, Harbor, and Neutron ), providing real-time support (e.g., FIT ), ex-
tending the programming model (e.g., protothreads , TOSThreads), and providing reprogram-
ming support (e.g., Deluge, Stream, and Elon ). For a more complete review in the areas of
sensor OS design.
Dept of CS&E, PESITM 20
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
CONCLUSIONS AND FUTURE WORK
In this paper, we present SenSpire OS, a predictable, flexible, and efficient operating
system for WSNs. We improve system predictability by two-phase interrupt servicing and
predictable thread synchronization; we achieve system flexibility by providing a hybrid
model for both event-driven programming and multithreaded programming; we retain system
efficiency by employing stack sharing and modular design. In addition, we have designed a
three-layer networking stack and an object-oriented programming language (CSpire) to en-
hance system usability and programming convenience. Having implemented SenSpire OS on
three most commonly used sensor node platforms, we evaluate its performance extensively.
While we have shown that SenSpire OS is promising in providing a flexible environ-
ment for building predictable and efficient sensor network applications. There is much future
work to consider. In particular, we would like to examine how SenSpire OS’s design princi-
ples will enhance the performance of large-scale complex WSN applications.
Dept of CS&E, PESITM 21
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
REFERENCES
1. I.F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci, “Wireless Sensor Net-
works: A Survey,” Computer Networks, vol. 38, pp. 393-422, 2002.
2. TinyOS, http://www.tinyos.net,
3. A. Dunkels, B. Gro¨ nvall, and T. Voigt, “Contiki—A Lightweight and Flexible Op-
erating System for Tiny Networked Sensors,” Proc. 29th Ann. IEEE Int’l Conf. Local
Computer Networks (LCN ’04), 2004.
4. C.-C. Han, R. Kumar, R. Shea, E. Kohler, and M. Srivastava, “A Dynamic Operating
System for Sensor Nodes,” Proc. Third Int’l Conf. Mobile Systems, Applications, and
Services (MobiSys), 2005.
5. S. Bhatti, J. Carlson, H. Dai, J. Deng, J. Rose, A. Sheth, B. Shucker, C. Gruenwald,
A. Torgerson, and R. Han, “MANTIS OS: An Embedded Multithreaded Operating
System for Wireless Micro Sensor Platforms,” J. Mobile Networks and Applications,
vol. 10, pp. 563-579, 2005.
6. A. Eswaran, A. Rowe, and R. Rajkumar, “Nano-RK: An Energy- Aware Resource-
Centric RTOS for Sensor Networks,” Proc. 26th IEEE Int’l Real-Time Systems Symp.
(RTSS), 2005.
7. H. Cha, S. Choi, I. Jung, H. Kim, and H. Shin, “RETOS: Resilient, Expandable, and
Threaded Operating System for Wireless Sensor Networks,” Proc. Sixth Int’l Conf.
Information Processing in Sensor Networks (IPSN ’07), 2007.
8. Q. Cao, T.F. Adbelzaher, and J.A. Stankovic, “The LiteOS Operating System: To-
wards Unix-Like Abstractions for Wireless Sensor Networks,” Proc. Seventh Int’l
Conf. Information Processing in Sensor Networks (IPSN ’08), 2008.
9. K. Lorincz, B. rong Chen, J. Waterman, G. Werner-Allen, and M. Welsh, “Resource
Aware Programming in the Pixie OS,” Proc. Sixth ACM Conf. Embedded Network
Sensor Systems (SenSys), 2008.
10. Q. Wang, Y. Zhu, and L. Cheng, “Reprogramming Wireless Sensor Networks: Chal-
lenges and Approaches,” IEEE Network Magazine, vol. 20, no. 3, pp. 48-55, May/
June 2006.
Dept of CS&E, PESITM 22