SESSION III: SOFTWARE FOR DEFORMATION DATA COLLECTION, PROCESSING, AND ANALYSIS

MODERN MONITORING SYSTEM SOFTWARE DEVELOPMENT

Karl Sippel

Business Area Software Solutions, Leica Geosystems AG

CH-9435 Heerbrugg, Switzerland; E-MAIL: Karl.Sippel@Leica-Geosystems.com

Abstract

The expectation of modern monitoring solutions requires more and more sophistication
from the monitoring software. With the use of motorized Total Stations or GPS it has
been possible for some time to automate monitoring measurements, but the software has
typically been restricted to collection of measurements. Limited emphasis has been
placed on the integration of data processing or analysis. Leica Geosystems AG is
developing a Geodetic Monitoring System, GeoMoS, using modern software technology
with a scalable and configurable architecture. GeoMoS is a system solution, built from
the ground up and based on years of monitoring software experience. The system uses
the latest messaging technology based on TCP/IP and Microsoft Message Queue for
secure data transmission between clients and servers and can be remotely accessed and
configured. Sensor connections are handled by a Sensor Manager component and include
TPS, GPS, meteorological sensors and geotechnical sensors (e.g. extensiometers). An
integrated computation component can be linked with a powerful event/messaging
management system so that displacements can be calculated and analyzed in real time and
messages can be sent via SMS, E-mail, Pager or Digital I/O interfaces. A powerful
Analyzer Toolbox allows the numerical and graphical visualization of results and
measurements. The results can be edited and post-processed over the data history. The
software components and architecture are presented along with two customer case
studies. The first example is one of the largest open-cut coalmines in the world situated
in Hambach, Germany. The second is a dam monitoring project in Switzerland above the
longest and deepest tunnel construction project in the world.

1. Introduction

As a surveying instrument manufacturer, Leica Geosystems AG, has been involved in

monitoring projects for many years. Since the introduction of motorized theodolites in
the late 1980’s there has also been considerable development of computer software to
control these motorized instruments for automatic measurements to remove the mundane
tasks of manual measuring the same points repeatedly at specified intervals. As these
automatic systems developed it has become very easy and cost effective to set up
automatic measurement schedules to measure large numbers of points at regular intervals.
This process removes the mundane task of manual measurements but typically the
customer ends up with a large amount of data to analyze. Currently available monitoring
software systems are generally inadequate with respect to the analysis software that is, or
can be, integrated and the different types of sensors that can be connected to the systems.
This initially occurs because the software is usually designed and developed from an
individual customer point of view that does not satisfy general customer needs. The
software is usually not designed with an open architecture that allows the easy integration
of specific customer requirements with regard to analytical computations and analysis.
Furthermore, the software is usually developed for a specific sensor and is not open to
adding additional sensors without rewriting part of the software. Leica Geosystems AG,

88 The 10th FIG International Symposium on Deformation Measurements

MODERN MONITORING SYSTEM SOFTWARE DEVELOPMENT

currently offers a popular monitoring software, APSWin, which is often limited by these
three drawbacks. The software technology of the past proves, today, to be limited in
terms of expansion for the new generation. For this reason, Leica Geosystems AG is
looking towards the future of the monitoring software market. It is not possible to build
an off-the-shelf monitoring software product that can satisfy 100% of the customers’
needs. What Leica can offer is a scalable and flexible base product that can be easily
customized to satisfy 100% of customers’ needs. With this concept in mind, and a wealth
of monitoring experience and customer requirements, the goal was to design a Geodetic
Monitoring System, GeoMoS, where the customer has the flexibility to configure the
monitoring software to suit their requirements. The GeoMoS product is developed in
Microsoft C++ using the latest technology from Microsoft Component Object Model
(COM), Microsoft Message Queue (MSMQ) with TCP/IP and Remote Server Access
(RSA). The product is also based on new generation ESRI survey database technology
that is being developed jointly by ESRI and Leica Geosystems AG.

