international graduate school cottbus / ihp microelectronics im technologiepark 25 15236 frankfurt...

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

Germany

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

<SENSOR-DATA> … </SENSOR-DATA>

</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>

</temperature>

<smoke>

</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

</DISTANCE></CONDITION><NUMBER OF DEVICES>

</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:

</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>

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?

international graduate school cottbus / ihp microelectronics im technologiepark 25 15236 frankfurt...

motivation slide

steffen slide

failures low cost devices

tmote sky sensor node

main challenge

integrated humidity

deep space applications

moteiv main features

Documents

ihp im technologiepark 25 15236 frankfurt (oder) germany ihp...

catalog produse ihp

iso 15236-2

ihp lec2 anderson

ihp im technologiepark 25 15236 frankfurt (oder) germany ihp...

ihp april 2014

2010 ihp annual report

ihp fall mag

meeting of ihp regional steering committee for southeast...

ihp seasons greetings

international hydrological programme (ihp) hydrological...

ihp december 2014

cadence intro ihp

living in whitehall borough, pa 15236

ihp general packet 7.29.16 (word document) - alsde.edu...

ihp news 485 : tedros’ annual letter introducing a new ihp...

ihp feature meditation

iso 15236-1

ihp stress voice

ihp september 2015