CHANNEL AND ACTIVE COMPONENT ABSTRACTIONS

FOR WSN PROGRAMMING

A Language Model with Operating System Support

Paul Harvey

, Alan Dearle

, Jonathan Lewis

and Joseph Sventek

School of Computing Science, University of Glasgow, Glasgow, Scotland, U.K.

School of Computer Science, University of St Andrews, St Andrews, Scotland, U.K.

Keywords:

Wireless Sensor Network, Insense, InceOS, nesC, TinyOS, Operating System, Programming Language.

Abstract:

To support the programming of Wireless Sensor Networks, a number of unconventional programming models

have evolved, in particular the event-based model. These models are non-intuitive to programmers due to the

introduction of unnecessary, non-intrinsic complexity. Component-based languages like Insense can eliminate

much of this unnecessary complexity via the use of active components and synchronous channels. However,

simply layering an Insense implementation over an existing event-based system, like TinyOS, while proving

efﬁcacy, is insufﬁciently space and time efﬁcient for production use. The design and implementation of a new

language-speciﬁc OS, InceOS, enables both space and time efﬁcient programming of sensor networks using

component-based languages like Insense.

1 INTRODUCTION

Wireless sensor networks enable a wide variety of ac-

tivities to be performed autonomously, and are cur-

rently being used in many diverse areas including

measurements of mountain permafrost (Hasler et al.,

2008) and grapevines (Burrell et al., 2004). Such

networks take highly constrained hardware devices

(motes) and connect them via short-range radios to

form useful monitoring tools, protection systems, and

research systems. In programming such devices, a

number of unconventional programming models have

evolved. For example, both TinyOS (Hill et al., 2000)

and Contiki (Dunkels et al., 2004) use an event-driven

programming model, although realised through dif-

ferent abstractions. We assert that these models are

non-intuitive to programmers due to the introduction

of unnecessary non-intrinsic complexity. In partic-

ular, the introduction of the TinyOS split-phase ex-

ecution model is a barrier to understanding, writing

and reasoning about WSN programs. The same ar-

gument could also be levelled at programming with

TinyOS threads and Contiki proto-threads. However,

due to space limitations, we focus on the event-driven

TinyOS abstractions in this paper.

In this paper we describe a new language-speciﬁc

operating system, InceOS, which was created to sup-

port the domain-speciﬁc language (DSL) In-

sense (Dearle et al., 2008). Unlike the previous

Insense implementation on Contiki, InceOS is

tuned to the needs of Insense, enabling non-trivial

Insense application to ﬁt onto real mote hardware

and execute in a timely manner. We hypothesise

that the component-based model and abstractions

presented by Insense, and implemented by InceOS,

support a simpler programming model for resource-

constrained embedded systems, removing much of

the complexity of an event-based system, while still

affording the user the power to express complex

applications. We demonstrate that applications

written using Insense, and running on InceOS both

ﬁt onto and run efﬁciently on real mote hardware

with better performance when compared to TinyOS.

This is shown via a comparison of Insense and nesC

applications that cover different aspects of embedded

programming.

The paper is structured as follows: Section 2

gives an overview of event-driven programming and

TinyOS, Sections 3 and 4 discuss Insense and In-

ceOS, Section 5 presents the results of the compar-

ison between the languages and systems, Section 6

highlights directions for future work, and Section 7

provides concluding remarks.

Harvey P., Dearle A., Lewis J. and Sventek J..

CHANNEL AND ACTIVE COMPONENT ABSTRACTIONS FOR WSN PROGRAMMING - A Language Model with Operating System Support.

DOI: 10.5220/0003832500350044

In Proceedings of the 1st International Conference on Sensor Networks (SENSORNETS-2012), pages 35-44

ISBN: 978-989-8565-01-3

 2012 SCITEPRESS (Science and Technology Publications, Lda.)

2 BACKGROUND

In order to place Insense and InceOS in context, we

describe the event-driven model and how it relates to

the computational model of TinyOS

. Event-driven

systems respond to events. These events can be gen-

erated by the hardware, for example by interrupts, or

by software. An event triggers an associated event

handler, which handles the event and results in some

computation being initiated that may, in turn, generate

further events.

In event-driven systems, there is no single locus

of execution; rather, there are a number of them each

triggered by an event. Such systems have become

popular for embedded systems since they do not re-

quire the same memory and processing overheads as

threads (e.g., for stacks and context switching), yet

provide a concurrent computational model. Another

advantage is that concurrency control is simpliﬁed

since, in many (single-CPU) systems, multiple event

handlers do not run simultaneously (Hill et al., 2000).

2.1 TinyOS

