Developed by Ji’an Liao, Zifa Wang, Dengke Zhao, Jianming Wang, Zhaoyan Li, and Siran Yang, SHM-EM addresses a deceptively simple failure mode: machine learning models used for forecasting demand their inputs in a fixed order with fixed columns, while monitoring platforms store data in vendor-specific tables with inconsistent fields, units, and point identifiers. The result is brittle glue code that is hard to verify, harder to reuse, and nearly impossible to audit when something goes wrong. Existing standards such as the Open Geospatial Consortium’s SensorThings API standardize how sensors and observations are described and queried, and complex-event-processing research supplies tools for windows, conditions, and event generation, but neither specifies how a persisted forecast should be inspected, aligned, and conditionally admitted into an official event workflow. That boundary is precisely where the new framework concentrates its effort.

Architecturally, SHM-EM is organized into four layers: a Vue-based user interface, Spring Boot application services, a Python forecasting runtime named PIT_PRE that runs fixed-version models, and a MySQL persistent store holding observations, model registrations, predictions, events, and responses. The authors deliberately keep the Python modelling ecosystem separate from the Java services, which isolates inference from page-access frequency and prevents model dependencies from leaking into the back end. Formal event creation is reserved exclusively for back-end services, a design choice that reflects the framework’s central concern: the difference between looking at a forecast and acting on one must be enforced by the software itself, not by user discipline.

The first of the framework’s three core mechanisms is a versioned, engineering-semantic data-model contract. This contract binds monitoring objects, source fields, ordered input features, fixed-version models, and prediction targets into a single inspectable registration. Cryptographic bundle hashes cover model weights, preprocessors, scripts, parameters, and runtime metadata, while feature mappings retain input order, source identity, units, conversion versions, and target roles. When anything drifts, whether the bundle, the schema, the contract, or the feature ordering, PIT_PRE rejects the run outright. Before inference, observations are aligned to a registered three-minute grid using backward as-of matching within one cadence, followed by linear interpolation and boundary fill, with signed time offsets and fill diagnostics recorded. Unresolved required inputs are rejected rather than silently imputed, and data freshness is checked separately.

The second mechanism is the project future state, a software-level representation of synchronized forecasts and risk summaries. In the reference deployment, six Transformer-CNN models forecast deep horizontal displacements in two directions, earth-pressure strain and pressure, groundwater elevation, and surface settlement. Five of the models consume 114 input features each while the settlement model uses 164, and together they produce 124 target channels across 40 future steps at three-minute intervals. All models share a single prediction origin and future timeline, so a project manager sees one coherent 120-minute view of predicted risk rather than six disconnected model outputs. A policy-bound aggregation algorithm then evaluates rule-level conditions step by step, activates severity levels when consecutive-step requirements are satisfied, assigns the highest activated severity, and merges forecast risk with any open risk from already-observed events.

The third mechanism, and arguably the most consequential, is the controlled transition from forecasts to formal engineering events. After a prediction batch is stored, SHM-EM validates it and prepares a unified engineering series in which observed and forecast values share object, metric, time, engineering-value, unit, and provenance fields. A gate then checks batch status, required runs and steps, timing, quality, bundle hashes, and the recomputed integrity of persisted results. Only then are two independent paths exposed. Evaluate returns candidate events and calculation snapshots, storing an audit run without creating any formal event or response record. Execute, by contrast, never consumes a stored evaluation result; it reloads the series, persists a fresh execution-gate result, revalidates rule and unit semantics, and creates the formal event, response workflow, and provenance chain only when every condition is satisfied. This separation means that a mutation of data after evaluation cannot slip a stale decision into formal execution, a failure path the authors explicitly test.

Provenance receives equally careful treatment. Every formal event can be traced to its rule version, prediction batch, model and input hashes, the exact input window, the exceedance details including lead time, peak value, and consecutive steps, and a result hash. In the published reproduction, a captured event resolves to rule version 2, a 40-step batch, a settlement model run, and an input window spanning late December 2024 into the first minutes of 2025, with the machine-readable trace retaining a peak settlement of roughly 9.43 millimeters. Such traces transform what is usually an opaque alerting pipeline into an auditable record that a reviewer can reconstruct end to end.

