Keywords

1 Introduction

Todays industrial automation applications are often realized as distributed systems. Such systems typically consist of multiple programmable logic controllers (PLCs) for the control of the application and remote input/output (I/O) stations at the field level for the integration of sensors and actuators. Industrial fieldbus systems (e.g. PROFIBUS, PROFINET or EtherCAT) are used to enable reliable communication between such devices in one automation cell [7].

The interconnection of these automation cells, the Machine-to-Machine communication, is a major objective in the context of Industry 4.0. In addition to other communication protocols, the platform-independent OPC OPC UA has become particularly popular for this purpose [12].

As well as eliminating the protocol break between the field level and higher levels, the application of OPC UA also at the field level could simplify the integration, configuration and management of field devices. Currently, field device information like process, diagnostic and parameter data are modeled differently from fieldbus to fieldbus and vendor to vendor. OPC UA represents an open ecosystem with tools for vendor-independent information modeling. It is expected that consistent information modeling and a uniform communication interface down to the field level offers the potential for increased Plug & Work capability across different manufacturers [12]. This work reviews the concepts of current specification work and investigates the impact on low-level device engineering at the example of a remote I/O application.

The paper is organized as follows. The focus of the technology review is noted in Sect. 2. Section 3 summarizes and discusses the basic concepts of initiatives that are relevant for the application of OPC UA at the field level. An exemplary low-level device integration is discussed in Sect. 4. Section 5 concludes the paper and reflects the findings.

2 Review Focus

Plug & Work and Plug & Produce are Industry 4.0 keywords that describe procedures that aim at reducing efforts by simplification and automation of the configuration and reconfiguration of distributed automation systems. In this context there are two general approaches [13]:

  1. 1.

    Dynamic orchestration of process steps that are offered by modular mechatronic subsystems [10].

  2. 2.

    Minimization of manual configuration efforts for real-time capable communication within a mechatronic subsystem [7].

A possible example is a conveyor system, which is composed of simple sensors and actuators. The integration of the conveyor system into a larger system refers to use case 1 and the realization within the subsystem refers to use case 2. OPC UA is a communication technology that is discussed in both approaches. This work focuses on approach 2, the communication within a mechatronic subsystem. In the following sections, relevant aspects for this use case are identified.

2.1 QoS Requirements of Distributed Applications

A basic requirement for the use of a communication technology at the field level is the guarantee of Quality of Service (QoS) for the communication. This guarantee is usually achieved by special Ethernet mechanisms [17]. In the past, OPC UA was criticized for its lack of real-time capability, which was compensated by parallel operation of OPC UA and established real-time Ethernet systems [10]. The manufacturer-independent real-time Ethernet standards in the set of Institute of Electrical and Electronics Engineers (IEEE) 802.1 Time-Sensitive Networking (TSN) standards are regarded as a solution to the problem, but the selection and configuration of TSN mechanisms is now perceived as a new problem [5].

2.2 System Requirements of Automation Ecosystems

Established systems have well-defined procedures and concepts for the efficient and error-free use of the system. In related work, the lack of such concepts and procedures is criticized for the application of OPC UA at the field level [5]. The following concepts are perceived as indispensable for established systems.

Offline device description::

Automation systems are virtually engineered before commissioning. In order to take manufacturer and device-specific parameters and interfaces into account, a virtual representation of this information is required without having the real device on site.

Standardized configuration approach::

A consistent manufacturer-independent configuration concept for endpoints and network infrastructure components is required. Especially the configuration of a network with Ethernet TSN features is currently associated with extensive configuration efforts [5].

Conformance testing::

To ensure an error-free, interoperable function, conformance testing and certification is required.

3 Specification Review

The specification work for the application of OPC UA at the field level converges at the Field Level Communication (FLC) initiative of the OPC Foundation. For conventional real-time Ethernet systems, the system specification also includes a specification for the use of system-specific Ethernet mechanisms. The OPC Foundation rejects proprietary Ethernet extensions and uses only Ethernet features from the IEC/IEEE 60802 Profile for Industrial Automation. Since the QoS mechanisms and their configuration are essential for the performance of an automation system, this profile is also reviewed in this paper.

System overview:

An exemplary communication system is shown in Fig. 1. The involved entities are separated by color according to the specification range of the OPC FLC and the IEC/IEEE 60802 working group. The management of the communication in the network is handled by the two respective configuration instances OPC UA FLC Connection Manager (CM) and Industrial Automation Management Entity (IA-ME).

