Menu

HART

Protocol overview for HART covering 4-20 mA overlay communication, point-to-point versus multidrop operation, command-based device access, and process-instrument integration scope.

Categories:

What HART Is

HART, short for Highway Addressable Remote Transducer, is a smart-instrument protocol that overlays digital communication on traditional 4-20 mA instrumentation loops. Its primary practical advantage is that plants can keep the installed analog wiring while adding digital access to device identity, diagnostics, configuration, and secondary process values that a plain analog loop cannot expose by itself.

HART is most common in process industries such as oil and gas, water and wastewater, chemicals, power generation, and other instrument-heavy environments where transmitters, positioners, analyzers, and valve devices still depend on 4-20 mA loops. It remains globally important because it bridges older analog infrastructure and newer smart-device expectations rather than forcing a full rip-and-replace.

In current Chipkin evidence, HART should still be treated as inquiry-stage and scoping-oriented rather than broad routine gateway support, but the protocol itself is widely established and well understood.

Block diagram showing HART feeding a Chipkin QuickServer that can bridge data to BACnet, Modbus, and more than 220 protocols.

See QuickServer for HART protocol conversion options

History

HART grew from smart-instrument work started by Rosemount in the 1980s and evolved into an open protocol so intelligent field instruments could exchange digital information without abandoning the 4-20 mA loops already installed across process plants. That backward-compatible approach is the reason HART remained relevant for decades: operators could add diagnostics and configuration data while preserving wiring, host systems, and maintenance practices built around analog instrumentation.

That history still matters because most HART projects are not greenfield digital networks. They are retrofit instrumentation projects where the existing loop behavior, host expectations, and device model details shape what the integration can realistically deliver.

Core Concepts

HART projects usually depend on these concepts:

  • Analog-plus-digital overlay: HART superimposes digital communication on the same pair of wires used for the 4-20 mA analog signal.
  • Bell 202 FSK signaling: traditional wired HART uses Bell 202 frequency-shift keying to carry the digital exchange without destroying the analog measurement loop.
  • Point-to-point versus multidrop: point-to-point mode preserves the analog signal for one instrument, while multidrop fixes the loop current and addresses multiple devices digitally.
  • Host and field-device model: a host system, handheld, or engineering tool issues commands to a smart field device rather than browsing a generic register map.
  • Command-oriented access: useful values and metadata are retrieved through defined HART commands rather than through a flat address table.
  • Variant context: some projects still mean classic wired HART, while others may imply HART-IP or WirelessHART discussions that need to be scoped explicitly.

HART-Specific Information

HART is not just “digital data on an analog loop.” The meaningful work sits in loop mode, command behavior, and what the instrument actually makes available through its HART implementation.

Loop Modes And Device Addressing

Classic wired HART is usually discussed in two modes.

ModeHow It WorksWhy It Matters
Point-to-pointOne device on the loop, typically polled at address 0, with the analog 4-20 mA signal still carrying the primary variableMost common expectation when the analog signal must remain meaningful to the host
MultidropMultiple devices share the loop, each with a unique address, while the analog current is fixed and the useful data is carried digitallyChanges both the device count and the assumptions about what the loop current means

That distinction is fundamental because an integration can look physically valid while still being designed for the wrong HART operating mode.

Commands, Variables, And Device Data

HART is command-driven. A host exchanges commands with the field device to retrieve identification, status, process values, and configuration details. The exact depth of available data depends on the instrument model and vendor implementation.

This is why HART intake usually needs more than a tag list. Support teams need to know which device model is present, which variables matter, and whether the project only needs the primary variable or also depends on diagnostics, secondary variables, or maintenance-oriented metadata.

Scope And Variant Reality

The phrase “HART support” can hide several very different jobs. A site might mean a classic transmitter on a wired 4-20 mA loop, a multidrop segment, or a more modern conversation around HART-IP or WirelessHART. Those are related, but they are not identical project shapes.

For current Chipkin scoping, the safest approach is to treat HART as a discovery-heavy protocol where the exact host path, instrument family, and destination expectations must be confirmed before the job is treated as routine.

Common Variants

VariantWhere It FitsWhy It Matters
Wired HART point-to-pointTraditional smart-instrument loopsKeeps the analog primary variable while adding digital access
Wired HART multidropMulti-instrument digital polling on one loopChanges addressing and fixed-current assumptions
WirelessHARTWireless instrument networksUseful where new instrumentation cannot rely on hardwired loops
HART-IPEthernet-based transport contextRelevant when the HART object model is being carried over IP infrastructure

How To Get The Points List

For HART, point lists usually come from the actual instrument model, the variables exposed by that device, and the host expectations for primary versus secondary data.

Preferred sources:

  • Device manuals and data sheets
  • Instrument configurator exports or commissioning records
  • Existing host-system documentation
  • Site-confirmed list of required variables, status bits, and diagnostics

The best intake package is not just the instrument tag name. It is the exact device model, the desired variables, and clarity on whether the job depends on only the primary analog value or on richer digital diagnostics and metadata.

Devices that Support HART

QuickServer is Chipkin’s primary gateway platform when HART-like source data must be normalized into supervisory or industrial formats such as BACnet, Modbus, or MQTT.

HART commonly appears on pressure transmitters, temperature transmitters, flow instruments, valve positioners, level devices, and analytical instruments in process and utility environments.

Common Integration Targets

  • BACnet for supervisory visibility of process values and alarms
  • Modbus for PLC and SCADA interoperability
  • MQTT for telemetry publishing where richer instrument data matters

Tools & Diagnostics

ToolTypeDescription
QuickServerProtocol gatewayNormalizes HART-adjacent source data into BACnet, Modbus, MQTT, and many other downstream protocols
FieldComm Group product registryProduct validationUseful for confirming registered HART devices and ecosystem context
Instrument configuratorsSource validationUseful for proving the device exposes the expected digital data
Loop diagnostics or calibratorsPhysical validationUseful when analog and digital assumptions diverge on the loop

Frequently Asked Questions

Is HART only an analog protocol?

No. HART combines the traditional 4-20 mA analog loop with a digital communication layer so devices can expose more than a single analog value.

What is the practical difference between point-to-point and multidrop HART?

Point-to-point keeps the analog signal meaningful for one device, while multidrop uses digital addressing for multiple devices and changes the assumptions about loop current.

Why do HART projects need more scoping than a simple analog point list?

Because the real value often sits in digital variables, diagnostics, and device-specific command behavior rather than in the primary analog signal alone.

Is HART the same thing as WirelessHART or HART-IP?

No. They are related variants in the same ecosystem, but they differ in transport and deployment assumptions, so the project needs to identify which one is actually in scope.

Reference Documents

Protocol Logo Attribution

Credit: KindPNG

Source: https://www.kindpng.com/picc/m/277-2771670_hart-protocol-hd-png-download.png

License: Source-hosted logo used for documentation reference.