The evidence base for these claims is unusually concrete. A public reference case built on 2,464 de-identified, time-shifted observations from nine excavation points verifies the software chain without claiming predictive accuracy, since confidentiality prevents release of the complete training data. A 15-case validation matrix combined one positive control, twelve injected failure paths, and two input controls; every expected blocked case produced zero formal business records, while audit writes remained permitted. Scripted reproduction families passed in full, including 55 back-end tests, 13 PIT_PRE tests, and the end-to-end reference workflow, and a Docker Compose route reproduced the entire six-model, 4,960-record pipeline. A synthetic bridge fixture then demonstrated reuse: adding three stations, twelve instruments, and new mappings required no changes to back-end, front-end, forecasting, or event code, with missing mappings correctly rejected. Runtime measurements on a warm-cache Windows machine showed a full six-model prediction batch completing in a median of about 16.8 seconds, with the execution gate itself taking only a few hundred milliseconds.

The authors are candid about limits, which strengthens rather than weakens the contribution. The excavation case and synthetic fixture do not validate predictions for other structure types, the point forecasts provide no calibrated uncertainty or safety confidence, and MySQL is the only tested back end behind a 50,000-row application-level gate cap. Cross-platform reproduction revealed that while input and model-contract hashes matched between Windows and Ubuntu, normalized prediction hashes differed slightly, with a maximum persisted absolute difference of about 0.00285, so Windows remains the exact-output reference. The public baseline lacks authentication, and the security documentation requires TLS, external identity and role-based access control, separate Execute privileges, least-privilege database accounts, and protected audit logs. Most importantly, the authors state plainly that forecasts must never be the sole basis for automated safety decisions.

Even within those boundaries, the significance of SHM-EM lies in what it makes routine. Researchers can register compatible model versions, thresholds, and rule settings without rewriting acquisition, forecasting, or event-handling workflows. After one-time registration, non-specialist users work through a web interface to inspect observed and forecast series, review threshold exceedances and lead times, and, crucially, distinguish a candidate event from a formally executed one, with eligibility or blocking reasons, model versions, input windows, and hashes all visible. Released under the MIT license with locked dependencies, immutable model cards, and a SHA-256-verified archive, the framework offers the structural health monitoring community something rarer than another forecasting algorithm: a disciplined, reproducible pathway by which a prediction earns the right to become an official record of engineering concern.

Subject of Research: A forecast-aware event management software framework for structural health monitoring of civil engineering projects

Article Title: SHM-EM: a forecast-aware event management framework for heterogeneous engineering monitoring

Article References: Liao, J., Wang, Z., Zhao, D., Wang, J., Li, Z., & Yang, S. (2026). SHM-EM: a forecast-aware event management framework for heterogeneous engineering monitoring. SoftwareX, 36, Article 103082. https://doi.org/10.1016/j.softx.2026.103082

Image Credits: AI Generated

DOI: 10.1016/j.softx.2026.103082

Keywords: structural health monitoring, SHM-EM, machine learning forecasting, Transformer-CNN models, sensor data integration, event management, provenance, reproducibility, open-source software, excavation monitoring, data-model contract, civil engineering

The core of the work is a five-layer architecture that connects everything from the dam’s intake structures to cloud-hosted analytics. At the base sits the equipment layer, comprising the hydro-generator units, shaft systems, bearings, valves, and hydraulic structures. Above it, a perception layer deploys pressure, flow, and temperature sensors that feed a multidimensional observation vector covering pressure, flow rate, temperature, rotational speed, and power output. The transmission layer then splits its workload intelligently: latency-sensitive data is processed at the edge, close to the machines, while historical records and training tasks migrate to the cloud. An analysis layer hosts the digital twin itself, and a service layer translates all of this into alarms, risk scores, and maintenance decisions for human operators. In benchmark comparisons, this edge–cloud division of labor produced an end-to-end alarm delay of just 56 milliseconds, substantially better than the 116 milliseconds of a cloud-only setup or the 67 milliseconds of an edge-only configuration, because it pairs the low communication latency of local computing with the heavy computational muscle needed for twin synchronization and health assessment.

