Geotechnical News December 2010
27
Geotechnical Instrumentation News
least store output from other packages
within the monitoring database? For
example railway track monitoring
vehicles may be used as part of a
monitoring system and derivation of
data from such a specialist system may
be beyond generic monitoring software
systems, but the ability to make a link to
the data at relevant site locations is all
part of the necessary data assimilation/
review process.
Other Functionality
In addition to viewing monitoring
results for trigger limit (response
value) breaches, there should be clear
demonstration of both instrument
and reading availability (where these
fundamentally differ) to allow effective
maintenance targeting. For example,
a robotic total station (RTS) takes
readings from a number of monitored
prisms. The loss of an RTS will result
in a total loss of readings for all those
prisms. Alternatively local line-of-
sight issues (RTS to prism) will result
in some prisms not being read. The
database software should be capable of
this discrimination, thereby assisting in
maintenance operations.
There should be an ability to anno-
tate the information held. For example
maintenance work may affect readings
at a certain location. Whilst the team
may be aware of the reason at that time,
two years later researching the history
becomes more difficult if that informa-
tion is not readily available.
The capability to include other rel-
evant information, such as reference
photographs and details of construction
progress may be required.
Ability to compare information be-
tween primary and secondary instru-
mentation systems may be required.
Is the ability to be able to compen-
sate for pre-construction movements
important?
How is the software segmented op-
erationally? Does a problem with data
collection overspill onto visualisation,
effectively locking the system up?
Is the system sufficiently scaleable
to encompass requirements at all moni-
toring stages? A monitoring database
sufficient to provide access to data dur-
ing pre-construction monitoring may
not meet the full project-wide system
requirements during the construction
phase. This could be in terms of lo-
cations being monitored, instruments
being used or user access require-
ments. Any such limitations should
be appreciated at commencement of
pre-construction monitoring, and not
discovered part-way though construc-
tion. Some specific data management
considerations are covered in Table 4.
Output
Generally outputs are graphical in order
to aid review, but data in a numeric
form often needs to be available for
evaluation outside the main monitoring
package. This can be provided with
an export facility to Excel and other
statistical and analysis packages.
Conclusions
My apologies for the inevitable number
of questions rather than answers in this
Table 2. Project/data timescale issues - generic
Category
Considerations
Timescale
Over what timescales are the pre-construction,
construction and close-out monitoring to be performed,
and what use is to be made of that data after close-out
monitoring is completed?
Software
Updates for operating systems/monitoring software
etc. are likely to take place within a project timescale
and recognition taken of this need. For example, if
monitoring software is based on a proprietary GIS,
updates on the base GIS software may result in custom
routines needing to re-written.
Computer Hardware Developments may prevent use of earlier software.
Whilst old software may run very fast on newer operating
systems, it may not work at all.
File Format and
Storage Media
The data file format and means to read it over time are
important if long-term use is to be made. An example is
the NASA 1960 space shots where there are warehouses
of punched cards which no longer have the necessary
reading equipment. The AGS Data Format may prove
to the way forward, but be wary of proprietary formats
which may not be supported in future.
What storage media is to be used and will it need
updating over time? Over the last 20 years there have
been 8”, 5.25” & 3.5” [720kb, 1.44Mb, 120Mb]
floppy disks, Bernoulli drives, Zip drives, CD, DVD
[+R/-R/RW], as relatively common examples. Many
organisations would now have trouble reading a 5 ¼”
floppy. What provision (if any) is to be made for the
project data longer term?
Time/Date Format
Convention
A very simple point to indicate the importance of
convention is that the Time/Date format (as expressed
in output) should not be capable of confusion between
different countries. An example is date/month/year as
indicated in UK v US systems and in countries where
there is an hour change, from example Greenwich Mean
Time (GMT) to British Summer Time (BST) in the UK:
is it clear what is being viewed? How are the 23:00,
00:00 and 01:00 GMT readings indicated in a system
which shows BST readings?
