HART Protocol Deep Dive: Field Device Integration with 4-20mA Loops (2026)

Walk into almost any refinery, chemical plant or water works and you will find thousands of two-wire transmitters whose digital brains have never been read. They are wired to analog input cards, they report one number between 4 and 20 mA, and everything else they know, from sensor health to configuration history, sits unused behind the same two wires. The HART protocol is the reason that data exists at all, and it is also the reason so much of it is still stranded.

This matters in 2026 because the economics have flipped. Rewiring a brownfield plant for a new fieldbus is rarely justified, yet digital twins, predictive maintenance and NAMUR Open Architecture (NOA) monitoring all want exactly the data HART devices already carry. This guide goes below the marketing summary: the physical layer with real loop arithmetic, the byte-level frame, the command classes, device description technologies, HART-IP, WirelessHART, multiplexers, and a concrete pipeline for feeding a twin.

What this covers: FSK signalling and loop budgets, frame timing, command classes, EDD/FDT/FDI integration, HART-IP, WirelessHART, NOA data paths, noise and grounding, failure modes, and a rollout checklist.

Context and Background

HART stands for Highway Addressable Remote Transducer. It originated at Rosemount in the 1980s and was opened up through the HART Communication Foundation, now part of the FieldComm Group, which maintains the specifications and the conformance program. FieldComm describes HART as supported by virtually every host system and every major manufacturer of process automation instrumentation, and it positions the protocol as a digital signal on top of the 4-20 mA analog loop, extended to IP networks as HART-IP and to radio as WirelessHART (FieldComm Group technologies). Exact installed-base figures vary by source and year, so treat any “40 million” style number, including those in older articles on this site, as an industry estimate rather than an audited count.

The design goal in 1989 was backward compatibility with analog. A transmitter keeps its 4-20 mA output as the primary, safety-relevant process signal, while a small frequency-shift-keyed (FSK) signal rides on top for configuration and diagnostics. Because the FSK waveform averages to zero over a bit time, the analog value a legacy input card sees is unchanged. That one decision explains both HART’s longevity and its limits: it is slow, but it never broke an existing loop.

Today the field-level landscape has several layers. Classic HART lives on analog and multiplexed loops. HART-IP carries the same application layer over TCP or UDP on Ethernet, and FieldComm lists it as one application of the Ethernet-APL physical layer. WirelessHART extends the commands onto an IEEE 802.15.4 mesh. If you are comparing it with other options, our guides to the PROFIBUS protocol and the Modbus protocol cover the other legacy workhorses, and OPC UA FX field-level communications shows where the controller-to-controller world is heading.

The thesis of this article is simple. Most plants do not have a HART problem, they have a HART access problem. The protocol is well specified and the devices already speak it. What is missing is a path from the loop to the data layer that does not disturb the control system, and that path is an architecture decision, not a protocol upgrade.

A note on corrections. Earlier versions of this post claimed that HART 7 appeared in 2022, that the bit encoding was 1 = 2200 Hz, that WirelessHART relays “up to 5 hops”, and that Ethernet-APL runs at 2.5 Mbps. Those statements were wrong or unverified. HART revision 7 dates from 2007, mark (1) is 1200 Hz and space (0) is 2200 Hz, and Ethernet-APL is a 10 Mbit/s, two-wire, powered, intrinsically safe physical layer, as FieldComm itself states.

HART Reference Architecture: Signal, Loop and Hosts

Short answer: a HART device sits on a 4-20 mA loop that also carries a Bell 202 FSK signal at 1200 bit/s. A primary master (a control system I/O card, a modem or a handheld) sends commands, and the device replies on the same pair. The analog value is untouched, so existing control keeps working while a second digital channel serves configuration and diagnostics.

Figure 1: Where HART traffic flows in a brownfield plant, from the loop to the control system, the asset management host and the data layer.

