2. Review on Node and Network Abstractions for WSN Nodes
2.3 Node Abstractions
2.3.2 WSN Programming Models
WSN programming models can be divided into low-level and high-level methods [154, 168, 176, 191]. The high-level methods create applications over the whole net-work, for example using Structured Query Language (SQL) middleware presented in Section 2.4.1. The low-level methods consist of two main approaches: OS API programming and virtual machine programming.
The WSN OS API is used with a programming language, typically C, to construct
2.3. Node Abstractions 17
Table 3:Related WSN OS proposals.
Operating System Type Design features
TinyOS [84] Event-driven One of the first WSN kernels, open source,
ap-plication development with NesC [72], thread and code protection extension [9].
MANTIS OS [24] Pre-emptive One of the first pre-emptive kernels.
Contiki [58] Event-driven Dynamic loading, multithreading library, open
source, event-driven programming with pro-tothreads [59].
SOS [80] Event-driven Dynamic module loading and primitive module
execution safety.
Nano-RK [66] Pre-emptive High timing accuracy and deadline guarantees.
t-kernel [77] Pre-emptive Small overhead virtual memory and memory
pro-tection.
RETOS [36] Pre-emptive Dynamically reconfigurable and user/kernel space
separation with software.
Pixie OS [133] TinyOS extension Resource aware dataflow programming model,
where task reserved tickets follow availability and reservation of the resources.
LiteOS [33] Pre-emptive UNIX -like file system approach. Each node can
be accessed with terminal connection.
CORMOS [218] Event-driven Communication oriented design.
TMO-NanoQ+ [220] Pre-emptive A time and message triggered pre-emptive task
scheduling. Also, supports cooperative compile-time serialization scheduling.
SenOS [107] State machine A finite state machine based OS where state
ma-chine applications are described as sequence of ac-tions.
OSone [167] Event-driven Thin hierarchical distributed OS that abstracts a
distributed WSN to a one processing computer.
LIMOS [223, 226] Hybrid Each cooperative event-handler can execute
sev-eral pre-emptive threads.
FreeRTOS [71] Pre-emptive General purpose open source Real-time
Operat-ing System (RTOS), small memory overhead com-pared to other general purpose RTOSs.
SensorOS [115] Pre-emptive High timing accuracy.
WSN applications. NesC [72] and protothreads [59] are specially designed program-ming methods for WSNs.
Protothreads [59] are a state machine abstraction for event-driven kernels that were first used in Contiki [58]. Protothreads are implemented with C precompiler macros that provide a pre-emptive thread like API for event-handlers. As protothreads have a special approach to traditional C programming, Listing 2.1 presents an illustrative example of timer event usage with protothreads. The actual program code of the protothread commands PT_<command> is inlined after the precompilation. This
Table 4:Comparison of the kernel types.
Kernel Type Benefits Drawbacks
Pre-emptive kernel Guaranteed timing accuracy.
Easy programming model for combining timing critical tasks and long running tasks.
Familiar programming model.
High memory overhead when deployed. Pre-emption exe-cution overhead increases en-ergy consumption.
Event-driven kernel Low memory and execution overhead.
Challenging to combine tim-ing critical tasks and long run-ning tasks. Non-familiar pro-gramming model for applica-tion developers.
complicates run time debugging, since lines 3, 6, and 9 of Listing 2.1 contain code that the debugger cannot break to. Protothreads simplify splitting the tasks in the event-handlers, but they do not solve the high accuracy timing issues.
NesC [72] is an event-handler programming language for TinyOS. The NesC code is a dialect of C programming language and is compiled into a full C programming code. Thus, NesC requires the application programmer to adopt a new language. As a similar illustrative example to that for protothread, Listing 2.2 presents timer event usage with NesC. Interface declarations are deprecated for the sake of presentation clarity. The code contains an initialization of the event-handler in lines 2–5, setting up a timer in lines 7–13, and the actual event-handling code in lines 15–18.
A Virtual Machine (VM) typically runs on top of a small OS kernel and a protocol stack. VM applications are developed using an HW-independent byte code that sep-arates the application from the running HW. This increases heterogeneity and porta-bility, since the same VM byte code runs on different MCUs without any changes.
As a downside, VM approaches have a higher execution and memory overhead than running native machine code. Also, VMs require handling a new byte code from the programmer, and may limit the application development, e.g. only allow access to predefined events.
Maté [124] is a VM for TinyOS that is a stack computer with predefined event trig-gers, and built-in sampling, sending, and receiving instructions. As a similar illustra-tive example, Listing 2.3 presents sensor sampling and sending with Maté. Darjeel-ing [30] is similar to Maté. Impala [131], SensorWare [28], and MagnetOS [20] are commonly cited VMs in WSN research, but they are too resource-consuming for
re-2.3. Node Abstractions 19
1 s t r u c t e t i m e r t i m e r ;
2 PT_THREAD( example (s t r u c t p t ∗p t ) ) 3 {
4 PT_BEGIN ( p t ) ;
5 while( 1 ) {
6 e t i m e r _ s e t (& t i m e r , 1000) ;
7 PT_WAIT_UNTIL ( pt , PROCESS_EVENT_TIMER) ;
8 / / A p p l i c a t i o n l o g i c .
9 }
10 PT_END( p t ) ;
11 }
Listing 2.1:Initiation and handling of a timer event with protothreads in Contiki
1 i m p l e m e n t a t i o n {
2 command r e s u l t _ t S t d C o n t r o l . i n i t ( ) {
3 return SUCCESS ;
4 }
5
6 command r e s u l t _ t S t d C o n t r o l . s t a r t ( ) {
7 return c a l l Timer . s t a r t (TIMER_REPEAT , 1000) ;
8 }
9
10 command r e s u l t _ t S t d C o n t r o l . s t o p ( ) { 11 return c a l l Timer . s t o p ( ) ;
12 }
13
14 e v e n t r e s u l t _ t Timer . f i r e d ( ) { 15 / / A p p l i c a t i o n l o g i c .
16 return SUCCESS ;
17 }
18 }
Listing 2.2:Initiation and handling of a timer event with NesC
source constrained WSNs. MagnetOS [20] is a general purpose Java VM distributed over ad hoc nodes, SensorWare [28] implementation takes 240 KB of program mem-ory, and Impala [131] is implemented for Personal Digital Assistants (PDAs).
Protothreads and NesC simplify event-handler programming, but they do not solve the timing and long running task issues. NesC and the VMs require programmers to adopt a new programming language and programming model for the applications.
Compared with native C, a VM can restrict application development.
1 pushc 1 / / S e t p r e d e f i n e d s e n s o r ID p a r a m e t e r t o t h e s t a c k 2 s e n s e / / Sample t h e s e n s o r u s i n g t h e b u i l t−i n i n s t r u c t i o n
3 pushm / / Push message t o t h e s t a c k
4 add / / Add sampled v a l u e t o t h e message
5 send / / Send t h e message
Listing 2.3:A sensor sampling with Maté.
WSN OTAP Software Updates
Software Transfer
Fall-back Upon Failure Software
Decoding
Dynamic Loading
Application Injection Provides
Consists of
Application Dissemination
Fig. 7:WSN OTAP definition.