The digital twin at the heart of the framework is not the static 3D visualization that the term sometimes connotes. Instead, the researchers constructed what they call a physics–geometry–behavior coupled model, dividing the virtual representation of each generating unit into four interacting sub-models. A geometric model captures the three-dimensional structure and assembly relationships of the equipment. A physical model, grounded in continuum mechanics, computes stress and strain distributions using the material stiffness tensor, tracking how the rotor, bearings, and support structures degrade under long-term loads. A rule model encodes operating constraints and fault criteria, while a behavior model simulates the dynamic response of the unit through electromechanical coupling equations that relate hydraulic torque, electromagnetic load torque, damping, and fault disturbances to the rotational dynamics of the shaft. Together, these sub-models map the machine’s structural state, stress distribution, and dynamic behavior into a unified virtual space.

What makes the twin genuinely useful, the authors emphasize, is its synchronization mechanism. The digital twin generates a predicted state at each time step, which is compared against the real measurements streaming from the plant’s PLC-SCADA control system. The difference between prediction and measurement, called the synchronization residual, is fed back to correct the twin’s state through a residual-feedback coefficient. As long as residuals stay within normal thresholds, the twin tracks the machine faithfully; the reported mean absolute percentage errors across five monitored variables — pressure, flow, speed, temperature, and power — all remained below 2 percent, with rotational speed tracked to within 0.51 percent. When a residual suddenly exceeds its threshold, the system does not merely flag an anomaly; it triggers the fault diagnosis model to determine whether the deviation stems from a sensor malfunction, genuine mechanical degradation, or a coupled failure of both.

Distinguishing between a lying sensor and a sick machine is one of the study’s central technical contributions. The researchers instantiated three pressure-sensor fault modes drawn from real maintenance records: fixed bias corresponding to a 5 percent static calibration deviation, linear drift at 0.02 megapascals per hour typical of sensor aging, and sudden faults producing abrupt 0.5 megapascal jumps. These were injected alongside equipment-level faults including bearing wear, rotor imbalance, shaft eccentricity, and hydraulic disturbances. The state evolution model, which tracks the unit’s condition through a state-space equation with a dedicated fault disturbance term, proved sensitive to these distinctions: pressure residuals rose from 0.021 to 0.074 megapascals under sensor faults, while speed and power residuals spiked under mechanical faults, and composite fault scenarios pushed the normalized residual score to 0.394, nearly seven times its normal-operation value.

On the diagnosis task itself, the proposed method — which fuses multi-source monitoring data, edge–cloud processing, and digital twin consistency checks within a deep learning framework constrained by physical consistency — outperformed a series of baselines. Traditional support vector machines reached 89.3 percent accuracy, convolutional and recurrent networks climbed to 92.5 and 94.1 percent respectively, and Transformer and digital-twin-only models achieved 95.6 and 96.4 percent. The full framework reached 98.2 percent accuracy with an F1-score of 0.973 and an average detection time of 31 milliseconds, results that held stable across repeated trials with different random seeds and survived paired statistical testing against every baseline. An ablation study traced the gains component by component: multi-source data fusion added roughly 1.4 percentage points, edge–cloud deployment cut detection time while adding accuracy, and digital twin consistency modeling contributed nearly another full point by helping the model separate transient signal fluctuations from real degradation.

The framework extends beyond diagnosis into prognostics. A health index, generated by a mapping function that fuses the digital twin’s virtual state with the physical measurements, was validated across normal, sensor-fault, mechanical-fault, and composite-fault conditions, producing mean values of 0.962, 0.781, 0.643, and 0.472 respectively — a graded, quantitative picture of degradation rather than a binary alarm. From this health index, the system predicts remaining useful life using a similarity-based approach that matches the current degradation trajectory against a library of historical lifetime curves. In quantitative tests across four benchmark scenarios, the method achieved a mean absolute error of 3.36 hours and a root-mean-square error of 4.58 hours, a 31.8 percent reduction in RMSE compared with LightGBM, and consistently outpaced Ridge and Lasso regressors, which lagged noticeably at the degradation inflection point.

