AI Structural Monitoring for Bridges & Tunnels: Predictive SHM

A bridge has been in service for 50 years, design documentation lost. Assessing the remaining service life without stopping traffic is a challenge that traditional visual inspections cannot solve: they detect defects when destruction has already begun. We replace rare inspections with continuous AI monitoring: vibration, strain, and acoustic sensors with real-time ML analysis. Our engineers have implemented such systems on 20+ structures, including cable-stayed bridges and metro tunnels. Leave a request and get a proposal within a day.

Problems We Solve

Missed micro-cracks before failure. Cracks 0.1 mm wide are invisible to the eye, but AI analysis of acoustic emission and strains detects them weeks before critical growth. The combination of strain gauges and cameras with 0.01 mm resolution provides early warning.

Fatigue failure without external signs. Rainflow counting of load cycles calculates accumulated damage using Miner's rule. If the resource is 80% exhausted, the system generates a repair plan.

Temperature anomalies and overloads. Sensors detect exceeding design loads (wind, snow, vehicle overload) and adjust the remaining service life forecast. The system enables a shift from reactive repair to predictive bridge maintenance.

Why Modal Analysis Detects Damage Earlier Than Visual Inspection

The natural frequency of a structure (e.g., 2.3 Hz for a 100-meter bridge) changes by 3-5% when stiffness is lost. An ML model detects such shifts within 24 hours, not a month of inspection. In one case from our practice, we detected a 7% frequency drop two days after a traffic accident — a crack in the beam was discovered before visible signs appeared. Moreover, the ML model analyzes frequency shifts 100 times faster than a human, allowing instant response.

How We Do It: Stack and Case Study

For a bay bridge from our practice, we installed 12 accelerometers (100 Hz), 8 strain gauges, and 4 crack gauges. Data flows to a server with an ML pipeline:

• PyTorch for feature extraction (spectrograms, modal parameters)
• LangChain + Hugging Face for analyzing text inspection reports (RAG)
• vLLM for generating prescriptions with explanations

Modal analysis code:

import numpy as np
from scipy import signal
from scipy.linalg import svd

def extract_modal_frequencies(acceleration_data: np.ndarray,
                               sampling_rate: float = 100) -> dict:
    """
    OMA (Operational Modal Analysis) — modal identification from ambient vibration.
    Change in natural frequency = change in stiffness = damage.
    """
    n_sensors = acceleration_data.shape[1]
    freqs, Sxy = signal.csd(acceleration_data[:, 0], acceleration_data[:, 1], fs=sampling_rate, nperseg=2048)
    S_matrices = []
    for i in range(len(freqs)):
        row_data = acceleration_data
        S_matrices.append(np.outer(row_data[i], row_data[i].conj()))
    singular_values = []
    for S in S_matrices:
        U, s, Vh = svd(S)
        singular_values.append(s[0])
    peaks, properties = signal.find_peaks(singular_values, height=np.mean(singular_values) * 3, distance=5)
    modal_frequencies = freqs[peaks].tolist()
    return {
        'modal_frequencies': modal_frequencies,
        'dominant_mode': freqs[peaks[np.argmax(properties['peak_heights'])]] if len(peaks) > 0 else None
    }

Monitoring frequency changes:

def detect_structural_change(current_freqs: list, baseline_freqs: list, tolerance_pct: float = 3.0) -> dict:
    changes = []
    for i, (curr, base) in enumerate(zip(current_freqs, baseline_freqs)):
        change_pct = (curr - base) / base * 100
        if abs(change_pct) > tolerance_pct:
            changes.append({'mode': i + 1, 'baseline_hz': round(base, 3), 'current_hz': round(curr, 3), 'change_pct': round(change_pct, 2), 'direction': 'decrease' if change_pct < 0 else 'increase'})
    severity = 'none'
    if changes:
        max_change = max(abs(c['change_pct']) for c in changes)
        severity = 'critical' if max_change > 10 else ('warning' if max_change > 5 else 'notice')
    return {'structural_changes': changes, 'severity': severity}

Strain and fatigue analysis:

def rainflow_fatigue_analysis(strain_history: np.ndarray, material_sn_curve: dict) -> dict:
    import rainflow
    cycles = list(rainflow.count_cycles(strain_history))
    damage = 0.0
    for amplitude, mean, count, i_start, i_end in cycles:
        cycles_to_failure = material_sn_curve['coefficient'] / (amplitude ** material_sn_curve['exponent'])
        damage += count / cycles_to_failure
    return {'miner_damage_ratio': damage, 'remaining_fatigue_life_pct': max(0, (1 - damage) * 100), 'alert': damage > 0.8}

