Prescriptive Maintenance (RxM) or Predictive Maintenance (PdM)?

The hot new term Prescriptive Maintenance is a mashup of Prescriptive Analytics and Predictive Maintenance. Both have been around for a long time. So is RxM new, or is it just a clever name? And whichever the case, how do you do it? And what’s the difference between prescriptive and descriptive analytics, and anomaly detection? Since 2015 I call the 24th of July (24/7) the World Reliability Day to recognize the women and men who keep things running 24 hours a day, 7 days a week (24/7) through reactive, corrective, preventive, predictive, condition-based, and proactive maintenance so thought it would be a good time to review Prescriptive Maintenance (RxM) and how to do it. Here are my personal thoughts:

Prescriptive Maintenance = Prescriptive Analytics + Predictive Maintenance

The term Prescriptive Maintenance is frequently popping up in articles about Digital Transformation (DX), digitization, digitalization, Industrie 4.0 (Industry 4.0), and the Fourth Industrial Revolution (4IR) or whatever you prefer to call it. There are various illustrations of prescriptive together with descriptive, diagnostics, predictive, reactive, condition-based, and scheduled are circulating. Here are two common examples [color and notes by me for clarity]:

Both illustrations, and others, are confusing some people because they mix the level of analytics detail (anomaly detection, descriptive, or prescriptive) with the time of maintenance (too early, too late, or just in time) in a single row. These are really two separate dimensions;

• time when maintenance is done
• and how actionable the analytics is

For instance, you can do predictive maintenance based on descriptive or prescriptive analytics, or even simple anomaly detection. Conversely, prescriptive does not necessarily mean it is predictive. The problem may already have occurred, but the analytics software recommends corrective action.

A better way to illustrate when maintenance is done, and how actionable the analytics is, is in two dimensions as in the illustration at the very top of this essay.

Prescriptive maintenance really means "Predictive maintenance based on prescriptive analytics" or "predictive maintenance based on recommended action". Anyway, prescriptive maintenance is easier to say so I guess the term will stick. Whatever you choose to call it, the interesting piece is how to do it.

The first dimension is the time when maintenance is performed as we have traditionally ordered maintenance schemes: reactive, corrective, preventive, predictive, condition-based, and proactive.

The second dimension is how actionable the analytics is; anomaly detection, descriptive, and prescriptive.

Analytics Detail

Since prescriptive analytics is the foundation for prescriptive maintenance, let’s take a closer look at the different levels of detail for analytics. Descriptive and prescriptive analytics have been around for a long time. Initially all analytics were already descriptive and prescriptive but it was simply called diagnostics. This is different from “anomaly detection”.

Anomaly detection

Anomaly detection means analytics detects something is not normal but it can’t tell what it is, and therefore there is no associated description or recommended action. Only when AI like machine learning became hot a few years ago did the term “anomaly” enter our vocabulary.

Very often the training dataset used for AI and machine learning does not contain multiple examples of each condition it is expected to predict such as various failure modes of a piece of equipment, or it doesn’t contain variables with a strong correlation to find a pattern. The AI/ML training dataset might be many years of data collected in your historian, but since equipment are very reliable there may not be 5 or more examples of each failure mode for the equipment or whatever number of exposures the algorithm requires to find a strong pattern. Or the data in the historian may only be process data which contains no useful early symptoms of equipment failure; because the piece of equipment had not been fitted with sensors for vibration, acoustic noise, and more. That is, the years of data for a piece of equipment in the process historian is almost exclusively for normal operation so the AI/ML algorithm can in this case only be trained for what “normal” operations looks like, and thus can tell that anything outside of this normal operating window is “abnormal” or an “anomaly”. So anomaly detection doesn’t tell you what the problem is or what to do about it, but knowing something is abnormal could still be useful information, as you can use it to initiate a detail investigation by an expert with other tools to determine what is going on and decide what to do about it.

On the other hand, the process is more dynamic, typically changing all the time with process upsets or smaller variability caused by variations in feedstock, catalyst, weather, or other factors. That is, historian data probably contains lots of samples of process upsets that can be used to train AI/ML to predict a process upset and differentiate between them, such as a change in Reid vapor pressure (RVP) before a sample gets analyzed in the lab.