TinyOS is a component-based, event-driven system in

which events are signalled by both hardware and soft-

ware, and event handlers (callbacks) are expressed as

user-written functions that are invoked in response to

events. To support this event model, TinyOS appli-

cations are composed of components that are wired

together; a conﬁguration is shown in Figure 1. Each

component contains state, effectively executes au-

tonomously, and presents and uses (procedural) inter-

faces. Interfaces are used to specify the events and

commands that a component should support.

configuration SenseAppC {}

implementation {

components SenseC, MainC, LedsC,

new TimerMilliC(),

new DemoSensorC() as Sensor;

SenseC.Boot -> MainC;

SenseC.Leds -> LedsC;

SenseC.Timer -> TimerMilliC;

SenseC.Read -> Sensor;

}

Figure 1: nesC SenseAppC conﬁguration.

Each component contains command handlers (for

handling down-calls) and event handlers (for han-

dling up-calls). Commands are non-blocking requests

made to lower level components; a command will

Other event-based [e.g. Contiki] and component-based

[e.g. Lorien (Porter and Coulson, 2009)] systems exist;

space limitations prevent their inclusion in the discussion.

usually deposit parameters into the component’s lo-

cal state and post a task for later execution; it may

also invoke a lower level command. Event handlers

are intended to be small blocks of code that either in-

voke other event handlers, initiate split phase oper-

ations, call commands, or post tasks. Tasks, unlike

events, are schedulable, non-preemptable entities that

must run to completion.

#include "Timer.h"

module SenseC

