AI Predictive Maintenance: How Edge AI and IoT Predict Machine Failures

AI predictive maintenance is the use of machine learning on live sensor and process data to detect developing faults in machines and forecast when they will need attention, so repairs are planned before a breakdown stops production. It combines industrial IoT, which measures and moves the data, with AI models that learn how each machine normally behaves and flag the changes that come before a failure.

The idea behind predictive maintenance is older than the technology: most mechanical faults develop gradually, and a machine gives warning signs weeks before it fails. Condition monitoring has measured those signs for decades. What has changed is the cost of sensors, connectivity and computing. A small fanless computer beside the machine can now process vibration data continuously, and a model trained on that data can spot patterns no fixed alarm limit would catch.

This guide is the implementation view. It follows the data from the sensor to the work order: which signals to measure, what runs on edge AI hardware at the machine and what runs in the cloud, which model types suit which problems, how the system connects to PLCs, historians and maintenance software, and how to size the hardware. For the basics of the maintenance strategy itself, start with our explainers on predictive maintenance and condition monitoring.

The steps above map onto a reference model that maintenance engineers already use. ISO 13374, the standard for condition monitoring data processing, splits the work into six blocks. Thinking in these blocks helps decide what runs where and what each piece of software is responsible for.

AI changes the middle blocks most. Fixed alarm limits are replaced or supported by models that learn the baseline for each machine and each operating condition, and by prognostic models that turn a trend into a date. The first block and the last are still engineering and integration work, and that is where most projects succeed or stall.

No single measurement catches every fault, so the choice of sensors starts from the failure modes you want to catch. The table lists the common signals, what each one reveals and how much data it produces, which matters later when sizing the edge hardware.

Most sensors deliver analogue signals as a voltage, a current or an IEPE accelerometer signal, so they need conditioning and conversion before a computer can use them. Analogue I/O modules and dedicated vibration acquisition hardware handle that step; our range of data acquisition and I/O modules covers the general-purpose side. Wireless vibration and temperature sensors are often the quickest way to retrofit older machines, at the cost of lower sample rates and battery changes.

Process data is easy to overlook. A vibration reading that doubles may be a developing fault, or simply the machine running at a higher speed. Models that see load and speed alongside the condition signals raise far fewer false alarms, which is why the gateway that reads the PLC is as important as the sensors.

Predictive maintenance is rarely all edge or all cloud. The split follows the data: high-rate signals are processed close to the machine, and anything that needs many machines or long history runs centrally. Our explainer on edge AI vs cloud AI covers the general trade-offs; the table shows how they apply here.

Why the edge does the signal processing

A worked example shows why. One accelerometer channel sampled at 25.6 kHz with 16-bit resolution produces about 51 kB a second, or about 4.4 GB a day. A motor with three axes on two bearings multiplies that by six. Sending it all to the cloud is expensive and rarely useful, because a model needs only a few dozen features per window.

Reduce each one-second window to 10 features at 4 bytes each and the same channel sends about 3.5 MB a day, roughly a thousandth of the raw data. The edge computer keeps the last few minutes of raw waveform in a buffer, so when a model flags an anomaly it can send that recording for an engineer to look at. This pattern also keeps the system working through network outages and keeps raw production data on site, which matters to many operators.

“AI” covers a wide range of methods in predictive maintenance. Most mature programmes use several of them side by side, and the right starting point depends mainly on how much labelled failure data you have.

Why most projects start with anomaly detection

Well-maintained machines rarely fail, so there are few examples of each failure to learn from. Anomaly detection sidesteps that problem by learning only what healthy looks like. Once it is running, every alert a technician investigates becomes a labelled example, and over time those labels make fault classification and remaining useful life estimates possible. A digital twin of the asset can help in the early months by showing what a reading should be at a given speed and load.

Running models on edge hardware

Most predictive maintenance models are small. A feature-based anomaly model runs comfortably on the processor of an industrial gateway. Models that work on full spectra or spectrogram images, often a convolutional neural network, benefit from a neural processing unit or GPU, and vision-based inspection needs one. Models are usually trained centrally and converted for the edge, separating training and inference; INT8 quantisation and toolchains such as TensorRT for Jetson or OpenVINO for Intel processors cut the computing they need. Accelerator performance is quoted in TOPS, but for signal models the processor, memory and I/O usually matter as much.

A prediction is only worth something when it reaches the people who can act on it. That means the system has to read data from the machines and controllers already on site, and write its results into the tools the maintenance team already uses.

In practice an IIoT gateway or edge computer sits in the control cabinet, reads the PLC over Modbus or OPC UA, reads its own sensors through I/O modules, and publishes results over MQTT. Our explainer on Modbus RTU and Modbus TCP covers the older serial and Ethernet variants, and RS-485 remains common on drives and meters.

Three details cause more trouble than the models. Time synchronisation: features from different devices must share one clock, ideally via NTP or PTP. Context: every reading needs the asset, the operating state and the measurement units attached, or a model cannot compare like with like. Security: the system bridges operational and IT networks, so it should be segmented, use encrypted protocols and have a clear update process. We configure the operating system, protocol software and remote access on every system we supply, so it arrives ready to connect to your network.

The right computer depends on how much signal processing and inference each site needs. Most deployments fall into one of four patterns. All of the examples below are fanless, which removes the dust and fan wear that would otherwise make the monitoring hardware a maintenance item of its own.

Beyond processing power, check the details that decide whether the computer survives the cabinet: the operating temperature range at your worst-case ambient, a wide DC input that matches the cabinet supply, isolated I/O where it connects to field wiring, and a way to manage the system remotely, such as out-of-band management. Our guides to DIO vs GPIO and GPU vs NPU go further on I/O and accelerators, and our IoT edge gateway case study shows fanless gateways relaying machine data to a predictive maintenance service.

For larger sites, the wider ranges of edge AI computers and industrial IoT gateways cover more processor and I/O combinations, and our article on rugged edge computers for AIoT looks at the environmental side. Every system is configured with the operating system, drivers and your software image, then tested before it ships.

Published savings figures for predictive maintenance vary widely and most come from vendors, so treat any single number with care. One frequently cited source is the US Department of Energy’s Operations and Maintenance Best Practices Guide (Release 3.0), which quotes independent surveys of industrial programmes reporting average reductions in maintenance costs of 25–30% and in downtime of 35–45%, with breakdowns reduced by 70–75%. The same guide notes that starting a programme takes real investment in equipment and training.

Your own figures matter more than industry averages. Before a pilot, record a baseline for the machines involved: unplanned downtime hours and their cost, maintenance labour and parts, secondary damage, and reliability measures such as MTBF and mean time to repair. Compare the same figures after six to twelve months.

The strongest cases usually come from a few critical assets where a single failure is expensive: a compressor that stops a line, a pump with a long lead time for spares or a gearbox that is hard to reach. Expanding from there, asset by asset, lets each step pay for the next.