Choosing a system software architecture for your wireless smart sensor design: Part 3

Anton Hristozov, Union Switch & Signal - December 17, 2007 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