SAP Leonardo Digital Innovation PDMS system allows user to identify potential failures and increase the production of highly critical assets. It helps industry to move from REACTIVE to PREDICTIVE. So that it reduces most of the operational and maintenance cost. This SAP Leonardo system runs on SAP Cloud Platform to support analytics , block chain , Big Data and IoT Machine Learning. Real time machine data is collected using SAP HCP Internet of Things (IoT) platform and enriched with business information and rules predict the failures using the right machine learning algorithm and historical failures.
The purpose of this blog post is to help consultant to configure end to end SAP Leonardo PDMS solution. In this blog we are covering the sensor data which comes from on-premise physical equipment’s using Internet of Things(IoT) Platform via gateway and flow through Leonardo Cockpit and then SAP cloud based predictive maintenance system(PDMS) system .
This PDMS system will capture the real time data and it will alert or notify the reliability engineer if there are any failure is going to happen in future based on the previous failures.
Julian Bellarmin working as a Technical Architect in Tech Mahindra and having around 16 years of experience in SAP platform. He is specialized in mobilize the business process in Native, Hybrid and Cross Platform using Digital Transformation Technology and bring the Modern Trending Features like Augmented Reality , Voice Recognition and Internet on Things(IoT) capabilities in to product for improve the business process.
Uma Anbazhagan working a principle Architect and leading SAP Leonardo competency and managing SAP Cloud Platform , SAP Cloud Integration and provide innovate solutions.
- Devices – Physical Device where sensor will display the data.
- Network Gateway – Edge – Gateway protocol (MQTT/REST).
- IoT Service – IoT Cockpit will consume the data in cloud.
- SAP Cloud Foundry – SAP HCP where PDMS and Leonardo has been configured
- SAP Leonardo IoT – Consume the real time data from IoT cockpit .
- SAP PDMS – Integrated with Leonardo – Consumes the data from Leonardo.
In the subsequent section , will discuss the importance of each component and how they are integrated with each other .
We have covered how the sensor data is flowing from Physical Device à Gateway -àIoT Cockpit -à Sap Leonardo Cockpit PDMS.
SAP Cloud Platform is an enterprise platform-as-a-service (enterprise PaaS) that provides comprehensive application development services and capabilities, which lets you build, extend, and integrate business applications in the cloud.
SAP Cloud Platform Cockpit is a web-based administration interface tool that provides access to number of functions for configuring and managing applications, services, and subaccounts.
This cockpit also helps us to manage resources, services, security, monitor application metrics, and perform actions on cloud applications.
Get the credentials from your admin or register yourself.
Once you logon to the cockpit , you can see all your global accounts. You can get your PDMS portal login link and Leonardo cockpit link from the below path.
Cloud platform cockpit —> Global accounts —> Sub account —> Subscriptions—> Choose the PDMS tile and click on “go to application” link.
This will open the PDMS FLP.
Based on the authorization ,PDMS tiles will be visible / enabled for the user.
To set up the authorization based on the users or stake holders , please refer part 2.
Once you get the successful login , you can see the PDMS FLP screen.
PDMS URL looks like
Configure all the required externals system.
Administrator—>Application settings—> External system —> Configure all external system with the required details.
The indicator details will be imported in to Leonardo Cockpit only after successful configuration of this step.
[please refer to the sap portal to get the list of external system and its attribute details.
If your admin id have the authorization for more than one tenant , then the automatic synchronization of PDMS indicator property changes will not reflect in IoT cockpit.
To have the automatic synchronization of PDMS indicator with IoT sensor (IoT Cockpit) , then maintain one communication user (admin) which has single tenant access. Use this user id when you create your external system configuration. However I prefers to go with manual property binding. So that I can have the control on what indicator property needs to be mapped with IoT EDGE.
Click on MASTER DATA —> Templates–>
Create the required indicators and assign to indicator group
Make sure that your indicator external id is mapped with right system.
You can find these external ID’s in Leonardo Cockpit- [Refer section 6]
Follow the Indicator Id / group Id naming conversions. Since few char values only taken in Leonardo digital twin creation.(ThingType and Thing).
Once the indicator properties are configured , then click on the indicator external id.
If you get the external system details then you can conclude that external systems are configured perfectly for the indicator.
The alert type allows you to define the alerts that are based equipment errors. It also define associations with an indicator and possible failure modes. The association with failure mode data allows you to identify associations like instructions.
Templates—> Alert Types —> Create alert types & Groups.
Assign right indicators to respective alert types .
Then assign the alerts types in to groups based on the category and the requirement.
Templates—>Attributes—>feed the attribute information with conditions.
Then assign the attributes in to attribute groups.
Create spare part and location template and assign the attribute groups.
Create model /Equipment template and assign the attribute & indicator groups.
The Failure mode is helping operator to identify the root cause of the failure based on historical data. This failure mode has been shared by OEM or OPERATOR or SERVICE PROVIDER.Based on user authorization they can edit or create their own failure modes.Failure mode will get triggered based on the rule engine configuration.
Create the failure mode and assign the equipment , models , location, spare parts ,causes , RAMS figure and instructions.Subsequently you can create the causes and effects for each failure modes.
Home –> Failure Modes.
Manufacturer shares the instruction to operator to perform the activities if there is breakdown or maintenance or operation or disposal.
As part of the instruction configuration , manufacturer / operator can assign the equipment info ,steps for the maintenance ,safety rule , failure mode, document, spare parts, duration of the activity, required person , images…etc
Once the instruction is configured , manufacturer can publish this information to required stake holders.
You can use the “RULES tile” to configure the rule engine for alerting or notifying the user if there are any deviation in the captured sensor values.
Here the notifications are getting triggered based on the rule configured .
Note: This rule engine configuration is not relate with machine learning.
A model is an abstract representation that is derived from model template. It maintains all the maintenance information.
Here you can assign the instruction, failure modes, alert types, documents, spare parts…
Based on this model user can go ahead to create the equipment.
Once the model has been configured, don’t forget the publish this .Otherwise the changes won’t reflect in Leonardo cockpit.
Equipment is a physical instance of a model.
Here operator can maintain the additional information like installation , location, documents….etc.
IoT SYNC flag should be checked to get the data from the end client.
Make sure that naming conversion should be maintained. Since Leonardo cockpit will take only few characters for “Thing” and “Thing Modeler” creation.[“Thing” is the virtual representation of the equipment].please refer Leonardo iOT section for more info]
Once the threshold limits and forecasting days are configured , publish the equipment and model. Now PDMS system is ready to consume the data from Leonardo Cockpit.
[Will discuss about configuring the “MACHINE LEARNING” section end of this document.]
The Internet of Things service cockpit is the main interface for users to interact with the Remote Device Management Service (RDMS). It can be used to register new Devices, to define the schema of messages . They can send and receive, as well as to establish the necessary trust relationship needed by devices to interact with the Message Management Service (MMS)
In this section we are going to see …
- user authorization
- Device on boarding with the required protocols.
- Sensor and Sensor type creation.
- Capability creation and mapping.
- Certification generation for handshake with end client.
Login with your ROOT Login account credentials and create the separate TENANT.
And also create the user id and password for the users.
Then assign the created user as a admin or member based on the need.
The Internet of Things Service Device Management offers an API that provides functionality for the management of the lifecycle of IoT devices. So based on your convenience and authorization you can go ahead to create the components through API or TOOL.
Capabilities are one the which you are read the it from the sensors.
Create the capability and properties for each equipment.
In this sample I have created one capability group and assigned all the properties of that sensor like temperature , pressure…etc.
Login with the newly created account.
Click on the Home —>device management—>capabilities section.
Enter the required property details like temperature ,pressure (which you have configured in PDMS – indicator)….and click on save button.
Make sure that the data type and Units should match with PDMS / LEONARDO property values. Otherwise mapping will not work when you integrate this sensor capabilities with PDMS indicator values.
Home —> Device Management—> Sensor Types.
Create the sensor types and assign the right capability group (…ie your indicator group which is created in PDMS) to sensor types.
This Gateway component is responsible for collecting data from a sensor network and sending commands to the network.
Here we are going to create a physical node of a device with the right gateway (MQTT/REST) protocol.
After a device has been on-boarded, you can download the device certificate to connect securely to the Internet of Things Gateway Cloud MQTT and REST.
Once the device is created , then you can proceed to create the sensors for the selected device.
As part of sensor creation, assign the sensor type which we have created earlier. So all the capabilities which are assigned to that sensor types will also appear in that sensor.
As part of this SAP Cloud Platform IoT configuration, Physical device needs to handshake with and IoT device.
For that we need to download the device certificate from on-boarded device in the IoT and upload in to physical device.
Home—>Tenant—>Device Management—> Devices—> Choose the device —>Click on Certificate Tab—>Choose the certificate type as P12 and generate it.
While generating the certificate , note down the secret Id of the certificate which will appear on the pop up window. This will be used in end client – postman.
And also you can see the downloaded certificate in your browser / download folder.
If you lost this secret key-value , then you need to get the new certificate and upload the same in to physical device – Here Postman.
Now it’ time to send the data from end client (Physical device) ie.. our simulated edge client to IoT cockpit. For that we need to upload the P12 certificate which have downloaded from IoT cockpit in to End client.
Click on chrome browser—>Preferences—>Manage certificate—>This will open your KEY-CHAIN.
File—> Import items.
Enter the secret password which you have noted when you upload the device certificate in to keychain.
- Download the postman from the chrome browser
- Enter the URL in the post method.
URL:<<hostname.eu10.cp.iot.sap>>/iot/gateway/rest/measures/<<alternate device id >>.
- In the authorization tab , TYPE should be marked as “No Auth” .
- In the Headers tab , KEY :Content-Type
- In the Body :
Data will be in “raw” format. choose the same .
Get the alternative ID’s of the device /capability / sensors in IoT Cockpit.
- payload should look like this..
Then click on send button to submit the data to the IoT cockpit. You will get certificate pop up.
Choose the right certificate of the device and click on OK.
If you didn’t receive the pop up for the first time , that means authorization is not configured properly.
Check once again all the configuration settings then close all the browser and sessions.
Then try again. You will get the success response status code as “200” or “202”.modify the number values and send further data to SAP Cloud Platform Internet of Things.
Open the IoT cockpit with your credentials.
Then go to Home —>Tenant—>Device Management—>Devices—> choose Your Device—> Click on Data visualization—>Choose the sensor and its properties.
The values will be displayed on the chart / Table.
Now we are ready to consume this sensor data in SAP Leonardo also from iOT Cockpit.
Open the IoT cockpit with your credentials.
Then go to Home —>Tenant—>Device Management—>Devices—> choose Your Device—> Click on Data visualization—>Choose the sensor and its properties.
The values will be displayed on the chart / Table.
Login in to SAP Cloud platform cockpit move in to Global Account—> sub account —> click on the right sub account—> Subscriptions—>Then click Go To Application in SAP LEONARDO IOT section.
This will open the LEONARDO portal.
If you don’t have the authorization , then your admin can add your id as a member.
Once logged in to the Leonardo portal , click on Thing Engineer OData / Thing Engineer Group.
Then click on Thing Modeler TILE.
From this “Thing Modeler” we can create the digital twins of physical assets directly.
In this sample , we are getting the “digital twins” directly from PDMS.
Leonardo platform will collect and process the sensor data from IoT cockpit.
Here you can invoke the customized UI5 application also which is hosted on HCP.
6.1 Mapping sensor data between IoT cockpit and Leonardo cockpit:
Once logged in to Leonardo cockpit—> Click on Thing Engineer ODATA —>Choose your device package which is created in PDMS (Refer section 1 – PDMS equipment creation) .
There you can see your Thing Modeler (Equipment Model) , Thing (Equipment) and its indicator properties associated with that.
As part of connectivity creation , Choose “SAP Cloud Platform IoT service for Cloud Foundry Environment” as a provider in ThingType.
The system will display all the devices and sensors which are all created in IoT cockpit.
Choose the right device and sensor.
Give any mapping name then perform the “Thing” and “sensor” data mapping.
You can see the green color if the Leonardo Thing properties and Sensor capabilities are matched. Otherwise this will be displayed as grey color with blank mapping indication. Click on SAVE Button to proceed further.
If the data type and UNITS not are matched , then the mapping will not happen .
Now you have completed the mapping configuration in LEONARDO .
This will consume the data from IoT sensor cockpit and pass it to PDMS.
Now it’s time to post the “measure values” from End client.
(Please refer Posting the data from postman section ):
Now you can view the sensor data which you are passing from postman in all the below three platform.
- SAP HCP IOT Cockpit
- LEONARDO portal
EDGE – postman – End Client:
SAP HCP-IoT Cockpit:
Tenant–>Device Management–>Devices–>Choose your device–>Data Visualization–>select sensor–>Choose the capability.
SAP LEONARDO portal–>Home–>Thing Modeler–>Choose the package–>Thing–>Measured Values.
PDMS indicator chart:
PDMS—> Equipment—>Master Data—>Monitoring—>Indicators.
Leonardo—>Thing Engineer OData—>Thing Type—>Thing—>Measured Values.
SAP HCP IoT cockpit—>Tenant—>Device Management—>Devices—>Data visualization
This section will help you to predict the critical failures. For that we need to configure the dataset and the model with right machine learning algorithm. Then Train the model and score it. You may need to have the MACHINE LEARNING expert to configure this section.
Create the data set for the health indicator configuration.
Use the data as much as possible. More data will improve the accuracy of the failure prediction.
In this sample we are using TEC algorithm to train our model.
Add the required “feature” and “label values” with the appropriate predict window , step size and lead time.
Based on your “feature size” , “bucket size ie..(aggregation period/step size)
your input data size(row) will vary for train the model.
For TEC [Tree Ensemble Classification], we have chosen labels and add our failure modes which are all part of this Heat Exchanger equipment. Configure the “lead time” and “prediction window”.
Once the Dataset is created , then click on “health indicator model management” tile.
As part of this model configuration, you need to give the data set as input and choose the right machine learning algorithm from the dropdown.
To calculate the health status and predict failures of equipment, you need to configure, train, and then do the scoring .
Choose the appropriate dependent , independent variable , score variable and predicted class variable.
In my sample , we have created few indicators and named as score ,health score, normalized score…etc with the below attribute values.
Datatype – Numeric
Unit of measure- None
Use those indicators in your output mapping.
There are around 10 algorithms are available in the standard package. You can go ahead choose the right one based on your need.
Choose the date range or schedule a job for train the model. once the training is completed then you can view the status in green color. After the training you can download the training input data and verify your feeds.
Once the training is completed, you can proceed to score this model.
You can find your scoring results in the log summary.
Feed the sensor data from the “end client” with healthy and unhealthy data.
In this example I am using TEC algorithm to predict our HEAT Exchanger failure.
If you are using classification algorithms ( Logistic regression / Tree Ensemble classification) then train the model with healthy (0) & unhealthy data (1) as part of sensor input.
For Example :
For train the model we have passed the sensor values with the 0 and 1.
Healthy DATA – :[85,88,285,265,0],
Unhealthy DATA – :[85,78,265,284,1],
Whenever the failures are getting triggered based on your rule configuration, you will notice that , alerts and notifications will be created for each sensor failure input data.
Currently in PDMS system ,few parameters are not taking by default like malfunction start & end date.
For the work around , you can invoke the notification through API collections.
Posting the notification from API with help of OAuth 2.0 and Generate the access token will be covered in my next block.
Here you can find the scoring results like accuracy , sensitivity , Specificity , Kappa , MCC…etc
8.4 Failure mode analytics Model management:
To analyze the notifications and failure modes for your equipment and model, you need to configure, train, and score the models in the “failure mode analytics” tile.
- To train an unsupervised model, you first need to configure it.
- Once you have configured the unsupervised model, you can train it.
- Once you have trained the unsupervised model, you can configure the supervised model.
- Once you have configured the supervised model, you can train it.
- Once you have trained the supervised model, you can use the latest trained model to score data.
This algorithm uses LDA, This algorithm takes text data as an input. Internally, this algorithm splits the data into train set and test set , It uses 90% of the data for the training. After a training, a quality metric calculated on the test set is displayed in the Log Summary in the Trainings table.
The unsupervised model identifies the characteristics of notification texts and maps the notification texts to the characteristics found in standard failure modes. After the training, it suggests the most appropriate failure mode for each notification.
You can perform validation tasks to validate and improve the suggestion.
The supervised model learns from this suggestion by performing text classification. This means, it learns the characteristics of individual failure modes from the mapped notification texts for upcoming notifications during the training. After the scoring, it maps the most appropriate failure modes to upcoming notifications.
Our next step is feed the unsupervised model as an input to this model.
This algorithm conducts automatic supervised classification on text data using ensemble agreement between multiple classification algorithms that makes a prediction.
At least one failure mode analytics model has been configured for Train the model.
The notifications for your equipment meet the following three requirements:
- The breakdown attribute of the notification is set to True or the notification Type Description attribute is set to Breakdown.
- The notification has a valid malfunction start and end date.
- The notification has a long description.
If these requirements are not met, then the notifications will not be collected during the training.
PDMS portal is not supporting to create all the required parameter for the notification.
For the work around , you can use the API for failure post the failure notification.
Once the unsupervised model is trained , then train the supervised model and pass the unsupervised model as a learner type here. (please refer the procedure given in failure mode analytics model mgmt)
To improve the accuracy of the text analysis that maps topics with top words from notification texts to the most appropriate failure modes, sap recommend us to perform validation tasks. Validation tasks are generated based on a trained unsupervised model and are displayed on the failure model analytics validation application. Once you have performed a validation task, you can apply your validation to the next supervised model
As part of the validation tasks , choose the right failure mode for each topics and click on next.
Choose the right failure mode for each notification and click next button.
Then activate the model.
It uses the machine learning and it provides you with insights and analytics about your equipment and models with the last occurring failures. It uses unsupervised and supervised machine learning to extract topics with top words from notification texts. It also uses various metrics and visualizations to provide you with insights
On the failure mode cards, you can also view details that include KPIs for MTTR , MTTF, MTBF and the top bad actors.
you can find top words found within the notifications for the chosen failure mode and equipment model by relevancy in a bar graph and a list of all related notifications.
Once your data model is trained ,then you can predict the failures with the help of RAMS failure figure and failure mode analytics.
- MTTR – MEAN TIME TO REPAIR.
- MTTF – MEAN TIME TO FAILURE.
- MTBF – MEAN TIME BETWEEN FAILURE.
So here is calculation – reliability engineer will do for predict the failure.
MTBF = MTTF + MTTR
As per the sample attached for the heat exchanger equipment , the next outlet temperature failure will be occurred in another 37.4 hrs.
To confirm this , reliability engineer will look in to the analytics of that failure mode. Based on the notification texts , he can identify the root cause for the outlet temperature failure is due to “Coolant Oil” level is not rightly maintained.
So the reliability engineer will notify / alert the technician to perform the required maintenance activity.
And also he will notify the suppliers / operator to keep the spare parts ready for this upcoming outlet temperature failure breakdown.