Anomaly detection moves beyond known failures
Manufacturers have spent years trying to predict known failures. The logic is attractive: understand what went wrong before, collect enough data around those events, and build models that warn when similar conditions begin to reappear. That approach still has value, but it only addresses the problems a plant already understands well enough to describe.
Nikunj Mehta, founder and CEO of Falkonry, argues that many of the most damaging production problems sit outside that familiar territory. “The problem in factory production operations is generally of a long-tail nature,” he says. “There are some problems that happen frequently and that cause a lot of damage, but there are many more that are not recurring, and it’s not possible to approach them through the standard predictive analytics technology.”
That distinction matters as manufacturers try to use AI on live production systems rather than isolated examples. Predictive maintenance tends to be asset-centric and failure-mode focused. It asks when a known asset is likely to fail in a known way. Anomaly detection asks a broader operational question: whether the system is behaving differently from its own normal baseline, even when no established failure signature exists.
For process industries and complex discrete production environments, that is increasingly the more important question. The plant may not have a clean failure label, a detailed fault history or a reliable record of the abnormal condition. The earliest warning may not be a threshold breach at all. It may be a subtle shift in waveform, a change in value distribution, a frequency pattern that moves out of sync, or a relationship between multiple signals that no operator would be expected to monitor manually.
Labels are the limiting factor
Traditional supervised learning depends on examples. That creates an immediate problem in manufacturing, where failure events may be rare, maintenance records may be incomplete and operational history may not have been captured for analytical purposes. Mehta says many industrial organizations kept records primarily for financial tracking, not for building predictive models. That makes the data difficult to use when the question is not simply what happened, but what was happening before the failure became obvious.
“Keeping precise documentation about failure is a near impossible task for most organizations,” he says. “People who do not have the clean failure labels can probably do so in a narrow sense, and it will require a significant amount of expert attention or effort. But without that, there is no hope of doing supervised learning, which is dependent on having labels.”
Even where labels exist, they can become a burden. Mehta points to a steel producer that had recurring failures but still needed a process engineer to spend about a day each week labeling data. That is time taken away from production improvement and troubleshooting. It also restricts the usefulness of AI to problems that are already recognized, repeatedly documented and worth the manual effort of classification.
Self-supervised anomaly detection is designed to remove that dependency. Instead of waiting for curated examples of failure, the system learns normal operating behavior from time-series data and flags deviations that may require attention. The challenge is not simply to find anything unusual. It is to find what is unusual enough, persistent enough and operationally relevant enough to be worth a human response.
The problem with normal
Manufacturing data is difficult because normal is not fixed. A plant changes with product mix, raw materials, ambient conditions, equipment wear, maintenance work and operating state. A signal that looks unusual in one context may be expected in another. A rule that worked last month may become misleading after a line change or process adjustment.
Mehta describes industrial time-series data as dynamic, high frequency and tied to shifting operational baselines. Some data may arrive thousands of times per second, while other signals update much more slowly. Some is compressed into historians, where dead bands can remove features that might have indicated an early change in behavior. Plants may be generating terabytes of operational data, yet still face delays of months or years in projects that need immediate answers because teams cannot locate, prepare or interpret the right data quickly enough.
This is why anomaly detection has to be more than another dashboard. Standard SCADA alarms are usually built around single-variable thresholds. They are useful for established limits, but they struggle when an abnormal condition is developing across several signals while each individual value remains within its allowed band.
“What may not be anomalous in the individual parameter could still be anomalous across multiple,” Mehta says. “Those are the kinds of things that we tend to pull out through anomaly detection. Many failures are preceded by multiple anomalies in different signals. Usually, one is where the behavior starts to manifest, and then it spreads to a number of related quantities.”
From anomalies to incidents
The danger with any monitoring system is noise. Manufacturers do not need another stream of alerts that operators learn to ignore. Falkonry’s supporting steel production paper makes the same point: not every anomaly requires immediate action, and manually reviewing every anomaly is impractical in large-scale operations. The paper describes a prioritization framework that considers factors including asset criticality, anomaly severity, persistence, spread across signals and contextual information such as production and maintenance schedules.
That prioritization is essential because a useful anomaly needs to become an operational incident. Mehta says heat maps can help people understand what the AI is seeing, but operations teams cannot run a plant by staring at heat maps. They need a manageable daily view of incidents, ranked by priority and supported by evidence that explains why attention is required.
“In order for them to be able to trust, they have to be able to see the big picture,” he says. “In order for them to be able to trust it, though, they have to actually operate with it, and that requires isolating anomalies into incidents because people cannot pay attention to heat maps in an operational sense.”
The aim is not to eliminate engineering judgment. It is to reduce the manual work required to find the right place to apply it. In Mehta’s view, anomaly detection should identify whether something important has happened, whether it has happened before, where it started and what may happen next. The human expert then decides whether the recommended action makes sense in the operational context.
He describes the desired shift as moving the human outside the loop rather than keeping them inside it. Engineers should not become data-labeling clerks or constant reviewers of raw telemetry. They should supervise the process, provide feedback and make decisions where domain knowledge, production priorities and practical constraints matter most.
Steel shows the value of prioritization
Steel production shows why the distinction matters. In a high-throughput mill, abnormal behaviour is rarely convenient or neatly labelled. A problem may begin as a small shift in torque, vibration, current or speed, then spread across related signals before anyone sees an obvious fault. By the time a standard threshold alarm is triggered, the useful window for earlier intervention may already have narrowed.
In one steel production deployment, anomaly detection was applied across core production areas including the melt shop, casting lines, hot mill and cold mill. The system used existing SCADA data to learn normal behaviour, then prioritised anomalies according to factors such as severity, persistence, asset criticality and spread across multiple signals. That is the important point for manufacturers: the value is not in detecting everything unusual, but in directing engineering attention to the abnormalities most likely to affect production.
In one reheat furnace case, the earliest anomaly was detected before a ball screw failure. The anomaly first appeared in torque signals, then spread to other parameters and increased in severity before production stopped for corrective action. The paper notes that the legacy monitoring system did not trigger an alarm because the signal values remained within threshold, even though the unusual behavior was already developing.
A second case involved increased vibration in circulation fans. The AI detected abnormal behavior about 100 minutes before the load condition began. The anomaly spread across fan speed and current trends, creating a higher-priority alert. Operators were able to continue production using backup fans and create a work order to fix the bearing during the next scheduled maintenance window, avoiding a more disruptive intervention.
Across a three-month assessment of the melt shop and cold mill, the paper reported 57 beneficial detections against 65 scoped delays and actions, an aggregate beneficial detection rate of 87.69 percent. The cold mill recorded a 96.22 percent beneficial detection rate, while the melt shop recorded 50 percent and potentially avoided 409 minutes of delay through timely corrective actions. Those figures are important because they move anomaly detection away from abstract model performance and toward operational value.
Analytics moves toward autonomy
The next stage of manufacturing analytics is not simply predicting more known failures. It is creating a continuous understanding of normal and abnormal behavior across complex assets and processes, then reducing the amount of human effort required to monitor them.
Mehta argues that the manufacturing sector needs the same kind of leverage that cloud technologies gave IT administrators, allowing one person to manage far more systems than before. In production environments, that means engineers and operations teams can cover more assets, investigate faster and spend less time firefighting. It also matters for workforce reasons, because skilled engineers are not always available where plants are located, and many do not want to work in the same reactive patterns that have defined plant operations for decades.
The direction is toward AI that can diagnose, explain, simulate and optimize, but that only becomes useful if it is grounded in operational telemetry and connected to human expertise. General AI can answer questions, but industrial systems need evidence, context and a clear relationship between abnormal behavior and physical consequences.
Factories will always need engineers. The question is whether those engineers spend their time searching through signals for signs of trouble, or whether AI can surface the right evidence early enough for them to act. For manufacturers trying to improve uptime, quality and productivity, the most valuable failures to find may be the ones they have not yet learned how to name.
