HART PROTOCOL SPECIFICATIONS
The FieldComm Group is the developer, owner and standards organization for the HART Communication Protocol establishing and controlling new technology developments and enhancements that support the needs of the process automation industry. FieldComm Group manages the HART Protocol Specifications and other related documents and provides related services and applications to end users.
The HART Protocol Specifications Kit is a collection of 17 documents that specify all the aspects of the HART protocol.
This document identifies the revision level of the HART Communication Protocol; phrases commonly used throughout the Protocol; and the documents that comprise the HART Protocol Specification. Any product claiming compliance with the HART Protocol must meet all specifications defined by this document and the indicated revision level of the specification documents included by reference. Referenced documents define the different elements of the protocol (i.e., Data Link Layer, Physical Layer, and Application Layer). In addition, this document defines the mechanisms for identifying the HART Communication Protocol Specification, the revision level of the specification and approval of changes to the specification.
The HART Physical Layer Specification provides information necessary to construct and use HART networks and devices.
This document is devised to:
- Promote interoperability among HART devices.
- Supply guidelines for acceptable communication under a variety of conditions.
- Provide guidelines for minimization of interference to and from 4-20 mA signaling.
This document specifies the HART C8PSK Physical Layer and provides information necessary to construct and use C8PSK compatible devices and networks.
This Specification is devised to:
1. To guarantee interoperability between HART FSK and C8PSK devices;
2. Define C8PSK signaling requirements; and
3. Specify the data coding, scrambling and equalization requirements for the C8PSK Physical Layer.
C8PSK communications (if supported) must meet all requirements specified in this document. Furthermore, several sections of this specification incorporate requirements found in the corresponding (i.e., same numbered) section of the FSK Physical Layer Specification. Whenever this occurs, conformance with the requirements, included by reference, from the FSK Physical Layer Specification is mandatory.
The C8PSK Physical Layer is designed to be backward compatible with both current loop and FSK signaling and, as a result builds on the requirements found in the FSK Physical Layer Specification. Conformance to all requirements found in the FSK Physical Layer Specification is a prerequisite to conforming to this specification. Furthermore, all C8PSK implementations must automatically detect and demodulate either FSK or C8PSK communications.
This specification defines the WirelessHART Physical Layer. This specification is used for devices implementing wireless mesh network communication as defined by the HART specifications. The Physical Layer is responsible for the signaling method, signal strength, device sensitivity, and environment for sending bits across the network media. This Wireless Physical Layer Specification is based on the IEEE STD 802.15.4-2006 2.4GHz DSSS Physical Layer employing O-QPSK modulation.
This document includes:
- Specific Physical Layer requirements many of which are adopted directly from IEEE STD 802.15.4-2006. It also provides specific requirements on channels, transmit power, and receive sensitivity.
- Service definitions the Physical Layer provides to higher layers to send and receive data on the media. It also defines the local management parameters used to control the operation of the Physical Layer.
- Specifies Physical Layer requirements to ensure interoperability among HART devices.
This specification defines the HART TDMA Data-Link Layer. This specification is normally used for mesh network communications via an IEEE STD 802.15.4-2006 Physical Layer. The Data-Link Layer is responsible for the secure, reliable, error free communication of data between HART compatible devices. In other words, this document specifies the rules used by HART products to wirelessly communicate HART digital information.
This document includes:
- The services provided by the Data-Link Layer to the Network Layer. These services constitute a "black box" model of the Data-Link Layer requirements. These services are specified with the assistance of Time Sequence Diagrams.
- Logical Link Control (LLC) requirements including the format of HART frames, the structure of HART device addresses; the security services used for message integrity and the error detection coding to be used.
- Medium Access Control (MAC) rules ensuring that transmissions by devices occur in an orderly fashion. In other words, the MAC specifies when a device is allowed to transmit a message. MAC specifications themselves are formulated in terms of state transition diagrams, which permit an unambiguous description of the action of the MAC sub-layer.
- The actual timing values required for proper operation of the MAC sub-layer. These timing values directly correspond to Physical Layer performance characteristics (e.g., Clear Channel Assessment time, Tx/Rx turnaround time).
This specification defines the HART Protocol Data Link Layer. The Data Link Layer is responsible for the reliable, error free communication of data between HART compatible devices. In other words, this document specifies the rules used by HART products to communicate digital information over a physical link.
This document includes:
- The services provided by the Data Link Layer to the Application Layer and the services required of the underlying Physical Layer are specified. These service constitute a "black box" model of the Data Link Layer requirements. These services are specified with the assistance of time sequence diagrams.
- Logical Link Control (LLC) requirements including the format of HART frames, the structure of HART device addresses (both master and slave); and the error detection coding to be used. In effect, the LLC adds addressing and framing information to the command and data fields supplied by the Application Layer.
- Medium Access Control (MAC) rules ensuring that transmissions by devices occur in an orderly fashion. In other words, the MAC specifies when a device is allowed to transmit a message. MAC specifications themselves are formulated in terms of a state transition diagrams. This notation allows an unambiguous description of the action of the MAC sub-layer.
- The actual timing values required for proper operation of the MAC sub-layer. These timing values directly correspond to Physical Layer performance characteristics (e.g., carrier turn on times). In addition, the Physical Layer requires preambles to be added to the HART Protocol Data Unit (PDU).
The segregation of requirements into these four categories is intended as a frame of reference rather than as a description of an actual implementation. While actual implementations may vary, all requirements in this
specification are mandatory.
This specification specifies and establishes the Network Layer and Network Management requirements for HART-compliant networks. The Network Layer is the point of convergence for traditional HART Token-Passing Networks, WirelessHART TDMA-based networks and HART over IP (see Figure 1). Above this layer resides the HART Application Layer that defines allowed HART data types, procedures and commands. Below this layer reside the two major HART disciplines: wired Token-Passing networks, and TDMA wireless communication technologies. In other words, this document specifies the rules used by HART products to communicate via the Network Layer over either wired or wireless HART networks.
This document includes:
- An overview of Network Layer requirements.
- Network Layer service requirements. These are segregated into common communication services and technology specific management services.
- Wired and wireless Network Layer specifications.
- HART-IP specifications.
- Common Network Management procedures.
This specification provides the core Application Layer requirements for HART-compatible devices. The Application Layer builds on the requirements specified for the Network Layer. While the Network Link Layer is responsible for the error-free end-end transmission of messages, it does not interpret message content. The Application Layer is responsible for message content, including the definition of commands and the interpretation of data. Thus the message's core payload is the focus of the Application Layer.
This document specifies:
- The allowable formats of data transmitted via the Protocol;
- Revision rules for all field devices;
- The allocation of Commands Numbers for use by Universal, Common Practice, Device-Specific and Device Family commands;
- The requirements for the construction of any HART command;
- The Command Status Bytes required to be returned with all commands responses;
- The use of Dynamic and Field Device Variables; and
- Procedures used by masters to identify field devices and manage HART networks
This document is an Application Layer specification and, as a result, builds on the Application Layer requirements found in the Command Summary Specification (HCF_SPEC-99). Conformance to the Universal Command Specification requires Command Summary Specification conformance as a prerequisite. This document supersedes all previous revisions of the Universal Command Specification.
The Universal Command Specification contains definitions of all HART Protocol Universal Commands. HART compatible devices must implement all universal commands exactly as described within this specification. Many Universal Commands refer to tables from the Common Tables Specification (HCF_SPEC-183). When Common Tables are referenced, data from the tables must be used exactly as specified.
The Common Practice Command Specification is an Application Layer specification and, accordingly, builds on the Application Layer Requirements found in the Command Summary Specification. Conformance to all
requirements of the Command Summary Specification is a prerequisite to conforming to this specification.
This specification contains both the definitions and the recommended usage of Common Practice Commands.
Common Practice Commands, if used, must be implemented exactly as specified. Many Common Practice
Commands refer to tables from the Common Tables Specification. When Common Tables are referenced, the
tables must be used exactly as specified. This document supersedes all previous revisions.
The Wireless Command Specification is an Application Layer specification and accordingly builds on the Application Layer Requirements found in the Command Summary Specification. Conformance to all requirements of the Command Summary Specification is a prerequisite to conforming to this specification.
This specification contains both the definitions and the recommended usage of Wireless Commands. Wireless Commands, if used, must be implemented exactly as specified. Many Wireless Commands refer to tables from the Common Tables Specification. When Common Tables are referenced, the tables must be used exactly as specified.
This specification contains commands that must be implemented by a Network Manager and Gateway. It also provides standard commands that must be implemented for the configuration of each device’s Physical Layer, Data Link Layer as well as Network Layer.
Device Families is an Application Layer specification and, accordingly, builds on the Application Layer Requirements found in the Command Summary Specification. Conformance to all requirements of the Command Summary Specification is a prerequisite to conforming to this specification.
This specification includes:
- The requirements for the definition and maintenance of Device Family Specifications; and
- Individual Device Family Specifications that are incorporated (by reference) in the Device Families Command Specification
The Common Tables Specification is an Application Layer specification and, accordingly, builds on the Application Layer Requirements found in the Command Summary Specification. Conformance to all requirements of the Command Summary Specification is a prerequisite to conforming to this specification.
The Common Tables Specification contains a collection of standard lookup tables (e.g., Engineering Units, Manufacturer Identification Code, etc.) used throughout the Protocol. Commands defined by the HART Protocol and device-specific commands often reference these tables. When a Common Table is referenced by a command, the table or subset of the table must be used exactly as specified. Furthermore, undefined (i.e., unlisted) codes must not be used in any device.
The Block Data Transfer Specification defines a reliable, stream oriented, Transport Layer service for the HART Protocol. The operation of the block transfer is specified as well as the services supplied to the HART Application Layer. Block transfer is accomplished via a virtual connection to a "Port". Each Port provides specific functionality that defines the content of the data stream.
In addition to specifying the operation of the block transfer, the content and functionality of the Ports are specified. Each Port Specification is a separate sub-document that is incorporated (by reference) into this specification.
This specification contains the rules that must be followed when defining a new Port Specification and when performing modifications to this specification. Among these rules are requirements to publish proposed Port Specifications to allow review and comment by the FieldComm Group membership. These proposed Port Specifications vary in maturity from Concept to Final. As part of this Port Specification development process a proposed Port Specification cannot be included into the Block Data Transfer Specification until proven in device implementations. As a result, incorporation into HART compatible products should only occur after a "Final" Port Specification is published. Furthermore, the FieldComm Group staff must be notified of any products using the Port Specification prior to its inclusion into the Block Data Transfer Specification.
This document is an Application Layer specification and, as such, builds on the Application Layer requirements found in the Command Summary Specification (HCF_SPEC-99).
This specification defines compliance requirements for Discrete Devices. For compliance purposes, a Discrete Device shall be classified as one of three different product types. These product types are:
- Discrete Field Devices are support discrete sensors and/or actuators in the field. These devices support only discrete inputs, outputs, and associated diagnostics. In other words Discrete Field Devices must support Discrete Variables. Discrete Field Devices often include smart, predictive diagnostics about the sensors, actuators or the connected plant equipment.
- Hybrid Field Devices include both Continuous and Discrete capabilities. These devices combine both the capabilities of traditional HART Process Automation Field Devices and Discrete Field Devices. Hybrid field devices must support both Process Variables (i.e. Device Variables) and Discrete Variables.
- Discrete Adapters that connects a PLC1 to a HART Network or HART-enabled I/O System. The Discrete Adapter must provide access to the registers inside the PLC and may allow the PLC program to be read/written via the HART Network using Block Data Transfer. Discrete Adapters must support Discrete Variables that are, in turn, mapped to PLC Registers.
Discrete and Hybrid Field Devices may support a Discrete Logic Execution Unit (DLEU). A DLEU is a simple logic engine that allows local control actions to be specified and executed thus avoiding network communication and central controller latency.
This Specification stipulates requirements for each of these device types, commands that they must support and Standard Operating Procedures (SOPs) that must be incorporated/supported. Discrete Devices are HART Devices and must comply with all HART Specifications. Where required, specific requirements (e.g., Common Practice Commands) are incorporated for other HART Specifications.
Document control procedures are also specified.
This document is an Application Layer specification and, as a result, builds on the Application Layer requirements found in the Command Summary Specification (HCF_SPEC-99). Conformance to the Universal Command Specification requires Command Summary Specification conformance as a prerequisite.
This specification defines compliance requirements for specific WirelessHART device types. For compliance purposes, a WirelessHART product shall be classified as one of five different product types. These product types are:
- Field Devices are mounted in the process and must be capable of routing packets on behalf of other devices. In most cases they characterize or control the Process or process equipment. A Router is a special type of field device that does not have a process sensor or control element and as such does not interface with the process itself.
- Adapters connect to existing HART compatible field devices and enable communication to them via a WirelessHART Network. Adapters must route messages to and from their subdevices and other devices in the network.
- Gateway enables communications between Host Applications and devices that are members of the WirelessHART Network. The Gateway has one or more Access Points interconnecting the Plant Automation Network and the WirelessHART Network.
- Handhelds and other Maintenance Tools are portable applications used to configure, maintain or control plant assets. Only portable equipment directly connecting to the WirelessHART Network fall into this category.
- The Network Manager is responsible for configuration of the network; scheduling communication between Network Devices; management of the routing tables and monitoring and reporting the health of the WirelessHART Network.
The specification begins with an overview of the WirelessHART Network. The specification describes in detail each of the five device types summarized above.
This document is an Application Layer specification and, accordingly, builds on the Application Layer Requirements found in the Command Summary Specification. Conformance to all requirements of the Command Summary Specification is a prerequisite to conforming to this specification.
Response Codes indicate command completion status that may be returned by a Field Device in response to a host application's HART command. The most significant bit of the Response Code is always set to zero to differentiate the Response Code from a Communication Error summary (see the Command Summary Specification). As a result, the Response Code is encoded as a 7-bit enumeration (i.e., as an enumeration between 0 and 127).
This document specifies all requirements pertaining to the assignment, classification, definition and application of Response Codes. Response Codes in all commands, whether defined by the Protocol Specifications or device-specific commands defined by a manufacturer, must follow the requirements in this document.
The HART Test Specifications is a collection of documents that specify the different testing procedures for HART devices and systems. These documents are required to adequately understand how to test products developed to the HART standards.
This document defines tests for HART Data Link Layer requirements. Data Link Layer Tests become useful early in the development life-cycle, usually, after initial Physical Layer development and testing is complete. In addition to Data Link Layer requirements, several Application Layer commands are used to execute these tests.
The intent of the FSK Physical Layer Test Specification is to define conformance tests for HART devices so as to promote Physical Layer interoperability between devices. This document outlines all recommended tests, procedures and equipment necessary to determine conformance of all devices designed to the HART FSK Physical Layer Specification.
This document defines conformance tests for the HART Universal Commands. Conformance with the Universal Command Specification is mandatory. This Test Specification provides Field Device implementers with a set of tests to assist in verifying conformance to the Application Layer and Universal Command requirements. Field Devices must successfully complete all tests outlined in this test specification.
This document defines conformance tests for the HART Common Practice Commands. Developers of Field
Devices must use these conformance tests to improve the probability of conformance for their device to the HART Common Practice Command Specification. Field Devices must successfully complete all applicable tests in this document. In other words, if a Common Practice Command is implemented in a Field Device, then its implementation must pass the corresponding tests in this Specification. Common Practice Commands that are not implemented are not tested.
This document defines the test criteria for FieldComm Groups’ HART EDD technology. Tests are comprised of manual source code inspection and automated verifications performed by the latest released EDD developer tools.
This document defines conformance tests for the HART Master Data Link Layer (Master DLL). Developers of a HART Master Device must use these conformance tests to improve the probability of conformance for their device to the HART Data Link Layer Specification. A HART Master Device must successfully complete all applicable tests in this document.
This specification will be available once it is released.
This Test Specification provides implementers of WirelessHART Devices with a set of standardized tests to assist in verifying conformance to all Protocol requirements. Devices must successfully complete all applicable tests in this document.
This specification will become available once it is released.
FieldComm Group members get free electronic downloadable access (please contact support if you do not have an account). General public can view these documents in the FieldComm Group document library and purchase them from our online store. Specifications and documents ordered as a non-member will be provided as a hard copy only. All items are sold and shipped from our Austin, TX location. Shipping is included, but any customs fees assessed by different countries and locales are the responsibility of the ordering company and will not be paid by FieldComm Group.