Automation Prescriptive Maintenance: A Cure for Downtime

Related Vendors

EMERSON ASIA PACIFIC PRIVATE LIMITED

DÜPERTHAL Sicherheitstechnik GmbH & Co. KG

TURCK GmbH

EagleBurgmann Germany GmbH & Co. KG

The new term prescriptive maintenance (RxM) 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 is it done? And what’s the difference between prescriptive and descriptive analytics, and anomaly detection?

Prescriptive Maintenance = Prescriptive Analytics + Predictive Maintenance. There are various illustrations of prescriptive maintenance in relation to descriptive, diagnostics, predictive, reactive, condition-based, and scheduled.

These illustrations are confusing 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) on a single axis. These are really two separate dimensions:

• time when maintenance is performed

• the level of actionable analytics

For instance, predictive maintenance is possible 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 performed, and the ‘level of actionable’ the analytics is, involves two dimensions.

Prescriptive maintenance really means ‘predictive maintenance based on prescriptive analytics’ or ‘predictive maintenance based on recommended action’.

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 understanding ‘how actionable’ the analytics are; anomaly detection, descriptive and prescriptive.

Analytics Detail

Prescriptive analytics is the foundation for prescriptive maintenance. 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 that analytics detects something that is not normal but can’t tell what it is, and therefore there is no associated description or recommended action. Only when machine learning (ML) gained interest a few years ago did the term ‘anomaly’ enter our vocabulary.

Very often the training dataset used for machine learning does not contain multiple examples of each condition it is expected to predict, such as various equipment failure modes. Or it doesn’t contain variables with a strong correlation to find a pattern.

The ML training dataset might include many years of data collected in a historian, but since the equipment is reliable, there may not be five 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 does not contain useful early symptoms of equipment failure, because the piece of equipment had not been fitted with sensors for vibration, acoustic noise or other issues.

That is, the years of data for a piece of equipment in the process historian is almost exclusively for normal operation so the ML algorithm can in this case only be trained for what ‘normal’ operations look like, and thus can only tell that anything outside of this normal operating window is ‘abnormal’ or an ‘anomaly’.

So, anomaly detection doesn’t indicate what the problem is or what to do about it, but knowing something is abnormal could still be useful to initiate a detailed 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 production process is more dynamic, 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 many samples of process upsets that can be used to train ML to predict a process upset and differentiate between them, such as a change in Reid vapor pressure (RVP).

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 it was simply referred to as diagnostics.

Descriptive analytics requires more data, more variables, 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.

Various types of analytics algorithms can be used to achieve descriptive analytics. Well understood equipment like pumps, compressors, and valves use rule-based AI built from Failure Mode and Effect Analysis (FMEA) data.

With process equipment fully instrumented with the right sensors to pick up the early symptoms, rule-based analytics is a very effective solution to many plant problems. Readymade engineered analytics apps are available from automation vendors.

Prescriptive Analytics

Prescriptive analytics means prescribing recommended actions for each of the many conditions it is expected to detect or predict such as suggestions for correcting or avoiding various failure modes of a piece of equipment to make maintenance more effective. That is, prescriptive analytics builds on descriptive analytics, after the descriptive analytics has diagnosed the condition of the equipment, corresponding recommended actions such as correcting alignment or adding lubrication is provided. Instrumentation and valve management software have had recommended actions for years, so prescriptive analytics is not new. Only the term is new. Traditionally it has simply been referred to as recommended action.

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 involve alarm management software or mobile notification software. The recommended actions are entered into the software. More than one recommended action is provided.

Scale Out

Prescriptive maintenance is about scheduling and carrying out predictive maintenance based on predictive analytics providing recommended actions. Some plants already have prescriptive analytics for some instrumentation and control valves and are using this information in scheduling and execution of maintenance for these asset classes. Plants now apply the same concept to larger pieces of equipment like pumps and heat exchangers. When the plant I&C engineers instrument these assets and deploy purpose-built predictive analytics for these equipment types, the plant can scale out prescriptive maintenance practices across multiple asset classes in the plant.

* The author is a Senior Director, Applied Technology at Emerson Automation Solutions. Contact: jonas.berge@emerson.com

(ID:47374587)