Any operating system strives to provide a framework for convenient and easy application software development. Through the use of multitasking and hardware abstractions, an operating system is useful to a programmer because it isolates dependencies from the particular hardware details through the agency of a Hardware Abstraction Layer (HAL).

One of the uses of a real-time OS (RTOS) is to guarantee determinism for real-time performance. It is equipped with facilities which can help the user to meet their application's real-time goals. For the OS to be real time it needs to have a special architecture, especially in the scheduler, a main component of the RTOS.

RTOSes are often classified as either soft real time or hard real time. A hard real-time RTOS is guaranteed to meet the timing requirements, while soft real-time solutions only guarantee these timing deadlines within a range of probability. One of the first design decisions to be made is to answer two questions:

1) Is the system real time or not? (The definition of 'real time' depends on the requirements and absolute time will be a different value for different projects.)

2) If the system is real-time, is it hard real time or soft real time? The answers to these questions will help in the selection of the software architecture. The requirements of the smart sensor wireless sensor network described in Part 1 can be used to help you pin down which alternative you need to deploy.

Shown in Figure 4 below is the typical interaction of the application, the RTOS, the Board Support Package (BSP) and the hardware. The BSP is the collection of drivers that an RTOS would define in order to interface with different hardware. As can be seen, the application can request services from the RTOS, or bypass the RTOS to talk directly to the BSP or hardware.

Depending on how the system is architected some of those links are optional and most RTOS vendors would recommend that it all be done through the RTOS and have the RTOS use its BSP to control the hardware.

Figure 4: Typical Interactions in an embedded design

Concurrency and IPC
A smart sensor design may implement layers through the full range of the seven-layer OSI model. Some layers may not be required for certain applications. For example, the Physical Layer, Data Link Layer and Application Layer must be present for the WSN to function as such. The control of the Physical and Data Link Layers is a parallel activity in the RTOS.

The same can be said for energy control of the smart sensor chip. Adding the networking and transportation layers requires another independent activity. That is why the question of concurrency becomes serious when the networking layer needs to do routing independently from the application layer.

If the smart sensor runs a mesh networking protocol such as Zigbee, and or has a TCP/IP stack in the case of a Zigbee gateway, then the convenience of an RTOS or at least a simple scheduler becomes necessary. With the concurrent execution facilities comes the need for IPC.

Memory Management
Memory management in embedded systems is handled differently depending on speed and capacity restrictions. Another restriction may come from the lack of a Memory Management Unit (MMU) in the smaller embedded CPUs.

This is especially true for smart sensors, where in some cases the CPU is 8-bit and the memory is restricted to several tens of kilobytes. Therefore the usual approach in the RTOS is to use static resource allocation [18]. This means that all buffers are allocated at compile time, thus exposing problems in the design and avoiding unexpected dynamic behavior.

In addition, the RTOS needs to optimize memory usage during resource allocation and during runtime [2]. It seems to me that there is a potential for tools to help the designer of the application to verify the memory offline and during the initial design.

I/O Management
It is hard to come up with an abstraction about all the possible I/O configurations, but there is an opportunity for an RTOS to standardize the reading and control of I/O [2]. Interfaces to common sensors can hide the details in the device drivers' implementation and the RTOS can provide a unified interface for classes of devices to the user.

This means that changing the underlying hardware would not lead to application code changes, but will simply require a new driver which complies with the established interface. The challenge is that the number of possible device driver classes is overwhelming compared to a standard embedded system with just serial and Ethernet interfaces and no sensors attached.

Similarly to how Zigbee classifies types of devices, an RTOS can support classes of drivers. Another issue in handling I/O is buffering, which also can be done by the RTOS and not the application code.

Network Management
A big portion of the RTOS functionality is the support for network protocols. Routing protocols in WSNs are special and can be tailored to the specific needs of the application. The energy conserving approach requires routing to be done efficiently. The same is true for data exchanges between nodes in the network.

Therefore the RTOS needs to have an architecture that supports easy installation of new wireless networking protocols. Handling collisions with special protocols is a subject of ongoing research in the area. Aggregating several packets into one and transferring in one burst is another feature of these protocols [2]. Nano-RK takes the approach of socket-like abstraction for the application, which is a convenient and well-known approach for software developers.

