Geotechnical News - December 2010 - page 26

26
Geotechnical News December 2010
Geotechnical Instrumentation News
Why Do I Feel Able to Write
This Article?
Readers may ask why my comments
might assist others in their decision
making. I have been involved in
monitoring and the use of custom
interfaces to allow interpretation
of the results since the late 1980s,
commencing with the Docklands Light
Railway Extension into the City of
London (which included 3D-spatial
survey, displayed via AutoCAD)
through Heathrow Express, Channel
Tunnel Rail Link, Heathrow Terminal
5 and Amsterdam Noord/Zuidlijn, an
EPSRC study examining the benefits
of 3D presentation of monitoring
results and as a Member of the British
Tunnelling Society Subcommittee
producing “Monitoring Underground
Construction: a best practice guide.”
Historic Context
At the outset, virtually all monitoring
software was custom-made for
each project, with Excel a favoured
data visualisation tool. Since then
proprietary software has become more
commonplace. However, some clients
will require monitoring visualisation
software to be incorporated with their
own systems, and that increasingly
means within a corporate Geographic
Information System (GIS).
Client Decisions
Data handling responsibilities must be
clearly determined at an early stage.
For example, does the monitoring
contractor merely provide the data,
with responsibility only for verifying
that it is correct, or do they also provide
a visualisation package and analysis
services? If a client chooses to split
these roles, does the client have the
capability of ensuring that mitigation
actions can be directed accordingly?
This decision will fundamentally direct
what is required.
Table 1 indicates some fundamental
decisions which need to be made.
Interface
How comprehensive an interface is
required? Is 3D visualisation required
and the added complexity this can
involve appreciated?
Systems are usually graphical, indi-
cating the locations being considered,
for easy assimilation.
Is a comparison of different instru-
ment types within the same graphical
output possible, for example compari-
sons between borehole extensometer
readings at surface and related precise
levelling can be instructive in deter-
mining where problems lie?
Is the system sufficiently flexible to
allow selection of particular locations
for comparison purposes, which have
not been pre-determined?
Can the data be viewed in different
graphing formats? For example incli-
nometer readings are often displayed
in a “tail-wagging” form but for exam-
ining data against time, but it may be
more useful to determine trends on a
movement versus time graph, at a par-
ticular level.
Response Times
What is the time delay from collection,
through import, to use being made
within the visualisation software?
This may be a project-wide standard
frequency, but more frequent at
focused locations (if required) without
compromising more global frequencies
elsewhere.
Does an increase in the data held
slow down response times, which then
make ease of archiving and re-import
(if required) a consideration? Times-
cale issues are covered in Tables 2 & 3.
Alarm Raising Functionality
Assuming that the monitoring office
will not be staffed 24/7, the system
will need to provide notification of
trigger limit (response level) breaches
or potential trigger level breaches to
an on-call monitoring engineer. This
could be provided by SMS text, e-mail
(Blackberry), or a digitised voice over
a mobile phone. Consider how reliable
each of these communication routes is
at the project location, before fixing
on one. There need to be escalation
capabilities if the initial contact does
not respond within the requisite time
scale. How does the software escalate
the alarm raising? The alarm message
is more meaningful if it gives specific
location where the breach is taking
place, the breach level which is
occurring (Red/Amber) (or predicted
to occur within a certain time), the
current value and the previous value
plus the times at which these details
were recorded.
Instrumentation Types
Does the system handle all the
instrumentation systems envisaged and
is there the capability to incorporate
additional instrumentation types or at
Table 1. Access requirements to monitoring data
Category
Considerations
Viewing
Who needs to view the data and for what purpose? Is only
local access (from within one office or network) needed or is
remote access, possibly via the Internet, also required?
Are multiple or limited simultaneous accesses by the various
parties required? There may be a performance hit in terms of
system response from multiple simultaneous accesses.
Access
Limitations
Consider the access limitations to be put in place and related
security considerations for each user. This could be from a
Full Administrator Read and Write capabilities (including
ability to add or remove access to/from others) through to
Read Only which, in itself, could be Read Only full access to
data for the main project team or partial access only for third
parties.
Maintenance
Is it possible for an on-call engineer to access remotely
and respond to alarms raised, without needing to attend
the monitoring office? It should be possible for limited
provision, even if general viewing of results by the team is
not planned.
1...,16,17,18,19,20,21,22,23,24,25 27,28,29,30,31,32,33,34,35,36,...68
Powered by FlippingBook