[SelfOrg], SS 2005 2-7.1

Self-Organization in Autonomous Sensor/Actuator Networks

[SelfOrg]Dr.-Ing. Falko Dressler

Computer Networks and Communication SystemsDepartment of Computer SciencesUniversity of Erlangen-Nürnberg

http://www7.informatik.uni-erlangen.de/~dressler/dressler@informatik.uni-erlangen.de

[SelfOrg], SS 2005 2-7.2

Overview

Self-OrganizationBasic methodologies of self-organization; comparison of central and hierarchical control, distributed systems, and autonomous behavior; examples of self-organization

Mobile Sensor/Actuator NetworksAd hoc routing; reliable communication and congestion control; sensor assistance for mobile robots; applications

Coordination of Autonomous SystemsCoordination and synchronization; communication aspects; clustering

Bio-inspired MechanismsSwarm intelligence; artificial immune system; intra/inter cellular information exchange

[SelfOrg], SS 2005 2-7.3

Case Study: Mica2 + TinyOS + Surge

HardwareMica2 / Mica2dotSensor boards

Programming environment (aka operating system)TinyOSnesC

Sensor applicationSurge

[SelfOrg], SS 2005 2-7.4

The MICA Architecture

Atmel ATMEGA103 4 Mhz 8-bit CPU128KB Instruction Memory

4KB RAM4 Mbit flash (AT45DB041B)

SPI interface1-4 uj/bit r/w

RFM TR1000 radio50 kb/s – ASKFocused hardware acceleration

Network programmingRich Expansion connector

i2c, SPI, GIO, 1-wireAnalog compare + interrupts

TinyOS tool chain sub microsecond RF synchronization primitive

Atmega103 Microcontroller

TR 1000 Radio Transceiver 4Mbit External Flash

51-Pin I/O Expansion Connector

Power Regulation MAX1678 (3V)

DS2401 Unique ID

8 Analog I/O 8 Programming Lines

SPI B

us

CoprocessorTransmissionPower Control

Hardware Accelerators

Digital I/O

2xAA form factor

[SelfOrg], SS 2005 2-7.5

Rich Sensor board

PHOTO

TEMP

MAGNETOMETER

MICROPHONE

SOUNDER

Mica PINS

X AxisY Axis Gain

Adjustment

MicSignal

ToneIntr

ACCELEROMETER

ADC Signals (ADC1-ADC6)

I2C BusOn/Off Control

Interrupt

1.25 in

LightSensor

TemperatureSensor

Microphone Sounder Magnetometer

2.25 in Accelerometer

[SelfOrg], SS 2005 2-7.6

Mote Evolution

[SelfOrg], SS 2005 2-7.7

Tiny OS Concepts

Scheduler + Graph of Componentsconstrained two-level scheduling model: threads + events

Component:Commands, Event HandlersFrame (storage)Tasks (concurrency)

Constrained Storage Modelframe per component, shared stack, no heap

Very lean multithreadingEfficient Layering

Messaging Component

init

Pow

er(m

ode)

TX_p

acke

t(buf

)

TX_p

ack

et_d

one

(suc

cess

)RX_

pack

et_d

one

(buf

fer)

Internal State

init

pow

er(m

ode)

send

_msg

(add

r, ty

pe, d

ata)

msg

_rec

(type

, dat

a)m

sg_s

end_

done

)

internal thread

Commands Events

[SelfOrg], SS 2005 2-7.8

Application = Graph of Components

RFM

Radio byte

Radio Packet

UART

Serial Packet

ADC

Temp photo

Active Messages

clocks

Route map router sensor appln

appl

icat

ion

pack

etbi

tby

te HW

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

3450 B code226 B data

Graph of cooperatingstate machines on shared stack

[SelfOrg], SS 2005 2-7.9

Sensor network programming challenges

Driven by interaction with environmentData collection and control, not general purpose computationReactive, event-driven programming model

Extremely limited resourcesVery low cost, size, and power consumptionTypical embedded OSs consume hundreds of KB of memory

Reliability for long-lived applicationsApps run for months/years without human interventionReduce run time errors and complexity

Soft real-time requirementsFew time-critical tasks (sensor acquisition and radio timing)Timing constraints through complete control over app and OS

[SelfOrg], SS 2005 2-7.10

TinyOS

Very small “operating system” for sensor networksCore OS requires 396 bytes of memory

