self-organization in autonomous sensor/actuator...
TRANSCRIPT
[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/[email protected]
[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.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.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.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.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