Overview

The Motion Condition Policy allows you to initiate a training period by which Bluzone cloud will use a machine learning algorithm to learn baseline vibration levels for each individual beacon.  The learning period (as well as several other configuration parameters) are specified in the policy.  After beacons are added to the policy, the learning/ training period automatically beacons, and after the period is complete, the policy automatically goes into evaluation mode where it looks for significant and sustained changes in vibration behavior from the established baseline.  

If the expected vibration behavior (as indicated by RMS and peak-to-peak values of acceleration and velocity) is well understood for the asset being monitored, then the Vibration Threshold Policy provides a good solution for monitoring.  However, when the expected vibration behavior is not well understood, the Motion Condition Policy can be a good tool for detecting changes in vibration state that may be indicative of a faulty condition.  The machine learning algorithm utilized can be considered an anomaly detection algorithm (in the machine learning world), or a fault detection algorithm (in the condition monitoring world).  The algorithm uses the time domain metrics calculated on the beacon (RMS and peak-to-peak of acceleration and velocity) to establish a baseline and produce subsequent alerts. 

The following steps assume that the beacon was configured according to the standard installation instructions (using the template: 'Default Beacon Template: Condition Monitoring AI').  It should be understood that the although the beacon needs to be configured properly to be compatible with the Motion Condition Policy, the beacon configuration itself is independent of any policies setup in Bluzone.  This means that several Motion Condition Policies can be created for a single beacon, and any changes made to these policies will not affect the data that the beacon produces.  

This policy can be used with BEEKs CM v2 beacons.

Getting Started

In Bluzone, select Policies > Create, then select 'Motion Condition' for the Policy Type.  You will likely need to create several Motion Condition Policies and group beacons in them by shared configuration settings.  This is discussed more in the following sections.

Configuration

The Motion Condition Policy requires the configuration of five parameters, two of which apply to the learning/ training phase (Model Training Interval and Asset Operating Speeds), two of which apply to the evaluation phase (Evaluation Window Size and Evaluation Threshold), and one that applies to both (Model Features).

Model Training Interval

This is the interval of time over which the algorithm will use the beacon's vibration data to establish a normal/ baseline state for the beacon.  It is recommended that you select a time interval over which the beacon will see all of its normal operating behavior, including changes in speeds, changes in loads, and downtime.  For example, if you are monitoring a motor on a bottling line, and this week the line is running 1 liter bottles, next week the line is down, and the following week the line is running 2 liter bottles, a training time of 3 weeks would be needed.

Even if the monitored asset has relatively consistent/ continuous behavior, it is still recommended that you select a training interval of at least 2 weeks.  This is because the model utilizes data points to build a parametric model of the asset operating behavior, meaning that a large, robust data set is required to build this accurately.  2 weeks will usually allow enough time for a sufficient number of data points to be generated to build a robust model.

Asset Operating Speeds

This option allows you go to give some guidance to the algorithm for the training phase.  If the asset operates at a discrete number of speeds, you can enter that number here.  This number takes into account the down (0 RPM) speed, so if you have a motor that is considered single speed, you would keep this number set to 2.  If it is a variable speed drive, this parameter can be set to the known number of speeds.  The model will generally be more sensitive the higher this number is, so even if the motor operates at many different speeds, it is sometimes advisable to keep this number lower (3, 4, or 5) to avoid an overly sensitive evaluation.

Model Features

This parameter allows you to select the vibration variable to be used in the model (acceleration or velocity).  It is good practice to create two separate policies, one for each of acceleration and velocity vibration.  When using the beacon default settings, it will automatically produce both.  Acceleration vibration will typically be a better indicator of faults at the higher end of the frequency spectrum, like late-stage bearing defects or gear tooth defects.  Velocity vibration will typically be a better indicator of faults at the middle portion of the frequency spectrum, like misalignment, imbalance, and looseness/ improper mounting.  By deploying a separate policy for each of acceleration and velocity, the policy that alerts may give some guidance into what might be happening.

