"Why don’t you make Profinet routable?!?!”
We received this question from a student at a recent Profinet One-Day Training Class. I found it particularly prescient given the latest discussions going on around Industry 4.0. The question is technically sound and indicates a thorough understanding of the technology’s functionality—but perhaps not its purpose.
The answer, however, is much deeper, and accounts for what lies ahead in terms of industrial networking.
Layers, switches and speed
Devices on an Ethernet network can be addressed in one of two ways: a MAC address and/or an IP address. MAC addresses are associated with the data link layer (Layer 2) of the ISO/OSI Model and IP addresses are associated with the network layer (Layer 3).
A receiver’s MAC address or IP address is inserted into an Ethernet frame by the sender and is directed there as such. Assuming the sender and receiver are not connected directly to each other, the frame will pass through other nodes along its path.
If that frame passes through a node and is directed to its receiver based on the destination MAC address, the method is called switching. If that frame is directed to its receiver based on the destination IP address, the method is called routing. In other words, switches direct Ethernet traffic based on Layer 2; routers direct Ethernet traffic based on Layer 3.
All Profinet devices on a network are required to be in the same subnet and Profinet frames move around based on their MAC address. There is no need to encapsulate Profinet data in Layer 4 (TCP/UDP) and Layer 3 (IP) information. Layers 3 and 4 are skipped entirely and Profinet data is sent directly from Layer 2 to the application layer (Layer 7) and vice versa. This makes Profinet frames relatively small and therefore faster and more deterministic.
So, back to the original question at hand: Why not make Profinet routable so that it can traverse different subnets? First, the scope of the protocol is extended beyond its purpose when considered this way. Profinet is intended to be used for controlling an automation process. Since this is a local process, routing little bits and bytes of data across an enterprise or the Internet doesn’t make sense from a timing perspective. Individually, these sub-second little pieces of data are not particularly useful at higher levels without first being buffered and collated. Second, it should be noted that Profinet uses TCP/IP for certain non-time-critical data like diagnostics; this information would be routed as such.
The right tool for the right task
There are protocols available today for moving information to higher-level systems. For example, OPC UA is purpose-built for this task. There is no need to reinvent the wheel. Instead, use the right tool for the right task. For example, you wouldn’t attempt to use the File Transfer Protocol (FTP) to load a webpage. There is already a protocol purpose-built to transfer hypertext (HTTP).
The beauty is that so long as the protocols leverage standard unmodified Ethernet, they can coexist plainly on the same network. Again, use the right protocol for the right task—one for moving your high-speed control I/O data, another for moving your information across the enterprise.
Incidentally, ensuring Profinet traffic remains in its own subnet introduces a certain measure of cybersecurity. For example, a man-in-the-middle attack might employ spoofing the destination MAC address of Profinet frames. A malicious actor needs to be inside your network to perform such an attack. And if an attacker is already inside your network, then you’ve got bigger problems to worry about.
For more information, visit PI North America at us.profinet.com.
