ReStructure: A Wireless Sensor Network for Monitoring
Temporary Earth Retaining Systems
Ross Wilkins Elena Gaura
Cogent Labs, Cogent Labs,
Coventry University, UK Coventry University, UK
ross.wilkins@coventry.ac.uk e.gaura@coventry.ac.uk
John Kemp James Brusey
Cogent Labs, Cogent Labs,
Coventry University, UK Coventry University, UK
aa9384@coventry.ac.uk j.brusey@coventry.ac.uk
ABSTRACT
Temporary earth retaining structures help prevent collapse
during construction excavation. To ensure that these struc-
tures are operating within design specifications, load forces
on supports must be monitored. Current approaches are
expensive, often manual, and difficult to integrate into pre-
dictive models. We developed a wireless strain gauge suit-
able for harsh construction environments along with a data
collection back-end that could be integrated into on-line
predictive models. This system has been used to monitor
an underground train station construction site in Singapore
for 5 months. Key challenges are to ensure valid meas-
urements, reliable wireless communication, sufficiently long
battery life, and protection against weather and incidental
damage. This paper describes the system design, experi-
ences with its deployment and lessons for future develop-
ments.
Categories and Subject Descriptors
C.3 [Special-Purpose and Application-Based Systems]:
[Realtime and Embedded Systems]
Keywords
Wireless Sensing; Structural Health Monitoring; Deploy-
ment
1. INTRODUCTION
Excavation operations require the use of Temporary Earth
Retaining Structure (TERS) whose designs are based on
model-based analysis carried out before the excavation be-
gins. Once construction begins, structural parameters of the
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for profit or commercial advantage and that copies bear this notice and the full citation
on the first page. Copyrights for components of this work owned by others than the
author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or
republish, to post on servers or to redistribute to lists, requires prior specific permission
and/or a fee. Request permissions from Permissions@acm.org.
RealWSN’15, November 1, 2015, Seoul, South Korea..
Copyright is held by the owner/author(s). Publication rights licensed to ACM.
ACM 978-1-4503-3840-0/15/11 ...$15.00.
DOI: DOI: http://dx.doi.org/10.1145/2820990.2820999.
37
Michael Allen
Cogent Labs,
Coventry University, UK
michael.allen@coventry.ac.uk
Andrew J. Whittle
Department of Civil and
Environmental Engineering,
MIT, MA, USA
ajwhittl@mit.edu
TERS are monitored through field measurements (typically
strain, pore pressure, and wall deflection). Measurements
are taken to compare against the expected values given by
the model and also to determine if the design specification
has been exceeded. These measurements, however, are ex-
pensive to obtain, and the process of gathering the data is
not always automated. Furthermore it is not general prac-
tice to incorporate field measurements into models during
construction to compare actual versus expected perform-
ance. If this could be enabled, knowledge about the con-
struction process could be improved, potentially reducing
risk and costs in the future.
In applying wireless sensing to TERS monitoring, we want
to increase measurement density and value to the overall
construction (e.g., enabling data to feed into real-time mod-
els, not just inform static alarm thresholds). Our initial
aim is to create a proof-of-concept Wireless Sensor Net-
work (WSN) that is deployed directly onto support struts
to acquire strain data (a proxy for structural load). Achiev-
ing a feasible prototype requires valid measurements, reli-
able wireless communication, and packaging for protection
against the weather. Analysis of the archive of data cre-
ated through this pilot will give insight into the feasibility
of moving toward intelligent WSNs for TERS monitoring.
The project has been active since January 2014. In the
first 12 months, a small prototype network was built and
characterised, and in the last 6 months we deployed our
network in stages over a TERS on a live excavation. A
unique and challenging feature of instrumenting an active
construction site is that sensor node deployment continues
for the duration of the construction, thus the environment is
constantly changing and the network expanding over time.
In this paper, we focus on the design of the WSN and its
performance in the pilot deployments, along with the lessons
learned over the course of the project.
The paper is structured as follows: Section 2 provides an
overview of our system. Section 3 describes a Mass Rapid
Transit (MRT) construction case study and provides results
of the system evaluation and deployment experiences. Sec-
tion 4 describes related work, and Section 5 concludes the
paper.
 Figure 1: Architecture of the strain monitoring sensor network.
