Anomaly Detection

A threshold monitor needs you to know the number. Anomaly detection does not: Pulse measures what a data point normally does, then watches for it doing something else.

That is useful exactly where thresholds are not. Nobody knows the right high limit for four hundred tags, and the ones worth alarming on are often the ones nobody thought about. A data point that has quietly drifted, seized, or gone quiet is a fault whether or not anyone wrote a limit for it.

What you get is not a new kind of monitor. Each check Pulse creates is an ordinary condition monitor -- you can open it, read the logic, change it, or delete it like any other.

Setting It Up

Anomaly detection lives on the data point table of a data source, next to the decision it follows from: a data point that is keeping a history is a data point with something to learn a normal from.

When you switch History on. Turning on History for a data point keeps its readings, and Pulse then offers to watch it. Decline the offer and the data point keeps its history exactly as it would have.

Any time afterwards. Every data point that is already keeping a history carries a Detect anomalies button on its row. That is the way in for points adopted long ago, and for the ones where the offer was waved away.

Either way, you then pick a sensitivity, choose which checks to create, and confirm.

Pulse works out which checks make sense for that particular data point. Anything it cannot do, it says so and why -- see When a check waits, and when it is not offered.

You do not have to wait for the baseline

Every check can be switched on straight away, including on a data point adopted a minute ago. The ones that need a measurement are created now and marked Active once measured: they sit quiet and report Unknown rather than judging against a normal nobody has measured, and they start watching on their own after the next nightly measurement. There is nothing to come back and do.

Start with them switched off

The Start these running checkbox is off by default, and leaving it off is the cheapest way to find out whether the checks suit your plant.

With it off the checks run and record what they would have done, without notifying anybody. Come back in a week and look at what would have fired. If it looks right, switch them on from the monitor list; if it looks noisy, lower the sensitivity or delete them. Nobody gets paged while you decide.

The Five Checks

Check	Fires when	Needs a baseline
Stopped reporting	No fresh reading for 15 minutes	No
Outside its normal range	The reading leaves the range the data point normally sits in, and stays out	Yes
Stopped changing	Still reporting, but the value has not moved	Yes
Moving unusually	Swinging or ramping far more than the data point normally does	Yes
Drifting from its reference	The level over the last day has moved away from where it was when this check was set up	Yes

Stopped reporting is the one that always works. It needs nothing measured, so it is available on a data point you added this morning -- and it is what makes the others' silence meaningful. A data point whose band could not be built is still watched for going quiet, so "nothing is alerting" and "nothing is looking" stay different states.

Stopped changing is not the same as Stopped reporting, and the difference matters when you are woken up by one of them. A stuck value means the data point is still talking and the number behind it is frozen: a seized valve, a frozen scan cycle, a cached read. The device is fine and the measurement is not.

Moving unusually covers a fast ramp and a noisy oscillation with one check. Both are the same fact about the window -- it covered far more ground than usual -- and separating them would need a direction that the check deliberately ignores.

Drifting from its reference detects slow change that the other checks would learn to accept. Those checks update their baselines nightly and call recent history normal; a data point that has gradually shifted over weeks looks fine to them. The drift check instead compares the last day's level against a fixed reference -- the measurement as it stood when the check was set up, or the first one taken if the data point had not been measured yet. That reference never moves on its own. Use it for equipment where a slow trend matters: a pump that has quietly lost efficiency, a PLC output that has crept outside its original operating point.

Sensitivity

Setting	Meaning
Low	Only the obvious. A wide band and a long hold before it fires
Medium	The recommended starting point
High	Catches things earlier, and fires more

Sensitivity changes two things together: how far outside normal counts as far, and how long it has to stay there. Both are deliberate -- an excursion that lasts ten seconds is usually the process, and one that lasts fifteen minutes usually is not.

High is not a fleet setting

High is a reasonable choice for one data point you are already worried about. Across a few hundred data points it produces incidents faster than anyone reads them, and a queue nobody reads is the same as no monitoring at all.

You can change the sensitivity of a check after it exists by opening its condition monitor and editing the numbers directly.

What Pulse Measures

Every night, Pulse measures each data point's recent history and stores what it found: the level the data point sits at, how far it normally strays from that, how much it moves within a few minutes, and how coarse its smallest real change is.

Three things follow from that, and they are worth knowing before you go looking for a check that is not there:

• A new data point has no baseline. The checks that need one are still created -- they report Unknown until the next nightly measurement and start watching after it. Stopped reporting works immediately.
• A measurement is kept until a better one replaces it. Pausing a monitor for three weeks of maintenance does not destroy its baseline.
• A measurement that goes stale stops the check. If the nightly measurement has not run for over a week, the checks that depend on it report Unknown rather than judging against a number nobody stands behind.

When a Check Waits, and When It Is Not Offered

The dialog gives two different answers here, and they mean opposite things. One is a check you have; the other is a check you cannot have.

Active once measured

The check is created and running. It simply has nothing to judge against yet, and reports Unknown until it does. These resolve on their own:

Reason	What it means
Pulse has not measured this data point yet	Normal for a data point added today. It starts watching after the next nightly measurement
Not enough history yet to say what normal is	The data point has data, but too little of it
Does not vary in a way a normal range can be built around	A tag pinned at one value, or one that steps between a handful. If it starts moving, the check starts working

That last one is the interesting case. Roughly half of all industrial tags sit in a control loop and barely move, and a band drawn around a signal that does not vary is a band that everything is outside of. Rather than create four thousand alerts, Pulse holds the check quiet until the tag gives it something to measure.

Not available for this data point

No amount of measurement changes these, so the check is not created at all:

Reason	What it means
This data point is on/off	A normal range has no meaning for a two-valued signal. Stopped reporting is still offered
This data point does not report numbers	Nothing can be watched, including Stopped reporting
The state data point does not report numbers	The state signal chosen to key the checks is not a numeric data point

Incidents

An anomaly incident says what was measured and what it was measured against, rather than "the condition was met":

Coolant Temp is outside its normal range Measured 91.4, outside the learned normal range 76.8–82.4, continuously for 15 min.

Feed Pressure has stopped changing Still reporting, but fixed at 4.02 for 30 min.

Drive Current has drifted from its reference Level over the last day 18.4, outside the reference range 11.2–15.6 pinned when this check was set up.

The duration is the hold the check was configured with, and it is a fact about the moment it fired rather than a running clock -- the incident list shows the ongoing age separately.

Incidents from these checks escalate through your escalation policy exactly like any other, and are acknowledged and resolved the same way.

An unevaluable check does not keep escalating

If the data point behind an open incident goes quiet, Pulse stops climbing the escalation policy rather than waking more people for something it can no longer confirm. The incident stays open, and escalation resumes by itself if the data point comes back.

The initial notification is never held this way -- you are always told the incident exists.

Limitations

Worth knowing before you rely on these checks:

• No engineering units. Pulse does not know that a tag is degrees or bar, so an incident quotes bare numbers.
• No shift or time-of-day awareness. A data point whose normal differs between a day shift and a night shift is measured as one population, which makes its normal range wider than either shift alone.
• Cyclic signals are refused. A tag that swings on a regular cycle is not something a static range describes, and Pulse declines rather than guessing.
• Planned downtime is not recognised. A plant shutdown looks like a fault to these checks. Pause the monitors, or expect them to fire.