Dynamic Downloadable Modules and Services
The benefit of being able to change the application code while preserving the relatively static RTOS kernel is attractive, especially when precious energy needs to be spared while transmitting only the bytes of the changed application or part of the application to the device. A good example in this area is the Contiki RTOS. The curious reader is advised to take a look at [6], which is an excellent paper.

The separation of the base functionality of the RTOS and the application code is used in many other RTOS solutions. I have seen the same approach in the commercial RTOS OSE from Enea and in Integrity from Green Hills. Contiki defines applications and services as loadable modules. In Contiki, a service contains common functionality that can be used by other processes. Examples are protocol stacks, sensor data handling, etc. The dynamic downloadable modules are related to the software updating strategies.

Energy Conservation Awareness
Smart sensors frequently depend on batteries. Based on how the application runs and what hardware resources are used, these batteries can be depleted quickly. The range of operation between changing the batteries may vary from several hours to years, based on the current drawn from them. Some newer chips allow for shutting down parts of the CPU for judicious energy saving. Similarly, other parts of the hardware besides the CPU can be designed to be controlled to enter a low consumption mode.

The RTOS can provide power saving mechanisms, which are abstracted from the particular hardware. If there is no RTOS used or if the RTOS does not have power saving mechanisms, then the application needs to do that. The control of the energy saving mode is so hardware dependent and varied from platform to platform, it is generally easier to have the application control the hardware directly or through an Application Programming Interface (API) provided by the chip manufacturers.

The MANTIS OS [17] has an interesting method of detecting when the system has no pending work for the tasks and putting the system to sleep. This seems like an ambitious task when taking into account dynamic changes, based on the timing requirements from the tasks and the changing load of the system in general. Contiki [6] takes a different approach and exposes the size of the event queue to the application, which decides how much work is pending for the running tasks and can go into energy saving mode or not.

The other side of the spectrum is when the RTOS does not give any indication and the application cannot decide when to control the power. The wake-up mechanism with RTOS or application control is based on an interrupt from a timer or an external source. This is an increasingly important topic and it is expected that more and more power saving algorithms will be embedded in RTOS architectures or some other from of system software for smart sensors.

Software Updating Strategies
Since WSNs are predicted to grow quickly and have many nodes, software updating becomes a challenge, but there are strategies for doing that. An example is the algorithm Trickle described in [16]. Over-the-air-programming (OTA) allows such updates to be performed wirelessly. Contiki supports an OTA protocol, described in [6].

The binary is sent to a selected concentrator node, which after successful reception of the entire binary image disseminates it to the neighboring sensor nodes. There is an error handling mechanism to facilitate the transmission between the concentrator and end nodes. Like any communication over the air, especially when software updates are concerned, the issue of security is an important one. The biggest challenges of OTA are: the time it takes to complete the task, the robustness of the protocol, and security.

Time Synchronization
Depending on the application, time synchronization may be or may not be needed. When it is needed, it is not a trivial problem to solve. One technique described in [18] uses a hook to place a timestamp in the packet. TinyOS provides set-and-get of the current system time as well as timestamps in messages, leaving the application to decide when to use those facilities.

Another approach is to use the Network Time Protocol [NTP], although its use can introduce errors in an environment as time sensitive as TinyOS [18]. There are other time synchronization protocols, such as the RTS IEEE 1588 Precision Time protocol

Table 1: Non-Commercial RTOSes

Commercial and non-commercial RTOSes
As a part of my research, I tried to run down RTOS solutions suitable for both commercial (Table 1, above), and non-commercial (Table 2, below) RTOSes in wireless sensor network designs.

Table 2: Commercial RTOSes

If I missed any it was due to my time limitations or information availability. Reader feedback is welcome to uncover other existing software gems.

Next in Part 3: Virtual machines, state machines and reactive deadline driven methods
To read Part 1, go to "The constraints imposed by wireless sensor networks."

