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

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

Any operating system strives to provide a framework for convenient andeasy application software development. Through the use of multitaskingand hardware abstractions, an operating system is useful to aprogrammer because it isolates dependencies from the particularhardware details through the agency of a Hardware Abstraction Layer(HAL).

One of the uses of a real-time OS (RTOS) is to guarantee determinismfor real-time performance. It is equipped with facilities which canhelp the user to meet their application's real-time goals. For the OSto be real time it needs to have a special architecture, especially inthe scheduler, a main component of the RTOS.

RTOSes are often classified as either soft real time or hard realtime. A hard real-time RTOS is guaranteed to meet the timingrequirements, while soft real-time solutions only guarantee thesetiming deadlines within a range of probability. One of the first designdecisions to be made is to answer two questions:

1) Is the system real timeor not? (The definition of 'real time' depends on the requirements andabsolute time will be a different value for different projects.)

2) If the system isreal-time, is it hard real time or soft real time? The answers to thesequestions will help in the selection of the software architecture. Therequirements of the smart sensor wireless sensor network described inPart 1 can be used to help you pin down which alternative you need todeploy.

Shown in Figure 4 below isthe typical interaction of the application, the RTOS, the Board SupportPackage (BSP) and the hardware. The BSP is the collection of driversthat an RTOS would define in order to interface with differenthardware. As can be seen, the application can request services from theRTOS, or bypass the RTOS to talk directly to the BSP or hardware.

Depending on how the system is architected some of those links areoptional and most RTOS vendors would recommend that it all be donethrough the RTOS and have the RTOS use its BSP to control the hardware.

Figure4: Typical Interactions in an embedded design

Concurrency and IPC
A smart sensor design may implement layers through the full range ofthe seven-layer OSI model. Some layers may not be required for certainapplications. For example, the Physical Layer, Data Link Layer andApplication Layer must be present for the WSN to function as such. Thecontrol of the Physical and Data Link Layers is a parallel activity inthe RTOS.

The same can be said for energy control of the smart sensor chip.Adding the networking and transportation layers requires anotherindependent activity. That is why the question of concurrency becomesserious when the networking layer needs to do routing independentlyfrom 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 theconvenience of an RTOS or at least a simple scheduler becomesnecessary. With the concurrent execution facilities comes the need forIPC.

Memory Management
Memory management in embedded systems is handled differently dependingon speed and capacity restrictions. Another restriction may come fromthe lack of a Memory Management Unit (MMU) in the smaller embeddedCPUs.

This is especially true for smart sensors, where in some cases theCPU is 8-bit and the memory is restricted to several tens of kilobytes.Therefore the usual approach in the RTOS is to use static resourceallocation [18]. This means that all buffers are allocated at compiletime, thus exposing problems in the design and avoiding unexpecteddynamic behavior.

In addition, the RTOS needs to optimize memory usage during resourceallocation and during runtime [2]. It seems to me that there is apotential for tools to help the designer of the application to verifythe memory offline and during the initial design.

I/O Management
It is hard to come up with an abstraction about all the possible I/Oconfigurations, but there is an opportunity for an RTOS to standardizethe reading and control of I/O [2]. Interfaces to common sensors canhide the details in the device drivers' implementation and the RTOS canprovide a unified interface for classes of devices to the user.

This means that changing the underlying hardware would not lead toapplication code changes, but will simply require a new driver whichcomplies with the established interface. The challenge is that thenumber of possible device driver classes is overwhelming compared to astandard embedded system with just serial and Ethernet interfaces andno sensors attached.

Similarly to how Zigbee classifies types of devices, an RTOS cansupport 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 networkprotocols. Routing protocols in WSNs are special and can be tailored tothe specific needs of the application. The energy conserving approachrequires routing to be done efficiently. The same is true for dataexchanges between nodes in the network.

Therefore the RTOS needs to have an architecture that supports easyinstallation of new wireless networking protocols. Handling collisionswith special protocols is a subject of ongoing research in the area.Aggregating several packets into one and transferring in one burst isanother feature of these protocols [2]. Nano-RK takes the approach ofsocket-like abstraction for the application, which is a convenient andwell-known approach for software developers.

