A dam monitoring dashboard should be organised by possible safety-loss mechanisms, not by sensor type. For each scenario, show the forcing, the expected response of the structure, evidence from several independent sources, the action level, and the response owner. Piezometers, displacements and flows then become answers to engineering questions, not separate folders of charts.
In brief
- Name the scenario and event chain first, then select the measurements. There is no single universal dashboard layout for every dam.
- Each view should connect the cause or forcing with the structural response: for example, reservoir level with pore pressure, seepage and displacement.
- A threshold without action is only a coloured line. For each state, record who verifies the data, what they inspect in the field, and who makes the decision.
- No data from a critical point is a separate operational state. It must not look like a stable chart.
- The dashboard supports supervision, but it does not replace dam safety analysis, field inspection or an emergency plan.
A typical monitoring panel starts from a list of devices. One page for piezometers, another for inclinometers, another for temperature and water level. That arrangement is convenient for instrumentation maintenance, but weak for the person who receives an alert at 3:20 about an unusual reading. That person must remember what the point is linked to, find the forcing, open neighbouring series and determine whether anything coherent is happening.
The manager's concern is simple: the panel will be full of data, yet still fail to answer under pressure. The solution is not to add more charts. The logic of the view needs to be reversed. FERC describes a monitoring programme based on "thinking in potential failure scenarios": instrumentation, inspections and procedures are meant to provide information about the mechanisms that pose the greatest risk. USACE states the same principle even more plainly, saying that every instrument on a dam should help answer a specific geotechnical question. The broader architecture of such a process is discussed in the complete guide to structural monitoring.
From failure scenario to dashboard question
A potential failure scenario is a credible chain of events that may take an asset from its initial state to loss of required function or safety. It is not a forecast that failure will occur. It is a working hypothesis: what could happen, what symptoms would appear first, and how they can be distinguished from normal operation.
A good scenario has five parts:
- initiator or condition, for example a rapid rise in level or long-term seepage;
- mechanism, for example increased pore pressure, internal erosion or slope instability;
- expected symptoms in the data and field observations;
- observation boundaries and action levels;
- the decision and the responsible person.
The dashboard is a summary of this analysis, not the place where it is created. First, the team that knows the asset reviews documentation, calculation results, operating history, inspections, unusual events and instrumentation reliability. Only then are the findings translated into views. FERC notes that identification of potential mechanisms uses both existing data and analyses, as well as the knowledge of field personnel. It cannot be outsourced to software alone.
A practical scheme for each view looks like this:
| Element | Design question | What you show |
|---|---|---|
| scenario | what can go wrong | short name and mechanism description |
| forcing | what starts or intensifies the process | water level, rainfall, temperature, operating mode |
| expected response | how the asset should respond | range, direction, lag and relationship between series |
| evidence | what confirms or weakens the hypothesis | 2-4 measurements, field observation, data quality |
| threshold | when the operating mode changes | observation, warning and action level |
| response | what we do and who decides | verification, field visit, additional reading, analysis, decision |
The most important part is not a single value, but the relationship. Pore pressure may rise correctly with reservoir level and fall with a typical delay. The same value at a low level, or without recovery after a drop in headwater level, may mean something else. That is why the "all piezometers" panel gives way to the view "response of the seepage zone to headwater level".
Three example scenarios for an earth dam
The examples below are illustrative. They are not a ready-made analysis for a specific structure and they do not define safety thresholds. They show how to move from mechanism to information. Names, measurement points and responses must be adapted to the structure, foundation, outlet works, history and operating instructions.
Scenario 1: intensified seepage and the possibility of internal erosion
The starting point may be a rise in reservoir level, a change in seepage path, damage to the seal, or the development of a local flow zone. An increase in drain flow alone does not prove erosion. It should be assessed together with water level, pore pressure in the sections, leakage character, possible transport of material, and observations of dampness.
Start the view with the forcing: the upstream water level and the rate of change. Below that, show the piezometric response in the section from the downstream side to the upstream side, and then the drain or seepage flow. The series share a common time axis. Next to them, place the current data freshness and a link to the inspection procedure. The question is: "is the response proportional, spatially consistent and reversible after a change in headwater level?"
Symptoms that require attention include a change in the relationship at a similar reservoir level, a response limited to one area, a rise without recovery, unusual turbidity, or new wet spots. Each of these requires engineering assessment. The dashboard is meant to collect evidence, not to name the mechanism on its own.
Scenario 2: slope or foundation instability
The mechanism may be linked to increased pore pressure, rapid drawdown, a weak foundation layer, or progressive displacement. In such a view, combine water surface position, piezometers, deep displacements, tilt and geodetic measurements, if they are available in the surveillance programme.
First show the local movement and its position in the profile, then the cumulative response relative to the stable zone, and finally the hydrological forcing. Acceleration of movement has a different meaning when pressure in the layer linked to the potential slip surface is also rising. Just as important is the absence of confirmation in neighbouring points, which may indicate a local problem or a fault in the measurement chain.
The dashboard should make it easier to compare with the expected range and with the same period in the previous operating cycle. That does not mean automatic seasonality subtraction. The point is to show the engineer whether the current trajectory is similar to a response already known, or whether its sign, rate or lag has changed.
Scenario 3: unusual crest deformation and uneven settlement
Settlement may develop slowly, but a local change in crest geometry, joints or appurtenant structures can be an important sign. The view combines benchmarks or displacement sensors, tilt, temperature, reservoir level and inspection information. For a concrete dam, analogous logic may apply to block movements, joints, uplift and thermal response, but the evidence layout will be different.
The question is not "has the point exceeded 5 mm?" unless 5 mm comes from an approved analysis. You ask: is the deformation pattern consistent with the expected one, is the change common to multiple points, does it correlate with temperature and impoundment, and does the expected recovery occur after a change in conditions? A single jump should first go through data quality control.
| Scenario | Forcing | Main evidence | Supporting evidence | First response |
|---|---|---|---|---|
| seepage / internal erosion | level and its change | pore pressure, seepage flow | field inspection of wet spots and material | reading verification, field visit, section comparison |
| slope stability | impoundment, drawdown, rainfall | pore pressure, displacement profile | geodesy, cracks, ground deformation | consistency review, additional observation, engineering analysis |
| crest deformation | time, temperature, level | settlement, tilt, displacement | condition of joints and elements | chain verification, spatial comparison, inspection |
How to design one scenario view
The screen should guide the eye in the same order in which the team reasons. At the top, place the scenario status, data freshness and a short action instruction. Below that, put the forcing and the main responses on a shared time axis. Then add a section or location map. At the bottom, include the state transition history and context from inspections or documentation.
Do not try to fit everything onto one screen. The dam manager needs a portfolio view with exceptions, the duty operator needs a response view, and the engineer needs diagnostic data. These can be three dashboards using the same series:
- "asset state" - scenarios, freshness and the highest alarm state;
- "operational response" - evidence needed in the first minutes and the procedure;
- "engineering analysis" - longer trends, sections, comparisons and source data.
Expected response matters more than colour
For each forcing-response pair, record four features: direction, typical range, lag and reversibility. For example, a rise in level may cause a rise in pressure with a delay, and after the level drops the response should return in a defined way. The limits must come from documentation, analysis, a history approved by an engineer, or the surveillance programme, not from the default percentage of the chart scale.
FERC points out that threshold levels and actions should arise from the expected operation of the specific dam. This protects against two errors: an alarm set so wide that it does not warn, and a threshold so tight that the normal response to impoundment triggers a stream of messages.
No data must change the interpretation
If the piezometer that serves as the main evidence in the scenario goes silent, the other green series do not prove safety. The view should show the NO_DATA state and a fallback procedure: a control reading, communication check, use of a neighbouring point only as supporting information, or an increase in field observations. More on designing this mechanism is in the article about the no data alarm.
Illustrative example: the same piezometer, two interpretations
Assume a hypothetical earth dam. The reservoir level rises by 1.2 m over three days. Pressure in three points across the section rises after 6, 11 and 18 hours respectively, and once the level stabilises, the pressures also stabilise. Drain flow increases, but remains within the relationship known from earlier, approved cycles. This pattern is consistent with the expected response, although without boundary values it cannot be called safe.
A month later the level is lower, but one point shows the same value as during high impoundment. Neighbouring points and the drain do not respond. A dashboard by device will show "high piezometer value". A scenario dashboard immediately reveals the lack of consistency. The first decision is data verification and point inspection, not automatic declaration of developing seepage and not ignoring the reading.
The example shows the value of relationships. The threshold alarm is still needed because it can indicate a dangerous value regardless of correlations. However, the scenario view shortens the path from message to the right evidence set and reduces the risk of a false narrative.
Dam monitoring dashboard acceptance checklist
- [ ] The scenarios were developed by a team familiar with the structure, foundation, history and operation.
- [ ] Each dashboard has one sentence describing the mechanism and the decision question.
- [ ] The forcing and the structural response are visible on a shared time axis.
- [ ] Each main piece of evidence has a name, location, unit and freshness.
- [ ] The expected direction, lag and range of response are defined.
- [ ] Thresholds have a source, an owner and assigned actions.
- [ ] The NO_DATA alarm covers critical devices or channels.
- [ ] The view distinguishes measurement, field observation and engineer interpretation.
- [ ] The procedure states who confirms the alarm, who carries out the field visit, and who decides.
- [ ] A test on historical data and a drill with simulated missing data were completed.
- [ ] A review cycle for the scenarios was established after asset changes, repairs or a new event.
What this looks like in Inclify
In one Inclify project you can create multiple dashboards, so the data can be arranged separately for overall state, duty response and scenario analysis. The chart panel lets you combine series on two axes, for example water level with pore pressure or temperature with displacement. Project equations turn raw readings into engineering values.
For each channel, you can configure WARNING and ALARM levels with hysteresis. A separate NO_DATA alarm monitors freshness. Notifications are sent by email and SMS according to user preferences. An alarm can be acknowledged with a record of the person and time, and muted only until a specified date. The platform keeps a history of states and an audit trail of configuration changes.
You can add context from public sources to the dashboard, including IMGW water levels and warnings, as well as weather data. Such a widget provides context, but it does not replace the local, validated measurement, and it does not automatically become the basis for a safety threshold. The data quality and SLA report shows completeness, gaps and freshness, which helps assess whether the evidence set for the scenario is available.
Limitations: the dashboard is not a safety analysis
The arrangement described in the article does not provide a universal list of scenarios. An earth dam, a concrete dam, a rockfill dam, an industrial reservoir and a flood embankment have different mechanisms, sections and operating conditions. Even two similar assets may differ in foundation, sealing, drainage and repair history. A competent engineering team must approve the set.
Correlation of series does not prove causation. The absence of a threshold exceedance does not exclude a process taking place between measurement points. Conversely, an alarm does not confirm a failure mechanism until you complete quality control and compare it with other evidence. Automated monitoring complements inspections, manual measurements, analyses and the emergency action plan; it does not replace any of them.
Public weather and hydrological data may have different location, cadence and verification status than the instrumentation on the asset. Show their source and time. For a critical decision, use sources and rules approved in the surveillance programme. The general principles of building a response plan for an alarm must be translated into the organisation of the specific owner.
FAQ
How many scenarios should a dam dashboard have?
As many as result from the current analysis of the specific asset, but the main screen should not force the duty operator to read a long list. Group scenarios by priority and show exceptions. Less likely mechanisms may still have separate diagnostic views. The number is not the goal; the goal is to cover the relevant risks and make the response clear.
Can one sensor belong to several scenarios?
Yes. The same piezometer can provide evidence for seepage, slope stability and rapid drawdown response. There is no need to copy data or devices. You can show the same series in several views with different context, time scale and comparison set. Meaning comes from the engineering question, not the equipment folder.
How often should scenarios and dashboards be updated?
After a change in the structure, equipment, operating mode, repair, significant event or new safety assessment. Independent of events, schedule a periodic review of the monitoring programme. USACE points to the need for continuous re-evaluation of instrumentation throughout the life cycle. An old view may look correct even though it no longer reflects the current mechanisms.
Should the dashboard automatically identify a failure scenario?
That should not be promised without a validated model for the specific dam. Alarms and relationships help gather signals, but final mechanism identification is carried out by a person based on data, inspections and analyses. A better panel clearly shows the evidence and its quality than an attractive label whose basis cannot be reproduced.
What should be done when the main piezometer stops sending data?
Trigger the NO_DATA state and the fallback procedure defined in advance. This includes checking communication and power, taking a control reading, assessing neighbouring points, and possibly increasing field observations. Do not automatically treat the neighbouring sensor as equivalent. Its location may answer a different geotechnical question.
Are IMGW weather data enough to assess dam response?
They are valuable regional context, especially for rainfall and warnings, but they do not replace the local measurement required by the surveillance programme. The station may be in a different catchment or elevation, and public data may be preliminary. On the dashboard, mark the source, time and role: context, not an independent safety proof.
Sources and further reading
- USACE EM 1110-2-1908 - Instrumentation of Embankment Dams and Levees - instrumentation planning around mechanisms, geotechnical questions, quality and maintenance.
- FERC - Dam Safety Performance Monitoring Program and Potential Failure Modes Analysis - linking the monitoring programme to potential failure mechanisms.
- FERC - Dam Safety Surveillance and Monitoring - expected dam response, threshold levels and actions.
- Environment Agency - Best practice in dam safety performance monitoring - good practice in inspections, instrumentation, analysis and data management.
- ICOLD - publications and technical bulletins - technical recommendations of the International Commission on Large Dams.
What next
Choose one high-priority scenario and draw it on a single sheet: initiator, mechanism, expected response, four pieces of evidence, threshold and action. Then compare the sheet with the current dashboard. If the necessary data are scattered across several screens, you have a good scope for the first improvement. Talk to the Inclify team if you want to translate such a scenario into a pilot view without rebuilding the entire monitoring programme.