There was a recent blog post over at Schneider called “It’s all about choice: EtherNet/IP and unicast and multicast traffic.”
You can follow the link to read the whole thing but the gist of it is: “PROFINET people think EtherNet/IP cannot unicast, but it can do both multicast and unicast. PROFINET can only unicast. So choose EtherNet/IP to get a choice.” So rather than leaving you casting about for definitions, here’s a video explanation of unicast and multicast:
EtherNet/IP began as a multicast-only protocol and at some point added unicasting. PROFINET IO spec version 1.0 specified both unicasting and multicasting. So I think the correct conclusion should be: “EtherNet/IP can do unicast but most devices support only multicast. PROFINET can do multicast, but most devices support only unicast.”
Now there are many other great reasons to choose PROFINET over EtherNet/IP, but let’s explore the casting difference and the Schneider blog post.
PROFINET is designed to use unicast transmissions because the frames are small and the protocol encoding doesn’t impose significant overhead on the IO data. Furthermore, unicast is by definition the best way to communicate between two endpoints. In contrast, multicast is the logical way for one point to communicate with many others. But that’s not what you really want to do when you only need to transfer cyclic data between two endpoints. So while PROFINET can support multicast IO and does give the system architect a choice to use it, most vendors don’t implement Multicast IO because it’s almost totally useless for day-to-day cyclic I/O tasks.
But let’s talk specifics here. The author of the Schneider blog post brings in a straw man to pose the argument against unicasting, “Multicast traffic over EtherNet/IP delivers benefits that reduce network traffic load as it facilitates the sending of information common to multiple but independent devices in one communication, thus reducing bandwidth.”
I see two problems with this sentence:
1) What information needs to be sent to multiple but independent devices with every IO cycle? Maybe it’s my PROFINET-centric view of the automation universe, but I just don’t see that use case in the field.
2) “Thus reducing bandwidth.” You have 100Mpbs of bandwidth available to you, and you’re going to sweat the difference between sending a single 128 byte frame vs… what, three of them? If the system integrator or end customer doesn’t install a switch with IGMP snooping enabled by default, a multicast transmission would send a single 128 byte frame to, say, thirty end nodes on the same switching domain! How does that reduce bandwidth utilization?
I also disagree with the claim that production networks need to utilize the finest (and most expensive) network topologies and traffic management features. A plant-level network will certainly have flood control mechanisms built-in (like Ethernet switches with IGMP snooping), but at the machine level, you can use a simple switch. Why spend the extra money per switch on a machine network to get a feature that you shouldn’t need in the first place? (Now there are lots of good reasons to use more expensive managed switches, but not always. See PROFINET on a Big Project or Small – What’s the Difference?) And as for “protecting from cybersecurity threats by pruning IO data traffic?” PROFINET does that by design – no IP encoding means our IO frames stay where they should be (with the exception of the rarely-used UDP Real Time channel). And you wouldn’t need some of that cybersecurity protection if you weren’t multicasting your IO data to everyone and their cousin!
Finally, why use multicast communication for IO in the first place? Now sometimes it might make sense to multicast to controllers. One use case would be when you have several motion controllers that need to share data. PROFINET can do that, but using it for IO is not common. Because there is seldom a need to send the same IO data to multiple IO modules.
So yes, both protocols give you choice as to whether or not to use multicast communication. But there is really little reason to use multicasting if you have the option to unicast.
–Carl Henning (with contributions from the PROFI Interface Center)
More on PROFINET: