Our 
is designed to help professionals that are new to the industrial automation space whether at the start of their careers, or moving into the operations technology (OT) world from an IT or other background.
One of the common challenges in Industrial Integration is communications between different brands or manufacturers’ control devices (PLC, DCS, Drives, RTUs, smart sensors). While most control devices have methods of communication, and some industry standards have helped, they don’t all communicate using the same methods or protocols, and even if they both have the same serial or Ethernet wiring the difference in communication protocols prevents them from passing information. It’s the same problem you have if someone calls you on the phone, but doesn’t speak the same language.
While, as humans, we may be able to overcome a difference in dialect, machine communication has to be precise and exact. Small differences in addressing or data formatting can be enough variation to create communications failure. So how do people overcome this challenge?
Hardware-to-Hardware Communication
The challenges of connecting together hardware from different manufacturers can be overcome in a number of different ways. In the past, hard wiring of I/O or internal coding of a common protocol were the only methods. As automation hardware evolved, special communication units called hardware gateways became available for different brands to allow more complex information to be passed without the specialization or time and energy required for hard wiring or internal coding.
One of the challenges with hardware gateways, though, is that not all brands are supported and you may need different modules for each different control system you need to connect with. The complexity and costs all go up if any redundant systems are involved.
Even in the case of module-to-module communications, any data conversion or mathematical manipulation will still need to be addressed at the controller level and require specific control knowledge.
Hardware-to-Software Communication
Hardware gateways try to address the communications issue completely at the control level but, in many cases, this challenge can be addressed through PC-to-Hardware communication as well. SCADAs and HMIs have long utilized methods to connect to different control systems and devices.
Since 1995, a vendor independent industry group, the OPC Foundation, has developed the OPC standards as a common communications method to help address these challenges.
The OPC standard was designed to provide a common method for communicating between software applications. The OPC Server software talks to the PLC or device over its native protocol and converts that message to standardized formats defined by the vendor-independent OPC specifications, which can then be read by any OPC client. Just think of an OPC Server like a software application that converts different device protocols into a common language that HMI/SCADA or any other client application that needs data can understand.
The OPC Unified Architecture (OPC UA) standards are an evolution of the first OPC standards offering methods for a standard communications interface to be embedded into control hardware as shown here. While some PLC brands have OPC UA interface modules for some of their hardware, it will take time for such units to be developed by more manufacturers, and legacy systems may or may not be considered at all. Even if OPC UA modules are available for a control system, there have to be available slots in the controller racks, the CPU’s have to support the newer hardware, and production downtime is likely required to install and implement the hardware.
Furthermore, the impact of the additional communications loading from client applications demanding data of the OPC UA module and in turn the controller CPU, must be considered. The controller’s primary role is to control the process, and communications demands must yield to those requirements. In applications with multiple client applications talking to a single controller with an embedded OPC UA server, this prioritization of control over communication will slow communications, which is why software based OPC UA servers that can service multiple clients while insuring traffic is not duplicated to the controller, continue to be used.
With the use of OPC Servers, whether embedded in a device or as standalone software, the number of brands and devices that can be interconnected includes the vast majority of hardware in the field, for almost every industry. You can learn more about OPC by downloading our 
.
Hardware-to-Hardware Communication, with a Twist
System integrators have long used OPC servers and HMIs to link tag data between systems by moving the data through their HMI or SCADA systems. They configure the HMI to read data from one device, perhaps displaying it on the screen also, and then write it down into the other device(s). This gives operators greater insight into the information being exchanged between systems when needed for process understanding and troubleshooting.
However, there can also be a downside to doing this type of tag or address linking at the HMI or SCADA system level. Large data transfers or high rate transfers between devices being handled by scripting can impact HMI or SCADA performance.
Conversely, frequent operator interaction can reduce the performance of the data transfers being handled in scripting since, after all, operator interaction is the application’s first priority. Tag linking in the HMI or SCADA may also require complex scripting or require the use of additional tags or items that could increase HMI or SCADA software license costs.
In tag linking cases that require under 1 second update rates, the additional latency introduced by linking tags in the SCADA/HMI means that hardwiring or 
may still be the only practical methods available. Sub-second tag linking in dedicated software is very possible, depending on how responsive the controller and its communications links are. The faster you need your tag transfers to occur, the more we recommend you 
to help you evaluate the variables in your scenario and determine the best solution.
Software-to-Software Communication
Specialized linking or “bridging” software has been developed as a method to handle this data exchange between control systems but handling the transfer at a lower level, closer to the devices that need to share information.
These 
provide the advantage of isolating the data transfer process from the HMI/SCADA system but still allowing access and control of the data when needed in the HMI/SCADA for display and interaction.
Depending on the features of the particular software chosen, it can provide additional security against unintended process variable changes, by limiting the transferring data in a single direction between OPC Servers. Handling the data transfer with dedicated software allows it to handle data type conversions or mathematical functions during the data transfer – without any interaction from or additional load placed on an HMI or SCADA package.
Higher update rates than are normally required for human machine interaction can be taken care of by this specialized software in the background rather than in your HMI/SCADA. Although the above drawing shows the bridging application running on a separate computer, that is not always required. Depending on your HMI/SCADA hardware and application requirements, you may be able to run both applications on the same computer and still gain the benefits discussed here. This allows the operator interface to perform better because it isn’t using processing power to run complex scripting.
As integration requirements have become more complex, so has this specialized software and you can now find products with the ability to move data not only between OPC Servers but between OPC Clients, as well, and linking data between Databases and text files and 
can easily be achieved.
Most of these product are easy to use, and require minimal training and no certifications. The long term costs of products which can be modified through configuration by anyone with the appropriate security has significate advantages over other methods.
There are a lot of moving parts in software-to-hardware connectivity integration. Those new to the field or who haven’t experienced the details may think that communications is black magic. The truth is that device communication is very logical once you get into the details. Since 1996 we have been immersed in these details, helping distributors, users, integrators, and OEMs with device and information integration products and consulting.
If you’re interested in learning more about communications, enter your email address below for access to over 20 additional useful resources including the following:
- Beginners Guide to What is OPC?
- Whitepaper: Four reasons to use tunneling for OPC data integration
- Introduction to OPC UA Seminar
- Secure OPC UA connectivity
- Connecting barcode scanners to HMI/SCADA
- Specific Industry-Focused Communications Options
- Much More
