1810-FCI-Supp-Fig-1-300
1810-FCI-Supp-Fig-1-300
1810-FCI-Supp-Fig-1-300
1810-FCI-Supp-Fig-1-300
1810-FCI-Supp-Fig-1-300

Software eases field device integration

Nov. 6, 2018
Information models and OPC UA power programmable paths to protocol independence and the installed base

Field devices can provide a wealth of information to improve maintenance and operations of existing plants. Along with the opportunity to make intelligent decisions about how best to maintain equipment to avoid unplanned shutdowns, field device data can be analyzed to extract useful information and used to improve plant operations.

So, many companies are looking for opportunities to gather more data and add more field devices. But there are many challenges in existing plants, where it’s difficult to get to the equipment, hard to extract information from smart devices, and a problem to integrate new devices to existing systems.

"We need to use data provided by field instrumentation to get information, use data analytics and artificial intelligence to process that information, and thereby generate customer benefits such us efficiency, productivity, flexibility, quality, etc.," says Thomas Hahn, chief expert, software for Siemens AG and vice-president, OPC Foundation (Siemens is a founding member of OPC Foundation).

"Much of the data available is currently not used, because control systems typically are the barrier to access the information," adds Achim Laubenstein, technology director, FieldComm Group. "Therefore, we need a solution that is much simpler, protocol-independent and non-proprietary."

Hahn explains, "A protocol- and system-independent software architecture is needed to secure the benefits of digitalization, Industrie 4.0, the Industrial Internet of Things (IIoT), Made in China 2025 and similar initiatives. These efforts require devices and systems that can cross-file and do other tasks, which in turn requires IoT interoperability and the ability to describe those devices and systems. We believe interoperable, scalable and secure OPC UA is a promising candidate for this job because it can work with companion specifications, and it networks with different partners, including FieldComm Group."

OPC UA provides the framework

Software systems like FDI, based on OPC UA, support a new level of innovation with data modeling that allows disparate protocols to behave uniformly at the application software level. "FieldComm Group now maintains the tools and components for this very important FDI initiative, and OPC Foundation continues to work with them to extend and maintain the deliverables—both specifications and technology—for vendors to meet the needs of process automation," says Tom Burke, president and executive director, OPC Foundation.

OPC Foundation is also working with FieldComm Group to develop a companion specification that will allow OPC UA to consume data from all vendors’ field devices, with the objective of making it available in the cloud. Along with NAMUR and Industrie 4.0, "We expect additional organizations will be part of this important initiative," Burke says. "All the rallying around the importance of standardization across process automation devices is really being driven by the end users, as illustrated by recent activities from OPA Forum and NAMUR."

Figure 1: The OPC UA architecture supports complex information models from the OPC Foundation, its collaboration partners and non-members. 

The OPC UA information model architecture (Figure 1) is fairly simple, yet supports complex information models from the OPC Foundation, its collaboration partners and non-members. "What’s most interesting about this architecture is that you don’t have to be a member of the OPC Foundation to develop a companion specification and take advantage of the rich service-oriented architecture of OPC UA,” Burke says.

OPC Foundation has a well-defined OPC UA meta-model that defines how data models are described from a syntax and syntactic perspective. The meta-model is the base architecture for OPC UA, describing all the native OPC UA datatypes, which themselves are structures that have both data and metadata.

Built on top of the OPC UA meta-model, the built-in OPC information models provide capabilities such as historical data access and standardization of devices, data access, alarms and conditions. Then the companion specifications, which are built by collaboration partners for their organizations’ information models, build on top of the OPC UA meta-model but also have the ability to take advantage of the standard OPC built-in information models. Vendors can build vendor-specific extensions on top of the OPC UA meta-model and extend the capabilities of the companion information model specifications.

"Thanks to FieldComm Group’s use of the OPC UA standard, Iconics’ HMI/SCADA and IoT-enabled software can easily connect to the wide variety of devices that leverage FieldComm Group’s technology,” says Russ Agrusa, president and CEO of Iconics. “Such connectivity to every ‘thing’ in the Industrial Internet of Things (IIoT) is critical for today’s manufacturing, energy management, industrial and building automation systems."

