WSN Software Platforms - concepts

WSN Software Platforms - concepts

Vinod Kulathumani

Lecture uses some slides from tutorials prepared by authors of these platforms

2

Outline

• Software concepts

TinyOS

3

Traditional Systems

• Well established layers of abstractions

• Strict boundaries

• Ample resources

• Independent applications at endpoints communicate pt-pt through routers

• Well attended

User

System

Physical Layer

Data Link

Network

Transport

Network Stack

Threads

Address Space

Drivers

Files

Application

Application

Routers

4

Sensor Network Systems

• Highly constrained resources

processing, storage, bandwidth, power, limited hardware

parallelism, relatively simple interconnect

• Applications spread over many small nodes

self-organizing collectives

highly integrated with changing environment and network

diversity in design and usage

• Concurrency intensive in bursts

streams of sensor data

• Unclear where boundaries belong

5

Choice of Programming Primitives

• Traditional approaches

monolithic event processing

full thread/socket posix regime

• Alternative

provide framework for concurrency and modularity

never poll, never block

interleaving flows, events

6

Split-Phase operation

• Consider sampling from ADC

Option 1: make ADC synchronous by blocking

CPU wasted

Option 2: achieve the same by using threads

Too much memory

Option 3: use split-phase operation

Commands

Events

7

TinyOS

• most popular operating system for WSN

developed by UC Berkeley

• features a component-based architecture

software is written in modular pieces called components Each component denotes the interfaces that it provides

An interface declares a set of functions called commands

the interface provider implements

and another set of functions called events

the interface user should be ready to handle

• Easy to link components together by “wiring” their interfaces to form larger components

similar to using Lego blocks

8

TinyOS

• Microthreaded OS (lightweight thread support) and efficient

network interfaces

• Two level scheduling structure

Long running tasks that can be interrupted by hardware events

• Small, tightly integrated design that allows crossover of

software components into hardware

9

TinyOS

• provides a component library that includes network protocols, services, and sensor drivers

• An application consists of

a component written by the application developer and the library components that are used by the components in (1)

10

Components

• A component has:

Frame (internal state) Tasks (computation) Interface (events, commands)

• Frame :

one per component statically allocated fixed size

Tasks

ComponentFrame

EventsCommands

● Commands and Events are function calls● Application: linking/glueing interfaces (events, commands)

11

Commands/Events

• commands:

deposit request parameters into the frame

are non-blocking

need to return status => postpone time consuming work by posting a task

can call lower level commands

• events:

can call commands, signal events, post tasks

preempt tasks, not vice-versa

interrupt trigger the lowest level events

deposit the information into the frame

12

TinyOS Commands and Events

{... status = call CmdName(args)...}

command CmdName(args) {...return status;}

{... status = signal EvtName(args)...}

event EvtName(args) {...return status;}

13

Application = Graph of Components

RFM

Radio byte

Radio Packet

UART

Serial Packet

ADC

Temp Photo

Active Messages

clock

bit

by

tep

ac

ke

t

Route map Router Sensor Appln

ap

pli

ca

tio

n

HW

SW

Example: ad hoc, multi-hop routing of photo sensor readings

3450 B code 226 B data

Graph of cooperatingstate machines on shared stack

14

Event-Driven Sensor Access Pattern

• clock event handler initiates data collection

• sensor signals data ready event

• data event handler calls output command

• device sleeps or handles other activity while waiting

• conservative send/ack at component boundary

command result_t StdControl.start() {

return call Timer.start(TIMER_REPEAT, 200);

}

event result_t Timer.fired() {

return call sensor.getData();

}

event result_t sensor.dataReady(uint16_t data) {

display(data)

return SUCCESS;

}

SENSE

Timer Photo LED

15

Introducing preemption

• Preemption needed for concurrency and realtime operations

• Important events cannot be missed

• Can all code simply be preemptible?

Leads to unmanageable race conditions

• TinyOS distinguishes async and sync code

16

Async and sync

• Any TinyOS code can be preempted

• Only Async code can preempt

• Sync code cannot preempt

• All code by default are sync

• Interrupts are async (so that they can preempt running code)

• Async methods call only async methods

