Add This Important Tool to your Predictive Maintenance Approach: Aspen Mtell

Back in the day I was a reliability engineer that supported space missions. We worked with very specialized and one-of-a-kind equipment. While we did have a good degree of redundancy in our systems, each element was deemed critical and required us to know what the probability of failure was at any time, as well as under specific operating conditions.

A large part of my job was to comb through not only closed work orders, but also operational data streams, looking for evidence and patterns leading up to failures of the past. For those failures evident in the data, I would look for those same failures in the historical work order data, making the connection back to the data to predict when they might happen again. Round and round we went between the ops data and the documented evidence of failure.

Months and years of telemetry data in different formats, custom designed over a 40-year period, and, even better, comprehensive, and thoughtfully completed work orders from our worldwide Maximo system. We didn’t waste our analytic skills on playing Tetris back then. No, grinding through all this data was satisfying enough.

Along comes tools like Aspen Mtell

To help you understand that implementing tools like Aspen Mtell would be of great benefit, start by visualizing this:

Out on the production floor (or in your facility) you have equipment that is humming along doing its job. Attached to this equipment are sets of sensors… perhaps temperature, vibration, pressure, occupancy, alarms, states, etc. that are sending telemetry at some frequency to a set of databases… let’s call them historians.

Imagine the amount of data that is being collected! Let’s say that every second each sensor is sending a packet of information with several data elements to the historian. Temperature values, averages, min, max, etc. each second… for perhaps many years. Gigabytes of time-series data ripe for analysis.

Further, all this data might be in use by Operations to respond to when sensor values are outside some threshold, then the system sends an alarm. The control room of any facility is a busy place because of this data. Many flashing red icons and perhaps even audible alarms going off all the time. Operations earns their money for sure, chasing down all this noise. Maintenance as well is on the receiving end of these alarms as they are often turned in to break-in or high priority work.

A look into the future of your equipment

While all that data and alarms are good for the moment, wouldn’t it be compelling to be able to analyze all this data to look for patterns and signatures of developing failures? In the back of your mind, you “know” that the data has in it evidence that your equipment is slowly moving to the right aiming for the ditch.

Also, you and your field teams have done an excellent job for the last few years clearly documenting in work orders when failures have occurred. Approximate start/end timestamps of not only the work, but also the resulting downtime. What the failure was, what the cause was, and what was done to remedy the situation. You have been doing this, right?

Now imagine a solution that assists you in bringing together all this telemetry from your historians and your work order system (let’s call that an EAM or CMMS). Then, with these sources of data in hand, be able to comb through it looking for patterns, signatures, and anomalies? The solution is doing the analysis… not you!

First steps…

One of the first steps to take is identifying the equipment/process groups that are critical to the operation. Best to start with a small and well-defined set of equipment before trying to take on the entire floor! If you have a CMMS/EAM system already in place, it can be an excellent source of the location and asset (equipment) hierarchy that describes where things are and how they might be related.

Now that you know what the focus of your initial efforts is, then you can begin to explore what sensors are on the equipment, the kind of data that they are producing, and where the data is currently stored. You may discover that the historical data is physically stored on different servers than the real-time data. You might need to crawl around on your hands and knees out on the production floor, following network cables to and from these “edge” computing devices.

Yes, gathering the sources of data and forming a reasonable understanding of what they contain, and for which equipment can be an initial time consumer. However, do not make the incorrect assumption that tools such as Mtell require “perfect” data, nor should you assume that your data is a complete mess either. Simply plan to spend some effort up front organizing the sources of data.

Learn as you go…

Mtell uses well known and time-proven statistical and machine learning methods (let’s properly call them algorithms) to analyze the data and visualize patterns. Yes, a human could do this for a few sensors (variables) with a spreadsheet, but how about 100’s or 1000’s? Best to leave that heavy lifting to a computer. That is why we invented them; to do the crunching for us.

With Mtell, you create virtual entities called “Agents,” that focus on finding anomalies or specific failure signatures in the data. Your first step is to introduce your historical data to the Agent for it to filter and learn with. Some Agents are trained to understand what “normal” is, while others are tuned to see trends developing that indicate a failure is impending. (There are other types of special purpose Agents available, but we will have to talk together about those.)

Once the Agent has been trained in what to look for, they are “deployed” to ingest the incoming live data (still from the historian databases, but in real time) looking for whatever they have been trained to look for.

Then, when a trend or an anomaly appears, the system sends out an Alert. (Not an Alarm for immediate action… an Alert to use for consideration and planning) The idea here is that the system is seeing a developing problem and is letting you know so you can plan for remediation vs. reacting immediately to the problem. The point here is that, based upon available data, the system is predicting that something is amiss and well ahead of time. It should be obvious the inherent value of these early warnings.

Over time, the Agents refine their learning (or are re-taught) the signatures of failure, delivering higher probability Alerts and, in some cases, with greater lead time. It is also possible that Alerts will come with shorter lead time, but with higher confidence. It is this sliding scale of lead time vs. probability that is a unique capability that tools like this deliver to you for decision-making.

I have an Alert… now what?

Here is the beauty of all this… you get to decide! An Alert from the system informs you that there is a high probability that either an anomaly in the live data stream has been detected, or that a failure pattern is being detected, indicating an impending failure. What you do with either of these indications is up to you. Maybe you dispatch a team to go inspect the situation. Maybe you generate a work order that gets inserted into your planning and scheduling process. No matter what the Alert is telling you, a human gets to decide what happens next.

Remember, the system is predicting, with a high degree of confidence, that something is amiss… something is brewing… based upon what you trained it with. Your collective experience and data have coalesced into an entity that runs in the background 24/7 looking for signs of trouble.

I don’t believe any of this Machine Learning hokum… prove it!

Can do! Making predictions using probability and statistical methods is not new. Data scientists have been munching on data in this fashion for many decades. What is new are solutions such as Aspen Mtell that have brought the power of these methods to the desktop of a reliability or process engineer. Rather than the analysis of this data being static as in a snapshot in time, and manually arrived at, it is in near-real time and actionable.

The data you have spent years collecting has hidden trends and patterns that you can benefit from knowing about. These patterns easily align with your work order activities, showing the relationship between brewing problems and the reality of equipment failures and downtime that have occurred.

You know the failures that your equipment has experienced, and what you did to react to and remedy the situation. You also know what to look for on the production floor that needs your attention. All the while your data collection engine has been quietly storing the evidence of all these activities, just waiting for you to make use of it.

We recommend that you select an initial set of equipment and a few significant failures that you wish to look for as a starting point. Do not take on the entire production floor at once. Start with a proof of concept to gain experience with the system, learning what it is telling you.

Wrap up

It is natural to be skeptical of the notion that a software/logic system could tell you something that you either didn’t know or couldn’t find out by other means. Our world thought this while making the transition from paper maps in our cars to maps displayed on the dash or on our mobile phone. Both works well to get us to our destination in their own way. But we must admit that the displayed map and its feature/function can be vastly more informative and efficient especially in a complicated environment.

The signatures of impending failures are in telemetry data… there is no denying that. The difference now is we have tools to point out these hidden patterns well ahead of failure, giving us far more lead time to make decisions.

TRM has been working with clients and their data sets for many years across industries. Contact us so we can show you Aspen Mtell in action and what it is capable of in the context of your operations and collected data. You will be impressed with what the solutions deliver and clearly see how it fits into your Predictive Maintenance methodology.