Anton Hristozov is a senior embedded software engineer at Union Switch Signal in Pittsburgh, PA. He is currently involved in developing software for communications-based train control. He can be reached at antonhr@verizon.net

References
[1] Yangbing Li, Miodrag Potkonjak, and Wayne Wolf, "Real-time Operating Systems for Embedded Computing", proceedings of the International Conference on Computer Design1997 IEEE

[2] Anand Eswaran, Anthony Rowe, and Raj Rajkumar, "Nano-RK: an Energy "aware Resource-centric RTOS for sensor networks", Real-Time Systems Symposium, 2005. RTSS 2005. 26th IEEE International

[3] Tae-Hyung Kim and Seongsoo Hong, "State Machine Based Operating System Architecture for Wireless Sensor Networks", PDCAT 2004

[4] Jason Lester Hill, "System Architecture for Wireless Sensor Networks", University of California, Berkeley , Spring 2003

[5] Kirsten Terfloth, Georg Wittenburg and Jochen Schiller, "FACTS " A rule based Middleware Architecture for Wireless Sensor Networks", IEEE/ACM International Conference on Information. Processing in Sensor Networks (IPSN), Los Angeles

[6] Adam Dunkels, Björn Grönvall, Thiemo Voight, "Contiki " A light weight and Flexible Operating System for Tiny Networked Sensors", In Proceedings of the First IEEE Workshop on Embedded Networked Sensors 2004 (IEEE EmNetS-I), Tampa, Florida, USA, November 2004.

[7] Martin Kero, Per Lindgren, Johan Nordlander, "Timber as an RTOS for Small Embedded Devices", Workshop on Real-World Wireless Sensor Networks, June 20-21, 2005 Stockholm, Sweden

[8] David Gay, Philip Levis, Robert von Behren, "The nesC Language : A Holistic Approach to Networked Embedded Systems", Conference on Programming Language Design and Implementation, Proceedings of the ACM SIGPLAN 2003 conference on Programming language and Design and Implementation, April 29, 2003

[9] David E. Culler , PhD, Arch Rock Corp. "TinyOS: Operating System Design for Wireless Sensor Networks", Sensor Magazine, May 1, 2006

[10] Jerry Gipper and Don Dingee, "Know your OS options", Embedded Computing Design, 2007 Open Systems Publishing

[11] Jennic Ltd., "Basic Operating System API Reference Manual", 30 Mar, 2007, http://www.jennic.com/support/view_file.php?fileID=0000000043

[12] http://www.sunspotworld.com/docs/

[13] http://research.sun.com/projects/squawk/

[14] Doug Simon, Cristina Cifuentes, Dave Cleal, John Daniels and Derek White, "Java on the Bare Metal of Wireless Sensor Devices, The Squawk Java Virtual machine", VEE, Ottawa, July 2006

[15] Jennic Ltd., "Application Queue Reference Manual", http://www.jennic.com/support/view_file.php?fileID=0000000095

[16] Philip Levis, Neil Patel, Scott Shenker, David Culler, "Trickle: A Self-Regulating Algorithm for Code. Propagation and Maintenance in Wireless Sensor Networks.", In First Symposium on Network Systems Design and Implementation (NSDI), Mar. 2004

[17] Shah Bhatti, James Carlson, Hui Dai, Jing Deng, Jeff Rose, Anmol Sheth, Brian Shucker, Chrles Gruenwald, Adam Torgerson, Richard Han, "MANTIS OS: An embedded Multithreaded Operating System for Wireless Micro Sensor Platforms", Mobile Networks and Applications, June 24, 2005

[18] Philip Levis, University of California, Berkeley; Sam Madden, MIT Computer Science and Artificial Intelligence Laboratory, and Intel Research Berkeley; David Gay, Intel Research Berkeley; Joseph Polastre, Robert Szewczyk, Alec Woo, Eric Brewer, and David Culler, University of California, Berkeley " The Emergence of Networking Abstractions and Techniques in TinyOS", NSDI 2004

[19] Philip Levis and David Culler, "Maté " A tiny Virtual machine for Sensor Networks", International Conference on Architectural Support for Programming Languages and Operating Systems, San Jose, CA, USA