Those predictions feed a maintenance optimization model that explicitly weighs three cost components: the cost of executing maintenance, the cost of lost generation during downtime, and the cost of failure risk. In a normalized comparison with periodic maintenance as the baseline, the predictive strategy reduced maintenance execution costs by 17.3 percent, downtime losses by 38.1 percent, and risk costs by 32.6 percent, cutting the total cost index from 300.0 to 212.0. Reactive maintenance fared far worse, with a total cost index of 446.5, because delayed intervention cascades into emergency repairs, extended outages, and amplified fault propagation. The optimization, the authors note, is particularly consequential for stations running two units in parallel, where the distributed PLC architecture reduces single-point failure risk and allows maintenance decisions to be prioritized across machines.

The engineering deployment details give the study unusual practical credibility. The experimental platform replicates a real hydropower station’s distributed three-level control structure, with a dam-side sensing unit, a SCADA monitoring host, a common PLC cabinet, and independent PLC cabinets for each of the two 625-kilowatt Pelton turbine units, which run at 750 revolutions per minute and deliver a rated output of 650 kilovolt-amperes. Data traveled over a hybrid network of fiber optic cable, Cat6 industrial Ethernet, and copper cable. The experimental dataset combined 30 days of continuously collected PLC-SCADA operational data at 1 hertz — roughly 2.59 million records — with historical fault and maintenance records and digitally injected fault scenarios used to supplement rare fault classes. To avoid data leakage, the team split data by time segments and fault events rather than shuffling individual samples, and all normalization parameters were derived exclusively from the training set.

The authors position their contribution against a body of prior work that has tended to address pieces of the problem in isolation. Earlier digital twin studies in hydropower focused on turbine fault simulation, pressure sensor anomaly detection, or operational visualization; cross-domain fault diagnosis research improved bearing diagnostics under variable speeds but did not engage with PLC-SCADA-driven plant operations or maintenance decisions; and generative data augmentation methods tackled sample scarcity without establishing physical–virtual synchronization. By integrating real-time edge–cloud collaboration, a coupled digital twin, health assessment, remaining-life prediction, and maintenance optimization into a single closed-loop workflow — from anomaly perception through fault diagnosis and degradation prediction to maintenance action — the framework addresses what the researchers identify as a persistent gap: most existing approaches stop at fault classification, leaving the decision-making end of the chain to human schedulers.

The implications reach beyond the two small Pelton units on which the system was tested. As power grids absorb growing shares of variable wind and solar generation, hydropower stations are increasingly called upon for peak shaving, frequency regulation, and black-start support, operating regimes that subject turbines and generators to frequent load fluctuations, hydraulic shocks, and multi-source coupled stresses. The study’s authors argue that condition monitoring built on single sensor signals lacks the robustness these conditions demand, while purely data-driven deep learning models suffer from scarce fault samples and limited physical interpretability — a serious drawback in high-reliability industrial settings. Embedding mechanistic constraints within the digital twin, they contend, gives the diagnostic models a physical anchor that pure pattern recognition cannot provide.

Limitations remain, and the authors are candid about them. The fault scenarios used for validation, while grounded in maintenance records and physical modeling, were partly generated through controlled fault injection on the digital twin platform, a strategy that supplements but cannot fully substitute for the long tail of rare failures that only decades of operation can produce. The health index classification thresholds and the weighting coefficients in the risk and cost models were tuned on validation data, and their transferability to larger installed capacities, different turbine types, or stations with different hydrological regimes has not yet been demonstrated. Data availability for independent verification is currently restricted to requests to the corresponding author.

Even so, the study offers one of the most complete demonstrations to date of what a fully closed-loop intelligent maintenance system for hydropower looks like in practice: sensors feeding edge controllers, edge controllers feeding a self-correcting digital twin, the twin feeding diagnostic and prognostic models, and those models ultimately deciding when a machine should come offline — all within a latency budget measured in tens of milliseconds. As the energy transition pushes hydropower into a more demanding operational role, the research suggests that the machines best prepared for that future will be the ones that carry their own virtual counterparts, watching for trouble before the first vibration signal ever reaches an operator’s screen.