Development work for using OPC technology on the field level began with the standardization of TSN (Time-Sensitive Networking). A large number of single- and multi-vendor demonstrators were illustrating the possibilities of TSN technology in terms of synchronicity and real-time capabilities at an early stage. However, if every company or user organization were to upgrade their own existing system to TSN, there would be no benefits for the automation world.

Against this backdrop, a TSN standardization project (IEC/IEEE 60802-IA) was started at the IEEE/IEC standardization level early on, aimed at standardizing TSN use in industrial automation technology. Upon completion of a uniform TSN profile, automation and IT protocols should be able to share a TSN network with corresponding guarantees. At the same time, the resulting new communication level – the “converged network” – should not interfere with existing communications. To be able to communicate in a common language at the application level, however, the two technologies TSN and OPC UA Pub/Sub (Publisher/Subscriber) had to be combined with each other.

To this end, a group of automation service providers, technology providers, and component and switch manufacturers within the OPC user organization came together at the 2018 SPS trade fair in Nuremberg to establish the Field Level Communication (FLC) initiative. There are currently 26 companies involved. They have committed to actively supporting the FLC initiative to develop a comprehensive FLC communication standard for automation technology based on OPC UA and TSN. Although these 26 companies are steering the initiative, the actual specification work carried out in working groups is open to every member of the OPC Foundation. And now, after around one and a half years, the initial results can be seen.

Controller-to-controller

Developing a completely new ecosystem for automation which is also capable of integrating technological developments that will be made in the coming 20 years is proving to be a great challenge. The specification will have to cover a range of requirements, from those of process technology all the way to synchronous motion control applications. Therefore, the FLC initiative members decided to realize a successive concept.

The first stage focused on exchanging data between controllers. The initial work addressed application scenarios in which two controllers are configured from both sides to coordinate with each other. The IP addresses have already been assigned and there is no need to configure the communication parameters.
Along with online communication, mechanisms were also defined for the offline engineering phase. In addition, the controllers are supposed to transmit standard and safety data securely. This step alone will create significant added value compared to current solution approaches.

Offline engineering with FLC

The device description solutions available today focus on integrating a specific sensor or actuator device type into a system provider’s engineering concept. Often, the file is no longer actively used once the device has been instantiated. This is not the case with FLC; the file can only contain type information (product descriptor), but it can also be extended with instance information. With this procedure, the file automatically becomes an instantiated solution descriptor.

If known, address information or specific configurations can therefore be defined in advance before then being integrated into the other engineering system. The device description file therefore automatically becomes the digital twin of the communication partner. Each user can add the information that they already know as a part of their engineering tasks. Consequently, the file content grows as the project develops. This is resolved using an approach based on the AML (Automation Markup Language) programming language, which combines both FLC-specific and other information in one packet.

Data receiver communications

In the first stage, the FLC initiative is favoring a simplified model for establishing a connection. Here, establishing communication is initiated by the data receiver, and the sender then transmits the data cyclically in the respective quality and cycle time in accordance with the receiver requirements. The idea behind this model is that where there are two communication participants, the receiver knows best when its application needs the data. If bidirectional data exchange is to be established, then both sides must be able to initiate data transmission. This approach has therefore been specified such that it can also be extended to bidirectional communication models.

A similar communication model has been created for forwarding safety-related data in OPC UA Safety applications: The safety consumer starts a cyclical request for the safety provider to send data to the consumer. If the consumer does not request any data, the provider does not send any. This means that the provider-side protocol is simple, because time and control mechanisms are not required. On the consumer side, safety-related control is based on timeouts or CRC and address errors. Therefore, any safety information can be transmitted securely, even in dynamically changing application scenarios. The safety specification through OPC UA through the client server has already been completed and will now be converted for FLC integration to Pub/Sub mechanisms, among other things.

Separating assets and functions

The FLC device model for the communication participants has also been redesigned. The participants are now called automation components (ACs). All devices have the same fundamental structure, regardless of whether they are controllers or sensors. Here, the asset and the function have been strictly separated. This separation means that functionalities can be viewed independently of the hardware in the future and, for example, can be easily combined in new products. Such a unit will be described as a functional entity (FE). The standardized FE will not know whether it is being operated in a modular or rigid structure, in a controller, or on a drive. On the other hand, the asset contains all hardware-related information, the device structure, Ethernet interfaces, and the firmware versions for the device or the device part.

The security mechanisms are based entirely on the mechanisms already defined in OPC UA. The few aspects that have not yet been implemented in OPC Security must become part of the OPC Security specification. The actual connection between the devices – the FLC connection – will therefore be established between functional entities that use existing OPC-specification Pub/Sub mechanisms. Connections to a participant will be managed in a connector group, which in turn comprises one or more datasets.

With this approach, different data, update rates, and communication participants can be mapped using one model. At the same time, the focus is currently placed on establishing a secure, multi-level connection. Both the asset and the functional entity can be checked for compatibility; there is a clear configuration phase, and then the switchover can be made to cyclic data exchange. Moreover, a corresponding status machine has been defined for both communication participants.

Function-specific integration models

In this first stage, the FLC initiative members have defined a reduced range of functions that are sufficient for transmitting standard and safety data between two controllers securely. The functions will be published in summer 2020. The second stage will focus on describing the functions not yet available that are necessary for transmitting data between controllers and devices, such as addressing, configuring, and extended diagnostics. Moreover, working groups are being established to develop function-specific information models for the first time, for example for motion applications, based on this model.

Here, the subject of TSN will always be addressed in parallel. It will be based on mechanisms that have long been defined in an OPC Foundation working group on TSN integration into the Pub/Sub model. Whether or not TSN, with its time guarantees, is ultimately used in a convergent network with numerous different communication systems will depend on the respective application. If the application has an unknown network load and short cycle times and yet demands low and guaranteed latency times, data exchange within the network must be switched over to TSN streams.

The FLC-initiative activities focusing on making OPC UA suitable for the field are in full swing and are beginning to bear fruit. A huge step forward will be made in field-related communication providing a great deal of innovation if the devices developed for OT can communicate in one language with OPC UA and at the same time be based on real-time capable Ethernet hardware with TSN in the future.

Robert Wilmes, System Management PLCnext, Phoenix Contact Electronics GmbH