Figure 1 shows the three paths data can take from one transmitter. The first is the analog path to the control system, which carries the process variable and is the only path a safety function should rely on. The second is the digital path through a HART-capable I/O card or a modem, which lets the control system or an asset management host read and write device data. The third is a gateway path that terminates the loop in a multiplexer or remote I/O with a HART-IP or OPC UA face toward the network.

The physical layer in numbers

HART uses Bell 202 style continuous-phase FSK. A logical 1 (mark) is 1200 Hz and a logical 0 (space) is 2200 Hz, at 1200 bit/s. The device modulates its current by roughly plus and minus 0.5 mA around the analog value, a 1 mA peak-to-peak signal. Since the sine wave is symmetric, its average over a bit is zero, and the loop’s DC value, and therefore a PLC’s reading, does not move. That is why HART can coexist with analog at all.

Masters send by voltage-modulating across the loop resistance, devices by current-modulating. A receiver therefore needs a minimum loop impedance to turn that 0.5 mA into a detectable voltage. The commonly quoted communication window is a total loop resistance between about 230 and 1100 ohms. A 250 ohm sense resistor is the classic design point, and it also converts 4-20 mA into 1-5 V for the input card.

A worked loop budget makes the constraint concrete. Take a 24 V supply and a transmitter that needs 10.5 V at its terminals (a typical figure, check your datasheet). The maximum allowable loop resistance must be evaluated at the highest current the device can draw, which is the high alarm level, say 21.75 mA. Then R_max = (24 – 10.5) / 0.02175 = about 620 ohms. Subtract the 250 ohm sense resistor and you have 370 ohms for cable, barriers and any isolators. A 1 km run of 1.5 mm2 copper is about 12 ohms per conductor, so 24 ohms for the pair, and the budget is comfortable. A passive Zener barrier can add 300 ohms or more, which is where designs quietly fail.

Capacitance is the other limit. Cable capacitance and the total network capacitance form a low-pass filter with the loop resistance, and it attenuates the 2200 Hz tone more than the 1200 Hz tone. FieldComm’s physical-layer specification gives cable length tables by wire gauge and capacitance per metre. For a single device on good shielded twisted pair, lengths of roughly 1.5 to 3 km are commonly cited, and multidrop networks are limited much more tightly by the sum of device and cable capacitance. Use the specification tables for a real design, not a rule of thumb.

Masters, devices and addressing

HART is master/slave with at most two masters. The primary master is normally the control system or a data acquisition host, the secondary master is typically a handheld communicator or a maintenance laptop with a modem. A bit in the address byte tells the device which master sent the request so it can reply appropriately and keep burst-mode traffic straight.

Devices have two addresses. The short, or polling, address is 0 to 63 in revisions 6 and 7 (earlier revisions allowed 0 to 15). Address 0 is the normal point-to-point case, where the device’s analog output tracks the process. Any non-zero polling address puts the device in multidrop mode, and the device then holds its loop current at a fixed 4 mA, so the analog channel carries no information. Older text, including a previous version of this post, said addresses extend to 255; that is not the case for the short address.

The long address is a 38-bit unique identifier built from the manufacturer ID, the device type and a 24-bit device-specific ID. It is the stable identity of a physical device, whereas the tag is a human-assigned 8-character label. For asset management and twin binding, the long address plus tag is the key you want, and we return to that below.

Burst mode and the response to a failure

In normal operation the master asks and the device answers. In burst mode, a device is configured to repeatedly send a chosen response, such as command 1, 2, 3 or 9, without being polled, and the master simply listens. Revision 7 supports multiple burst messages from one device and trigger modes such as continuous, rising, falling, on-change and windowed. Burst is the efficient way to get a dynamic variable stream to a gateway when you cannot afford one poll per device.

Failure signalling stays analog first. NAMUR recommendation NE 43 defines the valid measurement range as 3.8 to 20.5 mA and the failure signalling bands as at or below 3.6 mA (low) or at or above 21 mA (high). Devices let you choose high or low alarm direction and commonly default to values like 3.75 mA or 21.75 mA, but the exact defaults are vendor-specific. The HART status bytes then tell you why the device failed, which is the diagnostic payoff of the whole scheme.

Frame format and timing

Every HART transaction is a UART-style byte stream. Each byte is sent as 11 bits: one start bit, eight data bits, one odd-parity bit and one stop bit. At 1200 bit/s that is 1200 / 11, about 109 bytes per second, or roughly 9.2 ms per byte. Everything in HART timing follows from that number.

A frame has the following fields, in order:

Field	Size	Purpose
Preamble	5 to 20 bytes of 0xFF (5 minimum)	Lets the receiver’s carrier detect and demodulator synchronise
Start delimiter	1 byte	Frame type (master request, slave response, burst) and whether the address is short or long
Address	1 byte short, 5 bytes long	Polling address or 38-bit unique ID, plus master and burst bits
Command	1 byte	Command number (extended 16-bit numbers use command 31)
Byte count	1 byte	Length of status plus data
Status	2 bytes, responses only	Response code and device status
Data	0 to about 25 bytes	Command-specific payload
Checksum	1 byte	Longitudinal parity (XOR) of all bytes from the delimiter on

The start delimiter is 0x02 for a master request, 0x06 for a slave response and 0x01 for a burst frame, with the high bit set when the long address format is used. Because the checksum is a plain XOR, it catches single-bit errors well but is weak against multi-bit corruption; the per-byte parity bit adds a second layer.

Now the worked timing. A command 1 (read primary variable) request in short-frame form with a 5-byte preamble is 5 + 1 + 1 + 1 + 1 + 1 = 10 bytes. The response carries a two-byte status and five data bytes (one unit code plus a four-byte IEEE 754 float), giving 5 + 1 + 1 + 1 + 1 + 2 + 5 + 1 = 17 bytes. That is 27 bytes, or about 248 ms of wire time. In long-frame form each of the two frames gains four address bytes, so 35 bytes and about 321 ms. Add the turnaround delay, and the commonly cited figure is about two transactions per second per loop in request/response mode, roughly 3 to 4 per second in burst mode. Those throughput numbers are widely quoted engineering approximations, not guarantees; check your device and host.

The consequence is brutal for scaling. Polling 200 devices behind a multiplexer at 0.5 s each takes 100 s per sweep on a single channel, which is why multiplexers run multiple parallel channels. HART is a configuration and diagnostics channel, not a measurement bus. Fast control stays on the analog signal.

Response codes and the device status byte

The first status byte is the response code. If its top bit is set, it signals a communication error (parity, framing, overrun, checksum); if clear, the lower bits are a command-level response such as “too few data bytes”, “device-specific error” or “write protect mode”. The second byte is the field device status, and it deserves to be memorised:

Bit 7: field device malfunction.
Bit 6: configuration changed.
Bit 5: cold start.
Bit 4: more status available (read command 48 for detail).
Bit 3: loop current fixed.
Bit 2: loop current saturated.
Bit 1: non-primary variable out of limits.
Bit 0: primary variable out of limits.

Each bit is a usable event for a digital twin or a maintenance system. “Configuration changed” is a free audit trigger, “loop current fixed” detects a technician who forgot to release a transmitter after a bench test, and “more status available” tells you when to spend a poll on command 48.

Command Classes and What They Let You Do

HART commands fall into three classes, plus an extension mechanism, and the older description of “universal commands 0-3, 20-23” was inaccurate. The classes are defined by command number ranges in the specification.

