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