Functional safety and high availability are at the forefront of the classic automation pyramid. While this ensures long-term operational reliability, it also makes it difficult for process automation to adapt new technologies quickly and cost-effectively and, above all, to participate in the digital transformation. Particularly in view of the rapid development of IoT and Industry 4.0, this 'inertia' is perceived as painful by those involved. To counteract this, NAMUR began designing an open system structure in 2016, the so-called NAMUR Open Architecture (NOA).

The NAMUR Open Architecture

NAMUR's NOA pyramid: The concept enables innovative solutions for both new and, in particular, existing systems, as the core of process automation remains largely untouched.

© Wetcon

The aim of the NOA is to expand the existing automation structure so that flexible implementation of Industry 4.0 is possible for new and existing systems. The new methods should be based on existing, open standards, not jeopardize the safety of existing systems, enable rapid and affordable implementations and be used in addition to the proven automation architecture.

NOA separates monitoring and optimization tasks from the core automation. The core automation data is transferred to the system world for monitoring and optimization tasks via open interfaces. OPC UA was selected as one option for such an open interface - an important component for information exchange in Industry 4.0.
important component for the exchange of information. Additional sensors for monitoring and optimization tasks can be easily integrated into the open system world, while the core automation remains largely unchanged. This opens the door to the cloud for companies and makes it possible to manage data and devices remotely, gain insights or use machine learning.

So much for the theory. But what solutions exist today to put NOA into practice?

FITS solution from the FDT Group

A concrete approach is provided by the FDT Group, an international non-profit organization whose main purpose is to provide an open interface for the integration of field devices with engineering, automation and resource management systems as an IEC standard. The FDT (Field Device Tool) specification divides an automation solution into three components and defines their areas of responsibility and the software interfaces between them:

• a software application such as an asset management or process control system (also called FDT framework application)
• Device drivers that take on the role of the 'digital twin' of a field device (Device Type Manager, DTM)
• Communication drivers that represent the hardware required to connect the field devices to the automation software

The tasks of the frame application are mainly the management of the field device instances, the storage of the respective project data, the user rights management, the device catalog management and the scanning for connected hardware. The DTM device drivers provided by the device manufacturers contain user-friendly, graphical user interfaces with which specific device functions and parameters can be accessed. The DTM can be opened, controlled and closed again by the frame application.

Usually, the frame application, device DTMs and communication drivers are simply installed on a notebook, which can then be used to configure and parameterize a wide variety of field devices without having to install several proprietary tools from the manufacturer. The first FDT specification was published back in 2001 and FDT is now widely used internationally as a device integration technology.

In 2018, the FDT Group announced the introduction of an Industrial Internet of Things (IIoT) server architecture called FDT IIoT Server - FITS - which is intended to provide a flexible platform for various IIoT-based solutions. This development was based on extensive surveys of end customers and manufacturers - key issues included the integration of OPC UA and the use of mobile devices for field device management.

The platform-independent approach and the use of .NET Core enables the application to run on Microsoft, Linux and macOS operating systems and forms the bridge from previous FDT basic installations to support for IIoT and Industry 4.0. At the heart of the FITS architecture is a central FDT server to which an OPC UA server and a web server are connected. The OPC UA server provides authenticated OPC UA clients with access to DTM data, while the web server provides browser-based clients such as smartphones, tablets or PCs with web UIs provided by the DTMs. Apps can also be supported. The FITS standard is due to be launched at the end of 2019.

OPC UA as a basis

Pactware OPC UA plugin with Azure IoT Central connection. A plugin adds the functionality of an OPC UA server to Pactware, which can be used to read process values and transfer them to various cloud solutions.

© Wetcon

Both the NAMUR and the FITS solution are based on the OPC Unified Architecture, or OPC UA for short. The OPC UA protocol enables standardized, secure and reliable platform-independent data exchange between devices, machines and services from different industries. It is used in components in all industrial sectors - from sensors, actuators and control systems to manufacturing execution and enterprise resource planning systems and the cloud.

