Anomaly Events

Anomaly detection watches your numeric Variables against their own recent behaviour and raises an event when a reading stops fitting the pattern. Nobody sets a threshold: the baseline is learned from the data already stored.

Overview

Anomaly detection is an Analyze stage feature. It works on readings that have already been Connected, Collected and Stored, and it needs history before it can say anything: the baseline is built from the previous 14 days of hourly buckets for the Variable, compared hour band by hour band so a reading at 3am is judged against other nights rather than against the working day.

A scan runs periodically across every eligible Variable in the Organization. Eligible means numeric, active, logging enabled and not archived, so boolean and string points are out of scope and a Variable that has just been created has nothing to compare against yet. Each scan writes what it finds as anomaly events, and where several findings on the same Asset describe one situation, it groups them into an incident.

The page lives at Events → Anomalies in the sidebar.

What Detection Looks For

Three detectors run over the same data, and each answers a different question.

Out of range compares the latest hourly value against the mean and standard deviation of the Variable's own baseline and reports how far off it sits, as a z-score. Anything within three and a half standard deviations is left alone. The severity follows the distance: 3.5 to 5 is low, 5 to 8 is medium, beyond 8 is high. A second robust check on the median guards against a baseline that a previous excursion has already dragged along with it, and a minimum relative deviation keeps very steady signals from flagging on noise.

Stuck sensor looks for a value that has stopped moving while its history says it should be moving. It needs most of a 24 hour window present, recent data, and a baseline that actually varies, so a genuinely constant point never qualifies. Duty-cycled equipment sitting at its idle value is excluded too, because a generator resting at zero is not a fault. Severity comes from how long the value has been flat: under two days is low, two to four days medium, beyond four days high.

Data gap reports readings that stopped arriving. Three consecutive missing hours are needed before anything is raised, which absorbs ordinary ingestion lag, and the Variable has to have been reporting reliably over the preceding week so a point that has always been patchy does not fill the list. Under six hours missing is low, six to twenty-four medium, beyond a day high.

All three extend an existing event rather than opening a new one when the condition continues, so a long excursion stays a single row with a growing episode length instead of an entry per hour.

The Events List

The page opens on the last seven days, most recent first, and refreshes itself while it is on screen.

Each row reads as a sentence. Severity shows low, medium or high with the detector that raised it underneath, and hovering explains what that severity means for that detector. Variable names the point and the Asset it belongs to, with a hover chart of the reading around the episode. Value shows what was measured, with the deviation from typical underneath for an out-of-range event, "flat since" for a stuck sensor, and "no data since" for a gap. Score is the evidence in one number: the z-score for out of range, hours flat for a stuck sensor, hours missing for a gap. When gives the episode window and, for a multi-hour episode, its length. Status is Open or acknowledged.

The time range selector at the top covers the usual presets. The filter row narrows by Severity, by Type (Out of range, Stuck sensor, Data gap), by Status for unacknowledged events only, and by Grouped, which is hidden by default and reveals the events that belong to an incident. The export button writes the current page to CSV, including the baseline mean and the deviation, which is what makes an anomaly defensible in a report.

Incidents

A single flat reading is a sensor question. Three flat readings on the same Asset at the same moment is an equipment question, and that is what an incident captures. When enough of an Asset's Variables go flat together, and they account for at least half of the Variables on it, the events are grouped into one incident and hidden from the table so the list stays one row per situation.

Incidents appear as cards above the table, each summarising the Asset, when it went quiet, how long it has been that way and how many of its sensors are flat. Expanding a card lists the member events with their values.

If the load has moved somewhere else, detection says so. When another Asset related to the quiet one shows an out-of-range step within three hours of the same moment, the incident is upgraded to a load switchover and names the Asset that picked the load up, which is the difference between "the utility service is reading zero" and "the utility service is down and the generator is carrying the building".

Acknowledge on the card silences the whole incident, member events included, and it drops out of the active list into the resolved section underneath.

Working Through Events

Every row has a menu with two actions. Acknowledge marks the event as handled and switches the row to acknowledged, and the same menu offers Reopen afterwards if it turns out not to be. Acknowledging is a record, not a mute: the detector keeps scanning the Variable and a new episode raises a new event.

Open in Explorer is the usual next step. It opens Data Explorer on the Variable with the window already framed around the episode, from a day before it started to a few hours after, so the shape of what happened is on screen without setting up a query. From there the Topology and comparison tools do the rest of the investigation.

A workable routine is to filter to unacknowledged events, work down from high severity, open anything unfamiliar in Explorer, and acknowledge what turns out to be expected. Data gaps and stuck sensors usually point at the Device or its connection rather than the equipment, so they are worth checking against the Device's health before anyone is sent to look at a machine.

Anomalies and Alarms

Anomalies and alarms answer different questions and are meant to be used together. An alarm is a rule you wrote: this Variable, this operator, this threshold, and it fires the moment the reading crosses it. Anomaly detection has no rule to write, learns what normal looks like per Variable and per hour of the day, and reports departures from it after the fact on a scan rather than in real time.

That difference decides which to reach for. Conditions you already know are dangerous belong in an alarm, where they notify people immediately through an alarm group. Conditions nobody thought to write a threshold for, or thresholds that would be wrong half the day because normal changes with the shift pattern, are what anomaly detection is for. An anomaly that keeps recurring for a known reason is usually a signal to write an alarm for it: see Alarms for how thresholds, severities and notification routing are configured.

Anomaly events do not notify anyone. They accumulate on this page for review, which is why the unacknowledged filter matters more here than it does on the Alarms page.

Availability and Permissions

Anomaly detection is enabled per Organization. Where it is not switched on, the Anomalies entry does not appear under Events in the sidebar. Contact ControlCom support to have it enabled for your Organization.

Permission	Grants
Events.ReadAnomalyEvents	The Anomaly Events page, its incidents and its exports

Anomaly detection depends on the Store stage having kept enough history for a baseline, it belongs to the Analyze stage alongside Data Explorer, and what it finds usually ends up in the Visualize stage as a chart on a dashboard or in the Report stage as an exported CSV.