Upload
red
View
48
Download
0
Tags:
Embed Size (px)
DESCRIPTION
System Architecture Directions for Networked Sensors. Qiuhua Cao (qc9b@cs) Computer Science Department University of Virginia. Outline. Hardware Organization of Berkeley Motes Critical Issues of Sensor Networks Does an OS for the Motes exsit? Design Goals of TinyOS Concepts in TinyOS - PowerPoint PPT Presentation
Citation preview
System Architecture Directions for Networked Sensors
Qiuhua Cao (qc9b@cs)
Computer Science Department
University of Virginia
Outline Hardware Organization of Berkeley Motes Critical Issues of Sensor Networks Does an OS for the Motes exsit? Design Goals of TinyOS Concepts in TinyOS Examples Evaluation and Critiques
Hardware Platform-Motes
Assembled from off-the-shelf components 4Mhz, 8bit MCU (ATMEL 90LS8535)
– 512 bytes RAM, 8K ROM 900Mhz Radio (RF Monolithics)
– 10-100 ft. range Temperature & Light Sensor LED outputs Serial Port
Critical Issues for Sensor Networks Highly Limited Device
power, memory, bandwith Inherently Distributed
large number of nodes coordinate, cooperate with each other to fulfill an job
Devices themselves are the infrastructure ad hoc, self-organized
Highly Dynamic failure in common variation in connectivity over time
Does an OS for the Motes exist?
Traditional OS design wait request, act, respond loop monolithic event processing full thread/socket POSIX regime
Alternative concurrency and modularity never poll, never block data flows, events, power management interact
Design Goals of TinyOS
Concurrency-Intensive Operations flow information from place to place on-the-fly Example: simultaneously capture data from
sensors, processing the data, then send out to the network
Design Goals of TinyOS (cont.)
Limited Physical Parallelism and Controller Hierarchy Less independent controllers Less processor-memory-switch level Sensor and Actuator directly interact with the
single-chip micro controller
Design Goals of TinyOS (cont.)
Diversity in Design and Usage Sensor network application specific design But wide range potential applications deep modularity of software needed
Design Goals of TinyOS (cont.)
Robust Operations Cross devices redundancy prohibitive Individual reliable devices desired Application tolerant individual device failures
Concepts in TinyOS Application = graph of components +
scheduler Example: INT_TO_LEDS
MIAN
COUNTER
CLOCKINT_TO_LEDS
LED
Concepts in TinyOS (cont.)
Component Implementation (.c file)
Frame a set of commands a set of handlers a set of tasks
Interface (.comp) Description file (.desc)
Concepts in TinyOS (cont.) Frame
Contains all permanent state for component (lives across events, commands, and threads)
Threads, events, and commands execute inside the component’s frame
Only one per component • Like static class variables, not internal class
variables. Fixed size Statically allocated at compile time
Concepts in TinyOS Frame example:
Frame declaration
#define TOS_FRAME_TYPE AM_obj_frameTOS_FRAME_BEGIN(AM_obj_frame) { int addr; char type; char state; char* data; char msgbuf[30];}TOS_FRAME_END(AM_obj_frame);
VAR(state) = 0;
Use of frame Variables:
Commands: Commands deposit request parameters into its frame Commands can call lower level commands Commands can post tasks Commands no-blocking Commands needed to return status Declaration TOS_COMMAND(cmd_name)(cmd_args_list); USE: TOS_CALL_COMMAND(cmd_name)(cmd_args_list);
Events Deposit information into frame Events can call lower level commands Post tasks and fire higher level events. Events can not be signaled by commands, Declaration
char TOS_EVENT(evnt_name)(evnt_arg_list);
Use TOS_SIGNAL_EVENT(evnt_name)(evnt_arg_list);
Tasks Tasks perform work that is computationally intensive. FIFO scheduler Run-to-completion Non-preemptable among tasks (concurrent) Preemptable by events Task declaration:
TOS_TASK(task_name){….} Posting a task:
– Asynchronous call to schedule the task for later execution
– USE: TOS_POST_TASK(avg_task);
Commands, Events, Tasks
Relationship Graph
Higher Level Component
Lower Level Component
Signal events
Issue cmds
Commands can not signal Events
Both event and cmd can schedule tasks
Tasks preemptive by Envents
Tasks non preemptive by Tasks
An Component Example
Messagin
g Com
pon
ent
init
Power(mode)
TX_packet(buf)
TX_packet_done (success)
RX_packet_done (buffer)
Intern
al State
init
power(mode)
send_msg(addr, type, data)
msg_rec(type, data)
msg_send_done (success)
send
_msg_th
read
Cmd Issued
Cmd accepted
Events handled
Eventssignaled
An Component Example (cont. ) .comp file interface definition TOS_MODULE name;
ACCEPTS{ command_signatures };
HANDLES{ event_signatures };
USES{ command_signatures };
SIGNALS{ event_signatures };
An Component Example (cont. )
.comp file interface definition//ACCEPTS:char TOS_COMMAND(AM_send_msg)(int addr,
int type, char* data);void TOS_COMMAND(AM_power)(char mode);char TOS_COMMAND(AM_init)();
//SIGNALS: char AM_msg_rec(int type, char* data);char AM_msg_send_done(char success);
An Component Example (cont.)
//HANDLES:char AM_TX_packet_done(char success);char AM_RX_packet_done(char* packet);
//USES:
char TOS_COMMAND(AM_SUB_TX_packet)(char* data);
void TOS_COMMAND(AM_SUB_power)(char mode);
char TOS_COMMAND(AM_SUB_init)();
An Component Example (cont.) .c file frame, commands, events implementation #define TOS_FRAME_TYPE AM_obj_frame
TOS_FRAME_BEGIN(AM_obj_frame) { char state; TOS_MsgPtr msg; }TOS_FRAME_END(AM_obj_frame);
// This task schedules the transmission of the Active MessageTOS_TASK(AM_send_task){ //construct the packet to be sent,fill in dest and type if(!TOS_CALL_COMMAND(AM_SUB_TX_PACKET)(VAR(msg)))
{ VAR(state) = 0; TOS_SIGNAL_EVENT(AM_MSG_SEND_DONE)(VAR(msg)); return; }}
.c file frame, commands, events implementation // Command to be used for power management
char TOS_COMMAND(AM_POWER)(char mode){ TOS_CALL_COMMAND(AM_SUB_POWER)(mode); VAR(state) = 0; return 1; } // Handle the event of the completion of a message transmission char TOS_EVENT(AM_TX_PACKET_DONE)(TOS_MsgPtr msg){ //return to idle state. VAR(state) = 0; //fire send done event. TOS_SIGNAL_EVENT(AM_MSG_SEND_DONE)(msg); return 1; }
An Component Example (cont. )
.desc file component modules specified the wiring of commands and events across
component interfaces Example:
include modules{ module list }; connection list
Storage Model One frame per component, shared stack
Previous frame
Current frame
Next frame
%sp
%fp(old %sp)
variable
data
Stack Growth
Storage Model (cont.) Message Buffer
Strict alternating ownership protocol Only TOS_MSG type pointer across component
AM
send_msgAM is owner of message buffer, the requesting component can not access this message buffer
send_done
AM gives up the owner of message buffer,
Storage Model (cont.)char TOS_COMMAND(INT_TO_RFM_OUTPUT)(int val){
... if (!VAR(pending)) { VAR(pending) = 1; message->val = val; message->src = TOS_LOCAL_ADDRESS; if (TOS_COMMAND(INT_TO_RFM_SUB_SEND_MSG)(TOS_BCAST_ADDR, AM_MSG(INT_READING), &VAR(data))) { return 1; } else { VAR(pending) = 0; /* request failed, free buffer */ } } return 0; }
Scheduler
Two-level scheduling structure– Tasks, Events
FSM execution model– Each task is like a state in the state machine,
which the events are like input signals
Events model– When there is no event, CPU is put in idle
An example of Execution Model
Get_Light
Send_MsgSleep
Light done event / Msg send command
Msg sent event / Power down command
Clock Event / Light Request Command
Add a task
Get_Light
Send_MsgSleep
Clock Event / Light Request Command
Thread Schedule / Msg send command
Msg sent event / Power down command
Calc. AverageLight done event / Post Task
An Composition Example
RFM
Radio Byte
Radio Packet
I2C
photo
Messaging Layer
clocksbit
byte
packet
Routing Layer
sensing application
HW
SW
ADC
routing
Temp
An Composition Example
RFM
Radio Byte
Radio Packet
I2C
photo
Messaging Layer
clocks
Routing Layer
sensing application
HW
SW
ADC
Temp
Send_message
An Composition Example
RFM
Radio Byte
Radio Packet
I2C
photo
Messaging Layer
clocks
Routing Layer
sensing application
HW
SW
ADC
Temp
TX_Packet
An Composition Example
RFM
Radio Byte
Radio Packet
I2C
photo
Messaging Layer
clocks
Routing Layer
sensing application
HW
SW
ADC
Temp
TX_byte
An Composition Example
RFM
Radio Byte
Radio Packet
I2C
photo
Messaging Layer
clocks
Routing Layer
sensing application
HW
SW
ADC
Temp
TX_Bit_Event
An Composition Example
RFM
Radio Byte
Radio Packet
I2C
photo
Messaging Layer
clocks
Routing Layer
sensing application
HW
SW
ADC
Temp
TX_Bit_Done
An Composition Example
RFM
Radio Byte
Radio Packet
I2C
photo
Messaging Layer
clocks
Routing Layer
sensing application
HW
SW
ADC
Temp
TX_Byte_Done
An Composition Example
RFM
Radio Byte
Radio Packet
I2C
photo
Messaging Layer
clocks
Routing Layer
sensing application
HW
SW
ADC
Temp
TX_Packet_Done
An Composition Example
RFM
Radio Byte
Radio Packet
I2C
photo
Messaging Layer
clocks
Routing Layer
sensing application
HW
SW
ADC
Temp
Msg_Send_Done
Evaluation
meet power constraints?
Active Idle Sleep
CPU 5 mA 2 mA 5 μA
Radio 7 mA (TX) 4.5 mA (RX) 5 μA
EE-Prom 3 mA 0 0
LED’s 4 mA 0 0
Photo Diode 200 μA 0 0
Temperature 200 μA 0 0
Evaluation meet power save?
Battery Lifetime for sensor reporting every minute
Duty Cycle
Estimated Battery Life
Full Time Listening 100% 3 Days
Full Time Low Power Listening
100% 6.54 Days
Periodic Multi-Hop Listening
10% 65 Days
No Listening 0.01% Years
Evaluation meet memory constraints?
Evaluation
Meet concurrent-intensive operations? Event-driven architecture Efficient interrupts/events handling (function
calls, no user/kernel boundary)
Modularity? Function call (event, command) interface
between components
Critique Real-time not addressed
Non-preemptable FIFO task scheduling NO real-time guarantees or overload protection
Tasks are dispatched to either software or hardware to best utilize the whole system resources but in TinyOS, all tasks go into software.
Adding event queues at the lowest layers can reduce the external event losses
The OS should collect runtime profiles and statistics, perform periodic system maintenance operations and maintain system level power state
No opposite argument
Thanks!!
Any Question??