Anomaly Alert Statuses
An anomaly alert moves through several statuses as it works its way through the corresponding phases. These statuses are described below.
Initialized
When an anomaly alert has been successfully initialized, it is ready to receive data from an edge device so it can prepare to monitor a data stream for anomalies.
If the anomaly alert cannot be created successfully, a status of Initialization Failed will display. This type of failure can occur if the Alert Processing Subsystem is not properly configured to point to the ThingWorx Analytics Server. For more information, see Preparing ThingWorx for Anomaly Detection.
 |
When ThingWorx restarts, it might take a minute to reconnect to the ThingWorx Analytics Server. The existing anomaly alerts will remain in Initialized status and will continue to poll for Analytics Server availability until the connection is re-established.
|
Calibrating
In the Calibrating status, the anomaly alert collects the data necessary to build an anomaly model and generate a set of validation data. The anomaly alert will remain in this status until the proper amount of data has been collected to begin the model building process. During the data collection phase, the sampling rate is imputed and any gaps in the data are interpolated so that there are no missing values.
Training
When a sufficient amount of data has been collected, the anomaly alert enters the Training status. During this phase, a Training service builds an anomaly model that will be used during Monitoring.
Buffering
In the Buffering status, the anomaly alert is no longer calibrating, or training. It has a few tasks to complete during this phase:
• Use the validation data, collected during the Calibrating phase, to build an expected distribution of values that will be used during Monitoring to evaluate new data points.
• Collect enough data to rebuild the operating lookback window in order to effectively monitor streaming data.
The lookback window is the last X number of data values received, (a number defined by the anomaly model created during Training). For example, if the model defines a lookback window of 16 values, the anomaly monitor uses the previous 16 values in the historical data to predict the next value. If any of the previous 16 values are missing, the anomaly monitor must rebuild its lookback window of values in order to effectively monitor the data stream.
There are two scenarios where the system might enter the Buffering state.
1. When Training is completed, the anomaly monitor must collect enough data to complete the lookback window, as defined by the model, before it can start monitoring. Therefore, a brief period of Buffering will always occur immediately following the Training status.
2. If a time gap occurs, while in the Monitoring status, between the previous and current data points, the lookback buffer will be cleared. The anomaly alert will re-enter the Buffering state and will remain in this state until the lookback window buffer is completely filled.
Monitoring
In the Monitoring status, the anomaly alert is evaluating the streaming data for anomalies. The Monitoring status can be considered the normal operating state of the anomaly alert once Calibrating and Training have completed.
Failed
The Failed status indicates that the anomaly alert is unable to continue its Calibrating, Training, Buffering, or Monitoring procedures. The following scenarios can cause the system to enter the Failed status:
• The ThingWorx Analytics Training or Results services are not running.
• The model building process fails.
• A problem occurs in the anomaly monitor itself.