Dam and Levee Safety Monitoring Software: Getting a Threshold Crossing to the Engineer of Record Today

Why instrumentation data stops being useful at about eight structures

A dam safety engineer covers eleven structures across a river system: two concrete gravity dams with automated piezometers and a datalogger, six earth embankments where a technician reads standpipes and seepage weirs monthly with a water level meter and a clipboard, two levee reaches with survey monuments read twice a year, and one tailings facility on a different regulatory regime entirely. Data arrives as CSV exports from the loggers, photographed field sheets in an email thread, survey reports as PDFs from a consultant, and a piezometer spreadsheet maintained since 2009 that has three tabs nobody understands.

The engineer knows the structures. That is the reason the system works at all, and it is also the risk. The knowledge of which instrument runs high after rain, which one has been unreliable since a lightning strike, and which reading pattern would actually matter, lives in one person and in the margins of the old spreadsheet. When a reading crosses a threshold on a Tuesday, whether anyone acts depends on whether that engineer happens to open the file.

The consequences are not proportionate to the effort saved. Dam and levee failure is a mass casualty event, and the regulatory programs that mandate instrumentation exist because monitoring data is the early signal. Between that and a spreadsheet sits a data handling problem that nobody funds until an inspection finds it.

Problem 1: most of your instruments are read by a person, and the software assumes they are not

Automated instrumentation is the minority at most portfolios. Standpipe piezometers, weir plates, crack meters, alignment pins and observation wells are read by a technician on a walk, and the reading arrives as handwriting. Every monitoring product on the market is architected around telemetry from dataloggers, so manual readings are either typed in later by an engineer or kept in a separate spreadsheet, which means half the safety record lives outside the safety system.

Vista Data Vision does a genuinely good job of visualising and alarming on datalogger data, and if your portfolio is fully automated it deserves a look. Geokon and Campbell Scientific build excellent instruments and dataloggers, and their software is naturally organised around their own hardware, which is awkward across a portfolio assembled over four decades from several manufacturers. Worldsensing brings wireless sensing and a data layer on the same pattern. None of these is trying to be the dam safety program record, and that is the gap.

A custom build treats a reading as a reading regardless of origin. A field application on a phone or rugged tablet captures manual readings offline, with the previous value shown so the technician sees an implausible entry before leaving the site, photographs attached, and the reading posted the moment there is signal. Automated readings ingest on their own path. Both land in the same record with the same conversion, threshold and alerting treatment. Owners consistently report that the offline field capture is the feature that changes daily practice, because it removes the transcription step where errors and delays both live.

Problem 2: a fixed alarm limit is the wrong instrument for this job

A piezometer rising during a reservoir rise is normal. The same rise at steady pool after a dry month is the thing you built the instrument for. A fixed threshold cannot tell those apart, so it either alarms constantly during every high pool event and gets ignored, or it is set high enough to be quiet and misses the signal it exists to catch.

There is a second layer under this. The number that matters is not the raw reading. Vibrating wire piezometers need their calibration polynomial and temperature correction applied, barometric compensation matters for some installations, and everything has to resolve to a piezometric elevation against a surveyed reference. When those conversions live in three different spreadsheets with different reference datums, portfolio comparison is not possible and trend analysis is quietly wrong.

A custom build applies conversion once, at ingestion, from instrument metadata that is versioned, so a recalibrated sensor or a re-surveyed reference does not corrupt the historical series. Thresholds then become the engineer of record's instrument, held as data with an author, a date and a rationale, and revised through a controlled change rather than by editing a logger program. The version that earns its keep alarms on residual: expected piezometric response given current and recent pool level and recent rainfall, compared against measured, with the deviation as the trigger. That is the difference between an alert an engineer investigates and an alert an engineer mutes.

Problem 3: the periodic inspection report is assembled by hand every time

Whether your regulator is a federal energy commission requiring independent consultant inspections on a fixed cycle, a state dam safety office with its own format, or a mining authority operating under a tailings management standard, the deliverable is the same shape: a period of instrumentation data, plotted and interpreted, alongside inspection observations, maintenance history and the status of prior recommendations. Assembling it means pulling exports, rebuilding plots, and chasing which of last cycle's recommendations were actually closed.

Prior recommendations are the part that goes wrong most often. They are issued in a report, tracked in a spreadsheet or not at all, and the next inspection asks about every one of them. An owner who cannot show the closure evidence for a recommendation issued five years ago is having a much longer conversation than the data warranted.

