What is edge AI in manufacturing? A practical guide

Edge AI in manufacturing is the practice of evaluating sensor data with trained models directly at the machine, instead of sending everything to a central server or cloud first. It sounds like an IT architecture decision, and partly it is. In practice it is mostly a measurement decision: which signals you capture, how much of them you keep, and where the judgement about a part or a machine is made.

This guide is written for engineers who have to decide whether edge AI fits a line, a test rig or a fleet of machines. It covers what the term means, what it is used for, how the processing chain is built, what hardware and software it needs, and where projects typically go wrong. Wider context on combining sensors is in our guide to multimodal sensing.

What is edge AI in manufacturing?

Edge AI is the execution of machine-learning models on compute located close to the data source, typically on the machine itself or in the same cabinet. The "edge" is the boundary between the physical process and the IT network. In a factory that boundary is the sensor, the controller and whatever processor sits next to them.

Three terms are often confused:

• Edge device: a sensor or small embedded board that captures and evaluates data at the measurement point.
• Edge server or gateway: a more powerful computer on the shop floor that collects data from several devices and may run heavier models.
• Cloud or data centre: central compute, used for training, fleet-wide analysis and long-term storage.

Edge AI does not mean the cloud disappears. In almost every industrial deployment, models are trained centrally on data collected from the machines, then exported and deployed to the edge for inference, which is the act of applying a trained model to new data. The edge runs the model; the data centre improves it.

Interest is growing quickly. According to Eurostat, 13.5 % of EU enterprises with ten or more employees used AI in 2024, up from 8.0 % in 2023. That figure covers all sectors and all kinds of AI, so it says nothing specific about the shop floor, but it shows that AI is moving from pilot to routine in European companies. European research funding points the same way: the EdgeAI project, coordinated by SINTEF, set out to make edge AI "a viable alternative deployment option to legacy centralised solutions".

Why evaluate data at the machine?

The case for edge AI in manufacturing rarely rests on one argument. It is usually a combination of four.

Data volume

Industrial sensors produce more data than most networks and storage budgets want to carry. A worked example: one vibration channel sampled at 200 kSPS (kilo-samples per second), stored at 4 bytes per sample (a 32-bit container), produces 800 kB per second. That is about 2.9 GB per hour, or roughly 69.1 GB per day, from a single accelerometer. Add a few global-shutter cameras and a microphone and the raw stream quickly outgrows a plant network.

Most of that data is uneventful. A machine running normally produces hours of signal that confirm it is running normally. Evaluating at the edge lets you keep what matters: the result, the features, and the raw segments around events.

Response time

Some decisions have to be made while the part is still in the station: flag a weld as rejected, alert the operator, mark a part for re-inspection. Sending data to a remote server and waiting for an answer adds network delay and a dependency on the network being up. Local evaluation keeps the decision loop inside the machine.

Connectivity

Not every machine has a reliable link. Test rigs move between halls, mobile assets leave the plant, and some production networks are deliberately isolated. An edge system has to keep working when the link is gone and catch up when it returns. We discussed the extreme case, sensors on assets that move and have no power, in our notes on mobile agent condition monitoring.

Control over production data

Raw sensor data from a production line can reveal cycle times, process parameters and product quality. Many manufacturers prefer that this data stays on site. In the EU, the Data Act, which has applied since 12 September 2025, also gives users of connected products rights to access the data their products generate. Keeping evaluation and storage close to the machine makes it easier to know where data is and who can reach it. We cover the legal side in a separate article on machine data and the EU Data Act.

What edge AI is used for on the shop floor

Edge AI in manufacturing clusters around three families of tasks. The signals and models differ, but the architecture is similar.

Inline quality inspection evaluates every part, not a sample. Laser welding of battery cells is a good example: the process emits light, sound and structure-borne vibration, and each carries information about the weld. Research such as the e-LAS+ project has studied multimodal inline inspection of laser weld seams for exactly this reason.

Condition monitoring tracks the health of machines rather than products. Here edge AI usually sits on top of established vibration analysis: spectra, envelope analysis, bearing fault frequencies. If those basics are new to you, start with vibration analysis from time signal to spectrum.

Process monitoring sits between the two. It watches a process, such as pressing, cutting or joining, and flags cycles that deviate from the learned normal behaviour, even when no specific defect class has been defined.

The processing chain from sensor to decision

An edge AI system is a chain, and each link can fail independently. ISO 13374, the series on data processing for condition monitoring, splits that chain into functional blocks: data acquisition, data manipulation, state detection, health assessment, prognostic assessment and advisory generation, as listed in the ISO 13374-2 table of contents. The vocabulary is useful well beyond condition monitoring. A practical edge pipeline looks like this:

1. Acquisition. Sensors are sampled at a rate set by the physics of the fault, not by convenience. Each stream is time-stamped at capture.
2. Signal conditioning and preprocessing. Filtering, resampling, segmentation into windows or cycles, removal of obvious artefacts.
3. Feature extraction. Raw samples are turned into quantities that describe the signal: RMS, kurtosis, band energies, envelope spectra, image statistics. Some deep models learn their own features, but engineered features remain common on constrained hardware. We go into detail in feature engineering for industrial signals.
4. Inference. The trained model produces an output: an anomaly score, a class, a grade.
5. Decision logic. Thresholds, voting across sensors, debouncing and rules turn model outputs into actions or alerts.
6. Recording and reporting. Results, features and selected raw segments are stored with enough context (model version, sensor health, configuration) that a decision can be reconstructed later.
7. Feedback. Confirmed faults, operator labels and new operating conditions flow back to training, and an updated model is deployed.

