Basic knowledge IoT basics: What is OPC UA?

Related Vendors

Jongen Werkzeugtechnik GmbH

LK Metallwaren GmbH

KUKA Industries GmbH

Bühler AG

Nemak Europe GmbH

Semantic interoperability is considered key for the implementation of Industry 4.0. Standardized and secure communication from the field device to the cloud is no longer a vision, but a reality that can be implemented with the help of OPC UA. In this article you will learn what this open communication standard is all about.

Definition and features

OPC UA (short for Open Platform Communications United Architecture) is a data exchange standard for industrial communication (machine-to-machine or PC-to-machine communication). This open interface standard is independent of the manufacturer or system supplier of the application, of the programming language in which the respective software was programmed, and of the operating system on which the application is running.

The biggest difference to previous versions is that machine data can not only be transported, but also semantically described in a machine-readable way. OPC UA provides access to a wide variety of data in both vertical and horizontal directions. The spectrum ranges from OPC UA components directly integrated on the devices and controllers or machines and systems to so-called gateways and aggregating servers.

OPC UA and Industry 4.0

A central challenge of Industry 4.0 and the industrial Internet of Things (IIoT) is the secure, standardized exchange of data and information between devices, machines and services, even from different industries. In April 2015, the Reference Architecture Model for Industry 4.0 (RAMI 4.0) already listed the IEC 62541 standard OPC Unified Architecture (OPC UA) [I.1] as the only recommended solution for implementing the communication layer.

The basic requirement for using OPC UA for industrial 4.0 communication is a network based on the Internet Protocol (IP). Anyone who wants to advertise with the label of "Industry 4.0-capable" must be OPC-UA-capable too (integrated or via a gateway). The property of the information modeling of OPC UA is explicitly highlighted.

Service-oriented architecture

Information modeling? Many SMEs already stop paying attention at this point — OPC UA is then quickly compared with other protocols and supposed restrictions in deployment scenarios are identified. First of all: Unknowingly, every equipment and machine manufacturer already provides an information model: Data and interfaces are already available (via various protocols). The new world of devices helps us to understand the things faster and easier, because they now offer services, but above all their meaning. This is nothing new in the IT world — but now this service-oriented architecture (SoA) is advancing into the “things” themselves.

And this is exactly where OPC UA helps the framework of industrial interoperability. Device and machine manufacturers describe the object-oriented information of their system and also define the access rights with integrated IT security. The German BSI has published the results of the OPC-UA safety analysis [I.3] on its website. The machine-builders therefore remain in control of their data or can distribute it in a targeted and controlled manner and thus also participate in big data and analysis in monetary terms.

There are two mechanisms for exchanging this data:

• a client-server model in which UA clients use the dedicated services of the UA server;

• a publisher-subscriber model in which a UA server makes configurable subsets of information available to any number of recipients.

Both mechanisms are detached from the actual protocol and therefore TCP and HTTPS represent the client server and UDP as well as AMQP and MQTT for the subscriber model. Definitely you need both variants:

• the peer-to-peer context for secure, confirmed transport — but with limitations on the number of connections;

• the broadcast distribution to all under the aspect “Fire and forget”.

OPC UA combines both. The question of choosing between “OPC UA or AMQP or MQTT” does not arise, says the OPC Foundation, since OPC UA can also deliver this. However, a resource-limited device with “MQTT only” should fire its data in the “OPC UA via MQTT” information model format.

What data and services does a device or machine offer?

Transport, Security, Access Rights
From an “external” point of view, access to machine data and services should be defined as completely secure in terms of IT security. OPC UA does not only offer the common IT mechanisms for authentication, signing and encrypted access.

The actual transport layer can be extended by additional protocols at any time. The independence from the physical transport medium and the transport protocol is a decisive advantage of OPC UA compared to other pure IoT data protocols. The device or machine builder does not have to worry about this, but only provides the data and services in a secure way.

Modelling
Machines must offer their data and services in machine-readable form if machines and services are to communicate with each other and if engineering is to be as simple as possible. The semantic definition of the interfaces can be modelled with OPC UA by the respective professional associations. As an example, the companies Harting and Siemens pushed this forward for the AutoID industry and implemented the interface specification as well as the implementation within a short time: RFID readers with integrated OPC UA and AutoID Companion Spec support are available from stock. OPC UA clients, available as PLCopen components in a PLC control or visualization or from the cloud, can now implement identical access to the devices of both manufacturers with extremely simple engineering efforts.

No Differentiation Possible with OPC UA?
If RFID readers from different manufacturers are equipped with an identical interface — is the differentiation of the devices still ensured? The answer is: No. In addition to the standardized information model, each device manufacturer can offer its own models as an “extra” in parallel. This combination of “device standards” and “device individuality” makes sense and is ideally suited to give competing device manufacturers the opportunity to reach an agreement, but still make their added value available to the users But one thing remains important: An OPC UA client accesses all interfaces - the standardized and the manufacturer-specific ones — with the same mechanism.