Evaluation Window Size

This is the moving window of time over which new data is evaluated to determine if an alert should be generated.  For each new data point transmitted by the beacon, the algorithm will look at the last window of time as defined by this parameter and determine if each data point in the window lies within the baseline levels as determined during the training interval.  This window of time should therefore be long enough to capture a typical duty cycle / shift run time for the asset.  The size of the window will also affect the sensitivity of evaluation: shorter windows produce more sensitive triggering, longer windows produce less sensitive triggering. 

Evaluation Threshold

This is the percentage of data points within the evaluation window that must be considered in violation in order to trigger an alert.  A data point is considered in violation if it lies outside of the trained baseline model.

For example, for an Evaluation Window Size of 6 hours and an Evaluation Threshold of 0.7, the algorithm will look at all data points in the last 6 hours.  Each data point will be compared to the trained baseline model.  If a data point falls within the bounds of the model, it is labeled normal.  If a data point falls outside the bounds of the model, it is labeled abnormal.  If 70% of the data points over the last 6 hours are labeled as abnormal, then an alert will be generated.

Adding Beacons

The beacons to which this policy applies are selected in the Scope section of the policy.  Unlike the Vibration and Temperature threshold policies, the Motion Condition Policy does not support a global scope, so all beacons must be added individually.  To select specific CM v2 beacons to apply the policy to, click the 'Save and Continue' button:

You may then select individual beacons to add to the policy, then click the 'Save' button:

Email Notifications

The Notifications section allows you to add email addresses to receive notifications when an alert has been generated.  The email addresses should be separated with a comma:

By default, all email notifications are disabled for new projects, so email notifications will not be active until enabled.  To enable email notifications, please request activation through a Jira ticket.

Saving Changes

Any time changes are applied to the policy, you must click the 'Save' button at the bottom of the screen in order for these changes to go into effect.

Training Status

After beacons have been added to the policy, you will see them populate in the grid view at the bottom of the screen, and will be given a Model Status of PENDING.  

The following are descriptions of the possible Model Status values:

• PENDING: a beacon has been added to the policy but the learning has not yet started because the cloud has not yet seen new vibration data
• LEARNING: the cloud is in the process of learning/ training.  The status will change from PENDING to LEARNING when the cloud has seen new data and has started the training period.
• COMPLETED: the training period is finished and the model has been successfully generated and saved.  Evaluation will now take place automatically according to the evaluation settings in the policy.
• FAILED: the period of time given for training has passed and the model was not successfully generated due to lack of data or insufficient data.  If this is the case, you will need to check to make sure that 1) the beacon is configured properly, and 2) the beacon has adequate connectivity to Bluzone cloud.  You can then restart the learning period.

Re-training / Resetting the Model

If the model training failed or you would like to re-train a beacon, you may do so by selecting the beacons and clicking the "Reset Condition Models" button.  Keep in mind that when you do this, it will erase the any existing model of that beacon on this policy.

Also keep in mind that a beacon may be added to many Motion Condition policies.  So resetting the training on one policy will not affect other policies.

Additional Considerations and Practical Use

Some additional considerations when using the Motion Condition policy:

• The evaluation settings (Evaluation Window Size and Evaluation Threshold) can be changed at any time without affecting the existing learned models.
• A beacon can be on several Motion Condition policies at one time.  If you are uncertain whether or not a robust model has been built and want to re-train, you may consider creating a new policy to train the beacon on while keeping the current policy in place, rather than re-training on the current policy.
• The model assumes that the vibration behavior during the learning period is considered "normal" and will generate alerts when the vibration behavior deviates significantly from this for a sustained period of time.  Given this approach, this policy may still be successful even if the asset is in a degraded state during the training period.  If the asset is in a degraded state and continue to degrade further, resulting in vibration level increases, a properly trained model should eventually detect this.