1 / 43

Presenter : Steve

Presenter : Steve. BRIMON: Wireless Sensor Network based Railway Bridge Monitoring Kameswari Chebrolu , Bhaskaran Raman, Nilesh Mishra, Phani Kumar Valiveti, Raj Kumar. Outline. Motivation Application Requirements Challenges Overview of Architecture Event Detection Data Transfer

watson
Download Presentation

Presenter : Steve

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Presenter : Steve BRIMON: Wireless Sensor Network based Railway Bridge MonitoringKameswari Chebrolu , Bhaskaran Raman, Nilesh Mishra, Phani Kumar Valiveti, Raj Kumar

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

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

  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. Architecture Overview • Data span as an independent network • Each cluster operates on a different • channel Channel 5 Data Transport modules Channel 3 Clusters Channel 5 3 6 Event Signaling module (Channel 1) 1 2 3 Channel 3 4 5 6 1 2 4 5 Span Cluster heads 1 Piers

  12. Topology Formation 3 6 1 2 3 4 5 6 1 2 Channel 3 4 5 Channel 5

  13. Time Synchronization 3 6 1 2 3 4 5 6 1 2 Channel 3 4 5 Channel 5

  14. Sleep-Wakeup 3 6 1 2 3 4 5 6 1 2 Channel 3 4 5 Channel 1 Channel 5

  15. Command Control: Wakeup Train Arrival Detection 3 6 1 2 3 4 5 6 1 2 4 5

  16. VibrationSensing 3 6 1 2 3 4 5 6 1 2 4 5

  17. Data Gathering by individual cluster heads 3 6 1 2 3 4 5 6 1 2 Channel 3 4 5 Channel 5

  18. Sleep-Wakeup 3 6 1 2 3 4 5 6 1 2 Channel 3 4 5 Channel 1 Channel 5

  19. Data Uploading Train Detection 3 6 1 2 3 4 5 6 1 2 4 5

  20. Sleep-Wakeup 3 6 1 2 3 4 5 6 1 2 4 5

  21. Data Analysis Centre Send Data to Repository

  22. BriMon Architecture: Event Detection Span P Head node

  23. BriMon Architecture: Event Detection Span P Head node

  24. BriMon Architecture: Event Detection Span P Head node

  25. BriMon Architecture: Event Detection Span Head node

  26. 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 propagation

  27. Event Detection • Tw = 2*Tcd + Tpc (at non-head mote) • Ans: Tdc = Tcc + Tw = Tsl + 2Tw

  28. 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

  29. 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

  30. 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%

  31. 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

  32. 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

  33. 3 4 5 1 2 6 Data Transfer C3 C5 C7 C9 Head Mote

  34. 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 • 1.Neighbor-discovery Phase • 2.Tree construction phase • Average duration of routing for 6 nodes : 567ms

  35. Routing Protocol: An Example 4 4 4 4 4 4 1 1 1 1 1 1 2 2 2 2 2 2 3 3 3 3 3 3 5 5 5 5 5 5 6 6 6 6 6 6 (d) Node 6 is a good neighbour to node3, node 5 has no good neighbour (c) Nodes 2,3 & 4 are good neighbours to node 1 (f) Dispatch Tree information (e) Node 5 is a bad neighbour to node 3 (b) Neighbourhood Discovery (a) Cluster of six nodes

  36. FLASH FLASH 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

  37. Single Hop Data Transfer

  38. 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

  39. 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)

  40. Lifetime Estimate • Can achieve 1.5 year of operation using a 2500mAH battery 36s 15s 131s 33s

  41. Measurements on a Bridge Omni antenna

  42. Measurements on a Bridge Sink Mote

  43. 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

More Related