Predictive Maintenance using SAP and AWS IoT to reduce operational cost

This post was written by Kenny Rajan, Patrick Leung, Scott Francis, Will Charlton & Ganesh Suryanarayan.

The convergence of Operational Technology (OT) and Information Technology (IT) is reinventing the way companies drive manufacturing efficiency. From the shop floor at the Programmable Logic Controller (PLC) level to the Manufacturing Execution System (MES), all the way up to SAP Plant Maintenance (PM) or S/4HANA Asset Management.

With AWS IoT solutions, industrial companies can digitize processes, transform business models, and improve performance and productivity, while decreasing waste. These are some examples of how customers can apply AWS IoT solutions to improve the performance and productivity of industrial processes.


In this blog post, we show how to integrate AWS IoT solutions with SAP for predictive maintenance. SAP Plant Maintenance (PM) comprises a set of data and processes to maintain the high availability of technical systems. This helps customers move away from outdated interval or breakdown-based maintenance cycles to a planned or preventative maintenance cycle.

The following diagram illustrates the business processes that effectively plan, inspect, record and act on information about various equipment’s, devices and assets within an organization in a timely manner. More detailed information about each of the technical objects can be found in SAP documentation.

Overview of SAP plant maintenace business processes

Example Business Process 1:

A lot of equipment readings are recorded in plant maintenance and customer service processes. In case of a potential disruptive event in an assembly or sub-component, a service notification can be triggered.

SAP PM measurement detection flow

Example Business Process 2:

Alternatively, a maintenance plan can be set up to trigger a maintenance order based on thresholds. Once the device at the edge detects an anomaly, an AWS Lambda function can be triggered to create a measurement document in SAP for the assembly or sub assembly. This would in turn trigger the creation of a maintenance order.

SAP PM measurement detection flow with AWS Integration

Architecture and Solution Overview

To keep it simple, we are using an IoT device simulator to mimic an equipment failure. Then, we show how to use AWS IoT services for early failure detection. For the integration back into SAP, we leverage REST-based OData (Open Data Protocol) services and AWS Lambda to create service notification for maintenance activities. SAP maintenance notification plays an important role in plant maintenance operations by proactively notifying an abnormal or exceptional situation. The solution consists of the following components:

Preventive Maintenance architecture for AWS IoT integration with SAP

    1. IoT Device Simulation environment: Use AWS Cloud9 or your own Integrated Development Environment (IDE) to simulate a compressor’s temperature reading to AWS IoT Core.
    2. Security and Connectivity: AWS Cloud Development Kit (CDK) deploys AWS IoT Core to register the IoT thing and generate X.509 certificate. The X.509 certificate is installed on your simulation environment to establish connectivity to AWS IoT core. The simulated data is then sent to AWS IoT Core using Message Queuing Telemetry Transport (MQTT) protocol. In addition, AWS IoT provides a registry that helps you manage IoT things. In this example, we have a compressor maintained in this registry.
    3. Message payload parsing:  AWS IoT action rules listen for specific MQTT payload from the simulator, formats the data and send the data to AWS IoT Analytics services.
    4. Monitor messages in real time with AWS IoT Analytics: AWS IoT Analytics channel receives the data from the AWS IoT Core.  AWS IoT Analytics validates that the data is within specific threshold. Here, we setup the set ID, source, and data retention period and routes the channel to appropriate pipelines.
    5. Configure AWS IoT Analytics pipeline activities:
      1. Process data:  Transform message attributes, filter entire messages. Here, you chain the activities together to process and prepare messages before storing them.
      2. Enrich data: Enrich the data from the IoT core before sending the data to the AWS IoT Analytics data store. An activity that adds data from the AWS IoT device registry to your message.
      3. Normalize data: Remove attributes from a message to normalize the IoT payload message to filter the required data at the root level.
      4. Transform data with AWS Lambda:  Call Lambda functions to transform and enhance the upstream message to get the product range from Amazon DynamoDB. Through this activity, AWS IoT Analytics can understand the standard temperature range for a given device by calling Amazon DynamoDB to determine if there is a temperature fluctuation in the data sent from the IoT simulator. In this example, this is the compressor.
      5. Retrieve SAP product data: DynamoDB setup includes the SAP attributes, which are mapped against the device name. Using these attributes, IoT Analytics retrieves the SAP product information for further downstream processing.
    6. Data Store: AWS IoT Analytics data store receives and stores your messages. Here, we configure a SQL query to select the most recent temperature reading over the period. Data sets are stored in Amazon Simple Storage Service (S3) and concurrently sent through to AWS IoT Events to capture the temperature status.
    7. Anomaly Detection: Using AWS IoT Events Detector model to define the conditional (Boolean) logic that evaluates the incoming inputs to detect an anomaly event (temperature out of normal range for more than 15 mins). When an event is detected, it changes the state and triggers additional actions to IoT events. For this demonstration, this model is configured to call the SAP to create an SAP service notification using AWS Lambda.
    8. API integration to SAP Lambda OData: This sample package contains a Lambda layer to connect with SAP and consume the OData services through REST API calls.  When an anomaly is detected, IoT Event detector model invoke an AWS Lambda function and passes the SAP equipment number and functional location to create a Service notification in SAP.
    9. Create Service Notification: HTTP POST request is initiated with the above payload to call the SAP OData service using the environment variables (Entity-Set Name, Service-name, SAP-host, SAP-port and SAP authentication). The HTTP POST response return the Service Notification number from the SAP system.
    10. Alert Message: Lambda receive a response with the SAP service notification number. This is parsed and sent to an AWS Simple Notification Service (SNS) Topic to alert the subscribers.

