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, including higher performance, cost reduction, and improved field maintenance and deployment.
On this page:
Protocol Comparison: Native vs OPC
What are the benefits of supplying native protocols interfaces to PLCs, instead of just use OPC client and rely on external OPC server to get the date?
Some PLCs are using OPC UA as their native built-in protocol, certainly this question does apply to them, but to other equipments using proprietary protocols.
There are many scenarios when the native driver is more beneficial. Let us explore some of them:
Higher Performance
Instead of a direct connection, invariably adding one more application in the middle 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
thought the Native Drivers an additional set of functionality is available,. For instance, for ControlLogix and CodeSys, we can execute discovery methods that goes beyond what would be available using a third-party supplied OPC gateway to those devices.
Cost Reduction
Most of the native drivers are included at no charge. The exceptions when there is a cost, it is typically quite smaller than the OPC server cost.
The OPC server still needs to use the Native Protocol Addresses
One misleading argument to use OPC is to hide the PLC address from the configuration. The reason it is misleading is that you need to use the native PLC address to setup the configuration of the OPC server anyway; you just duplicated the work load.
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 Module device for the Edge application. In this case, the project connects with the field device with the native protocol, still enabling its OPC Server functionality, so other applications can use the built OPC Server in the FrameworX to access the data.
Easier Field Maintenance and Deployment
As explained on the previous item, if the OPC Server was not in its place, adding one more "middle-man" is just stressing the deployment and maintenance procedures.
Improved technical support
Two points for potential failure or misconfigurations, and two independent suppliers, typically do not compare with a single environment and centralized support.
In this section...