Fig. 1
figure 1

Overview of an OPC UA based automation system. Entities specified by the OPC Foundation are marked in blue. Entities specified by the IEC/IEEE 60802 Profile are marked in green

Full size image

3.1 Field Level Communications Initiative

The OPC Foundation develops an open, manufacturer-independent architecture for extending the application of OPC UA down to the field level. Within the initiative, the specification is initially directed towards the realization of a minimum Controller-to-Controller use case. A specification release suiting this use case is planned for this year [9].

System concept:

The system concept is based on the modeling of Automation Components [3]. An Automation Component can represent a simple device, a machine or an entire production line. For modularization, an Automation Component can contain further Automation Components. This paper primarily deals with modeling at device level.

Device description:

Figure 2 shows that these components are strictly divided into an Asset Model and a Functional Model. The Asset Model contains a virtual object for each real, purchasable asset. The Functional Model represents the logical functions that can be provided by the assets. This strict separation corresponds to the concept of an Industry 4.0 component [14]. This model of an Automation Component is intended to be used during project planning as a device description in XML format and can also be retrieved during operation via the AddressSpace of the OPC UA server.

Fig. 2
figure 2

Overview of the FLC System Architecture. The architecture defines the modeling of a system in form of Automation Components. Each Automation Component is separated into a submodel of physical Assets and a submodel of logical Functional Entities

Full size image

Standardization and conformance:

The object-oriented information modeling of OPC UA is used to model Assets and Functional Entities. This enables a manufacturer-independent, uniform modeling of these objects. A minimal structure of these objects is prescribed by the FLC. For example, each Functional Entity contains a defined field for input, output and configuration data. Besides communication capabilities also simple device types and basic device functionality such as drives or I/O functionality are intended to be included as a series of profiles and conformance units [15]. Such items can be integrated into the existing OPC UA conformance test. Certification of profiles is performed in OPC certification test labs.

Communication configuration:

As visualized in Fig. 2, communication relationships are defined as connections between Functional Entities. These connections are intended to synchronize process data of the Functional Entities. These connections can be provided by the user with application-specific QoS requirements, such as a maximum delivery time for the process data.

For the complete automation system the communication configuration can be seen as a list of connected Functional Entities and can be regarded abstractly from the concrete devices. This list is used by the CM to aggregate and define concrete process data streams between endpoints. For a policy-based network configuration these data streams are requested together with the assigned QoS parameters as policies from the IA-ME. The endpoint configuration of OPC UA communication mechanisms above the Ethernet layer is performed by the CM.

3.2 IEC/IEEE 60802 Profile for Industrial Automation

The IEC/IEEE 60802 Profile for Industrial Automation defines an uniform feature set and an uniform configuration scheme for the engineering and commissioning of networks for industrial automation systems [2]. A special characteristic is that only Ethernet features from the IEEE 802 standards are used and that these operate independently of the communication protocol used above the Ethernet layer.

QoS requirements:

To meet the QoS requirements of distributed automation systems, the working group is currently discussing various standards and their features. Among them are established Ethernet standards as well as numerous new standards from the set of TSN standards. With regard to the performance indicators delivery time, synchronization accuracy and redundancy recovery time of the IEC 61784-2 standard for fieldbus profiles [1], the IEC/IEEE 60802 working group currently discusses Ethernet features that use similar mechanisms as the established fieldbus systems [4]. A comparable QoS performance can be expected.

Conformance testing:

The working group defines two conformance classes (ccA and ccB) for end stations and bridges. For each class mandatory and optional features are being defined [4]. The supported features of a device can be compiled into a device description by the manufacturer and independently be tested at Certification Authorities like the Certification Bodies of the IEC System for Conformity Assessment Schemes for Electrotechnical Equipment and Components (IECEE) [6].

Network configuration:

As illustrated in Fig. 1 the IA-ME is being specified for the configuration of the industrial network. It operates according to the centralized network configuration approach of the IEEE 802.1Qcc standard. Evaluation in testbeds has shown that the standard still has gaps with regard to a consistent workflow. A revision and extension of the standard is aimed at, with IEC/IEEE 60802 as the driving force, in the project P802.1Qdj [11].

Network abstraction for automation applications:

