Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
former_member183045
Contributor
In the following blog I will show how the predictive service of the SAP Cloud Platform can be used to detect unusual behaviour of a production machine. This could be in the ideal case the basis to avoid unplanned future machine downtime.

Introduction


The Cloud Platform, predictive services API seems quite promising. You can make predictions on a set of data without the need of writing some code or even carrying about the structure of the data. The only thing you have to do is to get your data into the Cloud Platform and then call the intuitive, predefined API services.

While playing around a bit with it I was thinking about a real case scenario which could be solved with this Cloud Platform service.
Well, one of the mostly discussed topics currently in this area is predictive maintenance, therefore I selected this topic and tried to design something in this area.

So let's open the curtains for my business case 🙂

Think of a production company which has a lot of drilling machines in its production area. These machines are fixed but due to moving parts they have movements in the three axes. As they are working without human interactions rising problems for example with the spindle should be predicted by examining their sensor data.

 
Simple model of a drilling machine

 

Machine setup


Due to the fact that drilling machines with build-in sensors for measurement of the 3-axis positions are currently rare and too costly for playing around I fixed my mobile phone on the drill of a simple drilling machine which serves normally to fix pictures on the wall of my flat ;-).

With the installation of the free Android app Accelerometer on my mobile device the test setup is complete.

Setting up the predictive service


I will not describe the setup of the  SAP Cloud Platform, predictive services in this blog as there is already an excellent blog in the SCN area: Predictive Services Starter Kit and if you prefer video tutorials I recommend the following two tutorials of the SAP HANA Academy Series: SAP HANA Academy - HCP predictive services: Getting Started (Trial Edition) and SAP HANA Academy - HCP predictive services: Outliers.

I sticked with the video tutorials. After following the instruction of the two tutorials there is only one step left to get the setup for my example:

Additionally I added a table POSITION_DATA with the fields ID, X, Y and Z to the schema PS_DATA in the HANA MDC database.

Data preparation


After starting the sensor collection in the Accelerator app I switched on the drilling machine for approximately 50 rotations altering continuously the speed. Before the 5 last rotations I gave the machine a slightly kick, simulating a failure with the spindle, the y-axis fastener or something similar.

To keep it easy I transmitted the collected sensor data afterwards manually first to my computer and then to the Cloud Platform. The Accelerator app delivers a CSV for each recording thus the import into the HANA MDC database on the SAP Cloud Platform is quite straightforward.

The sensor data retrieved from the mobile phone contains approximately 1100 data points. In my example the drilling machine was horizontal and the mobile was fixed also horizontally on the drill. This explains why the x and z axis values have high peaks (rotation) and the y axis small peaks (rotation axis) - just if you care.
# The following file provides the data from accelerometer in the m/s^2 format.
# The diff value is just a time delta between the samples
#
# data format:
# so we have 4 columns with values separated by the ";"
# X;Y;Z;time_from_previous_sample(ms)

# units set to: Gravity
# gravity NOT filtered out
-7.996;2.193;-7.077;0
-6.799;2.375;-7.642;21
-5.564;2.221;-9.078;21
-3.581;2.068;-10.17;21
-1.149;1.915;-10.247;21
0.22;1.963;-10.553;21
2.317;1.695;-9.758;21
4.807;1.57;-9.318;21
6.11;1.359;-8.149;21
7.086;1.321;-7.058;22
7.814;1.292;-5.736;21
... and approximately 1000 more data tuples for 25 seconds

Text file with the sensor data




Graphical represenation of the sensor data


Spreadsheet with data can be found at https://github.com/andau/outliers

 

Data analysis


To analyse my data I selected the Outliers API. My hypothesis is, if there is a condensed cluster of outliers in a certain timeframe this should correspond with a (upcoming) malfunction.

  1. Data upload. 

    The first step is to insert the data into the prepared table. As mentioned before I loaded the data into the table manually for simplicity reasons.

  2. Registration of the data in the Recommendation API. 

    The second step is to tell the Predictive Service which data set should be used. This can be done with the POST-method /api/analytics/dataset/synch. The only parameter which has to be provided is the hanaURL which gets the value "PS_DATA/POSITION_DATA" as shown below.
    Data set registration to the predictive service

    After pressing the POST button which did not fit on the screen shot above you get a Status 200 response in case everything could be processed like expected.
    In the response the ID which is needed to reference the data set is returned. In our case 28.


    Response of the data set registration 


    After registering the data you can choose of various Predictive Services APIs. For this example Outliers fits best. To start the data processing the POST method /api/analytics/outliers has to be called. The method needs at least 4 parameters.
    - the datasetID, which we retrieved as response of the method above
    - the targetColumn, which should be used for the prediction *)
    - the numberOfOutliers which should be returned
    - the numberOfReasons for each outlier which should be returned

    *) I analysed my data with all 3 axes as targetColumn and each of them returned similar results

    Starting the outlier analysis


     


    As response the method returns once more an ID. In this case it is the job ID of the outlier processing which has be started. Dependent on the data size the processing takes some time, in my case not more than it takes too call then next method.

     

  3. Starting the Outliers API. 

    The result of starting the outlier analysisWith the retrieved job ID the method /api/analytics/outliers/jobID can be called. This method return the calculated outliers if the processing is already finished.

  4. Getting the results. 


    Querying the result of the outlier analysisThe result contains a lot of information. The important is the number of found outliers and then a list of all outliers with the real and predicted values and the main reasons why the data point is an outlier (the number of reasons was given as an parameter in the processing call).


    The result of the outlier analysis




The result contains 19 outliers, shown in the diagram below. 13 of them are clustered on one area and the six remaining are splitted randomly. Thus it can be assumed that at the position next to data point 1000 there was an unusual behaviour which exactly corresponds to the slightly kick that I gave the drilling machine.


Visualisation of the sensor data with the outliers indicated as dots



Summary


I am really surprised how fast you get the SAP Cloud Platform, predictive services running and how intuitive the handling of the different API functions is.

The outlier service seems to give good results if the sensor data trend is smoove and/or of course if the outliers have a significant distinction to the common trend. The best results I got with sensor data correlating to a sinus function which is the case for the above example. Working with another machine that has a lot of noise in the sensor data lead not to satisfactory results.

As a follow up to this concept the next step would be to send the machine sensor data in realtime. Well this is a bit of work but I do not see a show stopper in this step. To get the results in nearly realtime back is a different thing. Currently I know only the possibility to register the whole data at once and perform the analysis which takes together some time as shown above.

Ideally in my opinion would be a possibilty to send one sensor data point (eg. one data point for X,Y,Z only) and receive as a result the information, if this single data point is an outlier compared to a sample data set or the already transmitted data set.

Thanks for reading till the end of this blog describing an use case with the SAP Cloud Platform, predictive services. Finally I want to encourage you to share your experience, suggestions and questions in the comment section below.
1 Comment
Labels in this area