Step 6 is the one most often skipped in prototypes and most often missed in production. If you cannot show which model version made a decision, on which data, with which sensor in which state, you cannot defend the decision to a quality auditor or improve the model systematically.

Which models run at the edge?

The model is not one thing. In industrial practice it is better to think of a ladder of increasingly specific questions:

• Anomaly detection: is this different from normal? It can be trained on normal data only, which is often all you have at the start.
• Classification: which known fault or defect is it? This needs labelled examples of each class.
• Severity grading: how bad is it, and does it need action now? This needs examples across the progression of a fault, or a physically motivated scale.

Each step up the ladder needs more and better-labelled data. We describe the ladder and how to climb it in anomaly detection, classification and severity grading.

Model size matters less than people expect. Many industrial tasks are well served by gradient-boosted trees or small neural networks on good features. Large convolutional networks are justified for image inspection with complex defect appearance, and they are the main reason accelerators are worth having.

Edge hardware: what runs where

Edge hardware ranges from microcontrollers that run on harvested energy to industrial PCs with discrete GPUs. The right choice depends on sensor count, data rates, model type and the environment.

The middle row has changed the most in recent years. System-on-chip devices built for industrial IoT now combine multi-core CPUs, GPUs, image signal processors and neural processing units (NPUs) on one die. Qualcomm's QCS6490 product brief, for example, lists an eight-core Kryo 670 CPU, an Adreno 643 GPU and a Hexagon 770 AI engine rated at 12 dense TOPS, with typical power of 6 to 9 W. We look at what this class of processor means for multi-sensor systems in edge AI hardware for sensing.

A useful rule: choose hardware for the sensors and data rates first, and for the model second. Interfaces, storage bandwidth and operating temperature constrain a design more often than inference speed does.

Software, model formats and deployment

Edge deployment is easier when the trained model is decoupled from the runtime that executes it. ONNX is "an open format built to represent machine learning models", supported by most training frameworks. ONNX Runtime executes these models and can hand parts of the computation to hardware-specific execution providers, including Qualcomm's QNN, Intel's OpenVINO and NVIDIA's CUDA and TensorRT.

That separation has a practical benefit. A model can be validated and deployed on the CPU of an edge device today, then moved to an accelerator later without retraining. Accelerators usually require quantisation, which converts 32-bit floating-point weights and activations to 8-bit or 16-bit integers. Quantisation changes the numbers the model computes, so a quantised model has to be validated again, not assumed equivalent.

Deployment also needs operational plumbing that has nothing to do with AI:

• versioned models and configurations, so you know exactly what ran where;
• a way to roll back a model that misbehaves;
• monitoring of inference inputs, so drift is visible before accuracy drops;
• secure update paths, because an edge device on a production network is an attack surface.

Where edge AI projects go wrong

Hardware is rarely the reason an industrial AI project fails. The usual reasons are data and validation.

Shortcut learning. A model can score well in testing by learning something that correlates with the label in your data but not in the world: the station a part came from, a background noise that was present only on fault days, the time of day. It then fails on the next line. Splitting test data by machine, batch or day, not randomly, is the first defence. We go deeper in validating industrial AI models.

Too little data of the right kind. Faults are rare and defects are, ideally, rare too. Projects often have thousands of normal examples and a handful of faulty ones. That is not a reason to give up, but it determines which rung of the model ladder you can realistically reach first.

Drift. Tools wear, materials change suppliers, seasons change hall temperature. A model trained in spring may see a different normal in winter. Edge systems need a way to notice when inputs move away from the training distribution.

Sensor faults mistaken for machine faults. A loose accelerometer, a damaged cable or a dirty lens changes the signal. If the system cannot tell a sensor problem from a machine problem, it produces false alarms and operators stop trusting it. Sensors that report their own health address this directly, as we explain in self-monitoring sensors.

A checklist before you start

Use this list to judge whether a use case is ready for edge AI:

• The question is specific: "Is this weld acceptable?" rather than "Can AI improve quality?"
• You know which physical effect carries the information and which sensor captures it.
• You can record data under realistic conditions, including the variation you expect in production.
• You have, or can create, ground truth: confirmed defects, maintenance records, lab results.
• Test data can be separated from training data by machine, batch or time period.
• Somebody owns the decision the model supports, and the action that follows.
• There is a plan for model updates, rollback and record keeping.

If several of these are open, start with a data-collection phase rather than a model. Good recordings are reusable; a model trained on poor recordings is not.

How NeuroControls approaches this

We build multimodal sensing systems that record and time-stamp data at the machine: an Edge AI Hub with cameras, a thermal imager and a microphone, plus vibration, acoustic and depth nodes, described on our edge AI solutions page and our hubs page. Recordings are made on site with a versioned manifest, per-segment SHA-256 hashes and an append-only journal, so every result can be traced back to the data it came from.

Custom models are trained by our engineers on customer data, covering feature extraction, anomaly detection, fault and multi-fault classification and severity grading, and delivered as ONNX; on-device inference was first proven on our Vibration Node. NPU inference and a self-service framework for labelling, training and deployment are coming soon. Details of how we build and validate models are on our models page.