Skip to Content
Technical Articles

Predictive Asset Insights – Mass Assignment of Failure Modes to Notifications

Synopsis

This post describes how customers of SAP Predictive Asset Insights (PAI), fka SAP Predictive Maintenance and Service (PdMS), can programmatically assign failure modes to notifications. This is relevant if that assignment was not previously made, but is now required to make use of certain PAI functions.

Kudos to Karanjeet Singh for compiling all the technical steps described here!

 

Introduction

A brief explanation of notifications, equipment, and failure modes

A notification is the request to perform maintenance. A notification can be of type “breakdown” when the equipment did not perform its intended function anymore.

A failure mode describes what the observable problem of an equipment issue was, which then led to a notification. Examples would be “overheating bearings” or “flooded carburetor”. Failure modes are different from “causes”.

From all the failure modes a customer set up in PAI, none, one, or more can be assigned to an equipment (or the model of the equipment).

When a notification gets created for an equipment, it can only be assigned one of the failure modes which were previously assigned to the equipment.

 

Notification failure modes are consumed in PAI functions

In SAP Predictive Asset Insights we have functions where we use breakdown notifications (with failure modes) as part of the input data, and differentiate the output of the function by the failure modes the breakdown notifications were assigned to. That is the case for example in:

 

  • Failure Curve Analytics – the curve is always shown for one failure mode, and the user may select a different one.

 

Damage codes and failure modes

PAI customers likely replicate their notifications from their SAP ERP or SAP S/4HANA system where they may have assigned damage codes to their notifications, but in the current PAI release these codes are not transferred automatically from the backend to PAI and turned into failure modes.

 

Options for assigning failure modes to notifications

Customers have three choices to assign  failure modes to notifications:

  • Do it manually in the Equipment application. That is a fine approach for a handful or two of notifications, but would be too tedious for more.
    • Tab Maintenance & Service > Notifications

 

    • Select a notification

 

    • Select Edit

 

    • Select a failure mode in either the user-proposed or confirmed failure mode field

 

  • Use the functions of PAI Failure Mode Analytics to propose a failure mode based on text matching between the failure mode description and the notification long text
  • Create a program to support the assignment work

 

This post gives you tips and tricks to do the last option.

 

Mass assignment of failure modes to notifications

Required skills

You need to have experience performing API requests programmatically using Postman or a similar platform, or a scripting language. For learning Postman check https://learning.postman.com

You also need experience for working with CSVs using MS Excel or something similar.

 

Understanding Asset Central Foundation public APIs

You will need to work with the public APIs of PAI’s Asset Central Foundation for notifications and failure modes. Check the API Tutorial for more information.

 

Notifications APIs

      • Base URI: Application_URL/services/api/v1
      • Permissions: You must have the roles EQUIPMENT_EDIT or EQUIPMENT_DELETE for equipment and FUNCTIONAL_LOCATION_EDIT or FUNCTIONAL_LOCATION_DELETE for locations assigned to your user ID.
      • API hub linkNotifications API

 

Failure mode APIs

      • Base URI: Application_URL/services/api/v1
      • Permissions: You must have the roles FAILURE_MODE_READ, FAILURE_MODE_EDIT, or FAILURE_MODE_DELETE assigned to your user ID.
      • API hub linkFailure Modes API

 

The five steps of the assignment process

The following steps need to be executed programmatically.

      • Steps 1-3 should be one program to get the mapping of notifications to assignable failure modes derived from the assigned equipment
      • Step 4 is a manual step to edit the file created in the previous steps to create a final mapping of a failure mode to a notification
      • Step 5 programmatically uses the finished version of the edited file from step 4 to persist the assignment of a failure mode to the notification

 

Step 1: retrieve the list of notifications in the system 

Request:

GET Application_URL/services/api/v1/notification

 

Sample Response:

[{

“notificationId”: “B4A240A5D6C44157882C2BF8F5427FD7”,

“shortDescription”: “test notification”,

“equipmentId”: 39F154B4964C403ABFFF2822205424FE,

“equipmentName”: “VIB_TEST_GVV94mFEW9”,

“rootEquipmentId”: null,

“rootEquipmentName”: “VIB_TEST_GVV94mFEW9”,

“internalId”: “NO.CFMANU.80”,

“modelId”: “6737BD2BEDEA4D118B651871B37710D2”,

“confirmedFailureModeID”: “”,

“confirmedFailureModeDesc”: “”,

“confirmedFailureModeDisplayID”: “”

// other details removed for brevity

},…],

 

Step 2: loop through notifications to get equipment and possible failure modes

Programmatically loop through the list of notifications from the first step and get equipmentId attribute for the current notification. Use this value to get the list of failure modes for the equipment object by using the following API request:

Request:

GET Application_URL/services/api/v1/objects/{objectType}/{objectId}/failuremodes

 

Sample Response:

[{

“ID”: “2F6F3B79535942FDB3EC8B5B1EAF36C6”,

“DisplayID”: “test failureMode”,

// other details removed for brevity

}, {

“ID”: “A84C7879535942FDB3EC27FDB1E240A6”,

“DisplayID”: “test failureMode”,

},…],

 

Result: Proposed failure modes derived from equipment are available for a notification

 

Tip: Ignore notifications from the list which already have failure modes assigned.

 

Step 3: export

Export this mapping of notificationId and list of failure modes from the previous steps to a CSV File which we will be using in the next steps.

 

Tip: hold the notificationId value for a notification from step 1 in a variable which can be used when exporting a CSV with a mapping of this notification to proposed failure modes.

 

Note: here we only show the GUIDs, but you’d want to also have the failure mode ID and description

 

Sample Output CSV File:

 

Step 4: assign the failure modes in the CSV file

Manually transform the CSV file from the previous step to have a final desired mapping of notifications and assigned failure mode.

 

Sample Output CSV:

 

Step 5: persist the failure mode in the notification

To assign a failure mode to a notification, import the file from previous step and for each failure mode get the list of notifications to be assigned.

 

For each notification:

 

(1) Make a GET request for current Notification ID to get required details needed as a payload in the next step.

Payload from Help Portal:
Notification PUT

Request: GET Application_URL/services/api/v1/notification/{NotificationID}

 

(2) Make a PUT request with attribute confirmedFailureModeID in payload to the current notification payload and make the following API request.

Request: PUT Application_URL/services/api/v1/notification

Sample Payload for Request:

{

“notificationId”: “B4A240A5D6C44157882C2BF8F5427FD7”,

“shortDescription”: “test notification”,

“equipmentId”: 39F154B4964C403ABFFF2822205424FE,

“equipmentName”: “VIB_TEST_GVV94mFEW9”,

// other details removed for brevity

“confirmedFailureModeID”: “2F6F3B79535942FDB3EC8B5B1EAF36C6”,

“confirmedFailureModeDesc”: ” test failureMode”,

“confirmedFailureModeDisplayID”: ” test failureMode”

}

 

Did this help?

Let us know if you were able to use these instructions for your own assignments.

And let us know if you have ideas to improve them!

Be the first to leave a comment
You must be Logged on to comment or reply to a post.