International Graduate School Cottbus / IHP microelectronics Im Technologiepark 25 15236 Frankfurt (Oder) Germany IHP Im Technologiepark 25 15236 Frankfurt

International Graduate School Cottbus / IHP microelectronicsIm Technologiepark 2515236 Frankfurt (Oder)

Germany

IHP Im Technologiepark 25 15236 Frankfurt (Oder) Germany www.ihp-microelectronics.com © 2008 - All rights reserved

Fault Tolerant Event Specification in Heterogeneous Sensor Networks

Ortmann, Steffen


2/23Outline

• Introduction & Motivation

• Related work

• Shortcomings and open issues

• Fault tolerant event specification

• Conclusion


3/23Motivation


4/23Introduction

• Ubiquitous systems are ambient intelligent environments build by cooperating autonomous devices

• Computing devices are to be embedded on everyday objectWatching 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 monitoringHomeland securityEmbedded systemsAvionic and deep space applications


5/23Sensor 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/23Tmote 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/23Related 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/23Distributed event evaluation


9/23Voting

• 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/23Shortcomings 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/23Event 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/23<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/23<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/23<SENSOR-DATA> example

<SENSOR-DATA>

<AND>

<temperature>

<atleast> 353 </atleast>

<kelvin/>

</temperature>

<smoke>

<atleast> 1.1 </atleast>

<percent/>

</smoke>

</AND>

</SENSOR-DATA>


15/23<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/23<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/23<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/23<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/23<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/23Conclusion

• 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/23Outlook

• 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/23References

[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/23Discussion

Thanks for your attention.

Any questions?

Documents

International Graduate School Cottbus / IHP microelectronics Im Technologiepark 25 15236 Frankfurt (Oder) Germany IHP Im Technologiepark 25 15236 Frankfurt