Universal commands (0 to 30): every compliant device must implement them. Command 0 reads the unique identifier, command 1 reads the primary variable, 2 reads loop current and percent of range, 3 reads up to four dynamic variables plus loop current, 6 writes the polling address, 11 reads the unique identifier by tag, 12 and 13 read the message and tag/descriptor/date, 14 reads sensor information, 15 reads output information, and so on.
Common-practice commands (32 to 126): optional but standardised, so a host can use them across vendors. Examples include command 33 (read device variables), 35 (write primary variable range values), 40 (enter or exit fixed current mode), 41 (perform self-test), 42 (device reset), 44 (write primary variable units), 45 and 46 (trim loop current zero and gain), 48 (read additional device status) and the burst commands 103 to 109.
Device-specific commands (128 to 253): vendor-defined, described only in the device’s description file. Damping, sensor trims, custom linearisation and Coriolis density settings typically live here.
Extended commands: command 31 introduces 16-bit command numbers, which opens the space beyond 255.

A typical commissioning conversation

Figure 2 shows a representative exchange. A master first issues command 0 using the short address to discover the long address and the device’s revision, then switches to long-frame commands for everything else, reads the variables, and uses command 48 only when the status bit says there is more to know.

Figure 2: A representative HART master/device exchange, from identity discovery to dynamic variables and extended status.

The point of command 0 is bootstrapping. A master that knows nothing about a loop sends command 0 to polling address 0; the reply includes the manufacturer ID, device type, universal revision, device revision and the device ID, which together form the long address. The device type and device revision then select the right device description file, which tells the host what the device-specific commands mean.

Dynamic variables versus device variables

HART separates what the loop reports from what the device measures. Each device exposes up to four dynamic variables, the primary, secondary, tertiary and quaternary values (PV, SV, TV, QV). The PV is the one mapped to the 4-20 mA output. Mapping is configurable: a multivariable transmitter might put differential pressure on the PV, static pressure on the SV and process temperature on the TV. Command 3 reads all four plus the loop current in one transaction, which is the most efficient way to harvest a multivariable device.

Device variables are the underlying measurements, addressed by index through command 33 and, in revision 7, command 9, which returns device variables with their status in a single call. Each variable carries a classification code and a quality indicator in revision 7, so you can tell a good reading from a “poor accuracy” or “fixed” one. This is the data a twin actually wants, because the quality tag tells it whether to trust the sample.

Write protection and the cost of a mistake

Many commands can change what the process control system sees: range values, units, damping, fixed-current mode. Classic HART has no authentication in the protocol, so anyone with a modem on the loop can issue them. Most transmitters offer a hardware write-protect jumper or a software lock, and safety-instrumented loops should use it. The “configuration changed” flag and a counter in command 0 responses let you detect modifications after the fact, which is why recording them matters for compliance.

Device Integration: DD, EDD, FDT/DTM and FDI

The protocol only gets you bytes. To turn command 131 into “Sensor trim point 2” in a user interface, a host needs a machine-readable description of the device. This is where most real-world HART integration projects lose time.

Figure 3: Device description technologies and the hosts that consume them, from DD files to FDI packages.

Device descriptions

The first generation was the Device Description (DD) written in the HART Device Description Language and compiled by a tool into a binary file, distributed through the FieldComm DD library. Electronic Device Description Language (EDDL, standardised as IEC 61804-3) generalised the idea across HART, FOUNDATION Fieldbus and PROFIBUS PA, and an EDD describes variables, commands, menus, methods (scripted procedures such as a sensor trim wizard) and unit relations. For commissioning, the methods are the valuable part.

A different approach, FDT (Field Device Tool, IEC 62453), uses a vendor-supplied Windows component, the DTM (Device Type Manager), that runs inside a frame application such as PACTware or FieldCare. DTMs give vendors full UI freedom but tie you to the Windows frame and to the DTM version, which is the origin of the “EDDL versus FDT fragmentation” complaint.

FDI as the convergence

