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