What HART Communicators Do

HART (Highway Addressable Remote Transducer) is a communication protocol that runs on top of the standard 4–20 mA analogue signal. A HART communicator — handheld devices like the Emerson 475 or 375 Field Communicator — connects to the loop via a pair of probes clipped to the signal wires anywhere along the 4–20 mA loop. It allows two-way digital communication with the transmitter while the analogue signal continues to carry the process value undisturbed.

Through a HART communicator, an engineer can read all transmitter configuration parameters (tag, range, units, damping, output mode), read diagnostic variables (device status, sensor temperature, loop current), perform loop tests, and — critically — write new configuration values to the transmitter. The write capability is what creates the GMP risk on a validated system.

Permitted vs Requires Change Control

The key question for any HART communicator operation on a validated system is: does this action change any parameter that is documented in the HDS or SDS, or affect the measurement accuracy the IQ calibration verification was based on? If yes, it is a change to the validated state and requires change control. If no, it is a read or diagnostic operation that can be performed with appropriate documentation but without formal change control.

HART Operation GMP Impact Status Documentation Required
Read tag number, descriptor, manufacturer info None — read-only Permitted freely None required (IQ/commissioning: record for verification)
Read process variable, loop current, % range None — read-only diagnostic Permitted freely None required
Read device status and diagnostics None — read-only Permitted freely None required
Read all configuration parameters (range, units, damping) None — read-only; useful for IQ verification Permitted; useful for IQ Record output in IQ protocol for configuration verification
Loop test (force fixed output mA) Temporarily disrupts the live 4–20 mA signal to PLC — PLC reads a forced value, not the process Permitted during commissioning / maintenance window Coordinate with control room; document test; verify transmitter returned to normal mode after
Write tag number or descriptor Changes a parameter documented in HDS instrument register — affects IQ traceability Requires change control if system is validated CCR required; update HDS and Engineering Lists
Write measurement range (LRV / URV) Changes calibrated measurement range — directly affects accuracy and IQ calibration basis Requires change control CCR required; new calibration certificate required; partial IQ re-verification required
Write engineering units Changes output units — affects SCADA display and all derived calculations Requires change control CCR required; update SDS/SCADA configuration; partial OQ re-verification required
Write damping value Changes signal response time — may affect alarm response time compliance Requires change control if validated CCR required if damping is specified in HDS or affects validated alarm response
Trim / zero calibration Changes the internal calibration of the transmitter — breaks traceability of existing certificate Requires change control; new certificate required CCR required; arrange re-calibration by accredited lab; new certificate; partial IQ update

The Loop Test Hazard — Most Common Incident

The loop test is the HART operation that most commonly causes unexpected problems on pharma projects. When a loop test is initiated, the communicator commands the transmitter to output a fixed 4–20 mA value — typically 4 mA (0%), 12 mA (50%), or 20 mA (100%) — regardless of the actual process value. The PLC receives this fixed value and acts on it as if it were a real process measurement.

If the PLC sees a 4 mA signal (0%) from a level transmitter during a loop test while the tank is actually half full, the PLC may trigger the low-level alarm and potentially the low-low interlock — stopping the distribution pump. If the system is in production during this test, the pump trip may cause a process interruption. If the test is performed without coordinating with the control room, the alarm appears in the audit trail with no context, and the next person who reviews the historian data sees a level alarm event with no corresponding process disturbance — which looks like a data integrity anomaly.

Always Coordinate Loop Tests with the Control Room

Before initiating any HART loop test on a live GMP system: inform the control room operator that you are about to force the output on a specific instrument, agree on the test value (low enough to avoid triggering interlocks, or accept the interlock will need to be bypassed with proper authorisation), and confirm the instrument has returned to normal mode after the test. Document the test in the maintenance log with start time, end time, test values used, and the confirming operator initials.

HART During IQ and Commissioning

During the IQ and commissioning phase — before the system is formally validated — HART communicator use is more flexible because the validated state has not yet been established. However, the configuration read-back during IQ is a valuable verification tool, and the discipline of documentation should be established from the start.

During IQ, HART communicator read operations are useful for:

HART COMMUNICATOR — DECISION TREE FOR GMP USE HART operation planned Does it write any parameter? NO Read / diagnose freely YES System validated? YES Raise CCR first NO Document in log
HART COMMUNICATOR — GMP DECISION TREE: READ OPERATIONS ARE FREELY PERMITTED; WRITE OPERATIONS ON A VALIDATED SYSTEM REQUIRE CHANGE CONTROL

HART Use After Validation — the Rules

Once a system is validated, the rules tighten. The transmitter's configuration is part of the validated state — every parameter documented in the HDS is frozen at the IQ-verified value. Any write operation that changes a documented parameter is a change to the validated state and requires a Change Control Request (CCR) to be raised and approved before the change is made.

The practical implication: a maintenance engineer using a HART communicator to "just adjust the damping a little" on a validated transmitter has made an undocumented change to a validated system. That the change was well-intentioned does not change the fact that the HDS now describes a transmitter configured differently from what is actually installed. If an auditor asks to verify the transmitter configuration against the HDS, the mismatch is a finding.

For situations where HART operations on a validated system are genuinely needed — reconfiguring a transmitter after a range change, adjusting the HART polling address when adding a second HART master, trimming after an OOT finding — the change control process described in the article on validating a new field instrument after installation applies. The HART-performed change is one step in that sequence, not a standalone action.

HART Address — The IQ Verification That People Miss

In a standard point-to-point 4–20 mA installation with HART, each transmitter is typically configured at HART address 0. Address 0 is required for the PLC's HART I/O module to poll the transmitter for digital variables — if the address is anything other than 0 in a point-to-point system, the HART polling fails silently and the PLC cannot read the HART digital values (only the 4–20 mA analogue signal works).

At IQ, read back the HART address of each transmitter using the communicator and verify it matches the SDS specification. Record the address in the IQ protocol. If any transmitter has been incorrectly configured at address 1 or higher during factory setup, correct it during the IQ commissioning phase — this is an as-built correction that should be recorded as a minor deviation if it differs from the SDS, or simply noted if the SDS specifies "address to be set during commissioning."

Defining HART Permissions in the Control Philosophy

Some sites include a short section in their Control Philosophy or System Administration SOP that defines who is authorised to use a HART communicator on the validated system, what operations are permitted without change control, and what documentation is required. This is good practice — it prevents the situation where different engineers make different assumptions about what HART operations are acceptable.

A practical three-rule HART policy for a validated system: