BRIMON: Wireless Sensor Network based Railway

Bridge Monitoring

Kameswari ChebroluAssistant Professor

Department of Electrical Engineering

IIT Kanpur

http://home.iitk.ac.in/~chebrolu

People

Kameswari Chebrolu Bhaskaran Raman Nilesh Mishra Hemanth Haridas Phani Kumar Valiveti Raj Kumar

Motivation Indian Railways consists

of 1,20,000 bridges spread over a large geographical area

Many in weak and distressed conditions 57% are over 80 years old

An automated system to track bridge's health is of utmost importance. Short term monitoring Long term monitoring

Existing Techniques

Mostly wired solutions Equipment is bulky and very expensive Large setup time (few days) for short-term

monitoring Few wireless solutions

WISDEN (UCLA) Continuous monitoring

Golden-gate bridge (UCB) Short-term monitoring

Problem Statement

Develop an easy to deploy, low maintenance and long-term structural health monitoring system for Railway bridges

Easy to deploy: Huge number of bridges to monitor Low maintenance: Technical expertise is difficult to get Long-term: Useful to monitor a structure's health over time

Application Requirements

What to measure? Acceleration in 3-axis of motion Frequency components of interest 0.25-20Hz

How long to measure? Forced vibrations: 20sec; Free vibrations: 20sec

Time Synchronization Necessary only across node in a span Need accuracy of 5ms

30-125m 3-axis accelerometers

Implications of Requirements

2km bridge can have as many as 200 sensors 6 nodes per span; 60m span

Data collection duration: 40sec Data generated by a node: 3 channels * 12 bits *

40 Hz * 40 sec = 57.6kbits Maximum data from a data span (12 nodes):

691.2kbits Maximum data generated by the sensors on the

bridge: 1.44 MBytes

Solution Approach

Battery operated wireless sensor motes Cheap alternative Easy to deploy and maintain

Eliminates hassle of laying cable to route data/power

No solar panels Expensive and prone to theft Sensors maybe placed under deck in shade

Key Goal: Minimize energy consumption

Hardware Details Sensor mote: Tmote-Sky

8 Mhz MSP430 processor 250kbps 2.4Ghz radio

complaint with 802.15.4 MEMS based ADXL 203

accelerometer Dual axis Range is +/- 1.7g Sensitivity 1000mv/g

8dBi Omni Antenna

Challenges

Event Detection Cannot predict train arrival To conserve power, sensor nodes have to

duty-cycle (sleep + wake cycle) Remote Access

Bridges may not have network coverage to transfer data to central server

Scalability Can have as many as 200 sensors per bridge Protocols and architecture needs to be

scalable

Outline

Motivation Application Requirements Challenges Overview of Architecture Event Detection Data Transfer Measurements on a Bridge Conclusions

Architecture Overview

12

3

45

6

Span

3

12

5

6

4

1 Cluster heads

Channel 3

Channel 5

Channel 3

Channel 5

Piers

Event Signaling module (Channel 1)

Clusters

Data Transport modules

Data span as an independent network Each cluster operates on a different channel

12

3

45

6

3

12

5

6

4

Channel 3

Channel 5

Topology Formation

12

3

45

6

3

12

5

6

4

Channel 3

Channel 5

Time Synchronization

12

3

45

6

3

12

5

6

4

Sleep-Wakeup

Channel 1

Channel 3

Channel 5

12

3

45

6

3

12

5

6

4

Train Arrival Detection

Command Control: Wakeup

12

3

45

6

3

12

5

6

4

Vibration Sensing

12

3

45

6

3

12

5

6

4

Data Gathering by individual cluster heads

Channel 3

Channel 5

12

3

45

6

3

12

5

6

4

Sleep-Wakeup

Channel 1

Channel 3

Channel 5

12

3

45

6

3

12

5

6

4

Train Detection Data Uploading

12

3

45

6

3

12

5

6

4

Sleep-Wakeup

Send Data to Repository

BriMon Architecture: Event Detection

Span

Head node

Dd

T dc=DdV

P

BriMon Architecture: Event Detection

Span

Head node

Dd

T dc=DdV

P

BriMon Architecture: Event Detection

Span

Head node

Dd

T dc=DdV

P

BriMon Architecture: Event Detection

Span

Head node

Event Detection: Analysis Question: What should be the

duration of sleep and wake up? Tdc = max time available between

