This blog describes how a small team built an application for monitoring cooking kettles in SAP. We used cooking kettles at SAP as the example devices to be monitored and to help SAP facilities with the maintenance of these kettles. You can see 5 of them in the above picture.
It features the use of IoT Services 4.0, its Edge Gateway for OPC-UA, Use of Unix-based Gateways, IoT Application Enablement, IoT Hardware from Siemens, a Web-based UI and a batch application checking for threshold violations deployed to cloud foundry.
This sample application is meant to make it simpler for you to build your own IoT application. It walks you through all of the steps and provides you with all project documentation, configuration and source code required for you to be able to reproduce the application 1:1. We used the below phases to define the milestones for such an implementation project and todays blog will address what happened in Phase 0.
- Project Phase 0 - Preparation - we made sure we have all the systems and resources required to get going
- Project Phase 1 - Rapid Prototyping - build and learn from lab prototype
- Project Phase 2 - Deployment - deploy prototype "in the wild" and learn from it
- Project Phase 3 - Application Development - build app and test it with end users
- Project Phase 9 - Operations Development - develop whats necessary to scale and go live
You can always refer to the source code at
https://github.com/SAP/iot-reference-app-opc-ua.
Project Phase 0 - Preparation
In this initial phase we made sure we have all the systems and resources that we need to understand and complete the project.
Establish First Use Case and Scope
The trigger for the whole project was when we talked to the head of SAP Facilities and he told us, that the biggest machines, in regards of power consumption, are the cooking kettle. He would think, that if we could monitor the current consumed by them we could detect quite a few things and come up with useful use cases.
The first use case he mentioned was, that inside of the kettle there are more then 10 heating elements, each connected to one of the 3 phases of the 400V alternating current. If one of them breaks the current consumed on this phase would go down. If more then 2 break then cooking is slowed down and it should be repaired, but it often goes unnoticed for some time.
We documented the use case here:
use case diagram in ppt
Finding the right Hardware
For kettles we needed to monitor current. The kettles themselves did not have any sensor output and connecting to them in the kitchen was not easy as everything in the installation wall had to be IP68 water proof. So we had to do a retrofit solution adding sensors in the switch cabinet.
We found current sensors that are non-invasive and clip around each wire of the 3 phases. We had to connect them to a controller of some kind that would read the measurement and serve it to our device management. We found a solution with the
Siemens IOT2040 and the
Open Energy Monitor Shields that would allow us to take the shield and plug it to a siemens 2040 controller.
We had to solder the components onto our board but this was a one-time, simple, manual task. The other option would have been current sensors that wirelessly transmit the value to a local gateway. panoramic.io offers such a solution - but it's a closed solution. It would not have allowed us to do local control loops with an opc-ua server and add other sensors later.
The image below shows the hardware shortly before beeing assembled on our desk. One of the current sensors is in blue, then you see the arduino shield to put into the Siemens controller and the Siemens controller itself (already opened up to make assembly possible). The shield sticks out on the left side from the controller and a hole has to be cut into the (plastic) case for this purpose. When it's mounted in the switching cabinet to the left there has to be free space.
In the switching cabinet we used an off-the-shelve power supply instead of the laptop power supply shown in the picture.
For most of the Hardware we bought 2 devices instead of only 1 in the prototyping phase. This is recommended for multiple reasons:
- you always have a backup if a device fails
- you can use one device on your desk to simulate and one in "production" in the real live context to compare and debug any issues that may arise
As with any IoT use case "bugs" can occur anywhere in the mechanics (e.g. sensor plug not all the way in), sensors (e.g. sensor sensitivity to low), electronics (e.g. power supply inefficient) and software (e.g. own coding or configuration of third party software) and worse in the combination of all of the above with each other.
Establishing the Architecture
Based on the architecture explorer from SAP and what we brought to the table we came up with the following (planned) architecture.
Obtaining a Full Landscape ready for use by End Users
We acquired all of the needed systems from within SAP following an internal process flow.
For a partner or a customer, it will be different.
You need the following to get started:
- A cloud foundry global and sub-account
- An instance of SAP Cloud Platform IoT (Service) for cloud foundry
- An identity tenant from SAP Cloud identity (you might want o re-use your existing one used in your company and for other projects)
- A subscription to SAP IoT Application Enablement in your cloud foundry sub-account
- You need trust setup between your identity tenant and the cf sub account
- To use the web ide you also need a neo global account and a sub-account
- You need to do Trust setup three ways between the cf and neo sub-account and the identity tenant
- You need to create destinations to make the link between neo and cf work (more details on this here: https://help.sap.com/viewer/86ce311577794701bae493bddd753aa3/latest/en-US/8d4601a525d94ab7baa603e26b...)
For the first 4 steps getting a license from your SAP account team (can also be a test license) or if you are a partner subscribing to the iot add-on package of cloud platform will trigger that SAP does the setup of these systems for you. In the meantime the iot express edition at http://sapstore.com comes with all needed components and can be purchased with a credit card.
Network Setup
The device will be connected to the Internet only and not to the SAP corporate network. Connecting to the corporate network is not necessary and as there might be many IoT Devices, its also safer to have them not in the intranet.
The devices are still protected from the internet by residing inside a network segment, that is not reachable from outside. Only the device can initiate a connection to the Internet but not vice versa.
We have the following devices:
- multiple siemens devices that measures the sensor values
- one raspberry pi server running the opc ua server and the iot service edge gateway
We initially tried to run all 3 components on the siemens iot 2040 device for keeping it simple. Unfortunately the siemens device did not have enough processing power for the iot edge component. So that's when we moved to a separate device for it.
As many different servers and system were used we created one central list of all links in the landscape at landscape links file.
In our case we felt its important to have remote access to the devices in production. Please refer to the last chapter here to learn more about how we achieved this: https://github.com/SAP/iot-reference-app-opc-ua/tree/master/Docs/0-5-NetworkingLandscapeSetup.
Onboarding the Team into the Systems
As the last step we needed to bring everyone from the team (and everyone joining later) into the systems involved. To achieve this we made every developer a member in the global account, cloud foundry sub-account, cloud foundry space, web ide and into iot application enablement. The details are described here: https://github.com/SAP/iot-reference-app-opc-ua/tree/master/Docs/0-6-DeveloperOnboarding.
Phase 0 - Results
All of the above steps took a few weeks of time but not that much effort. With all the Hardware, Software, Architecture and Team available we could start with Phase 1 - the first lab prototype. To get through this phase we put ourselves into a workshop room. This will be covered in the next blog in this series.
Feedback to this blog and the source code is very welcome. For more detailed questions please check out
https://answers.sap.com/tags/73555000100800000136.
