Overview of: System Architecture Directions for

Networked Sensors

John Kerwin

CSE 291 Sensor Networks

Paper by:

Jason Hill, Robert Szewczyk, Alec Woo, Seth Hollar, David Culler, Kris Pister

http://webs.cs.berkeley.edu/tos/

Motivation

Sensor networks are new computing environments in the post-PC era that are different from traditional desktop and server environments.

There are several trends working together to enable the networked sensor: Moore’s Law System on a chip Micro-electromechanical sensors (MEMS) Integrated low power communication

Motivation (cont)

Today, sensors exist on the scale of a square inch in size, and a fraction of a watt in power.

In the future, it may be possible to reduce sensors to the size of a cubic millimeter, or smaller.

The key missing technology for these devices is system software to manage and operate them efficiently.

Project Objectives

Create a prototype of a current generation sensor constructed from off the shelf components.

Identify key requirements that an operating system for such a sensor must satisfy.

Build an operating system that meets these requirements.

Evaluate the operating system’s performance while running a real application.

Today’s Hardware

Assembled from off-the-shelf components

4Mhz, 8bit MCU (ATMEL) 512 bytes RAM, 8KB ROM

900Mhz Radio (RF Monolithics) 10-100 ft. range

Temperature Sensor & Light Sensor

LED outputs Serial Port

1.5” x 1.5”

Slide courtesy Jason Hill et al

Hardware Features

3 Sleep Modes that can shut off the processor and other components not required for wake up.

Radio can transfer data at up to 19 Kbps, with no data buffering.

Sensor consumes about 19.5 mA at peak load, and 10 μA when inactive.

A 575 mAh battery can power a sensor for 30 hours at peak load, or for over a year when inactive.

Image courtesy Jason Hill et al

Operating System Requirements

Small physical size and low power consumption Devices have limited memory and power resources

Concurrency intensive operation Need to be able to service packets on-the-fly in real-time

Limited hardware parallelism and controller hierarchy Limited number, and capability of controllers Unsophisticated processor-memory-switch level

interconnect Diversity in design and usage

Provide a high degree of software modularity for application specific sensors

Robust Operation OS should be reliable, and assist applications in surviving

individual device failures

The Solution: TinyOS

A microthreaded OS that draws on previous work done for lightweight thread support, and efficient network interfaces

Two level scheduling structure Long running tasks that can be interrupted by

hardware events Small, tightly integrated design that allows

crossover of software components into hardware

TinyOS Component Model

Component has:Frame (storage)Tasks (computation)Command and Event

Interface

Messaging Component

Internal StateInternal Tasks

Commands Events

Image courtesy Jason Hill et al

To facilitate modularity, each component declares the commands it uses and the events it signals.

Statically allocated, fixed sized frames allow us to know the memory requirements of a component at compile time, and avoid the overhead associated with dynamic allocation.

Tasks

Perform the primary computation work Atomic with respect to other tasks, and run to

completion, but can be preempted by events Allow the OS to allocate a single stack

assigned to the currently executing task Call lower level commands Signal higher level events Schedule other tasks within a component Simulate concurrency using events

Commands

Non-blocking requests to lower level components

Deposit request parameters into a component’s frame, and post a task for later execution

Can also invoke lower level commands, but cannot block

To avoid cycles, commands cannot signal events

Return status to the caller

Events

Event handlers deal with hardware events (interrupts) directly or indirectly

Deposit information into a frame Post tasks Signal higher level events Call lower level commands

TOS Component

Messaging Component

AM_SUB_INIT

AM_SUB_POWER

AM_SUB_TX_PACKET

AM_TX_PACKET

_DONE

AM_RX_PACKET

_DONE

Internal State

AM_INIT

AM_POWER

AM_SEND_MSG

AM_MSG_REC

AM_MSG_SEND_DONE

Internal Tasks

Commands Events

//AM.comp//TOS_MODULE AM;ACCEPTS{ char AM_SEND_MSG(char addr, char type,

