Choosing the best system software architecture for your wireless smart sensor design: Part 1

Anton Hristozov 12/4/2007 5:32 PM EST

Anton Hristozov evaluates the factors you need to consider in selecting the best system software architecture for your embedded wireless sensor Network (WSN) design. First in a three part series. 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-thewheel 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 Resourcecentric 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, Bjrn Grnvall, 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

Choosing the best system software architecture for your wireless smart sensor design: Part 2
Anton Hristozov, Union Switch & Signal - Pittsburgh, PA 12/10/2007 3:13 PM EST
In this second in a series, Anton Hristozov evaluates the factors you need to consider in selecting the best system software architecture for your embedded wireless sensor Network (WSN) design. This week: anatomy of a small device RTOS 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 Resourcecentric 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, Bjrn Grnvall, 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

Choosing a system software architecture for your wireless smart sensor design: Part 3
Anton Hristozov, Union Switch & Signal 12/17/2007 10:30 PM EST
Anton Hristozov evaluates the factors you need to consider in selecting the best system software architecture for your embedded wireless sensor Network (WSN) design with particular focus on virtual and state machines and reactive deadline driven methods. In addition to the use of main loop plus interrupt service routine approaches (Part 1) and simple scheduler or home-grown and commercial RTOS configurations (Part 2), the developer of a wireless smart sensor application design has available to him or her a number of other less mainstream alternatives, including virtual machines, state machines and reactive-deadline driven designs. The virtual machine concept, popularized by Sun Microsystems, is very different from the alternatives discussed so far, but with the recent development by the company of its Small Programmable Object Technology (SPOT), virtual machines will become a factor in wireless sensor designs due to increased CPU power and widespread use of Java technology, even in the embedded world. I think SPOT is one of the most interesting products from Sun Microsystems since Java was introduced 12 years ago. In this paper we are not going to focus on the Sun Spot product, but rather on the system software technology that enables it [13], in particular, Squawk, a virtual machine for Java that came out of Sun's research laboratories. Squawk - a Java VM for sensor apps Squawk has a small footprint, is Java compliant, and is Connected Limited Device Configuration (CLDC) compatible. For a complete description the reader is advised to consider [14]. The Squawk Virtual Machine is a subset of a full blown Java Virtual Machine (JVM). In addition to the standard Java functionality, it provides interrupt handling. An interesting and new approach is that the drivers are written in Java. That is true for most of the implementation of Squawk, leaving a small portion of native code implementation. Squawk for Sun SPOT JVM uses a split VM architecture in order to save memory on the device. Classes to be deployed onto the device are verified and transformed into Squawk's internal object representation, which is then saved onto a file called a suite. Suites are then loaded into the sensors device and are interpreted by the VM on-device. This allows for a smaller VM to be stored in the sensor device, as well as faster start-up time for the sensor application. The implementation on the device has some unique features to address the fact that Java runs without a RTOS and that it runs on embedded hardware.

Therefore the mechanisms of garbage collection, thread management and interrupt handling have special implementations in Squawk. An interesting feature is that each application is represented by a Java object. As expected, the application programmer is armed with very rich Java API. This approach obviates the need for a RTOS, because it handles threads and interrupts in the JVM. The performance penalty of using Java is mitigated by ever increasing power of today's 32-bit CPUs. If you have not seen the device and the technology please visit Sun SPOT's web site at www.sunspotworld.com. There is another example of a Virtual Machine approach from the TinyOS community [19], called Mat. It addresses the problem of reprogramming sensor nodes, from changing configuration parameters to replacing application code. The approach taken defines a set of high-level primitives that are interpreted by a byte-code interpreter. The claim is that the energy consumption cost of the byte-code interpreter is justified by the reduced network traffic of the short high-level program capsules. Another benefit is that non-programmer users of WSNs can easily implement solutions with a simpler high level approach. The CM runs in TinyOS environment and uses a stack-based architecture. As the authors suggest, the two-stacks architecture is influenced by languages such as FORTH, which was popular in industrial control in the eighties. I'm not sure if Mat is going to grow in popularity and be ported to other RTOS solutions for sensor networks. It seems like a good approach which solves an important issue for WSN use. State Machine Architecture Approach Using Finite State Machines (FSM) is popular among embedded developers. An FSM is described by an initial state, set of inputs, outputs, set of states, and allowed transitions. This approach is fairly predictable, because all the elements are a finite set and are predefined. It seems to me that most of the code that is designed around a FSM is targeted for applications, and not so much the system software. To deal with this limitation, the authors of SensOS [3] have gone a step further and have generalized that approach into their RTOS. SensOS, like other RTOS solutions, has an event queue for the inputs. In addition it has a state sequencer accepting inputs from the event queue, a collection of callback functions that generate the outputs, and a transition table that represents the possible transitions. The RTOS can host multiple applications with their separate transition tables and can provide concurrent execution by servicing events from the input queue in the order of their arrival. It then performs a transition and invokes the respective output function to produce an output. One benefit is that the application is updated by reloading a new transition table and installing the new output functions if any are needed. Yet another advantage is that users can use tools to create their state machines and generate code from them. This is a good approach for some

classes of applications for smart sensors, but it is probably not very suitable for others, such as data-intensive applications. Timber - A programming language for real-time systems Another exotic approach in the form of a specialized language is described in [7]. Timber is a reactive deadline-driven language for embedded programming. It is concurrent, object-oriented and functional and is derived from O'Haskell. There is no division of application and RTOS, as we saw in Figure 4, but rather the application and the run-time environment form one unit. The language allows concurrently executing objects in their own execution context. There is inter-object communication in the form of messages. Through sending a message one can invoke a method from another object. The semantics of Timber specifies that every invoked method has to be executed within a specified time. This means that timing constraints are specified in the source code and are made possible by the scheduler at run-time. Timber has a run-time system that allows all that to happen. Another interesting feature is that Timber allows dynamic allocation. I know that most of us embedded folks will be a little pessimistic about doing that in memory restricted devices. The authors [7] claim that the allocation is predictable and that the collector is transparent and incremental without affecting the predictability of the solution. Solutions like this one can be a success when the right tools and implementation make them practical. This seems like a good opportunity for implementers wanting to create something different. Conclusions and Future Challenges I have tried to provide a general outline of how the WSN system software landscape looks today. Since there are many new developments in the hardware of the new smart sensor chips, new software solutions will become available. Hardware parallelism and new unleashed power will make the software architecture for smart sensors even more compelling. The ability to put more in silicon and the ubiquitous FPGA and soft-core solutions will inevitably make a contribution in this fast-evolving field. Economic forces will shape the solutions to come. As developers we can only benefit from the future smart sensor challenges. To read Part 1, go to "The constraints imposed by wireless sensor networks." To read Part 2, go to "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 Resourcecentric 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, Bjrn Grnvall, 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