180 likes | 192 Views
This paper discusses the implementation of software on resource-constrained mobile sensors, focusing on Impala and ZebraNet technologies. It covers system layering, middleware weight, application modularity, and hardware design rationales. Various challenges and solutions in hardware constraints, operation scheduling, event handling, communication needs, and limited resources are explored in detail. The study emphasizes the importance of software adaptivity, simplicity, and repairability in the context of sensor network performance and deployment. The paper also presents a roadmap for hardware design and constraints, along with solutions to complex hardware realities and miscellaneous system activities. It addresses issues like memory footprint, irregular events handling, event prioritization, communication models, and unified MAC and transport control. Overall, this research provides insights into effectively implementing software on mobile sensors with limited resources.
E N D
Implementing Software on Resource-Constrained Mobile Sensors: Experience with Impala and ZebraNet Ting Liu Christopher M. Sadler Pei Zhang Margaret Martonosi Depts. Of Electrical Engineering and Computer Science Princeton University
ZebraNet: Fusing Mobile Computing and Sensor Systems Tracking node with CPU, FLASH, radio and GPS Data Store-and-forward communications Data Base station (car or plane) Data Data
Applications Impala Hardware Middle ground Software Design Rationales Question One: System Layering Single Software System Layer 6 Layer 5 Layer 4 Layer 3 Layer 2 Layer 1 Monolithic approach: Layered approach: Software modularity Layering overhead
Applications Impala Hardware Middle ground Software Design Rationales Question Two: Middleware Weight Applications Applications Super-middleware Mini-Middleware Hardware Hardware Limited services: Overloaded services: application simplicity Middleware overhead
Impala Overview Application modularity, simplicity, adaptivity and repairability Adapter Updater Operation Scheduler Event Filter Network Support • Software adaptation for sensor network performance • Software update for sensor network deployment • Operation scheduling for regular operations • Event handling for irregular events • Network support for sensor network communications
This Paper Application modularity, simplicity, adaptivity and repairability Adapter Updater Operation Scheduler Event Filter Network Support PPoPP 2003: This Paper: Operation, event, network Adaptation and update Implemented on ZebraNet node Prototyped on iPAQs
Roadmap • Hardware design and constraints • Problem 1: Complex hardware realities Solution: Layers and interfaces • Problem 2: Miscellaneous system activities Solution: Operation scheduling and event handling • Problem 3: Special communication needs Solution: Messages models • Problem 4: Limited communication resources Solution: Networking strategies • Conclusions
Microcontroller TI MSP430F149 16-bit RISC 2KB RAM 60KB ROM 8MHz/32KHz dual clock FLASH ATMEL AT45DB041B 4Mbit 78 days data capacity SPI 667Kbps USART 38.4Kbps Radio MaxStream 9Xstream 902-928MHz 19.2Kbps over-the-air 0.5-1mile transmit range GPS µ-blox GPS-MS1E 10-20s position fix time USART 38.4Kbps 5V 3.3V Power supplies Charging circuits Solar modules Hardware Design and Constraints Power Measurement (4.0V applied) • Memory constraint • Energy constraint • Device access constraint • Radio packet size constraint • GPS sensing time constraint • FLASH storage constraint
Application 1 Application 2 Application 3 Application 4 Asynchronous Network Transmission GPS Data Event Handler Application Timer Event Handler Protected FLASH Access Network Packet Event Handler Application Timer Control Network Send Done Event Handler System Clock Time Read Adapter Updater Operation Scheduler Event Filter Network Support GPS Data Event Access and Control to All Devices Radio Packet Event Timer Event CPU Radio GPS FLASH Timer WDT Problem 1: Complex Hardware Realities Solution: Layers and Interfaces
Problem 2: Misc System Activities Solution: Regular Operation Scheduling • GPS-aided operation synchronization • Prohibited simultaneous device operations • Non-trivial radio wake-up time • Potentially long GPS sensing time • Stringent energy budget 1 2 7 8 4 5 3 6 Networking Period Sleep Period GPS Sensing Period 1 5 CPU wake up/Radio, FLASH power on GPS power on 2 6 Radio transmitting / receiving start GPS sensing time 3 7 Network communication time GPS power off / FLASH power on 4 8 Radio power off/FLASH power off CPU sleep / FLASH power off
Problem 2: Misc System Activities Solution (cont.): Handling Irregular Events Issue One: Event Abstraction Issue Two: Concurrency Abstract Application Events Short / atomic hardware interrupts Impala Idle Long / preemptive software events Miscellaneous Hardware Interrupts Issue Three: Event Prioritization High Priority Events Event Handler Event Signaler Low Priority Events
Problem 3: Special Communication Needs Solution: Message Models and Sessions • Peer discovery or data • 1 to 32KB • One, more or unlimited destinations • Data from FLASH or RAM • Acknowledgment or not • Connectionless • Asynchronous Sensor data ACK Reliable Unicast Sensor Sensor data data ACK Unreliable Broadcast Reliable Multicast
Problem 4: Limited Comm Resources Solution: Unified MAC &Transport Control • MAC: round-robin timeslots (w/ GPS-aided time synchronization) • Transport control: detect packet loss and retransmit • Unified: reduce data copy and overhead across protocol layers B acks packet 1-8 C acks packet 1-4 D silent B acks packet 9-16 C acks packet 1-4 D acks packet 9-16 B acks packet 1-8 C acks packet 1-4 D acks packet 1-8 A B C D A B C D A B C D A gives up C and sends packet 9-16 A sends packet 1-8 to B, C, and D A sends packet 1-8
ZebraNet Status and Next Steps • Status • January, 2004: 7 test collars deployed on zebras in Kenya. First data received: 1/19/2004 • Next Steps • Refine collar design; switch to lower-energy GPS, merge Impala software update code into final collars
Conclusions • Propose and implement Impala middleware model • Solutions for hardware constraints and app req • Concrete experience with real system and application Applications Simple layering and rich services Impala Hardware