FDT is an international, IEC-62453 open standard for industrial automation integration of networks and devices, harnessing IIoT and Industrie 4.0 for enterprise-wide connectivity.
High-level FDT IIoT Server - FITS™ Architecture
FDT IIoT Server (FITS™) consists of FITS™ Core Server which is platform independent and is built on top of frame application business logic that manages all the DTM instances. FITS™ Server may contain optional components mentioned below.
- OPC UA Server: FITS™ OPC UA Server exposes the FDT OPC UA Information Model via OPC interface for any generic or FITS™ aware OPC UA Client. FDT OPC UA Server Information Model contains the internal client component which interacts with the FITS™ Core Server to fetch the DTM related information to map it to the FDT OPC UA Information Model.
- FITS™ Web Server: FITS™ Web Server provides the web interface for the remote web-enabled FDT client application. It is also possible to have the custom application built based on the FITS™ web server using AppData Services.
Asset health as per Namur NE 107 recommendation
NAMUR has identified that the status of the devices is important to help the plant operators run the plant better along with measured process values. This requirement is captured in their NE107 recommendation defining that detailed device-specific diagnostics are summarized as four simple status signals (Failed, Out of specification, Maintenance Required and Check Function). These signals ensure that the plant operator is not inundated with device troubleshooting details and cryptic error codes. The NAMUR NE107 recommendation harmonizes the display of status for devices.
Monitoring asset health using FITS™ and OPC PUB/SUB mechanism
Disparate network and devices in the plants are connected to the FITS™ Server and are modelled in the FDT OPC UA Information model as per the specification. DTM instances in the Frame application business logic will be fetched by the FITS™ Core Server while client component in the FDT OPC UA Server Information model will use this information to build the FDT OPC UA Server Information Model.
Mapping of FDT Interfaces to OPC UA DeviceHealth Status information
FDT OPC UA Server shall support access to both offline and online information. However, DeviceHealth Status is applicable only for Online Devices. Below table maps the OPC UA Object Type for DeviceHealth information to FITS™ Server Interface. As per FDT 2.5 specification, ReadDevice Status method available in the OnlineOperation interface is an asynchronous operation. FDT also provides StaticFunction GetDeviceStatus to return the DeviceHealth values which can also be mapped to OPC UA DeviceHealth attribute.
Along with DeviceHealth Status, it is also possible to include Device Diagnostic Information and map it to the OPC UA Information Model. However, this has not been discussed in this position paper.
OPC UA Publisher Module for FITS™ OPC Server
This position paper proposes the OPC UA Pub/Submodel on top of FITS™ OPC UA Server to support pushing the DeviceHealth Status in the event of status change instead of OPC UA Client polling the DeviceHealth information on time-based interval. OPC UA Pub/Sub Communication Model is based on a well-known Publisher-Subscriber design pattern where publisher and subscriber are loosely coupled.
With Pub/Sub Communication Model, OPC UA application does not exchange the information directly using the request-response mechanism, instead, OPC UA publisher module sends the message/topic to the Message Oriented Middleware (Broker). Message Oriented Middleware could be software or hardware infrastructure which supports sharing the information between publishers and subscribers. OPC Pub/Sub Communication mechanism supports both broker-less and broker-based middleware.
The broker-less mechanism uses the UDP multicast whereas in broker-based mechanism uses the standard messaging protocols like AMQP or MQTT to communicate with broker.
OPC Pub/Sub Communication Model supports two types of DataSet Messages - Key Frame and Delta Frame messages. A key frame DataSetMessage includes all fields of the DataSet whereas Delta Frame message includes only subset of fields that changed since the previous DataSetMessage.
Benefits
OPC Pub/Sub Model enables the Asset Health Monitoring Applications (Subscriber) to pull the interesting data i.e. topics from the cloud platform without any knowledge about the FITSTM Server (Publisher) of the data. However, these messages will be associated with its metadata information which enables the subscriber to interpret this information correctly.
FITSTM Server (Publisher) and Asset Health Monitoring Application (Subscriber) do not have to be directly addressable. They can be anywhere in their own networks as long as they have access to the broker.
Fan out can be handled against a very large list of subscribers, multiple networks or even chained or scalable brokers. Publisher and subscriber lifetimes do not have to overlap. The publisher can push data to the broker and terminate. The data will be available in the subscriber application which can be accessed later.
OPC Pub/Sub Model is independent of the cloud platform and messaging protocols like AMQP or MQTT. This enables the existing application to easily adopt this technology with less investment.
Conclusion
FITS™ Server (Publisher) can push the data to the broker only on change of status which brings huge benefit in reducing message exchange between the Asset Health Monitoring Application and the FITS™ Server.
FITS™ OPC UA Server supports Client-Server based Request-Response Communication mechanism between the OPC UA client application and generic client application. Combining the OPC Pub/Sub communication mechanism with FITS™ OPC UA Server brings huge benefit in reducing the communication traffic between the Asset Health Monitoring Application and FITS™ OPC UA Server application, making it scalable to IIoT requirement.
Apart from Asset Health Monitoring, this position paper can also be extended to support Loop & Control Valve Diagnostics, Equipment Diagnostic, KPI Monitoring and Dashboard Application etc.
Dharmaraju Balasubramanya, Senior Software Architect at Utthunga Technologies
