Industrial Network Protocols. OPC UA. Part 1.

By Roman ShulenkovIndustrial automation and robotics

Theoretical part

Open Platform Communications (OPC) is a series of standards and specifications for industrial telecommunications and industrial networks. An industrial automation task force developed the original standard in 1996 under the name OLE for Process Control (Object Linking and Embedding for process control). OPC specifies the communication of real-time plant data between control devices from different manufacturers.

OPC was designed to provide a common bridge for Windows-based software applications and process control hardware. Standards define consistent methods of accessing field data from plant floor devices. This method remains the same regardless of the type and source of data. An OPC Server for one hardware device provides the same methods for an OPC Client to access its data as any and every other OPC Server for that same and any other hardware device. The aim was to reduce the amount of duplicated effort required from hardware manufacturers and their software partners, and from the SCADA (Supervisory Control And Data Acquisition) and other HMI (Human-Machine Interface) producers in order to interface the two. Once a hardware manufacturer had developed their OPC Server for the new hardware device, their work was done with regard to allowing any ‘top end’ to access their device, and once the SCADA producer had developed their OPC Client, their work was done with regard to allowing access to any hardware, existing or yet to be created, with an OPC compliant server.

Despite the huge success and general acceptance, the practice has identified the following disadvantages of OPC technology:
  • Available only in operating systems of the Microsoft Windows family.
  • Connection with DCOM technology, the source code of which is closed. This does not allow solving problems of software reliability, as well as identifying and eliminating emerging software failures.
  • There are configuration issues related to DCOM.
  • Inaccurate DCOM communication interruption messages.
  • DCOM’s inability to communicate over the Internet.
  • DCOM’s failure to provide information security.
Therefore, to address these shortcomings, in 2006 the OPC Foundation proposed a new standard for device communication in industrial automation. The new standard is called OPC unified architecture, which is considered the next generation OPC standard.

Distinctive features of OPC UA:

  • Focus on communicating with industrial equipment and systems for data collection and control.
  • Open – freely available and implementable under GPL 2.0 license.
  • Cross-platform – not tied to one operating system or programming language.
  • Service-oriented architecture (SOA).
  • Inherent complexity – the specification consists of 1250 pages in 14 documents.
  • Offers security functionality for authentication, authorization, integrity, and confidentiality.
  • Integral information model, which is the foundation of the infrastructure necessary for information integration where vendors and organizations can model their complex data into an OPC UA namespace to take advantage of the rich service-oriented architecture of OPC UA. There are over 35 collaborations with the OPC Foundation currently. Key industries include pharmaceutical, oil and gas, building automation, industrial robotics, security, manufacturing, and process control.
The OPC UA standard specifies the methods for exchanging messages between the OPC server and the client, regardless of the hardware and software platform, the type of interacting systems, and networks. ОРС UA provides reliable and secure communication, counteracts hacker attacks, and guarantees the identity of client and server information. The new standard uses the concept of an object, which is understood as a physical or abstract element of a system. Examples of objects include physical devices, including their systems and subsystems. A temperature sensor, for example, can be thought of as an object that includes a temperature value, a set of alarm parameters, and their thresholds. An object, by analogy with object-oriented programming, is defined as an instance of a class, and a class is treated as a data type. Objects include variables, events, and methods. OPC UA uses several data formats, the main ones being binary structures and XML documents. The data format can be defined by the OPC server vendor or by the standard. To work with arbitrary formats, the client can ask the server for information about the description of this format. In many cases, automatic recognition of the data format during transmission is used.

Protocol

The TCP-based binary protocol is by far the most common transport layer for OPC UA. The general concepts also translate to HTTP and SOAP-based communication defined in the standard. Communication in OPC UA is best understood by starting with the following key principles:

Request/Response
All communication is based on the Request/Response pattern. Only clients can send a request to a server. And servers can only send responses to a request. Usually, the server is hosted on the (physical) device, such as a sensor or a machine tool.