2. Software Design Models

The development of software at Leica Geosystems AG is based on software modeling

techniques and notation outlined by Rational Unified Process, RUP (Quatrani, T. (1998))
and Unified Modeling Language, UML (Booch, G., Jacobson, I. & Rumbaugh, J. (1999);
Fowler, M. & Scott, K. (1997)). In a very short summary, these techniques outline
process, notation and guidelines of how to develop software with minimal risk. One of
the biggest risks of software development, today, as making sure the project is completed,
on time, and satisfies the customers’ needs. Leica Geosystems AG, employs ideas and
concepts based on the UML notation and uses processes such as RUP to document the
software development. It is not the intention of this paper to recite the theories and
concepts of these models, but they are reflected throughout the paper in the way that
GeoMoS was designed and developed. It is always necessary to deviate slightly from
theoretical models so that is fits to the practical situation. These models, however, allow
for some flexibility. Further information on UML and RUP can found in books and
documentation references for UML and RUP given above.

3. Total Project Time Schedule

A project plan was drawn up including separate tasks for the design, prototyping, source
code development and testing. Including the design and prototyping in the development
plan was an important factor to emphasise the importance of these steps in the product
development. Approximately one third of the project duration was distributed between
the three phases of design, prototyping and source code development. The total project
time planned for GeoMoS was approximately 15 months. The 15 months covers the time
from when the project was first conceived to the release of the software to the customer.
More than 30 % of the development effort has been spent on testing and quality assurance
activities. Because of the limited time, it was critical that the project planning was as
accurate as possible. It would not have been possible to complete the project in such a
short time without proper project planning.

4. Where to Start - Software Design Requirements

Leica Geosystems AG has a wealth of monitoring experience from the existing APSWin
product and the extensive experience supporting existing customers as well as high

19 – 22 March 2001 Orange, California, USA 89

SESSION III: SOFTWARE FOR DEFORMATION DATA COLLECTION, PROCESSING, AND ANALYSIS

expertise in software development. The customer interaction was an integral part of the
development of GeoMoS. The close co-operation and interaction of key customers has
assisted greatly in the design and development of the product.. The initial approach to the
software design was to ask the customers to define a list of requirements. This task
resulted in an 80 page document listing all the features the customers required. The
development team then reviewed this document, clarified uncertainties and formed a plan
for the project. This process was a cyclic operation where constant reviews by the
customer and development team ensured that the requirements still satisfied the
customer’s original intention. After the completion of the project plan and the
requirements document this then became the defined agreement between the customers
and Leica Geosystems AG.

The software requirements were collected from 2 main key customers and included also
Leica Geosystems AG own monitoring and APSWin experience. A summary of the main
requirements that were obtained from these three sources are as follows.

4.1 RWE Rheinbraun AG Requirements

In the development of the GeoMoS software Leica Geosystems AG worked closely with
the company RWE Rheinbraun AG, located in Hambach, near Cologne, Germany. For
this project, GeoMoS is configured as a large system. It is one of the biggest open cut
coalmines in the world covering an area of over 20 sq. km to a depth of 650 metres. The
system for Rheinbraun requires a large multi-station monitoring system. It was ideal to
have this system in the design phase to ensure the system had the scalability to be
configured as a small or large system. Some of the main Rheinbraun features are listed
below.

• Large Database Support

• Long term database storage and archiving (>15 years)
• Specialized filtering mechanisms for computations and analysis
• Client/Server architecture with multiple connection media (e.g. radio link, cable)
• Remote control of Client software via Server or modem connection.
• Fast measurement capacity (1 TPS measurement/10sec. per station)
• Long Distance Measure up to 3000 metres.

4.2 Leica Geosystems AG Requirements

The development of large system software is expensive. It was important for Leica to
satisfy the customer, but also look ahead with the vision that GeoMoS was the new
generation software for monitoring. For this reason the design was approached in a way
to make it flexible and configurable for our customers’ needs, keeping in mind that not all
Leica customers want to have the same system. Some customers need a small system and
some need a large system, depending on the size of their project. Some of Leica’s
requirements were as follows.

