IoT Integration in Digital Transformation

The popularity of the “Internet of Things” is increasing day by day since it is one of the most effective instruments of digital transformation in the industry, also followed by IoT integration. Undoubtedly, it is obvious that we need to use these solutions, but adding these instruments directly to our system is not as easy as it seems. Companies already have many data collection, analysis, and process tracking tools. It is quite challenging and impossible at some scales to abandon these systems in one day and switch to platforms and applications offered by new technologies.

During the digital transformation period, hybrid models and old and new systems need to work together to make the transition smooth and risk-free. Therefore, it is expected that IoT/SaaS solutions will be able to act together with these systems. At this point, the most important topic is “merging”, in other words, “ability of integration”.

Sure, there is no one-size-fits-all solution for all the scenarios. The technical skills of your business, the methods offered by the IoT/SaaS solutions you provide, and the integration options of the system you currently use are the determining factors of the transformation strategy.

How the integration will take place mostly depends on how the data communication is going to take place. In other words, the question is where does the data flow from and to where? In addition, where the data is processed is another determining factor.

While expressing the integrations, we will continue by saying “SCADA” to the data collection / visualization system you already have, and “SAP” to the process/resource management systems.

Master/Slave

Master/slave is a communication model for hardware devices in which one device has one-way control over one or more devices. This is usually used in the field of electronic hardware where one device acts as a controller while other devices are those that are controlled.

Let’s say you bought a temperature IoT sensor. The system you are currently using also allows device identification with Modbus/TCP protocol.

In this scenario, the integrated system is responsible for the management of the device. In other words, how often the measurement will be taken, where the measurement will be displayed/stored, all these tasks are the tasks of the system in which you integrate the sensor. At this point, the Master-Slave structure is one of the most frequently used integration methods. Of course, in order to make this integration, the integration method offered by the sensor and the methods of the SCADA system you use must match. It may be preferable if your concern is only data collection, monitoring, and basic alarm structures. On the other hand, IoT sensors that are getting smarter by the day require much more complex managerial skills. For example, it is unlikely that you will integrate wireless sensors into your system with this method.

Platform -> SAP (WebHook)

Let’s explain this scenario with an example:

You bought an IoT pressure sensor and there is a SaaS platform that comes with this device. You perform device management, configuration and measurement strategies through this software. Your expectation from the platform is to enable you to monitor the pressure values and to create a work order in your internal system by giving an alarm when it reaches a certain threshold value.

Several integration strategies can be implemented at this stage;

You can create an integration point in the SAP system to which alarm data can be forwarded. When the alarm occurs, the platform can send this request to the Web-Service (middleware) you have located and save it in the SAP database.

If you can perform the data analysis in your own system, you can also write a middleware software to integrate the sensor directly into your system, process the data there and interact with your SAP system accordingly. Presumably your service will interact with the sensors via MQTT/HTTP or any other protocol popular in the IoT world.

Scada -> Platform

In some cases, you want your system to interact with the platform.

For instance, you have positioned a vibration sensor on a press on the production line. You want the press to take a measurement on the time it hits. Since your existing system produces the “Press” command, you want to send this information to the sensor and enable it to take measurements.

If you have a Master-Slave application, it will be very easy to transmit this order, but it is important to remember that it will still be your responsibility to store, process and analyze the collected data. It should not be forgotten that the main reason for integration is to make your existing system smarter by supplying the workforce through external solutions.

On the other hand, you can forward this order using one of the integration points of the platform you are using. Most of the time this event is triggered by an HTTP Rest API endpoint. The platform can also initiate the measurement process by transmitting this request to the sensor. You can do this with a small HTTP Request that you add to your PLC system.

Thanks to message-based communication, it is possible to communicate two-way and asynchronously. You can think of it as a chat application. Both the output of the data from the SCADA system to the platform and the transmission of data from the platform to the sensor or to the SCADA system can be performed asynchronously. For this, it is useful to take a look at message-based communication.

In message-based applications, there is a message queue in the middle of the communication, this queue is managed by an external actor (broker). Parties wishing to communicate communicate with each other through this channel. In this way, they can communicate without knowing each other’s access points. Since the data will be stored in the queue, data integrity is also preserved.

Thanks to the message queues, making a two-way integration becomes very easy. The team integrated with the platform does not need to write a Web-Service or open a port to the internet.

Example:

As an example, you have positioned your IoT sensors on various electric motors. You want the sensors to take measurements only when you want them to. You will immediately provide the alarms and reports generated by the platform and display them in your own system.

You start the measurement processes on your own system. In addition, you are sending various data to the platform you are integrated with. For example, instantaneous rotation speed, oil information, machine model, last maintenance date. You send the measurement order and additional parameters to the queue via the integration leg, the platform receives the message in the queue and starts the measurement process, collects the data after the measurement via the sensor. It performs analysis and alarm checks using the additional parameters and measurement data you send. It puts the reports and notifications it produces in the queue. The integration service receives the message in the queue and performs the relevant actions in SCADA and SAP systems.

It is very critical that the instruments you will use in Industrial Digital Transformation are integratable. You do not want to choose a closed box system and undermine your digital transformation process by keeping it dependent on a brand or a system. Having a digital transformation team and IT staff will speed up these processes. If you do not have such departments, it is very important that you work with service providers who work with you in this process.

At Sensemore, we attach great importance to this issue. We try to keep almost all of our products integrated with external systems, and to support our customers’ processes by diversifying their integration options. Moreover, we do this with completely open source code. If you are wondering about the integration options Sensemore offers, you can take a look at Sensemore Documentation.

And you can contact us at any time.