System Architecture Directions for Networked Systems Based on paper - - PowerPoint PPT Presentation

System Architecture Directions for Networked Systems

Based on paper written by Jason Hill, Robert Szewczyk, Seth Collar, David Culler, Kristofer Pister UC Berkeley

Outline

Introduction Networked sensor characteristics Example design point TinyOS design Evaluation, related work & implications

Introduction

• Trends in sensor design
• Smaller, cheaper & fully functional
• Smart dust – integrated into physical

environment

• System software to manage and operate the

device is missing

• Authors have developped TinyOS to

address this problem

Sensor characteristics

• Small physical size and low power

consumption

• Size and power constrain the processing,

storage and interconnect capability of the device

• Software must make efficent use of

processor and memory while enabling low power consumption

Sensor characteristics

• Concurrency-intensive operations
• The primary mode of operation is to flow

information from place to place with a modest amount of processing on-the-fly

• Information may be captured from sensors,

manipulated and streamed onto the network

• Data may by received and forwarded in a

multi-hop routing

Sensor characteristics

• Limited physical parallelism and controller

hierarchy

• Number of independent controllers, their

capabilities are much lower than in conventional systems

• Sensor provides a primitive interface to a

single-chip microcontroller

Sensor characteristics

• Diversity in design and usage
• Networked sensors are application specific

and carry only the hardware support which is actually needed

• It is important to easily assemble the

required software components – unusual level of modularity

• Applications should be constructed from

components without heavyweight interfaces

Sensor characteristics

• Robust operations
• Devices are numerous and largely

unattended – should be operational large percentage of time

• Redundancy vs Efficiency
• Enhancing the reliability of individual

devices is essential

Example design point

• Microcontroller
• Internal flash program memory
• Data SRAM
• Sensors including LEDs, radio transceiver,

photo and temperature sensors

Example design point

Example design point

• MCU is an 8-bit architecture (32 registers, 4

MHz)

• 8 KB program memory
• 512 bytes of SRAM data memory
• Using the coprocessor
• Three sleep modes
• Idle – shuts off the processor
• Power down – shuts everything
• Power save – async timer is still running

Example design point - sensors

• LEDs represent output through general I/O
• Photo sensor – analog input device
• Radio – async input/output device with hard

realtime constraints

• Temperature sensor – analog sensor through

I2C

• Serial port
• etc

Power characteristics

TinyOS design

• Two-level scheduling
• Hardware events can be performed

immediately while long running tasks are interrupted

• System based on the event model
• Small amount of space needed
• Effective usage of CPU resources
• System consists of a tiny scheduler and a

graph of components

TinyOS design - component

• Command handlers
• Event handlers
• Encapsulated fixed-size frame
• Bundle of tasks

TinyOS design - frame

• Fixed size frames are statistically allocated
• Prevents overhead associated with dynamic

allocation

• Execution time savings regarding accessing

the variables

TinyOS design - commands

• Non-blocking requests made to lower level

components

• Will deposit request parameters into the frame

and post a task for later execution

• May invoke lower level commands but must

not wait for long actions to finish

• Must provide feedback by returning status

TinyOS design - events

• Are invoked to deal with hardware directly or

not

• Can deposit information into the frame, post

tasks, signal higher level events or call lower level commands

• Commands and events are intended to

perform a small amount of work

TinyOS design - tasks

• Perform primary work
• Atomic with respect to other tasks (single

allocated stack is needed), though can be preempted by events

• Can call lower level commands, signal higher

level events or schedule other tasks

• Must never block or spin wait – this would

prevent progress in other components

TinyOS design - scheduler

• Simple FIFO scheduler
• Power aware
• Whenever the task queue is empty it puts

the processor to sleep

• Another task can be scheduled only as a

result of hardware event

Example component

Component types

• Hardware abstraction components
• RFM radio
• Synthetic hardware components
• Radio byte
• High-level software components
• Messaging module

Putting it all together

Putting it all together

• How to determine topology?
• Base station periodically broadcasts out the

route updates

• Each sensor within range rebroadcasts it

and remembers the first update in the era

• When routing, the address of this sensor is

used as a next hop

Putting it all together

• There are three events each device must

respond to

• The arrival of the route update
• The arrival of the message that needs to be

forwarded

• Collection of the new data (which is to be

forwarded into the net)

Evaluation – code & data size

Evaluation – operations

• verhead

Data flow

Related work

• Current real-time embedded operating

systems are not suitable for sensor systems

• Execution model similar to desktop systems

(only smaller)

• Memory footprint is too big
• It takes to long to switch between contexts

Architecture implications

• Individual microcontroller for each sensor is

not a requirement anymore

• For higher speed radio components bit level

processing cannot be used – RadioByte will become hardware abstraction

• Hardware support for events (like more

registers) would make the CPU load smaller and would lead to higher performance or lower power comsumption