OPC Background and evolutionOPC (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. OPC FundamentalsOPC 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. OPC Protocols or typesThe 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.
The LabVIEW OPC UA Toolkit contains the OPC UA API that was formerly part of the LabVIEW Datalogging and Supervisory Control (DSC) Module and the LabVIEW Real-Time Module. From the 2017 release, the LabVIEW OPC UA Toolkit becomes a standalone product. The LabVIEW DSC Module and the LabVIEW Real-Time Module no longer contain the OPC UA API.
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. OPC Data AccessThe 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. OPC Alarm & EventsThe 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. OPC Unified Architecture (UA)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. OPC UA Information ModellingThe 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 Communication layersOPC 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. Applications with OPC UASo 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 LabVIEW OPC UA Toolkit is a software add-on for LabVIEW. It contains the OPC UA API that integrates secure and reliable communications. You can use this toolkit to create OPC UA clients, servers, and security management. In addition to the Data Access facet of the OPC UA Specifications, the LabVIEW OPC UA Toolkit offers support for the Historical Access and Alarms & Condition facets.
The toolkit works with both Windows and NI Linux Real-Time OSs.The registered trademark Linux® is used pursuant to a sublicense from LMI, the exclusive licensee of Linus Torvalds, owner of the mark on a worldwide basis.