Field Device Integration (FDI) was introduced in 2015 by FieldComm Group together with PI (PROFIBUS and PROFINET International), with the OPC Foundation and others involved in the specification; FieldComm describes its goal as one device, one package, all tools. An FDI package bundles an EDD for the device logic, an optional User Interface Plug-in (UIP) for rich graphics, and metadata. The family is standardised as IEC 62769, and part 109 defines FDI profiles for HART and WirelessHART (IEC 62769-109-1 on the FieldComm library). In FDI, an FDI Server holds the information model of the device and exposes it over OPC UA, so a client can browse and manage devices without a bespoke driver.

For a brownfield plant the practical rule is: ask the host vendor which of EDD, DTM and FDI it supports, check that the device’s package exists in the FieldComm library, and plan to maintain a managed catalog. Device descriptions are versioned against device revisions. A transmitter firmware update can orphan a DD, and a missing DD silently reduces the host to generic universal and common-practice commands only.

Generic access without a DD

You can do a lot without a DD. Universal and common-practice commands are the same on every device, so a gateway that speaks only those can still read identity, PV, SV, TV, QV, loop current, status and tag, plus use command 48. That is often enough for monitoring. Writing configuration, trimming or reading device-specific diagnostics (valve positioner signatures, for example) needs the DD. A pragmatic split is to use generic access for the data pipeline and a DD-aware asset management tool for the maintenance workflow.

Code: reading a device with a HART modem

The snippet below uses plain Python with pyserial against a HART modem, building a command 0 request in short-frame form. It illustrates the frame, not a production driver; real code must handle carrier detect (RTS), timeouts, retries and long-frame addressing.

import serial

def checksum(frame: bytes) -> int:
    c = 0
    for b in frame:
        c ^= b
    return c

def cmd0_request(poll_addr: int = 0, primary: bool = True) -> bytes:
    preamble = b"\xff" * 5
    delimiter = 0x02                      # master to slave, short frame
    addr = (0x80 if primary else 0x00) | (poll_addr & 0x3F)
    body = bytes([delimiter, addr, 0x00, 0x00])   # command 0, byte count 0
    return preamble + body + bytes([checksum(body)])

port = serial.Serial("/dev/ttyUSB0", 1200, bytesize=8, parity=serial.PARITY_ODD,
                     stopbits=1, timeout=0.6)
port.rts = True                           # key the modem carrier
port.write(cmd0_request())
port.flush()
port.rts = False
reply = port.read(32)
print(reply.hex(" "))

Parsing the reply: after the preamble and delimiter 0x06, the address echo, command 0 and byte count, the two status bytes come first, then the identity fields including the manufacturer ID, device type, preamble count, universal revision, device revision, software revision, hardware revision and flags, and finally the 24-bit device ID. The manufacturer ID and device type are looked up against the FieldComm registry.

From Loop to Network: Multiplexers, HART-IP, WirelessHART and NOA

Once you can speak HART on a loop, the engineering question becomes where to terminate it and how to expose it. Four patterns dominate, and most plants end up using more than one.

HART-capable I/O and multiplexers

The cheapest path is the control system itself. Many DCS and PLC platforms offer HART-enabled analog input cards that run a modem per channel, read the dynamic variables and status, and pass the data to an asset management station over the system network. The catch is that HART data often travels through a separate, slower path and some systems expose only the PV. Check whether the I/O card gives you secondary variables and extended status or only passes through commands for a handheld.

The second pattern is the HART multiplexer, a dedicated box that sits in the marshalling cabinet, connects in parallel to many loops through a bank of modems, and presents them as a polled network, historically over RS-485 and now often over Ethernet. This is the retrofit path when the existing I/O cards are not HART-capable. A multiplexer must be installed in series-parallel with the loop correctly so that it does not add enough resistance to violate the loop budget. The cost is more boxes to maintain; the benefit is zero changes in the control system.

HART-IP