Solution Deployment

There are two key steps in the deployment process. The first part is to configure the SAP system and the second part is the AWS deployment. The detailed steps are shown below.

SAP Configuration

In the SAP backend system, create an OData service. There are two possible ways to achieve this.

  1. Activate the OData Service using SAP EAM_NTF_CREATE SAP OData service.
  2. Create an SAP OData service using a customized structure for the payload

For this deployment, we are using a customized structure and the high-level steps are shown below.

  1. Create a custom SAP ABAP structure using SAP Transaction SE11 for ZSERVICE_MESSAGE_IOT.                                                            SAP ABAP structure - ZSERVICE_MESSAGE_IOT
  2. Create a custom SAP ABAP structure using SAP Transaction SE11 for ZPM_SERVICE_NOTIF_STR.   SAP ABAP Structure ZPM_SERVICE_NOTIF_STR
  3. Create an SAP gateway service in SAP Transaction SEGW using the SAP ABAP structure created in the previous step.                          Create an Entity Type of Complex Type
  4. Redefine the method NOTIF_CREATESET_CREATE_ENTITY in the Service Implementation section.                                   Redefine NOTIF_CREATESET_CREATE_ENTITY
  5. Update the ABAP code to call the function module BAPI_ALM_NOTIF_CREATE, BAPI_ALM_NOTIF_SAVE and BAPI_TRANSACTION_COMMIT. This part of the code create a service notification when a HTTP POST request is triggered from SAP OData services.
    "Call the BAPI to create the Notification
            notif_type                      = 'M2'
            notifheader                     = lwa_notif_header
            notifheader_export              = lwa_notif_export
            longtexts                       = lt_longtext
            return                          = lt_return
    IF lwa_notif_export IS NOT INITIAL.
         "Call BAPI to save the Notification
                number                      = lwa_notif_export-notif_no
                notifheader                 = lwa_notif_export2
                return                      = lt_return
  6. Register the OData service in using SAP transaction /IWFND/MAINT_SERVICE
  7. Test the OData service in SAP transaction /IWFND/GW_CLIENT. An example payload is shown below.Example JSON for HTTP Request
  8. If the HTTP POST request is successful, the returned status code should be 201. An example screenshot is shown below.SAP Gateway HTTP Post Request

AWS Solution Deployment

