Business Objective:
For many of the OEM manufacturers or for those client(s) who have individual manufacturing lines, the business objective is to increase overall equipment effectiveness which defines impact on the product(s) manufactured not only from loss in terms of quantity being generated but also around the quality being generated which might end up as a huge re-work.
Business problem / opportunity:
The main impacting factor on OEE (Overall Equipment Effectiveness) in this line is unscheduled equipment downtime for technical reasons, or as an operational consequence of another type of downtime impacting a machine's OEE. The move to predictive maintenance will allow maintenance engineers to shift their focus on achieving a higher equipment up time figure, reducing scheduled maintenance to tasks designed to increase up time based on early warnings on production machines & processes.
Scope of the asset being built as a ready to deploy solution:
Based on the user requirements around the KPIs get the initial data analysis, data preparation and machine learning algorithms applied to identify the
The objective is to get this solution delivered by SAP Data Intelligence not only as a data orchestration product but also as an AI/ML based handler which can address the above scenarios.
Complexity:
The complexity of the project was not just getting the predictive models in place but also being able to carry out data processing using the SAP DI pipeline where both R based script along with standard operators were used to get the required output which then was fed as an input to the ML Scenario manager.
KPIs addressed:
While OEE is a key metric that plant management uses to assess productivity of the plant & plant equipment. OEE is impacted by 3 key losses
(a) downtime loss - when machine unexpectedly goes down & stops production
(b) quality loss - when bad parts are being produced reducing the total product (yield) & increasing the scrap
(c) speed loss - when the production line or equipment is not producing targeted number of parts due to bottlenecks or slower manual feeds
Hence the main KPI was to how do we predict the failure of the equipment along with potential downtime based on other influencing factors to ensure the OEE can be improvised?
We have leveraged IBM’s foundational methodology for data science to get this use case delivered
Before we go into the details of the solution within DI and SAC, lets have a look at the solution architecture leveraged
The solution not only leveraged SAP HANA as DB along with SAP DI, SAP SAC but also had a use case implemented leveraging the machine floor data processed into SAP MII and from there the same being pushed into SAP IOT based system from where this data was processed into SAP PDMS for Anomaly detection to be done leveraging “Auto Anomalous detection” technique.
Stay tuned for a follow up blog to get more details around the PDMS usage and the Pros and Cons of the same compared to SAP Data Intelligence.
Coming back to the solution, lets have a quick review of the SAP DI pipelines put together to address the requirements:
We have developed three graphs/pipeline which are consuming data, transformed the data and store in Database or data lake as per our POC requirement. We tried to use different operator to showcase the full capability of DI from Modeling perspective.
Our Data Intelligence graph can read unstructured data from any SDL (in our case its AWS S3). By using Python operator, unstructured data is converted to structured format(.csv) for further processing. We are using HANA DB as staging to store converted structured data and using the same HANA table to transform the data as per pre-defined business logic. R script operator based on docker image in pipeline, is used to convert the numerical value from Hexadecimal to Decimal for final data preparation.
Final output will be stored in HANA DB. SAP MII will consume the same data to push SAP PDMS via SAP Leonardo for Anomaly Score generation.
Snapshot of DI Pipeline
To more know more about technical details of the pipeline please read our next blog.
SAP PDMS data can be consumed only by API. DI has lot of predefined operator to consume API data in structured format (JSON, .CSV). Instead of using any predefined DI Operator, we used a python script which not only read the API data and also store the data directly in HANA DB. Python script is dependent on Docker image which installed required libraries.
Technical details of the pipeline will be available in our next blog
Key DI features used:
Key Takeaways:
Pipeline execution can be debugged step by step.
Now that we have reviewed the DI pipeline related effort, lets go through the process followed for SAP DI ML Scenario manager:
Once the data is prepared and persisted in HANA database, we create our Machine Learning (ML) experiments using Jupyter Notebooks via the Machine Learning Scenario Manager. We use the Python Producer template graph to read the data (from HANA table), train and finally generate the model on top of this data. The metrics are saved to check the performance of the model and the model artifacts are saved for inference on new data. The 3 ML use cases are detailed below.
Detect Anomalous Voltage and Current Readings
This ML experiment reads the formatted machine data (from the data preparation pipeline output) and finds anomalous voltage and current readings in peer groups across robots. Open source Python libraries are used to predict anomalies in the dataset. This analysis also helps us to detect local (specific to a robot) versus global anomalies (across all robots in assembly line) and thereby take preventive measures.
To more know more about technical details of the use case please follow our blog series.
Pattern Mining to check Common Messages that lead to Failure
In this ML use case, we mine for frequent patterns from the streaming message data generated by monitoring systems. The patterns of most interest are those which lead to failures. These antecedents are monitored and when encountered in future will call for action (via some alarm mechanism). Thus, a preventive check can be done for the robot component thereby reducing chances of failure. In this experiment, we use SAP HANA Predictive Analytics Library (PAL) via the Python Machine Learning package to perform the association analysis. No data copyback to DI server is needed since the training is federated to HANA engine.
A small code snippet which leverages the HANA PAL via Python ML library is shown below:
To more know more about technical details of the use case please follow our blog series.
Prediction of Component Failure in the Event Window
Whereas the previous 2 use cases talk about unsupervised models, this is a typical supervised learning example. We try to predict in the ‘Event Window’ whether the robot component is going to fail given that it has stayed healthy in the ‘Campaign Window’. The data is taken both from the Anomalous current/voltage readings and Message counts to perform the analysis. We use Python open source classifiers to predict the target (‘failure’ / ‘no failure’). Some key metrics are evaluated, and further tuning is done to improve the model performance. A sample ROC-AUC curve from the training run is provided below:
To more know more about technical details of the use case please follow our blog series.
Deployment of the Machine Learning Pipelines
The machine learning experiments are deployed using ML Pipelines integrated in the ML Scenario Manager in SAP DI. Since our experiments are done using Python, we use the SAP provided ‘Python Producer’ template and change the source to read from an SAP HANA table. The Python script is modified to read the data and send the output to appropriate node to generate metrics and produce artifacts (for future inference).
The sample pipeline for supervised training pipeline is shown below:
Key DI features for ML used:
Key Takeaways:
The inputs and outputs of Python code for each ML experiment are handled via API calls to the connecting ports of operators (preceding and succeeding).
As the flow suggests, lets have a quick look at the analytics put together once the required data processing and the ML predictions have been made:
Our Equipment Performance Dashboard will help you to monitor all your equipment’s at one place by
Key SAC features used – SAC Live Models on top of HANA Calculation Views, Heat Maps, Time Series Charts, & R –Scripting for custom visualization of Scatter plots and Lollypop Charts.
Key Takeaways –
Below is a quick overview of the home screen of the SAC story board put together. We will discuss in more detail about each of the KPI being reported in our upcoming blog (link here).
Benefits to the client(s):
We will provide further details of the operators and graphs used along with the ML scenario lessons learnt and the SAC story board including the step by step breakdown of what imputation strategy and the output of EAD has been in our next blog.
Those who are interested in downloading the solution, please visit the IBM Solution hub using the link provided (link here).
Introducing the team who made this asset possible
For more questions, please drop us an email at dhatluri@in.ibm.com
For many of the OEM manufacturers or for those client(s) who have individual manufacturing lines, the business objective is to increase overall equipment effectiveness which defines impact on the product(s) manufactured not only from loss in terms of quantity being generated but also around the quality being generated which might end up as a huge re-work.
Business problem / opportunity:
The main impacting factor on OEE (Overall Equipment Effectiveness) in this line is unscheduled equipment downtime for technical reasons, or as an operational consequence of another type of downtime impacting a machine's OEE. The move to predictive maintenance will allow maintenance engineers to shift their focus on achieving a higher equipment up time figure, reducing scheduled maintenance to tasks designed to increase up time based on early warnings on production machines & processes.
Scope of the asset being built as a ready to deploy solution:
Based on the user requirements around the KPIs get the initial data analysis, data preparation and machine learning algorithms applied to identify the
- Outliers / Anomalies w.r.to features impacting or causing the downtime
- Pattern identification to be able to call out potential sequencing based on which there is a probability of the failure to happen
- Prediction of the failure based on the combination of anomalous records and the transaction history
The objective is to get this solution delivered by SAP Data Intelligence not only as a data orchestration product but also as an AI/ML based handler which can address the above scenarios.
Complexity:
The complexity of the project was not just getting the predictive models in place but also being able to carry out data processing using the SAP DI pipeline where both R based script along with standard operators were used to get the required output which then was fed as an input to the ML Scenario manager.
KPIs addressed:
While OEE is a key metric that plant management uses to assess productivity of the plant & plant equipment. OEE is impacted by 3 key losses
(a) downtime loss - when machine unexpectedly goes down & stops production
(b) quality loss - when bad parts are being produced reducing the total product (yield) & increasing the scrap
(c) speed loss - when the production line or equipment is not producing targeted number of parts due to bottlenecks or slower manual feeds
Hence the main KPI was to how do we predict the failure of the equipment along with potential downtime based on other influencing factors to ensure the OEE can be improvised?
We have leveraged IBM’s foundational methodology for data science to get this use case delivered
IBM Foundational Data Science Methodology
Before we go into the details of the solution within DI and SAC, lets have a look at the solution architecture leveraged
Solution Architecture with PdMS and SAP DI/HANA/SAC
The solution not only leveraged SAP HANA as DB along with SAP DI, SAP SAC but also had a use case implemented leveraging the machine floor data processed into SAP MII and from there the same being pushed into SAP IOT based system from where this data was processed into SAP PDMS for Anomaly detection to be done leveraging “Auto Anomalous detection” technique.
Stay tuned for a follow up blog to get more details around the PDMS usage and the Pros and Cons of the same compared to SAP Data Intelligence.
Coming back to the solution, lets have a quick review of the SAP DI pipelines put together to address the requirements:
We have developed three graphs/pipeline which are consuming data, transformed the data and store in Database or data lake as per our POC requirement. We tried to use different operator to showcase the full capability of DI from Modeling perspective.
- Graph for to prepare data for Anomaly detection of Robot
Our Data Intelligence graph can read unstructured data from any SDL (in our case its AWS S3). By using Python operator, unstructured data is converted to structured format(.csv) for further processing. We are using HANA DB as staging to store converted structured data and using the same HANA table to transform the data as per pre-defined business logic. R script operator based on docker image in pipeline, is used to convert the numerical value from Hexadecimal to Decimal for final data preparation.
Final output will be stored in HANA DB. SAP MII will consume the same data to push SAP PDMS via SAP Leonardo for Anomaly Score generation.
Snapshot of DI Pipeline
Flow for PdMS related output into HANA DB
To more know more about technical details of the pipeline please read our next blog.
- Graph for PDMS Anomaly score, Sequence and Classification data Consumption
SAP PDMS data can be consumed only by API. DI has lot of predefined operator to consume API data in structured format (JSON, .CSV). Instead of using any predefined DI Operator, we used a python script which not only read the API data and also store the data directly in HANA DB. Python script is dependent on Docker image which installed required libraries.
Python based flow for reading API based data
- Our Third graph is capable of reading Structured data(.csv) from AWS S3 related to Sequence and Classification, transformation of the consumed data and store in HANA DB. Same data will be used by DI ML Scenario for Sequence mining and Classification.
DI pipeline for Sequence and Classification related data processing
Technical details of the pipeline will be available in our next blog
Key DI features used:
- Docker image to install different set of Python, R libraries in DI tenant which can be used in different python and R script in Operator to consume, transform and store the data.
- Schedule of pipeline like any other ETL tool
Key Takeaways:
- Lot of predefined operator are available to develop simple and medium complex level pipeline.
- Python and R Scripting knowledge can be advantage for DI consultant to develop complex graphs.
- DI can connect with almost every data source from various SAP system, data lake, Big data, RDBMS, API interface.
Pipeline execution can be debugged step by step.
Now that we have reviewed the DI pipeline related effort, lets go through the process followed for SAP DI ML Scenario manager:
Once the data is prepared and persisted in HANA database, we create our Machine Learning (ML) experiments using Jupyter Notebooks via the Machine Learning Scenario Manager. We use the Python Producer template graph to read the data (from HANA table), train and finally generate the model on top of this data. The metrics are saved to check the performance of the model and the model artifacts are saved for inference on new data. The 3 ML use cases are detailed below.
Detect Anomalous Voltage and Current Readings
This ML experiment reads the formatted machine data (from the data preparation pipeline output) and finds anomalous voltage and current readings in peer groups across robots. Open source Python libraries are used to predict anomalies in the dataset. This analysis also helps us to detect local (specific to a robot) versus global anomalies (across all robots in assembly line) and thereby take preventive measures.
Global Anomaly identification
Local Anomaly identification
To more know more about technical details of the use case please follow our blog series.
Pattern Mining to check Common Messages that lead to Failure
In this ML use case, we mine for frequent patterns from the streaming message data generated by monitoring systems. The patterns of most interest are those which lead to failures. These antecedents are monitored and when encountered in future will call for action (via some alarm mechanism). Thus, a preventive check can be done for the robot component thereby reducing chances of failure. In this experiment, we use SAP HANA Predictive Analytics Library (PAL) via the Python Machine Learning package to perform the association analysis. No data copyback to DI server is needed since the training is federated to HANA engine.
A small code snippet which leverages the HANA PAL via Python ML library is shown below:
HANA PAL via Python ML
To more know more about technical details of the use case please follow our blog series.
Prediction of Component Failure in the Event Window
Whereas the previous 2 use cases talk about unsupervised models, this is a typical supervised learning example. We try to predict in the ‘Event Window’ whether the robot component is going to fail given that it has stayed healthy in the ‘Campaign Window’. The data is taken both from the Anomalous current/voltage readings and Message counts to perform the analysis. We use Python open source classifiers to predict the target (‘failure’ / ‘no failure’). Some key metrics are evaluated, and further tuning is done to improve the model performance. A sample ROC-AUC curve from the training run is provided below:
To more know more about technical details of the use case please follow our blog series.
ROC curve analysis as a performance measure for Classification model
Deployment of the Machine Learning Pipelines
The machine learning experiments are deployed using ML Pipelines integrated in the ML Scenario Manager in SAP DI. Since our experiments are done using Python, we use the SAP provided ‘Python Producer’ template and change the source to read from an SAP HANA table. The Python script is modified to read the data and send the output to appropriate node to generate metrics and produce artifacts (for future inference).
The sample pipeline for supervised training pipeline is shown below:
Deployment graph of ML pipeline
Key DI features for ML used:
- ML Scenario Manager is used to create the ML experiments (using the SAP Jupyter Lab interface)
- The Scenario Manager is also used to create the pipelines, submit the metrics and generate the artifacts
- We used HANA PAL libraries via the Python HANA ML package to use the algorithms already developed in HANA for one use case. This would also mean no data copyback to SAP DI server and thereby reducing the training time
- HANA ML dataframe is used to easily access data from HANA database (read and writeback). The HANA dataframe is easily converted to Pandas dataframe to take advantage all the open source libraries
Key Takeaways:
- The ML experiments should use the HANA ML libraries (if possible, in context of use case). This would imply faster training times.
- Use the HANA ML dataframe features to easily read and write back to HANA database during creation of experiments
- Proper creation of docker images for using the Python / R libraries should be defined based on the base package of Python and R installation inbuilt in SAP DI
- The output of the ML pipelines culminates in HANA database, which are further used for SAC storyboards
The inputs and outputs of Python code for each ML experiment are handled via API calls to the connecting ports of operators (preceding and succeeding).
As the flow suggests, lets have a quick look at the analytics put together once the required data processing and the ML predictions have been made:
Our Equipment Performance Dashboard will help you to monitor all your equipment’s at one place by
- Monitoring the Events occurring and their severity to help monitor overall system health.
- Monitoring every equipment average Current and Voltage consumption pattern to understand if there is any anomaly .
- Analysis of event log to develop a predictive system which will be able to determine which particular warning events are more likely to lead the equipment towards a failure.
- A predictive mechanism that will help predict potentially at what time the next equipment failure may happen and will help plan predictive maintenance .
Key SAC features used – SAC Live Models on top of HANA Calculation Views, Heat Maps, Time Series Charts, & R –Scripting for custom visualization of Scatter plots and Lollypop Charts.
Key Takeaways –
- The dashboard can be configured to auto-refresh every 30 second now, not less than that .
- Complex calculations should be pushed down to Hana Calculation Views for faster performance .
- SAC Limits datapoints when there are too many in visualizations which can lead to confusion. If you need to visualize all of them you must use R-Scripting .
Below is a quick overview of the home screen of the SAC story board put together. We will discuss in more detail about each of the KPI being reported in our upcoming blog (link here).
Storyboard for Asset downtime failure - overview of landing page
Benefits to the client(s):
- Provide KPIs such as health scores, top performing assets, life expectancy, and so on for assets.
- Reduce operational risk of mission-critical equipment.
- Increased ROI on assets by predicting failures before they occur.
- Real time maintenance can have a lower cost of maintenance
- Lower customer attrition improves brand image, and lost sales.
- Discover patterns connected to various maintenance problems and enable customer retention.
- Enable just in time inventory by estimating order dates for replacement of parts through Ariba.
We will provide further details of the operators and graphs used along with the ML scenario lessons learnt and the SAC story board including the step by step breakdown of what imputation strategy and the output of EAD has been in our next blog.
Those who are interested in downloading the solution, please visit the IBM Solution hub using the link provided (link here).
Introducing the team who made this asset possible
The A team
For more questions, please drop us an email at dhatluri@in.ibm.com
- SAP Managed Tags:
4 Comments