This layer of data and service modeling is the real key to Industry 4.0 and the main difference to “just pushing IoT data” into the cloud: Many organizations have recognized this and have thus modeled their market-specific information models with OPC UA — an overview offered by the OPC Foundation can be found online [I.4]. By the way: Membership in the manufacturer-independent non-profit organization is not required for the use of OPC-UA technology or the creation of OPC-UA products.

Services
Irrespective of the purpose of the device or machine, certain services are always available; only a few are presented here:

• Today, data services provide visualizations of the required live data (the IT world speaks of real-time data - not to be confused with deterministic data from the hard real-time) of the machine. Historical data from the past or alarms when certain value levels are exceeded or undercut also belong to this category of services.

• Administrative services tend to affect the functionality of the devices: A PLC control can be switched between stop and start (this service was defined by the PLCopen & OPCF workgroup, for example) in order to transfer new logic sequence programs to the control via OPC UA file transfer. A distribution of a revised PLC logic into many applications distributed worldwide, such as wind turbines, is thus easy and, above all, safe to implement. Sending and loading of files also supports decentralized Smart Meter applications.

• Monitoring services can provide information about the device itself at any time, such as the temperature of the CPU or its usage, fan speed, etc.

• Application services or machine services: The device or machine builders can simply define their own external services - in networked machines in the timber industry, e.g. “Readout feed rate” or “Readiness for operation”, as well as in completely different industries such as an intelligent camera “Capture and evaluate image”.

Operating System and real time
Which operating system works on a machine or whether a special real-time implementation is used plays no role for external device and machine communication: None of this is visible to the outside — in an Industry 4.0 compatible device. The selection of an operating system, e.g. a control manufacturer, is subject to different criteria and provides the actual basis for differentiating the machine functionality:

Long support availability, exemption from IP policies, an excellent software tool chain for simple engineering, scalable deployment from the smallest embedded system to multi-core systems are, for example, factors that distinguish one controller manufacturer from the other.

Scalability
OPC UA is scalable from small devices to the IT level. Already in 2012, the Fraunhofer Institute Lemgo reduced an OPC UA server to a 10 kB footprint in order to integrate it into tiny sensors mounted on chips.

Areva has integrated an OPC UA server into the sensor of monitoring devices for valves and their electric actuators. This solution is used in the nuclear industry to monitor critical systems in remote areas. Apart from the reliability of the data, integrated security is therefore also an essential aspect. The OPC UA server requires a memory utilization starting with 240 kByte Flash and 35 kByte RAM.

Adaptation
Beckhoff and Siemens supported the OPC UA standard as early adapter in 2008, integrating it into devices and selling it from stock. Today, almost all PLC, visualization and MES-manufacturer support this standard. The connection of a new production machine therefore no longer takes days - with considerable integration and testing effort - but can be implemented in less than an hour. OPC UA continues to be used in the smallest devices as well as in the cloud.

Since May 2015, the OPC UA specifications are publicly available and the OPC Foundation has implemented the opening of stacks as OpenSource for evaluation purposes in 2016. For professional OPC UA integration into industrial products, companies offer toolkits and consulting services.

Practical applications of OPC UA

Vertical Application: Energy Monitoring and Big Data
With energy monitoring in decentralized properties, operators are in a position to implement all requirements for optimized, energetic operational management. As an example, up to 2,000 properties and more are managed by their facility management in cities such as Aachen. The energy monitoring system “e2watch of the regio iT Gesellschaft für Informationstechnologie” was developed in cooperation with the building management of the city of Aachen [I.7].

An embedded microcontroller was used as a decentralized device, which collects the measurement data, first buffers it locally and synchronizes it with the cloud at freely configurable times (Fig. 6). OPC UA is used as a transport route and IT standard featuring integrated security. As an OPC UA client, the controller pushes the data as "historical access" data directly into the "big data management solution" stored in the cloud. This is where a further analysis or evaluation of the data takes place, which operators and users of the properties can access using Internet-based visualization.

A further benefit is that parameter comparisons and benchmarking between equivalent properties can be carried out in order to ensure control of energy consumption. Access to the evaluated data is also expected to have a positive effect on user behavior.

The addressable customer potential of this solution can be transferred to many other industries: Collecting, buffering and forwarding data are common tasks.

Horizontal application: M2M in water management
The Water and Waste Water Consortium Vogtland confirms the financial savings potential as an essential result of a complete communication architecture based on OPC UA. More than 550 water and wastewater treatment plants (water supply for 40 towns and municipalities, wastewater disposal in 37 towns and municipalities with a total population of 240,000) are distributed over an area of 1400 km².

The number of plants includes waterworks, pumping stations, elevated tanks, sewage treatment plants and sewer relief structures. In the past, information was only collected centrally in the control room in order to coordinate partly cost-intensive service operations there. Special requirements, such as the buffering of process data in the event of a communication transport failure and the use of many different protocols with different configurations, have led to high maintenance requirements and corresponding costs over many years.

