A System Architecture for Tiny Networked Devices Jason Hill http://www.cs.berkeley.edu/~jhill http://tinyos.millennium.berkeley.edu U.C. Berkeley 9/22/2000 Goals: To develop an ultra low power networked sensor platform, including hardware and software, that.
Download
Report
Transcript A System Architecture for Tiny Networked Devices Jason Hill http://www.cs.berkeley.edu/~jhill http://tinyos.millennium.berkeley.edu U.C. Berkeley 9/22/2000 Goals: To develop an ultra low power networked sensor platform, including hardware and software, that.
A System Architecture for Tiny
Networked Devices
Jason Hill
http://www.cs.berkeley.edu/~jhill
http://tinyos.millennium.berkeley.edu
U.C. Berkeley
9/22/2000
Goals:
To develop an ultra low power networked
sensor platform, including hardware and
software, that enables low-cost deployment
of sensor networks.
To be a system level bridge that combines
advances in low power RF technology with
MEMS transducer technology.
Key Characteristics of TNDs
Small physical size and low power consumption
=> Limited Physical Parallelism and Controller Hierarchy
=> primitive direct-to-device interface
Concurrency-intensive operation
flow-thru, not wait-command-respond
=> must handle multiple inputs and outputs simultaneously
Diverse in Design and Usage
application specific, not general purpose
huge device variation
=> efficient modularity
=> migration across HW/SW boundary
Largely Unattended & Numerous
=> robust operation
=> narrow interfaces
‘Mote’–The Hardware
COTS Dust
weC Mote
4Mhz, 8bit MCU (ATMEL)
512 bytes RAM, 8K ROM
900Mhz Radio (RF Monolithics)
10-100 ft. range
Temperature Sensor
Light Sensor
LED outputs
Serial Port
Second Generation ‘Mote’
Two Board Sandwich
Main CPU board with
Radio Communication
Secondary Sensor
Board
Allows for expansion and
customization
Current sensors include: Acceleration, Magnetic
Field, Temperature, Pressure, Humidity, Light, and
RF Signal Strength.
Can control RF transmission strength & Sense
Reception Strength
Tiny OS – The Software
Provides a component based model abstracting hardware
specifics from application programmer.
Capable of maintaining high levels of concurrency.
Allows multiple applications to be “running.”
Services Provided Include:
RF messaging protocols.
Periodic Timer Events.
Asynchronous access to UART data transfers.
Mechanism for Static, Persistent Storage.
Can “Swap Out” system components to get necessary
functionality.
Complete applications fit in 4KB of ROM and 256B RAM.
Tiny OS Internals
Scheduler and Graph of Components
constrained two-level scheduling model: tasks + events
Component:
Frame (storage)
Tasks (concurrency)
Commands, and Handlers (events)
Constrained Storage Model
frame per component, shared stack, no heap
Very lean multithreading
Layering
components issue commands to lower-level components
event signal high-level events, or call lower-level
commands
Guarantees no cycles in call chain
msg_send_
done
(success)
msg_rec(type, data)
send_msg(ad
dr, type,
data)
power(mode)
init
TOS Component
/* Messaging Component Declaration */
//ACCEPTS:
char TOS_COMMAND(AM_SEND_MSG)(char addr,char
type, char* data);
void TOS_COMMAND(AM_POWER)(char mode);
char TOS_COMMAND(AM_INIT)();
//SIGNALS:
char AM_MSG_REC(char type, char* data);
char AM_MSG_SEND_DONE(char success);
Messaging Component
Commands
Internal State
TX_packet
_done
(success)
RX_packet_
done
(buffer)
init
Power(mode)
TX_packet(buf)
send_msg_thread
Events
//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)();
Composition to Complete
Application
application
Route map
router
sensor appln
Active Messages
packet
Radio Packet
Serial Packet
Temp
Radio byte
UART
i2c
SW
byte
HW
photo
bit
RFM
clocks
Programming with CAD
Can assemble overall system using
structural VHDL
Scripts pre-process VHDL at compile
time
Allows for compile time resolution of
event handlers
Eliminates need for registration
mechanisms and dynamic dispatch
Automatically allows events to be
handled by multiple components.
(TX_Done)
Significantly more flexibility than
library based component models
Event Based Programming Model
System composed of state machines
Each State Machine is a TinyOS “component”
Command and event handlers transition a component
from one state to another
Quick, low overhead, non-blocking state transmissions
Allows many independent components to share a single
execution context
Emerging as design paradigm for large scale systems
“Tasks” are used to perform computational work
Run to completion, Atomic with respect to each other
Dynamics of Events and
Threads
Message Send Transition
Timing diagram of event propagation
Multi-Hop Routing Demo
Sensors automatically assemble and determine routing topology
Parallel Breadth First Search
Shortest path to all nodes remembered
Base station broadcasts out routing information
Individuals listen for and propagate route update
N messages sent
Generational scheme to prevent cycles in routing table
Base
Demo (cont.)
Sensor information
propagated up routing
tree
Statistics kept for number
of readings received and
number of packets
forwarded by each node
Sensors transmit data
when “significant” events
occur or when time limit
is exceeded
Must be continuously
listening for packets to be
forwarded – impacts
power considerations
Future Goals:
Short Term
Deploy sensor net for week long trials
Target Civil Engineering’s and The Center For the
Built Environment’s needs for a real world
deployment.
Determine algorithms for aggregation and analysis
of data inside the network.
Support applications where data is “picked up” by
roaming data collection nodes.
Long Term
Deploy networks of 1000s of nodes
Year long, unattended deployments