Start Small - Go Big - Eat Elephants in pieces

5 Ants Are More Than 4 Elephants*. But, Elephants need to be eaten in pieces, especially in Industrial IoT.

Learn from two useful examples on how to start simple and move to more complex implementations of Industry 4.0 use cases.

Implementing industrial IoT use cases can be a challenge. By working with many customer projects over the last years we have learnt that a key success factor is to start with small projects that are easy to implement and finish and then gradually build up to the more advanced/complex use cases. That is, eat the elephant in pieces, don’t try to swallow the whole elephant at once.

In most cases it is possible to find small and simple use cases that are good starting points, both by quickly returning value and requiring a low effort to implement. With the right tools it is easy to start simple and then add more advanced features over time. In this article we will introduce some examples of such use cases and also some guidelines to help you identify these use cases within your organization.

*) “5 ants are more than 4 elephants” is a TV series for children that was produced in the mid-70’s in Sweden. It had an educational intent by introducing a letter and a number in each episode, but was done in a very playful way with a combination of live actors, animations and songs. It became hugely popular and has been re-broadcasted many times. In 2006 it was voted as the best children’s program ever produced in Sweden and everyone above the age of 20 knows the program.

Example use cases

Here we will introduce some simple, but still useful, use cases and show how they can be implemented with Crosser’s Edge Streaming Analytics system. The Crosser system provides a large library of pre-made building blocks (modules) that implements common functionalities for these types of use cases. 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 you quickly verify your application before installing it for continuous operation on Crosser Nodes that you have installed near the systems you want to interact with.

#1 - Monitor system availability

Monitoring system availability is a very common use case. We can build this kind of use case by starting with a time trigger that will trigger our application once per minute, or whatever makes sense. We then make a call to the system we want to monitor, e.g. a PLC or a REST endpoint. If the request fails we send a notification to someone using a text messaging service. Let’s see what it looks like:

Here we are polling a Modbus PLC every minute and if we don’t get a response we will send a text message to mobile phones using the Twilio messaging service. This is of course a very basic application but if you don’t expect failures too often it could still be useful. The same concept can be used with any system that accepts an external request. For example, if we want to monitor a HTTP endpoint we just replace the Modbus module with a HTTP Request module.

When you’ve got this up and running you can start to think about ways to improve this application. One obvious problem is that we will get a message every minute if the PLC stays in an unresponsive state, which will be quite annoying. That’s easy to fix, just add a Report By Exception module so that we only get a message when the PLC changes from being responsive to being non-responsive.

If the PLC is a bit shaky, flipping back and forth between online/offline states we might still get more messages than we want. Another easy fix, we add a Throttle module to make sure we don’t get more than one message per hour (or whatever suits you).

Finally, we might want to get some statistics on the availability measured over a longer time period. For that we use the Time Counter module that will use the same input as above but provide us with a summary of the times spent in each state over some time window we specify. We can then get an uptime report once per day.

After adding these incremental improvements we end up with the following:

We started with something really simple, but still useful, and then gradually improved our application to finally arrive at something which is still pretty simple but now with much more functionality. You decide how far you want to take it and at what pace.

#2 - Data integrity

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

Here we will use the latter use case, checking that our sensor data is updated at the expected rate. For this example we will set up a subscription against an OPC UA server that will then push changes in values to us and we will check that the data changes every second by using a Timeout module.

We will set up the Timeout module to tell us if there are no changes within 70 seconds, to have some 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 tell us which sensor that fails. This time we will make a HTTP request when a sensor fails, maybe calling our ERP or MES system to trigger further actions.

With this very simple flow we can monitor thousands of sensors, as long as they have the same expected data rate. If we have different data rates for different groups of sensors we can just add multiple Timeout modules with different timeout settings and a filter on each to select the relevant sensors:

We have now seen a couple of simple but realistic use cases that are good starting points for introducing edge streaming analytics. You can most likely find many equally simple examples within your organisation. To help you with this journey, let’s finish with some general guidelines.

Guidelines

The examples above share some characteristics that can serve as general guidelines when trying to identify use cases that are good starting points for edge analytics:

• Find use cases that are add-ons to the existing operation, i.e. neither the input or output systems rely on the operation of your application.
• Find use cases that add value when they work but don’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. Then incrementally add features until the final goal has been met.
• Start with a “happy-path” implementation, i.e. build an application that solves the problem when everything works as expected. Then later on add additional logic to cover the situations when things don’t work as expected.