Figure 2: Sensor node hardware.
2. SYSTEM OVERVIEW
Figure 1 shows the an overview of the end–to–end sys-
tem architecture. Data flows from the sensor nodes to a
sink, where it is transmitted to a remote server via 3G and
made available to user applications. To reduce risk and de-
velopment time, we opted to use off-the-shelf hardware and
software wherever possible.
2.1 Sensor node
Our sensor node combines the Zolertia Z1 platform with
a custom strain gauge board (see Figure 2). The Z1 is based
around an MSP430 CPU and a CC2420 radio. Our custom
board provides input for one resistive strain gauge (strut
loading is assumed to be axial), whose readings are acquired
using a Wheatstone bridge combined with a low power 16-
bit ADC (TI ADS1115). Measurement resolution is <1 μe
with a measurement range of ±2500 μe. External tem-
perature/humidity is enabled by a Sensirion SHT15. Each
sensor node is packaged in an IP65 aluminium enclosure
(115×65.5×50 mm, 370 g) with holes for an external radio
antenna (4.4 dBi Antenova Titanis), a gland to support the
strain gauge wiring, and a waterproof breathable membrane
for the SHT15. Magnetic feet on the enclosures allow the
nodes to be placed over the strain gauges.
Our software was developed on top of the Contiki WSN
OS. Contiki provides a network stack with a low power MAC
(ContikiMAC) and multi-hop tree formation/data collection
protocol (Contiki Collect) that we took almost entirely out-
of-the box. The only minor change necessary was to reduce
the size of the recent message buffer kept by each node; this
reduced the amount of time needed to wait in order to verify
network formation after a node restart.
38
Drivers were written for our strain board, and at the ap-
plication level we developed a traditional sense and send
system that acquires, stores to flash and transmits network
information (time, RSSI, beacon interval, sequence number,
neighbours), strain and temperature/humidity data at five
minute intervals (92 bytes of payload total). Storing samples
to flash allows a full dataset after construction is completed,
regardless of the network condition during the deployment.
This is important for post-deployment analysis of data for
techniques such as edge mining [1].
Micro-benchmarking was used to estimate the lifetime of
the sensor nodes given a particular battery capacity and
sampling rate. The individual operations of a sensing cycle
(5 minute interval) were measured and aggregated to de-
termine a baseline for node lifetime. 270 days of operation
are expected with two 7.8 Ah 1.5 V C cells.
2.2 Gateway
Our Gateway was built using a Raspberry Pi model A+
combined with a TelosB node and a USB 3G modem (both
with external antennas). The Gateway is deployed inside
an IP65 mild steel enclosure and mounted on a pole. Due
to deployment constraints, we chose to power the Gateway
using a 12 V 100 Ah battery. During normal operation WSN
data is collected by the TelosB, aggregated at the Raspberry
Pi and transmitted hourly via 3G to a remote server.
From prior experience with deploying WSNs, we focused
on ways to i) lower power consumption, ii) improve fault
tolerance to minimise on-site maintenance, and iii) to make
on-site maintenance as easy as possible. To reduce power,
we disabled HDMI on the Raspberry Pi and made custom
circuitry to allow the power to the TelosB and 3G modem
to be controlled through GPIOs. To provide fault tolerance
between the TelosB and the Raspberry Pi, we implemented
a simple handshake connection so that the Raspberry Pi
can periodically check and restart the TelosB if necessary.
For 3G transmissions, if an hourly update fails, it is rolled
into the following hour’s transmissions, and data is always
archived locally in case of extended 3G outages. In order to
make on-site debugging and deployment easier, the Gateway
hosts a USB WI-FI dongle. When the dongle is connected,
the Gateway becomes a wireless access point (using hostap),
hosting a web page that shows real-time updates of data.
Our measures reduced the average power requirement of
the gateway from over 400 mA to 128 mA (at 12V). Based
on microbenchmarking tests, we estimate a 100 Ah battery
will provide one month’s operation.
 100
3. CASE STUDY: MRT EXCAVATION SITE
From February to July 2015, we deployed our system on
the TERS of an active MRT excavation site in Singapore. 75
The main goals of our deployment were to: i) validate the

Daily Yield (%)

communication performance of our system in-situ, ii) assess NodeId
the measurement validity, and iii) collect an archive of data 50 53
Day before 57
for offline analysis. The deployment environment was par- battery change
ticularly challenging for three reasons:
Server covered
Climate - Singapore has a tropical climate with frequent 25
in plastic
and severe rainstorms. Temperatures can rise to 35 ℃ and Stopped receiving
data after
99% RH above ground, and above 40 ℃ inside the excav- battery change
0
ation. There are large daily cycles where temperature can
change by 25 ℃ and relative humidity by 60%. Feb 15 Mar 01 Mar 15 Apr 01 Apr 15

