A System Architecture for Tiny Networked Devices

1. 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

2. Who We Are: • The Tiny OS Group • Jason Hill – CS Grad Student jhill@cs.berkeley.edu • Robert Szewczyk – CS Grad Student szewczyk@cs.berkeley.edu • Alec Woo – CS Grad Student awoo@cs.berkeley.edu • Seth Hollar – EE Grad Student shollar@eecs.berkeley.edu • David Culler (Prof.) culler@cs.berkeley.edu • Kris Pister (Prof.) pister@eecs.berkeley.edu

3. 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.

4. 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

5. ‘Mote’–The Hardware COTS Dust • 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 weC Mote

6. 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.

7. 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

8. 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

9. 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

10. 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

11. 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

12. Messaging Component Internal State send_msg_thread TX_packet(buf) Power(mode) init send_msg(addr, type, data) power(mode) msg_rec(type, data) msg_send_done (success) init RX_packet_done (buffer) TX_packet_done (success) 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); //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)();

13. 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

14. Composition to Complete Application Route map router sensor appln application Active Messages packet Serial Packet Temp Radio Packet SW byte HW UART Radio byte i2c photo bit clocks RFM