OPC Field Level Communications: A controller-to-controller specification within reach

• By Peter Lutz
• July 31, 2020
• Connectivity & Cybersecurity

Summary

Essential for the convergence of IT and OT, FLC is also important for upgrading legacy systems

Because of its versatility and manufacturer independence, OPC UA is already used today in many different industrial applications. However, OPC UA is much more than just a transport protocol in its traditional sense. Instead, OPC UA is an industrial, protocol-agnostic framework for the Industrial Internet of Things (IIoT) and Industry 4.0 that contains mechanisms for secure and reliable manufacturer- and platform-independent information exchange, as well as options for semantic information modeling and self-description of devices. OPC UA scales from the sensor across all levels to MES/ERP and also into the cloud. It includes cybersecurity mechanisms built in from the start.

To meet all requirements for use cases from end users, suppliers, and integrators from process automation to factory automation, in November 2018 the OPC Foundation established the Field Level Communications (FLC) initiative, supported by an impressive list of major automation suppliers. The scope of this initiative (figure 1) is to jointly specify and standardize the semantics, protocol, and physical interface of controllers and field devices from different manufacturers.

The main use cases covered by FLC are controller-to-controller and controller-to-device, including support for IIoT connectivity for both controllers and field devices. The FLC-related technical work includes the following topics:

• definition of an “automation component” with functions, interfaces, and behaviors that are common to the different FLC-conformant controllers and devices used in various applications in process and factory automation
• definition of system behaviors and sequences for common functionalities (e.g., bootstrapping and connection establishment)
• harmonization and standardization of application profiles like I/O, motion control, functional safety, and system redundancy
• standardization of OPC UA information models for field level devices in online and offline scenarios (e.g., device description and diagnostics)
• mapping to subordinate communication protocols and transmission physics, such as TCP, UDP, Ethernet APL/SPE, deterministic Ethernet (TSN) with future mapping to 5G and Wi-Fi 6
• guaranteeing the best integration of OPC UA companion specifications like FDI, FDT, PA-DIM, Analyzer Device Integration (ADI), Module Type Package (MTP), and MDIS (oil and gas), VDMA pumps, UMATI, and Spectaris.

FLC interaction model

To generalize from the specific and diverse application scenarios in the broad field of process and factory automation applications, FLC is using an abstract interaction model (figure 2), with the various “abstract” OPC UA use cases.

A controller represents a function typically implemented in a programmable automation controller, programmable logic controller, or distributed control system. Today, automation devices are typically connected to controllers and can be as simple as an inductive proximity switch or as complex as a Coriolis flowmeter or servo drive. Compute’s hardware aspect scales from a Raspberry Pi–based data gateway to a blade server in the cloud, but more important are the software applications running on these. Controllers and devices have many attributes in common—the term “automation component” is used where functions apply to both.

Controller-to-Compute. Software running on Compute platforms is a major area of innovation today, whether it is management information in dashboards, long-term process optimization, predictive device level diagnostics, or digital twins. These all require information to be extracted from controllers. OPC UA is dominant today, and almost every major controller supplier offers OPC UA directly on its controller or device.

Controller-to-controller. Plant owners and system integrators are assembling complex operations using machinery purchased from different machine/skid builders. They may find that each is fitted with a controller from a different vendor. This causes a need for an easy way to set up controller-to-controller communications across multiple vendors. The industrial automation industry has not yet effectively solved this problem, and the FLC controller-to-controller solution will be the first to deliver an interoperable real-time solution covering both standards and safety communications for all types of automation applications.

Controller-to-device. The traditional fieldbus approach of having a controller communicate with a subnet of I/O modules, drives, servos, instruments, and other smart automation components is well understood in the industrial automation community. However, it comes with constraints on network architecture and topology when a converged IT/OT solution is deployed, or when different industrial automation technologies share the network. The FLC initiative will have controller-to-device communications that meet or exceed the capabilities of existing solutions, and will add capabilities that are incompletely delivered by the IEC 61784 profiles.

Device-to-device. In bringing together best practices for multiple shop-floor technologies and by harmonizing the application profiles used in end devices, applications such as load sharing of inflexible loads across multiple servo drives will become far easier to deploy in an interoperable manner.

Device-to-Compute. Controllers often serve as a proxy for devices, add valuable context to the information provided by these devices, and in some cases control access to that information. However, as devices become increasingly complex with an ever-growing number of useful variables and internal and external measurements, the use of a controller as a proxy becomes increasingly impractical. For example, routing 4,000 variables from each device through a controller is no longer scalable. FLC will define the necessary semantics and metadata to contextualize the information from devices for use in diverse Compute-based software applications in an open architecture without the controller acting as a bottleneck.

Compute-to-Compute. These applications include gateways to IT systems, cloud-cloud connectivity, interoperable manufacturing operations management, and many more. The Field Level Communications initiative will use and build on the services, information modeling, and interoperability that have driven the success of OPC UA in Compute-to-Compute applications over the past decade. No need for the further development of capabilities to support Compute-to-Compute applications is expected within the FLC initiative, but these applications will inherit and benefit from the increased harmonization at the field level.

FLC system architecture

