11-08-2012, 04:39 PM
SenSpire OS, a predictable, flexible, and efficient operating system for WSNs.
[attachment=31188]
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.
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 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.
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.
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 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.
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 OS’s integral design goals distinguish its hybrid system design from existing works. The hybrid model of SenSpire OS has the following features.
[attachment=31188]
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.
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 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.
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.
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 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.
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 OS’s integral design goals distinguish its hybrid system design from existing works. The hybrid model of SenSpire OS has the following features.