1 / 23

Fault Tolerant Event Specification in Heterogeneous Sensor Networks

Fault Tolerant Event Specification in Heterogeneous Sensor Networks. Ortmann, Steffen. Outline. Introduction & Motivation Related work Shortcomings and open issues Fault tolerant event specification Conclusion. Motivation. Introduction.

jadon
Download Presentation

Fault Tolerant Event Specification in Heterogeneous Sensor Networks

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. Fault Tolerant Event Specification in Heterogeneous Sensor Networks Ortmann, Steffen

  2. Outline • Introduction & Motivation • Related work • Shortcomings and open issues • Fault tolerant event specification • Conclusion

  3. Motivation

  4. Introduction • Ubiquitous systems are ambient intelligent environments build by cooperating autonomous devices • Computing devices are to be embedded on everyday object • Watching and serving us at any place and any time • Supposed to substitute today’s computers and information technology • Reliable and fault tolerant ubiquitous systems are potentially capable of executing mission- and safety-critical applications • Healthcare- and structural monitoring • Homeland security • Embedded systems • Avionic and deep space applications

  5. Sensor networks • Sensor networks are one of the first real world examples of ubiquitous systems • Tiny autonomous devices that are assembled to fulfill common tasks • Structure:  Main challenge: Devices and systems are prone to failures • Low cost devices, rare resources, strict energy constraints

  6. Tmote Sky sensor node from Moteiv • Main Features: • 250kbps 2.4GHz IEEE 802.15.4 Wireless Transceiver • 8MHz Texas Instruments MSP430 microcontroller • 10k RAM, 48k Flash • Integrated ADC, DAC, Supply Voltage Supervisor, DMA Controller • Onboard antenna with 50m range indoors / 125m range outdoors • Integrated Humidity, Temperature, and Light sensors • Programming and data collection via USB • Ultra low current consumption • Fast wakeup from sleep (<6μs)

  7. Related Work • Most reliability enhancing approaches for sensor networks focus on data gathering and data transmission • Events are predefined states based on certain measurements • Usually defined by threshold values • Exploit the effect of redundancy on mean time to failure • Strongly depends on the density in the network • Main approach: collective distributed data evaluation by voting • Neighbored nodes compare their results to decide about events  Many different voting algorithms are presented so far

  8. Distributed event evaluation

  9. Voting • Based on redundant devices in certain areas of the network • Cluster, position-based, n-hop neighborhood etc. • Majority Voting [1] • All nodes within the region of event possess the same weights • Fusion center analyzes and combines all values • Distance Weighted Voting [2] • Voting weight decreases with distance to the center of the event • Confidence Weighted Voting [2] • Grants higher weights to sensors that are more likely to be correct • Every nodes assigns a confidence value • Best implemented in the TIBFIT [3] protocol

  10. Shortcomings and open issues • Voting is sufficient enough to provide an enhanced reliability • Currently done on predefined event regions • Not adaptable to different tasks and network conditions • Consider heterogeneous sensing capabilities • Almost all sensor network applications are handmade and customized • Take care on energy dissemination • Varying tasks demand different overhead for fault tolerance • Exploit reactive algorithms that vote on demand only! • Vision: adaptable multi-tasking sensor networks • Miscellaneous fine-grained multi-event detection

  11. Event Specification Language for Sensor Networks • Idea: Enable complete events specifications by an uniform description language • Get rid of custom-built sensor networks! • Combine heterogeneous sensing capabilities • Enable more precise and complex event detection capabilities • Fine-grained configuration of fault tolerant event evaluation • Configure voting conditions explicitly for any single event • Specify execution intervals and associate appropriate event handlers  Online configuration of sensor networks without physical access to every node!

  12. <EVENT> element • Structure of an events specification <EVENT id=“fire.001" priority="high"> <SENSOR-DATA> … </SENSOR-DATA> <VOTING> … </VOTING> <EXECUTION> … </EXECUTION> <CONSEQUENCE> … </CONSEQUENCE> </EVENT>

  13. <SENSOR-DATA> element • List sensing capabilities • e.g. <temperature>, <smoke>, <humidity> etc. • Configure corresponding threshold values • Exact threshold values as <equal> element • Scopes of threshold values by <atleast> or <atmost> • Correlate threshold values by logic operations • <AND/>, <OR/>, <NOR/>, <NAND/> etc.  <SENSOR-DATA> element is analyzed to a Boolean value during evaluation of sensor readings

  14. <SENSOR-DATA> example <SENSOR-DATA> <AND> <temperature> <atleast> 353 </atleast> <kelvin/> </temperature> <smoke> <atleast> 1.1 </atleast> <percent/> </smoke> </AND> </SENSOR-DATA>

  15. <VOTING> element (1) • Customizes preconditions for distributed event evaluation • Precisely configures conditions for voting • Determines which other devices are allowed to vote • Defines the legal size of the event evaluation region •  All nodes within this area are allowed to vote • <DISTANCE> element defines a radius around initiating sensor node • Using quantifying elements like <atmost> • Other preconditions are to be considered too • e.g. all nodes within 1-hop neighbourhood

  16. <VOTING> element (2) • Number of necessary voting devices can be fixed or limited • Stated by <NUMBER_OF_DEVICES> element • Enables n-modular redundancy • Specification of further abort criteria (called Exceptions) • Listed by the <EXCEPTION> element • Deadline criteria •  Keeps timing constraints for safety-critical applications! • Other criteria imaginable • <no_devices_available> • All listed criteria can be concatenated by logic operations

  17. <VOTING> example <VOTING> <CONDITION> <DISTANCE> <atmost> 5 </atmost><meters/> </DISTANCE> </CONDITION> <NUMBER OF DEVICES> <atleast> 3 </atleast> <NUMBER OF DEVICES> <EXCEPTION> <OR> <DEADLINE> <equal> 3 </equal><seconds/> </DEADLINE> <no_devices_available> </OR> </EXCEPTION> </VOTING>

  18. <EXECUTION> element • Configuration of demand-oriented execution intervals • Precisely adaptation to varying requirements • Implicitly considers energy consumption of the sensor node • Manages active and sleep periods of the sensor node • Can be quantified by acceptable time periods or exact time slots • Example: <EXECUTION> <INTERVAL> <equal> 60 </equal> <seconds/> </INTERVAL> </EXECUTION>

  19. <CONSEQUENCE> element • Connects procedures to an event • Procedures are called event handlers • <CONSEQUENCE> element holds a list of event handlers • Every event handler links a certain procedure • Attribute id holds the respective identifier  All listed handlers are successively executed if an event occurs • Example: <CONSEQUENCE> <TRIGGER HANDLER id="send-fire-alert"> </CONSEQUENCE>

  20. Conclusion • Reliable and fault tolerant sensor networks are in great demand • Enable mission- and safety-critical applications • Current approaches and solutions revealed several shortcomings • Idea: Define events by an uniform event specification language • Regards heterogeneous sensing capabilities • Allows for fine-grained event-related fault tolerance • Provides miscellaneous task execution  Improves maintenance capabilities and enables online configuration of sensor networks

  21. Outlook • Finish definition of event specification language • Implement pre-parser for event specifications • Parses specification into tree that can be send through the network • Implement interpreter for the sensor node side • Using network (OMNet++) and algorithm simulator (Castalia) • Comprehensive test procedures on simulator • Different network density • Different event specification containing varying voting conditions • Measure and compare energy consumption

  22. References [1] B. Krishnamachari and S. S. Iyengar. Efficient and fault-tolerant feature extraction in sensor networks. In 2nd Workshop on Information Processing in Sensor Networks, IPSN’03, Palo Alto, California, April 2003 [2] T. Sun, L.-J. Chen, C.-C. Han, and M. Gerla. Reliable sensor networks for planet exploration. In L.-J. Chen, editor, Proc. IEEE Networking, Sensing and Control, pages 816–821, Tucson, USA, 2005 [3] M. Krasniewski, P. Varadharajan, B. Rabeler, S. Bagchi, and Y. Hu. Tibfit: trust index based fault tolerance for arbitrary data faults in sensor networks. In Proc. International Conference on Dependable Systems and Networks DSN 2005, pages 672–681, 2005

  23. Discussion Thanks for your attention. Any questions?

More Related