DTM Opens HART to Modernization

Hidden complexity

Today’s industrial automation architectures are built based on many complex technologies and standards to provide the best in efficient manufacturing.

The FDT/DTM technology standard (IEC 62453) is one of them, working transparently behind the scenes and focused on industrial device management.

In real applications today, end users shouldn’t worry about the inner details of how the data exchange between field devices and asset management software works. Instead, they should be focused on monitoring and maintenance, optimizing production.

There is good news: behind both FDT-based host applications and DTM packages, there is a complex software communication structure, but it works like an abstraction layer, simplifying the data exchange process to a simple model based on a few basic concepts.

The FDT/DTM communication structure and user interface allow data access to all connected devices without the user knowing they are using the technology.

The sum is more than its parts

An FDT-based hosting (Frame) application is necessary. FDT Frame applications host device DTMs without the need for device or protocol-specific knowledge. FDT hosting or client applications handle lifecycle management, including design – topology and IO planning, configuration, commissioning, monitoring, diagnostics, parameterization, device replacement, and asset management – all services DTMs provide.

Frame applications may be stand-alone software packages, manufacturer-specific implementations that work as stand-alone software packages, or fully integrated frameworks embedded into engineering tools (DCS, PLC, Asset Management Applications, etc.).

Two Types of DTMs

Device DTMs:

Device-Specific DTMs: these software drivers represent a physical device type. A DTM can represent a single device, a family of devices, or a modular system. DTMs work as servers that supply device data to client applications running in the FDT hosting application.

Interpreter DTM: these files interpret different device descriptions and make them available in an FDT Framework application. There are third-party suppliers that offer Interpreter DTMs that can manage files such as Device Descriptors (DD), Field Device Integration (FDI) Device Packages, IODD descriptors, EDS, GSD, etc., and make them appear as device DTMs in the FDT/Framework device catalog.

Universal (Generic) DTM: These DTMs can work with all devices according to a specific communications protocol.

Communication DTMs:

Comm DTMs: these drivers represent hardware devices that require some application software to perform specific communication tasks and are protocol-dependent.

Gateway DTMs: these software drivers represent hardware that connects multiple communication protocols. It can be seen as combining a Communication DTM and a Device DTM.

We will use some application examples to show how these components can interact and work in real life.

We will begin with examples showing different ways to easily integrate HART field devices into control systems, thus allowing end users to gain access to the complete datasets available for these smart devices.

Single HART device with a Communication DTM

We will use PACTware Version 6.1 (FDT Desktop Solution) with the HART Communications DTM developed by CodeWrights GmbH and an Endress+Hauser (E+H) Promass 83 HART Coriolis Flow Transmitter.

The first step in a new FDT project is to select the adequate Comm DTM since this driver will enable the interaction between the field devices and the computer/configuration tool running the FDT framework.

Some popular communication protocols are supported by several Comm DTM options; some offer more functionalities, and others focus on simplicity.

Let’s look at an example: CodeWrights HART Comm DTM. This Comm DTM supports HART modems and multiplexers using either actual COM ports or emulated ones. The support of emulated COM ports is provided by the computer’s OS. At the same time, serial communication can be established on emulated COM ports using USB or Bluetooth technologies.

Once configured, you can either perform an automatic scan for HART-connected devices or, if you already know the device address, you can add it manually.

Then, there are two options: you can use a Universal HART DTM or a Device Specific DTM to gain access to the physical device assets.

Universal HART DTMs only allows ‘common practice’ HART commands to exchange information with the connected HART device. This means manufacturers with device-specific profiles (functionalities and features) outside ‘common practice’ HART profiles will not be accessible through the Universal HART DTM. Universal DTMs can be deployed for any protocol; recognize that they can quickly bring all devices supporting that protocol online but are tied to the ‘common practice’ profiling by the protocol.

To gain access to the full functionality of the connected HART device, you must use the Device Specific DTM developed by the manufacturer.

Using a Universal HART DTM or a Device Specific DTM depends on your application’s requirements and characteristics. Suppose you only need to get the primary process variable value and store the three remaining variables in the HART standard on an external database. In that case, a Universal DTM is sufficient.

