A System Architecture for Tiny Networked Devices Jason Hill jhill U.C. Berkeley 9/22/2000

Preview:

Citation preview

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

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

Recommended