Dynamic Downloadable Modules andServices
The benefit of being able to change the application code whilepreserving the relatively static RTOS kernel is attractive, especiallywhen precious energy needs to be spared while transmitting only thebytes of the changed application or part of the application to thedevice. A good example in this area is the Contiki RTOS. The curiousreader is advised to take a look at [6], which is an excellent paper.

The separation of the base functionality of the RTOS and theapplication code is used in many other RTOS solutions. I have seen thesame approach in the commercial RTOS OSE from Enea and in Integrityfrom Green Hills. Contiki defines applications and services as loadablemodules. In Contiki, a service contains common functionality that canbe used by other processes. Examples are protocol stacks, sensor datahandling, etc. The dynamic downloadable modules are related to thesoftware updating strategies.

Energy Conservation Awareness
Smart sensors frequently depend on batteries. Based on how theapplication runs and what hardware resources are used, these batteriescan be depleted quickly. The range of operation between changing thebatteries may vary from several hours to years, based on the currentdrawn from them. Some newer chips allow for shutting down parts of theCPU for judicious energy saving. Similarly, other parts of the hardwarebesides the CPU can be designed to be controlled to enter a lowconsumption mode.

The RTOS can provide power saving mechanisms, which are abstractedfrom the particular hardware. If there is no RTOS used or if the RTOSdoes not have power saving mechanisms, then the application needs to dothat. The control of the energy saving mode is so hardware dependentand varied from platform to platform, it is generally easier to havethe application control the hardware directly or through an ApplicationProgramming Interface (API) provided by the chip manufacturers.

The MANTIS OS [17] has an interesting method of detecting when thesystem has no pending work for the tasks and putting the system tosleep. This seems like an ambitious task when taking into accountdynamic changes, based on the timing requirements from the tasks andthe changing load of the system in general. Contiki [6] takes adifferent approach and exposes the size of the event queue to theapplication, which decides how much work is pending for the runningtasks and can go into energy saving mode or not.

The other side of the spectrum is when the RTOS does not give anyindication and the application cannot decide when to control the power.The wake-up mechanism with RTOS or application control is based on aninterrupt from a timer or an external source. This is an increasinglyimportant topic and it is expected that more and more power savingalgorithms will be embedded in RTOS architectures or some other from ofsystem software for smart sensors.

Software Updating Strategies
Since WSNs are predicted to grow quickly and have many nodes, softwareupdating 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 performedwirelessly. Contiki supports an OTA protocol, described in [6].

The binary is sent to a selected concentrator node, which aftersuccessful reception of the entire binary image disseminates it to theneighboring sensor nodes. There is an error handling mechanism tofacilitate the transmission between the concentrator and end nodes.Like any communication over the air, especially when software updatesare concerned, the issue of security is an important one. The biggestchallenges of OTA are: the time it takes to complete the task, therobustness of the protocol, and security.

Time Synchronization
Depending on the application, time synchronization may be or may not beneeded. When it is needed, it is not a trivial problem to solve. Onetechnique described in [18] uses a hook to place a timestamp in thepacket. TinyOS provides set-and-get of the current system time as wellas timestamps in messages, leaving the application to decide when touse those facilities.

Another approach is to use the Network Time Protocol [NTP], althoughits use can introduce errors in an environment as time sensitive asTinyOS [18]. There are other time synchronization protocols, such asthe RTSIEEE 1588 Precision Time protocol

Table1: Non-Commercial RTOSes

Commercial and non-commercial RTOSes
As a part of my research, I tried to run down RTOS solutions suitablefor both commercial (Table 1, above ),and non-commercial (Table 2, below) RTOSesin wireless sensor network designs.

Table2: Commercial RTOSes

If I missed any it was due to my time limitations or informationavailability. Reader feedback is welcome to uncover other existingsoftware gems.

Next in Part 3: Virtual machines,state machines and reactivedeadline driven methods
To read Part 1, go to “The constraints imposed by wireless sensornetworks.”

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

[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.