AWS Cloud Development Kit (CDK) lets you define your cloud infrastructure as code in one of five supported programming languages. For AWS CDK installation steps, refer to the AWS CDK documentation.

  1. Clone the aws-iot-sap-condition-monitoring-demo repository
    git clone
  2. Create an SAP user for this demo and add the OData service to the menu of back-end PFCG roles. This should include the start authorizations for the OData service in the back-end system and the business authorizations for creating the service notification.
  3. Update the cdk.json. An example of the variables are shown below.
    Variable Description Example
    thing_name Name of the IoT device IoT_thing
    Type Name of the device type Compressor
    Equipment SAP Equipment number 299998888
    FunctLoc SAP Functional location SAPFunction
    temperature_min Minimum temperature 12
    temperature_max Maximum temperature 14
    sns_alert_email_topic Temperature alarm TemperatureAlarm
    alarm_emails Email address example@email.address
    odpEntitySetName ODP entity set name NOTIF_CREATESet
    odpEntityServiceName ODP service name ZPM_SERVICE_NOTIFICATION_SRV
    sapHostName SAP host name saponawshostname
    sapPort SAP port 8000
    sapUsername SAP user name, CDK stored this in  AWS Secrets Manager Johndoesap
    sapPassword SAP user password, CDK stored this in  AWS Secrets Manager Johdoepassword
  4. Follow the instruction in the readme section of repository to complete the setup and to run the simulator.
  5. Check the stack deployment in AWS CloudFormation. An example of successful deployment is shown below.screenshot of cloudformation stack deployed.

Simulate a malfunction of the compressor

Now that we’ve successfully deployment the solution, let’s run a test!

  1. The simulator uses the temperature_min and temperature_max variables to simulate temperature of the compressor. These are defined in cdk.json file as part of the CDK deployment. Refer to the script for the code for this simulator.
  2. These are stored as an entry in a DynamoDB Table. The minimum temperature (12) and maximum temperature (14) are shown in the DynamoDB table as shown below.Screenshot of DynamoDB table showing compressor maximum and minimum temperature
  3. In AWS IoT Analytics, select the DATA SET called cdksapbloganalyticsdataset, which was defined in the CDK stack. Then click Run now to view the actual temperate generated. An example is shown below.                                          screenshot of how to preview the result from AWS IoT analytics
  4. You can view the readings generated by the simulator in AWS IoT Events. Go to Detector models, choose CDKSAPBlogDetectorModel in detector models, then select tracker in the key value. An example of the temperature in degree is shown below. screenshot of readings generated by the simulator in AWS IoT Events
  5. To simulate an anomaly, modify the table temperature values in the DynamoDB table as shown in step 2. As an example, we have changed the maximum from 14 to 13 as shown below. screenshot of how to modify the table temperature values in the DynamoDB table
  6. Check The readings generated by the simulator in AWS IoT Events and this should now reflect the temperature range set in the DynamoDB.
  7. If the anomaly continues for more than 5 minutes, an alarm will be triggered to create a service notification in SAP. In addition, an Amazon Simple Notification Services (SNS) notification to the subscriber. An example of email notification is shown below.                                                              screenshot of AWS notification message
  8. Validate the service notification in SAP. Go to SAP Transaction IW23. Enter the SAP service maintenance notification generated. Click enter to verify the entries. Screenshot of the alert trigger in SAP system

Clean up

Don’t forget to clean up your AWS account to avoid ongoing charges for resources you created in this blog. Simply follow the instructions outlined in the cleanup section in the Github repository.


Machine failures cause adverse impact on manufacturing operational efficiency and the identification of such critical failures pose a challenge in a traditional manufacturing environment. In this blog post, we have shown an example of how to leverage AWS IoT Core, AWS IoT Analytics and SAP to identify equipment anomalies.

There are many more integration scenarios with SAP on AWS. For example, Amazon Lookout for Equipment can be used to quickly enable predictive maintenance. AWS also makes it easy for you to create your own Machine Learning (ML) models using Amazon SageMaker, such as Long Short-Term Memory (LSTM) neural network. If you have questions or would like to know about SAP on AWS innovations, please contact the SAP on AWS team or visit to learn more. Start building on AWS today and have fun!