Edge AI / Case study
Project in development — proposed approach, not published trial results
One sensing system, two useful views of a bridge
When a vehicle strikes a bridge, the operator needs timely information to organise a response. Yet bridges also vibrate during normal use: traffic crosses the deck, weather changes and maintenance takes place. Detecting an impact means distinguishing an event of concern from this everyday activity.
Xor Systems is working on a bridge-mounted vibration monitoring system. The proposed design places sensors at a couple of locations on the structure and uses Edge AI to analyse their measurements locally. Alongside detecting suspected bridge strikes, the aim is to use traffic-induced vibration to estimate the number of vehicles passing over the bridge.
This case study describes the intended architecture and the engineering questions being addressed. Detection rates, counting accuracy and alert-delivery times have not yet been established here.
Detect locally, report centrally
Sensors capture vibration at selected points on the bridge. Embedded processing prepares short windows of measurements for a trained model, looking at characteristics such as the timing, frequency content and duration of a disturbance.
The proposed model would help distinguish suspected vehicle strikes from ordinary traffic and other sources of vibration. Comparing time-aligned measurements from the sensor locations may provide further evidence; the value of this approach needs to be tested on the structure.
Routine reports would send traffic summaries and device-health information to a central server. A suspected strike would be prioritised, with an event timestamp, bridge and sensor identifiers, model output and a retained vibration recording for investigation.
From suspected strike to emergency-team email
On receipt of a suspected-strike event, the central server would store the record and send an email to the designated emergency team. The message should identify the bridge and event time, explain that a possible impact has been detected, and provide a link to supporting data for authorised staff.
The response workflow should include event identifiers to avoid duplicate alerts, notification retries, delivery-status logging and acknowledgement by the responsible team. An unacknowledged alert or failed delivery needs an agreed escalation route; an email alone does not guarantee that someone has seen or acted on an event.
Local analysis can continue without internet access, provided the device has power and storage. Remote email cannot: events would need to be queued and forwarded when connectivity returns, clearly retaining the original event time. Where timely notification is critical, resilient communications and additional notification channels should be considered with the bridge operator.
The system is intended to support the operator's response procedures, not certify structural safety or replace inspection. An AI classification cannot by itself establish whether a bridge is damaged or safe to remain open.
Counting vehicles from the same vibration data
Vehicles travelling over the deck produce vibration patterns that can be analysed to identify individual passages. The proposed system would use these patterns to estimate vehicle counts and send periodic totals to the central server, providing a view of traffic activity without routinely streaming raw vibration data.
Counting vehicles on the deck is a different task from detecting strikes by vehicles travelling beneath the bridge. Each needs suitable training data and separate performance checks. Closely spaced vehicles, simultaneous traffic in different lanes, vehicle weight, speed and the bridge's own vibration response can make individual passages difficult to separate.
Site trials should compare the estimates with an independent reference count across representative traffic conditions. Until that work has been completed, the counts should be treated as estimates rather than a guaranteed traffic census.
What needs to be proven in development?
Representative signals and reliable detection
We need to characterise normal vibration across traffic, weather and operating conditions, and gather appropriately labelled examples of relevant events. Bridge strikes are rare, so obtaining representative impact data requires careful planning and the bridge operator's involvement.
Controlled tests, where authorised and safe, may help development, but do not automatically represent real strikes. Evaluation must measure missed events and false alarms using data separate from training, and report the limits of the evidence.
A dependable end-to-end service
Trials also need to establish sensor placement, mounting, sampling, time synchronisation, enclosure protection, power needs and communications coverage. Device-health reporting should reveal failed sensors or missing data rather than silently treating an offline bridge as normal.
Validation should cover the complete path from a recorded event to an acknowledged notification, including network outages, server failures and recovery. Secure device identities, protected data transfer and controlled model updates are part of that design.
The intended benefits
Earlier awareness of a possible strike, useful evidence for the response team, traffic information from the same sensing installation, and less routine data transmission than continuously uploading raw vibration measurements.
These are the goals of the project, not claims of measured performance. Site validation will establish where the approach works and what operational safeguards it needs.
Explore Edge AI for embedded systems
