Rela AIRela AI Docs
Quality

Anomaly Detection

Machine learning system that detects abnormal patterns in sensor data without manually defined thresholds. Learns normal behavior for each piece of equipment and alerts when something changes.

Anomaly Detection

Anomaly Detection is the intelligent monitoring system of Rela AI. Instead of relying only on fixed thresholds ("alert if temperature exceeds 85°C"), this system learns how each piece of equipment normally behaves and detects when something is different — even before any threshold is crossed. It is the difference between waiting for a problem to occur and anticipating it.

What is it for?

Fixed thresholds have a fundamental problem: the same value can be normal in one context and abnormal in another. Vibration of 4.5 mm/s on a compressor during the morning startup may be completely normal. The same vibration at 3 AM, when the equipment has been running in steady-state for 8 hours, may indicate something is changing.

Anomaly Detection solves this by learning the normal behavior of equipment in different contexts (time of day, day of week, operating conditions) and alerting when behavior deviates from normal — even before reaching a critical threshold.

Key situations where this matters:

  • Detecting gradual bearing wear before catastrophic failure
  • Identifying energy inefficiencies that appear slowly (consumption rising 3% per week)
  • Detecting process changes that affect quality without reaching limit alarms
  • Anticipating failures in equipment whose behavior is difficult to parameterize with simple thresholds

How does it work?

The system uses two complementary statistical methods:

Z-Score: Measures how many standard deviations a value is from the equipment's normal mean. If a motor's normal temperature oscillates between 68°C and 72°C (mean 70°C, standard deviation 1°C), a value of 73°C has a Z-Score of 3 — it is 3 standard deviations from the mean. This is statistically unusual. The system uses a default threshold of 3 standard deviations, which means in normal conditions, only 0.3% of readings would trigger an alert from natural variation.

IQR (Interquartile Range): More robust for data that does not follow a symmetric distribution. It calculates the range between the 25th and 75th percentiles of historical data and flags values that fall far outside that range. This method works well for equipment with variable operating cycles.

Temporal context: The system learns behavior by time of day and day of week. It knows that energy consumption on Mondays at 8 AM is different from Sundays at 3 AM. An anomaly is always evaluated in its temporal context, not against a global average.

For the model to work, it needs historical data — a minimum of 500 data points and 30 days of history is recommended. With less data, the model works but may generate more false alarms.

How to use it?

Configure detection for a piece of equipment

  1. Go to Quality > Anomaly Detection in the sidebar.
  2. Click New Configuration.
  3. Select the data source (the connected sensor or event source).
  4. Select the metric to monitor (e.g., vibration_rms, temperature, power_kw).
  5. Define the sensitivity:
SensitivityDescriptionWhen to use
LowFewer alerts, only very large deviationsEquipment with naturally high variability
MediumBalance between detection and false alarmsMost industrial equipment
HighMore alerts, detects minor deviationsCritical equipment where over-alerting is preferred
  1. Select the detection methods: Z-Score, IQR, or both (using both is recommended).
  2. Define the training window — how many days of historical data to use to learn normal behavior.
  3. Activate the configuration.

Train the model

After creating the configuration, start the training:

  1. Open the created configuration.
  2. Click Train Model.
  3. The system processes historical data. This takes from seconds to minutes depending on the amount of data.
  4. When training completes, detection is active.

Review detected anomalies

Once active, the system displays detected anomalies with:

FieldDescription
TimestampWhen the anomaly occurred
TypeIsolated point, gradual drift, or contextual anomaly
SeverityLow, Medium, High, Critical (adjusted by asset criticality)
Anomalous valueThe specific value detected as anomalous
Deviation scoreHow far it deviated from normal (numerical measure)

Assets with "critical" criticality have a multiplier on the score — the same deviation on a critical piece of equipment generates a higher-severity alert than on a low-criticality one.

Three types of anomalies

TypeDescriptionExample
Isolated pointA single value that falls outside the normal rangeA sudden temperature spike
Gradual driftBehavior slowly shifting in one directionVibration rising 0.1 mm/s per week for a month
ContextualValue is generally normal but abnormal for that momentHigh energy consumption at 2 AM when the line is stopped

Give feedback to the system

When the system detects an anomaly, you can indicate whether it was correct or an error:

FeedbackWhen to use it
False alarmThe value was normal — it was not a real anomaly (e.g., during a scheduled cleaning)
ConfirmedIt was a real anomaly that required attention
ResolvedIt was an anomaly, the cause was identified, and it was corrected

The system uses this feedback to adjust the model in the next retraining cycle, gradually reducing false alarms.

Key benefits

  • Detection without manual thresholds — the system learns what is normal on its own
  • Detects gradual deviations that fixed thresholds would never catch
  • Temporal context — knows that normal behavior is different at 3 AM versus 3 PM
  • Asset criticality affects severity — more sensitive on critical equipment
  • Improves with feedback — each correction makes the model more accurate
  • Early warnings before a problem becomes a costly failure

Common use cases

Scenario 1: Anticipate a bearing failure The vibration sensor on motor M-04 has been showing values within the limit for 3 weeks (3.8 mm/s, alarm threshold 7.5 mm/s). But anomaly detection notices that vibration has been rising gradually at 0.15 mm/s per week — a drift that a fixed threshold would never catch. It generates a "gradual drift" alert with medium severity. The maintenance manager reviews it, confirms the trend in the historical chart, and schedules a preventive bearing replacement for the following Saturday. The catastrophic failure that would have occurred in 2-3 weeks is avoided.

Scenario 2: Detect abnormal nighttime energy consumption The system learns that Line B's energy consumption is about 45 kW during daytime production and about 8 kW at night (equipment in standby). On a Wednesday at 1 AM, consumption registers 38 kW — within the daytime range but completely anomalous for that time. Detection generates a contextual anomaly. Investigation reveals that someone left a curing oven running by mistake. The problem is corrected and unnecessary energy cost is avoided.

Scenario 3: Reduce false alarms with feedback When configuring detection for compressor C-02 with high sensitivity, the system generates 8 false alarms in the first week — all during the daily cleaning routines (when the compressor behaves differently than normal). The operator marks each one as "false alarm" with the note "scheduled cleaning." In the next training cycle, the model learns that this behavior during that specific time is normal, and the false alarms disappear.

On this page