• Customizability of the sensors

• Software must be maintainable and expandable for future needs
• Computations and Analysis must allow the user or Leica to build in their own
components without rebuilding the product

90 The 10th FIG International Symposium on Deformation Measurements

MODERN MONITORING SYSTEM SOFTWARE DEVELOPMENT

• Graphics must be user definable and open in design

• The GeoMoS software must be scalable so that it can be configured for small and
large monitoring projects.

4.3 Swissphoto AG Requirements

During the development of the prototypes a second key customer became involved in the
GeoMoS project. The Swiss firm Swissphoto AG required GeoMoS to monitor concrete
dams in the Swiss alps. The dams are situated in the Swiss alps near Chur in eastern
Switzerland and are being monitored as part of a engineering project where a 58
kilometre railway tunnel is being built between Zürich to Lugano in Switzerland. The
tunnel runs directly beneath 3 dams that must be monitored during and after the tunnel
construction. The first stage of this project involves monitoring one of the three dams in
a remote valley. Of particular interest in this project is the combined use of TPS sensors,
atmospheric sensors, extensiometer sensors and eventually GPS to monitor the dam wall
and surrounding valley. Because of the inaccessibility of the monitoring station in the
rugged alpine terrain, especially in winter months, it is also vital that the monitoring
station can be remotely configured. Many of the requirements requested where already
included in the GeoMoS design. The following are a few of the main requirements
requested for the software.

• Remote control of client station due to inaccessibility

• Integration of extensiometers into the GeoMoS product
• Integrated GPS sensors for monitoring

5. Prototyping

One of the important early steps in the development process was the prototyping.
Prototypes were developed in Microsoft Visual Basic. Only the user interface was
realized with no underlying functionality. The advantage of using Visual Basic was that
is was very quick to create user interface views and dialogs and it was not a language that
was being used directly in the development of the product. Therefore there was no risk of
using any of the prototype code in the actual development. Prototypes, with their
unstructured design and source code, have a habit of being developed into final products,
usually because of time pressure from management. Using a different language avoids
this scenario.

The main purpose of the prototyping is to confirm and develop the requirements and
wishes in a visual way. A prototype not only allows the customer to get a feeling for the
end product design, but also allows ideas to develop about the product design. Not just
from the interface design but also how the interface ultimately interacts with the
underlying components, such as the database, computations and messaging.

The procedure of collecting the customer requirements, APSWin requirements and

experience and prototyping can be summarized in the cyclic Diagram 1.0. This was the
first cycle of the development process that lasted at least 5 to 6 months before any line of
source code was actually written.

Because the first step of the development process was cyclic as shown in Figure 1.0, the
requirements from the second key customer, Swissphoto, could be easily incorporated

19 – 22 March 2001 Orange, California, USA 91

SESSION III: SOFTWARE FOR DEFORMATION DATA COLLECTION, PROCESSING, AND ANALYSIS

into the initial design. It was also very intuitive for the customer to see the first stages of
the prototype. They could see exactly what was being developed and could easily see that
GeoMoS was the suitable product for their project.

Figure 1.0 : The first process of design did not included source code development of the
final product. Many cycles through customer input, APSWin knowledge and experience
and prototyping were completed over several months before any source code
development was started.

6. Underlying Concept

The basic design concept of GeoMoS was to build a flexible system that could be pieced
together from basic components depending on the purpose of the monitoring project. The
expertise from the customer and Leica was assessed. The first step was to evaluate the
experience and knowledge Leica had in-house.

Leica Geosystems AG experience and knowledge

• Expert software development teams
• Knowledge of software design in the latest technologies
• Knowledge of overall market requirements
• APSWin experience and knowledge

Customer expertise is high in

• Practical knowledge of data collection
• Practical and theoretical knowledge of data computations
• Practical and theoretical knowledge of data display and analysis

