OPC DA Communications

A reader sent me this question a few weeks back: “I see that OPC DA seems like it is being dropped by just about everybody.  Why is that?”

That’s an interesting question, and the premise is very true. OPC DA is no longer the preferred mechanism for moving data from an industrial automation device into a Windows application.

OPC – what we now called OPC Classic – had a really good run. Starting in the 1990s when PCs first hit the manufacturing floor, it became the preferred way to get data out of a drive, a linear actuator or any other industrial device. Remember, this was before EtherNet/IP and PROFINET IO. It was even before DeviceNet and Profibus DP.

And most of all, it was before EtherNet/IP, Modbus TCP and PROFINET IO. In those days, PLCs connected to I/O points with physical wires. Everybody had those monstrous PLC5 racks with tons of analog and digital I/O cards. Sometimes, Remote I/O was used, and those cards were remote in another rack off on another part of the machine. There was Data Highway if an automation device vendor was a partner of Allen-Bradley, but not much more than that.

The only open way to move data was serial communications. Most devices had a UART (Universal Asynchronous Receiver/Transmitter) and could do some data transfer (you might remember DB25 and DB9 connectors). System integrators of the day wanted to write applications for PCs, and their only choice to get data was to write custom drivers to get that serial data. That was time-consuming and expensive – great for an SI that billed by the hour, but not so great for the manufacturer paying the bills.

The answer to this problem was OPC. A group of system integrators got together and came up with this idea to have a standard mechanism to interface with a driver. The communications protocol – the bits and bytes that actually moved over the wire – would be hidden from the application program. No matter what device or communications strings were transferred, the application program would receive the data in the same way.

The designers of what came to be called OPC chose Microsoft COM as the underlying mechanism for OPC. COM was something that every PC application could support. All of the Microsoft applications, like Excel, Word and PowerPoint, had the ability to integrate COM data. It was a really good solution to this problem.

But now, 20 years later with the advent of WIN 10, COM exists but it’s no longer explicitly supported. But COM is not the only weakness of OPC. In today’s world, we need to move data between all sorts of embedded devices, some with specialized operating systems and software, and enterprise/internet systems. OPC Classic was never designed for that:

• OPC Classic is dependent upon Microsoft – It’s built around COM and DCOM (Distributed COM), a technology that is, if not obsolete, certainly being de-emphasized by Microsoft.
• OPC Classic has no support for sophisticated data models – It lacks the ability to adequately represent the kinds of relationships, information, objects and interactions among systems that are important in today’s connected world.
• OPC Classic is vulnerable – Microsoft platforms that support COM and DCOM are vulnerable to sophisticated attacks from all sorts of viruses and malware.

And on top of that, most devices today talk Ethernet and advanced communication mechanisms like MQTT and OPC UA – devices don’t need a DA driver to be integrated into applications.

Yes, OPC DA is no longer in favor. But today, we have much better tools than we’ve ever had to move data and information around the factory floor.