Industrial IoT: How to Eat the IIot Elephant

Learn, through two useful examples, how to start simple and move to more complex Industrial IoT implementations.

Moving to Industrial IoT can be a challenge. Through working on many customer projects over a number of years at Crosser, we have learnt that a key success factor is to start with small projects that are quick and easy to implement before gradually building up to the more advanced and complex use cases. That is, always eat the elephant in pieces, don’t try to swallow it whole.

How to get There: From Here Data mismatch is a common problem in IoT. Therefore, data transformation and harmonisation play a major role. (source ©: Crosser Technologies)

In most cases it is possible to find small and simple projects that are good starting points requiring a low effort to implement while returning value quickly. With the right tools it is easy to start simple and then add more advanced features over time.

Simple Beginnings Here are some simple but useful projects, showing how they can be implemented with Crosser’s Edge Streaming Analytics. The Crosser system provides a large library of premade building blocks (modules) that implement common functionalities for these types of use cases. By using these modules, it is easy to get started by combining modules into applications using a graphical drag and drop editor. With the interactive debugging capabilities, each application can be verified before installing them for continuous operation on Crosser Nodes that have been installed near the systems with which they will interact.

The new generation integration platform: Allows you to integrate any device or machine data and any data source with smart workflows, events and triggers in real time. (source ©: Crosser Technologies)

Industrial IoT: System Availability

Monitoring system availability is a very common requirement. This kind of application can be created by starting with a time trigger that will fire the application once every minute, or whatever time period makes sense. A call is made to the system to be monitored, for example a programmable logic controller (PLC) or a representational state transfer (REST) endpoint. If the request fails, a notification is sent to someone using a text messaging service. Here a Modbus PLC is being polled every minute and, if no response is detected, text messages will be sent to the managers’ mobile phones using the Twilio messaging service. This is, of course, a very basic application but, if failures are not expected too often, it could still be useful. The same concept can be used with any system that accepts an external request. For example, if an HTTP endpoint has to be monitored, the Modbus module can easily be replaced with an HTTP request module.When the monitor is up and running, ways to improve it can be considered. One obvious problem is that a message will be triggered every minute if the PLC stays in an unresponsive state – which could be quite annoying. It’s easily fixed just by adding a Report By Exception module so that a message is sent only when the PLC initially becomes unresponsive.

Always eat the elephant in pieces - don't try to swallow it whole.

_{Göran Appelquist, CTO at Crosser}

If the PLC is a bit shaky, flipping back and forth between online and offline, the monitor may once again send more messages than necessary. Another easy fix is to add a Throttle module to make sure only one message is sent per hour (or whatever duration is suitable).

Finally, it might be desirable to get availability statistics captured over a long timespan. Here, the Time Counter module can be used to take the same input as before to provide a summary of the times spent in each state over a specified period. The results can be sent as an uptime report once per day. The project started with something really simple, but still useful, and then it was gradually improved to finally arrive at something that now has more functionality. The development team can decide how much further to take it and at what pace.

Integrity Checking

Data integrity is a broad concept with many possible applications, such as checking that values are within reasonable limits, counters are constantly incremented, or that data is updated at a certain rate.

The latter case will be used here, checking that sensor data is updated at the expected rate. For this example, a subscription must be set up against an open platform communications unified architecture (OPC-UA) server that will then push back changes in values and these results will be checked every second by using a Timeout module.

Timeout module has to be set to check there are no changes within periods of 70 seconds rather than 60 seconds, chosen to offer a margin for small deviations in update frequency. This module can monitor any number of sensors and, as soon as one of them fails to deliver data in time, it will indicate which sensor has failed. In this project, the application will make an HTTP request when a sensor fails, maybe calling on the enterprise resource planning (ERP) or manufacturing execution systems (MES) to trigger further actions.

Getting There: Build integration flows with the Flow Studio using a library of modules and connectors. Add data map-ping, data trans-formation, triggers and events to your flows with ease. (source ©: Crosser Technologies)

With this very simple flow, thousands of sensors can be monitored as long as they have the same expected data rate. If the sensors, or groups of sensors, have different data rates, multiple Timeout modules can be added with differing timeout settings using a filter on each to allow the relevant sensors to be selected: These two simple but realistic use cases are good starting points for introducing edge streaming analytics. It’s possible to find many alternative but equally simple examples within any organisation.

Guidelines

The examples given share some char-acteristics that can serve as general guidelines when trying to identify other projects that are good starting points for edge analytics:

• Find use cases that are add-ons to the existing operation, that is, ensure that neither the input nor the output systems rely on the operation of the business critical application to which they are attached.
• Find uses that add value when they work but won’t have a major negative impact if they don’t.
• For the first implementation, try to scale down the problem to an absolute minimum, while still adding value (minimum viable product). Then incrementally add features until the final goal has been reached.
• Build an application that solves the problem when everything works normally, known as a ‘happy path’ implementation. Then add additional logic later to cover situations where things don’t work as expected.

READ MORE ARTICLES