Fieldbus solutions have been in place for decades in most industries, and there’s an incredible amount of knowledge built up around them. Everything from PROFIBUS to DeviceNet, from 4-20 loops to MODBUS RTU… engineers just graduating with their B.S. degrees were born after most of these automation systems were developed!
Migrating these solutions to PROFINET is a common challenge. Every automation system is specialized in some way, and specialized components may not speak PROFINET. To move data from the specialized systems up to the PROFINET network, you have to add an interpreter to the network using either a Proxy or a Gateway. The difference between the two is nuanced, but it can have a big impact on how your PROFINET automation system functions.
Gateways
The most basic way to move data across protocols is a gateway. Gateways are only designed to move I/O data between protocols, and may not expose “special features” of one protocol to another. For instance, a PROFINET Device | IO-Link Master gateway may map data from its slaves up to slots and subslots in the PROFINET device, but it won’t be able to provide diagnostic data about the connected slaves to the PROFINET controller.
A PROFINET Gateway doesn’t provide any context to the data sent to the PROFINET Controller
In addition, each gateway’s “data mapping” must be configured for each individual gateway and has to be saved in a vendor-specific format – since PROFINET doesn’t know what sits on the other side of a gateway, it can’t save or maintain this data mapping without those vendor-specific tools or formats. To make matters worse, there’s a loss of data going the other way, too. For instance, a Modbus TCP Slave | PROFINET controller gateway won’t pass all of the alarm data generated by the connected PROFINET devices up to the Modbus master.
Gateways are relatively easy to manufacture but carry an implementation cost when you have to deploy them in the field. Writing, using and maintaining that custom data mapping between protocols requires a significant investment.
Proxies
Proxies fill the same role as Gateways: they translate a foreign network protocol to PROFINET. The biggest difference between the two is that proxies use a standardized data mapping that’s been defined by PI. By using a standard data map, a proxy is able to make a nearly invisible transition between PROFINET and the foreign protocol, mapping not just I/O data, but also alarms, diagnostic information, and even network topology and health. There’s no question about how data is presented through a proxy. Each proxy will implement the full data map defined by PI.
A PROFINET Proxy provides context and full data mapping between PROFINET and the proxied protocol.
Proxies have been defined for a number of protocols, including:
Because the data mapping in a proxy relies on a standard, there are a number of protocols (like Modbus TCP, Ethernet/IP, etc) that don’t enjoy this native solution. For those protocols, application engineers have to rely on Gateway solutions to move data from PROFINET to other protocols.
Conclusion
Proxies are a comprehensive, targeted solution to connect PROFINET to other automation networks. Gateways are a catch-all solution that fills in the gaps between proxies. When you’re considering how to move bytes across network boundaries, check on the availability of a proxy before choosing a gateway. It’ll pay off in the long run.
Do you want to learn more about PROFINET?
The PROFI Interface Center has you covered with PROFINET Certified Network Engineer classes.
Our certification classes are intense, hands-on courses. You will learn how the underlying technology works from the application to the frame level. After passing both a practical and written exam, you become certified.
For more information, contact us or visit our website.