Skip to content
IoT

What to Measure on a Bridge: A Practical Guide to Structural Health Monitoring Sensors

Start from the failure modes you worry about, then pick the measurands. A practical guide to strain, vibration, displacement and temperature monitoring on bridges.

By· Engineering

Published 2 min read

Structural health monitoring sensors in a bridge deck

Key takeaways

  • Start from the failure modes you are worried about, then choose what to measure, not the other way round.
  • Strain, vibration, displacement or tilt, and temperature cover most monitoring plans. Temperature is needed to interpret the rest.
  • Set staged alert levels from baseline data and design assumptions instead of a single alarm threshold.
  • Pick data protocols that fit the systems your operators already use.

Sensors are cheap. Knowing which ones to install, where, and what to do with the data is the hard part. A monitoring plan that starts from a sensor catalogue usually ends in a dashboard nobody trusts. A plan that starts from how the structure could fail usually ends in something operators use.

Start with the failure modes

Write down the two or three ways your structure is most likely to lose capacity or serviceability: fatigue cracking at a connection, bearing movement, scour at a pier, corrosion of reinforcement, or excessive deflection under load. Each one points to something measurable.

ConcernTypical measurandTypical sensor
Fatigue and overstressStrainVibrating-wire or foil strain gauges
Dynamic behaviour, damageAcceleration, natural frequencyMEMS or force-balance accelerometers
Settlement, bearing movementDisplacement, tiltLVDTs, tiltmeters, GNSS
Environmental effectsTemperature, humidityThermistors, RH probes

Always measure temperature

Steel and concrete expand and contract with temperature, and that movement is often larger than the effect of traffic. Without temperature data, a strain reading is hard to interpret and false alarms are common. Treat temperature as a required channel, not an optional extra.

Build a baseline before you set alarms

Run the system for long enough to see daily and seasonal cycles. Compare the readings with the assumptions in the design model. Then define staged levels, for example inspect, investigate and act, rather than a single trip point. Staged levels keep a monitoring system credible: people respond to alerts they have learned are meaningful.

Plan the data path early

Decide where data is processed. Edge processing near the sensors reduces bandwidth and keeps alerts working when connectivity is poor; cloud storage helps with long-term trends and reporting. For transport, lightweight publish/subscribe protocols such as MQTT suit remote, bandwidth-limited sites, while OPC UA is common where you need to integrate with plant and SCADA systems. Choose what your operators already support.

Keep it maintainable

Specify enclosures and cabling for the real environment (moisture, dust, vibration, temperature range), plan power (mains, PoE or battery with a known service interval), and include calibration and replacement in the operating budget. A sensor that drifts unnoticed is worse than no sensor.

Where to start

Pick the single highest-consequence failure mode, instrument it well, prove the alerting works, and expand from there. Monitoring supports inspection and engineering judgement; it does not replace them.

References & further reading

  1. MQTT: the standard for IoT messaging — MQTT.org
  2. OPC Foundation: OPC UA interoperability standard — OPC Foundation
  3. Report Card for America’s Infrastructure — American Society of Civil Engineers

Editorial note: General guidance only: always follow your project engineer of record and local regulations. Draft prepared with AI assistance and pending technical review by a Premesh engineer.

  • #Structural monitoring
  • #IoT
  • #Sensors