In order to compete and win in a global, competitive, fast moving world with increasing demands, all kinds of technology must be harnessed and put to good use. But without an effective approach to enterprise integration, all these technologies remain in silos and won’t be useful to the business.
The following article describes how technology collaboration between two leading open, automation industry standards organizations is changing the paradigm for integrating control systems, applications and devices within a unified architecture – all aimed at optimizing information exchange throughout the industrial enterprise.
Background
As two leading open, industrial automation standards organizations, FDT Group and OPC Foundation are working together to provide greater access to critical information throughout the industrial enterprise. FDT is the established integration standard, globally adopted with hundreds of thousands of FDT/FRAME™-enabled control and asset management systems and tens of millions of FDT/DTM™-enabled field devices, while the OPC Unified Architecture (UA) provides an infrastructure to make enterprise information available to thousands of other applications and platforms.
The FDT standard intersects the variety of networks attached to intelligent instrumentation and the higher-level systems that interact with these devices. It establishes an open, modular and holistic automation architecture that adapts to the changing requirements of suppliers and end-users. FDT incorporates a plant hierarchy based on a physical network topology coupled with a logical topology. The technology supports all the major networks employed in process, hybrid and discrete automation, and is adaptive to future networks as the industry demands. This approach makes it possible for FDT-based systems to transparently tunnel through disparate networks to gain access, and talk with any end device.
OPC UA, on the other hand, is focused on providing complete information modeling that allows industry stakeholders to take advantage of a service-oriented architecture enabling previously disconnected devices and applications to work together in a seamless manner. For example, OPC UA enables client applications to connect to server applications without understanding the syntax and semantics of the data compiled into the client application. This approach is all about simple discovery of the capabilities of the server, and efficiently leveraging its services and data.
Meeting today’s data challenges
In November 2016, FDT Group and OPC Foundation announced the release of an FDT for OPC UA companion specification/annex for information modeling. This was an important milestone for standard integration of information provided by FDT/DTMs into the OPC UA information model.
Recently, the FDT Group worked with OPC Foundation to enable native integration that’s supported both by OPC UA and FDT 2.x technologies. Instead of writing this integration capability into the FDT specification, the two organizations collaborated on a companion specification describing how to implement an OPC UA Server in an FDT/FRAME as part of the emerging FDT IIoT Server™ (FITS™) architecture. Most of the companion specification is devoted to outlining the data mapping between the two sides.
The FITS solution takes advantage of the FDT for OPC UA companion specification in enabling sensor-to-cloud, enterprise-wide connectivity for industrial control systems. It combines native OPC UA integration, web services and rich control network interoperability to optimize connectivity and information exchange for the next generation of automation. The solution also features robust layered security addressing all components of the server architecture.
Progress on information integration
Standard integration of information provided by FDT/DTMs into the OPC UA information model is essential for device diagnostics, configuration and remote asset management, as well for integration with higher-level business applications. This document defines an OPC UA Information model to represent the FDT architectural models. This allows an FDT/FRAME or FDT IIoT Server to expose project structure and device specific information through standard OPC UA mechanisms. While this mapping is an essential activity to achieve interoperability, it is completely transparent to the end user.
As part of the integrated FDT/OPC UA solution, the built-in OPC UA Server can read and write device information. Any OPC UA Client can access the FDT/OPC UA Server and obtain data as long as it has the right credentials. There are a multitude of possible clients within this architecture.
From the FDT standpoint, the aforementioned approach exposes its project tree to the OPC UA Client so that it can see what devices are accessible. As users click on each device, they can view and access its specific attributes and information.
Figure 1: Screenshot of FDT OPC UA Client showing the project tree exposing what devices are accessible.
OPC UA provides a uniform information exchange methodology between applications, whereas FDT provides network/device configuration and access to devices. The combined FDT/OPC UA approach enables unification of system engineering, configuration and diagnosis in Industrie 4.0.
The capabilities for OPC UA integration were introduced with the FDT 2.0 specification. Additional enhancements were made with the subsequent 2.1 version and will be strengthened in the 2.5 standard (also known as FITS), which is set to deploy in the 4th quarter of 2018.
Optimizing network communication
We all know that process control and discrete automation systems, field devices and other electronic instruments are networked so they can exchange information. But how does that information get where it’s supposed to go?
Within a traditional client-server (i.e., request-response) communication model, a client computer or software requests data or services, and a server computer or software responds to the request by providing the data or service.
For example, when sending a spreadsheet to the printer, the spreadsheet program is the client. Its request for printer services goes to the print server, which responds to the request and allocates resources for printers on the network. The print server handles all the client requests for printing, making sure the spreadsheet and other pending print jobs are all completed in an orderly way.
A different way for systems and devices to communicate on a network is called publish-subscribe messaging (i.e., a form of asynchronous service-to-service communication). In this model, any message published to the network on a topic is immediately received by all of the subscribers to the topic. Clients that publish the data send it only when the data changes. Clients that subscribe to the data automatically receive it from the server, but again, only when it changes.
The publish-subscribe extension enables public subscriptions for larger numbers of devices. The client-server model has drawbacks in this case, as a large number of connections would have to be established, each client would need to provide memory for storing the connection information, and high processor load would be generated in the server for encoding the individual messages per established connection.
OPC Foundation recently announced the release of a publish-subscribe (aka, “PubSub”) specification to make the OPC UA standard compatible with emerging IIoT applications. Its mission is to provide a mechanism for publishing server data to many clients. With OPC UA PubSub, applications do not directly exchange requests and responses. Instead, publishers send messages to a message-oriented middleware, without knowledge of what, if any, subscribers there may be. Similarly, subscribers express interest in specific types of data, and process messages that contain this data, without knowledge of what publishers there are.
Among other things, PubSub allows peer-to-peer communication between industrial controllers, and between controllers and human-machine interfaces (HMIs). The peers are not directly connected and do not even need to know about the existence of each other. It also allows things like asynchronous workflows and OPC UA Servers to stream data to applications hosted in the cloud.
Improving information exchange
Thanks to ongoing FDT/OPC collaboration, members of the industrial automation industry have a choice of methodologies for implementing a network communication model that suits their specific needs. Both client-server and publish-subscribe models are included in the FDT for OPC UA companion specification.
With the client-server approach, the client goes through OPC UA to access current data values but must keep asking to verify the information. This is done either through a program in the OPC UA Client or by having an individual do a manual “refresh.”
Alternatively, the emerging FITS architecture can employ a publish-subscribe methodology allowing sensor, network and topology information to permeate the enterprise, including mobile devices, distributed control systems (DCSs), programmable logic controllers (PLCs), manufacturing execution systems (MESs), enterprise resource planning (ERP) systems, the cloud, IIoT and Industry 4.0.
The publish-subscribe methodology eliminates the burden of request-response communication. Clients essentially say, “I’m interested in a particular piece of data, so please tell me whenever it changes.” Multiple clients can subscribe and receive notifications at once. The server will automatically notify all the subscribed clients when the specified information has changed according to the pre-defined parameters. This approach has been proven to save valuable system bandwidth. Think of a child in the back seat of a car asking, “Are we there yet?” The child is now quiet until something changes (i.e., the parents in the front seat announcing, “We’re here!”).
A typical use case for the publish-subscribe communication model is employing OPC UA and an FDT/DTM to monitor device health. By requesting notification only on changes in device condition, system and network resources are freed from continually polling the device to ascertain its health.
One of the key advantages of the FDT architecture is OPC UA is an easy plug-in. There’s no need for changes to the communication, gateway or device DTMs. The FDT standard is robustly written so that it is only necessary to intercept communications at the right points within the FDT/FRAME or FDT Core Server in FITS to fully enable OPC UA. Plant or factory personnel can see all the networks on the server, as well as all FRAME applications and devices with DTMs through OPC UA. In addition, developers writing communication or device DTMs don’t have any added requirements to support OPC UA.
Figure 2: FDT IIoT Server (FITS) topology
In the classic automation architecture, a DCS or PLC is located near the middle of the hierarchy and communicates with all of the upper level business systems like MES and ERP. This activity is completely eliminated with the integrated FDT/OPC UA solution.
Benefits to industrial enterprises
As described in this article, the FDT/OPC UA information model was designed to provide expanded integration capabilities along with ease of implementation. When industry stakeholders implement OPC UA, however, they may have challenges using the technology within their automation architecture due to the data trafficking role of the PLC or DCS. This could require the assistance of a process or control engineer to expose the required data from the control system to OPC UA.
FDT/OPC collaboration is intended to eliminate the typical constraints in industrial communication. When most engineers think of OPC UA, for example, they envision it running at the Ethernet level – but some kind of device hardware is needed to reach a compatible network. With the addition of FDT technology, users can take advantage of their existing infrastructure, thus bypassing any PLC or DCS that’s in the architecture and communicating directly with end devices through OPC UA. As long as the device has a DTM in the FRAME or Server, the user will be able to access the device and all of its data through OPC UA.
If the user already has an FDT/OPC UA-enabled application in the architecture there is no need for additional configuration other than assigning security credentials. At that point, every bit of data inside FDT is accessible through OPC UA. Engineers are no longer faced with modifying ladder logic or writing rules for DCS systems. Thanks to an OPC UA Server inside an FDT application, all of the information is available. Nothing is held back, and there is no need for extensive configuration work to get the desired data. If a DTM is present, every bit of data about a device is available through the application.
Furthermore, IT departments utilizing MES or ERP systems don’t have to consult with a PLC or DCS programmer every time they want to access specific types of control data. They can just browse the server structure and find the necessary information. IT personnel also have a choice of ways to interface with the FDT Core Server.
OPC UA is a known entity in the IT world with available tools to enable full connectivity and easy integration. As an option, FDT Web Services can be used to write Apps to support maintenance or engineering organizations. Users can access FITS through web sockets to browse project structures and perform other tasks.
Conclusion
Industrial organizations can now bring systems, applications and devices together in a unified architecture to exchange information throughout the enterprise. With integration of the FDT and OPC UA standards, they have an optimal approach for multi-network intelligent device configuration and data interchange.