Condition-based maintenance using SAP PDMS Cloud

[abhishek_jaiswal]

Condition-based maintenance (CBM) is a maintenance program that recommends maintenance decisions based on the information collected through condition monitoring. CBM focuses on the physical condition of an equipment and how it operates. It is ideal when measurable parameters are good indicators of impending problems.

Below are some of the primary goals of a CBM System:
1. Reduced dependency on manual processes to generate maintenance action.
2. Automate the maintenance management process and make it more reliable.
3. Identify equipment degradation earlier.
4. Identify gaps in sensor data.

As per ISO 13374, a CBM system can be broken into the below six distinct and layered processing:



The purpose of this blog is to highlight how SAP Predictive Maintenance and Service, cloud edition ( SAP PdMS) provides new features (effective 1805 release) to support equipment State Detection, Health Assessment, Prognosis Assessment and Advisory generation.

SAP PdMS now supports maintenance/service engineers in setting up a rule/alert-based condition monitoring system through a user-friendly interface.

 

Below are the key feature set/features:

1) Alert/Alarm Management

• Centrally manage all the alarms (Alert Types) for an equipment model.

 

• Configure alarms by entering a semantic description and specifying whether it is a machine- generated alarm (error codes), or generated via software rules. Enrich these alarms with business semantics like measured parameter, possible failure modes, and alarm categories. The linkage to failure modes helps move towards prescriptive maintenance.

 



 

• Group the alarms according to business needs (for example, according to instrumentation, maintenance/service contracts, or other criteria)

 



 

• Assign alarms to the relevant equipment model(s) and the system automatically inherits these alarms to the on-boarded equipment.

 



 

2) Rules Management

• Set up condition monitoring at equipment model level by specifying the rule condition(s). This eliminates the need to set up a rule for each equipment individually, thereby significantly reducing the system configuration efforts.

 

The rules are used to identify possible symptoms, further possible causes, and finally infer a diagnosis. The symptom identification is done by monitoring the measured parameters.

Below is an example of a rule:

If machine status is ‘producing’ and ( feed flow > 100 liter/hour and motor speed < motor design speed) then machine is in a critical state and needs some action.

 



 

• Activate/deactivate the condition monitoring for individual equipment(s) according to the business needs (for example, according to the unique equipment operating conditions, environmental conditions, maintenance/service contracts…).

 

• Support the maintenance/service departments in an organization to automatically trigger emails informing the responsible engineer(s) about the alarm conditions. Specify the recipients (business partners) for a rule-based alert while composing the corresponding rule for an equipment model. As a result, the system sends an email to all those recipients when the rule conditions are met.

Process flow summary:



Plans for upcoming releases:

• Set up condition monitoring at individual equipment level by specifying the rule condition(s) for that equipment according to its own unique operating condition, environment conditions, usage patterns…


• Allow composition of rules using aggregate functions over a defined time window. Trigger of alerts/alarms based on calculation of the history of condition readings (average, sum, mean, max or min of last n readings must be within certain control limits).

Here are some examples:

If motor temperature > 80C 5 times in the last 1 hour
or
If motor temperature > average motor temperature last week

• Allow support for further automatic actions corresponding to a rule. For example, when a sensor detects a machine vibration level above the upper control limit by a user-defined amount for a user-defined period, it can initiate an alarm condition and optionally also a ticket in the backend system like a ERP PM notification or a C4C ticket.


• Support the usage of additional data like equipment attributes, alerts and work activities to trigger rule-based alerts/alarms.

Stay tuned for even more insights in subsequent blogs.