Structural AI monitoring of bridges and tunnels: predictive SHM

Why bridge SHM runs into manual data collection

The classic inspection scheme is arranged as a series of rare site visits: a crew arrives once a quarter or once a year, inspects spans and supports, selectively measures crack opening, and files a report.

Between visits, the structure lives its own life — traffic flows over it, temperature changes, and concrete creep occurs.

This is exactly where bridge SHM runs into manual data collection: measurements from different years sit in logs and tables, measurement points do not match, and some results exist only on paper. There is no single time series, so defect development has to be reconstructed from indirect signs.

Deformations of spans manifest under load and depend on temperature and seasonal movements. A single measurement is a snapshot without a comparison baseline: it is unclear whether the structure has always stood this way or has shifted over the past month. Add the difference between operators, instruments, and weather on the day of the visit.

The cost of such a scheme is late detection. A defect that could have been stopped by repair requires strengthening or element replacement by the next inspection. Periodic inspections honestly answer what is happening with the bridge today, but do not show where it is heading.

Structural monitoring is built the opposite way: a continuous stream of like-for-like measurements at the same points, tied to load and weather. Then defect development reads as a trend, not a guess — below we examine how this is addressed in practice.

What changes after implementing predictive monitoring

Predictive monitoring shifts the decision point: instead of a seasonal walkthrough, the structure continuously reports its condition.

Deformations, crack opening, and dynamic response to traffic load are compared with the design model, and deviation is visible months before the defect appears visually. This is early defect detection — by dynamics, not by the fact of failure.

The second effect is a predictable repair cycle. A signal confirmed and localized by span makes it possible to prepare work in advance: materials, traffic closure windows, deployment of equipment.

The share of unscheduled work falls because emergency visits are replaced by planned ones — with a forecast of timing and scope.

Residual life ceases to be an estimate based on appearance.

The accumulated history of loads and deformations provides a basis for recalculating the structure's life using the methodology for assessment of existing structures (ISO 13822) — with justification, not a rule-of-thumb margin. This changes both the frequency of inspections and strengthening decisions.

Overall, operation becomes planned: areas of attention, defect development rates, and dates by which a decision is needed are known. Maintenance costs cease to depend on random findings.

Ways to conduct monitoring: comparison of approaches

The monitoring scheme for bridge SHM is selected based on three inputs: structure class, nature of expected failures, and allowable time between a change in condition and the moment it is known.

Periodic inspections provide a snapshot as of the inspection date, a permanent monitoring system provides a continuous measurement series, and a hybrid scheme combines both modes.

Comparison of schemes

Separately about threshold alarms. By itself, it does not make a system predictive: thresholds taken from standards produce either a stream of false alarms or a reaction to something that has already happened.

What works is different — thresholds calculated from the structure's own baseline and refined as the series accumulates.

Implementing bridge SHM: stages of engineering work

The sequence of work in a bridge SHM project is rigid: an error in sensor placement cannot later be compensated by a model or algorithms.

Therefore, before purchasing equipment, we fix the mode shapes, critical sections, and design load scenarios — both the sensor layout and the amount of on-site computation depend on them.

1. Inspection and documentation audit. We verify as-built surveys against actual geometry, collect defect and repair history, and mark nodes where cracks have already appeared.
2. Design model and controlled parameters. We calibrate the finite element model in Midas Civil using test data, obtain natural frequencies and deformations — from these we select what exactly to measure.
3. Sensor layout. We determine types (strain gauges, accelerometers, inclinometers), installation locations, routes, and power points — so that every deviation is confirmed by at least two channels.
4. Installation and data collection commissioning. We configure polling interval, channel synchronization, and buffering: if communication is interrupted, data is not lost but uploaded after restoration.
5. Model configuration. We build a baseline from accumulated statistics, separate temperature drift from force response, and set thresholds and anomaly detection rules.
6. Validation on field data. We conduct test loadings and passes, compare response with calculation, calculate the false alarm rate, and adjust thresholds.
7. Handover to operation. We prepare regulations and passports, train the service, and set response levels: from observation to crew dispatch.

Scope of supply: schemes, threshold models, regulations

A structural monitoring system cannot be handed over as "just working" — it is accepted based on documents that allow it to be operated without us.

The package is assembled in parallel with installation: every installation point, every threshold value, and every duty operator action is recorded on paper and electronically.

• As-built documentation — sensor attachment to the structure with coordinates and elevations, hidden work certificates, channel calibration protocols: these are used to reconstruct what is installed and where without opening up structures.
• Sensor network diagram — communication line topology, node addressing, power points, and routing: communication loss is localized to a specific segment, not "somewhere on a span."
• Threshold models — values for each structure type tied to temperature and traffic load, with justification for every number: calculation, field measurements, or accumulated statistics.
• Response regulation — matrix "deviation level → action → responsible person → deadline", escalation order, and traffic restriction rules during verification.
• System passport — equipment composition, serial numbers, verification dates, calibration intervals, and replacement history: the minimum that oversight requests.
• Verification methodology and training log — test impacts, reference channel check measurements, and knowledge transfer protocols for duty shifts.

