Structural health monitoring of bridges & buildings from sensor data

Ageing bridges and buildings are inspected by people at fixed intervals, so damage that develops between inspections, or hides inside concrete, can be missed. Structural health monitoring (SHM) instruments the structure permanently; ML models separate real damage-related changes from the daily and seasonal noise of temperature and traffic, and tell owners where to look first. The benefit is earlier warning and better prioritisation of scarce inspection and repair budgets, not a replacement for engineers.

Problem & value

• Who: road and rail authorities, municipalities, infrastructure operators, owners of large buildings, stadiums, towers and industrial structures, and the consulting engineers who serve them.
• Today: periodic visual inspection (in Germany per DIN 1076 for road bridges), occasional load tests, and for few structures a classical monitoring system with fixed alarm thresholds. Thresholds on raw values fail because frequencies and strains move with temperature, humidity and traffic.
• Why now (Germany): the partial collapse of the Carolabrücke in Dresden on 11 September 2024 put hidden prestressing-steel damage and monitoring in the public debate; later sensor readings on the remaining spans showed cracks in the steel reinforcement and led to accelerated demolition [5]. Public research projects funded through mFUND, with BASt and Autobahn GmbH as partners, develop ML-based anomaly detection for bridges (P-BIM, OSiMaB) [1][2].
• AI value: (1) normalise away environmental effects, (2) detect deviations from a learned healthy baseline without damage examples, (3) fuse many sensors, (4) rank structures for inspection, (5) draft reports. Sourced quantitative field benefits are scarce; the P-BIM page reports no results [1], so treat vendor ROI claims with caution.

Variants

• Road/rail bridges: vibration, strain, bearing displacement, tendon-break acoustic emission; typically long-term "smart bridge" installations.
• Buildings, towers, stadiums, heritage: modal tracking, settlement and tilt, post-earthquake or post-storm screening.
• Tunnels, dams, wind-turbine towers and offshore foundations reuse the same pipeline with different sensors.
• Temporary monitoring: campaigns during construction, retrofit or neighbouring excavation.
• Prioritisation at network level: combine a few monitored "sentinel" structures with inspection records to rank the rest (links to VIS-003, PRED-033).
• Private use: essentially none beyond homeowners using crack monitors; not an individual-consumer use case.

How it works

1. sensors (accelerometer, strain, tilt, fibre, acoustic emission, temperature, traffic)
2. edge logger: sync, filtering, decimation, store-and-forward
3. signal processing: operational modal analysis (frequencies, damping, mode shapes)
4. normalisation: remove temperature/traffic/wind effects (regression, PCA, autoencoder)
5. anomaly detection against healthy baseline (statistical, deep, physics-informed)
6. localisation & severity hints (mode-shape change, sensor-group residuals, FE-model updating)
7. alert logic with persistence rules
8. engineer review
9. inspection / load restriction decision

• Operational modal analysis (OMA) estimates natural frequencies, damping and mode shapes from ambient vibration (algorithms such as SSI and pLSCF, available in the open-source pyOMA toolbox) [4].
• Environmental compensation is the core ML problem: a model predicts expected features from temperature and traffic; the residual is the damage indicator [3][8].
• Unsupervised learning is the norm because real damage data is almost non-existent; P-BIM uses a deep network on strain-gauge grids that learns normal behaviour, embeds physical prior knowledge and adds an explainability module [1].
• Hybrid physics-AI: finite-element (FE) models generate synthetic damage scenarios to train or validate detectors and to localise damage (simulation capability).
• LLM layer (optional): summarising alerts, drafting monitoring reports, and Q&A over inspection documents; never a decision-maker.
• Human-in-the-loop: a qualified structural engineer reviews every alert above "information" level and alone decides on closures or load limits.

Data preparation

The core data are sensor time series (accelerometers, strain, tilt, temperature, fibre-optic) plus context: weather, traffic and weigh-in-motion data, inspection reports (DIN 1076), drawings or BIM models. In an SMB or authority these live in vendor portals, logger files on site, bridge-management databases, PDF inspection reports and paper archives.

Typical gaps: clock drift and unsynchronised channels, sensor drift and outages, no labelled damage (so unsupervised baselines), missing temperature or traffic data for compensation, inspection reports only as scans, structure data scattered across offices.

Preparation steps: 1. Inventory sensors, channels and data owners; extract data via APIs or logger exports (PREP-005). 2. Synchronise, clean and resample signals; flag outages and calibrate sensors. 3. Record at least one full seasonal cycle as healthy baseline before alerts count. 4. Digitise and OCR inspection reports and link findings to sensor locations (PREP-006, PREP-010). 5. Define alert categories and severity levels with engineers (PREP-019).

Effort: high; installation and data quality dominate, ML is the smaller part. See GUIDE-003.

Implementation paths

Which path for whom

