Structural and Geotechnical Monitoring Software: Who Sees the Amber Trigger at 2am, and What Happens Next?

The weekly report is a record of what you failed to act on

A deep basement excavation is running next to a Victorian terrace and eleven metres from a live rail tunnel. There are prisms on the terrace facades read by an automated total station, MEMS tiltmeters on the party walls, vibrating wire piezometers in the surrounding ground, crack gauges across existing damage, and precise levelling points along the track. Four suppliers, four portals, four sets of credentials, four alarm configurations.

On a Tuesday the monitoring engineer opens the weekly report and sees that a tiltmeter on the north party wall crossed amber the previous Thursday. Five days have passed. Two more excavation stages have been dug in that time. The conversation that follows with the asset protection engineer is not about the reading, it is about why nobody called, and the answer, that the alarm went to an email address on a supplier portal that a departed engineer configured, is not an answer anybody accepts.

Trigger levels exist because a third party agreed to let you excavate next to their asset on conditions. Breaching amber means an agreed response. Breaching red usually means the works stop and somebody senior explains themselves. The monitoring system is therefore not a data collection exercise. It is the mechanism that proves you were watching and that you did what you promised when something moved.

Problem 1: four suppliers, four portals, no single truth

Worldsensing, Senceive and similar suppliers do a genuinely good job of the hard physical part: rugged wireless nodes, long battery life, gateways that survive a construction site. Trimble 4D Control is strong on the geodetic side with automated total stations. Each ships with a platform. None of them is designed to be the single truth for a site where three other suppliers are also installed.

So the monitoring engineer builds the joined view by hand, usually in Excel, weekly. That single fact explains the five day delay in the story above. There is no combined view in real time because assembling one is a person's job, and people work Monday to Friday while ground movement does not.

A build starts with ingestion adapters per supplier and a normalised reading model: instrument, channel, timestamp in a single timezone convention, raw value, corrected value, applied corrections, baseline reference and quality flag. Getting that model right is most of the project. Everything downstream, the triggers, the reports, the correlation, is straightforward once every reading from every supplier means the same thing.

Problem 2: real trigger regimes are not thresholds

People outside the discipline assume a trigger level is a number. In an asset protection agreement it usually is not. It may be cumulative movement since a defined baseline, plus a separate rate of change over 24 hours, plus a different set of values for a different construction stage, plus a distinction between movement toward and away from the asset. Different assets on the same site carry different regimes because they were negotiated with different owners at different times.

Baselines are their own complication. A baseline is established over a period before works start, and it may legitimately be reset after a defined event, for example after a preloading stage or after an instrument is reinstalled. Every reset must be recorded with its justification, because an asset owner reviewing the record later will ask why a baseline moved and a satisfactory answer needs to have existed at the time rather than been constructed afterwards.

A configurable trigger engine is the core of the build: rules per instrument or group, per stage, combining absolute, cumulative and rate based conditions, with an audit trail on every change to a rule. Supplier platforms offer thresholds. Thresholds are a fraction of what your agreements actually say.

Problem 3: false alarms are the real failure mode

The way monitoring systems fail is not that they miss a movement. It is that they cry wolf until people mute them. Total station readings drift with temperature and refraction. A prism gets obstructed by a scaffold lift and reports nonsense. A tiltmeter bumped by a plant operator produces a step change that looks alarming and means nothing. A gateway loses power and the last stored reading repeats.

So data quality has to sit between ingestion and alarming, not after it. Range checks, rate of change plausibility against physics, cross checks against neighbouring instruments that ought to move together, reference and backsight stability checks on total stations, and gap detection. A reading that fails quality checks raises an instrument health alert rather than a movement alarm, and those two things must never appear in the same queue.

Silence deserves its own alarm, and it is the one most often missed. An instrument that has not reported for six hours is a problem, and a system that only alarms on values will happily stay quiet while half your array is dead. In our builds the comms watchdog is usually the first feature that earns trust from the monitoring team, because it makes the invisible failure visible.

Problem 4: escalation is a phone tree in somebody's memory

