AI anomaly detection
AI-based anomaly detection is one of the things that makes Treon Connect more than a chart viewer. Instead of asking you to know the right threshold for every machine, it learns what normal looks like for each individual machine and tells you when that machine starts behaving unlike itself.
How it works
Each device gets its own model, built from that machine's own measurement history. The model learns the normal range and patterns of that specific machine, not a generic template. Under the hood it is a Gaussian Mixture Model (GMM): during training the model learns the clusters of values that represent the machine's normal vibration, and afterwards every new measurement is compared against that learned baseline. A measurement is flagged as anomalous when it sits significantly outside the distribution the machine showed while healthy.
The model works from a single signal: the combined vibration velocity RMS — the overall vibration energy, derived from the machine's three measurement axes. (Temperature is trended and can raise its own threshold events, but it is not an input to the AI model.)
Because the baseline is per-machine and learned from data, AI detection catches developing problems that a fixed threshold would miss — a machine drifting away from its own healthy behaviour long before it crosses a generic limit.
Only running data counts
A stopped machine measures near-zero vibration, and if that were treated as "normal" the baseline would be meaningless. So the model uses only measurements taken while the machine is actually running — samples with enough vibration energy, above a default cutoff of about 0.5 mm/s velocity RMS (below that the machine is treated as stopped, not faulty). Idle-machine samples are excluded from both training and evaluation. This is why an intermittently-run asset simply trains more slowly rather than learning a wrong normal.
Training
A model needs enough history before it can judge normal from abnormal. When a sensor is commissioned and comes online, the system begins baseline training automatically, collecting hourly running-state velocity-RMS measurements that represent healthy operation.
- The model completes once it has 336 running-state measurements. They're collected while the machine runs, so in practice this takes a few weeks.
- Collection is capped at about 2 months, so an asset that runs only occasionally still finishes rather than waiting indefinitely — if the cap is reached first, the model can complete on as few as 84 measurements.
- Until it has enough data the device shows as not yet trained. You can see how many devices in a group are trained on the Condition dashboard ("Devices Trained"). A freshly commissioned device is untrained until it accumulates data; this is expected and resolves itself as the machine reports.
Training on historical data
You can also train a model from history instead of waiting: pick a start point, and the model trains on the next 336 running-state measurements from there. Use this when the automatic training period didn't capture all of a machine's normal operating conditions — for example if the machine ran in only one mode during its first weeks online.
How an AI event is raised
The model does not raise an event on a single odd measurement — a one-off spike is usually noise, not a fault. An event is raised only once a deviation persists: when at least 4 of 6 consecutive measurements are classified as anomalous.
This deliberate delay is why AI events are trustworthy signals of a real change rather than sensor jitter — and why there is a short lag between a machine changing and the event appearing.
AI detections appear in the Events application as AI Warning events, alongside threshold and ISO events, and are broken out separately on the dashboards so you can see AI-detected problems at a glance.
What closing an event does to the model
How you close an AI event feeds back into the model, so it matters which options you choose. There are three possible outcomes:
| Outcome | What happens |
|---|---|
| Model is improved | The flagged period is re-learned as healthy, so the same behaviour stops raising events. |
| Model is not modified | The model is untouched. The same behaviour will raise the event again. |
| Model is retrained | The model is rebuilt from a new starting point, so the machine's new behaviour becomes its baseline. |
Which one you get is decided by the Cause of Event you pick when resolving — and, for a real fault, by the Action Taken.
Resolving as a false positive — the model improves
Choosing No Failure Detected (or New Process Change) marks the event as a false positive. The platform then retrains the model with the 24 hours of data before the event ended included as healthy, so that behaviour becomes part of the machine's normal and stops triggering on the same criteria.
This is the option that teaches the model. Use it when the machine was fine and the model simply had not seen that behaviour before.
Resolving as a real fault — the model is left alone
Pick the fault that describes what you found — imbalance, misalignment, bearing wear, lubrication, and so on — and then record the Action Taken. The model is not modified: the behaviour was genuinely abnormal, so the baseline is still correct and you want the event to raise again if it comes back.
Resolving as undetermined — the model is left alone
Unable to Detect (Keep Monitoring) closes the event without a verdict and leaves the model untouched, so the event will raise again on the same criteria. That is the point: you have not learned anything yet, and you want another look.
Rejecting — the model is left alone
Reject removes the event without any model effect. A rejected event is also hidden from the trends after clearing.
Retraining after a real change
Sometimes an event reflects a genuinely new normal rather than a fault — after a rebuild, a component change, or a deliberate change in operating conditions. Retrain the model so it re-learns the machine from the changed baseline, using the RETRAIN control on the measurement point's Set Event Rules panel. You can retrain from today, or pick the date the change happened.
Retrain deliberately: after the machine legitimately changed, never to silence a real developing fault.
Four worked scenarios
What happened: the event was a real fault, and you replaced the machine or a major component — a major modification.
How to close it: resolve with the fault as the Cause of Event and Replace (or Overhaul) as the Action Taken.
Model outcome: not modified by closing the event. But the machine is physically different now, so its old baseline no longer describes it. Retrain it from the date of the replacement, or the model will keep comparing new hardware against the old machine's normal.
What happened: the event was a real fault, and you corrected it with a minor intervention — realignment, lubrication, cleaning, a small adjustment.
How to close it: resolve with the fault as the Cause of Event and Adjust, Lubricate or Clean as the Action Taken.
Model outcome: not modified, which is what you want. The machine is back to the condition the model already learned, so the existing baseline still applies — and if the fault returns you want to hear about it.
What happened: nothing is wrong. The machine ran in a mode that was not present during training — a different load, speed or product — and the model flagged it as unfamiliar.
How to close it: resolve with New Process Change (or No Failure Detected) as the Cause of Event. No maintenance action is needed.
Model outcome: improved. The period is re-learned as healthy, that operating mode becomes part of normal, and the event stops recurring for it.
What happened: you investigated and could not determine what caused the event.
How to close it: resolve with Unable to Detect (Keep Monitoring).
Model outcome: not modified. The event will raise again if the behaviour repeats, which is the right outcome — you have not established that it is normal, and a repeat gives you a second chance to catch it.
Trusting AI events
- An AI event means "this machine is behaving unlike its own learned normal" — it points you at something changed, not necessarily at the specific cause. On a Make/Treon Industrial Node X machine, diagnose the cause with the spectra and waveforms.
- AI and threshold/ISO detection complement each other: thresholds and ISO classes encode known engineering limits; AI catches the unknown-unknowns specific to each machine. You can run all of them at once on the same machine — they don't conflict.