1 EE249 Discussion System Architecture Directions for Networked Sensors (J. Hill, et al) Presented By: Sarah Bergbreiter EE249 Discussion Section October 15, 2002

2 EE249 Discussion What are Networked Sensors? Cheap, plentiful, low-power, small, communication-enabled (radio, optical, etc) Mica Mote Smart Dust1mm

3 EE249 Discussion Networked Sensor Characteristics Small physical size and low power consumption Concurrency Intensive Operation –sensing data, forwarding packets, etc. Limited Physical Parallelism and Controller Hierarchy –can’t have one processor per sensor Diversity in Design and Usage –modular components allow for application specific design Robust Operation –numerous and unattended

4 EE249 Discussion Sample Hardware Design Radio - 1  J/bit - real time constraints Coprocessor - reprogramming Atmel AVR - power save modes - memory constrained Sensors

5 EE249 Discussion TinyOS Overview Small size and power limitations decided by the hardware platform Two-Level Scheduling –long running tasks (processing data) –hardware events (radio, sensors, etc.) Event-Driven Design –better concurrency –power savings Modular Component-Based Design

6 EE249 Discussion TinyOS Design – Components Commands Events Frame –static, fixed Tasks –simulate concurrency Type depends on hardware connection INIT POWER SEND_MSG INIT POWER TX_PACKET MSG_REC MSG_SEND _DONE RX_PACKET _DONE TX_PACKET _DONE MESSAGING COMPONENT INTERNAL STATE (FRAME) SEND_MSG THREAD

7 EE249 Discussion Ad hoc Routing Application

8 EE249 Discussion How Does TinyOS Perform? Small Physical Size –scheduler uses 178 bytes program memory, 16 bytes data memory –application ~3k program memory, 226 bytes data memory Concurrency-intensive Operations –context switching relatively cheap (equivalent to writing 6 bytes in memory) –interrupt handling more expensive in software

9 EE249 Discussion How Does TinyOS Perform? Efficient Modularity –using function calls to propagate events and commands keeps costs low 40  s 90  s

10 EE249 Discussion How Does TinyOS Perform? Limited Physical Parallelism and Controller Hierarchy –make design choices about parallelism based on data Diversity in Usage and Robust Operation –reconfigurable for node failure

11 EE249 Discussion Related Work Other Operating Systems –These operating systems address embedded PCs –Control v. dataflow (context switching difficult) FSM Description Language New Hardware Platforms and Applications

12 EE249 Discussion Architectural Implications Physical parallelism is optional Deciding where to draw the hardware/software boundary line may improve performance and/or power usage Quantified effect of additional hardware support (early benchmarks)

13 EE249 Discussion Conclusions/Questions Sample hardware/software architecture presented for networked sensors Bigger is no longer better Platform-based design? Complexity limits?