Cannot call sync methods

17

Why all code cannot be async

command result_t SendMsg.send ... {if (!state) {

state = TRUE;// send a packetreturn SUCCESS;

}return FAIL;

}

What happens if this were async?Or if an async event handler could call this method?

18

Another example

• The receive event that processes incoming message is “sync”

• Why?

Event Radioreceive (Msg) {

// Process message

}

Else message processing order can be reversed

• But then how does async “receive” interrupt signal radioreceive event [which is sync]?

Posts a task Task signals radio receive event Tasks execute sequentially Tasks are “sync” but posting task is “async” command

19

Tasks

• provide concurrency internal to a component

longer running operations

• are preempted by async events

• able to perform operations beyond event context

• may call commands; may signal events

• Only one instance of a task can be outstanding at any time

• not preempted by tasks

{...post TskName();...}

task void TskName {...}

20

Typical Application Use of Tasks

• event driven data acquisition

• schedule task to do computational portion

• Keep tasks short as well

event result_t sensor.dataReady(uint16_t data) { putdata(data); post processData(); return SUCCESS; }task void processData() { int16_t i, sum=0; for (i=0; i ‹ maxdata; i++) sum += (rdata[i] ›› 7); display(sum ›› shiftdata); }

21

Why tasks need to be short

• Otherwise processing of important events can be delayed

• Example reception of message

• Recall, when message received task posted to signal the received event

If task too long, then the message gets processed late Instead tasks should be broken up into smaller tasks and keep

reposting

22

Keep tasks short - example

• Consider two cases

In case 1, a sensor processing component posts tasks that run for 5ms

In case 2, the processing components post tasks that run for 500us and repost themselves to continue the work

If the radio stack posts a task to signal an event that a message has arrived, what is the maximum expected latency for the radio task, incurred in the task queue in case 1 and case 2.

23

Task Scheduling

• Currently simple fifo scheduler

• Bounded number of pending tasks

• When idle, shuts down node except clock

• Uses non-blocking task queue data structure

• Simple event-driven structure + control over complete

application/system graph

instead of complex task priorities

24

Handling Concurrency: Async or Sync Code

Async methods call only async methods (interrupts are async)

Potential race conditions:any update to shared state from async codeany update to shared state from sync code that is

also updated from async code

Compiler rule:if a variable x is accessed by async code, then any accessof x outside of an atomic statement is a compile-time error

Race-Free Invariant: any update to shared state is either not a potential racecondition (sync code only) or is within an atomic section

25

Atomicity Support in nesC

• Split phase operations require care to deal with pending operations

• Race conditions may occur when shared state is accessed by premptible executions, e.g. when an event accesses a shared state, or when a task updates state (premptible by an event which then uses that state)

• nesC supports atomic block

implemented by turning off interrupts for efficiency, no calls are allowed in block access to shared variable outside atomic block is not allowed

26

Benefits of using TinyOS

• Separation of concerns

TinyOS provides a proper networking stack for wireless communication

abstracts away the underlying problems and complexity of message transfer from the application developer

E.g., MAC layer

27

Benefits of TinyOS

• Modularity

facilitates reuse and reconfigurability software is written in small functional modules several middleware services are available as well-documented

components Over 500 research groups and companies using TinyOS numerous groups actively contributing code to the public domain

28

Benefits of TinyOS

• Concurrency control

TinyOS provides a scheduler that achieves efficient concurrency control

An interrupt-driven execution model is needed to achieve a quick response time for the events and capture the data

For example, a message transmission may take up to 100msec, and without an interrupt-driven approach the node would miss sensing and processing of interesting data in this period

Scheduler takes care of the intricacies of interrupt-driven execution and provides concurrency in a safe manner by scheduling the execution in small threads.

29

TinyOS Limitations

• Static allocation allows for compile-time analysis, but can make programming harder

• No support for heterogeneity

Support for other platforms (e.g. stargate)

Support for high data rate apps (e.g. acoustic beamforming)

Interoperability with other software frameworks and languages

• Limited visibility

Debugging

Intra-node fault tolerance

• Robustness solved in the details of implementation

nesC offers only some types of checking