A drive needs 14% more power today than yesterday. Is that unusual? Maybe. Perhaps different material is being processed today. Perhaps the machine is in another process phase. Perhaps speed is higher. Perhaps a tool was changed. A single number comparison cannot explain any of this.
In learning industrial systems, the question “Has a value changed?” is therefore not enough. The decisive question is: What behavior are we comparing it to? A deviation only gains meaning through its context.
When does a change become a relevant deviation? This is not a side issue in anomaly detection. It sits at the core of making machine behavior understandable in production.
The problem with global baselines.
Many systems compare measurements to a global average, a static setpoint, or one learned “normal.” On complex machines, that is often too coarse. A plant has several legitimate operating states: idle, setup, production, acceleration, machining, tool change, job change — and often several of them within a single day.
A current of 40 A can look alarming at idle, normal during acceleration, and unusually low in another process. The value alone does not carry sufficient meaning. Anyone who sees only the measurement point misses the state in which it arose.
Globally learned normality blurs these differences. An average across all states is often not normality in an engineering sense, but a statistical compromise — useful on dashboards, risky for live evaluations.
Context identity instead of raw value similarity.
A meaningful comparison should happen between situations that are comparable in practice. Not: current measurement against all historical measurements. But: current behavior against historical behavior under similar conditions.
Possible context dimensions include operating state, process phase, job, material, tool, speed, machine configuration, relevant preceding events, simultaneously occurring signals, or recurring behavior sequences. These illustrate the solution space — not a claim that any specific system already uses every dimension in production.
Two measurements can be numerically similar yet mean different things because operating context is not comparable. Conversely, different numbers can be perfectly normal when context fits. Context identity is not optional metadata; it is a prerequisite for a fair comparison.
Behavior instead of single measurement points.
A single measurement point is often less informative than a trajectory or sequence of states. Not only “temperature = 68 °C,” but: temperature rises, power draw rises at the same time, speed stays constant, then both quantities stabilize. Such a sequence can be more characteristic than an isolated value.
Temporal behavior, sequences, recurring patterns, and relationships between signals often describe machines more precisely than point thresholds. For industrial AI and machine monitoring, deviation is frequently a pattern problem — not only a limit problem.
Expectation bands instead of a perfect setpoint.
Real machines rarely reproduce behavior exactly. The assumption “normal = exactly 63.4” is therefore problematic. An expectation band or plausible distribution is more realistic.
Simplified, a system might derive from historical experience for a comparable process: x lies in [μ − Δ, μ + Δ]. Here μ stands for expected behavior and Δ for tolerable natural variation. This is a thinking model — not a description of an internal Copass implementation.
In practice, systems are multidimensional: several signals and context cues matter at once. One channel can sit inside the band while the interplay of signals is still unusual — or the opposite.
A deviation needs a reference.
A deviation does not exist in absolute terms. It always exists relative to an expectation or reference. Formally, simplified: D = d(O, E) — with O as currently observed behavior, E as expected behavior in the fitting context, d as a measure of difference, and D as the resulting deviation.
The hard part is not necessarily computing D. The hard part is: Which expectation E is the right one? That is where a system either compares numbers or tries to understand machine behavior.
Why the same difference can mean different things.
Imagine two processes. In process A, expected power draw has historically been around 18–22 kW. In process B, around 28–34 kW. You measure 29 kW now. Against a global average model, that may look notable. In the context of process B, it is completely normal.
Conversely: 25 kW during process A. Globally, perhaps unremarkable — in the context of process A, clearly more unusual. A global comparison can create false warnings and hide real change. That is one of the most common reasons anomaly detection loses trust on the shop floor even though something was “detected.”
Too little data: the machine must be allowed to say “I don’t know.”
A learning system must not force a verdict. A new job runs, unknown material is used, a rare machine state appears, or only a few comparable situations have been observed — then there may be no reliable reference.
The system should be able to express uncertainty — not blanket “normal” or “abnormal,” but in practice: there is not yet enough comparable experience for this context. Uncertainty here is not weakness; it signals a robust system.
This connects closely to what we describe in another research article on machine memory and trust in past experience: not every stored observation is automatically a valid reference for today.
Deviation is not yet a fault.
Deviation is not the same as fault. Deviation is not the same as failure. Deviation is not the same as root cause. A detected deviation initially only says: this behavior differs meaningfully from what was expected under comparable conditions.
Reasons can include process change, different material, tool condition, operator intervention, maintenance, ambient conditions, emerging wear, measurement error, or an unknown new operating state. A system should not invent a diagnosis from that alone. Inform people, do not replace them — that guideline holds here as well.
How could context-dependent deviation comparison work?
The following describes general technical principles — not Copass architecture.
Context selection: First, determine which historical situations are comparable to the current one at all.
Reference formation: Derive expected behavior from suitable historical observations — not from the entire archive, but from the fitting subset.
Comparison: Hold the current observation against that expectation.
Uncertainty: Account for how much and how reliable historical evidence exists.
Repetition: Treat a single deviation differently from a pattern that recurs across several comparable situations.
Provenance: Keep it traceable which observations and comparisons an assessment rests on — for people in operation, not for a black box.
A simplified thinking model.
Conceptually, relevance of a deviation can be abstracted as R(O, c) = g(d(O, E_c), Q_c, N_c). O is the current observation, c the current context, E_c expectation for that context, d the gap between observation and expectation, Q_c the quality of comparison evidence, N_c the amount of relevant historical experience, and R the resulting relevance of the deviation.
This models the research problem — it is not disclosure of a Copass algorithm. It shows why industrial systems need more than a single threshold.
What this means for Copass.
Copass is not meant to judge machine behavior against one global normal state. Our research interest is to derive expectations from genuinely comparable operating situations and to view deviations within that context.
Three points matter especially: a deviation needs a reliable reference; missing experience must be allowed to remain uncertainty; a deviation must not automatically be interpreted as a fault.
Not everything described here is already fully implemented in production. It outlines the solution space and the direction in which we develop and study Copass — without presenting Copass as a finished predictive maintenance product.
The hardest part of intelligent machine monitoring is not noticing that something changed. Machines change constantly. The decisive question is: Has something changed that, under these exact conditions, should not be different?
Only when a system can answer that question does a difference become a relevant deviation. Not every change is a deviation. Only the right comparison makes it one.
Related research: When should a machine trust its own memory? — when memory is context-dependent, the same applies to expectations.