• Enterprise (infrastructure owners, operators): Path A — mature European monitoring vendors take responsibility for sensors, data quality and alert logic, which most owners cannot staff themselves.
• Public (road authorities, municipalities): Path A — established vendors with EU hosting and open data export fit procurement rules and the standard DIN 1076 inspection process.
• Developer: Path C — open-source tools (pyOMA, scikit-learn, a time-series database) on HW1 let engineering teams build tailored detectors for their structures.

Path A — Buy (recommended)

• Monitoring platforms and sensor vendors: HBK (Hottinger Brüel & Kjær, formerly HBM, DE/DK, OSiMaB partner [2]), Sixense (FR, Vinci group), mageba (CH, bridge bearings with sensing), Gantner Instruments (AT), plus engineering consultancies offering monitoring-as-a-service. Mark: all listed are European.
• Asset platforms and digital twins: Bentley iTwin and similar infrastructure twins for visualisation and integration.
• Choose A when: you own few structures, lack in-house signal-processing/ML staff, and need a vendor that takes responsibility for installation, data quality and alert logic. Insist on EU data hosting, open data export and explainable indicators.

Path B — Build on cloud APIs

• Ingest via IoT services in EU regions (Azure IoT Hub, AWS IoT Core Frankfurt, or EU providers), store in a time-series database.
• Time-series foundation models such as Amazon's Chronos-2 (zero-shot forecasting with covariates, 120M parameters, Apache-2.0) can predict expected sensor values from temperature and traffic covariates; the residual becomes an anomaly feature [6].
• Frontier LLMs (Claude, Gemini, GPT, Mistral) for report drafting and inspection-document Q&A, with numeric results always computed by deterministic code.
• Choose B when: you are an engineering firm or large owner with a data-science team and need custom indicators across many structures. Note that foundation models are not validated for structural damage; use them for baselines, not as certified detectors.

Path C — Self-host (open source)

• OMA/SHM: pyOMA (GPL-3.0, SSI-cov, SSI-data, pLSCF, automated mode clustering, SHM support) [4]; general Python stack with SciPy.
• Anomaly detection and forecasting: Darts (Apache-2.0; scorers, detectors, PyOD wrapper, N-BEATS/TFT, foundation models) [7]; scikit-learn/PyOD; PyTorch autoencoders.
• Pipeline: MQTT/Kafka ingest, TimescaleDB or InfluxDB, Grafana, edge gateways with ONNX runtime.
• Hardware: HW1 suffices (CPU server plus edge loggers) for modal tracking and small models; add a single GPU (HW2) only for deep or physics-informed training. Ops effort is dominated by sensor maintenance and data QA, not compute.

Path D — Custom training

• Worth it for operators of many similar structures (e.g. a fleet of prestressed bridges) or for research-grade detectors. Needs one to several years of baseline monitoring data per structure (to cover seasons), FE-model-generated damage scenarios, and ideally laboratory damage tests. Without damage labels, limit the claim to anomaly detection. Public examples: P-BIM and OSiMaB [1][2].

State of the art (2026)

• Methods: vibration-based damage detection has shifted from offline model-driven analysis to online data-driven detection, and reviews call for explainable and hybrid physics-AI models, with edge deployment as an open challenge [3][8].
• Typical pipeline is OMA plus environmental normalisation plus unsupervised novelty detection; supervised damage classification is rarely possible outside the lab.
• Foundation models for time series (Chronos-2, released Oct 2025) make baseline forecasting with covariates cheap, but they are generic and not damage-aware [6].
• Sensor trend: distributed fibre-optic sensing and acoustic emission for hidden tendon damage; the Carolabrücke case shows the interest in detecting prestressing damage early [5].
• Limits: environmental effects can mask or mimic damage; localised damage barely changes global modes; sensors drift and fail; few validated damage datasets exist; false alarms cause alert fatigue; data from one structure rarely transfers to another. Large installations exist (e.g. Hong Kong bridges with about 900 sensors, Sydney Harbour Bridge with over 2,400 [8]), yet quantified benefit from ML specifically is thinly published.

Shared resources & combinations

• Same building blocks (time-series + anomaly-detection + streaming): PRED-006 predictive maintenance (same vibration analytics), PRED-014 soft sensors, PRED-033 buried-network failure (network-level prioritisation), PRED-026-style degradation modelling.
• Combines naturally with: VIS-003 drone inspection and VIS-043 pipe/sewer inspection (visual evidence for sensor alerts), GEN-025 photo-to-3D capture and digital twins, ROBO-010 simulation for synthetic damage scenarios, PRED-017 weather forecasts and PRED-027 flood loads as covariates, PRED-048 building energy models (shared building sensors and BIM data), DOC-014 for turning legacy inspection reports into structured data.
• Hardware/data: edge gateways and a time-series database serve several monitoring use cases; one HW1 server can host dozens of structures.

