HART Universal, Common-Practice, and Device-Specific Commands
When a host reads a HART transmitter, it is issuing numbered commands, and those commands fall into three tiers that determine how portable your integration is. Understanding the tiers tells you why any HART master can read a device's basic identity and variables, but why only the vendor's own tool can reach every calibration and configuration feature. This page is for the integrator deciding how much they can do with a generic host versus a device-specific driver.
HART Command Structure in one line: HART commands come in three classes. Universal commands are implemented by every HART device and read core data like identity and the primary variable. Common-practice commands are a shared library most devices support for routine tasks such as ranging and reading additional variables. Device-specific commands are defined by the manufacturer for features unique to that model, and only a host that knows the device can use them.
The Three Command Tiers
Universal commands are the mandatory floor. Every device that calls itself HART implements them, and they cover the data any host needs regardless of what the device measures: its identity, its manufacturer and device type, its tag, its dynamic variables, and its status. Command 0, which reads the device identity, is the anchor of the whole scheme - it is how a host discovers what it is talking to and learns the long-frame address it will use afterward. Because universal commands are guaranteed, a generic HART host can always read a device's core information without knowing anything about the specific model.
Common-practice commands sit one tier up. They are a standardized library for operations that most devices need but that are not strictly universal - things like setting the range, choosing units, mapping dynamic variables, or reading additional device variables. A device is not required to implement all of them, but when it does implement one, it does so in the standardized way, so a host that supports common-practice commands can perform routine configuration across many different devices from different manufacturers. This is the tier that makes multi-vendor asset-management tools practical.
Device-specific commands are the manufacturer's own extension. When a transmitter has a feature no generic command anticipates - a proprietary sensor trim procedure, a special diagnostic, an advanced linearization table - the vendor defines commands for it, numbered above the reserved universal and common-practice ranges. These commands are meaningful only to a host that carries the device's description. This is precisely where a device description file or DTM earns its keep, because it teaches the host what those otherwise-opaque command numbers do.
What the Tiers Mean for Integration
The command structure directly answers a question integrators ask constantly: how much can I do with a generic host? The answer is that you can always read identity, dynamic variables, and status through universal commands, and you can usually perform standard ranging and configuration through common-practice commands. That is enough to bring a transmitter's readings and health into a monitoring system, map its dynamic variables to a scada tag, and alarm on its status, all without a model-specific driver.
What you cannot do generically is reach the features hiding behind device-specific commands. A generic host has no idea what device-specific command 130 does on a particular flowmeter, so any calibration, diagnostic, or configuration that lives there is invisible until you load the manufacturer's device description or DTM. This is why a plant that wants full lifecycle management of its instruments - not just reading them - ends up needing the vendor integration files rather than relying on universal access alone.
For a monitoring architecture the split is liberating. Reading the process values and device status that operations cares about leans almost entirely on universal and common-practice commands, so a platform such as Merobix can surface HART variables and diagnostics pulled from a gateway or multiplexer without needing every device's proprietary command set. The deep, model-specific configuration stays in the engineering tool where it belongs, while the routine, portable data flows to the historian and the operator screen. The related overview of the HART protocol and the page on reading HART command 3 both show where these commands fit in practice.
Frequently Asked Questions
What is a HART universal command?
A universal command is one that every HART device must implement, covering core data that is independent of what the device measures - its identity, tag, dynamic variables, and status. Command 0, which reads device identity, is the best-known example. Because universal commands are guaranteed, any HART host can read a device's basic information without a model-specific driver.
Do I need the manufacturer's tool to configure a HART device?
For basic ranging and reading you often do not, because those use common-practice commands that generic hosts support. But any feature the vendor implemented as a device-specific command - proprietary trims, advanced diagnostics, special linearizations - is only usable by a host that has loaded the device's description file or DTM. Full configuration of an advanced device therefore usually needs the vendor integration files.
What is the difference between common-practice and device-specific commands?
Common-practice commands are a shared, standardized library for routine tasks like ranging and reading extra variables, so a host can use them across devices from many manufacturers. Device-specific commands are numbered extensions the manufacturer defines for features unique to one model, and they are meaningless to a host that has not loaded that device's description. The first tier is portable; the second is not.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.