HART-IP carries the HART application layer, the same commands and the same response codes, over TCP or UDP on IPv4 or IPv6. It has been part of FieldComm’s network management specification since June 2012, as a gateway vendor’s technical write-up also notes (Softing on HART devices and Industry 4.0). A HART-IP server is a gateway, multiplexer or remote I/O that tunnels HART transactions between a client and the devices behind it, and a native HART-IP device can sit directly on Ethernet, including on Ethernet-APL.

Each HART-IP message starts with a short fixed header carrying a version, message type (request, response, publish or notification, error), message ID, status, sequence number and byte count, followed by the standard HART frame content for pass-through commands. HART-IP is registered on port 5094 for both TCP and UDP. I describe that header layout and port from the published specification as I understand it; verify field widths against HCF_SPEC-085 before building a parser.

The architectural benefit is that asset management tools, which previously needed a serial modem or a proprietary I/O driver, can talk to HART devices across the network. The risk is that the same reach brings the plant network’s threat model to a protocol with no native authentication in classic form. Treat a HART-IP server as an OT asset: segment it, restrict clients, and prefer read-only roles for data collection.

WirelessHART

WirelessHART (IEC 62591) brings the HART command set to a self-organising mesh. It is part of the HART 7 specification and runs on IEEE 802.15.4 radios in the 2.4 GHz band at 250 kbit/s raw. Medium access is time division with channel hopping across the 15 channels, in time slots of 10 ms, which gives predictable latency and resistance to interference. Communication is secured with AES-128 and a network manager and security manager govern joins, keys and routes.

Two architectural points matter. First, the network manager, not the field device, schedules everything, so device behaviour is deterministic and power use is low enough for battery operation. Second, a gateway translates between the mesh and the plant network, often to HART-IP, OPC UA or Modbus. WirelessHART suits monitoring points that never justified a cable run: corrosion probes, tank levels, vibration. It is not a control medium for fast loops, and a mesh must be planned for path redundancy. For a standards-level comparison with its main rival, see our ISA100.11a versus WirelessHART comparison.

NAMUR Open Architecture as the data path

NOA, from the NAMUR user association, extends the traditional automation pyramid with a second, parallel channel for monitoring and optimization (M+O) so that non-control uses of data never touch the core control path. In the commonly described form, the M+O side receives data through an OPC UA interface, and a one-way “NOA diode” or equivalent ensures read-only, secure access. The Beckhoff and Softing write-ups describe a typical implementation: an embedded OPC UA server in a remote I/O system, a gateway or a field device with Ethernet, surfacing HART data without disturbing the control loop (Beckhoff on NOA).

This is the correct frame for HART in a digital twin project. The twin consumes from the M+O side. The control system keeps its analog signals and its existing HART path for maintenance. Nothing about the twin’s polling rate or software quality can alter the process.

Feeding a Digital Twin from HART Data

Twin projects tend to fail at the data binding step. The sensors exist, the data exists, but nobody can say with confidence which sample belongs to which asset instance. HART gives you more help here than most field protocols, if you use it.

Figure 4: A NOA-style pipeline that turns HART device data into a twin-ready asset model without touching the control path.

Identity binding

Use the long address (manufacturer ID, device type, device ID) as the immutable hardware identity, and the tag as the logical plant identity. Maintain a mapping table: tag, long address, loop number, I/O channel, asset model ID. When a device is replaced, the tag stays and the long address changes, and your pipeline should record that as a lifecycle event rather than as a new asset. Standards such as the ISO 23247 digital twin framework name this observable element to digital entity relationship formally; the practical content is the mapping table.

What to collect

Group collection into three tiers by value and cost:

Cheap and constant: dynamic variables (PV, SV, TV, QV) with units and loop current via command 3, at a rate of seconds to tens of seconds per device.
Event-driven: the device status byte on every transaction, with command 48 only when “more status available” is set. Write these as events, not time series.
Slow context: identity, revision, range values, damping and configuration counters, read at startup and on “configuration changed”, then diffed against a stored baseline.

