Sen Sip Ire

SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks
CHAPTER 1 INTRODUCTION
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 communication 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 envisioned to support a variety of applications, including military surveillance, habitat monitoring, 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 becoming increasingly important. The basic functionalities of an OS include resource abstractions for various hardware devices, interrupt management, task scheduling, concurrency control, and networking support. Numerous applications are built on top of the OS. A sensor networkOS(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 community. While they address various challenging issues by adopting different approaches in the design spectrum, two important issues, i.e., predictability assurance and programming flexibility, 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 responsive 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 preferred. Specific challenges should be addressed to design a hybrid system while retaining
Dept of CS&E, PESITM 1
predictability and efficiency at the same time. Sensor nodes are usually equipped with low-power microcontrollers with stringent resource 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
CHAPTER 2 DESIGN OF SENSPIRE OS

This section presents the design of SenSpire OS. Fig. 1 gives an overview of SenSpire OSs 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 multithreaded 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 abstraction 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
2.1 Approaches for Predictability

Interrupt handling is very important for tiny embedded systems like sensor nodes. Existing 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 cannever 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 inversion 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.
Figure 2: The sensetask application in tiny OS versus Senspire OS
It perfoms sensitive and critical tasks with all interrupts disabled. In contrast, the bottom half can be deferred to a more suitable point in time to complete servicing of a prior interrupt. 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 immediately once interrupts trigger. Note that the critical primitive is used to protect shared data between 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 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 application 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 irrespective of the critical section size. Hence, SenSpire OS achieves a more predictable interrupt latency.
2.1.2 Predictive Thread Synchronization

A number of recent sensor OSs 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 T3s critical section, T1 preempts 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.
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 unpredictable 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 priority ceiling protocol is used, at time t4, T3 will continue because it has a higher dynamic priority than T2s static priority.
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 programming, 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 expressiveness of threads and customizability of events. While there exist a number of prior works on the design of hybrid models, SenSpire OSs integral design goals distinguish its hybrid system design from existing works. The hybrid model of SenSpire OS has the following features. Flexibility and customizability. Existing hybrid approaches, based on legacy codebase, make tight coupling of two subsystems, e.g., event-biased approaches require the existence 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 allows 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 advances prior work by supporting programmer-assigned priority-based preemption, thus natively supporting longrunning computations without degrading system performance. Moreover, SenSpire OS supports event preemption, which is important to achieve predictability in the eventdriven subsystem. In addition, SenSpire OS employs the priority ceiling protocol to achieve predictable thread synchronization (Section 2.1). 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 OSs hybrid system. In SenSpire OS, we classify 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 multithreaded 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 OSs 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 calling sleep( ) or yield( ). Hence the number of context switches can be reduced. In SenSpire OS, the event-driv-
en subsystem takes a higher priority than the multithreaded subsystem because it is more suitable for time-sensitive operations. We have introduced the design of SenSpire OSs thread synchronization primitives in Section 2.1.2. In the following section, we will describe SenSpire OSs novel differentiated kernel scheduling scheme which implements the hybrid model while reduces memory consumption by stack sharing at the same time.
2.2.2 Differentiated Kernel Scheduling

SenSpire OSs 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 OSs 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 preemptive 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.
Table 1: Differentiated Kernel Scheduling
10
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 synchronization 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 unavailable 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.
2.2.3 Comparison with Prior Work

Fig. 6 compares SenSpire OSs hybrid model with prior works in the sensor network community. 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
11
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 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 relinquish 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 programming. The Contiki preemptive library, and TOSThreads, support true preemptive multithreading on eventdriven 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, SenSpire OS supports customizing different scheduling policies with the help of the CSpire language 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 approaches (as opposed to approaches for traditional OSs). In particular, we employ stack sharing to reduce stack memory consumption in our scheduler design. In addition, the modular extension of SenSpire OS enables energy-efficient network reprogramming. We will introduce the stack sharing technique and the modular design approach in the following two sections, 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 themselves. 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 noninterleaved, i.e., if ESj begins execution between the start and finish of ESi (to make it possible, ESj must have a higher priority), then ESi is not allowed to resume execution until ESj has finished. Second, all ESs can share a common stack with one of the threads (primary thread). This is because each ESs execution cannot be preempted by threads (as ESs 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 analyze the stack consumption of the scheduling hierarchy shown in Fig. 5 for prior approaches (without stack sharing) and SenSpire OSs approach (with stack sharing). Without 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.
13
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks 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 constrained 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, require full image replacement to reprogram a network of sensors. This incurs 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 format, 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 OSs modular design has two major advantages. First, compared to Contikis 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 further. 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 SOSs MELF, SELF is more flexible. MELF, being small in size, has several limitations. First, it uses Position Independent Code (PIC). Not all CPU architectures 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 limitaDept of CS&E, PESITM 14
tion 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 programming 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 neighborhood management and link estimations, which can be shared among different upperlayer networking routing protocols.
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 customizations. We summarize CSpires features as follows:
Encapsulation. CSpire forces the application code be encapsulated in classes.
15
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 dynamic 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 OSs 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 excluded if the application never uses. CSpire also supports stack size estimation by differentiating different execution contexts and analyzing at the assembly level.
CHAPTER 3 IMPLEMENTATION
We have implemented SenSpire OS on three commonly deployed sensor node platformsMica2, MicaZ, and TelosB.
16
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 hardware 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. 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.
17
The kernel scheduler is the core of SenSpire OS. The SenSpire OS kernel scheduler maintains 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).
CHAPTER 4 RELATED WORK

TinyOS, developed at UC Berkeley, is perhaps the earliest sensor OS in the literature. To enable 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 component. 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 supports 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 dynamically 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 semaphores (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 guaranteeing that task deadlines are met. It also supports CPU and network bandwidth reservations, 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 aspects 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 services. LiteOS, developed at the University of Illinois at Urbana Champaign, is designed to provide 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 Unixlike commands.
19
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks 1) 2)
Kernel support for dynamic loading native execution of multithreaded applications. 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 programming. 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 reliability (e.g., t-kernel, Harbor, and Neutron ), providing real-time support (e.g., FIT ), extending the programming model (e.g., protothreads , TOSThreads), and providing reprogramming support (e.g., Deluge, Stream, and Elon ). For a more complete review in the areas of sensor OS design.
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 enhance system us-
20
ability 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 environment for building predictable and efficient sensor network applications. There is much future work to consider. In particular, we would like to examine how SenSpire OSs design principles will enhance the performance of large-scale complex WSN applications.
REFERENCES
1.
I.F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci, Wireless Sensor Networks: 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, ContikiA Lightweight and Flexible Operating System for Tiny Networked Sensors, Proc. 29th Ann. IEEE Intl Conf. Local Computer Networks (LCN 04), 2004.
21
SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks 4.
C.-C. Han, R. Kumar, R. Shea, E. Kohler, and M. Srivastava, A Dynamic Operating System for Sensor Nodes, Proc. Third Intl 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 Intl 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 Intl Conf. Information Processing in Sensor Networks (IPSN 07), 2007.
8.
Q. Cao, T.F. Adbelzaher, and J.A. Stankovic, The LiteOS Operating System: Towards Unix-Like Abstractions for Wireless Sensor Networks, Proc. Seventh Intl 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: Challenges and Approaches, IEEE Network Magazine, vol. 20, no. 3, pp. 48-55, May/June 2006.
22

