Overview
Native protocols and OPC communication are two methods for enabling device communication in industrial automation systems. This page explores the benefits of using native protocol interfaces with PLCs, which include higher performance, cost reduction, and improved field maintenance and deployment.
On this page:
Comparison: Native Protocols vs OPC ThirdParty Tools
What are the benefits of supplying native protocol interfaces to PLCs instead of just using an OPC client and relying on an external OPC server to get the data?
Some PLCs use OPC UA as their native built-in protocol; certainly, this question applies to them as well as to other equipment using proprietary protocols.
There are many scenarios where the native driver is more beneficial. Let us explore some of them:
Higher Performance
Adding one more application in the middle, instead of having a direct connection, will cause additional lag time. Further, the AccessTypes and the ability of parallel execution (multi-threading) available in the Device Module allows optimized configuration not available in most OPC servers.
Extended Functionality
By connecting through the Native Drivers, an additional set of functionalities will be available. For instance, for ControlLogix and CodeSys, we can execute discovery methods that go beyond what would be available using a third-party supplied OPC gateway for those devices.
Cost Reduction
Most of the native drivers are included at no charge. When there is a cost, it is typically much smaller than the cost of the OPC server.
The OPC server still needs to use the Native Protocol Addresses
One misleading argument for using OPC is that it hides the PLC address from the configuration. The reason this is misleading is that you need to use the native PLC address to set up the configuration of the OPC server anyway; you are just duplicating the workload.
The exception here is if the OPC server is already installed and serving multiple applications. In this case, the connection using the OPC client to the centralized OPC server is recommended.
Another good option is to leverage the OPC server included in the device module for the Edge application. In this case, the project connects to the field device using the native protocol while still enabling its OPC server functionality, allowing other applications to use the built-in OPC server in the platform to access the data.
Easier Field Maintenance and Deployment
As explained in the previous item, if the OPC server is not in place, adding one more "middle-man" only complicates the deployment and maintenance procedures.
Improved technical support
Two points for potential failure or misconfigurations, along with two independent suppliers, typically do not compare with a single environment and centralized support.
In this section...