Effort, cost & KPIs

• Path A: months for installation and commissioning; sensors and installation (traffic management, cabling) dominate cost, software is a minor share.
• Path B/C: 6–12 months to a validated pipeline on top of an existing sensor installation; baseline period of at least one seasonal cycle before alerts are trustworthy.
• Path D: multi-year, research-level.
• KPIs: sensor availability, data completeness, false-alarm rate per structure-year, detection of known test damage or retrofit effects, lead time of alerts versus findings in manual inspection, share of inspections triggered by data, engineer review time per alert.

People & change

Involve management (budget, liability), the department lead / structural engineers (who alone decide on closures or load limits), IT and IT security (sensor network, remote access, OT segregation, GUIDE-013) and suppliers (sensor and monitoring vendors) from the planning stage. Data owners for existing inspection records join early; legal-compliance clarifies liability when alerts are ignored or missed.

Works council: generally no. The system measures structures, not employee behaviour or performance. Check only if alert-handling logs or engineer review times are evaluated per person; then §87(1) no. 6 BetrVG (or Personalrat rights) applies. Inform the council anyway under §90(1) no. 3 if work processes change.

Data protection: sensor data are normally non-personal; traffic or camera data may not be, so involve the DPO if licence plates or video appear (GUIDE-005).

AI literacy: support engineers with short training on baselines, false alarms and the limits of unsupervised detection (GUIDE-006).

Pilot and concerns: begin with one structure and run alerts in shadow mode next to regular inspections. Engineers may fear being second-guessed or overloaded with false alarms; address this with persistence rules, transparent indicators and clear human authority over decisions (GUIDE-009, GUIDE-008).

Risks, regulation & compliance

• EU AI Act: classification depends. Annex III point 2 lists AI used as safety components in the management and operation of critical digital infrastructure, road traffic, or the supply of water, gas, heating or electricity [9]. Pure condition-monitoring that advises engineers is usually not such a safety component (minimal risk), but a system that automatically closes lanes, restricts traffic or acts as the safety function of a utility structure can be high-risk; assess case by case. Art. 4 AI literacy applies.
• Construction and inspection law: DIN 1076 inspections and German recalculation guidelines stay mandatory; monitoring supplements, not replaces, them. Structural engineers retain professional responsibility for the assessment.
• GDPR: generally no personal data; traffic sensing by cameras or licence plates would be personal data, so use anonymous weigh-in-motion or aggregated counts.
• NIS2/critical infrastructure: operators of critical infrastructure must secure sensor networks and data links.
• Risks: false negatives creating false confidence, false positives leading to unnecessary closures, vendor lock-in with proprietary formats, cyber-attacks on sensor feeds. Mitigations: independent redundancy, documented alert thresholds, open data export, regular sensor calibration, audit log, and a defined escalation chain to a qualified engineer.

Getting started

1. Define the monitoring objective and failure modes with a structural engineer (what damage, where, what action follows an alert).
2. Install a pilot sensor set (accelerometers, strain, temperature) and collect at least a full seasonal cycle of baseline data.
3. Run OMA with pyOMA and track frequencies against temperature; build a simple regression-based normalisation first.
4. Add unsupervised anomaly detection (Darts/PyOD) and validate against known events such as retrofit or test loads.
5. Integrate alerts into the inspection workflow with documented review and escalation; only then consider foundation models or LLM reporting.

Sources

1. P-BIM (Predictive Bridge Information Deep Learning Model for Anomaly Detection), University of Würzburg Data Science Chair — https://www.informatik.uni-wuerzburg.de/datascience/projects/physics-informed-deep-learning/p-bim-concluded/
2. HBK/HBM — OSiMaB project (mFUND, BASt-funded adaptive bridge safety evaluation) — https://www.Hbm.com/en/9279/osimab-project-on-the-road-to-mobility-40/
3. Algorithms and Techniques for the Structural Health Monitoring of Bridges: Systematic Literature Review (PMC) — https://www.ncbi.nlm.nih.gov/pmc/articles/PMC10181214/
4. pyOMA — Operational Modal Analysis toolbox (Bauhaus-Universität Weimar) — https://github.com/pyOMA-dev/pyOMA
5. Carola Bridge (Dresden collapse, 11 Sept 2024; sensor-detected cracks Feb 2025) — https://en.wikipedia.org/wiki/Carola_Bridge
6. Amazon Science — Chronos forecasting models (Chronos-2) — https://github.com/amazon-science/chronos-forecasting
7. Darts time-series library (anomaly detection module) — https://github.com/unit8co/darts
8. Structural health monitoring overview (Wikipedia) — https://en.wikipedia.org/wiki/Structural_health_monitoring
9. EU AI Act Annex III (point 2, critical infrastructure) — https://artificialintelligenceact.eu/annex/3/
10. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj