Get in touch with our specialists, please fill in the form below, and we will get back to you as soon as we can
OPC is one of the most used way to communicate in the automation area. Learn more about OPC and OPC UA here.
OPC (OLE for Process Control) was first defined by a number of players in automation together with Microsoft all the way back in 1995. Over the following ten years it became the most used versatile way to communicate in the automation layer in all types of industry. Over the years it has evolved from the start with simple Data access (DA) over Alarm & Events (AE) to the more advanced Historical Data Access (HDA) to have quite extensive functionality and reach. Though there were always some gaps where it didn’t cover the needs and requirements from the more and more advanced control systems. It was out of those needs for model based data and getting more platform independent that resulted in the creation of the OPC UA standard.
Learn more about the Kepware Communication platform
OPC stands for OLE for Process Control which clearly shows that it comes out of the Microsoft community, based on the OLE and DCOM technology. OPC is a Client/Server based communication which means that you have one or more servers that waits for several Clients to make requests. Once the server gets a request it answers to that and then goes back into wait state. But the client can also instruct the Server to send updates when such comes in to the server. In OPC it’s the client that decides when and what data the server will fetch from the underlying systems. That is also true if the client subscribe to updates where the client decides how often the server should quire the systems.
The different classical OPC protocols are completely self-sustained and have nothing in common. That means that the quality field in DA have no connection to the same field in HAD. Currently in the classic OPC model you have the following protocols; DA (Data access), AE (Alarm & Events), HDA (Historical Data Access), XML DA (XML Data Access) and finally DX (Data eXchange). Each of these protocols have their own read, write, etc. commands that only affect one protocol at the time. That is true even if one OPC server supports several of the protocols. The most commonly used and oldest protocol is the data access (DA) and in the following sections that and the others will be more explained.
The most basic protocol of the OPC stack is the Data Access protocol that gets data out of the control systems into other systems on the shop floor. Each information about a specific tag or data point contains some information about it. First you have the data itself and that is called Value and of course the Name of it. To that comes a number of other pieces of information that describes the information, the first is the Timestamp that gives you the exact time when the value was read. This timestamp can be taken either directly from the underlying system or assigned to it when the data is read in the OPC server. The last piece is called Quality which gives a basic understanding if the data is valid or not.
The second protocol to be added to the OPC stack was Alarms & Events. This protocol is fundamentally different from the DA protocol simply due to the fact that events not have a current value. This means that this protocol always is a subscription based service where the clients gets all the events that comes in. In terms of data that comes with the event there is no tags and therefore not any name and quality but there is of course a Timestamp. But like in the case with DA there is no store in the server and once the event is transferred the server forgets it was ever there.
The difference between DA, AE and HDA is that HDA contains historical data and you can call for a large amount of past data. The protocol therefore supports long record sets of data for one or more data points. It was designed to provide a unified way to get out and distribute historical data stored in SCADA or Historian systems like OSI-PI or Historian from GE. The protocol is not so widely used today and now the introduction of OPC UA makes it somewhat obsolete.
The most significant difference between classical OPC and OPC UA is that it doesn’t rely on OLE or DCOM technology from Microsoft that makes it possible to implement it on any platform if that being Apple, Linux (JAVA) or Windows. The other very important part of UA is the possibility to use structures or models. This means that the data tags or points can be grouped and be given context which make governance and maintenance much easier. These models can be identified in runtime which makes it possible for a client to explore connection possible by asking the server.
The information modelling is very modern in OPC UA. These models can be defined by manufactures or protocols like BACNet but it can also contain more of a MESH structure where very complex relations and connections between points and nodes can be defined. The possibility also exist to have data structures so that certain data always is grouped and handled as one piece. This is important in many applications where you want to be sure that the data set is taken at the same time.
OPC UA is as said before built to be platform independent and the communication is built into layers on top of the standard TCP/IP stack. Above the standard transport layers there are two layers, one that handles the session and one to establish a secure channel between the client and server. The transport layer is made up of TCP/IP and on top of that SSL, HTTP or HTTPS. The Communication layer secure the communication channel not just that the data is corrupted but also it secure the authentication so that the end points can’t be infiltrated and changed. This is based on X.509 certificates that have three parts to it and the first peer to peer trust needs to be manually done but after that the rest is taken care of securely.
So far OPC UA are mostly used for bridging between different OPC servers, this is called tunneling. This is something that for example KEPServerEX OPC UA tunnel does. Other applications include the GE Global discovery server and the same control system that have full OPC UA support for browsing the data structures. This is still quite uncommon but the development goes fast and there is a lot of work done in order to include data models for transferring models from BACNet, ISA95 and PLCopen.
The OPC Quick Client assists in the testing and development of the OPC Data Access 1.0 and 2.0 servers. It supports both local and remote OPC server connections. Remote connections are handled through the operating system's DCOM interface.
OPC Unified Architecture (UA) is an open standard created by the OPC Foundation with help from dozens of member organizations.
Pop up content