The FLC system architecture is based on the OPC UA framework (IEC 62541), which enables secure, reliable, and manufacturer- and platform-independent information exchange (figure 3). FLC controllers and devices support the connection-oriented client/server communication model on the one hand, and the publish/subscribe (PubSub) extensions on the other. OPC UA PubSub is essential for communication at the field level due to the corresponding requirements for flexibility, efficiency, and determinism. FLC also uses the security mechanisms specified in OPC UA, which among other things support authentication, signing, and encryption of the data to be transported and can be used for client-server as well as PubSub communication relationships.

The central element for the extensions specified by FLC is the metamodel of OPC UA (figure 3). This is used to specify corresponding information models for FLC automation components and to make the modeled information accessible via standardized OPC UA services.

Because all FLC automation components (controllers and devices) are based on OPC UA, uniform, integrated communication is available across all automation levels supporting a broad range of use cases that open up completely new possibilities, especially with regard to the different Industry 4.0 application scenarios and IT/OT convergence.

Offline engineering

Offline engineering is an important element for the development, operation, and maintenance of an automation system. When the user has the ability to understand the operation of the automation system before deploying the system in physical hardware, the user will know that the system will perform the control function reliably and correctly once the physical system is in place. The user will be able to simulate changes and updates to the automation system before making changes to the physical system and be assured the changes will perform up to the expectation of the user and improve the performance of the system. With the help of product and configuration descriptors, the device descriptions are made accessible to the corresponding configuration tools. However, the specification work does not start “from scratch,” but the corresponding preparatory work and experience of the supporting automation manufacturers and fieldbus organizations serve as the basis.

FLC-related modeling

A key element of the FLC-related work is the modeling of functions by means of so-called OPC UA Facets. OPC UA Profiles represent a collection of Facets that can be atomically tested. Full Profiles represent the complete functionality of a device.

The FLC base facet describes basic functions that are common to the various types of automation components (controllers and field devices), such as device identification, basic diagnosis, and connection management. Device- or function-specific facets are built upon the base facet, such as for functional safety, motion, I/O, and instrumentation.

Safety and motion

Functional safety requirements are covered by OPC UA Safety. For this purpose, the first OPC UA safety specification has already been adopted, which is based on client-server mechanisms and has emerged from a joint working group with the Profibus user organization (PNO). There will also be an extension shortly that describes the mapping to PubSub and the parameterization of safety devices. The special feature of the safety concept for OPC UA is, among other things, that safe participants can be integrated into the communication even during ongoing operation, which is not possible with conventional safety protocols.

The Motion Facet includes the specification of motion control functions for various types of motion devices, such as controls, standard drives, frequency converters, and servo drives. The FLC initiative has determined CIP Motion™ and Sercos to be ideal solutions on which to base OPC UA Motion. The CIP Motion and Sercos specifications will be used and may be changed or extended for adaptation to the FLC system architecture, to support innovation to cover Industry 4.0 and digitalization use cases, and to facilitate modern concepts of data modeling and real-time requirements.

The facets that are specified and standardized by OPC can be complemented by OPC UA companion models like FDI, FDT, PA-DIM, Analyzer Device Integration (ADI), Module Type Package (MTP), MDIS (oil and gas), VDMA pumps, UMATI, Spectaris, and so forth. In addition, vendor-specific models can be integrated.

Communication

An important aspect of FLC is to support different underlying transport protocols and physical layers for the broad range of use cases in factory and process automation. To achieve this, the concept of quality of service (QoS) modeling is introduced, which has the possibility of flexibly mapping services to lower-level communication protocols.

In a first step, FLC supports a layer 3 mapping via UDP and a direct layer 2 mapping to Ethernet TSN, both combinable with SPE/APL physical layer. However, the QoS modeling also allows an easy expansion to other subordinate transmission standards, including wireless data exchange, such as 5G or Wi-Fi 6.

The combination of OPC UA with a direct mapping to Ethernet TSN is of particular importance. Only then is deterministic data transmission via OPC UA possible. A working group headed by the FLC steering committee is currently working out which TSN substandards for the FLC end devices and infrastructure components shall be mandatory to meet the specified requirements for performance, flexibility, and ease of use.

On the part of the OPC Foundation there is a clear commitment to the TSN-IA profile, which is being developed in the IEC/IEEE 60802 working group. It has the goal that different protocols and traffic types can be transmitted via a common network infrastructure. This coexistence is not only essential for the convergence of IT and OT, it is also an important aspect when migrating existing brownfield solutions based on conventional fieldbus protocols. In the end, users should be able to freely decide how quickly they want to replace old systems or system components with new ones.

Road map

Work on the first specification version has made good progress in recent months, despite Covid-19 and its limitations. The basic concepts have largely been adopted and have been incorporated into the first draft specifications. The release candidate of the first specification version is within reach. According to current planning, it should be ready in the third quarter. Prototyping has started to verify the draft specifications.

A first specification release can be expected by the end of 2020. At the same time, a working group is also set up to generate the corresponding test specifications, which are then converted into corresponding test cases for the OPC UA Certification Tool (CTT) in a second step. Work has already started on concepts for the controller-to-device use case, which will be included in the second specification version.

• Facebook
• Twitter
• Linked In