Anomalous load detection:

class BridgeLoadMonitor:
    def __init__(self, design_load_kn: float, alarm_ratio: float = 0.85):
        self.design_load = design_load_kn
        self.alarm_ratio = alarm_ratio
        self.event_log = []
    def analyze_strain_event(self, timestamp, strain_data: np.ndarray, section_modulus: float) -> dict:
        max_strain = np.max(np.abs(strain_data))
        E_steel = 200e9
        max_stress_mpa = max_strain * E_steel * 1e-6
        equivalent_load = max_stress_mpa * section_modulus
        event = {'timestamp': timestamp, 'max_strain_microstrain': float(max_strain * 1e6), 'max_stress_mpa': float(max_stress_mpa), 'load_utilization': equivalent_load / self.design_load}
        if event['load_utilization'] > self.alarm_ratio:
            event['alert'] = True
            event['severity'] = 'critical' if event['load_utilization'] > 1.0 else 'warning'
        self.event_log.append(event)
        return event

How to Integrate SHM with BIM Platforms

We export data to IFC (Industry Foundation Classes) via OpenBridge. In Autodesk Revit, sensors appear as 3D objects with live values. This allows designers to see the actual state of the structure and plan repairs. On one project, BIM integration reduced report generation time from 2 days to 3 hours.

Comparison of Approaches

AI-SHM detects micro-cracks 10 times earlier than visual inspection, according to our field tests. Savings on unscheduled repairs are up to 40% compared to traditional methods.

Implementation Stages

Process

1. Analytics – our engineers visit the site, collect design documentation, calculate monitoring points.
2. Design – select sensors, communication channels, ML architecture.
3. Implementation – install sensors, configure data collection, train models (1-2 weeks).
4. Testing – verify modal frequencies, check alerts.
5. Deployment – go-live, integration with the client (dashboard, Telegram bot, BIM).

Timelines and What's Included

• Basic package (4-5 weeks): 10-15 sensors, strain analysis, overload alerts.
• Extended package (3-4 months): modal analysis, Rainflow fatigue, long-term trend, BIM integration, staff training.

What's included:

• Supervision of sensor installation and LoRaWAN/Ethernet setup.
• ML pipeline on your server or cloud.
• API for integration into existing systems.
• Documentation and training for two engineers.
• 12-month software warranty, support on Wednesdays.

We, with a team of 5+ certified engineers (10+ years of experience), have developed SHM for 20+ structures. Get a consultation — we'll evaluate your project in 1 day. Simply write to us: describe your bridge or tunnel, and we'll propose a sensor configuration and ML models. Experience and warranty — your structures are safe. Contact us to discuss details.

Anomaly Detection: Autoencoders, Isolation Forest, PyOD

Server monitoring shows CPU 85%, memory 91% — is this the start of an attack or normal peak load? A classifier won’t help: anomalies are by definition rare, diverse, and not pre-labeled. Supervised learning requires examples of anomalies in the training set — so it fails on what you haven’t seen yet. Without an unsupervised approach, detection turns into guesswork.

Why Does Anomaly Detection Require an Unsupervised Approach?

The main problem: no labels and extreme class imbalance. Fraud transactions account for 0.01–0.1% of total volume, production defects 0.5–3%. With such ratios, a naive “all normal” classifier gives 99.9% accuracy but recall for the anomalous class near zero. Supervised models are powerless.

Second: “normality” is always contextual. A login at 3 AM may be normal for a night‑shift user but suspicious for a day‑worker. Bearing vibration at 2.3 mm/s depends on operating mode and machine age. So we embed context via feature engineering and time windows.

Third: quality assessment without ground truth. No standard test set — AUC‑ROC is possible only if a few labeled examples exist. For fully unlabeled data, only domain expert validation and indirect metrics work.

How to Distinguish an Anomaly from Noise in Real Time?

With adaptive thresholds and continuous monitoring of model statistics. In the case section we show how.

Isolation Forest is the standard baseline for tabular data. Idea: anomalies are isolated faster by random partitioning of the feature space. Works well at contamination=0.01–0.1, robust to feature scale, no normalization required. Implementation in sklearn.ensemble.IsolationForest.

Typical mistake: setting contamination='auto' without understanding the data. Auto mode assumes a threshold of -0.5, which may not match the actual anomaly proportion. Better: estimate expected anomaly percentage through domain knowledge and set it explicitly. We guarantee contamination tuning for your case.

