The smart sensors used in wireless industrial and building automation applications are often characterized by energy restrictions, small CPUs, and small memory footprints. The limited resources of the hardware make special applications necessary, which in turn create special requirements for the system software.

This three part series outlines the factors a developer needs to consider when choosing system software for Wireless Sensor Networks (WSNs) to be used in embedded designs.

While there will be extensive discussion of appropriate RTOSes and features, this series will also evaluate alternative approaches, both commercial and non-commercial, for use in small footprint embedded systems, and will also discuss the usefulness of such approaches in WSNs. Commercial and non-commercial solutions are listed for reference and further exploration of the subject. Some of these approaches might not be familiar to the working embedded developer.

Some of these applications are easy to implement without a RTOS, some require a simple scheduler approach, and some warrant a full-fledged RTOS from a commercial vendor or from some of the non-commercial sources discussed in this article. The hardware architectures of the smart sensor devices as well as their use as network devices are characterized with the following specifics:

* Restricted CPU power
* Restricted available memory
* Limited energy supply, mainly provided by batteries or alternative sources such as the sun, vibrations, etc.
* Software update challenges such as the Over The Air (OTA) approach
* Changeable network topology
* Dimensions and weight restrictions, which can lead to cooling and CPU usage restrictions

All these specifics of smart sensors require special attention when designing or considering the software architecture. There are several approaches that can satisfy the constraints of such designs, including:

* Main loop plus interrupt service routine approaches (Part 1)
* Simple scheduler or home-grown RTOS configurations (Part 2)
* Virtual machines, state machines and reactive-deadline driven designs (Part 3)

Main loop plus interrupt service routines approach
This approach is a standard one for small software implementations and is a good solution when there is no need for well separated parallel execution. The parallelism is achieved through the Interrupt Service Routines (ISR), which get triggered by a software or hardware interrupt. The main loop is a forever loop which repeats the same activities forever. Its flow is suspended when an interrupt occurs while the interrupt is being processed by the ISR. The pseudo code in Figure 1 below illustrates the solution.

However, there are several problems with this approach. First, it inevitably leads to the use of variables with global scope. Second, it is hard to separate the application into independent modules that have their own timing constraints. The dependencies of such implementation are too many and therefore changes are hard to maintain.

Third, the ISRs need to execute fast and return when done. This creates delays for certain activities and often means that the ISR needs to schedule something to happen. The actual processing needs to happen when control returns to this point in the main loop.

Depending on when the interrupt occurred, a full loop cycle may pass before the requested action by the ISR is executed by the main loop software. In other words, this solution is the easiest to create, but is the least flexible choice. It is suitable to small, well-defined applications where minimal changes and maintenance are anticipated over the life of the design. Because of the inflexibility, it amazes me how many systems " some of which are not so small " still use this approach.

Figure 1 ISR Pseudo Code

One way to overcome limitations of the ISR approach is to provide a layer that queues all interrupt sources and the data associated with them. The application processes the queue entries in the order of their arrival, thus making the application code well organized . This technique, shown on Figure 2 below, is used by Jennic in its application queue implementation [15].

In this design, two output queues are provided for MCPS and MLME events from the 802.15.4 stack layer and one queue for all hardware interrupts. Thus the application can check all three queues in the main loop and process the queued events and interrupts accordingly. If latency is not an issue, this approach is cleaner than having many ISRs. If there are some latency sensitive events, some minimal reconfiguration of the ISR is in order to meet the real-time requirements.

Figure 2: Jennic application queue structure

The simple scheduler or the home grown RTOS solution
A much more flexible way to go is to use a simple task scheduler, which has the advantage of allowing the creation of tasks. The term 'task' as used in this article is equivalent to a light process or thread. Tasks allow the software solution to be divided into independent execution contexts having their own logic. Having their own context is especially beneficial for local encapsulated variables, thus reducing the necessity for global variables.

There needs to be some form of Inter Process Communication (IPC) in order to exchange information between tasks, but this is done through the framework and is not directly controlled by the tasks. The tasks can exchange messages, events, signals, etc. through message queues that the solution needs to provide. So in addition to the scheduler there can be IPC mechanisms, energy saving mechanisms, memory management mechanisms and so on. This approach is illustrated in Figure 3 below.

Figure 3: IPC framework

One can argue that this is a small RTOS with nothing but the basic functionality to achieve parallel software execution in order to achieve deterministic behavior. A modern example could be Basic Operating System (BOS) from Jennic. A reference document can be found at www.jennic.com/support.

The overall functionality may vary, depending on the designer's goals, but the main steps in implementing this approach include:

* Initialization of the scheduler, which allocates resources and creates the framework for IPC and task entry points
* Creation of task code
* Starting the scheduler, which starts the tasks and the scheduling algorithm
* Handling of tasks and message queues for as long as there are tasks running

All the tasks have the same priority and run to completion, which in many cases means they run forever. The scheduler usually runs in a round-robin fashion and allows tasks to be executed in turn. It assigns time slices to each task in equal portions and in order, handling all tasks without priority.

The round-robin approach is suitable when there are only a small number of tasks that do not need to be run with different priorities. If the scheduler needs to provide preemptive execution based on priorities of tasks, then the complexity of the system software solution rises significantly.

The creation of such a solution is moderately difficult. The reality is that it requires some experience with the hardware architecture as well as understanding of real-time concurrent software development. Another disadvantage is that it is a custom solution and a reinventing-the-wheel type of activity.

Still, home-grown RTOS solutions are perceived by some to be economically feasible. However, my belief is that an already developed RTOS is the way to go, and as you will see in the next part in this series there are a lot to choose from in both the commercial and in the non-commercial arenas. Even for those of us who hope to spruce up our own RTOSes once the kids have gone off to college and we have more time, the availability of already created RTOSes to cover almost any situation makes re-inventing the wheel impractical. Porting an existing RTOS to a sensor board is much easier and a less risky approach than creating your own.

Next in Part 2: Anatomy of an RTOS for small devices.

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