OPC UA and M.O.U.

opc-mouThe OPC Foundation is signing a number of Memorandums of Understanding (MOUs) with a number of trade associations, technology consortiums, and other organizations. An MOU is a simple agreement that the two organizations agree to work jointly to promote each other’s objectives. Among the organizations that have signed MOUs with the OPC Foundation are the ASHRAE, the Building Automation organization, MDIS, one of the Oil and Gas Industry trade associations, and, just recently, the CCLPA.

The CCLPA, which I thought was some sort of golf association, is the trade association that promotes CC-Link, a Japanese I/O protocol offering high speed communication and simplified deployment. CC-Link is supported primarily by Mitsubishi and is as popular in Japan as EtherNet/IP is in the US and ProfiNet IO is in Europe.

Many automation engineers and many members of these organizations don’t really understand the benefits of a partnership with the OPC Foundation and what it means technically. This article describes why these organizations are forming these links, and how it will benefit their industry and their members.

If you think about all these organizations, no matter what their purpose or industry, in today’s world an important aspect is moving data. Typically, it’s been between a controller (a Building Management System, BMS, for ASHRAE or a subsea controller for MDIS) and some end device. Now, of course, it’s important to be able to move this data to remote servers or the cloud.

These organizations have usually been in existence for many, many years before OPC and have long experience providing these types of solutions in their area of expertise. ASHRAE, for example, developed a BACnet for RS485, one for Ethernet, one for the IP protocol of Ethernet, and several others. As technology changed, they continuously worked on transports, encodings, and connectivity issues that were needed by their members. They did a great job, but those aspects of their business—transports, encodings, and connectivity—are really ancillary to their real job: defining data models and mechanisms to access data within buildings. The same is true of MDIS in the subsea oil and gas industry. And of the CCLPA in all sorts of Japanese industrial concerns. For every one of these trade organizations, moving the data they define is really ancillary to what they want to accomplish.

Over time, what these organizations have all come to realize is that networking technology continues to rapidly evolve, and every year it becomes more difficult to provide the best, most reliable, most secure mechanisms for their members to deploy in the field. As the technology gets more complicated, it gets increasingly complex and difficult for them to implement. These people understand heating and cooling, undersea drilling, or whatever their trade association’s technology is—not what security algorithms to use or what encoding is the most beneficial.

Instead of working in areas where they don’t have inherent expertise, they’ve realized that the OPC Foundation offers them a way to leverage the most current technology in a way that preserves what’s special and unique about their application domain. And since OPC UA is flexible and can evolve as new transports are developed, new security standards are implemented, and technology advances, they can future-proof themselves.

This all sounds great. But how does it work? There are actually two ways that an organization can leverage the OPC UA technology.

One way is to simply implement their data models using the Object Modeling capabilities of OPC UA Servers. MDIS could model a drill bit in OPC UA and a Client device could use the standard OPC functionality to access that data. The trade organization could simply build their data models on OPC UA and leverage all the OPC UA communication functionality and command structure to access their data.

Another way to leverage OPC UA is for a trade association to simply pass through its current protocol in the data packet of an OPC UA message. The BACnet organization could send its standard Read Attribute message as the data payload of an OPC UA message. All the encoding, security, and transports are leveraged while preserving the current BACnet protocol. This means that application developers who have an application that currently uses the BACnet protocol can simply implement OPC UA to provide the transports, and preserve their current application code to process the actual BACnet messages.

No matter how a trade organization chooses to leverage the OPC UA architecture, it provides them with many benefits. I expect to continue to see many more organizations choose to leverage the capabilities of OPC UA.

For more good information on OPC UA you may want to look at my book, “OPC UA – Unified Architecture: The Everyman’s Guide to the Most Important Information Technology in Industrial Automation”.