Obstructions - Radio communication is challenging due

to the construction environment, which is mainly a combin- Figure 4: First deployment daily PDR
ation of metal and concrete materials that can reflect and
attentuate radio signals. The construction site itself is very Deployment D1–L2 D2–L1 D2–L2
dusty and there is lots of machinery and movement that Node 53 57 51 55 50 52
could damage equipment. Days 70 70 82 82 47 47
Dynamic environment - A construction site is con- PDR 83.9 83.9 90.9 86.3 94.3 94.1
stantly changing: over days and months material is being Avg. RSSI -75.1 -82.8 -83.9 -84 -82.7 -82.2
excavated from the bottom of the trench and new struts % 1–hop 98.3 51.1 83.9 98.6 71.7 79.7
and supports are being placed. Therefore, the communica- % beacon 99.2 98.0 98.1 99.0 96.8 98.1
tion environment can as struts are deployed, providing new
surfaces that can reflect and interfere with signals. Table 1: Network performance for 2 deployments
In our deployments, the network performance of the sys-
tem was evaluated using two metrics: i) Packet Delivery Ra-
tio (PDR) (calculated as packets received / expected num- traced to human error. In the first instance, the external
ber of packets) and ii) network stability - which we define as antenna for the TelosB became dislodged from the enclos-
the ratio of the number of packets a sensor node sends with ure during construction works right next to it. In the second
beacon interval = 3600 versus the total number of packets case, the battery was not changed in a timely manner be-
sent. The beacon interval is a per-node parameter used in cause there was no capability on the Gateway to remotely
the Contiki Collect stack; the beacon interval gets shorter report the battery voltage; this caused a power outage at
when the network is reorganising to allow quick building the Gateway for several hours. Finally, a faulty battery was
of neighbour tables. We also measured the Received Sig- installed on site and could not be changed over the weekend,
nal Strength Indication (RSSI) for incoming packets to the leading to several days of data loss.
Gateway. Nodes communicated on 802.15.4 channel 26 in Table 1 summarises the deployment; for both nodes the
an attempt to avoid any WI-FI interference and the max- beacon interval was at 3600 for 98 to 99% of the time, indic-
imum retries for each packet sent by Contiki Collect was set ating a stable network. Node 53 sent directly to the sink 98%
at 16. The rest of this section evaluates two deployments of the time, whilst node 57 sent through node 53 roughly as
undertaken at the MRT site. often as it sent directly to the sink.

3.1 Deployment 1: Two Node Deployment
Two sensor nodes were deployed on a level 2 strut at the
excavation, 10 metres below ground level. The gateway was
deployed at ground level near the excavation, 12 metres away
from the nodes. The strain gauges were welded to the strut
next to the contractor’s vibrating wire system, as shown in
Figure 3, while the strut had zero load on it. This enabled
us to have reference measurements to compare against. De-
ployment 1 lasted for 70 days, during which time both nodes
sent data, but one node’s data stream began to drift away
from realistic values when compared against reference con-
tractor data. We suspect this was due to water ingress from
a storm event, but it was not possible to retrieve either of
the nodes to debug for safety reasons, since the construction
had progressed significantly by this point. After this period
the Gateway was moved to another part of the construction
site for deployment 2; the nodes continue to log data and
will be collected at the end of the construction.
Figure 4 shows the daily PDR for the deployment, with
an average PDR of 83.9%. For 50 days, the PDR was 98%
on average. The drop in PDR for the other 20 days can be
3.2 Deployment 2: Four Node Deployment
Two sensor nodes were initially deployed on a level 1 strut
and two more on a level 2 strut as it was installed, several
weeks later. This demonstrated the growing of the network
as the construction evolved. The gateway was situated at
ground level, 10 m away from the level 1 strut.
The level 1 deployment has been in place for 82 days, with
level 2 in place for 47 days; Table 1 shows the results for both
levels. The PDR ranges from 86% to 94%, and expected the
nodes on level 1 transmit directly to the sink over 95% of
the time. The nodes on the second level still manage to get
directly to the sink between 72% to 80% of the time. The
network can be considered stable with the maximum beacon
interval being reported 97% of the time.
3.3 Deployment experiences
The deployments allowed us to test the integrity of the
network and the data collected, and better understand how
a network could be scaled up alongside continuing construc-
tion. We found that the Gateway lifetime was in line with
our predictions, and the battery is being replaced every 30

