1 / 22

Impala: A Middleware System for Managing Autonomic, Parallel Sensor Systems

Impala: A Middleware System for Managing Autonomic, Parallel Sensor Systems. Ting Liu and Margaret Martonosi Princeton University. Sensor Networks: An Emerging Style of Parallel Computing. Comprised of many distributed sensor nodes Long-running distributed environments Data aggregation

Download Presentation

Impala: A Middleware System for Managing Autonomic, Parallel Sensor Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Impala:A Middleware System for Managing Autonomic, Parallel Sensor Systems Ting Liu and Margaret Martonosi Princeton University

  2. Sensor Networks: An Emerging Style of Parallel Computing • Comprised of many distributed sensor nodes • Long-running distributed environments • Data aggregation • Distributed queries Base Station data query data data query Sensor Need for loosely-coordinated parallelism on low-capability nodes

  3. CPU, Memory, Wireless Transceiver GPS Data Peer-to-Peer communication Protocol Data Base Station (car or plane) Data ZebraNet Wireless Sensor Network Current applications = protocols Future applications more complex

  4. Long-Term Sensor Deployment: Needs Effective Middleware • Adaptive application software • To handle parameters • To handle device failures • Automatic software updates • Software updates inevitable • Manual updates impractical Applications Adapt Update Impala Device Software • Middleware adapts and updates apps, protocols dynamically • New protocols can be plugged in at any time • Switches between protocols can be performed at will Device Hardware External Updates

  5. Roadmap • Middleware Architecture Overview: Modularity • Application Adapter: Adaptivity • Application Updater: Repairability • Evaluation • Conclusions

  6. D A B D Motivation: Middleware Support for Application/Protocol Modularity Individual Protocols A A B C D B B Aggregate Protocol C Impala Layer Layered Approach Monolithic Approach • Modularity: applications independent, specialized • Correctness: individual apps vs. super-application • Ease of Updates: local changes vs. global changes • Energy Efficiency: transmit smaller program modules

  7. System Architecture and Programming Model Application A Application B Application C Application D Initialize Query Packet Data Terminate Send Done Timer Application Updater Application Adapter Event Filter Device Event Packet Event Data Event Send Done Event Timer Event

  8. Timeline Example of Event-based Application Programming Model Node A: Data Sender Node B: Data Receiver Time Application Impala Impala Application Timer Event Timer Event Send a peer discovery message Send a peer discovery message Packet Event Packet Event Receive B’s peer discovery message Receive A’s peer discovery message Send Done Event Send Done Event Be notified previous message is sent Be notified previous message is sent Timer Event Timer Event Send a data packet to B No data packet should send Packet Event Receive A’s data packet Send Done Event Be notified previous packet is sent Send another data packet to B Packet Event Receive A’s data packet Send Done Event Be notified previous packet is sent Timer Event Timer Event Check status Check status/switch Application query Application query Application terminate Application initialize Timer Event Timer Event Send a peer discovery message Send a peer discovery message

  9. Timer Event: Send a peer discovery message Timer Event: Send a peer discovery message Packet Event: Receive B’s peer discovery message Send Done Event: Be notified previous message is sent Timer Event: Check status and switch Timer Event: Send a data packet to B Timer Event: Send a peer discovery message Timer Event: Check status but no switch Timer Event: Send a peer discovery message Send Done Event: Be notified previous message is sent Timer Event: No data packet should send Packet Event: Receive A’s peer discovery message Node A: Data Sender Node B: Data Receiver Time Application Impala Impala Application Timer Event Timer Event Send a peer discovery message Send a peer discovery message Packet Event Packet Event Receive B’s peer discovery message Receive A’s peer discovery message Send Done Event Send Done Event Be notified previous message is sent Be notified previous message is sent Timer Event Timer Event Send a data packet to B No data packet should send Packet Event Receive A’s data packet Send Done Event Be notified previous packet is sent Send another data packet to B Packet Event Receive A’s data packet Send Done Event Be notified previous packet is sent Timer Event Timer Event Check status Check status/switch Application query Application query Application terminate Application initialize Timer Event Timer Event Send a peer discovery message Send a peer discovery message

  10. Impala: Adaptivity • Adaptation scenarios • Adapt to sensitive changes in parameter values • Adapt to device failures • Adaptation mechanisms • Parameter tracking • Device failure detection • Event-based adaptation • Timer event triggers parameter query • Device event triggers failure check • Both can eventually cause application switch App A App B Terminate Initiate Adapter

  11. ZebraNet Characteristics Design Implications • High Node Mobility • Constrained Bandwidth • Wide Range of Updates • Incomplete Updates • Updates vs. Execution • Out of order Updates Impala: Repairability A C D B Node Update Updater On a single sensor node Full network

  12. Software Modules • Each application is divided into several modules • Module version number vs. app version number • Allows selective software transmission Application A: Version 1 Application A: Version 2 Module 1: Version 1 Module 2: Version 1 Module 1: Version 1 Module 2: Version 1 Upgrade Module 3: Version 1 Module 4: Version 1 Module 3: Version 2 Module 4: Version 1 Module 5: Version 1 Module 6: Version 1 Module 5: Version 1 Module 6: Version 2

  13. Stage 2 I want Module 5 from Version 3.0 Node A Node B Complete Version: 3.0 Incomplete Version: Complete Version: 1.0 Incomplete Version: 2.0 and 3.0 Stage 3 Module 5 from Version 3.0 Node A Node B Complete Version: 3.0 Incomplete Version: Complete Version: 3.0 Incomplete Version: On-demand Software Transmission for Remote Software Update Stage 1 I have Version 3.0 Node A Node B Complete Version: 3.0 Incomplete Version: Complete Version: 1.0 Incomplete Version: 2.0 I have Version 1.0 Repeat as needed … Repeat interval backs off if frequent updates not needed

  14. Roadmap • Middleware Architecture Overview: Modularity • Application Adapter: Adaptivity • Application Updater: Repairability • Evaluation • Conclusions

  15. Impala Prototype Implementation • Prototyped on HP/Compaq iPAQ Pocket PC Handhelds • System configuration • 206MHz CPU, 32MB flash RAM, 16MB flash ROM • Linux Familiar 5.3 and Xipaq GUI • Implementation includes • Impala layer: Adapter, Updater, Event Filter • Application layer: two application protocols

  16. Prototype Implementation: Application Protocols • Flooding: Send to all neighbors found • History-based: Send only to neighbor with best “score” at delivering data to base

  17. Event Processing Time Measurements • Impala events require less time than app events except for receiving a code packet Application Events Adaptation Event Update Events Send data pkt Send peer msg Send code pkt Send software req Receive code pkt App query&switch Install update Send software info

  18. Efficient Network Reprogramming • Probabilistic broadcasting broadcasts to all neighbors with a probability • Impala’s on-demand transmission retains infection rate of high-probability broadcast

  19. Efficient Network Reprogramming • Probabilistic broadcast continues to send useless updates • On-demand transmission caps transmissions to number of nodes

  20. Adaptation Example: Improving Routing Performance • Impala adaptation achieves equal/better data homing success rate at any given radio range

  21. Adaptation Example: Improving Routing Performance • Adaptation switches are infrequent even in intermediate ranges where adaptation has highest payoff

  22. Conclusions • Impala: A middleware architecture for application …… • Modularity • Adaptivity • Repairability • Prototype implementation and simulations demonstrate: • Low overhead • Efficient network reprogramming • System Improvements

More Related