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

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

In addition to the use of main loop plus interrupt service routineapproaches (Part 1) and simple scheduler or home-grown and commercial RTOS configurations (Part 2),the developer of a wireless smart sensor application design hasavailable to him or her a number of other less mainstream alternatives,including virtual machines, state machines andreactive-deadline driven designs.

Thevirtual machine concept,popularized by Sun Microsystems, is very different from thealternatives discussed so far, but with the recent development by thecompany of its Small Programmable Object Technology (SPOT), virtualmachines will become a factor in wireless sensor designs due toincreased CPU power and widespread use of Java technology, even in theembedded world.

I think SPOT is one of the most interesting products from SunMicrosystems since Java was introduced 12 years ago. In this paper weare not going to focus on the Sun Spot product, but rather on thesystem software technology that enables it [13], in particular, Squawk,a virtual machine for Java that came out of Sun's researchlaboratories.

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 isadvised to consider [14]. The Squawk Virtual Machine is a subset of afull blown Java Virtual Machine (JVM). In addition to the standard Javafunctionality, it provides interrupt handling. An interesting and newapproach is that the drivers are written in Java. That is true for mostof the implementation of Squawk, leaving a small portion of native codeimplementation.

Squawk for Sun SPOT JVM uses a split VM architecture in order tosave memory on the device. Classes to be deployed onto the device areverified and transformed into Squawk's internal object representation,which is then saved onto a file called a suite. Suites are then loadedinto the sensors device and are interpreted by the VM on-device.

This allows for a smaller VM to be stored in the sensor device, aswell as faster start-up time for the sensor application. Theimplementation on the device has some unique features to address thefact that Java runs without a RTOS and that it runs on embeddedhardware.

Therefore the mechanisms of garbage collection, thread managementand interrupt handling have special implementations in Squawk. Aninteresting feature is that each application is represented by a Javaobject.

As expected, the application programmer is armed with very rich JavaAPI. This approach obviates the need for a RTOS, because it handlesthreads and interrupts in the JVM. The performance penalty of usingJava is mitigated by ever increasing power of today's 32-bit CPUs. Ifyou have not seen the device and the technology please visit Sun SPOT'sweb site at

There is another example of a Virtual Machine approach from theTinyOS community [19], called Maté. It addresses the problem ofreprogramming sensor nodes, from changing configuration parameters toreplacing application code.

The approach taken defines a set of high-level primitives that areinterpreted by a byte-code interpreter. The claim is that the energyconsumption cost of the byte-code interpreter is justified by thereduced network traffic of the short high-level program capsules.Another benefit is that non-programmer users of WSNs can easilyimplement solutions with a simpler high level approach.

The CM runs in TinyOS environment and uses a stack-basedarchitecture. As the authors suggest, the two-stacks architecture isinfluenced by languages such as FORTH, which was popular in industrialcontrol in the eighties. I'm not sure if Maté is going to growin popularity and be ported to other RTOS solutions for sensornetworks. It seems like a good approach which solves an important issuefor 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 ofstates, and allowed transitions. This approach is fairly predictable,because all the elements are a finite set and are predefined. It seemsto me that most of the code that is designed around a FSM is targetedfor applications, and not so much the system software.

To deal with this limitation, the authors of SensOS [3] have gone astep 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 eventqueue, 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 separatetransition tables and can provide concurrent execution by servicingevents from the input queue in the order of their arrival. It thenperforms a transition and invokes the respective output function toproduce an output.

One benefit is that the application is updated by reloading a newtransition table and installing the new output functions if any areneeded. Yet another advantage is that users can use tools to createtheir state machines and generate code from them. This is a goodapproach for some classes of applications for smart sensors, but it isprobably not very suitable for others, such as data-intensiveapplications.

Timber – A programming language forreal-time systems
Another exotic approach in the form of a specialized language isdescribed in [7]. Timber is a reactive deadline-driven language for embedded programming. It isconcurrent, object-oriented and functional and is derived fromO'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 ownexecution context. There is inter-object communication in the form ofmessages. Through sending a message one can invoke a method fromanother object.