An amber breach has an agreed response. Often that response is a trigger action response plan negotiated with the asset owner: notify named people within a stated time, increase reading frequency, inspect the asset visually, and in some cases pause a specific construction activity. Red has a stronger version.

In most operations that plan lives in a document, and its execution depends on somebody reading an email. What a build does is turn it into an executable sequence. The alarm has a named owner and a deputy, a required acknowledgement within a defined period, automatic escalation up a chain if acknowledgement does not come, an SMS or voice path rather than email alone for red, the response actions as a checklist with timestamps, and a record of who did what and when. That record is the evidence pack. Assembled automatically at the time, it takes minutes to produce. Assembled afterwards from emails, it takes a week and it looks exactly like what it is.

Problem 5: movement without context is an argument, not a finding

The question after every trigger breach is what caused it. Was it the excavation stage that opened on Monday, the dewatering that started at the same time, a heavy rainfall event, a thermal cycle, or nothing to do with your works at all. Without construction activity in the same system the answer is a meeting.

The high value feature, and the one supplier platforms will never build, is overlaying your own works onto the monitoring record. Excavation stage changes, pile installation, dewatering rates, prop installation and removal, and significant plant movements, timestamped and shown against the instrument traces. A monitoring engineer who can say that the step change on tiltmeter 14 coincides precisely with prop removal at grid line C, and that the response settled within the predicted envelope, is having a completely different conversation with the asset owner than one presenting a graph with no context.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, the honest shape is as follows. A first release covering multi vendor ingestion, the normalised reading model with baselines and corrections, the configurable trigger engine, data quality checks with a comms watchdog, and escalation with acknowledgement runs $70,000 to $150,000 and ships in 12 to 18 weeks. A full platform adding construction activity correlation, automated reporting in each asset owner's expected format, portfolio views across projects, and instrument lifecycle management runs $180,000 to $450,000 over 6 to 12 months.

What drives the number up in monitoring specifically: the count of supplier integrations, since each protocol, API and file format is real work and some suppliers are more cooperative than others. Automated total station data, which brings geodetic corrections and reference stability handling that is a discipline of its own. Reporting formats, because each asset owner wants their own layout and several still want a signed PDF. Alarm delivery paths beyond email, particularly voice escalation with confirmed delivery. And high frequency instruments such as vibration or continuous strain, which change the storage and query design.

What keeps it down: one site, the instruments already installed, and the trigger regimes for the two assets that actually matter. Portfolio views can wait until the first site is trusted.

Build versus buy, and when buying is right

Buy if you have a single supplier on a single site. Worldsensing and Senceive platforms are perfectly adequate when everything on site is theirs, and their alarm handling covers a straightforward threshold regime. Trimble 4D Control is the right answer where the array is predominantly geodetic. Adding a bespoke layer over one supplier's estate is rarely worth it.

Build when two or more of these are true. Instruments come from several suppliers and no portal shows the whole picture. Your trigger regimes are negotiated per asset owner and involve cumulative and rate based conditions rather than simple thresholds. You run a programme of sites and want consistent regimes, consistent reporting and portfolio oversight. You need construction activity overlaid on the readings, which nobody else will do for you. Or you are the party carrying the risk under an asset protection agreement and you want the evidence chain under your own control rather than in a supplier's tenant.

How to choose a developer for monitoring software

Ask them how they would distinguish a genuine movement from an obstructed prism. If they have no answer beyond an outlier filter, they will build a system your engineers mute within a month, and a muted system is worse than no system because it creates the appearance of vigilance.

Ask how a baseline reset is recorded and who is allowed to do it. This is the question an asset owner's engineer will ask you eventually, and the system needs to have had a good answer at the time.

Ask what happens when a gateway goes offline overnight, and whether silence raises an alarm. Then ask how alarms are delivered when someone does not acknowledge at 2am.

Ask about timezones and daylight saving explicitly, because correlating a reading against a construction event an hour out is the kind of error that discredits an entire dataset. And settle code ownership before kickoff: you should hold the repository, the infrastructure accounts and the right to bring in another firm. At Digital Heroes the client owns the code from the first commit, which on data that may be examined in a claim years later is a control question rather than a preference.