The Performance of a Wireless Sensor Network for Structural Health Monitoring

1
The Performance of a Wireless Sensor Network
forStructural Health Monitoring

• Jeongyeup Paek, Nupur Kothari, Krishna
  Chintalapudi, Sumit Rangwala, Ning Xu, John
  Caffrey, Ramesh Govindan, Sami Masri, John
  Wallace and Daniel Whang
• Computer Science Department, University of
  Southern California, Los Angeles, California,
  USA.
• Civil Engineering Department, University of
  Southern California, Los Angeles,California, USA.
• Civil Engineering Department, University of
  California Los Angeles, Los Angeles, California,
  USA.

2
Outlines

• Abstract
• Motivation
• SHM
• Wisden
• hardware
• software
• Deployment I STS
• Deployment II The Four Seasons building

3
Abstract

• It is the first evaluation of actual deployment
  for SHM.
• Deployed in 2 real environments
• seismic test structure
• The Four Seasons building (LA)
• Evaluations of
• reliability
• latency
• data integrity
• Validation
• compared to a wired data acquisition system

4
Motivation

• In order to improve the work in progress, Wisden,
  based on the experiences gained from these
  deployments.

5
SHM

• Structural Health Monitoring (vibration)
• traditional way
• wired
• The bad
• long cables
• change to the structure
• taking lots of time to deploy
• expensive
• wireless
• The good
• flexibility (easy to add or to remove a node)
• low cost on maintenance and deployment

6
Wisden

• a wireless multi-hop sensor network based data
  acquisition system for structural health
  monitoring (SHM) applications.
• several tens of nodes
• an accelerometer on each node
• base station
• store data from every node
• nodes form a tree topology
• sink is the root of the tree.
• nodes ? sink ? base station
• quiescent period
• make the average data generation rate less than
  the maximum achievable throughput of the network.

7
Hardwares of Wisden

• mica2 motes
• vibration card rather than native accelerometer.
• 5 to 20,000 Hz (sampling rate)
• 16 bits/sample
• -2.5g to 2.5g (range)
• can be controlled by mica2.

8
Software of Wisden

• Components
• reliability
• data compression
• data synchronization

9
Reliability

• topology self-construction
• using one component of BLAST (SenSys 2003) tree
  construction (parent selection)
• select parents based on packet loss
  performance,
• using only good wireless links in order to get
  good performance.
• reliable data delivery
• using NACK-based reliability schemes
• hop-by-hop
• end-to-end

10
reliable data delivery (1)

• hop-by-hop recovery
• sources store data in its EEPROM and transmits
  the data to its parent.
• parents keep track of seq. no. of packets that
  they receive, on a per source basis.
• if there is a loss, records source ID and seq.
  no. in a list of missing packets.
• this list and packet would be transmitted
  together to its parent, so that its child could
  overhear the list, and repair the losses.
• nodes would cache some recently transmitted
  packets.

11
reliable data delivery (2)

• end-to-end recovery
• When?
• missing packets list exceeds the memory of the
  mote.
• topology change.
• How?
• the base station can keep track of all missing
  packets.
• hop-by-hop recovery performed by base station to
  propagate this recovery request downward.

12
Data compression

• reduce the duty-cycle
• lossy run-length based compression scheme.
• if difference/variation is less than a threshold
  over a window, send average, window size.
  (quiescent period)
• threshold
• chosen experimentally based on the noise floor.

13
Data Synchronization (1)

• Sensor network time synchronization scheme
• The bad
• overhead of synchronization packets periodically.
• Time-stamping the data consistently at the base
  station
• residence time
• the time of the packet in the network.
• overhead
• the addition of a small number of bytes to each
  packet.

14
Data Synchronization (2)
15
STS (Seismic Test Struture)
16
STS

• a full scale model of an actual hospital ceiling
  structure
• Deployment
• 9 Wisden nodes (node 2-10)
• sink node (node 1), which is connected to the
  base station (a PC) via a serial port.
• validation node (node 11), which is also
  connected to a PC via a serial port.
• sampling rate 50Hz
• data generation rate 0.5 packet per sec.

17
STS

• Experiment
• excitation generation using hydraulic actuator
• impulse
• random shaking over a period of 1 minute.

18
STS
19
STS

• Experiences
• one-hop network for 99.3 of the time.
• dimensions of the structure are small.
• alignment of sensors
• issue
• mis-alignment or real vibration
• using a compass to align sensors

20
STS validation (1)

• inter-sample times between consecutive samples
  are irregular.
• reason correct the sinks local time
• Improvement equip sink with a GPS directly

21
STS validation (2)

• a consequence of the lossy compression scheme
• ignores small variations

22
STS evaluation (1)

• 0.17 packet losses
• 10 minutes are too short to perform end-to-end
  recovery scheme completely.

23
STS evaluation (2)

• quiescent period send packets once every 2
  minutes.
• packet generation rate 8.33 pkts/sec
• packet sending rate 0.5 pkts/sec
• excitation is over
• different number of packets
• number of packets are fewer, the latencies are
  lower.

24
STS evaluation (2)
25
STS evaluation (3)

• a sudden hike at a latency of around 2 minutes.
• node 7 has the highest slope.

26
STS evaluation (3)

• only a few nodes contribute to the overall CDF
  toward the end.

27
The Four Seasons Building
28
The Four Seasons Building

• a four-story office building in LA
• Deployment
• 10 motes (not in direct line-of-sight)
• validation nodes wired instruments (Building
  Sensors) of UCLA/NEES group.
• performing tests using eccentric mass shakers.

29
The Four Seasons Building
30
The Four Seasons Building

• Experiences
• communication environment is worse than STS.
• average link quality 81.12 - 37.6
• some 2 or 3 hop paths.
• some have direct connections.
• Noise and vibrations form human movements.
• a new set of batteries runs without noticeable
  increase in noise for at least 24 hours.
• deployment effort
• several days (UCLA/NEES)
• half a hour (Wisden)

31
validation (1)

• differences in instruments
• 100Hz, 50Hz
• way to set-up
• no stable zero-acceleration offset
• compression mechanism
• software bug in Wisden
• a gap in Fig. 18.

32
evaluation
33
evaluation
34
evaluation
35
evaluation
36
Conclusion

• This paper is written hastily.
• For the evaluation of deployment II, they all
  blame on the software bugs in Wisden.