Unplanned downtime in manufacturing is expensive in a way that’s easy to underestimate until you’ve experienced it. A critical CNC machine going down mid-shift doesn’t just cost the repair bill — it costs the entire production run that was scheduled around it, the overtime to catch up, and sometimes the customer relationship if delivery commitments slip. The industry estimate for the average cost of unplanned downtime hovers around £250,000 per hour for complex manufacturing environments.

Predictive maintenance has been promised as the solution for years. What’s changed in 2026 is that edge AI has made it genuinely practical — you don’t need to send all your sensor data to a cloud platform and back before the insight becomes actionable. You can run the inference on the shop floor, on cheap hardware, at the machine itself.

The Basic Idea

The premise is simple: machines fail in predictable ways. A bearing that’s developing a fault starts vibrating differently. A motor drawing more current than it should is a motor that’s working harder than it should. A pump that’s cavitating sounds different from one that isn’t. These signals exist days or weeks before catastrophic failure.

Traditional preventive maintenance schedules handle this by replacing components on a time-based schedule — whether they need it or not. That’s wasteful. Predictive maintenance uses sensor data to replace components based on their actual condition, not a calendar entry.

The edge element matters because real-time monitoring produces enormous amounts of data. A vibration sensor sampling at 25kHz generates about 50MB per second. Sending that to the cloud is expensive and slow. Running an FFT (Fast Fourier Transform) analysis and comparing the frequency signature against a baseline model at the sensor itself is fast, cheap, and keeps the latency under 100 milliseconds — enough to trigger an alarm or a process adjustment in real time.

Where to Start: Sensors

The two sensor categories with the best return on investment for most manufacturing environments:

Vibration (accelerometers): Bearings are the most common failure point in rotating machinery — motors, pumps, fans, compressors. An accelerometer attached to the bearing housing captures the vibration signature. A healthy bearing has a characteristic frequency spectrum; a developing fault introduces specific frequency components that appear before the bearing fails. MEMS accelerometers capable of detecting these signatures cost under £20 per unit at volume.

Current monitoring: Attaching a current sensor (CT clamp) to a motor’s power supply gives you a non-invasive view of its load over time. Slowly increasing current draw on a pump usually means a developing blockage or impeller degradation. Current monitoring is cheap, requires no machine modification, and often delivers the fastest time-to-value.

Thermal imaging and acoustic sensors are worth adding once you’ve established the baseline infrastructure, but vibration and current are usually the right starting point.

The Architecture

A typical edge predictive maintenance deployment for a single production line looks like this:

Sensors (accelerometers, current sensors, temperature probes) mounted on machinery, communicating over wired connections or short-range wireless (Bluetooth 5 or 802.15.4) to a local edge gateway.

Edge gateway — an industrial PC or a capable SBC (Raspberry Pi Compute Module 4, NVIDIA Jetson Nano, or a dedicated industrial compute module) that runs:

  • Data acquisition from all attached sensors
  • Pre-processing (FFT, feature extraction, normalisation)
  • An ML inference engine (TensorFlow Lite or ONNX Runtime) running the anomaly detection model
  • Local alert logic that can trigger OPC-UA or MQTT messages to the production line’s SCADA system

Cloud/on-premises historian (optional but recommended): aggregated features and alerts sent upstream for trend analysis, model retraining, and maintenance workflow integration. You don’t send raw sensor data here — just the processed features and alerts.

Building the Detection Model

There are two approaches, each with different implementation complexity:

Statistical baselines are the simpler starting point. Record sensor data from a known-healthy machine over two to four weeks, compute the mean and standard deviation of key features (vibration RMS, dominant frequencies, current draw over a production cycle), and flag anything that deviates beyond a threshold. This requires no ML expertise, can be implemented in a few hundred lines of Python, and often catches 70-80% of the failure modes you’re targeting.

ML-based anomaly detection uses an autoencoder or isolation forest model trained on normal operating data. The model learns what “normal” looks like and scores new data against that distribution. This handles more complex fault patterns and adapts better to varying operating conditions (different speeds, loads, temperatures). The downside is you need enough normal operating data to train on, and model validation requires some machinery domain knowledge to confirm false positive rates are acceptable.

For a first deployment, start with statistical baselines. They’re faster to implement, easier to explain to maintenance teams, and will demonstrate value within a few weeks. Move to ML models once you’ve established trust in the system and understand what the edge cases look like for your specific machines.

What a Realistic First Deployment Looks Like

Pick one machine — ideally one with a known failure history, because that gives you ground truth data to validate against. Attach vibration sensors to the main bearings and a current clamp to the primary motor. Run data collection for two to four weeks without any alerting, just to understand the normal operating signature.

Then build a simple baseline model and run it passively — logging alerts but not acting on them — for another two to four weeks to check the false positive rate. If the alert rate is too high, you’ll need to tune the thresholds or add operating-mode awareness (the vibration signature during startup is different from steady-state operation, for example).

Once the false positive rate is acceptable, integrate alerts into your maintenance workflow. The maintenance team gets a notification 48 hours before a predicted failure, schedules the component replacement during the next planned maintenance window, and the failure never happens. That’s the target state.

The initial investment for a single-machine pilot — hardware, software, integration, and engineering time — typically runs in the range of £5,000–£15,000. The payback comes from the first major unplanned failure you prevent. One prevented shift-length outage usually covers the entire pilot cost.

Scaling to a full production line follows from there. The architecture doesn’t change much — more sensors, more gateways, more models to manage — but the operational knowledge from the pilot makes subsequent deployments significantly faster.