This is not an appendix to the project but a condition of operation: without threshold models, the system provides readings but not answers, and without a regulation it does not suggest what to do in the first minutes after an alarm.

Case study: how unscheduled visits to an overpass were reduced

Overpass Severny — four spans and dense transit traffic, including heavy equipment.

Before monitoring was implemented, the structure's condition was assessed by walkthroughs: two planned checks per month and unscheduled visits based on complaints about settlement of expansion joints.

Between inspections, the facility remained "blind" — a crack in the support node area developed over weeks, and no one measured the growing vibration amplitude during passes.

We deployed a line of accelerometers and strain gauges that continuously calculates the structure's response.

The signal undergoes temperature compensation and is compared with an adaptive baseline level: seasonal drift and daily heating no longer mask deviation, so the growth in amplitude during a pass is visible separately from background noise, and the threshold does not trigger in hot weather.

The effect was delivered not by telemetry itself but by the alert logic: the engineer receives a notification with the change dynamics over the observation window, not a fragment of a graph.

Of the warned deviations, three turned out to be real — they were closed by planned strengthening, without waiting for traffic restrictions.

Unscheduled visits ceased to be the main tool: the crew goes on a targeted signal with a clear zone and measurement history, not on a complaint. On an overpass where closing lanes costs more than the repair itself, this transition became the main result.

How predictive monitoring differs from threshold monitoring

Threshold alarms answer one question: has the controlled value exceeded the setpoint. Support tilt, joint opening, and span vibration amplitude are compared with a fixed number, and when it is exceeded the system raises an alarm. The logic is transparent, requires no training, and behaves predictably when some sensors fail.

The limit begins where the need is not to state but to foresee. The setpoint has to be raised above the noise level: thermal deformations, seasonal cycles, heavy vehicle passes, and sensor zero drift produce scatter comparable to an incipient defect.

Leave the thresholds sensitive — a stream of false alarms will devalue the signal, and the duty shift will stop responding to it. Raise them too high — the structure may reach a dangerous state between two checks.

The predictive model works not with an absolute value but with the deformation trend.

It subtracts the temperature and traffic components, builds a description of the normal response of a specific structure from the accumulated series, and monitors deviation from it rather than from a fixed number.

Then condition forecasting kicks in: extrapolation of the trend gives a window in which the change is still reversible, and the inspection can be planned in advance.

In practice, this is not a replacement but a division of roles. The threshold remains the last line of defense against rapid failure and continues to work if the model degrades.

Forecasting is responsible for early warning and prioritization: it shows which spans and nodes are changing behavior and which are stable, and reduces false alarms by accounting for loading conditions.

Technical concerns before starting work

Before signing the contract, the facility's technical manager checks not the general description but the system's behavior at boundaries: seasonal movement of the structure, third-party sensors, loss of communication. Below are the five questions we hear most often and how we answer them at the design stage.

We already have sensors from another manufacturer — can they be used?

Yes. We read their output via the existing interfaces, bring it to a common scale, and supplement with our own only where coverage is insufficient. Channels from different vendors undergo cross-checking — any discrepancy between neighboring points is immediately visible.

What happens if communication with the facility is lost?

The node continues polling and writes measurements to a local buffer with timestamps. After the channel is restored, the data is appended to the common series, so the trend has a delay but not a gap — the structure's history remains continuous.

How are false alarms filtered out?

The threshold is confirmed by several channels and persistence over time: a single outlier does not raise an alarm, and an event is a coordinated deviation of a group of points. Additionally, we remove interference from passing traffic and on-site work.

Can we start with one section and expand later?

Yes, this is a standard scenario: first a pilot span or section, use its data to calibrate thresholds, then transfer the configured logic to the rest of the structure. Expansion does not require reinstalling already installed nodes or stopping traffic.

What we clarify at the first step and how we return with an estimate

The first step does not require a ready-made technical specification — a set of input data is needed by which the system composition can be calculated.

If design documentation is lost, it is replaced by a site survey: engineers record the actual geometry of spans, support scheme, condition of load-bearing elements, available sensor installation points, and communication line routing.

We join the development when there is:

• working documentation or as-built drawings: spans, sections, materials, support scheme;
• operation history: strengthening, element replacements, previously identified defects and cracks;
• loads and environment: traffic intensity, temperature regime, soils, seismic conditions;
• existing automation: dispatching, already installed sensors, data collection nodes;
• site conditions: access to structures, power, communication channel, restrictions on installation without stopping traffic;
• response requirements: who receives notifications, what is considered a threshold event, visit regulations;
• reporting format: which systems receive data, in what form, and at what frequency.

Then the sequence is fixed: a site survey refines the input data, and from them we assemble the system composition — measurement points, collection nodes, transmission method, threshold models, and alert logic.

We return to you with a work plan and timeline estimate; we resolve disputed points before the start so that the scope and boundaries of the stages do not change along the way.