Sn S Lab System Architecture Directions for Networked

Sn. S Lab. System Architecture Directions for Networked Sensors Jason Hill, Robert Szewczyk, Alec Woo, Seth Hollar, David Culler, Kristofer Pister Presented by Byeong-gil, Kim Summer 2004

Outline Introduction o Networked Sensor Characteristics o Hardware Organization o Tiny Microthreading Operating System (Tiny. OS) o Tiny. OS Design o Components o Evaluation o Architectural Implications o Software & System Laboratory

Introduction o One of the interesting design in the post-PC era is networked sensors. o Network sensors are small (~1 sq inch), cheap, low power (~a fraction of a watt) devices with integrated n n o Communication Transducers Building blocks for sensor So. Cs include n n n Microcontrollers, memory DACs, ADCs UARTs, ITCs, counters etc Software & System Laboratory

Introduction (2) o Technological progress has made low power CMOS network sensors viable n n o Spread around like smart dust Interact with environment to detect light, heat, position, movement, chemical presence etc However an overall system architecture and methodology for systematic advance is missing This work is an initial exploration of system architectures for networked sensors Software & System Laboratory

Networked Sensor Characteristics o Small physical size and low power consumption n o Processing, storage, interconnect capability constrained by size and power Concurrency-intensive operation n Information may be simultaneously captured from sensors, manipulated, and streamed onto a network n Limited on-the-fly processing Limited internal storage capacity n Software & System Laboratory

Networked Sensor Characteristics o Limited Physical Parallelism and Controller Hierarchy n n n The number of controllers, capabilities of the controllers and the sophistication of the processormemory-switch level interconnect are much lower than in conventional systems. The sensor provides a primitive interface directly to a single-chip microcontroller. In contrast, conventional systems distribute the concurrent processing over multiple levels of controllers. Software & System Laboratory

Networked Sensor Characteristics o Diversity in Design and Usage n n o Application specific rather than general purpose Require extensive s/w modularity for quick assembly of s/w components to synthesize app from h/w components Robust Operation n n Traditional redundancy techniques limited by space and power OS must ensure reliable (distributed) operation Software & System Laboratory

Example Design Point o To ground their system design study, authors developed a small, flexible networked sensor platform n n n n n Microcontroller + flash program memory Data SDRAM, EEPROM Actuator and sensor devices LEDs Low power radio transceiver Analog photo-sensor Digital temperature sensor Serial port Small coprocessor unit Software & System Laboratory

Hardware Organization o o o The processor within the MCU. It is an 8 -bit Harvard architecture with 16 -bit addresses. It provides 32 8 -bit general registers an runs at 4 MHz and 3 V. The system is very memory constrained: it has 8 KB of flash as the program memory and, 512 bytes of SRAM as data memory. Processor cannot write to the instruction memory; uses a coprocessor for the same. Three sleep modes: n Idle, which just shuts off the processor. n Power down, which shuts off everything but the watchdog and asynchronous interrupt logic necessary to wake up. n Power save, which is similar to the one above, but leaves an asynchronous timer running. Software & System Laboratory

Software & System Laboratory

Network Sensor Platform Software & System Laboratory

Power Characteristics ¡ ¡ ¡ At peak load, the system consumes 19. 5 m. A of current, or can run about 30 hours on a single battery. In the idle mode, the system can run for 200 hours. When switched into inactive mode, the system draws only 10 u. A of current, and a single battery can run for over a year. Software & System Laboratory

Tiny Micro-Threading OS (Tiny. OS) o Multithreading engine n n n Building efficient network interfaces Maintain a large number of concurrent flows Juggle numerous outstanding events n o Scalable n n Support smaller, tightly integrated design Support crossover of software components into hardware Software & System Laboratory

Tiny Micro-Threading OS (Tiny. OS) o Event model n n handles high level of concurrency in a small amount of space Multi-task between execution contexts p 40, 000 o switches per second Power aware n Unused CPU cycles are spent in the sleep state Software & System Laboratory

Tiny. OS o Complete system comprises of n n Tiny scheduler Components p p o Command handler Event handler Frame task Layers of components n n n High level components issue commands to low level components Low level components signal events to higher level components Physical h/w lowest level of components Software & System Laboratory

Components o Command handlers n n o Commands are non blocking requests made to lower level components Feedback to its caller by returning status Event handlers n n Invoked to deal with h/w events Connected to hardware interrupt p o external, timer, counter interrupt Encapsulated fixed size frame n n n Fixed size frames are statically allocated Memory requirements of a component at compile time known Prevent the overhead associated with dynamic allocation Software & System Laboratory

Components o Bundle of simple tasks n n n Atomic tasks perform primary work Call lower level commands Signal higher level events Schedule other tasks within a component Simulate concurrency within each component p execute asynchronously with respect to events Software & System Laboratory

Set of Commands Events that is signaled Commands Set of Handlers Software & System Laboratory

Component Types o Hardware abstractions n n o Synthetic hardware n n o Map physical h/w directly into component e. g RFM radio component Simulate behavior of advanced h/w e. g Radio Byte component High level software n n Perform control, routing, data transformations e. g messaging module Software & System Laboratory

Software & System Laboratory

Putting it all together o To illustrate interaction of components, authors describe a networked sensor application they developed n n n Consists of a number of distributed sensors within a localized area Sensors monitor temperature and light conditions, periodically transmitting measurements to a central base station Sensors may forward data for sensors that are out of range of the base station Software & System Laboratory

Routing Topology Software & System Laboratory

Application o Base station periodically broadcasts route updates o Sensors in range record identity of base station and rebroadcast update n o Each sensor remembers source of first update when routing data towards base station later Timer is used to periodically start data collection in a sensor Software & System Laboratory

Evaluation • Small physical size Software & System Laboratory

Evaluation - Concurrency-intensive operations Software & System Laboratory

Evaluation - Efficient Modularity o TX_bit_evt -> TX_byte_ready -> TX_packet_done -> sned_msg o step 0 ~ step 4 => 40 us step 0 ~ step 6 => 95 us o Software & System Laboratory

Evaluation • Diversity in usage − multi hop routing apps − location detection apps − sensor network monitoring apps • Since system was developed in C, multiple CPU architectures can be targeted in the future • Robust Operation − multi hop routing automatically reconfigures itself to withstand individual node failure Software & System Laboratory

Architectural Implications o Demonstrates that it is possible to maintain multiple flows of data with single microcontroller. o The interconnect of such a system will need to support an event based communication model. o Tradeoff arises between power consumption, speed of off chip communication, flexibility and functionality. Software & System Laboratory