In oil and gas, predictive analytics efforts seem to fall into two camps: the “can’t get it off the ground” and the “can’t get it to work” despite heavy investment -- with not much in between. At eLynx, we’ve been working at the edge of the envelope on anomaly detection by building and testing various ways data models can automatically identify and classify problems and then recommend actions in real-time.
As we’ve charged forward with some beta tests, we noticed the immediate value of this work was how it engaged production engineers and field operators in the process of identifying and measuring the key variables that become the signatures of a specific problem. These often exhibit a consistent pattern of (mis)behaviors when a problem occurs.
In this process, we discovered that a fairly straightforward mathematical function can be written that sets conditions and thresholds for multiple variables that if they are ever simultaneously crossed would flag that a specific problem was occurring. This was intuitive, powerful, and it works right now with high quality SCADA data. This is a practical advancement in predictive analytics oil and gas.
This got us thinking about how we could build this multi-condition rule-making capability into our current SCADA software offering. Oil and gas companies would find this SCADA application immediately useful. The “can’t get it off the ground” group would actually make some major progress with less investment and uncertainty, while the “can’t get it to work” crowd would finally make some very large strides and realize significant gains and efficiencies.
This would also be possible at a fraction of the cost of other unproven alternatives. Predictive analytics oil and gas applications can take advantage of advanced computing and the insights and interpretations from engineers and operators in the field.
We are calling this our Multivariate Rules Engine (for now) and we wanted to share what it is and how it works at a high level. We are ready to show you more, so get in touch.
One of the biggest problems oil and gas companies experience when it comes to their SCADA and analytics investments is the perceived mismatch that is occurring between the amount of data collected and the measured improvement in productivity and efficiency. As real-time data floods in every day, this elevates the expectation of what this should enable engineers and operators to do.
But what has happened on the ground is a growing epidemic of alarms that create fatigue and indecision. As more devices measure more things, it is standard to program a set point for each device to alarm operations teams if a threshold has been exceeded. In the steady swell of data, more alarms are triggered each day. This has led to much more noise and less signal.
In addition, static set point alarms only indicate symptoms of many potential problems and not underlying causes. Without a better understanding of the specific cause, the right actions can’t be taken in a timely manner. Operators are sent to investigate and try to understand if there is a problem and what it might actually be. This process costs and wastes time, energy, and often results in missing the more important problem to solve.
The big promise with AI and machine learning is that a computer can comb through a large data set and find hidden correlations amongst numerous variables that frequently occur together to cause specific events in the field. And then be able to flag these in real-time.
The formidable roadblocks to this ideal are many, especially since most oil and gas companies do not have the foundational infrastructure and processes in place to provide the right kind of inputs into computer systems.
Lots of data does not mean it is the right kind of data. What models need in particular are the accurate ingestion of events that occur in the field based on human inspection and diagnosis. The output from machines and algorithms can only be as good or as smart as the inputs.
However, what is the heart of this endeavor is to discover the different key variables that act a certain way in unison when a particular event in the oilfield occurs. Fundamental to this undertaking is the simple, common-sense idea that looking at more than one variable in isolation should help determine with greater specificity what problem is actually occurring. This should help identify a problem instead of merely a symptom, which means a team can make the decisions and take the actions much faster to solve them.
Instead of single, static set point alarms, we know that moving to a multivariate approach -- looking at variations in data across multiple variables at the same time -- will help engineers and operators more rapidly identify problems with greater specificity. This is possible because commonly recurring events, such as liquid loading, typically exhibit a repeated pattern of conditions across a range of variables. In this case, a divergence between tubing pressure and casing pressure that reaches a certain spread is the classic signature that precedes a liquid loading event.
A rule is a formal way to express the string of conditions that must occur with a group of variables before it triggers a problem notification and a recommended action. It is written as a sequence of straightforward mathematical functions so the SCADA system can always be checking them to see if the collective trigger point has been reached.
Let’s take a common scenario. One of the typical multivariate signatures of an electronic submersible pump (ESP) gas interference problem is when a significant change in noise level occurs in conjunction with a rise in temperature and pump intake pressure. Engineers and operators can create a rule in the system to always look for the movement of these three variables and trigger a notification of gas interference when all three variables cross their designated threshold in the same timeframe.
When this occurs, these notifications of a specific and identified problem -- gas interference -- will be sent immediately to the people who are best suited to do something about it on a jobsite. Because they have a likely problem already diagnosed, they can prepare to take action to fix that problem.
The rules engine approach focuses operations teams on real problems as they first show signs of occurring. This means they will miss much fewer of them. They will also be able to get to them sooner and have everything and everyone they need to solve them much faster. With the ability to set multivariate conditions, significant productivity gains can be made.
It’s simple to add, subtract, and alter any aspect of a variable or threshold in a rule. Engineers and operators can simply program these and immediately begin to assess their effectiveness. If a specific problem occurs, such as liquid loading, and the rule with the variables only catches it 50% of the time, then engineers can look to determine what variables and at what levels might be better indicators of the problem. They can modify the rule and see if diagnosis accuracy improves.
At the same time, a rule can have a high rate of success in identifying a specific problem. When these notifications trigger, operations teams become confident and quick-acting to solve the problem.
Presently, alarms in oil and gas are cues to further investigate. These alarms are potential symptoms, not root causes. A multivariate rule results in a more effective alarm that actually triggers the right people or automated response at the right time to go do something to remedy a specifically identified problem. This is why calling it another type of alarm short changes how the operation can be run differently with the rules engine.
Depending on the rule and the action chain associated with it, once it is triggered, a notification might go to the lease operators because they're responsible for clearing out a blockage, or it might go to the compressor mechanic because their compressor turned off, or it might go to the well technicians for some other reason. The rules engine allows for a better identification of specific problems which enable better notifications that go to specific groups so the right people get the information at the right time to take action.
One of the misconceptions of AI is that human input is minimally required. A system can only learn and gets smarter if there are extensive feedback loops between the predictions and the observed realities. Most companies do not have disciplined feedback systems that record field observations and the actions taken to remedy problems. No matter how sophisticated a system is, if it doesn’t have the feedback loops, it will never evolve.
The rules engine puts smart humans who know their operations at the center of the process. It empowers them to take the patterns they spot in their data and construct rules that lead to predictions of problems. Because they understand the process and become invested in it, teams feed their field observations into the system and this helps them quickly learn what is working and what is not.
The rules engine is something that is immediately useful today. It is a practical approach that will quickly lead to ever-improving oilfield performance. Sophisticated computer models and statistical analysis will also help inform how to create better rules now and in the future. But doing this does not depend on investing great sums of money and time on the elaborate, complicated, and yet-to-be-proven.
What eLynx is creating with our rules engine is a way to bring value and performance to existing SCADA systems without the need for significant overhauls. We can provide companies the value of sophisticated analytics with this approach at a much-reduced cost. And it is not pie in the sky. Your people will understand it and can start using it right now.