Valve positioners and some analyzers expose richer device-specific diagnostics, such as friction or travel deviation, which need the DD. These are where predictive maintenance models gain real leverage, and where a DD-aware tool or an FDI server is worth its cost.

Throughput budgeting for the gateway

Do the arithmetic before buying hardware. A command 3 exchange in long-frame form carries four floats plus loop current; its response is about 5 + 1 + 5 + 1 + 1 + 2 + 21 + 1 = 37 bytes, plus a 15-byte request, so about 52 bytes or 0.48 s of wire time. A 16-channel multiplexer with parallel modems can therefore cycle all of its devices in under 10 s if channels truly run in parallel. If it multiplexes through one modem, the sweep is closer to 16 x 0.5 = 8 s plus switching, and a 200-device plant on a single channel takes about 100 s. Choose collection intervals that exceed the sweep time, or you create a permanent backlog.

Clock and sampling semantics

HART samples are not timestamped by the device in most transactions. The timestamp is when your gateway received the reply, which can lag the measurement by hundreds of milliseconds plus queueing. For trending slow process variables this does not matter. For correlating a valve travel anomaly with a pressure spike, it does. Revision 7 lets devices report a time stamp and the update period for device variables through command 9, so prefer it where the devices support it and treat gateway time as an approximation otherwise.

Publishing to the rest of the stack is then a standard exercise. Gateways emit OPC UA nodes or Sparkplug topics, an edge broker fans out, and a historian and the twin platform subscribe. Our OPC UA protocol guide covers the server side and the IIoT edge gateway architecture post covers placement and buffering.

Trade-offs, Gotchas, and What Goes Wrong

HART’s failure modes are rarely protocol bugs. They are loop-design and process errors that surface when you start using the digital channel seriously.

Input cards that filter the FSK badly. An analog input with poor filtering will show a small ripple on the process value when a handheld or multiplexer talks. Use HART-aware or HART-transparent input modules, and test by polling a loop while watching the analog reading.
Outputs and barriers that block the signal. A low-impedance analog output (a positioner driver) or an intrinsic safety isolator that is not HART-transparent will suppress communication. Zener barriers pass HART, but their series resistance eats the loop budget. Always check the isolator’s datasheet for HART support.
Accidental multidrop. Writing a non-zero polling address (command 6) to a device that was meant to stay point-to-point drives its loop current to a fixed 4 mA. The control system sees the process reading collapse to zero percent. It is the classic commissioning mistake, and the device status bit “loop current fixed” is the clue.
Fixed-current mode left on. A technician running a loop check with command 40 and not releasing it leaves the transmitter frozen at a test current. Alert on the status bit in your pipeline, and require the release step in work procedures.
Two primaries. A second host configured as primary master on the same loop causes collisions and lost replies. Assign roles deliberately: control system as primary, maintenance tools as secondary, or use a multiplexer as the single primary.
Polling storms. Asset management tools that scan whole loops every minute for 2,000 devices saturate the slow channel and can delay legitimate transactions. Rate-limit and use burst mode for the variables you need.
Unmanaged DD catalog. A host that silently falls back to generic commands after a device firmware change can mislead maintainers. Keep a device-revision inventory against DD or FDI package versions.
Security. Classic HART has no encryption or authentication, and HART-IP exposes it to the network. Use segmentation, hardware write protect and read-only gateway roles. Check your HART-IP revision and vendor notes for transport security options; I have not verified a specific TLS profile here.

There are also honest limits to the protocol. At 1200 bit/s, HART is not a diagnostic firehose, so waveform-level data such as vibration spectra cannot flow over it. Its master/slave design means a device cannot raise an alarm on its own in non-burst mode. And its universal commands expose less than a modern information model does. This is why FieldComm built PA-DIM with the OPC Foundation and why Ethernet-APL, a 10 Mbit/s two-wire powered intrinsically safe layer, will carry new installations. For brownfield sites, though, rip-and-replace is rarely the economic answer. The sensible plan is to harvest what HART already provides, then migrate loop by loop as instruments reach end of life.