FDI uses CDD and semantic ID

Of course, OPC UA is aided by one of the FieldComm Group’s three primary standards, namely FDI, which delivers specific device type information within a protocol-independent OPC UA information model. FDI provides device data by using standardized semantic identifiers (Semantic ID) that are part of Common Data Dictionary (CDD), which is based on international standards, such as IEC 61987 or even ecl@ss that defines protocol-independent semantics, according to Frank Fengler, head of Device Integration, Measurement and Analytics at ABB.

"Semantic IDs are located on web pages and indexed, so they can be found in the CDD, just like database identifiers. This gives users a way to find parameters in their devices and applications, and determine how they’re working,” explains Fengler. “By using semantic IDs, users know exactly what a parameter is doing, how it’s behaving, and the meaning behind it."

Without knowing any internal field device item names, Semantic ID provides generic access to data items and adds semantic contents to the raw data values read from and written to the field devices. Fengler adds that Semantic IDs help to get data up from the physical layer to higher levels like cloud-computing services, but because they’re protocol independent, any protocol such as HART or Profibus can be used. "Once the data reaches the application layer or the cloud, its name and meaning is the same," he explains. "This provides benefits for the user interface, as well for machine-to-machine communication. IEC 61987 has been available for more than 10 years, and Semantic IDs are several years old, too, but now organizations like NAMUR are using them to put all the pieces in place for process automation."

PA-DIM brings it together

"OPC Foundation participated in the FDI standard, and this was a significant achievement, as we developed the FDI specification with a multitude of DCS vendors funding the initiative for process automation,” Hahn says. “OPC Foundation is now working on a very special initiative with FieldComm Group addressing process automation, which includes a multitude of vendors working with organizations like NAMUR Open Architecture (NOA) and Industry 4.0 (RAMI 4.0) to achieve standardized process automation device normalization, allowing flexibility in a multivendor environment."

The initiative, by FieldComm Group, OPC Foundation and Profibus/Profinet International, will jointly standardize and specify the information model for process automation devices (PA-DIM). It’s based on the NAMUR requirements on Open Architecture (under development), Self-Monitoring and Diagnosis of Field Devices (NE107), and NAMUR standard
device—field devices for standard applications (NE131). PA-DIM covers use cases like:

  • Provide/receive information to/from HMIs, information apps, reporting apps, etc.
  • Provide information for inventory management and remote monitoring applications
  • Provide information that is used by real-time control applications
  • Device configuration and parameterization
  • Provide interfaces for configuring the security of a device and for monitoring its current
  • Provide information for device dashboards

PA-DIM is protocol-independent, thus allowing development of software solutions that are independent of automation supplier systems. The protocol-agnostic unified information model will allow software applications to access device information without additional mapping or protocol-specific knowledge. "They just need to follow the standardized PA-DIM," says Laubenstein.

For existing devices, PA-DIM can be set up as part of the FDI information model server through the respective device description (EDD). Fieldbus-specific information will be mapped to the defined standard information model (PA-DIM) by the FDI server (Figure 2).

Figure 2: When set up as part of the FDI information model through the device description (EDD), fieldbus-specific information will be mapped to the standard PA-DIM model by the FDI server.

"OPC UA provides the possibility to describe and use in different domains—the ‘how.’ The ‘what’—whether it be companion specifications for field devices, machines etc.—should and must be done as a responsibility of industries, industry association, etc.,” says Hahn. PA-DIM is an example of industry associations taking that responsibility.

"Having a standard where all process automation devices of a certain class agree to the same syntax and semantics of data and metadata will facilitate complete system software solutions,” says Burke. “Not only does it facilitate operations like training and preventive maintenance, we will now be able to have true plug-and-play interoperability in a multi-vendor environment, no matter what vendor a specific field device comes from. We’ll have a standard for all field devices and will have total interchangeability across vendors."

"We now have a complete ecosystem leveraging OPC UA technology and PA-DIM that allows field devices to integrate directly into higher-level applications, including IOT-aware applications, edge devices and cloud-based applications," Burke concludes. "We’re now able to truly break down the wall between OT and IT, with standardization of process automation devices that will facilitate this convergence with protocol and device independence.”