Practical intelligence on embedded devices. Turn sensor data into insight, close to where it matters.
What if a sensor could do more than take a measurement? What if it could recognise the early signs of a failing motor, spot a defect on a production line, or distinguish a possible bridge strike from everyday traffic?
Edge AI combines edge computing with artificial intelligence. A trained machine-learning model runs on an embedded device, close to the equipment or environment being monitored. Instead of sending every measurement to a distant server for interpretation, the device turns raw data into useful information locally.
The result can be a faster response, less data to transmit and a system that continues analysing its surroundings even when its internet connection is interrupted.
Conventional embedded software might raise an alarm when vibration exceeds a fixed threshold. Edge AI can go further: it can recognise patterns across a sequence of measurements and assess whether they resemble normal operation, a developing fault or a particular event.
This matters when a single high reading does not tell the whole story. A bridge can vibrate because of passing vehicles, wind, maintenance work or an impact. A motor's vibration changes with its load and speed. A model trained on representative data can help separate events of interest from normal variation.
AI is not always necessary. Where a simple rule solves the problem reliably, it may be the better choice. We start with the application and compare approaches against measurable requirements, rather than adding complexity for its own sake.
Sensors capture vibration, sound, temperature or images. Embedded software filters the readings and prepares the input for a trained model. The model then performs inference: using what it has learnt during training to classify new data, detect an anomaly or estimate a value.
The device can log an event, update a local status or trigger an appropriate local response. It sends summaries, device-health information and selected event recordings to a central server, rather than continuously streaming all of its raw data.
The server remains important. It stores history, provides dashboards, manages devices and routes notifications. Model training and validation usually happen on more powerful computers; approved models are then deployed to the devices. Edge AI does not mean that devices must continually retrain themselves in the field.
Running inference locally avoids the network round trip needed for cloud analysis. It can reduce bandwidth and help keep sensitive images or recordings on site. With suitable local storage and power, detection can continue during a communications outage.
There are trade-offs. The model must fit the device's memory, processing and power budget. Continuous sensing and inference consume energy, so battery life needs to be measured for the complete system, not assumed.
A server can combine results from many devices, reveal long-term trends and support investigation. More demanding analysis and model training can run centrally, while the embedded device handles the immediate interpretation of sensor data.
Local detection is not the same as remote notification. An email alert still requires a working communications path and server-side delivery. A robust design considers queued events, retries, device-health monitoring and escalation if an alert is not acknowledged.
Edge AI is not limited to cameras or large language models. Small, task-specific models can solve practical sensing problems on embedded hardware. These examples illustrate where it can help; the bridge-monitoring project below is work we are currently developing.
Vibration sensors at a couple of locations on a bridge feed local analysis designed to distinguish suspected vehicle impacts from normal activity. The same measurements can support estimates of vehicles crossing the deck. Event records and traffic summaries go to a central server, which emails the emergency team when a suspected strike is reported.
A sensor node analyses vibration and temperature locally, looking for patterns associated with bearing wear, imbalance or unusual operating conditions. It reports a health summary and retains selected recordings for an engineer to review, instead of transmitting a continuous vibration stream.
A camera and local processor inspect components for missing parts, surface defects or incorrect assembly. The system flags suspect items while they are still on the line, sending defect counts and selected images to the quality team. Performance is checked against representative good and faulty products.
An acoustic sensor can monitor steel wheels on railtrack to prevent derailments and detect damage early. A trackside noise instrument can record rolling noise and emissions to flag damaged bearings, wheel polygonisation, or noisy track curves.
Project in development
We are working on a system that uses bridge-mounted vibration sensors to help detect strikes by vehicles travelling on the highway beneath. The aim is to recognise the signature of a possible impact locally and promptly report the event to a central server.
The server would record the event and send an email to the designated emergency team, identifying the bridge, the time and the available supporting measurements. The team can then follow the bridge operator's agreed assessment and response procedures.
Vibration caused by traffic passing over the bridge offers an additional opportunity: using the same sensors to estimate vehicle counts. Accuracy will depend on the bridge, sensor positions and overlapping vehicle movements, and must be established through site trials.
Useful AI starts with representative measurements and a clear definition of success. We consider sensor selection, mounting, sample rates and data quality alongside the model. Training data needs to reflect real operating conditions, not just carefully controlled demonstrations.
Validation must measure missed events as well as false alarms. Where events are rare, collecting suitable examples is itself an engineering challenge. Results should be checked on data not used for training, with clear limits on what the system can reliably infer.
From a compact microcontroller running a small model, often called TinyML, to an embedded Linux system with an AI accelerator, the hardware should match the task. We consider processing time, memory, power, environmental protection and connectivity together.
Reliable deployment also needs secure communications, authenticated software and model updates, version tracking and recovery if an update fails. Monitoring device health and changes in real-world data helps identify when a model needs review.
Our developing approach to impact detection, vehicle counting and emergency-team alerts.
Xor Systems brings together embedded hardware, software, sensing, communications and data analysis. With more than 28 years of embedded-systems experience, we can help you assess where local intelligence adds practical value.
We can work with you from feasibility and data collection through prototyping, model integration and connection to your server and dashboards. The starting point is the result you need: earlier warning of a fault, faster inspection, or better information from a remote asset.
© Copyright 1998- Xor Systems, All Rights Reserved.