By eliminating proprietary communication protocols and installing decentralized, networked intelligence, engineering and service costs have been reduced, while IT security and data availability increased. Using OPC UA for direct M2M communication, all devices in the decentralized properties had to operate autonomously, the smallest embedded controllers were intelligently networked with each other and communicate directly with each other.

This application represents a first real implementation of the results of the cooperation between the PLCopen and OPC working groups: Real objects (e.g. a pump) were modeled in the IEC-61131-3 PLC control as complex objects with interaction possibilities. The OPC UA server integrated into the controller automatically made these objects available to the outside world as a complex data structure for semantic interoperability.

The result is a decentralized intelligence that makes decisions independently and transmits information to its neighbors or queries statuses and process values for its own process in order to ensure an undisturbed process flow. The devices “talk” directly to each other: e.g. waterworks 1 reports a decreasing water quality (caused e.g. by fertilized fields) to its own pump. The latter can now delegate the "fill elevated tank" job to another pumping station. With the standardized Functionblocks of PLCopen, the devices, i.e. UA clients, independently initiate communication from the PLC to other process participants.

As UA servers, they respond simultaneously to their requests or to requests from higher-level systems (Scada, Meserp). The devices are connected via mobile routers. A physical loss of connection does not lead to a loss of information, since the data is automatically buffered in the UA server for some time and can be retrieved as soon as the connection has been re-established. This is a very important feature that used to require a lot of proprietary engineering.

For the integrity of this partly sensitive communication, the security mechanisms integrated in OPC UA, such as authentication, signing and encryption, were used in addition to a closed mobile radio group. The manufacturer-independent interoperability standard OPC UA gave the end user the opportunity to subordinate the selection of a target platform to the required technology in order to avoid the use of proprietary products or products that do not meet the requirements. The replacement of a proprietary solution by a combined OPC UA client/server solution resulted in a reduction of initial licensing cost of more than 90 % per device.

Vertical application: IoT platform
Microsoft recognized the importance of OPC UA in the context of Industry 4.0 early on and integrated OPC UA into the Azure Cloud. New OPC UA servers (1) that support pub/sub-functionality can already upload telemetry data directly to the Azure Cloud via JSON/AMQP. A gateway (2) is available for the OPC UA server with client-server (TCP) channel - in this case the UA data is converted to UA and forwarded via AMQP. The "Control & Command" return channel (3) can also be configured.

Roadmap and outlook

OPC UA continues to evolve. The trends described below can currently be predicted.

Trend: Information models
Other associations such as the AutoID industry (RFID readers, scanners, ...), VDMA specialist groups such as injection molding machines, robotics or machine vision (and 35 other automation industries) already define their information in OPC UA servers — a so-called OPC UA Companion Specification. To fulfill such an industry standard as a provider does not mean to be immediately interchangeable: Anyone can continue to offer their own manufacturer-specific services in parallel.

Intelligent devices should be able to support several information models in parallel: in addition to dedicated functionality, they should also be able to support energy data or MES interfaces, etc. In order to reduce engineering, the importance of these industry and cross-industry information models will increase significantly in the future: Manufacturers who do not support the standard will soon no longer be able to sell their products.

Trend: Service-Oriented Architecture (SoA)
The information models of most industries are no longer based on bit/byte property exchange, but on services with complex parameters. A UA client that does not support methods or complex parameters will increasingly be unable to communicate with UA servers. The DKE organization lists OPC UA as the only SoA solution. Independent of SoA: The automation pyramid for organizing a factory will certainly continue to exist — but the communication pyramid has become obsolete with OPC UA: Devices can deliver data directly or in parallel to the MES (Manufacturing Execution System) or the ERP (Enterprise Resource Planning) level — even the logic does not always have to run on the PLC on site, but can (currently for non-critical processes) run in the cloud.

Trend: OPC UA on a Chip
OPC UA will “grow” into ever smaller devices and sensors. The smallest OPC UA software solutions with limited (but readable) functionality require 35 kB RAM and 240 kB Flash. The first chips with integrated OPC UA are available on the market, and so OPC UA continues to move into the sensor world. The applications of OPC UA are already moving from the core area of automation to other industries such as industrial catering equipment.

Trend: OPC UA with TSN
The robot manufacturer Kuka joined the OPC Foundation in 2015 in order to actively help in shaping this standard: From KUKA's point of view, faster, real-time communication via OPC UA must also be feasible in order to use a single communication solution for scaling: from the horizontal robot controller to the manual robot controller, but also down to the MES and IT levels. There is another significant advantage: OPC UA is not just a "protocol", but an architecture that can be extended to meet the requirements of the market: The requirement for hard real-time with the combination of Time Sensitive Network (TSN) and OPC UA has already started in a working group, but the implementation and market launch will still take some time.

This article is based on the reference book “Industrie 4.0: Potenziale erkennen und umsetzen” by Thomas Schulz (Ed.) The book offers the professional a practice-oriented and comprehensive insight into the digitization of manufacturing and production.