Rheinbraun’s requirements were specific to their particular problems but also Leica used
their own knowledge and knowledge of other customers’ requirements to generalize the
design. This does not mean that the design was restricted, but on the contrary the design
was made extremely open to accommodate future possibilities other customers may
require.

92 The 10th FIG International Symposium on Deformation Measurements

MODERN MONITORING SYSTEM SOFTWARE DEVELOPMENT

Some of the main areas where the design was made flexible were in the computations,
graphical analysis, connections to sensors and the Client/Server configuration possibilities
of the system. In reality, every customer has a different monitoring problem and has
different ways to solve these problems. However, there are some “standards” that people
have come to use in monitoring, usually acquired through experience, that were packaged
together in the GeoMoS system as tools. These basis elements include such things as

• Collection of measurements from various types of sensors

• Independent solution of Station coordinates using techniques such as Free Station and
GPS coordinates to control station movements within the active monitoring zone.
• Reduction of TPS measurements for atmospheric conditions
• Customizable graphical display of results
• Analytical computations of results
• Data snooping and outlier detection

7. Scalability

The GeoMoS system can be set up as a Client/Server architecture for larger systems or as
a single workstation computer for small systems. It is scalable depending on the size of
the project. The GeoMoS system comprises of two main applications called Monitor and
Analyzer. The Monitor is the online application responsible for the sensor control and
collection of data and event and alarm activation. The Analyzer is the offline application
for the analysis and visualization of the data. Both applications can be run from
anywhere on the Client/Server network, or from a single workstation computer. Because
of the communication technology used for exchanging data between the system
components the GeoMoS software also goes beyond being just a Client/Server system.
This is discussed further in section 12, Connectivity.

TPS

GPS

Any
Device

Environmental/ GeoMoS GeoMoS GeoMoS

Geotechnical Workstation Analyzer Server
Sensors

Figure 2.0 : An example of a medium to large scale system configuration showing a

GeoMoS Workstation, collecting data from several types of sensors, which is connected
to a network server. The data can be viewed or analyzed with GeoMoS Analyzer from
any network connection.

19 – 22 March 2001 Orange, California, USA 93

SESSION III: SOFTWARE FOR DEFORMATION DATA COLLECTION, PROCESSING, AND ANALYSIS

The system configuration shown in Figure 2.0 has the client configured as the GeoMoS
Workstation, connected to the different sensors. Monitor runs on the GeoMoS
Workstation collecting the data from the sensors and calculating the results and also
transfers the data to the GeoMoS Server. The GeoMoS Analyzer can run anywhere a
connection is available. Consequently, it is possible to run GeoMoS Analyzer on the
GeoMoS Workstation or from the GeoMoS Server.

This is just one example setup for a medium to large-scale system. It would also be
possible to run the whole system with a GeoMoS Workstation and connected sensors.
The size of the monitoring project determines what size system is required. GeoMoS has
been designed with scalability in mind so that it can be configure for small or large
customer projects.

8. Computations

The design of the computations is based on the component architecture used throughout
GeoMoS. An essential criterion for the computations is the ability re-process the data at a
later stage. This quite often occurs when data has been edited and needs to be re-
calculated. For a computation to be re-computed, the information about which data is
used and how it is computed must be contained somewhere. The computation
information will be referred to here as the computation “intelligence”. In most software
the computation intelligence is contained within the application. In the GeoMoS design
the computations have been encapsulated in individual components containing the
intelligence (i.e. the information about the data and the algorithm that is used for the
computation). These computation components can be stored in the database, retrieved
and used by the application through a generic interface, but the application does not need
to know anything about the computation in order to use the component. The advantage is
that additional computation components can be added to the system without having to
change the process of how this computation interacts with the GeoMoS application. The
end result is it is possible to extend GeoMoS with additional computation components
that are customized for the user.

GeoMoS Application

Computation Object Computation Object

With Intelligence With Intelligence

Computation Computation
Mathematics Mathematics