{

uses {

interface Boot;

interface Leds;

interface Timer<TMilli>;

interface Read<uint16_t>;

}

implementation

{

// sampling frequency in binary milliseconds

#define SAMPLING_FREQUENCY 100

event void Boot.booted() {

call Timer.startPeriodic(SAMPLING_FREQUENCY);

}

event void Timer.fired() {

call Read.read();

}

event void Read.readDone(error_t result,

uint16_t data) {

if (result == SUCCESS){

if (data & 0x0004)

call Leds.led2On();

else

call Leds.led2Off();

if (data & 0x0002)

call Leds.led1On();

else

call Leds.led1Off();

if (data & 0x0001)

call Leds.led0On();

else

call Leds.led0Off();

}

Figure 2: nesC SenseC component.

TinyOS does not perform blocking operations;

instead it uses split-phase operations for long run-

ning executions. This methodology typically in-

volves initiating operations via a startOperation()

command, and completing an operation with an

operationDone() event handler. TinyOS and its ap-

plications are written in the nesC language (Gay et al.,

SENSORNETS 2012 - International Conference on Sensor Networks

2003), a component-based language that extends C.

The code fragment shown in Figure 1 describes the

(static) conﬁguration of the Sense program (Hauer,

2006) which displays the battery status of a mote on

its LEDs. The configuration describes both the

components to be used and their interconnectivity.

The only user-supplied nesC component for this

program is shown in Figure 2. Execution starts when

an event is handled by Boot.booted(); it initiates a

periodic timer by calling Timer.startPeriodic()

before yielding control. At some later point in time, a

timer event is signalled to Timer.fired(); it initiates

a read of the battery sensor by calling Read.read()

before yielding control again. Finally, when the Read

component signals a Read.readDone() event, it is

handled and the LEDs switched accordingly.

We assert that the split-phase programming model

introduces unnecessary cognitive load on the readers

and writers of such programs. Note that even this,

relatively short, piece of code contains 2.5 split-phase

operations, obfuscating the ﬂow of control.

3 INSENSE

Insense is a component-based language for WSN

programming that was previously implemented over

Contiki. The computational model presented by In-

sense is simple: applications are constructed as com-

positions of active components communicating over

strongly typed, directional, synchronous channels.

This model borrows from both the Actor (Hewitt

et al., 1973) and π-calculus (Milner et al., 1992) lan-

guage families. This computational model simpliﬁes

three areas of programming: synchronisation, mem-

ory management, and event-driven programming.

3.1 Components

Insense components exhibit shared nothing seman-

tics: there are no global variables and a component’s

state may only be accessed from within the compo-

nent. Insense components may be dynamically in-

stantiated using one of the components’ constructors

in a manner familiar to Java or C++ programmers.

Each Insense component comprises three ele-

ments: a behaviour, one or more constructors and

an arbitrary number of interfaces. It may also con-

tain component local state and functions. A com-

ponent’s behaviour is akin to a void procedure that

is repeatedly executed upon component instantiation,

until explicitly terminated. Each behaviour runs as

an individual pre-emptible locus of control (similar

to a thread) and may access the component instance’s

state. Since there is only one locus of control per com-

ponent which can never leave the component in which

it was created, threads and component instances are

in 1:1 correspondence. This, coupled with all compo-

nent state being private, means that there is no need

for explicit synchronisation or other concurrency con-

trol primitives in the language.

3.2 Interfaces

Components present interfaces which comprise a

collection of typed, named, directional channels.

Synchronous sending of messages via channels is

the only inter-component communication mechanism

provided in the language. Figure 3 below shows an

Insense component deﬁnition that presents an inter-

face containing three channels named: ticker, battReq

and battVal. Two of these channels are input channels

meaning that values can be read from them, one is

an output channel to which data may be written. The

speciﬁcation of a channel in a component interface

implicitly makes a declaration, introducing the chan-

nel name into the scope of the component body; thus

the names ticker, battReq and battVal are available for

use within the component.

3.3 Channels

Channels are typed and directional. In addition to be-

ing able to declare channels in component interfaces,

they may also be dynamically declared. Channels are

ﬁrst class entities in Insense and may be passed down

appropriately typed channels. This technique may be

used to dynamically wire-up Insense programs. As

stated above, send and receive are synchronous op-

erations in Insense and implement a rendezvous in

which either the sender or the receiver will block un-

til the other is ready. The program in Figure 3 re-

ceives ticks from a ticker channel and makes requests

for data from the battery component.

Channels are connected using explicit connect

statements in the language. If a component attempts

to communicate over an unbound channel it will block

until a connection is established and data is available.

This mechanism is extremely powerful and facilitates

dynamic composition and evolution of components in

a live system. In the program in Figure 3, a newly

created instance of the sense component is explic-

itly connected to the (predeﬁned) sensors component.

A disconnect operator is also provided although not

shown in this example. In addition to the send and re-

ceive operations shown here, Insense also provides a

powerful guarded, non-deterministic select statement

permitting data to be read from an arbitrary number

CHANNEL AND ACTIVE COMPONENT ABSTRACTIONS FOR WSN PROGRAMMING - A Language Model with

Operating System Support

of channels. Unlike nesC, connect statements may

be dynamic, permitting ﬂexible, reconﬁgurable archi-

tectures. Insense channels may be used to wire up

components in arbitrary topologies. Thus an output

channel can be connected to multiple input channels

or vice versa. Whilst this makes channel implemen-

tation more complex, it increases the expressive ca-

pabilities of the language and permits complex archi-

tectural patterns to be expressed. It also introduces a

second source of non-determinism into the language.

3.4 Memory Management

Like Java, Insense provides the new keyword for dy-

namic memory allocation of arrays, structs, chan-

nels, and components; reference counted garbage

collection is used to restore unused memory to the

heap, thus removing the burden of memory manage-

ment from the programmer. An upper bound on the

(relatively-small) stack space required for each com-

ponent instance is calculated at compile time. This is

possible due to restrictions on recursive invocation of

functions and a simple computational model.

3.5 Event-driven Programming

The channel mechanism provides an excellent vehi-

cle for event-driven programming with events deliv-

ered via channels either from hardware devices or

other components. If required to do so, components

can be made to block awaiting delivery of events via

a receive statement. Typically a single component

will be connected to an event channel. However, mul-

tiple handlers can also be connected to a single event

channel providing the capability to process events in

parallel. This model is more expressive than those

of TinyOS, is no less efﬁcient, and simpler to under-

stand.

3.6 SenseC in Insense

The code in Figure 3, shows a program equivalent to

the TinyOS SenseC application encoded in Insense.

The code deﬁnes and instantiates a single compo-

nent type called sense which presents an interface

ISense containing three channels as described above.

The component repeats its behaviour clause forever,

blocking every repetition until a tick is received from

the ticker channel. Once a tick is received, the battery

levels are requested by sending a message on the bat-

tReq channel before blocking awaiting a reply. The

ﬁnal four statements represent the ”main” for the ap-

plication. They create the component, bind its chan-

nels to the sensors, and instantiate the ticker to de-

liver timer messages every 0.098 seconds; the value of

SAMPLING FREQUENCY in Figure 2 corresponds

to a timer event every 0.098 seconds due to TinyOSs

use of 1024 ticks per second. This program is shorter,

simpler and, easier to understand than the nesC equiv-

alent.

type ISense is

interface (in bool ticker; out bool battReq;

in integer battVal)

component sense presents ISense {

constructor() {}

behaviour {

receive tick from ticker

send true on battReq

receive reading from battVal

if (reading & 4) == 4

then setRedLedPower(true)

else setRedLedPower(false)

if (reading & 2) == 2

then setBlueLedPower(true)

else setBlueLedPower(false)

if (reading & 1) == 1

then setGreenLedPower(true)

else setGreenLedPower(false)

}

s = new sense()

connect s.battReq to sensors.batteryRequest

connect s.battVal to sensors.batteryOut

setTimer(s.ticker , 0.098 , true)

Figure 3: Entire Insense SenseC program.

4 InceOS

InceOS is a new operating system that has been

speciﬁcally created to execute applications written in

Insense. The OS is pre-emptive and supports the

concurrent execution of multiple Insense components.

The language concepts of components and channels

are directly implemented, ensuring that the language

semantics are captured and enforced in the OS. In-

ceOS itself is written in C, and exports an API which

is targeted by the Insense compiler.

InceOS provides Insense applications with both

system calls and system components. System calls

are provided to manage the fundamental language

abstractions: channels and components, and to per-

form appropriate checks such as array bounds checks.

These system calls are used by the C code gen-

erated by the Insense compiler. The system calls

mainly encompass the creation, destruction, and ma-

SENSORNETS 2012 - International Conference on Sensor Networks

nipulation of components and channels; for example,

channel send() and channel receive() abstract

over the communication and concurrency control as-

pects of inter-component communication. There is no

need for the run-time to ensure type safety of such

operations as this is ensured by the compiler. These

system calls provide a platform-neutral API for the

Insense compiler, enabling the language to be ported

to multiple sensor hardware platforms.

The OS also provides a number of system com-

ponents which provide an abstraction over access to

the platform speciﬁc hardware and services, for ex-

ample, the battery sensor in Figure 3. These compo-

nents are well-known, in that they are known to both

the programmer and Insense compiler. An application

interacts with these system components via channels.

These system components include the timer, radio,

buttons, and sensors.

4.1 Scheduling and Threads

Due to the close coupling of channels and compo-

nents, the InceOS scheduler does not need to maintain

references to components which are blocked and un-

schedulable. A blocked component can only become

eligible to run through the rendezvous of channel ac-

tions; the most recent rendezvous action unblocks the

component and places it onto the run queue of the

scheduler. This is possible as each channel is aware of

the components to which it is connected; thus when a

channel action occurs, only the relevant components

are examined. Consequently, the scheduler is simpli-

ﬁed, as it has less state to maintain. TinyOS requires a

programmer to explicitly post a task to the scheduler

before it can be executed. While this is not neces-

sarily an onerous requirement on the programmer in

TinyOS, the removal of this responsibility by InceOS

simpliﬁes the process.

InceOS provides a round robin scheduler with a

quantum of 30 ms and two priority levels: interrupt

and normal. Normal priority is for any component,

system or user, which becomes runnable as a result

of a channel operation. Interrupt priority is only used

for system components which are made runnable by

hardware interrupts. For both priority levels, the same

run queue is used; normal priority components are

added at the tail of the run queue, and interrupt prior-

ity components are placed at the head. Should mul-

tiple components be scheduled at interrupt priority,

they are added in chronological order. To simplify

the interaction with the hardware, a system compo-

nent simply waits on a channel in the same manner

as the sense component in Figure 3 waits on a tick

from the ticker channel. The following exempliﬁes

this for the system-level Timer component which in-

terfaces with both the timer hardware and user-level

components. The hardware timer generates interrupts

causing an interrupt handler to be invoked. The han-

dler sends a message to the system-level Timer com-

ponent on its interrupt channel. The Timer component

repeatedly waits for messages from an interrupt chan-

nel prior to sending messages to those user-level com-

ponents for which requested timers are due. At the

end of its behaviour clause, the Timer component re-

sets the hardware timer for the next outstanding user-

level timer that is due to expire prior to waiting for

the next interrupt to occur. In this way, the system

components are able to interact with both user com-

ponents and hardware via the channel mechanism.

As with TinyOS, InceOS enters a low power state

when there is no more work to be done - i.e., the

scheduler’s run queue is empty. The system reawak-

ens when a hardware interrupt causes a system com-

ponent to become schedulable again. User compo-

nents are awakened when messages are received on

the channels on which they are blocked as described

above.

Each user component in Insense is pre-emptible,

ensuring a fair share of the CPU to all eligible user

components. This requires that each component has

an associated thread and stack. The main opposition

to threads and stacks on motes is that they consume

relatively large amounts of limited RAM. Insense and

InceOS minimise this impact by determining the stack

size required for each component’s behaviour at com-

pile time and dynamically allocating this at runtime,

as described in section 3.4. For example, the compiler

has calculated a stack size of 22 bytes for the compo-

nent in Figure 3. This provides space for local vari-

ables, as well as variables required by the OS. A fur-

ther 120 bytes are added to provide space for system

actions and interrupts, giving a maximum stack depth

of 142 bytes. The compiler also calculated a size of

10 bytes for the component’s heap object. This is used

to hold references to a component’s channels and in-

stance state, as well as the ﬁelds used for garbage col-

lection and component manipulation. These values

are passed to the OS when creating a component.

4.2 Radio Comms

Presently, InceOS has broadcast and unicast capabil-

ities. It does not support tree based routing proto-

cols, or IP, unlike TinyOS. However, these can be

implemented within a programmer’s application. At

present, user components communicate with a radio

component provided by the system. This component

provides two input channels, broadcast and unicast,

CHANNEL AND ACTIVE COMPONENT ABSTRACTIONS FOR WSN PROGRAMMING - A Language Model with

Operating System Support

and a single output channel, received. A user com-

ponent will connect to either the broadcast channel

to send broadcast messages, or the unicast channel to

send unicast messages. A component wishing to re-

ceive either type of message connects to the received

channel.

5 EVALUATION

In order to demonstrate that applications written us-

ing Insense both ﬁt onto and run efﬁciently on real

mote hardware, a number of comparisons were made

between Insense and nesC, and InceOS and TinyOS.

Several WSN applications were written in nesC and

Insense and executed on their respective operating

systems. All of the following results were obtained

from Tmote Sky

motes which have 10 KB of RAM

and 48 KB of ﬂash available. The motes were tested

under full power.

5.1 Applications

The chosen test applications are primarily from the

TinyOS source tree, augmented with some that were

explicitly constructed to highlight syntactic and com-

putational performance differences. The source code

for all of these applications is available online

• BlinkA is a simple application that periodically

blinks the three different LED’s of the Tmote

Sky at different rates. BlinkB performs the

same operation using the TinyOS thread library

(TOSThreads (Klues et al., 2009)).

• TestSineSensor periodically samples a sensor, af-

ter which it forwards the obtained value over the

serial link. Under TinyOS, it is implemented us-

ing TOSThreads.

• RadioStress uses three threads to send messages

to another mote where three threads are listen-

ing for messages from their counterparts. Under

TinyOS, it is implemented using TOSThreads.

• RadioCountToLeds involves two motes, one

maintains a counter which is transmitted over the

radio to the other mote which displays the lower

three bits of the transmitted value on its LED’s.

• RadioSenseToLeds is a similar application, except

that it collects and sends sensor data as opposed

to a software counter.

http://www.sentilla.com/moteiv-transition.html, Ac-

cessed on 25/09/2011.

http://blogs.cs.st-andrews.ac.uk/insense/insense-on-

inceos-examples/

• Sense is similar to RadioSenseToLeds, but it only

uses one mote and does not send sensor values

over the radio, as shown in Figures 2 and 3.

• TestRoundRobinArbiter is an example of an ac-

cess control mechanism where three resource

users request access from a central controller,

which grants access to each in turn.

• Fourier performs a Fourier transform on an array

of 40 integers repeatedly.

• Grid is based on the notion of using ad-hoc

grids in sensor networks to mitigate the power

consumed by excessive radio transmission of

data (Rondini and Hailes, 2007). This applica-

tion consists of two types of node: leaders, who

make requests, and slaves, who service requests.

Initially the leader broadcasts a request asking for

any free slave. Once a slave replies to this re-

quest, the leader collects enough sensor data to

ﬁll an array of size 10 and transmits it to the

slave that acknowledged it. The slave performs a

Fourier transform on the received data, calculates

the maximum value and returns this to the leader.

The Grid and Fourier applications were not pro-

vided by TinyOS. The combination of these applica-

tions cover intense computation, radio transmission,

interactions between components on a single node

and combinations thereof.

5.2 Concurrency and Serialisation

As each component within Insense executes an iso-

lated, independent thread, there is no need for the de-

veloper to use any special thread libraries, functions

or routines while writing an application, in contrast to

TinyOS. Instead they can simply concentrate on writ-

ing the code that embodies the activity of a compo-

nent within its behaviour. Additionally, as InceOS is

pre-emptive, it will ensure that all user components

that are eligible to be run have an equal opportunity

to do so. This ensures that no one component monop-

olises the CPU, and does not require the programmer

to explicitly yield control.

A context switch in InceOS takes 15.3µs (380 as-

sembly instructions). Context switching is often cited

as a drawback of using threads in embedded systems,

however these values show that the time required to

go from executing in one component to another is

small and bounded.

One of the most common problems associated

with concurrency is the incorrect use of locking mech-

anisms to guarantee serialised access to shared vari-

ables, leading to race conditions and deadlock. In-

sense removes race conditions by making the instance

SENSORNETS 2012 - International Conference on Sensor Networks

Table 1: Comparison of Insense and nesC code.

Lines of Code Components Wiring Statements Interfaces

Application Insense nesC Insense nesC Insense nesC Insense nesC

BlinkA 28 40 2 6 3 5 1 5

BlinkB 30 54 4 7 1 6 1 6

TestSineSensor 13 45 2 7 2 8 1 7

RadioStress 50 94 5 13 9 12 1 12

RadioCountToLeds 55 103 5 7 4 7 2 7

RadioSenseToLeds 57 101 6 8 6 8 2 8

Sense 29 43 3 5 3 4 1 4

TestRoundRobinArbiter 49 180 5 11 10 15 2 24

Fourier 19 30 1 2 0 1 1 1

Grid 97 177 5 8 7 8 1 8

state of components private as part of the language.

When data must be shared between components, it is

done via the channel mechanism. The channel mech-

anism must be efﬁcient for production use. In In-

ceOS, typical transmission time on a channel when

both components are ready is 215±0.08µs.

5.3 Code Composition

Both Insense and nesC applications are composed of

components, interfaces, and wiring statements. Ac-

cordingly, these features were used as metrics to judge

code complexity. Table 1 shows the results. The ta-

ble shows the application, number of lines of code

used, number of components either written or refer-

enced, number of wiring/connect statements, and the

number of interfaces used. Obviously each of these

features could be manipulated -e.g., every Insense ap-

plication could be written in a single component. To

prevent this, each Insense application uses a compo-

nent representing each activity of the program and the

system components.

The table shows that the applications can be writ-

ten in Insense with fewer elements from each cate-

gory, excluding the Fourier application where both

languages require one interface. Although it does

not necessarily follow that fewer is better, the pre-

vious discussion of the simpler composition of In-

sense and these results show that it is possible to

write functionally-equivalent programs in Insense

with many fewer lines of code.

5.4 Size

Figure 4 shows the amount of ﬂash which is con-

sumed on the Tmote Sky by TinyOS and InceOS

when compiled with an application. Figure 5 shows

the amount of space consumed by the data and bss

sections of the compiled InceOS and application, and

Figure 6 shows the equivalent for TinyOS. It can be

seen that there is variation between the applications

on TinyOS compared to the relatively static ﬁgures for

InceOS. InceOS consumes more ﬂash than TinyOS

partially due to the optimisations of the nesC com-

piler, but mostly due to the extra support mechanisms

found in InceOS. These include the runtime features

discussed previously.

InceOS dynamically allocates the structures used

to represent channels and components at runtime. Dy-

namic allocation leads to the small values seen in Fig-

ure 5, and the lack of conditional compilation causes

them to be uniform across the different applications.

The use of dynamic allocation and stacks exacts a run-

time cost in RAM. The cost for Insense and InceOS is

highlighted via two examples. The ﬁrst uses a (null)

component with no channels and no code in the be-

haviour section. This null component requires 188

bytes. The 188 bytes is the size required to repre-

sent the component, its channels, its stack, and any

dynamically allocated structures. After the system

and null components are initialised, with both com-

ponents and channels being allocated, there are 4363

bytes of RAM available. The second example uses

the component from Figure 3. Here the sense compo-

nent requires 364 bytes, leaving 4187 bytes of RAM

available. Taking the sense component as an exam-

ple of an average component, there is enough space

on the Tmote Sky to create 11 such components. As

discussed in section 4.1, 120 bytes are added to the

compiler computed stack size for a component to ac-

commodate system calls and interrupts. We intend

to introduce a kernel stack for all system operations,

thus reducing the 120 byte overhead to 26 bytes, the

maximum stack space required for an interrupt. For

the sense example above, this would permit the cre-

ation of 17 Sense component instances, each consum-

ing 272 bytes of RAM.

InceOS consumes more ﬂash and RAM than

TinyOS, however there is still adequate space avail-

able on the motes for even larger and more complex

applications; the largest and most complex applica-

tion in this evaluation, grid, leaves just under 24 KB

CHANNEL AND ACTIVE COMPONENT ABSTRACTIONS FOR WSN PROGRAMMING - A Language Model with

Operating System Support

of ﬂash and nearly 3 KB of RAM available, 50% and

31% of the total space available, respectively.

Figure 4: Flash consumed by applications and speciﬁed OS.

Figure 5: Space consumed by InceOS applications.

Figure 6: Space consumed by TinyOS applications.

5.5 Performance

To ascertain if support for the channel and thread-

ing mechanisms exact some cost in performance, we

measured the performance of a representative cross

section of the applications on both TinyOS and In-

ceOS. In the following graphs, each data point is the

average of 100 iterations of the application. For ex-

ample, each point in Figure 7 is the average time re-

quired to increment a software counter and broadcast

this value in a packet over the radio 100 times. The

error bars on each point represent the standard de-

viation, however most are not visible as the results

are often consistent within the measurement accuracy.

Both TinyOS and InceOS are using a csma/ca proto-

col for radio transmission - i.e., before attempting to

send, the radio hardware is queried to detect the pres-

ence of other radio transmissions; if radio signals are

detected, the transmission is delayed, otherwise the

packets are sent.

Figure 7: Comparison of RadioCountToLeds application.

Figure 8: Comparison of RadioSenseToLeds application.

Figure 9: Comparison of the Sense application.

In both Figures 7 and 8, the measurements reﬂect

the sender’s action of collecting the data to be sent

and sending it. Both ﬁgures show a similar perfor-

mance increase of approximately 4 ms for InceOS as

compared to TinyOS. This can be attributed to the

fact that the Insense behaviour clause is repeatedly

executed, rather than in TinyOS where events must

be generated before the application can continue to

SENSORNETS 2012 - International Conference on Sensor Networks

its next iteration. Figure 9 shows the comparison of

the Sense application from Figures 2 and 3. We can

see that InceOS performs a further 2 ms better than it

did in Figures 7 and 8. This is because unlike Radio-

Count/SenseToLeds, the InceOS Radio component is

not being used (or being scheduled) thus giving more

time for the Sense component to execute.

Figure 10: Comparison of the Fourier application.

Figure 10 shows an example of intense compu-

tation; the measurements reﬂect the time required to

complete a fast Fourier transform on a forty element

array and then calculate the maximum. Again In-

ceOS outperforms TinyOS. This is due to the use of

tasks in TinyOS to process the Fourier computation.

When the task is ﬁnished, it must be reposted, requir-

ing an invocation of the scheduler, whereas the be-

haviour clause in Insense is naturally repeated, not

requiring any intervention by the scheduler, or extra

code from the developer. This highlights that a purely

event-driven model is not well-suited to straight com-

putation (Dunkels et al., 2004).

Figure 11: Comparison of the Grid application.

The results for the grid application are shown in

Figure 11. Here the time for a complete iteration of

the application is taken: request a slave, give it work

and collect the reply. We see that InceOS performs

substantially better than TinyOS. The 35 ms differ-

ence is caused by a simpler ﬂow through the logic of

the Insense application and the relatively small num-

ber of actions required to access the sensor and radio

components. This is in contrast to the disjoint ﬂow

necessitated by control switching between the event

handlers of the application in nesC, as well as the

posting of a task to compute the Fourier transform.

Figure 12: Comparison of the TestRoundRobinArbiter ap-

plication.

The TestRoundRobinArbiter application results

are displayed in Figure 12, again showing an InceOS

performance gain when compared to TinyOS. Here

the 36 ms gain is because the Insense channel abstrac-

tion is used in InceOS to arbitrate access to the shared

resource, whereas additional functionality is required

for such arbitration using TinyOS. This particular ap-

plication is well-suited to the Insense blocking chan-

nel interaction which naturally handles arbitration.

5.6 Summary

The initial hypothesis was that sensor network appli-

cations written using a programming language with

more appropriate abstractions, such as active compo-

nents communicating over synchronous channels (as

provided by Insense/InceOS), ﬁt onto and run efﬁ-

ciently on real mote hardware. By comparing In-

sense implementations against equivalent nesC imple-

mentations on the same hardware platform, we have

demonstrated the following:

• It is possible to write functionally-equivalent pro-

grams in Insense with many fewer lines of code;

• InceOS applications consistently outperform

TinyOS for all applications in our test suite;

• Insense/InceOS systems consume more RAM and

Flash memory to provide this performance, but a

substantial fraction of each resource still remains

for use by applications.

CHANNEL AND ACTIVE COMPONENT ABSTRACTIONS FOR WSN PROGRAMMING - A Language Model with

Operating System Support

6 FUTURE WORK

Given the strong encapsulation exhibited by Insense

components, as well as the low coupling between

them, an obvious next step is to include dynamic re-

programming via the radio in Insense and an imple-

mentation in InceOS. This will enable dynamic, over-

the-air composition of components at runtime.

Currently the radio interaction is exposed to the

programmer and is the only means of inter-node com-

munication. Although the actual hardware interaction

is abstracted, the programmer is aware of the radio

transfer via the Radio component. Future work will

include the ability to introspect and react to the nodes

network environment, thus making it possible to dis-

cover a node’s neighbours and be alerted to changes.

New language-based systems can only become

prevalent if sufﬁcient program development, testing,

veriﬁcation, deployment, and runtime monitoring ca-

pabilities are also provided. We are building such a

development environment for Insense/InceOS-based

systems.

7 CONCLUSIONS

The language-speciﬁc operating system, InceOS, en-

ables programs written in Insense to exhibit the space

and time efﬁciency needed for production use in sen-

sor networks. A comparison of Insense/InceOS and

nesC/TinyOS code for a range of applications shows

that it is possible to write functionally-equivalent pro-

grams in fewer lines of Insense and that InceOS appli-

cations consistently outperform their TinyOS counter-

parts. Thus, use of the component-based abstractions

provided by Insense coupled with the efﬁcient sup-

port for these abstractions in InceOS facilitates the

development of WSN applications that exhibit state-

of-the-art performance while reducing programming

complexity.

More generally, we conclude that provision of

a language-speciﬁc operating system is an effective

mechanism for making programs written in higher-

level languages competitive with equivalent programs

written in lower-level languages supported by more

general-purpose operating systems.

REFERENCES

Burrell, J., Brooke, T., and Beckwith, R. (2004). Vineyard

computing: Sensor networks in agricultural produc-

tion. IEEE Pervasive Computing, 3:38–45.

Dearle, A., Balasubramaniam, D., Lewis, J., and Morri-

son, R. (2008). A component-based model and lan-

guage for wireless sensor network applications. In

COMPSAC ’08: Proceedings of the 2008 32nd An-

nual IEEE International Computer Software and Ap-

plications Conference, pages 1303–1308, Washing-

ton, DC, USA. IEEE Computer Society.

Dunkels, A., Gronvall, B., and Voigt, T. (2004). Contiki

- a lightweight and ﬂexible operating system for tiny

networked sensors. In LCN ’04: Proceedings of the

29th Annual IEEE International Conference on Lo-

cal Computer Networks, pages 455–462, Washington,

DC, USA. IEEE Computer Society.

Gay, D., Levis, P., von Behren, R., Welsh, M., Brewer, E.,

and Culler, D. (2003). The nesC language: A holistic

approach to networked embedded systems. In PLDI

’03: Proceedings of the ACM SIGPLAN 2003 con-

ference on Programming language design and imple-

mentation, volume 38, pages 1–11, New York, NY,

USA. ACM.

Hasler, A., Talzi, I., Tschudin, C., and Gruber, S. (2008).

Wireless sensor networks in permafrost research

- concept, requirements, implementation and chal-

lenges. In Proc. 9th Intl Conf. on Permafrost (NICOP

2008.

Hauer, J. (2006). nesc sense application reposi-

tory. Web Site. http://code.google.com/p/tinyos-

main/source/browse/trunk/apps/Sense/?r=2898 , Ac-

cessed on 25/09/2011.

Hewitt, C., Bishop, P., and Steiger, R. (1973). A universal

modular actor formalism for artiﬁcial intelligence. In

Proceedings of the 3rd international joint conference

on Artiﬁcial intelligence, pages 235–245, San Fran-

cisco, CA, USA. Morgan Kaufmann Publishers Inc.

Hill, J., Szewczyk, R., Woo, A., Hollar, S., Culler, D.,

and Pister, K. (2000). System architecture directions

for networked sensors. SIGOPS Oper. Syst. Rev.,

34(5):93–104.

Klues, K., Liang, C.-J. M., Paek, J., Mus

aloiu-E, R., Levis,

P., Terzis, A., and Govindan, R. (2009). Tosthreads:

thread-safe and non-invasive preemption in tinyos. In

Proceedings of the 7th ACM Conference on Embedded

Networked Sensor Systems, SenSys ’09, pages 127–

140, New York, NY, USA. ACM.

Milner, R., Parrow, J., and Walker, D. (1992). A calculus of

mobile processes, i. Inf. Comput., 100(1):1–40.

Porter, B. and Coulson, G. (2009). Lorien: a pure dy-

namic component-based operating system for wire-

less sensor networks. In MidSens ’09: Proceedings of

the 4th International Workshop on Middleware Tools,

Services and Run-Time Support for Sensor Networks,

pages 7–12, New York, NY, USA. ACM.

Rondini, E. and Hailes, S. (2007). Distributed compu-

tation in wireless ad hoc grids with bandwidth con-

trol. In Proceedings of the 5th international confer-

ence on Embedded networked sensor systems, SenSys

’07, pages 437–438, New York, NY, USA. ACM.

SENSORNETS 2012 - International Conference on Sensor Networks