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 overhead

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