In addition to the use of main loop plus interrupt service routineapproaches (
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 , 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
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 www.sunspotworld.com.
There is another example of a Virtual Machine approach from theTinyOS community , 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  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 . Timber is a reactive deadline-driven language
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 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 “
To read Part 2, go to “
Anton Hristozovis a senior embedded software engineer at
 Yangbing Li, MiodragPotkonjak, and Wayne Wolf, “Real-time Operating Systems for EmbeddedComputing”, proceedings of the International Conference on ComputerDesign1997 IEEE
 Anand Eswaran, AnthonyRowe, and Raj Rajkumar, “
 Tae-Hyung Kim andSeongsoo Hong, “
 Jason Lester Hill, “
 Kirsten Terfloth, GeorgWittenburg and Jochen Schiller, “
 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.
 Martin Kero, PerLindgren, Johan Nordlander, “
 David Gay, Philip Levis,Robert von Behren, “
 David E. Culler , PhD,Arch Rock Corp. “
 Jerry Gipper and DonDingee, “Know your OS options”, Embedded Computing Design, 2007 OpenSystems Publishing
 Jennic Ltd., “BasicOperating System API Reference Manual”, 30 Mar, 2007,
 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
 Jennic Ltd.,”Application Queue Reference Manual”,
 Philip Levis, NeilPatel, Scott Shenker, David Culler, “
 Shah Bhatti, JamesCarlson, Hui Dai, Jing Deng, Jeff Rose, Anmol Sheth, Brian Shucker,Chrles Gruenwald, Adam Torgerson, Richard Han, “
 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 ”
 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