Anomaly detection is one of the most useful - and most misunderstood - ideas in industrial AI. Stripped of jargon, it is simple: teach a system what normal operation looks like, so it can flag anything that deviates, often before a human would notice. It is the quiet engine behind a lot of "predictive" and "smart factory" tooling.
This post answers a scoped question: what exactly is anomaly detection, and how does it work in a manufacturing context?
A plain definition
Anomaly detection = learn normal, then flag the abnormal. Instead of being told every rule for every fault in advance, the system studies how a machine or process usually behaves and raises a hand when something no longer fits that pattern. That is powerful in manufacturing, where you often cannot list every way a machine might fail, but you *can* show what healthy operation looks like.
Three kinds of anomaly
Not all anomalies look the same, and knowing the type helps you choose the right approach.
- Point anomaly - a single reading far from normal (a sudden temperature spike). The easiest to catch.
- Contextual anomaly - a value that is normal in general but wrong *for its context* (a motor current that is fine at full load but abnormal at idle).
- Collective anomaly - a sequence that is off *together*, even if no single point looks extreme (an unusual oscillation pattern building over minutes).
How it works, in four steps
1) Collect signals - consistent time-series from the asset or process. 2) Learn normal - a model builds a picture of healthy behavior from history (usually unsupervised or semi-supervised, since normal data is plentiful and failures are rare). 3) Score deviation - each new reading gets an "how unusual is this?" score against learned normal. 4) Flag and act - when the score crosses a sensitivity level, it raises an alert for a human or workflow to act on.
Where it helps on the shop floor
- Predictive maintenance - catch a bearing or motor drifting toward failure early.
- Quality - spot process drift before it turns into scrap.
- Energy - flag consumption that no longer matches output.
- Process excursions - notice when a line is behaving unlike any normal run.
Use case in practice: pasteurization in a dairy plant
Pasteurization is a perfect fit, because the three anomaly types map straight onto it. A sudden probe spike is a point anomaly. A temperature that is fine during heat-up but too low during the holding phase is a contextual anomaly - a normal value at the wrong moment. A slow, coordinated drift of temperature, flow, and hold time across a batch is a collective anomaly. Fixed alarms catch the obvious spike; anomaly detection also catches the contextual and collective cases that quietly put a batch at food-safety risk.
How you would build it: collect the pasteurizer signals (inlet and outlet temperature, flow, hold time) per batch, attach context (product, line, CIP state), and label past batches that were held, reworked, or failed QA. The model learns the normal batch profile and flags deviations for QA to review before product ships.
What good anomaly detection needs
The method is only as good as its inputs. It needs clean, consistent signals, enough history of normal to learn a reliable baseline, context (product, shift, setpoint) so it does not confuse a normal changeover with a fault, and labels of known events to validate that its flags are useful. This last point is where many projects stumble: without labeled examples, you cannot measure whether the model is catching real problems or crying wolf.
Anomaly detection vs prediction
A common confusion: anomaly detection tells you "this is unusual," not necessarily "this specific failure will happen in 200 hours." It is the foundation for prediction and root-cause analysis - the layer that surfaces the interesting moments so people and downstream models can act on them.
Common pitfalls
- No context -> false alarms. Normal changeovers get flagged as faults.
- Alarm fatigue. Too-sensitive settings train operators to ignore flags.
- No owner. A flag with nobody responsible changes nothing.
Practical rule
Anomaly detection is not magic and not a black box you buy - it is the discipline of defining normal well enough that "not normal" becomes actionable. Get the data and context right on one asset, and it becomes the early-warning layer everything else builds on.
Start by teaching a model your normal: import signals, add context, and label known events to build an anomaly-ready dataset in Predsense labeling: https://www.predsense.ai/products/labeling