char* data); void AM_POWER(char mode); char 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 AM_SUB_TX_PACKET(char* data); void AM_SUB_POWER(char mode); char AM_SUB_INIT();};

Slide courtesy Jason Hill et al

Putting It All Together

The task scheduler is a simple FIFO scheduler.

The scheduler puts the processor to sleep when the task queue is empty.

Peripherals keep operating and can wake up the processor.

Communication across components takes the form of a function call. This results in low overhead, and allows compile time type checking.

Sample Application

The authors built an application consisting of a number of sensors distributed within a localized area

Monitor temperature and light conditions Periodically transmit measurements to a base

station

Sample Application (cont)

Sensors can forward data for other sensors that are out of range of the base station

Dynamically determine the correct routing topology for the network

Image courtesy Jason Hill et al

Internal Component Graph

Slide courtesy Jason Hill et al

RFM

Radio byte

Radio Packet

UART

Serial Packet

I2C

Temp

Photo

Active Messages

Clocksbit

byte

packet

Ad hoc Routing Applicationapplication

HW

SW

Ad hoc Routing

0Base

1

1

2

2

3

Base station periodically broadcasts route updates Any sensors in range of this broadcast record the

identity of the base station, and rebroadcast the update

Each sensor remembers the first update received in an era, and uses the source of the update as the destination for routing data back to the base station

Image courtesy Jason Hill et al

Evaluation: Small Physical Size

Component Name Code Size (bytes)

Data Size (bytes)

Multihop router

AM_dispatch

AM_temperature

AM_light

AM

Packet

RADIO_byte

RFM

Photo

Temperature

UART

UART_packet

I2C_bus

88

40

78

146

356

334

810

310

84

64

196

314

198

0

0

32

8

40

40

8

1

1

1

1

40

8

Processor_init

TinyOS scheduler

C runtime

172

178

82

30

16

0

Total 3450 226

Scheduler only occupies 178 bytes

Complete application only requires 3 KB of instruction memory and 226 bytes of data (less than 50% of the 512 bytes available)

Only processor_init, TinyOS scheduler, and C runtime are required

Evaluation: Concurrency Intensive Operations

Operations Cost (cycles)

Time (µs)

Normalized to byte copy

Byte copy 8 2 1

Post an Event

Call a Command

Post a task to scheduler

Context switch overhead

10

10

46

51

2.5

2.5

11.5

12.75

1.25

1.25

6

6

Interrupt (hardware cost) 9 2.25 1

Interrupt (software cost) 71 17.75 9

Low overhead is essential for achieving modular efficiency

Cost of posting an event = cost of copying 1 byte of data

Cost of posting a task or context switching is the same as copying 6 bytes of data

Interrupt handling requires saving and storing registers

Efficient Modularity

Message Send Transition Total propagation delay up the 5 layer radio

communication stack is about 80 instructions

Timing diagram of event propagationSlide courtesy Jason Hill et al

Evaluation: Limited Hardware Parallelism and Controller Hierarchy

Successfully demonstrated a system with multiple flows of data running through a single microcontroller

ComponentsPacket reception work breakdown CPU Utilization Energy (nj/Bit)

AM 0.05% 0.20% 0.33

Packet 1.12% 0.51% 7.58

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

Idle - 54.75% -

Total 100.00% 100.00% 2028.66

Slide courtesy Jason Hill et al

Evaluation: Diversity in Usage and Robust Operation

Created several sample applications that exploit the modular structure of the systemSource based multi-hop routing applicationsActive-badge-like location detection applicationsSensor network monitoring applications

C programming language allows the ability to target multiple CPU architectures in future systems

Robustness: Multihop routing application automatically reconfigures itself to withstand individual node failures

Slide courtesy Jason Hill et al

Conclusions

TinyOS is a highly modular software environment tailored to the requirements of Network Sensors, stressing efficiency, modularity, and concurrency.

TinyOS should be able to support new sensor devices as they evolve.

Running an application on TinyOS can help reveal the impact of architectural changes in the underlying hardware, making it easier to design hardware that is optimized for a particular application.