Structural Monitoring Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does the trigger regime get underscoped so often?

Most monitoring software is specified by someone who assumes a trigger level is a number. Green below, amber above, red above that. Every supplier platform is built on that assumption, so it appears in requirements documents unchallenged, and the build gets priced against it.

Real asset protection agreements are not written that way. A regime commonly combines cumulative movement since a defined baseline, a separate rate of change over a stated period such as 24 hours, different values per construction stage, and sometimes direction sensitivity relative to the asset being protected. Different assets on the same site carry different regimes because they were negotiated with different owners at different times, and the tunnel operator's terms will not match the terms agreed with the owner of the Victorian terrace.

The failure is discovered late and it is discovered by an engineer, not by a tester. The system reports green while cumulative movement since the pre works baseline has quietly crossed the level your agreement actually defines, and the first person to notice is reading the weekly report.

Scope it properly by taking the two agreements that carry your real risk into the first design session and reading the trigger clauses out loud. Ask the supplier to model those exact regimes, including the stage dependent values, before anything is priced. Insist that rules are configurable data with an audit trail on every change, because the regime is contractual and a changed threshold is a changed obligation. If a proposal offers thresholds per instrument and nothing else, it is describing a supplier platform you could have had for free.

What goes wrong when baselines and historic readings are migrated?

Migration in monitoring is not the volume problem people expect. It is a meaning problem, and it makes historic data either usable as evidence or not.

Three things go wrong. First, timezone and daylight saving. Supplier platforms store timestamps differently, some in local time, some in coordinated universal time, some in local time without recording which offset applied. Correlating a reading against a construction event an hour out discredits the whole dataset, and it is the kind of error that only becomes visible when a third party engineer examines the record during a claim. Second, corrections. A raw reading, a corrected reading and the corrections that were applied are three different things, and a migration that carries only one of them destroys your ability to explain a value later. Third, baselines. A baseline is established over a period before works start and may legitimately be reset after a defined event such as a preloading stage or an instrument reinstallation. Historic baseline resets are frequently undocumented, so migrated data shows a discontinuity nobody can justify.

The fix is a normalised reading model that carries instrument, channel, timestamp in one explicit convention, raw value, corrected value, the corrections applied, the baseline reference and a quality flag. Migrate into that model rather than into a table of values. Where a historic baseline reset has no recorded justification, record that it has none rather than inventing one, because an honest gap in the record is defensible and a reconstructed explanation is not.

Why do the multi vendor sensor integrations break after launch?

The whole point of a custom monitoring build is that instruments come from several suppliers and no portal shows the whole picture. That also means you have taken on several integrations that will each decay in their own way.

Wireless node platforms change their application programming interface between releases. File based deliveries from an automated total station arrive with a renamed column after a survey contractor updates their software. A gateway loses power and the last stored reading repeats, which looks like a perfectly stable instrument. A prism gets obstructed by a scaffold lift and reports nonsense that is inside the plausible range. And when a supplier is replaced mid project, which happens, the new feed arrives with different units and nobody converts them.

All of these are silent. None of them raises an error in a system built to react to values.

Build three things and the category largely goes away. A comms watchdog that alarms when an instrument has not reported within its expected interval, which in our builds is usually the first feature that earns the monitoring team's trust because it makes an invisible failure visible. A quality layer between ingestion and alarming, running range checks, physical plausibility on rate of change, cross checks against neighbouring instruments that ought to move together, and reference and backsight stability checks on total stations. And a strict rule that readings failing quality checks raise an instrument health alert in a separate queue from movement alarms. Mixing those two queues is exactly how engineers learn to mute everything.

What happens when escalation and evidence duties are not covered?

An amber breach has an agreed response, usually written into 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, and it usually stops work.

Builds that stop at alerting deliver an email and consider the requirement met. That fails in two ways. It fails at 2am, when nobody reads the email and there is no path that escalates past a person who is asleep. And it fails afterwards, when the asset owner asks you to demonstrate that the agreed response happened, and the evidence has to be assembled from email archaeology a week later, at which point it looks exactly like what it is.

Make the response plan executable rather than documentary. Each alarm gets a named owner and a deputy, a required acknowledgement within a defined period, automatic escalation up a chain when acknowledgement does not arrive, and a delivery path beyond email for red level events, meaning short message service or voice with confirmed delivery. The response actions become a timestamped checklist. The evidence pack then assembles itself at the time, which takes minutes to produce and is contemporaneous, which is the property that matters if it is ever examined in a claim years later.

Should you build custom or configure what you already own?

If everything on your site comes from one supplier and your trigger regime really is a simple threshold, use their platform and spend the money elsewhere. Worldsensing and Senceive do the hard physical part genuinely well, with rugged wireless nodes, long battery life and gateways that survive a construction site, and their alarm handling covers a straightforward regime adequately. Adding a bespoke layer over one supplier's estate is rarely worth what it costs.

Where the array is predominantly geodetic, Trimble 4D Control is the right answer and a build will struggle to match its handling of automated total station data, because geodetic corrections and reference stability are a discipline of their own.

The build case is specific. Instruments from several suppliers with no single view. Trigger regimes that combine cumulative and rate based conditions negotiated per asset owner. A programme of sites where you want consistent regimes and consistent reporting rather than a different arrangement per contract. A need to overlay your own construction activity onto the readings, which no supplier will build for you because it requires your works data rather than theirs. Or the simple fact that you carry the risk under the asset protection agreement and want the evidence chain in your own control rather than in a supplier's tenant. Before committing, ask your current supplier to configure one of your real regimes with a stage dependent cumulative rule. Their answer will settle the question faster than any comparison document.

How do hidden costs get into the quote?

Five things routinely sit outside a monitoring quote and inside the real project. The count of supplier integrations, since each protocol, interface and file format is genuinely separate work and some suppliers are considerably more cooperative than others. Ask which suppliers are in scope by name.

Second, automated total station data, which brings geodetic corrections and reference stability handling that is a specialism, not an extra feed. Third, reporting formats, because each asset owner wants their own layout and several still want a signed document rather than a dashboard link, so reporting can quietly become a larger workstream than alarming. Fourth, alarm delivery paths beyond email, particularly voice escalation with confirmed delivery, which brings a third party service, cost per message and a failure mode of its own. Fifth, high frequency instruments such as vibration or continuous strain, which change the storage and query design rather than adding to it.

Defend against all five with a written exclusion list on a fixed first release. Name the suppliers, name the report formats, and state whether voice escalation is included. A quote with no exclusions has not been thought about.

What separates a monitoring build that works from one that fails?

The builds that work are deployed in stages. Ingest and display first, then the quality layer, then alarming once the monitoring team trusts what they are seeing. The builds that fail switch alarming on at go live, so the team's first experience of the system is a false positive at 3am caused by an obstructed prism, and trust never recovers. That sequencing decision costs nothing and determines the outcome more than any technical choice in the project.

The second differentiator is whether construction activity reaches the system. Excavation stage changes, pile installation, dewatering rates, prop installation and removal, timestamped against the instrument traces. A monitoring engineer who can attribute a step change to prop removal at a specific grid line, and show the response settling within the predicted envelope, is having a different conversation with the asset owner than one presenting a graph with no context. It is the highest value feature in the category and the one most often deferred.

The third is control of the record. You should hold the repository, the cloud accounts and the unrestricted right to bring in another firm, agreed before kickoff rather than at handover. Monitoring data can become evidence in a third party claim long after the works finish, so where it lives and who can alter it is a risk decision rather than a procurement preference.