Component-oriented architectureSet of reusable system components: sensing, communication, timers, etc.No binary kernel - build app specific OS from components

Concurrency based on tasks and eventsTask: deferred computation, runs to completion, no preemptionEvent: Invoked by module (upcall) or interrupt, may preempt tasks or other eventsVery low overhead, no threads

Split-phase operationsNo blocking operationsLong-latency ops (sensing, comm, etc.) are split phaseRequest to execute an operation returns immediatelyEvent signals completion of operation

[SelfOrg], SS 2005 2-7.11

TinyOS Execution Model

Commands request actionack/nack at every boundarycall cmd or post task

Events notify occurrenceHW intrupt at lowest levelmay signal eventscall cmdspost tasks

Tasks provide logical concurrencypreempted by events

Migration of HW/SW boundary

RFM

Radio byte

Radio Packet

bit

byte

pack

etevent-driven bit-pump

event-driven byte-pump

event-driven packet-pump

message-event drivenactive message

application comp data processing

crc

encode/decode

[SelfOrg], SS 2005 2-7.12

Programming TinyOS: nesC

Dialect of C with support for componentsComponents provide and require interfacesCreate application by wiring together components using configurations

Whole-program compilation and analysisnesC compiles entire application into a single C fileCompiled to mote binary by back-end C compiler (e.g., gcc)Allows aggressive cross-component inliningStatic race condition detection

Important restrictionsNo function pointers (makes whole-program analysis difficult)No dynamic memory allocationNo dynamic component instantiation/destructionThese static requirements enable analysis and optimization

[SelfOrg], SS 2005 2-7.13

Event-Driven Sensor Access Pattern

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

clock event handler initiates data collectionsensor signals data ready eventdata event handler calls output commanddevice sleeps or handles other activity while waitingconservative send/ack at component boundary

[SelfOrg], SS 2005 2-7.14

TinyOS Commands and Events

{...status = call CmdName(args)

...}

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

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

{...status = signal EvtName(args)

...}

[SelfOrg], SS 2005 2-7.15

TinyOS Execution Contexts

Events generated by interrupts preempt tasksTasks do not preempt tasksBoth essential process state transitions

Hardware

Interrupts

even

ts

commands

Tasks

[SelfOrg], SS 2005 2-7.16

Tasks

provide concurrency internal to a componentlonger running operations

are preempted by eventsable to perform operations beyond event contextmay call commandsmay signal eventsnot preempted by tasks

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

task void TskName {...}

[SelfOrg], SS 2005 2-7.17

Typical Application Use of Tasks

event driven data acquisitionschedule task to do computational portion

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);

}

• 128 Hz sampling rate• simple FIR filter• dynamic software tuning for centering the magnetometer signal (1208 bytes)

• digital control of analog, not DSP• ADC (196 bytes)

[SelfOrg], SS 2005 2-7.18

Task Scheduling

Currently simple FIFO schedulerBounded number of pending tasksWhen 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 and IPC

[SelfOrg], SS 2005 2-7.19

TinyOS Active Messages

SendingDeclare buffer storage in a frameRequest TransmissionName a handlerHandle Completion signal

ReceivingDeclare a handlerFiring a handler

automatic behaves like any other event

Buffer managementstrict ownership exchangetx: done event => reuserx: must rtn a buffer

[SelfOrg], SS 2005 2-7.20

Sending a Message

bool pending;

struct TOS_Msg data;

command result_t IntOutput.output(uint16_t value) {

IntMsg *message = (IntMsg *)data.data;

if (!pending) {

pending = TRUE;

message->val = value;

message->src = TOS_LOCAL_ADDRESS;if (call Send.send(TOS_BCAST_ADDR, sizeof(IntMsg), &data))

return SUCCESS;

pending = FALSE;

}

return FAIL;

}destination length

• Refuses to accept command if buffer is still full or network refuses to accept send command

• User component provide structured msg storage

[SelfOrg], SS 2005 2-7.21

Send Done Event

event result_t IntOutput.sendDone(TOS_MsgPtr msg, result_t success)

{

if (pending && msg == &data) {

pending = FALSE;

signal IntOutput.outputComplete(success);

}

return SUCCESS;

}

}

Send done event fans out to all potential sendersOriginator determined by match

free buffer on success, retry or fail on failureOthers use the event to schedule pending communication

[SelfOrg], SS 2005 2-7.22

Receive Event