A custom build makes recommendations tracked objects with owners, due dates, closure evidence and a link to the report that raised them. Plots are generated from the live record against the reporting period, with the instrument metadata and any data quality exclusions stated rather than silently applied. The report is still written by an engineer, as it must be, but the assembly stops consuming the weeks that should have gone into interpretation.

What a custom dam safety build has to include

• One reading model covering automated telemetry and manual field capture, with an offline-capable field application showing prior values at the point of entry.
• Versioned instrument metadata holding calibration constants, reference elevations, installation details and status, so conversions are applied once and history stays correct through recalibration.
• Thresholds as governed data owned by the engineer of record, with author, date, rationale and revision history rather than settings inside a datalogger program.
• Reservoir level and rainfall correlated expected behaviour, so alerting is based on deviation from expected response rather than on a fixed limit.
• Escalation that reaches a named person with an acknowledgement record, because an unacknowledged alert on a safety instrument is a finding.
• Inspection observations, photographs and prior recommendations as tracked objects with closure evidence.
• Report generation against the regulator's period and format, with data quality exclusions declared explicitly.

What it costs and how long it takes

From the infrastructure monitoring work Digital Heroes has delivered, the shape is this. A first release covering unified reading capture including offline field entry, versioned instrument metadata with correct conversions, governed thresholds and acknowledged alerting runs $60,000 to $120,000 and ships in 10 to 14 weeks. A full platform adding correlated expected behaviour models, survey and inspection integration, regulator-specific report generation and portfolio risk views runs $150,000 to $350,000 phased across 6 to 12 months.

What drives cost up for dam and levee owners: instrument diversity, since a portfolio built over decades carries several manufacturers, several datalogger generations and some instruments whose documentation no longer exists. Historical data migration, because a forty year piezometric record is the asset and importing it with correct datums and calibration history is careful work rather than a file upload. Multiple regulatory regimes, particularly where a portfolio spans hydro structures, state-regulated dams and a tailings facility with its own standard. And connectivity, because remote sites need a field application that genuinely works with no signal for a full day rather than one that degrades.

What keeps cost down: starting with the structures that carry the highest hazard classification, migrating the last ten years of history rather than everything at once, and leaving correlated behaviour modelling to phase two once the data is clean enough to model against.

Build versus buy, and when buying is right

Buy or stay manual if you own one or two low hazard structures with a handful of instruments read monthly. A disciplined engineer with a maintained spreadsheet is proportionate and honest, and a custom system would add process without adding safety. Use a monitoring product if your portfolio is fully automated, single manufacturer, and your regulatory reporting is light, because that is the case those products serve well.

Build when two or more of these are true. You hold more than eight structures, or any structure with a high hazard classification and a population at risk. More than a third of your readings are manual and therefore live outside whatever automated system you have. Your thresholds are inside datalogger programs and nobody can produce the rationale for their current values. A periodic inspection has raised findings about data management or about closure of prior recommendations. You report to more than one regulator with different formats. Or your entire dam safety knowledge base is one engineer who is within five years of retirement.

The threshold is not instrument count. It is whether a threshold crossing on a Tuesday reliably reaches a named engineer with enough context to act, without depending on someone opening a file.

How to choose a developer for dam safety monitoring software

Ask them how they would handle a piezometer rise during a reservoir filling event. A developer who has done this work will immediately separate expected response from anomalous response and talk about correlating with pool level. A developer who describes a threshold and an email has built a generic alerting tool and will hand you alarm fatigue.

Ask how instrument recalibration affects historical data. The answer you want is versioned instrument metadata with effective dates, so past readings keep their original conversion and the series stays interpretable. Anyone who overwrites calibration constants in place is going to corrupt a forty year record.

Ask what the field application does with no signal for eight hours. Manual readings are the majority of most portfolios and an application that needs connectivity will be abandoned in week two. You want offline capture, prior value display for plausibility checking, photograph attachment and reliable sync.

Ask who owns the code, the data and the export path, in writing before kickoff. The instrumentation record is a safety document with a lifetime measured in decades, and it must outlive any vendor relationship. At Digital Heroes the client owns the repository and the infrastructure from the first commit. A useful place to start: take the last threshold exceedance in your portfolio and trace how many hours passed between the reading being taken and an engineer seeing it. That interval is the project.