39
 Figure 3: Example deployment on a strut next to vibrating wire gauges
days. Having the Gateway as a wireless access point was
helpful when deploying sensors below ground, as a laptop
could be taken into the excavation to calibrate the node
and get immediate connectivity feedback. It is important
that functionality be added to the Gateway to detect and
report low battery levels and tampering (i.e. a tilt sensor).
In general, we found that communication links were much
shorter than expected. In ground level tests of radio con-
nectivity, a maximum transmission range of 60 m was ob-
served. However, hop lengths observed during deployment
were closer to 10 m. The most likely cause of this problem
is the 2.4 GHz communication frequency used.
As part of the deployment, our sensor nodes required the
Wheatstone bridge to be manually calibrated (or balanced);
this was an extremely inconvenient, time-consuming opera-
tion that would benefit from being automated [2].
The relatively slow speed of construction limited our de-
ployment speed, and the inability to access nodes after they
had been deployed meant that we couldn’t re-use nodes,
or debug them directly. This presents two significant chal-
lenges in relation to learning from the deployment: i) the
development iteration cycles become much longer term than
is standard in research, and ii) hardware failures cannot be
quickly diagnosed and resolved.
4. RELATED WORK
Our work has a commonality with other WSNs deployed
for structrual health monitoring, though those systems tend
to focus on sub-second sampling of acceleration and strain
on dynamic structures such as bridges. The Illinois Struc-
tural Health Monitoring Project (ISHMP) yielded a struc-
tural health monitoring platform based around the Imote2.
Jang et al. [2] describe the hardware and deployments of
2 single hop networks of 33 and 37 nodes. Their dynamic
resistive strain interface provides auto-calibration and zero-
ing of the Wheatstone bridge. Kurata et al. [4] deployed 28
Narada nodes on the New Carquinez suspension bridge for
a period of two years. Kim et al. [3], carried out a three-
month deployment of a 64 MicaZ node multi-hop network
on the Golden Gate Bridge, sampling vibration/acceleration
at 1 kHz. These projects highlight the difficulties of deploy-
ing on physical structures; Kim et al. [3], for example, found
that radio reception range was around 30 m, decreasing to
around 15 m where line of sight was blocked, matching our
deployment experience.
40
5. CONCLUSIONS
This paper has described our experiences with building a
WSN for strain monitoring and its deployment on a TERS
for an MRT excavation site in Singapore. Future work will
investigate scaling up deployment sizes to larger numbers
of nodes, as well as the improvement that can be gained
through using sub 1 GHz radios, the integration of meas-
urements into real-time models, and the use of in–network
intelligence to increase the lifetime of individual nodes in
the network.
6. ACKNOWLEDGEMENTS
This research was supported by the National Research
Foundation Singapore through the Singapore MIT Alliance
for Research and Technology’s Center for Environmental
Sensing and Modeling research program. Fieldwork has
been enabled through a collaborative agreement between
SMART and Singapore’s Land Transport Authority. We’d
also like to thank the reviewers for their valuable feedback.
7. REFERENCES
[1] E.I. Gaura, J. Brusey, M. Allen, R. Wilkins,
D. Goldsmith, and R. Rednic. Edge mining the internet
of things. IEEE Sensors Journal, 13(10):3816–3825,
Oct 2013.
[2] S. Jang, H. Jo, S. Cho, K. Mechitov, J. A. Rice, S. Sim,
H. Jung, C-B Yun, B. F. Spencer Jr, and Gul A.
Structural health monitoring of a cable-stayed bridge
using smart sensor technology: deployment and
evaluation. Smart Structures and Systems,
6(5-6):439–459, 2010.
[3] S. Kim, S. Pakzad, D. Culler, J. Demmel, G. Fenves,
S. Glaser, and M. Turon. Health Monitoring of Civil
Infrastructures Using Wireless Sensor Networks. In
2007 6th International Symposium on Information
Processing in Sensor Networks, pages 254–263.
[4] J. P. Lynch G. W. van der Linden H. Sedarat E.
Thometz P. Hipley L.-H. Sheng M. Kurata, J. Kim.
Internet-enabled wireless structural monitoring
systems: Development and permanent deployment at
the new carquinez suspension bridge. Journal of
Structural Engineering, 139:1688–1702, October 2013.