Descriptive Analytics

Descriptive analytics means the ability to distinguish between multiple conditions it is expected to detect or predict such as to diagnose to distinguish various failure modes of a piece of equipment telling one failure mode from the other to more specifically pinpoint the problem to make maintenance more effective. That is descriptive analytics is more advanced than mere anomaly detection. Descriptive analytics is the most common level of analytics detail in the process industries. The most interesting fact is that instrumentation diagnostics, control valve diagnostics, and vibration monitoring was never about ‘anomaly’ but has all along been very specific; descriptive. So descriptive analytics is not new. Only the term is new. Traditionally we have simply referred to it as diagnostics.

Descriptive analytics requires more data, more variables, in order to reliably distinguish one failure mode from another. For example, both bearing wear and cavitation on a pump cause vibration, so vibration sensor data alone may not be sufficient to distinguish bearing wear from cavitation. Additional sensor data may be required. This is the reason why plants are now having their I&C engineers deploy additional sensors; advanced equipment sensors, to complement the already existing process sensors. These sensors are digitally networked using WirelessHART, fieldbus, or the future Ethernet-APL.

Various types of analytics algorithms can be used to achieve descriptive analytics. Well understood equipment like pumps, compressors, and valves for which tons of research and field data exists lend themselves very well to engineered analytics based on first principles (1P) and fault trees based on Failure Mode and Effect Analysis (FMEA) data. This is commonly referred to as known solutions to known problems.

Known solutions to known problems

With process equipment fully instrumented with the right sensors to pick up the early symptoms, engineered analytics is a very effective solution to many plant problems. Readymade engineered analytics apps are available from automation vendors. Engineers are very good at identifying failure modes and the sensors required to predict them.

When first principles or FMEA have not been established for the problem at hand, this is where data science like AI and machine learning can help. But you still need additional sensors to pick up on the leading indicators of the conditions it is expected to detect or predict.

Prescriptive Analytics

Prescriptive analytics means prescribing recommended actions for each of the many conditions it is expected to detect or predict such as suggest fixes to correct or avoid various failure modes of a piece of equipment to make maintenance more effective. That is, prescriptive analytics builds on descriptive analytics, relying on descriptive analytics to diagnose the condition to recommend actions such as alignment or lubrication of a pump. Instrumentation and valve management software have recommended actions for years, so prescriptive analytics is not new. Only the term is new. Traditionally we have simply referred to it as recommended action.

The step from descriptive analytics to prescriptive analytics is simple.

Prescription

The recommended action (prescription) can be provided by the analytics software, which is easiest. Alternatively, if the analytics app provides the description (diagnosis) the app presenting the diagnostics to the user can display associated recommended action (prescription) text together with the description. This could be alarm management software or mobile notification software. The recommended actions are entered into the software. Often more than one recommended action is provided.

Simplified for clarity

Scale Out

So, Prescriptive Maintenance (RxM) is about scheduling and carrying out Predictive Maintenance (PdM) based on predictive analytics providing recommended actions. It is not RxM or PdM. With RxM you are doing PdM with recommended action. Some plants already have prescriptive analytics (diagnostics with recommended action) for some instrumentation and control valves and using this information in scheduling and execution of maintenance for these asset classes. Now is the time to take this to the next level; larger pieces of equipment like pumps and heat exchangers. That is, get your I&C engineers to instrument these assets and deploy purpose-built predictive analytics for these equipment types as per the NAMUR Open Architecture (NOA) to maintain the robustness and safety of the core process control. With that, the plant can scale out prescriptive maintenance practices across multiple asset classes across the plant.

So, is RxM a recipe for success or just another buzzword? What do you think? Do we need this new term? Or is it just confusing? Please commend below.

Schedule a meeting for the 24th of July (24/7) the world reliability day. Forward this essay to your maintenance and reliability managers. Celebrate the maintenance and reliability teams in your plant on the 24th. And remember, always ask for product data sheet to make sure the product is proven, and pay close attention to software screen captures in it to see if it does what is promised without expensive customization. Well, that’s my personal opinion. If you are interested in digital transformation in the process industries click “Follow” by my photo to not miss future updates. Click “Like” if you found this useful to you and “Share” it with others if you think it would be useful to them.