BRIMON: Wireless Sensor Network based Railway Bridge Monitoring

1
BRIMON Wireless Sensor Network based Railway
Bridge Monitoring

• Kameswari Chebrolu
• Assistant Professor
• Department of Electrical Engineering
• IIT Kanpur
• http//home.iitk.ac.in/chebrolu

2
People

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

3
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

4
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

5
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
6
Application Requirements
30-125m
3-axis accelerometers

• 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

7
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

8
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
9
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

10
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

11
Outline

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

12
Architecture Overview
Channel 5

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

Data Transport modules
Channel 3
Clusters
Channel 5
Event Signaling module (Channel 1)
Channel 3
Cluster heads
1
Piers
13
Topology Formation
3
6
1
2
3
4
5
6
1
2
Channel 3
4
5
Channel 5
14
Time Synchronization
3
6
1
2
3
4
5
6
1
2
Channel 3
4
5
Channel 5
15
Sleep-Wakeup
3
6
1
2
3
4
5
6
1
2
Channel 3
4
5
Channel 1
Channel 5
16
Command Control Wakeup
Train Arrival Detection
3
6
1
2
3
4
5
6
1
2
4
5
17
Vibration Sensing
3
6
1
2
3
4
5
6
1
2
4
5
18
Data Gathering by individual cluster heads
3
6
1
2
3
4
5
6
1
2
Channel 3
4
5
Channel 5
19
Sleep-Wakeup
3
6
1
2
3
4
5
6
1
2
Channel 3
4
5
Channel 1
Channel 5
20
Data Uploading
Train Detection
3
6
1
2
3
4
5
6
1
2
4
5
21
Sleep-Wakeup
3
6
1
2
3
4
5
6
1
2
4
5
22
Data Analysis Centre
Send Data to Repository
23
BriMon Architecture Event Detection
Span
P
Head node
24
BriMon Architecture Event Detection
Span
P
Head node
25
BriMon Architecture Event Detection
Span
P
Head node
26
BriMon Architecture Event Detection
Span
Head node
27
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

28
Event Detection

• Tw 2Tcd Tpc (at non-head mote)
• Ans Tdc Tcc Tw Tsl 2Tw

29
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

30
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

31
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 ltlt Tpc Tdet 50ms
• Tw 125ms Tsl 360.25 35.75
• Duty Cycling 0.3

32
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

33
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

34
Data Transfer
C3
C5
C7
C9
Head Mote
35
Data Transfer within SpanRouting 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

36
Routing Protocol An Example
37
Data Transfer within Span Transport Protocol

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

CMD Data TFR
CMD Data TFR
CMD Data TFR
CMD Data ACK
CMD Data ACK
CMD Data ACK
HEAD Mote
NODE-2
NODE-3
NODE-4
Block Data TFR
Block Data TFR
Block Data TFR
Block Data ACK
Block Data ACK
Block Data ACK
38
Single Hop Data Transfer
39
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

Contact Range D
Head node
40
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)

41
Lifetime Estimate

• Can achieve 1.5 year of operation using a 2500mAH
  battery

36s
131s
15s
33s
42
Measurements on a Bridge
Omni antenna
43
Measurements on a Bridge
Sink Mote
44
Data Analysis Tool
45
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