The semantics of Timber specifies that every invoked method has tobe executed within a specified time. This means that timing constraintsare specified in the source code and are made possible by the schedulerat run-time. Timber has a run-time system that allows all that tohappen.

Another interesting feature is that Timber allows dynamicallocation. I know that most of us embedded folks will be a littlepessimistic about doing that in memory restricted devices. The authors[7] claim that the allocation is predictable and that the collector istransparent and incremental without affecting the predictability of thesolution.

Solutions like this one can be a success when the right tools andimplementation make them practical. This seems like a good opportunityfor implementers wanting to create something different.

Conclusions and Future Challenges
I have tried to provide a general outline of how the WSN systemsoftware landscape looks today. Since there are many new developmentsin the hardware of the new smart sensor chips, new software solutionswill become available. Hardware parallelism and new unleashed powerwill make the software architecture for smart sensors even morecompelling.

The ability to put more in silicon and the ubiquitous FPGA andsoft-core solutions will inevitably make a contribution in thisfast-evolving field. Economic forces will shape the solutions to come.As developers we can only benefit from the future smart sensorchallenges.

To read Part 1, go to “The constraints imposed by wireless sensornetworks.”
To read Part 2, go to “Anatomy of an RTOS for small devices.”

Anton Hristozovis a senior embedded software engineer at Union Switch Signal in Pittsburgh,PA. He is currently involved in developing software forcommunications-based train control. He can be reached References
[1] Yangbing Li, MiodragPotkonjak, and Wayne Wolf, “Real-time Operating Systems for EmbeddedComputing”, proceedings of the International Conference on ComputerDesign1997 IEEE

[2] Anand Eswaran, AnthonyRowe, 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 andSeongsoo Hong, “StateMachine Based Operating System Architecture for Wireless Sensor Networks”,PDCAT 2004

[4] Jason Lester Hill, “SystemArchitecture for Wireless Sensor Networks”, University ofCalifornia, Berkeley , Spring 2003

[5] Kirsten Terfloth, GeorgWittenburg and Jochen Schiller, “FACTS ” Arule based Middleware Architecture for Wireless Sensor Networks”,IEEE/ACM International Conference on Information. Processing in SensorNetworks (IPSN), Los Angeles

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

[7] Martin Kero, PerLindgren, Johan Nordlander, “Timber asan RTOS for Small Embedded Devices”, Workshop on Real-WorldWireless Sensor Networks, June 20-21, 2005 Stockholm, Sweden

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

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

[10] Jerry Gipper and DonDingee, “Know your OS options”, Embedded Computing Design, 2007 OpenSystems Publishing

[11] Jennic Ltd., “BasicOperating System API Reference Manual”, 30 Mar, 2007,



[14] Doug Simon, CristinaCifuentes, Dave Cleal, John Daniels and Derek White, “Java on the BareMetal of Wireless Sensor Devices, The Squawk Java Virtual machine”,VEE, Ottawa, July 2006

[15] Jennic Ltd.,”Application Queue Reference Manual”,

[16] Philip Levis, NeilPatel, Scott Shenker, David Culler, “Trickle: ASelf-Regulating Algorithm for Code. Propagation and Maintenance inWireless Sensor Networks.”, In First Symposium on Network SystemsDesign and Implementation (NSDI), Mar. 2004

[17] Shah Bhatti, JamesCarlson, Hui Dai, Jing Deng, Jeff Rose, Anmol Sheth, Brian Shucker,Chrles Gruenwald, Adam Torgerson, Richard Han, “MANTIS OS: Anembedded Multithreaded Operating System for Wireless Micro SensorPlatforms”, Mobile Networks and Applications, June 24, 2005

[18] Philip Levis,University of California, Berkeley; Sam Madden, MIT Computer Scienceand 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 ” TheEmergence of Networking Abstractions and Techniques in TinyOS”,NSDI 2004

[19] Philip Levis and DavidCuller, “Maté” A tiny Virtual machine for Sensor Networks“, InternationalConference on Architectural Support for Programming Languages andOperating Systems, San Jose, CA, USA

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.