Asynchronous Responses
A server does not have to immediately respond to requests and responses may be sent in a different order. This keeps the server responsive when it takes time until a specific request has been processed (e.g. a method call or when reading from a sensor with delay). Furthermore, Subscriptions (aka push-notifications) are implemented via special requests where the response is delayed until a notification is generated.

OPC UA Services:
  • Discovery Services – this service allows the client to know what objects are available, how the current objects are related to other objects, what data and what type of data is available, what metadata is available that can be used to organize, classify and describe these objects and their values.
  • Subscription services – this service can be used by the client to determine what data is available for notifications. This service helps the client to determine how often and when to be notified of changes not only in data values but also in metadata and object structure.
  • Query Services – this Service Set is used to issue a Query to a Server. OPC UA Query is generic in that it provides an underlying storage mechanism independent Query capability that can be used to access a wide variety of OPC UA data stores and information management systems. OPC UA Query permits a Client to access data maintained by a Server without any knowledge of the logical schema used for internal storage of the data.
  • Node Services –this service can be used by clients to create, delete, and modify the data structure supported by the server.
  • Method Services – clients can use this service to call functions related to objects.
  • Secure Channel Service – this Service Set defines Services used to open a communication channel that ensures the confidentiality and Integrity of all Messages exchanged with the Server.
  • Session Service – this Service Set defines Services for an application layer connection establishment in the context of a Session.
  • View Service – clients use the browse Services of the View Service Set to navigate through the address space or through a View which is a subset of the address space.
OPC UA server is a data engine that gathers information and presents it in ways that are useful to various types of OPC UA client devices, devices that could be located on the factory floor like an HMI, a proprietary control program like a recipe manager, or a database, dashboard or sophisticated analytics program that might be located on an enterprise server. Data is not necessarily limited to a single physical node. Objects can reference other objects, data variables, data types, and more that exist in nodes off someplace else in the subnet or someplace else in the architecture or even someplace else on the Internet.

Practical part

To implement our example, we need Tia Portal, Linux OS (Ubuntu, Debin), UaExpert and S7-1200. Tia Portal is necessary for us to program the S7-1200 PLC.

Tia Portal V16 – Totally Integrated Automation Portal (TIA Portal) provides you with unrestricted access to our complete range of digitalized automation services, from digital planning and integrated engineering to transparent operation. The new version shortens your time to market, for example by means of simulation tools, increases the productivity of your plant through additional diagnostics and energy management functions, and offers you broader flexibility by connecting to the management level. The new options benefit system integrators and machine builders as well as plant operators. TIA Portal is thus your perfect gateway to automation in the Digital Enterprise. As part of the Digital Enterprise Suite along with PLM and MES, it complements the comprehensive range of offerings from Siemens for companies on their path to Industrie 4.0.

On the PLC side, we will launch the OPC UA server.

1. We go into the PLC settings and activate the OPC UA server.

2. Checking the security settings for the OPС UA server.

3. Next, we configure the licensing options.

4. We need to create a block of data for 4 variables of type boolean.

5. We create a simple program that, by changing the state of variables in a data block, will turn the output discrete signals on or off.

6. We create an elementary program in the LD language.

7. Add the created variables of the data block to the OPC UA interface.

8. We load the configuration and firmware into the PLC and check the work online.

9. We will use UaExpert v1.5.1 to monitor the state of the OPC UA server.

10. We configure the network and configure the software for our OPC UA server.

11. We connect to the OPC UA server and monitor the state of the data block, using this software, we can also change the state of variables in the data block, thereby turning on and off the discrete outputs of the PLC.

Today we got to know OPC UA and created a basic example that we will need in other articles on OPC UA.

  • Industrial Network Protocols. OPC UA. Part 1.
  • Industrial Network Protocols. OPC UA. Part 2.
  • Industrial Network Protocols. OPC UA. Part 3.
  • Industrial Network Protocols. OPC UA. Part 4.
  • Industrial Network Protocols. OPC UA. Part 5.
  • Industrial Network Protocols. OPC UA. Part 6.
  • Industrial Network Protocols. OPC UA. Part 7.