IIoT Communications

Aug. 20, 2018
Though the cloud and Big Data analytics are important components of the Industrial Internet of Things, don’t forget to start with the necessary communications layer and work your way up from there.

I have had several discussions with various vendors, distributors and other integrators regarding Industrial Internet of Things (IIoT) solutions. I have read articles regarding whether or not IIoT is really coming. I am not sure if we’re all on the same page regarding what IIoT is and the communications demands therein.

If you believe we already have all the devices in our control systems, and IIoT is getting everything on Ethernet, and adding the cloud with Big Data analytics and dashboards, then you’re focusing on analytics. That’s fine, but that’s not IIoT. That’s advancing analytics that have been around for a while, which is a good place to be. But that is not necessarily IIoT.

The cloud and Big Data analytics are important components of IIoT solutions and smart manufacturing. So it is indeed an advancement to get there. However, you cannot solve an IIoT solution with software and the cloud alone any more than you can a control system. A control system needs control hardware with a control communications layer along with the equipment and devices we are controlling. Then software can contribute. Likewise, an IIoT solution is about the “things” first.

Look up the Purdue Reference Model (PRM) used in ISA-95, and look at Level 0 and Level 1. That’s where we start an IIoT solution just like a control system, even if we know we are also implementing Level 3 solutions and integrating top to bottom. I don’t think this idea is foreign to most reading this. However, there is a gap between the Level 0 and 1 control solution and the Level 0 and 1 IIoT solution. I have mentioned this before, but I want to bring a focus to it now.

As control system integrators, we typically consider that we have the device-level communications (PRM Levels 0 and 1) covered. If new devices come into the system, we solve any communications hurdle and bring it into our system. Not all IIoT solutions will come back to the control system, though. For instance, a safety application using a camera should be integrated with control. Calculating inventory levels that a batching system uses as source raw material will be integrated to some degree. Safety inspections might not be. Security might not be. Accountability solutions might not be.

Sensors might or might not be connected with control. If a sensor contributes to analytics but is not a tangible contribution to the control system, then it might just be clutter for the control system. If a sensor is remote, it might not make sense to add it to the control system. It might not make sense to connect drones to the control system. It might not make sense to tie trucks in the supply chain to the control system.

Communications with enterprise resource planning (ERP) systems, databases, cloud solutions, Big Data and other various software solutions are important. Communications with control systems and integrating with enterprise software is important. These are covered well. This does leave a gap, however. What about the Level 0 and 1 IIoT solutions that extend control solutions or add solutions not even related to control?

This gap between control systems and IIoT solutions is met by a gap in communications as well. We know how to get our systems on Ethernet, hardwired or via Wi-Fi. We know how to convert or bridge the gap to many different legacy plant floor networks and protocols of the past. What is new is thinking about things outside of that domain. We might have to think about communications such as cellular, redundant cellular, RF and low-power RF, NFC, LoRaWAN, BLE (Bluetooth low energy), ZigBee, Thread (IPv6), CAN bus, long-range Wi-Fi, specialized new IoT sensor modems, and more. This is a communications integration project by itself within an IIoT solution, and probably a proof-of-concept hurdle for many customers who are forward-thinking in this way already.

Furthermore, once you can reach out and touch a thing, you will need to be able to speak its language as well. That might or might not happen via a typical hardware module or OPC driver that control system integrators are used to.

If engaging IIoT, engage it at the tangible hardware level first. IIoT is a bit like a control solution, or a plant floor analytics solution except with more parts and pieces that could come in from a broader area and a larger context of business factors than operations. We have more things in more places to talk to over various networks that speak various hardware languages we are not necessarily used to. Solve problems for IIoT at ground level, going back to the days when communications were half of the battle. Then build up to the cloud from there where warranted.

Michael Bachelor is president at Bachelor Controls Inc., a certified member of the Control System Integrators Association (CSIA). For more information about Bachelor Controls, visit its profile on the Industrial Automation Exchange.

Sponsored Recommendations

Why Go Beyond Traditional HMI/SCADA

Traditional HMI/SCADAs are being reinvented with today's growing dependence on mobile technology. Discover how AVEVA is implementing this software into your everyday devices to...

4 Reasons to move to a subscription model for your HMI/SCADA

Software-as-a-service (SaaS) gives you the technical and financial ability to respond to the changing market and provides efficient control across your entire enterprise—not just...

Is your HMI stuck in the stone age?

What happens when you adopt modern HMI solutions? Learn more about the future of operations control with these six modern HMI must-haves to help you turbocharge operator efficiency...