But if you need access to the entire dataset of a complex device, using the Device Specific DTM is the best option.

Single HART device with a Communication DTM and Gateway DTM

We will use CodeWrights’ HART Comm DTM set in multiplexer mode for this example. With this configuration, we can add a HART multiplexer. HART multiplexers can sequentially poll up to 64 HART devices that are connected.

Several HART Comm DTMs are available on the market, some developed by the device manufacturer and tailored specifically for use with their devices. For example, the procedure would be essentially the same using MTL’s HART Comm DTM.

Gateway DTMs allow communication between the FDT Hosting Framework application and the HART devices through a single RS-485 connection to the multiplexers.

The multiplexers deployed belong to the MTL 4851/2 series. A serial server (a device that can convert RS-485 messaging to RS-232) provides an RS-485 connection that supports up to 32 MTL 4851 master multiplexers. Additionally, each one of the 4851 master multiplexers can connect to up to 16 MTL 4852 slave multiplexers. Up to 16 HART devices can be connected to each one of the 4852 slave multiplexers. Theoretically, this arrangement would allow users to manage up to 7936 HART devices with a single RS-485 connection.

Of course, in real-life applications, such a large installation would be separated into many parts to avoid single points of failure. However, the application concept is an example of the scalability that FDT technology can provide. In our example, three MTL 4851 and three MTL 4852 multiplexers are configured.

The next step involves connecting the Device DTMs to the HART multiplexers’ Gateway DTMs. We will use Flowserve’s Logix 3820 proportional valve actuators.

When we connect a Logix 3820 valve actuator to an MTL 4851 master multiplexer, we must use channel 2 since channel 1 is already connected to an MTL 4852 slave multiplexer. Actuators connected to the MTL 4852 multiplexers can be connected to all channels.

These valve actuators use Device Specific DTMs that allow users to perform extensive configuration and parameterization of the devices and enable end users to do remote diagnostic tests from the control room, such as Partial Stroke tests, which are mandatory in safety-related applications.

There is even one more advantage; you can add devices of any type, if already installed, by performing a copy-and-paste operation.

This modular expandability support makes using HART multiplexers an excellent example of the asset management capabilities that FDT technology can provide for large-scale applications, such as plant centralized valve management.

Integrating HART-IP and Wireless HART with FDT Technology

Over the years, the HART protocol has evolved. Newer implementations of the technology include wireless HART and HART-IP.

The most exciting aspect of these new technologies is that, although they incorporate state-of-the-art wireless communication protocols or embed traditional HART data packages into an Ethernet-based implementation, they are fully interoperable with legacy devices.

Therefore, users have the flexibility to connect a Wireless HART Adapter to an already installed HART device and provide it with a wireless connection to a Wireless HART Gateway that will pass its data to the control system after adequately converting it to a standard Industrial Ethernet protocol like Modbus TCP, EtherNet/IP or Profinet.

For example, we will use an Endress+Hauser HART-IP Comm DTM that will convert Wireless HART data generated by Wireless HART devices into the HART IO protocol to be used by HART-IP-compliant control systems.

Other Comm DTMs could communicate the data to EtherNet/IP-, Modbus TCP- or Profinet-based control systems if that option wasn’t available. A Gateway DTM, corresponding to the Wireless HART Gateway used in the application, would be responsible for creating and managing the Wireless HART mesh network composed of the HART field devices.

These Wireless HART devices can be either native or traditional HART devices equipped with a Wireless HART Adaptor. All these options are made possible using Device Specific DTMs.

Conclusions

In all the above examples, we were able to see how FDT technology helps solve industrial device management complexities by simplifying the process. Complexity is not the answer!

Tasks that used to require the use of large and very expensive handheld configurators can now be done with a cheaper PC running an FDT/DTM hosting framework application and with a more straightforward user interface.

It has always been challenging to use and take advantage of the complete set of features of smart devices. But with FDT/DTM, complex operations like data memory mapping and protocol translation are done in an invisible way to the end user.

Smart devices will continue to evolve with new features and functions that generate larger datasets. All of which will continue to benefit even more from this ubiquitous and flexible technology.