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
Mar 27, 2015
A System Architecture for Tiny Networked Devices
Jason Hillhttp://www.cs.berkeley.edu/~jhill
http://tinyos.millennium.berkeley.edu
U.C. Berkeley
9/22/2000
Who We Are:
The Tiny OS Group Jason Hill – CS Grad Student [email protected]
Robert Szewczyk – CS Grad Student [email protected]
Alec Woo – CS Grad Student [email protected]
Seth Hollar – EE Grad Student [email protected]
David Culler (Prof.) [email protected]
Kris Pister (Prof.) [email protected]
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
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
COTS Dust
weC Mote
Tiny OS – The Software Provides a component based model abstracting
hardware specifics from application programmer Utilizes an event based programming model to allow
high levels of concurrency Allows multiple applications to be “running” Services Provided Include:
Active Messages Based messaging protocol 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.
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
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
Short Term Goals: Deploy sensor net in Soda for week long trial
runs Amass a collection of hundreds of first
generation nodes Improve Radio communication reliability Bring online second generation hardware Target Civil Engineering’s and The Center For
the Built Environment’s needs to get a real world deployment.
Support applications where data is “picked up” by UAV’s
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
TOS Component
Messaging Component
init
Po
we
r(m
od
e)
TX
_p
ack
et(
bu
f)
TX
_p
ack
et
_d
on
e
(su
cce
ss)
RX
_p
ack
et_
do
ne
(b
uff
er)
Internal State
init
po
we
r(m
od
e)
sen
d_
msg
(ad
dr,
typ
e,
da
ta)
msg
_re
c(ty
pe
, d
ata
)
msg
_se
nd
_d
on
e
(su
cce
ss)
send_msg_thread
/* 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);
//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)();
Event Based Prog. 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
Composition to Complete Application
RFM
Radio byte
Radio Packet
UART
Serial Packet
i2c
Temp
photo
Active Messages
clocksbit
byte
packet
Route map router sensor applnapplication
HW
SW