detection of oncoming train and data collection

Tcc = sleep/wakeup cycle = Tsl + Tw

Tw = Tdet + Tcd + Tpc (at head mote)

Tdet: Time taken to detect the train

Tcd : Maximum clock drift

Tpc : Time taken for command propogation

Event Detection

Tw = 2*Tcd + Tpc (at non-head mote) Ans: Tdc = Tcc + Tw = Tsl + 2Tw

Radio Range Measurements

Tdc = D/V D is found to be

about 400m with 8dBi omni-antenna for various speeds

At 80kmph, Tdc = 36s

Use of 802.11 extends

range to 800m Frontier Nodes

Time Synchronization Tw is function of Tdet & Tcd & Tpc

Tsl = Tdc - 2* Tw

Tpc : We use same protocol for synchronization as well as command issue Flooding with multiple retransmissions (3) Tpc turns out to be about 72ms Error in synchronization is 0.18ms

Time Synchronization

Calculating Tcd

Worst case clock drift in 36 sec is 20ppm Synchronization error is 0.31ms Tcd = 36s * 20 * 10^-6 (0.72) + 0.18 = 0.9ms

Tcd << Tpc ; Tdet ~ 50ms;

Tw ~ 125ms; Tsl ~ 36–0.25 = 35.75;

Duty Cycling ~ 0.3%

Data Transfer

Long distance wireless links infeasible 2km bridge with 200 sensors generate 1.5MB

data Transfer to single hop over 10-20 hops presents

scalability problems Data transfer time for 14 node network is 5 min

Reference: “A Wireless Sensor Network for Structural Health Monitoring: Performance and Experience”, EmNetS-II, May 2005

Data Transfer: Our Approach

Use multiple channels; one for each data span Data across spans independent At most 12 nodes per span; very scalable Adjacent channels are 7 spans apart with 16

available channels Transfer data of the span motes to the head

mote Transfer data from head mote to train

Data Transfer

C3 C5 C7 C9

Head Mote

3

6

52 41

Data Transfer within Span:Routing Issues

Links are very stable in our setting Reference: “Implications of Link Range

and (In)Stability on Sensor Network Architecture”, WINTECH 2006

Any simple protocol can be used Centralized 2 Phase routing Average duration of routing for 6 nodes :

567ms

Routing Protocol: An Example

2

4

1 3

6

5

(a) Cluster of six nodes

2

4

1 3

6

5

(b) Neighbourhood Discovery

2

4

1 3

6

5

(c) Nodes 2,3 & 4 are good neighbours to node 1

2

4

1 3

6

5

(d) Node 6 is a good neighbour to node3, node 5 has no good neighbour

2

4

1 3

6

5

(e) Node 5 is a bad neighbour to node 3

2

4

1 3

6

5

(f) Dispatch Tree information

Data Transfer within Span: Transport Protocol

Transport protocol Transfers data from the motes to the head mote NACK based block transfer

HEAD Mote NODE-2

FLASH

NODE-3 NODE-4

FLASHCMD Data TFR

CMD Data ACK

CMD Data TFR

CMD Data ACK

CMD Data TFR

CMD Data ACK

Block Data TFR

Block Data ACK

Block Data TFR

Block Data ACK

Block Data TFR

Block Data ACK

Single Hop Data Transfer

Mobile Data Transfer Achievable data transfer rate using block

transfer transport protocol on hardware is 46kbps (tested on field)

Max data per data span is 693Kbits (12 nodes) Contact duration required is 15sec

Contact Range required = contact duration * speed of train

Head node

Contact Range = D

Throughput Considerations

Contact range required for data transfer is 330m at train speed of 80kmph 250m at train speed of 60kmph

Our measurements give a contact range of 400m (one-side)

Transfer is possible with enough leeway. Throughput can be further increased via

Compression Multiple receivers at head and rear of train Better Hardware

Simultaneous operation of flash and radio Bluetooth Radio (1Mbps)

Lifetime Estimate Can achieve 1.5 year of operation using a

2500mAH battery

131s 33s 15s

36s

Measurements on a Bridge

Omni antenna

Measurements on a BridgeSink Mote

Data Analysis Tool

Conclusions Application specific design

Extensive measurement study Novelty of our contributions

Event detection mechanism Mobile data transfer Integration with

time-synchronization/routing Estimates indicate network can operate

without intervention for 1 1/2 years