works
TinyOS [29] is probably the earliest operating system that directly targets the specific applications and limitations of sensor devices. TinyOS is built around a lightweight event scheduler where all program execution is performed in tasks that run to completion. TinyOS uses a special description language for com- posing a system of smaller components [21] that are statically linked with the kernel to a complete monolithic binary image of the system. After linking, modifying the system is not possible [42]. The Contiki system is also designed around a lightweight event-scheduler, but is designed to allow loading, unload- ing, and replacing modules at run-time.
To load new applications in an operating system where the entire system is compiled into a monolithic binary, the entire system binary must be up- dated. Since the energy consumption of distributing code in sensor networks increases with the size of the code to be distributed several attempts have been made to reduce the size of the code to be distributed. Reijers and Langen- doen [60] produce an edit script based on the difference between the modified and original binary system image. After a number of optimizations including architecture-dependent ones, the script is distributed throughout the network. A similar approach has been developed by Jeong and Culler [32] who use the rsync algorithm to generate the difference between modified and original exe- cutable. Koshy and Pandey’s diff-based approach [37] reduces the amount of flash rewriting by modifying the linking procedure so that functions that are not changed are not shifted.
FlexCup [49] uses another approach to enable run-time installation of TinyOS software components: loadable applications include the symbolic
4.2 Operating Systems for Wireless Sensor Networks 23
names of functions in the loaded application. When an application is loaded, the symbolic names are resolved and the loaded binary is updated. FlexCup uses a complete duplicate image of the system’s monolithic binary image that is stored in external flash ROM. The copy of the system image is used for constructing a new system image when a new program has been loaded. How- ever, FlexCup uses a non-standard format and is less portable than the loader in Contiki. Further, FlexCup requires a reboot after a program has been installed, requiring an external mechanism to save and restore the state of all other ap- plications as well as the state of running network protocols across the reboot. Contiki does not need to be rebooted after a program has been installed. Also the Contiki dynamic linker does not alter the core image when programs are loaded and therefore no external copy of the core image needs to be stored.
In order to provide run-time reprogramming for TinyOS, Levis and Culler have developed Mat´e [42], a virtual machine for TinyOS devices. Code for the virtual machine can be downloaded into the system at run-time. The virtual machine is specifically designed for the needs of typical sensor network appli- cations. Similarly, the MagnetOS [10] system uses a virtual Java machine to distribute applications across the sensor network. The advantages of using a virtual machine instead of native machine code is that the virtual machine code can be made smaller, thus reducing the energy consumption of transporting the code over the network. One of the drawbacks is the increased energy spent in interpreting the code—for long running programs the energy saved during the transport of the binary code is instead spent in the overhead of executing the code. Contiki does not suffer from the executional overhead since modules loaded into Contiki are compiled to native machine code.
The Mantis system [5] uses a traditional preemptive multi-threaded model of operation. Mantis enables reprogramming of both the entire operating sys- tem and parts of the program memory by downloading a program image onto EEPROM, from where it can be burned into flash ROM. Due to the multi- threaded semantics, every Mantis program must have stack space allocated from the system heap, and locking mechanisms must be used to achieve mu- tual exclusion of shared variables. In Contiki, only programs that explicitly require multi-threading need to allocate an extra stack.
Systems that offer loadable modules besides Contiki include SOS [26] and Impala [46]. Impala features an application updater that enables software up- dates to be performed by linking in updated modules. Updates in Impala are coarse-grained since cross-references between different modules are not pos- sible. Also, the software updater in Impala was only implemented for much more resource-rich hardware than the memory-constrained systems considered
24 Chapter 4. Related Work
in this thesis. SOS [26], which was published after Contiki, is similar in design to Contiki: SOS consists of a small kernel and dynamically-loaded modules. However, unlike Contiki SOS uses position independent code to achieve relo- cation and jump tables for application programs to access the operating system kernel. Application programs can register function pointers with the operat- ing system for performing inter-process communication. Position independent code is not available for all platforms, however, which limits the applicability of this approach.