Technology
Initial FLC initiative results: OPC UA into the field
SOURCE: PHOENIX CONTACT
Field level communications (FLC) activities focusing on making OPC UA suitable for the field are in full swing. A step forward will be made if 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.
The first stage involved defining controller-to-controller (C2C) communication for standard and safety data which can then be extended to controller-to-device (C2D) and device-to-device (D2D) communication. 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 7. 2020
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
i n d u str i a l e th e r n e t b o o k
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
17