Practical Recommendations

Start with an audit rather than a purchase. Count how many loops have HART-capable devices, how many pass through HART-capable I/O, and how many have a DD or FDI package available. In most plants that exercise alone turns up a large population of devices already reporting, but nobody is reading them.

Then pick the collection path by constraint. If the existing I/O is HART-capable and the vendor exposes the data, use it. If not, a multiplexer or HART-enabled remote I/O adds access without touching the control system. For new wireless points, use WirelessHART with a gateway that speaks HART-IP or OPC UA. Whatever the path, deliver data to the twin through a read-only M+O boundary in the NOA spirit.

Finally, treat device identity and status as first-class data. A pipeline that logs only the PV wastes the protocol.

Checklist:

Confirm loop budgets (supply voltage, sense resistor, barriers, cable) allow HART communication at the high alarm current.
Verify every isolator, barrier and analog output on the loop is HART-transparent.
Keep one primary master per loop and document secondary master use.
Record tag, long address, loop and asset model ID in a managed mapping table.
Alert on device status bits: malfunction, configuration changed, loop current fixed, loop current saturated.
Poll command 3 for dynamic variables and command 48 only on demand; use burst mode where supported.
Maintain the DD or FDI package inventory against device revisions.
Enable write protect on safety-related transmitters and make the gateway read-only.
Segment HART-IP servers and restrict clients.
Plan the migration to Ethernet-APL at instrument end of life.

Frequently Asked Questions

What is the HART protocol in simple terms?

HART is a hybrid analog and digital communication protocol for process instruments. A transmitter outputs its measurement as a 4-20 mA current while also exchanging digital messages, using a small 1200 and 2200 Hz FSK signal laid over the same two wires. The analog value keeps controlling the process, and the digital channel carries configuration, identity, secondary variables and diagnostic status for maintenance and monitoring tools.

Does HART interfere with the 4-20 mA signal?

Not in a correctly designed loop. The FSK signal swings about plus and minus 0.5 mA around the analog value and averages to zero over each bit, so a standard input card sees an unchanged reading. Interference appears only when an input card filters poorly, when a loop has too little resistance for communication, or when a non-HART-transparent isolator is installed. A 250 ohm sense resistor is the standard design point.

HART runs at 1200 bit/s, which yields roughly two request/response transactions per second per loop, and about three to four per second in burst mode. These are commonly quoted approximations. In point-to-point mode, one device uses the loop. In multidrop mode, polling addresses 1 to 63 are available in revisions 6 and 7, but power and capacitance limits mean practical networks are much smaller, and the analog signal is lost.

What is the difference between HART, HART-IP and WirelessHART?

All three share the same application layer, meaning the same commands and response codes. Classic HART uses FSK over a 4-20 mA loop. HART-IP carries the messages over TCP or UDP on Ethernet, typically through a gateway, though native HART-IP devices exist. WirelessHART, standardised as IEC 62591, runs the commands over an IEEE 802.15.4 2.4 GHz time-synchronised mesh with AES-128 security.

Is HART obsolete because of Ethernet-APL and OPC UA?

No. Ethernet-APL is a 10 Mbit/s powered, two-wire, intrinsically safe physical layer aimed at new installations, and HART-IP is one of the application protocols that can run over it. But the installed base of HART devices is enormous, and replacing working loops is costly. For brownfield plants, HART remains the practical route to device data, and OPC UA through a NOA-style path is how that data reaches modern systems.

Which software do I need to configure HART devices?

You need a host that understands each device’s description: a handheld communicator, an asset management system such as an EDD-based device manager, an FDT frame such as PACTware or FieldCare with the vendor’s DTMs, or an FDI-capable host. FDI packages, standardised in IEC 62769, aim to replace per-tool drivers with one package per device. For read-only monitoring, a gateway using only universal commands often suffices.