Traditional Alarm Management Transformed with the eLynx Rules Engine
Learn how the eLynx Rules Engine can reduce alarm fatigue, increase operator response time, and offer oil and gas operators a real-time diagnostic tool.
Traditional SCADA alarming only allows for single variable consideration. The Rules Engine, however, allows operators to alarm when multiple conditions on multiple variables are met.
Operators experience an excessive number of alarms without multivariate alarming capabilities. The Rules Engine was designed to reduce the number of alarms operators receive daily. This multivariate approach to alarm management helps operators focus on diagnostic problems they can fix.
For example, our canned diagnostic rule for Liquid Loading looks at the divergence between tubing pressure and casing pressure. When the alarm sounds, lease operators will know the well is loading. Traditional alarm settings could only notify when either variable reached a certain threshold.
The Rules Engine allows users the choice to either clear the alarm when the trip conditions normalize or when a different set of conditions are met. With traditional SCADA alarming, flagging and clearing conditions cannot be two separate things.
For instance, when tank levels are oscillating, you would not want to receive alarm notifications each time a threshold is met. Instead, the Rules Engine allows for the creation of a “dead band,” allowing operators to decide when to notify and when to clear.
Unlike traditional alarm management, the Rules Engine is not solely tied to thresholds, but can take it a step further with more complex parameters. Users have the option of working with the traditional ‘Last Known Value,’ or use functions such as minimum, maximum, and average value over a specified time frame.
As part of the new Rules Engine, the way alarms and notifications are stored has changed. The eLynx Event System gives operators a way to obtain a labeled time series data set. Data storage as a time series database can significantly augment the way operators use the eLynx Data Historian for machine learning initiatives.
When rules are running, the system records data points, such as the start and end time, or rule logic parameters. Operators may also add notes or further categorization. Data collection of points in time develops an operator’s time series analysis capabilities.
For most lease operators, production superintendents, and engineers, the Rules Engine is an answer to building a meaningful alarm management system as well as combating alarm fatigue. The Rules Engine gives a simple, yet reliable, way to sound alarms on issues that matter most. These issues could include alarms for consecutive missed arrivals or sending a notification to management when the field opens a well.
When a meter is receiving the same value repeatedly, it is likely an indication that the reading is stuck. Traditional SCADA alarm management does not have the functionality to alert you for this type of issue. With the Rules Engine, create logic that alarms when a reading shows no variation for a specific amount of time. When this rule is flagged, you automatically know there is something wrong with the sensor.
Traditional alarm management usually alarms on-the-spot. In contrast, with the Rules Engine, you can alarm for the ‘last known value’ over a specified time period. Sometimes you only need to know when a reading has been over a certain threshold for more than 15 minutes.
Traditional alarm management will send a notification for each occurrence. The Rules Engine will send a notification when the threshold has been breached for X amount of time.
Compare the average value of two different time periods. If the percentage of change for the two averages is greater than your specified threshold, the alarm will trip.
For line pressure issues, the Rules Engine compares the average line pressure for the past two hours and compares it to the average line pressure for the prior two-hour time period. Set your percentage threshold to your desired rate to detect an issue. If the percent change between the two averages is greater than your percent threshold, then the rule will flag.
When a variable’s rate of change is greater than the desired percentage threshold, the eLynx Rules Engine lets you know there is an issue. We can even look over a longer period by calculating the slope of the variable over a given time period.
The Rules Engine can alarm for variables that should be constant. Operators may choose to flag for any change of any kind. For example, if there is any change to the diameter of a pipe, the Rules Engine will send a notification.
This rule applies to variables you would expect to remain constant, such as pipe diameter. Likewise, this could be used to automatically document when changes are made, such as plate size or choke size.
Traditional alarm management can create an event for when a value is too high, but this is not always an accurate parameter for issues. The Rules Engine contains a rule that sounds an alarm when the signal to noise ratio falls outside of your predetermined threshold range for a specific amount of time. Imagine being able to know when an ESP starts gas locking after receiving a notification that the amperage is not steady.
For stuck motor control valves, set your minimum and maximum parameters for a time period.
For example, if the maximum flow rate is less than 350 mcf/d and the minimum flow rate is greater than 25 mcf/d for a period of 4 hours, then you know the valve has not shut when it was supposed to. This asset requires your immediate attention. (Setting the minimum value at 25 mcf/d prevents a leaky valve from flagging the rule.)
Advise your team that the controller needs to be reset. Obtain maximum value with minimal effort.
Instead of receiving multiple alarms for multiple communication failures, set the rule to alarm when no readings have been received for the past two hours. Traditional alarming doesn’t have that functionality. It is not helpful to get a notification every time there is a break in communication. Knowing there has been a break in communication for the past two hours minimizes alarm fatigue and pinpoints a solution to fix the radio.
Find out the percentage of out of bounds readings for a specific time period. Set your ‘in-bounds’ threshold, the duration to be evaluated, and the percentage at which you want to receive an alarm. For example, set a rule to flag when the total values less than 0 and greater than 5000 over the past 4 hours is more than 10 percent for casing pressure. Now you can detect a failing sensor without the alarm noise created by a few bad readings.
When a plunger misses an arrival, traditional alarm management lets you know when it happens, which means you get an alarm notification every single time. Often, it’s more meaningful to know when the arrival has been missed consecutively. Consequently, the Rules Engine can flag an event when there are two or more missed arrivals in a row. That means less alarms and more meaningful data.
If you are interested in learning more about the eLynx Rules Engine, contact one of our sales representatives today.