Wsnopsys Article 159 Final 159

OPERATING SYSTEMS FOR WIRELESS SENSOR NETWORKS: AN OVERVIEW Daniele De Caneva, Pier Luca Montessoro and Davide Pierattoni DIEGM – University of Udine, Italy {daniele.decaneva; montessoro; pierattoni}@uniud.it

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.

1

INTRODUCTION

Thanks to the well known “Moore’s Law” integrated circuits are becoming smaller, cheaper and less power consuming. This trend has led to the emergence of complete systems on a chip with integrated low power communication and transducer capabilities. The consequence is the opening of the ubiquitous computing era, in which electronic systems will be all around us, providing all kind of information services to users in a distributed, omnipresent but nearly invisible fashion. One of the most important applications that new technologies are enabling is the paradigm of Wireless Sensor Networks (WSNs), where hundreds or even thousands of tiny sensors with communication capabilities will organize themselves to collect important environmental data or monitor areas for security purposes. The hardware for WSNs is ready and many applications have become a reality, nevertheless the missing of a commonly accepted system architecture and methodology constitute a curb to the expansion and the improvement of such technologies. Aware of that, many research groups in the world have proposed their own system architecture. The key point in all these proposals is the capability of the software to manage a considerable number of sensors. In particular, there is a tradeoff between the responsiveness of the system and the extremely scarce resources of the nodes in terms of power supply, memory and computational capabilities. In this article will be presented an overview of

the most known operating systems designed for WSNs. Without proposing direct comparisons, we describe the key features of these architectures, the challenges that led their development, with the aim of helping the reader to choose among these systems the one that best suites his/her purposes. 2

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.

Ubiquitous Computing and Communication Journal

1

In TinyOS neither blocking nor polling operation is permitted and the CPU doesn’t waste time in actively looking for interesting events; on the contrary, unused CPU cycles are spent in a sleep state. System configuration can be summarized in a tiny scheduler and a set of components. The scheduler is a simple FIFO utilizing a bounded size scheduling data structure for efficiency, nonetheless a more sophisticated scheduling policy could be implemented. When the task queue is empty, the CPU is forced to the sleep state waiting for an hardware event to trigger the scheduling of the event-associated tasks. Tasks in the TinyOS architecture are atomic and run to completion although they can be preempted by events. This semantics of tasks allows the allocation of a single stack, which is an important feature in memory constrained systems. Three types of components were thought to constitute the TinyOS architecture. The first type of components are the “hardware abstraction” which map physical hardware like I/O devices into component models. The second type of components is called “synthetic hardware” and simulates the behavior of advanced hardware; often synthetic hardware sits on top of the hardware abstraction components. The last type of components are the “high level software” components, which perform control, routing and all data transformations such as data aggregation and manipulation. This kind of abstraction of hardware and software in the component model is intended to ease the exploitation of tradeoffs between the scale of integration, the power requirements and the cost of the system. Every component owns a fixed-size frame that is statically allocated: this allows to know exactly the memory requirements of a component at compile time and prevents the overhead associated with dynamic allocation. TinyOS was originally developed in C, giving the system the capability of targeting multiple CPU architectures. However, the system was afterwards re-implemented in nesC: this is a programming language specific for networked embedded systems, whose key focus is holistic approach in design. It’s remarkable that for TinyOS a byte-code interpreter has been developed that makes the system accessible to non-expert programmers and enables quick and efficient programming of a whole WSN. This interpreter, called Maté, depicts the program’s code as made of capsules. Thanks to the beaconless, ad-hoc routing protocol implemented in Maté, when a sensor node receives a newer version of a capsule, it will install it. Through a hop-by-hop code injection, Maté can update the code of the entire network.

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

Ubiquitous Computing and Communication Journal

2

across heterogeneous platforms. It extends beyond simulation permitting the coexistence of both virtual and physical nodes in the same network. This feature is derived directly by the system code architecture, which can run without modifications on virtual nodes within an x86 architecture. Dynamic reprogramming in MANTIS is implemented as a system call library, which is built into the kernel. There are different granularities of reprogramming: entire kernel reflashing, reprogramming of a single thread, changing of variables within the thread. Along with dynamic reprogramming, an important feature has been also developed: the Remote Shell and Command Server which allows the user “logging in” into a node and taking control of it. The server is implemented as an application thread and gives the user the ability to alter node’s configuration, run or kill programs, inspect and modify the inner state of the node.

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 WSN’s 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 system’s EEPROM memory. Shared libraries like user programs may be replaced in deployed systems by using the dynamic

linking. Dynamic linking is based on synchronous events: a library function is invoked by issuing an event generated by the caller program. The event broadcasts the request to all the libraries and a rendezvous protocol is used to find out the library that implements the required function. When the correct library has completed the call, the control returns back to the calling process. Since dynamic linking bases its functioning on synchronous events, it is essential that context switching overhead is as small as possible, in order to have a good system performance. Contiki developers have granted this by implementing processes as event handlers, which run without separate protection domains. The flexible mechanism of dynamic linking allowed Contiki researchers to implement multithreading as a library optionally linked with programs. Another important component based on a shared library is the communication stack. Implementing the communication stack as a library allows its dynamic replacement and, more precisely, if the stack is split into different libraries it becomes easy to replace a communication layer on the run.

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

Ubiquitous Computing and Communication Journal

3

