Bridging the gap between HART devices and the IIoT
The gradual introduction of Industrial Ethernet and wireless networks in process plants has meant that data exchange with corporate networks is becoming common.
Over the last couple of decades, with industrial networks changing to facilitate greater data exchange within a facility and even throughout global corporate networks, the separate information hierarchy levels related to process data exchange within a manufacturing facility, as outlined in the ISA 95 model (Figure 1), have started to coalesce. This free flow of information has introduced a new set of ubiquitous terms, standards and phrases such as IIoT (Industrial Internet of Things), Smart Factory, Cloud Automation and Industry 4.0.
Plant of the future
The typical process control model that involves decision-making for the process at the local or centralised level by PLCs or process control system is quickly changing. These systems installed in the past were never intended to deal with or even realise 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 manufacturing facilities face is manpower.
Because the streamlining of costs and overheads has left many manufacturing facilities with just enough personnel to keep the plant running, facilities no longer have the extra resources required to analyse data. For this reason we are seeing third-party companies, and even some of the larger process control vendors, offer leasing or annual agreements that involve collecting, storing and analysing all sorts of process data. This data is part of a larger predictive analytics strategy that can not only forewarn operators of impending problems to come, but is also being used to optimise the process itself. This type of cloud automation looks to gather as much data as possible to reduce operating expenditures and future 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 you already have installed but either didn’t know it was there or couldn’t afford the equipment upgrades to gain access to it.
The process industry has had no lack of digital instruments and protocols introduced to market over the last 30 years. 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 over 40 million installed HART devices worldwide, HART is not only here to stay but, unlike other protocols, it also continues to get updated revisions that continually 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.
With over 40 million HART instruments installed worldwide, one might conclude that everyone understands HART protocol and what data is available from HART smart devices. Unfortunately, that conclusion is too often false. Even though HART has been around since the early ’80s, end users are often surprised when they realise the amount of data they actually have access to.
HART-enabled devices superimpose a digital signal on 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 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 plant-wide HART monitoring system and 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. This HART data can then be made available to the control system, asset manager or plant Ethernet backbone where it can then be shared with higher level systems or corporate WANs (Figure 2).
The data gathered from smart HART interfaces or HART-enabled hosts uses specifically defined universal and custom commands outlined within the HART specification. The HART specification has also had updates to the protocol, referred to as revisions, which have additional capabilities. Most HART devices operating in the field today utilise revision 5, 6 or 7. For the sake of 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 backwards compatibility with HART hosts and handheld communicators. It is important, however, 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 much additional data to the primary variable which 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 utilising 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 multi-variable 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 Device Variable Codes shown in Table 1 are defined in the HART specification.
Note that 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). Since HART Commands 3, 9 and 48 that are used for the reading of Dynamic Variables, Device Variables and Additional Status (respectively) 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 one supports:
HART 5 Devices support Command 3 only. Using Command 3, the host or interface device will read the Dynamic Variables 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 as for HART 5. Using Command 9, the host or interfacing device can read up to four Device Variables from the field device. To use Command 9, the number of Device Variables and each Device Variable Code from the specific field device need to be specified.
HART 7 Devices supports the same Command 3 and Command 9 capabilities as HART 5 and HART 6 with the exception that Command 9 can be used to read up to eight Device Variables from the 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 performing 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.
HART interface options
There are several ways to interface with HART smart field devices in order to acquire the digital process and diagnostic information. They vary from HART-enabled 4–20 mA input cards, HART multiplexer 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 control system cards that are installed in legacy systems don’t 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 for the CPU/controller and input cards that read HART.
HART multiplexers are common and typically their interface is a custom RS-422, RS-485 or RS-232 serial connection and is custom configured for a particular vendor’s hardware interface, asset management system or control system. Some PLC and control system companies offer slide-in chassis-type gateway cards that read the HART data and offer a proprietary backend communication connection to the system. Usually each of these options is quite costly and therefore often avoided.
Lastly are standalone HART gateways that most often provide the most economical pathway to extracting HART data from field devices, 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 multi-dropped for maximum data concentration (see Figure 3).
Employing the extracted HART data
Once HART data is extracted from field devices it is essential that the information is made available in an open and easy-to-interface manner. Now that Ethernet backbones (often further propagated by fibre and wireless modems for longer distances) have become the standard for in-plant communication links, it seems only reasonable that any interface device should include an Ethernet port. Likewise, these same devices should support open protocols that run seamlessly over Ethernet networks.
At a minimum, Ethernet devices should offer the viewing of its collected HART process and diagnostic data via web pages supported by any PC, tablet or mobile device. Efforts should be made by device vendors to lay the information out 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.
Now that HART supports Ethernet with HART-IP, it seems only logical that any device supporting the HART protocol with an Ethernet port would support HART-IP. 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.
One of the most installed and supported industrial Ethernet protocols is MODBUS/TCP, which makes implementation by both host computer and field device manufacturers quick and abundant due to the popularity of MODBUS.
IIoT, cloud storage, big data and a host of other interconnecting methods and strategies has led to no shortage of production and efficiency increases. Unfortunately, these have not been, nor do they continue to be, realised 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, unauthorised reconfiguration of device is not allowed and unauthorised writes to memory locations are not accepted by the device. In addition, physical security of such devices must be restricted to authorised personnel only and process values should be read only — unless the device is required to perform control. Post installation considerations should also be taken to assist on-site protection of site data and property. At a minimum, a two-layer protection scheme should be put in place for any Ethernet-enabled device that includes software and physical hardware restricted access.
Taking critical plant floor data from smart HART field devices and sharing it with higher level control and information systems within a manufacturing facility and further no longer has to be difficult or expensive. With the acceptance of Industrial Ethernet backbones and wireless networks, IIoT HART interface devices, open industry protocols and ease of programming provide a quick and seamless way to share process data with the entire corporate infrastructure.
In times of decreasing water security, IoT technology has been proven to boost operational...
Most problems that occur in Industrial Ethernet networks come down to twelve basic mistakes.
Is the call to take advantage of the current disruption and bring manufacturing back to Australia...