Remote Monitoring System

Remote Monitoring System
Wong Jin Xiang Terence, Department of Electrical and Computer Engineering,
National University of Singapore
Abstract—This paper presents a final year project on the
design and development of a remote monitoring system for a
bridge. Essentially, the system will monitor the health of the
bridge based on continuous measurements of physical variables
from sensors mounted strategically on the structure, and fuses
the available information to yield a decision on the corrective
actions to be taken to minimize the possibility of a disaster
occurring due to a bridge structural failure. The project is
sponsored by Agilent Technologies under the Agilent
Engineering Excellence Program, and it is entirely powered
from an instrumentation and control engine which is based on
the VEE Pro Graphical Programming software and U2300
Series USB DAQ device. Full details of the working prototype
will be furnished in the paper.
I. INTRODUCTION
G
eneral structural fatigue is a key factor inducing the
occurrences of disasters due to structural failures. Early
detection of structural fatigue can arrest the occurrences
of such disasters through the use of timely preventive and
corrective measures [1]. Symptoms relating to structural
fatigue can be effectively inferred from measurements of
physical variables relating to stress, strain and/or vibration.
These measurements can be obtained through appropriate
industrial sensors and instrumentation systems. When such
information is transmitted on a regular basis to an
intelligence center which diagnoses the health of the
structure and takes corrective actions to minimize the risk of
a catastrophe from occurring, a structural health monitoring
system is essentially in place.
In this paper, a monitoring system will be developed for a
bridge which is likely to be remotely located with respect to
the monitoring and control center, and personnel. There have
been a number of bridges collapsing due to lack of
maintenance [2], causing critical damage to the structure.
Over the years, bridges have to withstand corrosion and
stress fatigue. Another major factor that contributed to
fatigue and stress corrosion in bringing down the bridge was
the weight of new cars and trucks [3]. Normally when the
bridge was designed, the design vehicle loads was of the era
at which the bridge was built. No one could foresee that in
the many years after the construction of the bridge, traffic
loads would more than triple. If these go undetected, the
prolong accumulation of these stress margin violations will
cause the failure of the entire structure, precipitating a
disaster of epic proportions. The collapse of the bridge and
This work was supported in part by Agilent Technologies under the
Agilent Engineering Excellence Program, which encourages the
development of applications using the Agilent VEE Pro 8.0 Graphical
Programming software and U2300 Series USB DAQ.
Wong Jin Xiang Terence is currently pursuing the Degree of Bachelor of
Engineering in Electrical and Computer Engineering Department, National
University of Singapore (e-mail: [email protected]).
loss of vehicles will be costly, but the loss of human lives is
beyond measure.
There are three challenges involved in monitoring an
extensive and heavily used structure such as the bridge.
First, there is an obvious need to have an adequate and
extensive arrays of sensors fitted at critical locations on the
structure. In many cases, hard wiring of the sensors to a
distant control center may not be possible and wireless
communication will be necessary. Secondly, an intelligent
control center must be present to make quick and sound
decision on the health of the structure based on the multiple
sources of information coming in on a continuous basis.
Finally, any corrective actions necessary for an extensive
structure as a bridge will typically require the immediate
mobilization of huge number of personnel who can be
located anywhere at the time of alert. An efficient and robust
notification system must form a part of such a remote
monitoring system. .
The entire real-time system is designed and built based on
Agilent’s USB Data Acquisition (DAQ) system [4] and VEE
Pro control platform [5]. In the subsequent sections, the
bridge model, the overall structure of the remote monitoring
system and its constituent components will be elaborated in
this paper. Realistic scenarios will be enacted and presented
to show the responsiveness of the system to failing
symptoms manifesting.
II. OVERVIEW OF REMOTE MONITORING SYSTEM
An overview of the Remote Monitoring System is shown
in Fig. 1. The overall system comprises of several key
components.
Fig. 1. Overview of the Remote Monitoring System
At the center stage is the Bridge Model which is the
subject to be monitored for safety. Although it is a scaleddown physical model, explicit efforts were put in to ensure
that all other components/signals are scaled proportionately
so that the system emulates a real bridge as closely as
possible.
The Health Signal Collector is a hardware device which
accumulates and processes measurements from incoming
sensors, thereafter conditioning them into generic signals
which the data acquisition system can relate to (i.e., the
Agilent USB DAQ). The collected information will then be
passed to the Central Control Center for data analysis.
The Central Control Center will process and analyse the
information from the Health Signal Collector. This is where
a categorization of faults identified will be done, and a
classification on the overall health status is made. These
decision algorithms may treat the monitored system as a
black-box and use simple signatory thresholds to compare
the actual situations against, or they may use more elaborate
model-based approaches to further identify the precise
source and bottleneck of fault symptoms occurring. The
Central Control Center will subsequently trigger appropriate
supporting subsystems based on user-defined rules.
The Traffic Advisory System provides a visual early
warning to road users of the bridge by showing lane status of
the bridge using large external LED displays. This provides
road users ample warning and sufficient time to reduce or
stop the traffic in the case of a critical fault on the bridge.
The Health Status System sends periodic and critical
updates on the health status of the bridge to the bridge
maintenance engineers. It uses a GSM SMS modem to send
SMS text messages to the mobile phones of the engineers.
The Video Monitoring System uses video cameras to
provide real time round the clock surveillance of the bridge.
The recorded footage together with the sensor data will
assist engineers in determining the cause of the fault.
The Web Monitoring System allows maintenance
engineers access and control of the Remote Monitoring
System through the use of the Internet. Thus, it allows
engineers to access the situation of the bridge anytime and
anywhere in the world as long as there is internet
connectivity.
In the ensuing sections, each of these components will be
elaborated in details.
III. BRIDGE MODEL
The Remote Monitoring System requires a platform on
which all the sensors can be installed and possibly having a
realistic scenario to be tested on. With all these
considerations in mind, a scaled-down version of a bridge is
chosen to be the model of study in this project.
The selection of the bridge is the one of the most crucial
part of the paper as it is the backbone on which the entire
system rests on. Special considerations went into the
selection of the type of material that the bridge is made of,
and also the flexibility of construction options of the bridge.
The final model bridge was built using K'NEX Education:
Real Bridge Building Kit, which contains numerous small
plastic rods and pieces that can be connected in a variety of
many different ways to construct the required structure, and
thus having the ability to create realistic replicas of real
world bridges.
The physical design of the “Firth of Forth Rail Bridge”
was used as a reference for the model bridge. The Firth of
Forth has two bridges in its name, the Road and Rail bridges
[6]. In this paper, the “bridge” thus refers to a model of the
“Firth of Forth Rail Bridge”.
Fig. 2. Completed Bridge Model
Fig. 2 shows a photo of the completed model bridge with
sensors already mounted on the bridge structure. Certain
areas have been modified to incorporate the mounting of the
required sensors onto the bridge.
IV. HEALTH SIGNAL COLLECTOR
The Health Signal Collector, shown in Fig. 3, is tasked to
collect real time data from all the attached sensors and pass
them on to the Central Control Center.
Fig. 3. Overview of the Health Collection System
The Health Signal Collector is designed to interface
efficiently with commercial sensors available. The sensor
information is acquired through the input analog ports of the
Agilent USB DAQ unit. After which, the information is
processed and passed to the Central Control Center for
analysis.
A. Sensors
Fig. 4. Typical sensing parameters for a bridge
Fig. 4 shows an example of typical parameters that are
observed in a real life application of a bridge monitoring
system.
Careful selection of the physical variables which can
reflect the health of a bridge structure is first done. They are
identified to be:
o Strain (via strain gauges)
o Vibration (via accelerometers)
o Pressure (via load cells)
Accordingly, sensors (strain gauges to measure strain,
accelerometers to measure vibration along three axes, load
cells to measure pressure) which can yield these
measurements over an adequate range associated with the
bridge models are selected and amounted onto the bridge.
MICAz wireless sensors are also mounted to reflect a
realistic scenario for the need of wireless transmission of
information from the bridge to a distant control centre.
kilograms by using this formula based on the provided
manufacturer’s datasheet
W = S • VO •
C. Measurements Collection
Information on the sensors is measured via the output
voltage levels using the USB DAQ. The command
Meas:Volt:Dc? (@101) is used to retrieve the voltage from
channel 101 of the USB DAQ and input it into the virtual
instrument on VEE Pro Software.
1) Strain
Since the data collected is a raw voltage signal, there is a
need to convert it to µstrain by using this formula:
VO
GF • ε ,
≈
V EX
4
Equation (1) can be re-written in terms of strain as:
4
V
• O
GF V EX
O,y
a z = (VO , z − 1 .66 ) / S
(6)
where ax, ay and az refer to the acceleration in the x, y and z
axes in terms of G force respectively, VO,x, VO,y and VO,z
refer to the output voltage of the accelerometer module in
the x, y and z axes respectively and S is the sensitivity of the
accelerometer module.
4) MICAz Wireless Sensors
Due to areas where hard wiring of sensors may be
impossible, MICAz wireless sensors nodes can be deployed,
enabling fault-tolerant self-healing mesh sensor networks.
The MICAz node can detect ultra-small vibrations, acoustic
noise, and magnetic disturbances, as well as conventional
light, temperature, and proximity. It also includes a sensorinterface port that enables the use of specialized sensors.
The Health Signal Collector has the capability to support
inputs from MICAz sensors. Currently it is being configured
into fault detection by checking if the sensor values hold the
following condition:
y = ET
(7)
where y is the output and ET refers to the threshold value.
Exceeding the threshold signifies a fault.
V. CENTRAL CONTROL CENTER
(1)
where VO, VEX are the output and excitation voltages of the
Wheatstone bridge, GF is the strain gauge factor, and ε is
the strain.
ε ≈
(3)
where W is the weight, S is the sensitivity of the load cell
and VO is the output voltage of the load cell, VEX, actual and
VEX, nominal are actual used and nominal excitation voltages of
the load cell.
3) Accelerometer Module
As for the accelerometer, it is connected to analog input
AI114 to AI116 with respects to X to Z axis. The formula,
given in the manufacturer’s datasheet, needed to convert the
raw input voltage into acceleration in terms of G force is
(4)
a x = (VO , x − 1 . 66 ) / S
,
a = (V − 1 .66 ) / S
(5)
y
B. Signal Conditioning Circuit
Signal conditioning is used to improve the Signal to Noise
ratio of the output signals coming out from the strain gauges
via the Wheatstone bridge [7]. The output voltage signal is
usually very small, and thus an instrumentation amplifier is
used to amplify the output voltage to an acceptable working
range. The Texas Instruments INA128 precision, low power
instrumentation amplifier is selected due to its excellent
CMRR of 120dB and low drift voltage of max 0.5µV/°C
maximum.
In order to integrate all the signal conditioning circuits in a
compact form, a Printed Circuit Board (PCB) was designed
and fabricated.
V EX ,actual ,
V EX ,nominal
(2)
The above equation is also used for the other strain gauges.
2) Load Cell
Similarly, for the load cell, it is connected to the analog
input channel AI107. The raw signal is also converted to
The Central Control Center is the main control center of
the Remote Monitoring System. It will retrieve conditioned
sensor measurements from the Health Signal Collection
System and make decisions based on known thresholds and
algorithms to determine bridge health. This center is where
the complex decision making algorithms will reside to filter
false alarms from real ones, to categorize faults and the
dangers they pose, and to carry out appropriate corrective
actions. The algorithms are programmed entirely in software
using VEE Pro 8.0.
A. Threshold Levels
Each individual sensor variable will be continuously
compared against the preset signatory thresholds to yield
three levels of warnings
1 - Normal
2 - Warning
3 - Critical fault
Should any of the thresholds associated with the
measurements be triggered, the status of the monitored
object will be change to reflect the following status.
B. Determining Threshold Levels
There are many methods available for setting threshold
levels for the bridge under monitoring. One effective method
is to use the known maximum stress level that the material
can withstand. As it is dangerous to use the exact maximum
value, it is advisable to refer to the safety limits set out by
government regulations.
Another method is to use the maximum likelihood
estimation theory to estimate the maximum limit. It is a
popular statistical method used to calculate the best way of
fitting a mathematical model to some data. Modeling real
world data by estimating maximum likelihood offers a way
of tuning the free parameters of the model to provide an
optimum fit.
C. Model-based Approach
The model-based approach can also be used to derive the
thresholds of the safety limits of the model bridge. A good
model of the system is usually necessary for such an
approach to work well. The model based approach can give
a better indication of the safety limits by observing unusual
deviations and trends from the recorded sensor data.
Currently the monitoring method used in the Central
Control Center is based only on fixed signatory thresholds.
However with data logging over extended, it can be possible
to monitor the trends as well other than absolute values.
Future plans are to convert the monitoring method to
incorporate model based approach.
VI. SUPPORT SYSTEMS
This section will describe in detail the functions of each
individual support system and how it interacts with the
Central Control Center.
A. Traffic Advisory System
LEDs
LEDs
LEDs
Fig. 5. Three lane traffic status display system
The Traffic Advisory System will control the availability
of road lanes to road users to minimize uneven loading of
the bridge, thus preserving the life of the bridge and
minimizing hazards posed to road users. Since each road
lane is attached with a strain gauge, the actual loading of
each lane can be retrieved from the Central Control Center.
The status of each road lane is shown to the road users via
a set of large and bright Green-Yellow-Red LEDs. The LEDs
are directly connected to the output port of the USB DAQ
and are controlled using the VEE Pro software. Fig. 5 shows
the traffic status display system.
B. Health Status System
The Health Status System will send out periodic SMS
(Short Message Service) alerts to the engineers in charge of
the maintenance of the bridge and informing them of real
time changes to the health of the bridge. The SMS alerts are
sent out using the iTegno 3000 GSM data modem as shown
in Fig. 6.
Fig. 6. iTegno 3000 SMS modem
C. Pedestrian Warning System
The Pedestrian Warning System allows users of the bridge
to know emergency situation arising by activating a loud
audible signal and bright flashing lights. A piezoelectric
buzzer is used in this project for this purpose.
D. Video Monitoring System
The Video Monitoring System allows maintenance
engineers to have 24/7 surveillance of the bridge condition.
This is particularly useful and advantageous as it provides
the maintenance engineers a better holistic view of the
situation. Multiple cameras can be connected to the Video
Monitoring System and in this paper, a generic USB Web
camera is used. Once a fault is activated, it will take a
snapshot of the bridge, thus providing the maintenance
engineers a firsthand overview of the situation.
E. Web Monitoring System
The Remote Monitoring System can be viewed and
controlled via the Internet. The Web Monitoring System uses
the built-in Web server in Agilent VEE Pro 8.0, providing
the engineers a means to monitor and troubleshoot faults in
the Remote Monitoring System from a remote Web browser
using standard HTTP protocol. This feature can be used to
allow the followings
•
Troubleshoot a fault in the Remote Monitoring System
•
Retrieve real-time health status information
•
Monitoring of off-site locations
VII. TEST RESULTS AND DEMONSTRATION SCENARIOS
The Remote Monitoring System has been completed and
trial tests have been made to determine the functionality of
the system.
As expected, the icons reflected the correct status of the
loading of the bridge.
A. Test vehicles
Three model vehicles shown in Fig. 7 were chosen to be the
test subjects for the loading of the bridge. Test Vehicles 2
and 3 have been selected to be heavier to simulate
overloading of the bridge. Details of each test vehicle are
given in Table I.
Fig. 8. Test Scenario 1 results
Fig. 7. Photo of Test Vehicles, from left to right, Veh2, Veh1 and Veh3
TABLE I
WEIGHT OF TEST VEHICLES
Test
Vehicle
Veh1
Veh2
Veh3
Color
Weight
Type
Purpose
red
white
green
40 grams
180 grams
195 grams
static
static
radio
controlled
normal
overloaded
Since Lane 3 had a critical fault, the alarm of the
Pedestrian Warning System was activated. At the same time,
a SMS message was sent to the engineers informing them of
the situation. Similarly, a snapshot of the bridge was taken to
record the incident for analysis by the Video Monitoring
System. A sample of photo taken is shown in Fig. 9.
Once any critical fault is triggered, the fault state is held
till it is cleared by the operator. The fault can be reset by
clicking on the “Reset Fault” button once the fault is
rectified or it has been deemed as a false alarm.
Green
Yellow
Red
overloaded
Test Vehicle 3 can be radio controlled to advance the
bridge via a radio controller. This will help to eliminate any
kind of human-induced uncertainties while running the test
experiments in tests where a precise determination of
specific faults are required..
B. Test Scenarios
The following test scenarios will test the functionality of
the bridge and determine its proof of concept. However, due
to the space constraint of this paper, important scenarios
have been chosen to display the key features of the system.
1) Static loading of lanes
In this scenario, each lane of the bridge is placed with
different vehicle loads as follows in Table II:
Fig. 9 Sample photo taken during Test Scenario 1
2) Dynamic loading of lanes
In this scenario, Veh3 is used to travel past the mid section
of the bridge, simulating dynamic loading.
TABLE II
LANE C ONFIGURATION OF TEST SCENARIO 1
Lane
Test vehicle
Weight
Purpose
1
2
3
Veh1 (x1)
Veh1 (x3)
Veh2 (x1)
40 grams
120 grams
180 grams
normal
medium loading
overloading
Three units of Veh1 were placed on Lane 2 to simulate
medium loading of the road and one unit of Veh2 was used
on Lane 3 to replicate overloading of the bridge. The results
are shown in the Remote Monitoring System’s GUI in Fig. 8.
Fig. 10. Mid Lane strain readings with Test Vehicle 3
The strain readings build up as Test Vehicle 3 travels along
the bridge as shown in Fig, 10. The strain value peaked at
about 330 µstrain when Test Vehicle 3 is at the mid-section
of the bridge where the strain gauge is mounted. Similarly in
Scenario 1, the alarm will be activated, a SMS will be sent
and a photo will be taken to record the incident at the point
of triggering of the peak value.
3) Undue Vibration
In this test, undue vibration is simulated by lateral
movement imparted deliberately to the bridge. Three levels
of test vibration have been decided, from low to medium to
high. The results of the different levels of vibration are
shown in Figs. 11 to 13.
name/viewpanel?monitoring”. In Fig 14, the user interface
of the Remote Monitoring System is shown in an Internet
Explorer window, where all bridge variables can be seen in
one glance in real-time.
Fig. 11. Accelerometer readings with low rocking vibration
Fig. 14. Remote Monitoring System in Internet Explorer window
C. Test Scenario Results
The above test scenarios have proven the functionally of the
Remote Monitoring System. It has been shown that a remote
monitoring system is feasible using Agilent’s USB DAQ
device and VEE Pro Graphical Programming software.
Fig. 12. Accelerometer readings with medium rocking vibration
Fig. 13 Accelerometer readings with high rocking vibration
Upon detection of the high rocking vibration, a fault is
triggered in the Central Control Center. Likewise in the
above scenario, the alarm will be activated, a SMS will be
sent and a photo will be taken to record the incident at the
point of triggering.
4) Premptive Action Via Wireless Sensor
In practical situations, the time to limit to a critical fault
signal can be very short and limited, and a strategy may be
to detect undue vibrations occurring a certain radius away
from where the bridge is located. In some situations,
wireless sensors may have to be used at these distant
locations. In this test, we use a MICAz wireless sensors.
Heavy vibration was applied to one of the MICAz wireless
sensors, resulting in the triggering of a fault. Because of the
propagation delay due to the wireless transmission, there is a
slight delay as opposed to the hard wired sensors but for the
purpose of detecting vibrational waves away from the
bridge, this short delay is tolerable.
5) Web Monitoring
Given the proper credentials, the status of the bridge can be
viewed remotely anytime via the internet by logging into the
system by keying in the server name, for example: “//server-
VIII. CONCLUSIONS
This paper has presented the final year project on the
design and development of a remote monitoring system for a
bridge. Essentially, the system monitors the health of the
bridge based on continuous measurements of physical
variables from sensors mounted strategically on the
structure, and fuses the available information to yield a
decision on the corrective actions to be taken to minimize
the possibility of a disaster occurring due to a bridge
structural failure. The project is entirely powered from an
instrumentation and control engine which is based on the
VEE Pro Graphical Programming software and U2300
Series USB DAQ. A working prototype has been
successfully constructed and tested.
REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
Fu-Kuo Chang, “Structural Health Monitoring: Current Status and
Perspectives”, pp. 339-350 (1997)
“Bridge Collapse in Minneapolis Kills at Least 7”, The New York
Times, http://www.nytimes.com/2007/08/02/us/02bridge.html
K. Yokoyama, A.K.M. Rafiquzzaman, “Sensors and Condition
Evaluation for Bridge Health Monitoring Using Operating Vehicle
Loading”, Chapter VI, 2005
“Agilent | U2353A USB Modular Data Acquisition”, Agilent
Technologies,
http://www.home.agilent.com/agilent/product.jspx?nid=35075.384460.00&cc=US&lc=eng
“Agilent | Agilent VEE Pro 8.0” , Agilent Technologies,
http://www.home.agilent.com/agilent/product.jspx?cc=US&lc=eng&n
id=-536900532.425703
“Forth Bridge (railway)”, Wikipedia ,
http://en.wikipedia.org/wiki/Forth_Bridge_(railway)
“Strain Gage: Installation”, EFUNDA engineering fundamentals,
http://www.efunda.com/DesignStandards/sensors/strain_gages/strain_
gage_installation.cfm