Over the last couple of decades there has been a rapid growth of industrial Ethernet and wireless networks in process manufacturing plants and automation facilities. As a result, data exchange within a facility and even throughout global corporate networks has become commonplace. The separate information hierarchy levels outlined in the ISA-95 model, which are related to process data exchange within a manufacturing facility, have started to coalesce.
In prior years, data and information that needed to be exchanged between the lowest plant floor levels 0-2 and the upper enterprise resource planning (ERP) level 4 required expensive manufacturing execution system (MES) products or custom coding-and oftentimes both (figure 1). This free flow of information has introduced a new set of ubiquitous terms, standards, and phrases, such as Industrial Internet of Things (IIoT), smart factory, cloud automation, and Industry 4.0.
This article outlines how the flow of process and diagnostics data from smart highway addressable remote transducer (HART) digital field instruments can easily be shared with mid- and higher-level control, asset management, and data information systems without having to upgrade expensive process control interface equipment. Additionally, it will review features and considerations of devices that enable this data sharing.
Figure 1. ISA-95 Model showing control and information levels
Plant of the future
The typical process control model that has decision making for the process at the local or centralized level by programmable logic controllers (PLCs) or a basic process control system (BPCS) is quickly changing. These systems were never intended to deal with the amount of data they would have access to in the near future. There are certainly newer ERP, MES, and asset management systems that collect some of this data now, but the more critical challenge that local manufacturing facilities face is manpower.
Streamlining costs and overheads has left many manufacturing facilities with just enough personnel to keep the plant running, so facilities no longer have the extra time, personnel, and resources required to analyze the data. For this reason, third-party companies, and even some larger process control vendors, offer leasing or annual agreements for collecting, storing, and analyzing all sorts of process data. This data is part of a larger predictive analytics strategy that not only can forewarn operators of impending problems but is also being used to optimize the process itself. This type of cloud automation looks to gather as much data as possible to reduce both operating costs and capital expenditures for future plant builds.
So, the challenge remains: how do existing and new manufacturing facilities find a cost-effective way to get critical plant floor data up to higher-level information systems? The answer is to take advantage of the digital HART data in installed instruments that is currently inaccessible because you did not know it was there or could not afford the equipment upgrades to read it.
HART protocol's persistence
The process industry has had no lack of digital instruments and protocols introduced to the market over the past thirty years, each promising new and improved methods of gathering and sharing process variables and diagnostics via digital communication links. However, there is only one smart instrument communication protocol that has outlasted and outsold all of these alternative options: HART, and the devices that use it. With more than 40 million installed HART devices worldwide, HART is not only here to stay but, unlike other protocols, it continues to evolve. In the past decade, new features and technologies have been incorporated to enhance data exchange capacity, speed, number of devices on a network, support over Ethernet, and wireless capability.
There is no other protocol that has the massive installed base, is open to all vendors, has proven worldwide end user support, and continues to get updates and unilateral support from nearly all mainstream device manufacturers. For these reasons, HART will continue to retain its leadership role, enabling end users to have free access to process and diagnostic data that can be shared with all areas of the new smart factory in support of the IIoT framework.
HART primer
With so many HART instruments installed worldwide, it is easy to assume that everyone understands the HART protocol and what data is available from HART smart devices. Unfortunately, that assumption is not always true. Even though HART has been around since the early '80s, end users are often surprised when they realize the amount of data they actually have access to. The following paragraphs briefly highlight the data available from HART smart devices and how to gain access to that data (for a more in depth and complete primer on HART, visit the FieldComm Group's website www.fieldcommgroup.org).
HART-enabled devices superimpose a digital signal upon their 4-20 mA process signal. The HART digital signal often contains additional process measurements and other variables that may include instrument status, diagnostic data, alarms, calibration values, and alert messages.
Many HART field transmitters are hard at work measuring process parameters and producing a 4-20 mA signal that is being used for process control by a BPCS, PLC, or some other control system. In many cases, HART instruments were installed simply because they could be configured and diagnosed easily with a HART handheld communicator. There are several reasons that the rest of the HART data often goes unused. One of them is the prohibitive cost of installing a plantwide HART monitoring system and a lack of familiarity with alternatives.
A simple and cost-effective solution for gathering HART information is to use a HART interface device. These HART interface devices make acquiring HART data a fairly simple proposition. HART data can then be made available to the control system, asset manager, or plant Ethernet backbone, where it can be shared with higher-level systems or corporate wide area networks (figure 2).
Figure 2. A HART interface device like the HES HART to Ethernet Gateway connects to the 4-20 mA process signal and extracts HART process and diagnostic variables and makes them accessible via Ethernet.
The data gathered from smart HART interfaces or HART-enabled hosts uses standard and custom commands defined in the HART specification. The HART specification has also had updates to the protocol, referred to as revisions, with additional capabilities. Most HART devices operating in the field today use revision 5, 6, or 7. For this article, we will limit the discussion to three universal commands routinely used with revisions 5, 6, and 7 to gather process and diagnostic data from field devices. Those three commands are command 3, 9, and 48.
HART revisions and compliance
HART field devices are compliant to a certain HART revision. Each new revision of HART offers different features and capabilities, but all field devices-regardless of revision-still support backward compatibility with HART hosts and handheld communicators. It is important to note that devices supporting earlier HART revisions may not support the full features of the latest revision of HART commands. For this reason, it is important to verify what revision of HART the field device contains to ensure that the HART interface device is using the appropriate commands and receiving the expected results.
HART dynamic and device variables
HART devices can provide a lot of additional data to the primary variable that is read on the 4-20 mA loop. In addition to diagnostic and status bits and bytes, there are two types of HART variables that you can retrieve from HART devices: dynamic variables and device variables. All of these HART variables support IEEE 754 floating point values and are retrieved by HART hosts or interface devices (commonly referred to as gateways or multiplexers) from the field device by using HART Command 3 or Command 9.
Dynamic variables consist of the primary variable (PV), secondary variable (SV), tertiary variable (TV), and quaternary variable (QV). These variables are most often obtained from field devices using HART Command 3. However, the HART specification also makes them available in later revisions as device variables (see below) so they could also be retrieved using Command 9.
Device variables may also be used in more sophisticated or multivariable field devices to provide additional process, diagnostic, or status-related information. Device variables are only available in HART 6 and 7 revision field devices and are read using HART Command 9. Each field device can define up to 240 device variables (HART 7) numbered consecutively from 0 to 239. The device variable codes (HART memory map location identifier) are unique to each field device and may be defined in the operation manual or obtained from the manufacturer. In addition, the following device variable codes are defined in the HART specification:
242 (Optional) Battery Voltage
243 (Optional) Battery life
244 Percent Range
245 Loop Current
246 Primary Variable (PV)
247 Secondary Variable (SV)
248 Tertiary Variable (TV)
249 Quaternary Variable (QV)
Note: On some HART field devices the dynamic variables PV, SV, TV, and QV can be assigned and represented as any of the device variables.
HART hosts and revisions
Most HART hosts and interface devices can be configured as a primary or secondary HART host and can poll between 16 and 64 field devices (dependent on revision). HART Commands 3, 9, and 48 are used for reading dynamic variables, device variables, and additional status (respectively). Because these are universal commands, most hosts and interface devices support them. The HART revision of the field device will determine how it supports these commands. This brief summary of the three HART revisions outlines which commands each device supports:
HART 5 devices support Command 3 only. Using Command 3, the host or interface device will read the dynamic variables, i.e., PV, SV, TV, QV, and loop current from the field device.
HART 6 devices support Command 3 and Command 9. Using Command 3, the host or interfacing device will read the dynamic variables and loop current from the field device. Using Command 9, the host or interfacing device can read up to four device variables from the field device. To use Command 9, specify the number of device variables and each device variable code from the specific field device.
HART 7 devices support Command 3 and Command 9. Using Command 3, the host or interfacing device will read the dynamic variables and loop current from the field device. Using Command 9, the host or interfacing device can read up to eight device variables from the field device. To use Command 9, specify the number of device variables and each device variable code from the specific field device.
All HART revisions support the Additional Status Command 48. HART protocol allows the manufacturer to report as many as 25 bytes of diagnostic data from each HART field device. This plays a key role in the overall health and status of field devices.
For multivariable and more complex HART field devices, where data is required from more than eight device variables, the field device can be polled multiple times by a HART host or interfacing device, with each poll specifying up to eight unique device variables. For example, if you wanted device variables 2-25 from a specific field device, you could configure the host or interfacing device to poll that same field device using HART Command 9 three times specifying eight unique device variables in each poll.
HART interface options
There are several ways to interface with HART smart field devices to acquire digital process and diagnostic information. They include HART-enabled 4-20 mA input cards, HART multiplexer (Mux) systems, slide-in PLC gateway cards, custom-coded software interfaces for asset management, and MES/ERP systems and standalone gateways that typically convert the HART data to some other proprietary or open industry format. Many PLC and BPCS cards installed in legacy systems do not have the capability to read the HART data that is superimposed on the 4-20 mA signal. However, each vendor usually has an alternative card that is more expensive or offers a full upgrade path to input cards that read HART.
HART multiplexers are common. Typically, their interface is a RS-422, RS-485, or RS-232 serial connection that is custom configured for a particular vendor's hardware interface, asset management system, or control system. Some PLC and BPCS companies offer slide-in chassis-type gateway cards that read the HART data and have a proprietary backend communication connection to the system. Each of these options is usually quite costly and therefore often avoided. The most expensive but also most specific HART interface is one written by a programmer; it can be customized to exact user and hardware specifications.
Lastly, there are standalone HART gateways that are often the most economical pathway to extracting HART data from field devices and making the data readily available to higher-level systems. These products usually offer one to four channels or ports that allow several HART devices to be multidropped for maximum data concentration (figure 3).
Figure 3. HART to Ethernet gateways offer a quick and economical way of sharing critical HART data with higher-level systems.
Employing the extracted HART data
Once HART data is extracted from field devices it is essential that the information be made available in an open and easy-to-interface manner. Now that Ethernet backbones (often further propagated by fiber and wireless modems for longer distances) have become the standard for in-plant communication links, it seems only reasonable that any interface device that gathers and holds enormous amounts of data should include an Ethernet port. Likewise, these same devices should support open protocols that run seamlessly over Ethernet networks.
Employing this HART data for process monitoring, control, predictive maintenance, and process optimization requires that open and vendor-neutral industrial protocols be supported. This allows the HART device data to freely flow to most any control, supervisory control and data acquisition (SCADA), and monitoring system from any vendor. Now that HART supports Ethernet with HART-IP, it only seems logical that any device supporting the HART protocol with an Ethernet port would support HART-IP (figure 4). HART-IP devices typically allow for any HART field device data to be mapped to a number of device variable locations for reading by a HART-IP host.
Figure 4. HART gateways supporting HART-IP typically allow freeform mapping of HART field device data.
One of the most installed and supported industrial Ethernet protocols is Modbus/TCP. Modbus/TCP takes Modbus data packets and wraps them in a TCP header using IP addressing. This makes implementation by both host computer and field device manufacturers quick and abundant due to the popularity and royalty free implementation of Modbus (figure 5).
Figure 5. HART to Ethernet gateways should support open industrial Ethernet protocols like Modbus/TCP.
Additionally, Ethernet devices can offer web pages to view the collected HART process and diagnostic data on any PC, tablet, or mobile device. For users, viewing web pages with an enormous amount of data can be overwhelming. Device vendors should make an effort to lay out the information in a table format with easy-to-understand headers and address locations (for other supported protocols), so that additional hosts can be configured more easily (figure 4).
Figure 6. Web servers should display extracted HART data on web pages in easy-to-read tables with optional addressing for other protocols (Modbus shown here).
Cybersecurity considerations
IIoT, cloud storage, big data, and a host of other interconnecting methods and strategies have led to no shortage of production and efficiency increases. Unfortunately, these have not been, nor do they continue to be, realized without a cost and threat from cybersecurity issues. For these reasons it is more important than ever that Ethernet-based devices include safeguards within their products to ensure that network bandwidth is protected, viruses or malware cannot be loaded, unwanted access is not granted, unauthorized reconfiguration of devices is not allowed, and unauthorized writes to memory locations are not accepted by the device. In addition, the physical security of such devices requires that they are restricted to authorized personnel only, and process data should be read only-unless the device is required to perform control. It is important that the entire product life cycle, including design, build, and test, adheres to tight process and quality assurance requirements. Additionally, post installation considerations should be taken to assist on-site protection of site data and property. At a minimum, a two-layer protection scheme that includes software and physical hardware restricted access should be put in place for the device (figure 7).
Figure 7. The HES HART-to-Ethernet gateway restricts unauthorized access with hardware solderless jumpers and software communication socket restrictions.
Configuration of IIoT devices
For many years, end users have had to deal with custom and proprietary configuration packages from vendors for advanced capability devices. Users typically have to learn and get IT support and permission for several custom software packages. Most IIoT-capable devices are not simple field instruments, and therefore small handheld configurators are not convenient for setup and configuration. In fact, many HART protocol gateways require complex database mapping and programming software. When sourcing or specifying an IIoT device, investigate what the programming interface will be. There are several open standards and software packages that vendors have access to that do not require custom or expensive programming software utilities (figure 8).
Figure 8. Look for devices that support open industry standards like FDT/DTM technology for programming, so you can use free software like PACTware™.
Taking critical plant floor data from smart HART field devices and sharing it with higher-level control and information systems no longer has to be difficult or expensive. With the acceptance of industrial Ethernet backbones and wireless networks, IIoT HART interface devices with built-in security measures, open industry protocols, and ease of programming, are a quick and seamless way to share process data with the entire corporate infrastructure.
Reader Feedback
We want to hear from you! Please send us your comments and questions about this topic to InTechmagazine@isa.org.
Tina S. Todd, is director of engineering at Moore Industries-International, Inc. She has a BSEE from Brunel University and more than 25 years of systems engineering experience in industrial, communications, and aerospace applications. For more information, contact info@miinet.com or www.miinet.com.
