1 / 21

Lazy Preemption to Enable Path-Based Analysis of Interrupt-Driven Code

This paper discusses the challenges of ensuring reliability in Wireless Sensor Networks (WSNs), particularly in the context of interrupt-driven code. Traditional software reliability techniques are often inadequate due to the unique challenges presented by WSNs, such as unpredictable environments and resource constraints. We introduce lazy preemption models that allow for more effective static analysis by scheduling interrupt handling based on execution timing and function completion. Our approach aims to enhance fault detection and reporting through path-based analysis, ultimately improving reliability in critical applications like volcano monitoring.

lazar
Télécharger la présentation

Lazy Preemption to Enable Path-Based Analysis of Interrupt-Driven Code

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. Lazy Preemption to Enable Path-Based Analysis of Interrupt-Driven Code Wei Le, Jing Yang, Mary Lou Soffa, and Kamin Whitehouse Department of Computer Science University of Virginia SESENA’11 May 22, Waikiki, Honolulu, Hawaii

  2. WSN Reliability is Important $25 million for a 100,000 node volcano monitoring network Large money loss if it mistakenly reports a non-existing eruption Severe vulnerability and human casualty if it fails to report a real eruption However, traditional techniques and tools for software reliability are handicapped in the WSN domain !

  3. Testing and Debugging? • Limited by the large range of possible input sequences • Real deployment environments are difficult to emulate • Resource constraints limit the use of runtime techniques • Continuous debugging and reprogramming is hard due to remote node deployments Simulation Deployment Real environments Scale EmStar ICE Realism Controlled environments

  4. A Complementary: Static Analysis • Interrupt-driven code • Exponential growth of the state space • Path selection: sacrificing coverage • Path merging: sacrificing precision • Our contribution • Insight: physical world changes much slower than software execution • Solution: run interrupt handlers when necessary (based on timing) or convenient (end of functions)

  5. A Complementary: Static Analysis Task Interrupt Handler 1, 5, (2|3), 4 1, 2, 5, 4 1, 3, 5, 4 1, (2|3), 4, 5 Total: 6 paths 1 5 1, (2|3), 4, 5 Total: 2 paths 3 2 4

  6. Outline • Background • Lazy preemption models • Path-based fault detector

  7. Execution Model • TinyOS • Tasks, interrupt handlers, and atomic sections • Task • In-order execution from the task queue • Interrupt • Generated by hardware or environments • Can preempt the current execution • Atomic section • Interrupts are disabled

  8. Faults Taxonomy From the most-severe-bug-pool of the TinyOS bug repository

  9. Requirements for A Fault Detector • Both detecting and reporting faults should be based on program paths • The interactions between interrupts and tasks should be modeled • Timing analysis should be performed

  10. Outline • Background • Lazy preemption models • Path-based fault detector

  11. Fully Preemptive Model Task Interrupt Handler 1, 5, (2|3), 4 1, 2, 5, 4 1, 3, 5, 4 1, (2|3), 4, 5 Total: 6 paths 1 5 3 2 4

  12. Size of Atomic Sections

  13. Size of Tasks and Interrupt Handlers

  14. Non Preemptive Model Task Interrupt Handler 1 5 1, (2|3), 4, 5 Total: 2 paths 3 2 4 Only preempt at the end of tasks

  15. Restricted Preemptive Model Task Interrupt Handler 1 5 1, (2|3), 4, 5 Total: 2 paths 1, (2|3), 4, 5 1, 3, 5, 4 Total: 3 paths 3 2 Preempt when necessary 4 Only preempt at the end of tasks

  16. Outline • Background • Lazy preemption models • Path-based fault detector

  17. Framework and Workflow Static Timing Analysis Runtime Enforcement nesC Compiler WSN App in nesC C program CFGs IICFG Execution based on IICFG Demand-Driven Analysis Faults Fix Bugs

  18. Static Timing Analysis to Build IICFG • Input • Source code • Arrival frequency for each interrupt • Required response time for each interrupt • Output • Inter-procedural control flow graph (IICFG) • Preemption points on IICFG

  19. Demand-Driven, Path-Based Fault Detection Task Interrupt Handler Q5 Len(input)<32:Vul Q1 Len(b)<32 b = input strcpy(a, b) 1 5 Q4 4 < 32: Safe Q3 Len(b)<32 b = “test” 2 3 4 Q2 Len(b)<32

  20. Runtime Preemption Enforcement • Record handler • Invoked whenever an interrupt arrives • Records the data at the hardware port • Action handler • Invoked only at preemption points • Switches the context • Executes the original interrupt handler

  21. Conclusion • Static analysis in the WSN domain • Satisfy both coverage and precision • Two lazy preemption models • Demand-driven, path-based • Implementation in progress

More Related