Representative End User Clients
Representative Automation Clients
Representative Software Clients
Industrial gateways are hard to love. Historically they have been treated as second class citizens both in the automation world and in IT (that is, when IT even knew that they existed!). Their traditional role has been to integrate industrial automation networks that use different protocols -- a hard thing to get excited about but a very important role given the polyglot nature of industrial communication.
But in the IIoT era, industrial gateways are taking on the new role of feeding real-time plant data to IIoT applications that usually reside in the cloud. ARC’s new market research study “Industrial Network Gateways” documents this transition and provides ARC’s forecast of how this role will grow over the next 5 years.
While some IIoT enthusiasts see these gateways as a necessary evil, I would argue that their role in the IIoT will exist for a very long time, at least in the manufacturing world. Let me explain.
The figure shows two sample automation systems served by a single IIoT gateway. The system on the left has the more common configuration. Note that the distributed sensor I/O (DIO) is not reachable from the gateway except via the controller. This is the way many factory systems exist today, and many end users like it that way because 1) they know that no other network traffic will interfere with the sensor I/O and 2) they can be clever and use a single network interface card (NIC) in the controller instead of two. The downside is that network monitoring and management of the I/O network is far more difficult and limited to the capabilities of the controller. Using protocols like SNMP and HTTP is often impossible.
The more modern and recommended configuration is the system on the right. Here the whole automation system can be reached via the network (and via the IIoT gateway). Many major end user manufacturers have transitioned to this configuration. In their opinion the greater network visibility and manageability is well worthwhile. This configuration represents the future trend.
In the old (left side) configuration the cloud-resident IIoT applications cannot reach down to the sensor I/O, but in the new configuration they can. However it’s a big Internet out there, and manufacturers do not want applications in the cloud interfering in any way with their production. So here the IIoT gateway serves as a proxy and a cache of manufacturing data. If every IIoT application in the world suddenly wants to look at a particular machine and its controller, the IIoT gateway prevents any load surge from reaching the automation system. It acts as a buffer sort of like load-balancing schemes do on high-volume internet servers. In addition, a gateway with substantial compute resources can serve in a “fog computing” role by sharing some of the cloud application’s compute work. As the IIoT grows, both of these roles will remain important and so will (in my opinion) the IIoT gateway.
But in the IIoT era, industrial gateways are taking on the new role of feeding real-time plant data to IIoT applications that usually reside in the cloud. ARC’s new market research study “Industrial Network Gateways” documents this transition and provides ARC’s forecast of how this role will grow over the next 5 years.
While some IIoT enthusiasts see these gateways as a necessary evil, I would argue that their role in the IIoT will exist for a very long time, at least in the manufacturing world. Let me explain.
The figure shows two sample automation systems served by a single IIoT gateway. The system on the left has the more common configuration. Note that the distributed sensor I/O (DIO) is not reachable from the gateway except via the controller. This is the way many factory systems exist today, and many end users like it that way because 1) they know that no other network traffic will interfere with the sensor I/O and 2) they can be clever and use a single network interface card (NIC) in the controller instead of two. The downside is that network monitoring and management of the I/O network is far more difficult and limited to the capabilities of the controller. Using protocols like SNMP and HTTP is often impossible.
The more modern and recommended configuration is the system on the right. Here the whole automation system can be reached via the network (and via the IIoT gateway). Many major end user manufacturers have transitioned to this configuration. In their opinion the greater network visibility and manageability is well worthwhile. This configuration represents the future trend.
In the old (left side) configuration the cloud-resident IIoT applications cannot reach down to the sensor I/O, but in the new configuration they can. However it’s a big Internet out there, and manufacturers do not want applications in the cloud interfering in any way with their production. So here the IIoT gateway serves as a proxy and a cache of manufacturing data. If every IIoT application in the world suddenly wants to look at a particular machine and its controller, the IIoT gateway prevents any load surge from reaching the automation system. It acts as a buffer sort of like load-balancing schemes do on high-volume internet servers. In addition, a gateway with substantial compute resources can serve in a “fog computing” role by sharing some of the cloud application’s compute work. As the IIoT grows, both of these roles will remain important and so will (in my opinion) the IIoT gateway.