Figure 3.0 : The GeoMoS computation schematic. The flexibility of the system is
enhanced by separating the computations into separate components.

94 The 10th FIG International Symposium on Deformation Measurements

MODERN MONITORING SYSTEM SOFTWARE DEVELOPMENT

The schematic of the computation design is shown in Figure 3.0. The mathematics of the
system can be also separated from the computation component to allow re-use of
mathematical algorithms in other components, but it is not required. The interface
between the computation object and the application is generic. Independent of the
computation type, the GeoMoS application can use every computation object in the same
way. The stored computation components can be recalled by the GeoMoS application
and re-calculated. The GeoMoS application must not know about the computation details
because that is held within the computation object. This design makes it possible to
process and post-process the data and also add additional computation components
without having the change the GeoMoS application. Clearly it makes the GeoMoS
software powerful and extendible for the future.

9. Graphical Toolbox

Incorporated in GeoMoS Analyzer is a toolbox where data and results can be visualized
graphically or numerically. Graphical representation of data is a very important part of
deformation analysis. A graphical plot can often show details and trends of deformation
better than numerical tables. GeoMoS Analyzer has standard graphic displays showing
displacement and velocity graphs against time and a displacement vector view. However,
customers have different requirements defining what they want to see or analyze. The
graphics in GeoMoS Analyzer can be customized in a number of ways, but the simplest
method is to define settings via a text file. Additional graphs can be integrated as a tab
view in the GeoMoS Analyzer application. The location of the data object in the database
and the value of the X-axis and Y-axis of the graph can be defined in the settings file, for
every additional graphic view. The GeoMoS Analyzer retrieves the relevant data from
the database and displays the graph accordingly. This option requires very little
expertise, other than knowing how to specify the location of the data in the setting file.

Figure 4.0 : GeoMoS Analyzer application showing the main graphic view. The view can
be customized, and additional tab views can be added, to show other data and result from
the database.

19 – 22 March 2001 Orange, California, USA 95

SESSION III: SOFTWARE FOR DEFORMATION DATA COLLECTION, PROCESSING, AND ANALYSIS

10. Database

GeoMoS is one of the first products to be built on a database technology being developed
jointly by ESRI and Leica Geosystems AG. The technology is independent of the
database that is actually used under this platform. It is possible to use Access, SQL
Server, or Oracle and is really a question of the size of data being stored. The GeoMoS
software is also capable of using a different database at the client and the server. For
example, the measured data and results can be configured to delete after several months
on the client where a Microsoft Access database can be used. On the Server a larger
Oracle or SQL Server database can be used. This keeps the database at the client
measurement stations small and efficient while the Server can be a larger system where
data is stored or archived over longer periods. The user can then make a choice about the
database depending on the amount of data that is being maintained. The database
technology is a key feature in the design of GeoMoS.

11. Sensor Manager

One of the strengths of the GeoMoS is the new Leica Sensor Manager component. This
is the component that handles the connections to various types of sensors. Monitoring
projects today require the software to connect to many different types of electronic
sensors and equipment. The goal of the Leica Sensor Manager is to enable virtually any
type of sensor to be connected to the application. The Leica Sensor Manager is a stand-
alone component that is one of the core features of the GeoMoS product. The Sensor
Manager takes the intelligence of sensor management out of the application itself. The
application communicates with Sensor Manager to find out what sensors are connected.
The application can send and receive data to and from the sensor without having to know
how to communicate directly with the sensor itself. The communication is done through
a generic Microsoft standard COM interface between the Sensor Manager and the
application.