of organizing the heap area into a number of different disjoint pools, and a set of configurable device drivers including serial ports, LCD displays and Ethernet interfaces.

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

EYES European project and tries to address the problems of scarce resources in terms of both the memory and power supply and the need for distribution and reconfiguration capabilities. The researchers found solution to these problems developing a event-driven system. In fact, EYES OS is structured in modules that are executed as responses to external events, leaving the system in a power saving mode when there is no external event to serve. Every module can ask for several tasks to be performed; each task in turn defines a certain block of code that runs to completion. In this paradigm, no blocking operation is permitted and no polling operation should be instantiated: the programmer instead will use interrupts to wake up the system when the needed input becomes available. The system provides a scheduler which can be implemented as a simple FIFO or a more sophisticated algorithm. The interrupts are also seen as tasks scheduled and ready to be executed. In the EYES architecture there are two system layers of abstraction. The first layer is the “Sensor and Networking Layer”, which provides an API for the sensor nodes and the network protocols. The second layer is the “Distributed Services Layer”, which exposes an API for mobile sensor applications support. In particular, two services belong to this layer: the “Lookup Service” and the “Information Service”. The first supports mobility, instantiation and reconfiguration, while the latter deals with aspects of collecting data. On top of cited layers stand the user applications. The EYES OS provides a four-step procedure for code distribution, designed to update the code into nodes, including the operating system. This procedure is resilient to packet losses during the update, using as few communication and local resources as possible and halting the node operations only for a short period.

3

CONCLUSIONS

The operating systems here described present different approaches to the common problems of WSNs. It is not in the aim of this article to express opinions about the presented systems; nevertheless, some general guidelines could be drawn from the work experience made by all the esteemed researchers. We present now some guidelines for the development of the next generation of WSN operating systems, that should help both researchers and users. The constrained nature of resources in embedded systems is definitely evident, so a small, efficient code is a primary goal, as well as power-aware policies are an obligatory

Ubiquitous Computing and Communication Journal

4

Table 1: summary of WSN OS features.

Objectives

Structure

Special features

Objectives Structure

Special features

Objectives

Structure

Special features

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

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

Two on-line special algorithms to reduce energy consumption

Each process thought as a FSM Multiplexing at state boundaries Written in C Memory allocator A set of configurable device drivers

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

Ubiquitous Computing and Communication Journal

5

condition to exploit the efficiency in WSN applications. To ensure a proper functioning of a network, which is constituted by unattended nodes that could have been deployed in a harsh environment, the operating system must provide a mechanism for self-organization and reorganization in case of node failures. A WSN, especially if composed of a huge number of nodes, must behave as a distributed system, exposing an interface where data and processes are accessible and manageable like it happens with databases. A large number of nodes carries also the need for an easy, yet power efficient way to program the network, which should be also usable after the deployment and without affecting normal functioning. Such a programming (and reprogramming) procedure must be robust to interference and to all other causes of transmission failures during the dissemination of code chunks. While the entire reprogramming of the core of the system may not be necessary, the applications must be patched, updated or even totally changed if the main purpose of the WSN is changed. This leads to the preference, if possible, of different levels of re-programming granularity. The operating system must treat wireless communication interfaces as special resources, providing a set of different power aware communication protocols. The system has to choose the proper protocol, according to the current environment state and application needs. The operating system should be portable to different platforms: this is necessary both for the possible presence of nodes with different tasks and for the opportunity of a post-deployment of newer sensors, which could be placed in order to reintegrate the network node set. The operating system should provide a platform for fast prototyping, testing and debugging application programs. In this context it is remarkable to note that, if the WSN paradigm will spread in a kaleidoscopic set of applications, touching many aspects of our life,

then program developers will not be just communication and computer engineers. It appears clear that, in order to support nontechnical developers, a really simple API or even an application-typology programming language must be provided, alongside with the “normal” and more efficient API. Making WSN easy to use will make them more attractive and step up their diffusion. 4

REFERENCES

[1] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, K. Pister: System Architecture Directions for Networked Sensors, ASPLOS. (2000). [2] K. Sohraby, D. Minoli, T. Znati: Wireless Sensor Networks: technology, Protocols and Applications, John Wiley & Sons Inc. (2007). [3] H. Abrach, S. Bhatti, J. Carlson, H. Dai J. Rose, A. sheth, B. Sheth, B. Shucker, J. Deng, R. Han: MANTIS: System Support for MultimodAl NeTworks of In-situ Sensors, Proceedings of the 2nd ACM International Conference on Wireless Sensor Networks and Applications. (2003). [4] A. Dunkels, B. Grönvall, T. Voigt, J. Alonso: The Design for a Lightweight Portable Operating System for Tiny Networked Sensor Devices, SICS Technical Report (2004). [5] E. Akhmetshina, P. Gburzynski, F. Vizecoumar: PicOS: A Tiny Operation System for Extremely Small Embedded Platforms, Proceedings of the Conference on Embedded System and Applications ESA’02 (2002). [6] R. Barr, J. Bicket, D. S. Dantas, B. Du, T.W.D. Kim, B. Zhou, E. Sirer: On the need for systemlevel support for ad hoc and sensor networks, SIGOPS Oper. Syst. Rev. (2002). [7] S. Dulman, P. Havinga: Operating System Fundamentals for the EYES Distributed Sensor Network, Proceedings of Progress’02 (2002).

Ubiquitous Computing and Communication Journal

2