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