towards system architecture for tiny networked devices jason hill jhill jhill/tos u.c. berkeley
TRANSCRIPT
Towards System Architecture for Tiny Networked Devices
Jason Hill
http://www.cs.berkeley.edu/~jhill
http://www.cs.berkeley.edu/~jhill/tos
U.C. Berkeley
6/20/2000
6/20/2000 Endeavor Retreat 2
An End-to-end Perspective
• Desktops– max out at few 100M– in your face– connected to the infrastructure
• Ubiquitous Devices– billions– sensors / actuators– PDAs / smartphones / PCs– heterogeneous
Service Path
• Scalable Infrastructure– highly available– persistent state (safe)– databases, agents– service programming environment
6/20/2000 Endeavor Retreat 3
Key Characteristics of TNDs
• Small physical size and low power consumption
• Concurrency-intensive operation– flow-thru, not wait-command-respond
• Limited Physical Parallelism and Controller Hierarchy– primitive direct-to-device interface
• Diversity in Design and Usage– application specific, not general purpose
– huge device variation
=> efficient modularity
=> migration across HW/SW boundary
• Robust Operation– numerous, unattended, critical
=> narrow interfaces
6/20/2000 Endeavor Retreat 4
‘Mote’ Initial Platform
• 4Mhz, 8bit MCU512 bytes RAM, 8K ROM
• 900Mhz Radio10-30 ft. range
• Temperature Sensor• Light Sensor• LED outputs• Serial Port
6/20/2000 Endeavor Retreat 5
Tiny OS
• Scheduler and Graph of Components– constrained two-level scheduling model: threads + events
• Component:– Frame (storage)– Threads (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
6/20/2000 Endeavor Retreat 6
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)();
6/20/2000 Endeavor Retreat 7
Composition
RFM
Radio byte
Radio Packet
UART
Serial Packet
i2c
Temp
photo
Active Messages
clocksbit
byte
packet
Route map router sensor applnapplication
HW
SW
6/20/2000 Endeavor Retreat 8
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
6/20/2000 Endeavor Retreat 9
Migration of the Hardware Software Boundary
• TinyOS component model propagates hardware abstractions into software
• Allows for a migrations of software components into hardware:
• Example:– Bit level radio procession component could be implemented
as specialized FIFO with complex pattern matching.
6/20/2000 Endeavor Retreat 10
Dynamics of Events and Threads
• Message Send Transition
Timing diagram of event propagation
6/20/2000 Endeavor Retreat 11
Empirical Breakdown of Effort
• can take apart time, power, space, …• 50 cycle thread overhead, 10 cycle event overhead
ComponentsPacket reception work breakdown
Percent CPU Utilization Energy (nj/Bit)
AM 0.05% 0.20% 0.33
Packet 1.12% 0.51% 7.58
Ratio handler 26.87% 12.16% 182.38
Radio decode thread 5.48% 2.48% 37.2
RFM 66.48% 30.08% 451.17
Radio Reception - - 1350Idle - 54.75% -Total 100.00% 100.00% 2028.66
6/20/2000 Endeavor Retreat 12
Storage Breakdown (C Code)
0
500
1000
1500
2000
2500
3000
3500
4000
Multihop Router
AM light
AM Temp
AM
Packet
Radio Byte
RFM
Photo
Temp
UART Packet
UART
i2c
Init
TinyOS Scheduler
C Runtime
3450 B code 226 B data
6/20/2000 Endeavor Retreat 13
Projects this Term
• Device Proxy Architecture– mobile-IP RDP variant
• Integration with infrastructure – JINI and Ninja
• Multithreaded vs. federated architecture
• Pluggable adaptive MAC layer– often periodic, moment of crisis
– sleep cycling
• Ad Hoc routing component
• Connectivity-based location detection
• smart badge + sensor in smart space
6/20/2000 Endeavor Retreat 14
Multi-Hop Routing Demo
• Sensors automatically detect routing topology
• Base station broadcasts out routing information
• Individuals listen for an propagate route update– N messages sent
• Generational scheme to prevent cycles in routing table
Base
6/20/2000 Endeavor Retreat 15
Multi-Hop Routing Demo (cont.)
• Sensor information propagated up routing tree
• Statistics kept as to number of readings received and number of packets forwarded for each node
• Sensors transmit data when “significant” events occur or when time limit is exceeded
• Must be continuously listening for packets to be forwarded
6/20/2000 Endeavor Retreat 16
Second generation hardware design is under way• Mote “designed for experimentation”
• Additional Sensors– 2 Axis Accelerometer and 2 Axis Magnetometers
» Allows dead reckoning in 2-D plane
– Humidity, Temperature, and Pressure sensor
– Transmission strength sensor and control
• Expansion capabilities through external BUS– The hardware sandwich
• Ability to directly plug into logic analyzer for debugging purposes
6/20/2000 Endeavor Retreat 17
Current and Future Work
• Quantify error characteristics of RFM Radio– Allows selection of coding techniques that optimize
throughput and reliability
• Aggressive inlining to minimize overhead of modules
• Document and release code for others to use
• Determine limitations of TinyOS
• Incorporate more exciting HW architectures
• Integrate with Ninja active proxies and Base services