Practical thoughts on industrial OPC

Care to share? ...Share on Google+Share on FacebookShare on LinkedInPin on PinterestShare on Reddit

Industrial OPC is a vital, yet relatively small component in a SCADA system. This is because OPC is typically responsible for the software communication aspect between a piece of industrial software, and a monitoring or control device (sensors, PLCs..etc). It may not be as complex as analysis algorithms embedded in data historians , or as fancy as visuals reflected on HMI screens. However, Inspite of this, industrial OPC can never be ignored. OPC is the equivalent of those resilient nails that make a fancy piece of furniture come together.

What is OPC ?

OPC is popular because it is an open standard that any certified vendor can implement in their software solution. Industrial OPC is best described as a shared “language” between a software solution and industrial device drivers. OPC is not the only way for software to communicate in SCADA systems, however it is quite popular because it affords not being locked to a single vendor.

The cornerstone of any OPC architecture consists of two main software components: An OPC client, and an OPC server. An OPC server is a piece of software that can speak OPC from one side, and a different protocol from the other side. The OPC side of an OPC server can then communicate with any OPC client that supports the same OPC flavor.

OPC software architecture

For example, an OPC server for Modbus will be able to communicate with OPC clients from one side, convert the OPC requests to Modbus requests, then send Modbus requests to field devices on the other side. This effectively allows OPC clients to communicate with Modbus devices via OPC servers without ever speaking Modbus directly. See the figure below:

PLC image courtesy of Elmschat and wikimedia (https://commons.wikimedia.org/wiki/File:BMA_Automation_Allen_Bradley_PLC_3.JPG)
OPC with Modbus

OPC clients typically exist as part of HMI packages, process historian components , or any software solution expected to have the ability to communicate with as much industrial protocols as possible.

The OPC architecture is expandable, meaning that multiple clients should be able to connect to a single OPC servers. This allows multiple independent pieces of software to communicate with an industrial devices.

Multiple OPC clients with OPC server

Flavors of industrial OPC

There are currently two main flavors of OPC: Classical OPC which is the original OPC, and OPC UA which is the new generation OPC. The OPC as a standard is managed by the OPC foundation.

Classic OPC

Classic OPC is the original form of OPC, which dates back maybe ~20 years ago. It relies on a Microsoft technology called COM\DCOM to exchange messages between OPC clients and OPC server. Classic OPC is by far the most widely used form of industrial OPC. It supports three types: OPC DA: a specification for real-time data exchange, OPC HDA: for historical data access, OPC AE: for capturing alarms and events via OPC.

Since Classic OPC relies on a Microsoft technology, it works only on the Windows platform.

OPC UA

Released around 2008. OPC UA uses a modern service oriented software architecture for data exchange between industrial OPC UA clients and servers. It is the OPC of the future. More industrial device vendors are building OPC UA servers for their devices.

Unlike classic OPC, OPC UA doesn’t rely only on Microsoft technologies, and hence it can run on multiple platforms. This allows a lot of flexibility for the technology. For example, OPC UA servers can be found in embedded devices that run low level non-Windows platforms, this was not feasible with classic OPC.

Similar to classic OPC, industrial OPC UA software supports real-time data communications (OPC DA), historical data access (OPC HA), as well as alarms and conditions (OPC AC). OPC UA then takes functionality further: It offers modern security features to protect the data, as well as more advanced data modeling among other things.

Industrial OPC vendors

Industrial OPC specifications are handled by the OPC foundation. Which is in charge of promoting, and evolving OPC. If you are a software vendor, and want to build an OPC server product, you need your product to get certified from the OPC foundation to prove that it follows the OPC specifications and that it will be able to communicate with any OPC client out there.

The OPC foundation requires membership in order to be able to enjoy it’s benefits. The membership fees mostly rely on the size of your company. Obtaining a membership with the OPC foundation is an important step to aide a business getting involved with building OPC clients or servers.

When it comes to current established OPC vendors, there are a lot. Almost every enterprise that builds industrial sensors, PLCs or devices provides an industrial OPC server to go along with their product. There are two companies that I would like to discuss here:

MatrikonOPC

MatrikonOPC is where I started my career in the industrial software space. I owe a lot of my current knowledge and expertise to my time there. MatrikonOPC focuses mainly on writing OPC servers for different types of industrial protocols out there. Their products are used by enterprises in all sorts of industries. They also offer other industrial OPC products that are not OPC servers, like desktop historian for example which is a process historian that mainly uses OPC to collect data.

Kepware

Kepware is another popular OPC server vendor with a wide variety of loyal customers. It is the company behind KEPServerEX which relies on a pluggable software architecture, where you can add the industrial protocol driver of your choice as a plugin to their server without the need to install new software for each new protocol. MatrikonOPC also supports this architecture with some of it’s products, however Kepware seems to revolve around this idea.

OPC and the open source world

Industrial OPC software offerings in general aren’t traditionally open source. This is was a fact of the industry for a very long time, with some exceptions here and there.

Nowadays, especially due to the fact that OPC UA supports more modern software technologies as well as the rising prominence of open source software, there are some nice options available. I will cover two of them

NodeOPCUA is a nice option out there. It allows you to write OPC software in node.js which is a very popular modern cross platform (Windows, MacOS, Linux..etc) Javascript technology. The project uses the MIT license which means it’s fully free to use and build products on.

OPC UA.net  are modern OPC UA libraries based on the powerful Microsoft .NET framework. This software is provided by the OPC foundation. The core license is GPL which means there will be some restrictions if you decide to build a business and sell products from software built with those libraries. Microsoft seems to be getting involved to make these libraries more cross platform by supporting the latest addition to the .NET world which is .NET core. Microsoft is also making the software more Azure cloud friendly, which will ultimately help improve the software and make it business freindly. You can witness the cross-platform version here.

 

 

Care to share? ...Share on Google+Share on FacebookShare on LinkedInPin on PinterestShare on Reddit

One thought on “Practical thoughts on industrial OPC”

  1. Hi there,

    Thank you for this comprehensive article.
    I have seen your github and I was wondering if you did some stress tests, would it work for something like 100 modbus salves with 40 registers on each slave (4000 registers) ? How to dimension the server to support such load ?

    Thank you in advance,

    Benjamin

Leave a Reply

Your email address will not be published.