A lot has changed in the past year in the Industrial Internet of Things (IIoT) space. Interestingly, advancements appear to be moving faster than ever. Instead of the hype abating, the excitement continues. Of note, there is a clear shift in language often used to describe the IIoT landscape. Many discussions now often revolve around a convergence of information technology (IT) and operational technology (OT). But it’s not just the messaging that has changed; product releases in the past year have been showcases for IIoT advances.
A great case in point is IoT gateways, which are now offered by several manufacturers. These devices act like any other gateway, in that they can be programmed to speak an automation language (e.g., Profinet) on one side and a higher-level language (e.g., OPC UA) on the other. The practical need for gateways are many and varied. Perhaps the engineer does not want to load the programmable logic controller (PLC) with any further responsibility. Or there might be information that simply is not germane to the PLC that is desired on the IT side. Gateways are helpful in such instances because they can bypass the PLC altogether (which is fascinating in its own right) to connect IT and OT networks.
Though gateway devices have long featured plenty of connectivity options on the OT side, all that was needed for IIoT application was something to connect to on the IT side. Enter the traditional IT companies: IBM, Amazon, SAP, Microsoft and so on. From the IT side, these companies are beginning to offer IIoT-specific solutions to tap into the industrial market. These solutions generally consist of analytics packages designed to ingest data and output business intelligence. In short: The OT side provides the data and the IT side analyzes the data. Great idea, but…
How do you know what to look for? It’s well known that the amount of data produced during a week of production in a factory can be huge. An analytics package cannot tell you what data is important and what data is irrelevant. With so much data to draw from, it’s often like searching for a needle in a haystack.
For example, in the grain processing industry, what metrics are tied to overall equipment effectiveness (OEE)? Only someone with expertise can discern the important data and separate the wheat from the chaff (pun intended). And, rest assured, such metrics will be significantly different from an engine assembly plant in the automotive sector where, again, domain expertise will provide the ability to filter on relevant data.
So if some domain expertise is required, combined with the competency to link into IT-side systems, what does that say for the average control engineer? It means multi-disciplinary engineers will become the norm. In addition to knowing how to program a PLC, they will also need to know how that PLC fits into the wider plant network.
A great example of this is seen with the move from serial fieldbuses to industrial Ethernet. From personal experience I can say that, nine times out of 10, when there is an issue with a Profibus network in the field, it’s because of installation errors.
Thankfully, Profinet is much easier to install, because it’s Ethernet. There is no need to worry about repeaters, segments, termination resistors, etc. However, because it’s Ethernet, it becomes part of the network infrastructure upon which Profinet traffic resides as well as other traffic, such as VoIP, HTTP, etc. Needless to say, additional complexities are introduced when this happens.
As a result, the control engineer must be familiar with networking an automation environment, but also networking in general. And as IIoT solutions become more prevalent, there will inevitably be more than one protocol sharing that network environment. This could be true even for small networks, where many Ethernet complexities would otherwise be inherently mitigated by the network’s small size.
In other words: As IT and OT converge, there is no longer such a thing as a small network.