5 Reasons Why Not To Use Data From PLCs For Your IIoT Project
Projects in the Industrial Internet of Things (IIoT) require a lot of data from the shop floor (OT). This data is usually processed in a cloud or edge gateway to gain further insights and optimize different processes. Nowadays, most IIoT projects are driven more from the software / IT side. For them, understanding shop floor technology is quite hard since it’s not very accessible.
If you found yourself in this position and have already spent some time researching how a typical production floor is organized, I bet you quickly found the Automation Pyramid. This model describes the different levels of automation in a factory and is a great starting point. On the bottom level, which is called field level, you’ll find sensors, actuators, and some other devices. This field-level equipment then connects to either a PLC directly or to IO-modules which then talk to a PLC via a Fieldbus. The PLC is the brain which then controls the machine. So you already have a central point where all sensors connect to. This sounds like a great source to retrieve data for your IIoT project, right? Like many other things in life, this, unfortunately, sounds too good to be true. Here are five reasons which you shouldn’t try to get data for your IIoT project from a PLC.
Wait, what about OPC-UA?
OPC-UA is an amazing standard to retrieve data including the semantic information from industrial equipment. If your PLC already has an OPC-UA server and the necessary data is mapped to it, congratulations and welcome to the fantastic blue ocean! Here is how to send OPC-UA data to the cloud. I know that you keep seeing OPC-UA on PowerPoint slides, but the reality looks different. Barely any PLC which you’ll find out there supports OPC-UA and even if it does, you still need to map data to OPC-UA variables using horribly complex Windows software which looks like it was built in the 90s (see Reason #3).
5 Reasons not to touch the PLC
#1 It’s high risk
PLCs are there to control machines or processes. Every change to them can lead to a malfunction. This is what the OT staff usually refers to when they talk about ‘failsafe’ and you should take it seriously. A malfunction can not only lead to an interruption of the production process which not only costs a lot of money but can also cost lives. Think of a huge press that suddenly starts while a worker is loading material.
PLCs play a highly critical role within a factory and thus should not be touched unless there’s a problem with its operation. Most companies understand this and would never allow installing anything that could interfere with those PLCs. Furthermore, the job of the OT staff is to keep the factory running. Since they are the only ones capable of modifying the PLC, exposing data for IoT projects doesn’t do anything for them. On the contrary!
#2 Lack of resources
Even if you’re willing to take the risks described in #1, the actual work needs to be done by an expert. In the best case, the changes are made by the person who originally programmed the PLC. Unfortunately, most of the time this was 20 years ago and the person has retired or left the company by now. Other experts are usually hard to find, don’t understand the idea behind IIoT, and make projects super expensive. Moreover, you might need several of those experts because there are so many different PLCs out there. Even if we’re just talking about one factory, you’ll already find PLCs from multiple vendors or at least from different generations.
#3 It’s super hard to realize (technically)
If you ever tried to program a PLC in the past, you know how data is actually handled there. It’s literally bits which sit in registers. So, if you want to have a temperature value you need to specify the register where it is stored. The register could look something like this: DB2, S7.10. Now, this would be a string of length 10 starting at byte 7 of DB 2 of a Siemens S7 PLC. Unfortunately, that alone doesn’t get you very far. Next, you need to take this Hex value and divide it by a constant like 3.4, which you get out of the sensor datasheet. Did I mention that this all happens based on proprietary and poorly documented protocols?
Of course, there are solutions like Kepware from PTC on the market which solve the protocol issue, but you’re still dealing with registers full of unstructured data that you need to put into context and fill with semantics. If you thought you could just install some software that instantly sucks data out of all PLCs in the network and provides them to a cloud in a well-structured way including the necessary semantics… I’m sorry! It’s a complex and painful work that needs to be done one by one for each PLC and sensor by highly qualified experts. This is expensive and doesn’t scale at all.
#4 Not all data is available
Do you still want to access all the valuable data from PLCs? In a lot of cases, the data might not even be valuable at all! The reason is that a lot of sensors are configured with “switching points”. PLCs are there to control the machine but have never been build to collect data. For example, a level sensor often doesn’t send the actual level in cm but instead sends a 1 or 0. That’s because the maximum level of a tank (let’s say before a pump would stop) is configured in the sensor itself. So the PLC just knows that the level is either “ok” or “critical”, which is enough to control the process. For IIoT projects, on the other hand, you usually need the raw data to do things like condition monitoring or predictive maintenance. So keep in mind, even if you access a PLC you might just find meaningless data.
#5 Cybersecurity
Still not convinced? Let me ask you one last question: What do you think happens when someone gets unauthorized access to a production network full of PLCs and other devices which received their last security update 18 years ago? Most of these devices are not even secured and can be configured over the network without requiring any credentials. Of course, edge gateways separate the production network from the internet, but they need to be extremely well maintained, and even then, there is no 100% guarantee. So if your edge gateway is not able to be remotely updated and tied to a subscription or maintenance contract, better think twice about connecting it to your production network.
Alternative: Retrofitting
Given the above-highlighted reasons, we believe that it’s faster, easier, and more cost-efficient as well as secure for most IIoT projects to choose a retrofitting approach. This either can be done by installing additional sensors to the machine which are exclusively for the IIoT project or by splitting the sensor signal using a Y-path before it reaches a PLC.
Secondary Sensors
The idea behind secondary sensors is pretty easy. You buy new sensors for everything you need to measure in your IIoT project and install them on the respective machine. These sensors are then connected to the CloudRail.Box which easily sends well structured and high-quality data to the cloud. The sensors, as well as the network, is completely separated from the production network, which means you won’t run into any of the above-mentioned issues. The cost to buy and install additional sensors is usually significantly lower compared to project fees related to PLC access.
Y-Path
In some cases, it might be possible to use the same sensor for the PLC as well as your IIoT project. This works using a Y-Path which splits the sensor signal in one to the PLC and another to the CloudRail.Box. Using this method you won’t need additional sensors but it’s more invasive compared to secondary sensors because you need to interrupt the sensor to PLC connection once to install the Y-path adapter. The good news is, from an IT perspective, it’s still a separate network and you don’t need to touch the PLC at all.
Title Image:
Ulli1105, S7300, CC BY-SA 2.5