Sensors are defined in Sensor Manager via an Extensible Markup Language, XML Script,
which is also a defined Microsoft standard. The XML file is a text file that defines the
protocol, commands, properties and configuration of the sensor. The schematic design
can be seen in Figure 5.0. Every sensor has its own XML file and is registered with the
Sensor Manager.
• Protocol – A sensor can be connected via an input/output port (e.g. serial, parallel or
TCP/IP). The protocol information for the connection can be defined in the XML file
(e.g. baud rate, parity, stop bits etc).
• Commands – The commands that the sensor understands are defined in the XML file.
• Properties – The properties of a sensor are the values that are returned when a
command is sent. The properties can be described in detail in the XML file. The
Sensor Manager re-organizes this data ready to send back to the application as a
generic format.
• Sensor Configuration – The settings and configuration of the sensor is also described
in the XML file. Depending on the sensor description it is possible to remotely
configure parameters of the sensor via a sensor properties dialog in the Sensor
Manager.

96 The 10th FIG International Symposium on Deformation Measurements

MODERN MONITORING SYSTEM SOFTWARE DEVELOPMENT

It is very easy to integrate additional sensors by defining the sensor description in an

XML file. As this requires only a definition of the sensor in a text format file there is no
programming required to integrate new sensors. It is possible to integrate a new sensor
into the system in less than a day. Once the XML file exists and is registered with the
Sensor Manager it can also work with the application. Data from the sensor is retrieved
through Sensor Manager and stored in the Database. The data from the Database can then
be retrieved from the Database and displayed or used in the analysis. This concept allows
various TPS Sensors, GPS Sensors, digital levels, atmospheric sensors, extensiometers,
tilt meters and other types of digital sensors to be integrated into the system.

Sensor Manager

Generic Protocol
SensorDriver Interpreter

I/O Channel
serial,parallel,TCP/IP

Figure 5.0 : Sensor Manager design showing interaction of the generic components. The
sensor information required for the communication is defined for each sensor in an XML
file. The interaction between the sensor and the application is always done via the Sensor
Manager providing a generic layer for integrating different types of sensors into an
application.

12. Connectivity

The communication between the GeoMoS hardware and software components runs over
an event channel using standard TCP/IP technology. TCP/IP is a standard
communication protocol often discussed in relation to the Internet although it is not
restricted to use on the Internet. The Internet has the advantage of being “platform/carrier
independent”. For GeoMoS the use of this technology means the communication
between individual software components and hardware components is independent of the
carrier. That means, the communication links can be established depending on the
localized requirements of the project. For the Rheinbraun project it is necessary to use a
radio link in one case connecting client and server and a cable in another. For the second

19 – 22 March 2001 Orange, California, USA 97

SESSION III: SOFTWARE FOR DEFORMATION DATA COLLECTION, PROCESSING, AND ANALYSIS

Swissphoto project in the Swiss alps, the connection can only be made via radio link due
to the remoteness of the measuring station.

The connections can be made using the following media.

• Cable
• Modem
• LAN
• WAN
• GSM
• Radio

The different connection methods allow total flexibility in how the system is configured.
In addition, the event channel is used for transferring information between software and
hardware components. That means it is possible to hook into the event channel with the
required security access and “listen to” or access the data going along the event channel.
This is useful to access the GeoMoS system remotely. Another example using the event
channel is a small application that hooks into the event channel and just checks that the
data transfer is active. If the data transfer stops a status message can be generated and
sent using email, SMS, Pager or other media. This is critical for continuously operating
systems.

13. What is The Future ?

The software is so flexible to expansion that it is ideally positioned for the future.
Modern software is often plagued by the fact that it is more or less out of date before it
even gets to market. GeoMoS it well placed for the future development and expansion
because of its modular architecture and the standard technologies that have been used in
the design of the software. Some of the fundamental technologies used in GeoMoS are
the same technologies being used in Internet applications. Although these technologies
are continuously developing, they also define standards that provide the basic building
blocks for many future applications.

Part of the expansions planned for the future products include extensions to computations,
graphical displays and specialized features. The intention is to build a customer database
of features that can be included in the product. Leica Geosystems cannot realistically
expect to implement all the possible features for the customer. Consequently, the
customers can extend the platform by implementing their own computations, graphics,
sensors, post-processing, etc. With this approach it is possible for the customers to add
value to the GeoMoS product and eventually offer these components to other users of
GeoMoS via a customer database and perhaps subsidize the development effort.