To enable a dynamic, manufacturer and application independent network configuration, a policy-based network configuration concept is discussed [8]. A policy-based network configuration does not consider the configuration by a user as the selection of a set of concrete parameters for concrete network technologies (like traffic shapers). Instead, it considers that a user defines a set of technology-independent rules, called policies, for configuration (like maximum allowed delivery time or maximum allowed frame loss count in case of a failure). This approach allows an abstracted view of the network [16].

An application controller, like the CM in the OPC UA automation system, requests and registers logical data streams including their QoS requirements as policies at the IA-ME. As the central instance for a network segment, the IA-ME holds a complete knowledge of all network components, the existing topology and all registered data streams, including the assigned policies, within this domain. With this knowledge the IA-ME derives the concrete configuration for the Ethernet features of all network devices within the domain. In a static system, the IA-ME can be disconnected from the network after commissioning. In a dynamic system, the unit remains connected to the network and can subsequently process topology or application changes.

3.3 Reflection

With regard to the aspects mentioned in Sect. 2, it can be summarized that essential concepts and requirements of established systems are conceptually considered and adapted in the specification work of both, the OPC FLC and the IEC/IEEE 60802 Profile for Industrial Automation.

The uniform use, configuration and conformity requirements of standard Ethernet features is discussed within the IEC/IEEE 60802 working group. With the currently considered standards and features, a performance comparable to established real-time Ethernet systems can be expected. The configuration concept allows an abstraction from the real network and thus speaks for a more dynamic and interoperable network. In practice, however, the concept cannot yet be implemented because the concrete Ethernet features required have not yet been determined [4] and the configuration concept still has gaps for a manufacturer-independent application [11].

The architecture of an OPC FLC system is based on a new way of modeling Automation Components. Suiting to this architecture, established system concepts such as offline device descriptions and conformance tests are conceptually adapted. A specification release, suiting for Controller-to-Controller use cases, is scheduled for this year. Controller-to-Device applications, on which this paper focuses, are covered in a later release [9]. The following Sect. 4 shows how the system concepts can theoretically be applied for the integration of low-level devices. Also here the abstraction from the real device speaks for higher possible interoperability and dynamics in the system.

4 Impact on Low-Level System Engineering

Up to this point, the general concepts of the current specification work were presented and evaluated with orientation on the properties of established systems.

As mentioned in Sect. 3.1, the FLC initiative initially focuses on Controller-to-Controller communication. In order to derive possible effects on the connection of simple devices, in other words the configuration of Controller-to-Device communication, assumptions on the process are made from now on.

It is possible that two different approaches for low-level system engineering can be implemented with the concepts of the FLC and IEC/IEEE 60802. As shown in Fig. 3, one approach starts with the selection of the concrete devices used and one approach starts with the selection of the required Functional Entities.

Fig. 3
figure 3

Possible engineering workflows for the integration of low-level devices into an OPC UA based automation system. The application of functional profiles allows to shift the selection and assignment of specific devices

Full size image

4.1 Device-Oriented Engineering

Using the currently specified offline device description, concrete devices can be integrated, parameterized and simulated at the beginning of a project. This approach corresponds to that of conventional automation systems and encourages a tight coupling between the automation application and the devices used. In terms of configuration efforts, this workflow is not expected to be significantly different from the one of established real-time Ethernet systems, for this reason it will not be discussed in detail here.

In conventional systems, it is also common to model the concrete network topology, including the network infrastructure components used, during project engineering. This allows communication planning and concrete QoS mechanism configuration without the real system. The use of a concrete projected network topology is supported as a use-case by IEC/IEEE 60802 and leads to a tight coupling between the automation application and the network infrastructure.

4.2 Function-Oriented Engineering

A cross-manufacturer specification of device and function profiles enables field device applications to be designed with a focus on their function and independently of their concrete implementation. An application engineer can define, use and simulate generic functions such as drives, I/O channels or integrated sensors during development without being tied to a specific device or vendor. In principle, this concept is similar to skill-based engineering, which is used in related work for motion-related components [18].

The following paragraphs illustrate how function-oriented application development can be applied to integrate simple I/O devices into a mechatronic subsystem as an example. The resulting subsystem could serve a larger system with its dedicated function, such as conveying. Simple sensors and actuators, such as a light barrier and a DC drive, are to be connected to a PLC via remote I/O systems in order to implement the conveyor application.

Function selection:

At the beginning of system engineering, the engineer selects and instantiates the Functional Entities that are required for the application. As shown in Fig. 4 in the Functional System Model, the Conveying Application requires four I/O channels from the function profiles.

Fig. 4
figure 4