event TOS_MsgPtr ReceiveIntMsg.receive(TOS_MsgPtr m) {

IntMsg *message = (IntMsg *)m->data;

call IntOutput.output(message->val);

return m;

}

Active message automatically dispatched to associated handlerknows the format, no run-time parsingperforms action on message event

Must return free buffer to the systemtypically the incoming buffer if processing complete

[SelfOrg], SS 2005 2-7.23

Maintaining Scheduling Agility

Need logical concurrency at many levels of the graphWhile meeting hard timing constraints

sample the radio in every bit window

⇒ Retain event-driven structure throughout application⇒ Tasks extend processing outside event window⇒ All operations are non-blocking

[SelfOrg], SS 2005 2-7.24

nesC Interfaces

nesC interfaces are bidirectionalCommand: Function call from one component requesting service from anotherEvent: Function call indicating completion of service by a componentGrouping commands/events together makes inter-component protocols clear

interface Timer {command result_t start(char type, uint32_t interval);command result_t stop();event result_t fired();

}interface SendMsg {

command result_t send(TOS_Msg *msg, uint16_t length);event result_t sendDone(TOS_Msg *msg, result_t success);

}

[SelfOrg], SS 2005 2-7.25

nesC Components

Two types of componentsModules contain implementation codeConfigurations wire other components togetherAn application is defined with a single top-level configuration

module TimerM {provides {

interface StdControl;interface Timer;

}uses interface Clock;

} implementation {command result_t Timer.start(char type, uint32_t interval) { ... }command result_t Timer.stop() { ... }event void Clock.tick() { ... }

}

[SelfOrg], SS 2005 2-7.26

Configuration Example

Allow aggregation of components into “supercomponents”

configuration TimerC {provides {

interface StdControl;interface Timer;

}} implementation {

components TimerM, HWClock;// Pass-through: Connect our "provides“// to TimerM "provides"

StdControl = TimerM.StdControl;Timer = TimerM.Timer;

// Normal wiring: Connect "requires" to "provides"TimerM.Clock -> HWClock.Clock;

}

[SelfOrg], SS 2005 2-7.27

Top-Level Configuration

[SelfOrg], SS 2005 2-7.28

Concurrency Model

Tasks used as deferred computation mechanism

// Signaled by interrupt handlerevent void Receive.receiveMsg(TOS_Msg *msg) {

if (recv_task_busy) {return; // Drop!

}recv_task_busy = TRUE;curmsg = msg;post recv_task();

}task void recv_task() {// Process curmsg ...

recv_task_busy = FALSE;}

Commands and events cannot blockTasks run to completion, scheduled non-preemptivelyScheduler may be FIFO, EDF, etc.

[SelfOrg], SS 2005 2-7.29

Main Loop of a TinyOS Application

[SelfOrg], SS 2005 2-7.30

Compilation of a TinyOS Application

[SelfOrg], SS 2005 2-7.31

Evaluation

TinyOS component censusCore TinyOS: 401 components (235 modules, 166 configurations)Average of 74 components per appModules between 7 and 1898 lines of code (avg. 134)

Race condition analysis on TinyOS treeOriginal code: 156 potential races, 53 false positivesFixed by using atomic or moving code into tasks

Race condition false positives:Shared variable access serialized by another variablePointer-swapping (no alias analysis)

[SelfOrg], SS 2005 2-7.32

Inlining and dead code elimination

Inlining and dead code elimination saves both space and time

[SelfOrg], SS 2005 2-7.33

TinyOS Kernel Efficiency and Simplicity Metrics

[SelfOrg], SS 2005 2-7.34

Surge Application

Surge is a java program for displaying multihop routing topology in sensor networksWhen working with multihop routing applications, Surge provides the following information to users:

Detects the existence of all the motes in a wireless network. Displays mote information,including the moteidentification number (ID),the number of messagessent from each mote, etc Displays the topologyof network

[SelfOrg], SS 2005 2-7.35

Surge Application: multi-hop data collection

Periodically collect sensor readings and route to baseTimer component fires event to read from ADCADC completion event initiates communication

Multihop routing using adaptive spanning treeNodes route messages to parent in treeParent selection based on link quality estimationSnoop on radio messages to find better parent

[SelfOrg], SS 2005 2-7.36

Raw Data Packet

[SelfOrg], SS 2005 2-7.37

TOS_Msg Data Packet

[SelfOrg], SS 2005 2-7.38

Multihop Message

[SelfOrg], SS 2005 2-7.39

Surge Message