Sen Sip Ire

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Sen Sip Ire

Hochgeladen von

Copyright:

Verfügbare Formate

SenSpire OS: A Predictable,Flexible and Efficient Operating System for Wireless Sensor Networks

Dept of CS&E, PESITM

CHAPTER 2 DESIGN OF SENSPIRE OS

Figure 1: A overview of SenSpire OS's Design Principle

Dept of CS&E, PESITM

2.1 Approaches for Predictability

2.1.1 Two-Phase Interrupt Servicing

Dept of CS&E, PESITM

Figure 2: The sensetask application in tiny OS versus Senspire OS

2.1.2 Predictive Thread Synchronization

Dept of CS&E, PESITM

Figure 3: Example of unpredictable periods of priority inversion

2.2 Approaches for Flexibility

2.2.1 Hybrid System

Figure 4:SenSpire OS's Hybrid system

Dept of CS&E, PESITM

2.2.2 Differentiated Kernel Scheduling

Dept of CS&E, PESITM

2.2.3 Comparison with Prior Work

Dept of CS&E, PESITM

Figure 5: An Example for Scheduling hierarchy

Figure 6: Comparision of existing hybrid systems

2.3 Approaches for Efficiency

2.3.1 Stack Sharing

Dept of CS&E, PESITM

2.3.2 Modular Design

2.4 Networking Abstraction

2.5 Programming Language

Encapsulation. CSpire forces the application code be encapsulated in classes.

Dept of CS&E, PESITM

Dept of CS&E, PESITM

Figure 7: SenSpire OS design overview

Dept of CS&E, PESITM

Figure 8:Pseudocode for kernel scheduler

CHAPTER 4 RELATED WORK

Dept of CS&E, PESITM

CONCLUSIONS AND FUTURE WORK

Dept of CS&E, PESITM

Dept of CS&E, PESITM

Dept of CS&E, PESITM

Das könnte Ihnen auch gefallen