Choosing the best system software architecture for your wireless smart sensor design: Part 1 - Embedded.com

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

The smart sensors used in wireless industrial and building automationapplications are often characterized by energy restrictions, smallCPUs, and small memory footprints. The limited resources of thehardware make special applications necessary, which in turn createspecial requirements for the system software.

This three part series outlines the factors a developer needs toconsider when choosing system software for Wireless Sensor Networks(WSNs) to be used in embedded designs.

While there will be extensive discussion of appropriate RTOSes andfeatures, this series will also evaluate alternative approaches, bothcommercial and non-commercial, for use in small footprint embeddedsystems, and will also discuss the usefulness of such approaches inWSNs. Commercial and non-commercial solutions are listed for referenceand further exploration of the subject. Some of these approaches mightnot be familiar to the working embedded developer.

Some of these applications are easy to implement without a RTOS,some require a simple scheduler approach, and some warrant afull-fledged RTOS from a commercial vendor or from some of thenon-commercial sources discussed in this article. The hardwarearchitectures of the smart sensor devices as well as their use asnetwork devices are characterized with the following specifics:

*Restricted CPU power
* Restricted available memory
* Limited energy supply, mainlyprovided by batteries or alternative sources such as the sun,vibrations, etc.
* Software update challenges such asthe Over The Air (OTA) approach
* Changeable network topology
* Dimensions and weight restrictions,which can lead to cooling and CPU usage restrictions

All these specifics of smart sensors require special attention whendesigning or considering the software architecture. There are severalapproaches that can satisfy the constraints of such designs, including:

* Main loop plus interrupt service routine approaches (Part 1 )
* Simple scheduler or home-grown RTOS configurations (Part 2 )
* Virtual machines, state machines and reactive-deadline driven designs(Part 3 )

Main loop plus interrupt serviceroutines approach
This approach is a standard one for small software implementations andis a good solution when there is no need for well separated parallelexecution. The parallelism is achieved through the Interrupt ServiceRoutines (ISR), which get triggered by a software or hardwareinterrupt. The main loop is a forever loop which repeats the sameactivities forever. Its flow is suspended when an interrupt occurswhile the interrupt is being processed by the ISR. The pseudo code in Figure 1 below illustrates thesolution.

However, there are several problems with this approach. First, itinevitably leads to the use of variables with global scope. Second, itis hard to separate the application into independent modules that havetheir own timing constraints. The dependencies of such implementationare too many and therefore changes are hard to maintain.

Third, the ISRs need to execute fast and return when done. Thiscreates delays for certain activities and often means that the ISRneeds to schedule something to happen. The actual processing needs tohappen when control returns to this point in the main loop.

Depending on when the interrupt occurred, a full loop cycle may passbefore the requested action by the ISR is executed by the main loopsoftware. In other words, this solution is the easiest to create, butis the least flexible choice. It is suitable to small, well-definedapplications where minimal changes and maintenance are anticipated overthe life of the design. Because of the inflexibility, it amazes me howmany systems ” some of which are not so small ” still use thisapproach.

Figure1 ISR Pseudo Code

One way to overcome limitations of the ISR approach is to provide alayer that queues all interrupt sources and the data associated withthem. The application processes the queue entries in the order of theirarrival, thus making the application code well organized . Thistechnique, shown on Figure 2 below ,is used by Jennic in its application queue implementation [15].

In this design, two output queues are provided for MCPS and MLMEevents from the 802.15.4 stack layer and one queue for all hardwareinterrupts. Thus the application can check all three queues in the mainloop and process the queued events and interrupts accordingly. Iflatency is not an issue, this approach is cleaner than having manyISRs. If there are some latency sensitive events, some minimalreconfiguration of the ISR is in order to meet the real-timerequirements.

Figure2: Jennic application queue structure

The simple scheduler or the homegrown RTOS solution
A much more flexible way to go is to use a simple task scheduler, whichhas the advantage of allowing the creation of tasks. The term 'task' asused in this article is equivalent to a light process or thread. Tasksallow the software solution to be divided into independent executioncontexts having their own logic. Having their own context is especiallybeneficial for local encapsulated variables, thus reducing thenecessity for global variables.

There needs to be some form of Inter Process Communication (IPC) inorder to exchange information between tasks, but this is done throughthe framework and is not directly controlled by the tasks. The taskscan exchange messages, events, signals, etc. through message queuesthat the solution needs to provide. So in addition to the schedulerthere can be IPC mechanisms, energy saving mechanisms, memorymanagement mechanisms and so on. This approach is illustrated in Figure 3 below.

Figure3: IPC framework

One can argue that this is a small RTOS with nothing but the basicfunctionality to achieve parallel software execution in order toachieve deterministic behavior. A modern example could be BasicOperating System (BOS) from Jennic. A reference document can be foundat www.jennic.com/support.

The overall functionality may vary, depending on the designer'sgoals, but the main steps in implementing this approach include:

*Initialization of the scheduler, which allocates resources and createsthe framework for IPC and task entry points
* Creation of task code
* Starting the scheduler, which startsthe tasks and the scheduling algorithm
* Handling of tasks and message queuesfor as long as there are tasks running

All the tasks have the same priority and run to completion, which inmany cases means they run forever. The scheduler usually runs in around-robin fashion and allows tasks to be executed in turn. It assignstime slices to each task in equal portions and in order, handling alltasks without priority.

The round-robin approach is suitable when there are only a smallnumber of tasks that do not need to be run with different priorities.If the scheduler needs to provide preemptive execution based onpriorities of tasks, then the complexity of the system softwaresolution rises significantly.

The creation of such a solution is moderately difficult. Thereality is that it requires some experience with the hardwarearchitecture as well as understanding of real-time concurrent softwaredevelopment. Another disadvantage is that it is a custom solution and areinventing-the-wheel type of activity.

Still, home-grown RTOS solutions are perceived by some to beeconomically feasible. However, my belief is that an already developedRTOS is the way to go, and as you will see in the next part in thisseries there are a lot to choose from in both the commercial and in thenon-commercial arenas. Even for those of us who hope to spruce up ourown RTOSes once the kids have gone off to college and we have moretime, the availability of already created RTOSes to cover almost anysituation makes re-inventing the wheel impractical. Porting an existingRTOS to a sensor board is much easier and a less risky approach thancreating your own.

Next in Part 2: Anatomy of an RTOSfor 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 atantonhr@verizon.net

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, 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, 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”, http://www.jennic.com/support/view_file.php?fileID=0000000095

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