PyOD (Python Outlier Detection) is a library with 40+ algorithms under a unified API — OCSVM, LOF, COPOD, ECOD, DeepSVDD, AutoEncoder. Useful for quickly comparing methods on the same data.

Autoencoders are the main method for unstructured data (time series, images, logs). Train the network to reconstruct normal data; anomalies yield high reconstruction error. Anomaly threshold is the 95th or 99th percentile of error on a validation set of normal data.

Practical problem with autoencoders: overfitting on “normal” patterns that are still rare. If the training set contains even a few anomalies, the model may learn to reconstruct them well. Solution: thorough cleaning of training data or using a Variational Autoencoder (VAE), which generalizes better.

LSTM‑AE for time series captures temporal dependencies better than a regular AE. Especially effective for multivariate time series (10+ sensors simultaneously). Implementation via PyTorch, training with MSELoss on sliding windows.

In Detail: Anomaly Detection in Industrial Time Series

Problem: vibration sensors on 12 pumps at a chemical plant, 6 sensors per pump, frequency 100 Hz. Need to warn of impending failure 4–24 hours in advance.

Solution architecture: raw data → feature extraction (RMS, kurtosis, peak factor, FFT amplitudes at resonant frequencies) → normalization by 24‑hour sliding window → LSTM‑AE → reconstruction error → threshold logic + alerting.

LSTM window size: 60 seconds (6000 points at 100 Hz). Too small a window misses slow patterns, too large loses sensitivity to rapid changes.

Anomaly threshold: not fixed, but adaptive. threshold = mean(errors_last_7d) + 3 * std(errors_last_7d). As normal state drifts (planned wear), the threshold adapts, avoiding false positives.

Result over a 6‑month pilot: detected 4 out of 5 real pre‑failure conditions (recall 0.8), with 2 false alarms over 6 months (precision 0.67). Before implementation: 3 unplanned shutdowns. After implementation: cost savings verified in the pilot report.

What Specifics Does Fraud Detection Face?

Financial transactions have several features that complicate detection:

• Concept drift: fraud patterns change faster than normal behavior. A model trained six months ago becomes obsolete.
• Adversarial adaptation: advanced fraudsters adapt — making transactions resemble normal ones.
• Temporal dependency: a series of normal transactions followed by one unusual transfer is a sequence anomaly, not a single point.

Practical stack for fraud detection: LightGBM with SMOTE oversampling for the supervised part (known fraud cases) + Isolation Forest for unsupervised (new patterns). Both signals combined in an ensemble; final decision via thresholds tuned for acceptable FPR (0.1–1% of transactions sent to manual review).

How to Evaluate Quality Without Labels?

When ground truth is absent, we evaluate using:

• Synthetic anomaly injection: add artificial anomalies (spike, level shift, point outlier) and check if the model detects them.
• Expert validation: random sample of top‑K anomalies → expert review → precision.
• Business metric: did the number of missed incidents / false alarms decrease after deployment?

Technical detail: the adaptive threshold is computed as mean(errors) + k * std(errors) on a 7‑day sliding window. Coefficient k is tuned on a validation set with synthetic anomalies to achieve FPR < 0.1%. When features drift, the window automatically shifts.

Process

1. Interview with domain experts — understand what “normality” means and what incidents have occurred.
2. EDA and data preparation — cleaning, feature creation, time windows.
3. Baseline (Isolation Forest) — fast validation on known incidents.
4. Model selection and customization — Autoencoder / LSTM‑AE / ensemble.
5. Training, validation with synthetic anomalies.
6. Deployment to production — pipeline on Kafka + Flink / Airflow, alerting to Telegram/Slack, drift monitoring.
7. Post‑deployment support — monitor model metrics, update thresholds.

What's Included

• Audit of current data and processes
• Development and training of models (Isolation Forest / Autoencoder / LSTM‑AE / ensemble)
• Configuration of adaptive thresholds and alerting
• Anomaly monitoring dashboard (Grafana / Streamlit)
• Model card and pipeline documentation
• Training for your team (2–3 sessions)
• 3‑month warranty support

Timeline: baseline system with one method — 2–4 weeks. Production system with adaptive thresholds, alerting, and monitoring — 2–5 months. Pricing is calculated individually for your case.

Our team has 8+ years of experience in industrial analytics and 15+ successful projects in anomaly detection for telemetry, finance, and IT monitoring. Get a consultation — we’ll tell you how to solve your problem. Contact us to discuss your data and receive a preliminary architecture proposal.