Where Supporters of Pub/Sub Get It All Wrong…

Unless you’ve chosen to lock yourself down on your couch for the last year, you know that pub/sub is all the rage. You’ve heard that MQTT (most of it appropriate) and Industry 4.0 (a.k.a smart manufacturing and digitalization) are going to bring us peace, prosperity, and a chicken in every pot. I’m not going to entirely rain on the pub/sub parade, but many of the industry pundits are getting this wrong, sometimes by a little and sometimes by a lot.

I’ll admit it, there are many positive attributes of the publisher/subscriber architecture:

1. Clients are not connected to the data originators. They simply view the set of available data topics and subscribe to the data.
2. Data is only communicated when new data is available. Precious bandwidth is preserved (bandwidth is continually expanding and becoming less precious as it does).
3. A single server serves as the source of data for any and all who want it.
4. The architecture has been advanced to include data context and knowledge of when data originators are online and offline (MQTT Sparkplug™).

All these benefits are real and attractive to many of us building manufacturing Ethernet networks. Where the proponents of pub/sub get it all wrong is applying this new architecture too broadly. I read an article from earlier this year in Automation World, “What Pub/Sub means for Industrial Networks”, by Beth Stackpole that makes my point.

The benefits of the pub/sub architecture lend themselves very nicely to the Industrial Internet of Things (IIoT). That is an architecture with many possible clients accessing data possibly through a single router and/or switch where one port serves to connect the industrial side of the network to the applications on the Enterprise. I have no argument at all when Ms. Stackpole espouses the efficacy of pub/sub to IIOT.

However, she gets it completely wrong when she suggests that the pub/sub architecture portends the end of control network architectures like EtherNet/IP, PROFINET IO, and even Modbus TCP. She goes completely off the rails when she proposes that this architecture means the demise of the controller-device architecture currently used by the majority of manufacturers. In these architectures, the benefits of pub/sub are not only not apparent, they are insignificant if they are applicable at all.

Pub/sub isn’t applicable to manufacturing systems for a number of very good reasons:

1. In manufacturing control networks, there is no need for multiple subscribers to access devices in a control network. These networks are PLC-centric, and there should be only one cell controller and its I/O in each process control segment. The PLC control algorithm is the only device that needs access to the end devices.
2. All devices on the cell network must be integral to the control of the process or they shouldn’t be on the network. Data gathering devices should not be connected to the process control network. Gary Workman and I are making this very point in our forthcoming book, “Everyman’s Guide to the Design of EtherNet/IP Networks.”
3. In a control network, it is vital that a controller have continuous and immediate contact with all of its control devices. A pub/sub architecture does not provide that. In pub/sub, contact with the control devices is sporadic and, in many pub/sub architectures, the controller never knows if the end device is online or not.
4. In manufacturing networks, data context is integral to the operation of the network. Pub/sub networks often lack data context.

End devices that must provide data to other applications should do that by connecting to a second network (dual network connectivity in the device) where they can send IoT data in such a way that the control network is never disrupted.

In the exuberance over pub/sub, some in our industry have raced to promote it as THE answer to every problem. Like many other technologies, pub/sub has its advantages but it is far from a panacea for every problem on the factory floor.

Pub/sub is very worthwhile and useful in manufacturing, but it can’t and should never replace the dedicated I/O networks that manufacturers are using today.