It is generally recognized as a key communication and data modelling technology in Industry 4.0 - the Reference Architecture Model for Industry 4.0, for example, has named OPC UA as the only recommendation for implementing a communication layer. The cloud computing platforms Microsoft Azure and Amazon Web Services already offer OPC UA adapters that connect to an OPC UA server and transfer relevant information directly into their IoT solutions. There is currently a third-party component for Google's cloud computing platform that fulfills this purpose.

DI and FDT OPC UA Model

OPC UA information models contain definitions of types and their relationships with each other, similar to object-oriented programming. There are more generic information models such as the information model for devices (OPC UA Device Integration Model). This defines how the information of a device is mapped to OPC UA objects, methods and variables, regardless of its underlying protocols. It also allows connected clients to configure, operate or troubleshoot devices without having to know the device internals. The OPC UA Device Integration Model also serves as the basis for other, more specialized information models, such as OPC UA for Analyzer Devices (ADI) or Field Device Integration (FDI).

The OPC UA Information Model for FDT Technology, which maps DTM information according to OPC UA, was developed specifically for FITS in a collaboration between the FDT Group and the OPC Foundation. Various simple use cases were selected and taken into account, which can be combined to allow more complex use cases.

Pactware advances to OPC UA server

As an FDT framework application, Pactware, like FITS, contains an FDT server component via which the device DTMs are addressed. Pactware also provides a plug-in system with which its function can be extended almost at will. This provides an entry point for an OPC UA server. But what does the development of an OPC UA plugin for Pactware look like in detail?

The device parameters can be read or modified via various FDT interfaces provided by the device DTMs. These would be, for example

• IDtmSingleDeviceDataAccess for reading and writing online device parameters
• IDtmSingleInstanceDataAccess for reading and writing offline device parameters
• IDtmParameter as a supplement for the offline device parameters
• IDtmOnlineParameter for uploading and downloading device parameters.
  

'Quickstart Reference Client' from the OPC UA .NET stack, connected to the OPC UA Pactware plugin. The open-source OPC UA client shows here a section of the OPC UA nodes provided by the plugin using the example of an optical distance meter.

© Wetcon

The Pactware plugin can address these FDT interfaces and provide the device parameters and other data and functionalities in its own OPC UA address space on the OPC UA server. As a trigger for reading and providing the data of a field device, it is possible to register for certain Pactware events within the plugin, for example when a project is opened or when a new DTM is added. In the latter case, the data and device parameters of the loaded DTMs are read out and added as objects in the OPC UA server. According to the Device Integration Model, the device objects are subordinate to a DeviceSet node and each provide additional subtypes and variables - the device parameters are located as variables under a ParameterSet node. The actual value of a device parameter is then read out via the corresponding DTM interface at the time when an OPC UA client requests it.

The OPC Foundation offers an official open-source .NET stack that contains reference implementations of OPC UA clients and servers as well as various sample applications. This can be used to develop OPC UA clients and servers. An open source implementation of such a Pactware plugin, which is based on this and already available, and which also implements the aforementioned OPC UA Device Integration Model, can be found at https://github.com/wetcon.

Connection to Microsoft IoT Central

Transmission of the measured values of an IO-Link distance meter to Azure IoT Central. The measured values are periodically read out via the OPC UA server and transferred to the cloud as telemetry data. Charts show their development over time.

© Wetcon

An OPC UA client can now read out the process value of a field device at regular intervals and transfer it to Azure IoT Central, for example. IoT Central is an IoT SaaS (Software as a Service) solution with a focus on simple operation, security and scalability that requires no cloud knowledge. Devices and their process values and properties can be created via a web-based user interface. Various protocols can be used to transfer the real device parameters to IoT Central, including MQTT or HTTP. Microsoft provides SDKs for various programming languages for this purpose. Step-by-step instructions and source code for console applications that transfer field device parameters to Azure IoT or AWS IoT are included in the open source implementation.

Alternatively, Pactware can also be used to transfer device parameters directly to the cloud without an OPC UA server via an additional plugin. The 'fielddevice.cloud' product takes exactly this approach. Compared to IoT Central, no explicit creation of device information is necessary there; in addition, the possibilities for visualizing the device data through user-specific Microsoft Power BI reports are more diverse.

Author
Jonas Jelli works as a software architect at Wetcon in Senden near Neu-Ulm.