The current version of GeoMoS allows the integration of GPS sensors as a single
differential baseline position. The vision for future versions of GeoMoS is to include
GPS RTK network solutions. Leica Geosystems AG has one of the most stable and well-
established GPS processing packages on the market, which can be integrated as a
component of GeoMoS. The integration of GPS network solutions will strengthen the
software with the advantage of both TPS measurements and GPS measurements. The
advantage of TPS is the ability to economically and precisely measure many points, but
the disadvantage is that the monitoring station point is usually within the active zone of
the monitoring area. A GPS network solution complements that by bringing in

98 The 10th FIG International Symposium on Deformation Measurements

MODERN MONITORING SYSTEM SOFTWARE DEVELOPMENT

independent coordinate solutions from outside the active monitoring region. So, GPS can
be used to bring in control coordinates for reference points and TPS can measure other
monitoring points that normally cannot be measured with GPS. GeoMoS is not only well
positioned to take advantage of both TPS and GPS technologies, but also geotechnical
sensor technologies.

14. Conclusions

The development of the GeoMoS product had the ideal conditions. It involved customers
with excellent practical experience in monitoring projects, with stringent software
requirements. The combination of that experience combined with the software
development expertise at Leica Geosystems AG resulted in the development of a state-of-
art monitoring software solution. The software is designed to be expandable and flexible
to the users’ needs and offers the latest benefits that modern software technology has to
offer.

Prototyping is an extremely important aspect of software development. It strengthens the

customer relation by visually realizing the requirements between the customer and the
software development team. It also provides one of the most important aids in the
development of the product.

The new Leica Sensor Manager is one of the most powerful components in the GeoMoS
software. Modern monitoring systems must be able to connect to and read data from
different types of sensors and display the results for analysis. The Leica Sensor Manager
enables new sensors to be quickly integrated into GeoMoS. The data can be stored in the
database and extracted for analysis or visualized numerically or graphically.

The component architecture of the GeoMoS software and the use of known standards in
the Information Technology such as COM, XML, Microsoft Message Queue, (MSMQ),
and TCP/IP make the software extremely flexible and scalable. The software components
can be pieced together to build a system that ideally suits the customer’s needs, whether it
be a large or small system. Third party customers can also use GeoMoS as a base system
and integrate their own features into the GeoMoS system. The flexibility of the software
allows us to use the catch phrase “We solve the puzzle to suit your needs”.

Glossary

COM – Microsoft Component Object Model is a standard, widely-used component

technology.
TPS – Terrestrial Positioning System used to describe terrestrial based measurement
system such as theodolites.
GPS – Global Positioning System used to describe satellite navigation and positioning
systems.
XML – Extensible Markup Language is a formatted description language for defining
structured data.
TCP/IP – Transmission Control Protocol/Internet Protocol defines a standard for
connectivity between Internet Provider sites.
MSMQ – Microsoft Message Queue is technology using Microsoft Transaction
Server for sending and receiving message transactions across computer
connections.

19 – 22 March 2001 Orange, California, USA 99

SESSION III: SOFTWARE FOR DEFORMATION DATA COLLECTION, PROCESSING, AND ANALYSIS

References

Booch, G., Jacobson, I. & Rumbaugh, J. (1999). "The Unified Modeling Language User Guide". ”.
Addison-Wesley, Object Technology Series, ISBN 0-201-57168-4.

Fowler, M. & Scott, K. (1997), “UML Distilled. Applying the Standard, Object Modeling
Language”, Addison-Wesley, Object Technology Series, ISBN 0-201-32563-2.

Quatrani, T. (1998). “Visual Modeling with Rational Rose and UML”. Addison-Wesley, Object
Technology Series Booch, G., Jacobson, I. & Rumbaugh, J., ISBN 0-201-31016-3.

100 The 10th FIG International Symposium on Deformation Measurements