Deployment of a Functional System Description to a real world system. The Functional Entity mapping of the generic system is used by the OPC UA Connection Manager to resolve and compose process data streams between the Endpoints. The resulting process data streams, including QoS policies, are then queried by the Industrial Automation Management Entity to set up the real network infrastructure

Full size image

Function configuration:

The function profiles shall specify mandatory and optional function parameters. These can be used, for example, to parameterize a generic analog output function to a defined voltage range. At this point, it is not defined which specific device implements the functionality, therefore the engineer still has all optional parameters to choose from.

Application development:

During application development the engineer defines the logic of the Conveying Application and how the application uses the process data of assigned Functional Entities. The application is therefore bound to the selected function profiles.

Device/Component assignment:

In the next step the application engineer defines that the mechatronic subsystem needs two I/O functions at location A and two I/O functions at location B. Accordingly, the engineer defines, as shown in Fig. 4 in the Functional System Description, two generic Automation Components which get assigned to implement the I/O function. These functional links can theoretically already be used as a communication description for the CM described in Sect. 3.1 and can be assigned with QoS policies for this communication. At this point, the application is not yet bound to specific devices from specific vendors and thus corresponds to a loose coupling.

Deployment to a real world system:

The deployment from the Functional System Description to real system components is shown in Fig. 4. This step of the assignment can theoretically be postponed to the end of the project engineering phase or even to the commissioning phase. This is the point in time, where the CM resolves the functional connections to real data addresses of the real devices and therefore derives the concrete endpoint communication configurations and stream requests for the network infrastructure.

At the end of the project planning phase, an engineering tool can compare and recommend automation components from different manufacturers. Based on the used functional parameters and the assigned QoS requirements only suiting components would be available for selection.

During commissioning, an engineering tool can compare the projected Functional System Model with the functional models of the real components available in the network and thus minimize the effort of communication configuration and manual device assignment.

4.3 Identified Effects

Section 4.1 has shown that an engineering workflow, similar to the one of the established systems, is expected to be realizable in the future with OPC UA. This is needed to ensure that the new system is accepted by experienced users of the established systems.

Alternatively, the function-oriented workflow from Sect. 4.2 can be considered. This workflow does not require a concrete modeling of the devices and network topology to be used. The definition of communication in the distributed system is reduced to the connection of Functional Entities and the definition of associated QoS requirements. Central configuration instances are used to resolve the abstracted communication connections on application and network level.

Reduced configuration effort:

The effort required for the exact reproduction of the devices used in engineering and for the exact reproduction of the network topology can be omitted. For example, the exact composition of modular remote I/O systems does not have to be reproduced using manufacturer-specific descriptions.

Loose coupling between application, devices and network infrastructure:

Besides the possible reduction of configuration steps, a loose coupling between the application, the used devices and the installed network infrastructure is achieved. This has the effect that the concrete devices can be selected more flexible and a manufacturer-independent device recommendation in the engineering system is possible. A loose coupling also leads to portability and higher dynamics in the resulting system. After commissioning, functionally identical devices can be exchanged or functions can simply be assigned to another device. Changes in the network infrastructure can theoretically be processed without manual intervention.

5 Summary

This paper has investigated the application of OPC UA with simple devices at the field level. This work was motivated by the idea that a uniform, cross-manufacturer specification for communication and data modeling can reduce manual configuration efforts.

The current discussions of the OPC FLC initiative and the working group for the IEC/IEEE 60802 Profile for Industrial Automation were reviewed to reflect the current state of application and network-related specification work. In addition to the adaption of established concepts, new system concepts were identified, such as a device and manufacturer-independent modeling of Functional Entities or a policy-based network configuration.

Effects of the new concepts on the integration of low-level devices in the engineering process, were derived by consideration of two workflows. One workflow following the device-oriented approach of established systems and an alternative workflow following a function-oriented approach.

In the function-oriented approach, the application is regarded as a Functional System Model abstracted from the concrete devices and the concrete network infrastructure. Besides the possible reduction of configuration steps, a loose coupling between the application, the used devices and the available network infrastructure is achieved. This leads to portability and higher dynamics in the complete system.

Critically considered is the fact that, in case of the abstraction of network topology and the concrete device model, a simulation of the overall system cannot be carried out as deterministically as with established systems that model the concrete network and devices. This could lead to the fact that problems occur during commissioning and cause additional effort. It is correspondingly a dilemma between flexibility and determinism.