How to Develop and Register a WirelessHART Device

HOW TO DEVELOP AND REGISTER AWIRELESSHART DEVICEHow to Develop and Register a WirelessHART Device
Release Date: February 1, 2022
Document Number: FCG_AG10319{1.0}Document Distribution / Maintenance Control / Document Approval
To obtain information concerning document distribution control, maintenance control and document approvalplease contact FieldComm Group at the address shown below.
Copyright © 2022 FieldComm Group
This document contains copyrighted material and may not be reproduced in any fashion without the written
permission of FieldComm Group.
Trademark Information
FOUNDATION™ Fieldbus and FDI™ are trademarks and FieldComm Group®, HART®, HART‐IP®, PA‐DIM® andWirelessHART® are registered trademarks of FieldComm Group, Austin, Texas, USA. Any use of these terms
hereafter in this document or in any document referenced by this document, implies the trademark/registeredtrademark. All other trademarks used in this or referenced documents are trademarks of their respective
companies. For more information, contact FieldComm Group at the address below.

Attention: FieldComm Group, President
FieldComm Group9430 Research Boulevard Suite I‐120
Austin, TX 78759, USA Tel: +1 (512) 7792‐2300
http://www.fieldcommgroup.org

Intellectual Property Rights
The FieldComm Group (the Group) does not knowingly use or incorporate any information or data into the
HART, FOUNDATION Fieldbus and FDI protocol standards, which the Group does not own or have lawful rights touse. Should the Group receive any notification regarding the existence of any conflicting private IPR, the Groupwill review the disclosure and either (A) determine there is no conflict; (B) resolve the conflict with the IPR
owner; or (C) modify the standard to remove the conflicting requirement. In no case does the Group encourage
implementers to infringe on any individual's or organization's IPR.

Edition 1.0

Page 2 of 22©2022 FieldComm GroupHow to Develop and Register a WirelessHART Device

TABLE OF CONTENTS
1

Introduction ....................................................................................................................................................... 4

2

Why Choose WirelessHART? .............................................................................................................................. 4

3

Development and Registration Process Quick Reference Guide ....................................................................... 6

4

Product Definition, Architecture and Project Planning ...................................................................................... 7
4.1

Create Functional Requirements ........................................................................................................ 7
4.1.1

Device Type ..................................................................................................................... 7

4.1.2

Application Layer Functionality ....................................................................................... 8

4.1.3

Sensors/Actuators ........................................................................................................... 9

4.1.4Powering the Wireless Device ....................................................................................... 10

4.1.5

Operation in Hazardous Areas ...................................................................................... 11

4.2

Identify Field Device Architecture .................................................................................................... 12

4.3

The Project Team .............................................................................................................................. 13

4.4

4.3.1

Training .......................................................................................................................... 14

4.3.2

Tools .............................................................................................................................. 14

4.3.3

Registrations and Certifications .................................................................................... 15

Estimate Project Duration and Costs ................................................................................................ 15

5

Develop Functional Prototype ......................................................................................................................... 15

6

Hardware and Firmware Development............................................................................................................ 16
6.1

Hardware Development ................................................................................................................... 16

6.2

Firmware Development .................................................................................................................... 17

7

Software System Integration............................................................................................................................ 17

8

FieldComm Group WirelessHART® Field Device Registration .......................................................................... 18

9Regulatory Compliance and Certification ........................................................................................................ 20
9.1

Operation in Hazardous Areas .......................................................................................................... 20

9.2

Wireless Certifications ...................................................................................................................... 20

9.3

Additional Regulatory Compliance and Certifications ...................................................................... 21

10

Conclusion ........................................................................................................................................................ 21

11

Acknowledgments ............................................................................................................................................ 21

12

References and Resources ............................................................................................................................... 22

Edition 1.0

Page 3 of 22©2022 FieldComm GroupHow to Develop and Register a WirelessHART Device

1 INTRODUCTION
This technical paper provides a step‐by‐step guide for the development and registration process of a
WirelessHART (IEC 62591) compliant field device. It also identifies the main decisions that must be made during
the development process and helps the developer navigate these decisions.
Once the development and registration process are well understood, the developer can effectively plan thedevelopment project to reduce time‐to‐market and minimize the costs involved.

2 WHY CHOOSE WIRELESSHART?
The advent of the Internet of Things/Industrial Internet of Things (IoT/IIoT) has created an unprecedented
opportunity to optimize process automation and expand the level of plant asset monitoring in a cost‐efficientmanner. The market has seen the emergence of a wide gamut of IoT/IIoT technologies with various use‐cases.
Due to the unique foundation of the original wired Highway Addressable Remote Transducer (HART) protocol,
only the WirelessHART protocol truly addresses the connectivity, scalability, networking, device management,
determinism, application layer modeling and security demands of the industrial process environment.
Communication reliability – self‐organizing and self‐healing wireless mesh network allows
communications to the gateway without line‐of‐sight to all devices and responds to changing
interference conditions with no user‐intervention resulting in 99.99% uptime in well‐formed networks.
Time diversity (TDMA), frequency diversity (hopping) and path diversity (mesh routing) ensure that all
packets transmitted are received loss‐free with minimal latency.

Interoperability – fully defined application layer allows device manufacturers to utilize existing data
structures (reducing product development demands) to ensure interoperability with existing control
systems and data networks. There are currently over 15 registered device manufacturers and over 27
registered devices which are all fully interoperable over existing host networks from multiple
manufacturers.

Cybersecurity – detailed, mandatory defense‐in‐depth security protocols that ensure communications
and networks are secured through a two‐layer strategy. Data is authenticated hop‐by‐hop at the datalink layer and encrypted and authenticated end‐to‐end at the transport layer. As security is notconfigurable, optional or vendor designed (as with most other IoT/IIoT protocols), end users are
comfortable utilizing WirelessHART networks for process control and monitoring and critical asset
monitoring.



Scalability – the self‐organizing mesh network allows for large networks of devices to be built without
requiring line‐of‐sight to the gateways (as required by point‐to‐point protocols.) The determinism
inherent in the protocol ensures messages are transmitted and received as per the application required

Edition 1.0

Page 4 of 22©2022 FieldComm GroupHow to Develop and Register a WirelessHART Device
update rates to meet the rigorous reliability and latency requirements mandated by process
automation, even as the number of devices increases.
Full Data Context – all data points in the application layer have full context (including units, timestamps
and health) maximizing the value of the data when used in analytics with little work by the device
manufacturer or the end‐user.

Publish‐by‐exception – all field devices and adapters publish (push) process data based on process anddevice conditions. This ensures the data needed to control and monitor the plant and its assets isavailable when it is needed. It also cuts the energy needed in half to transport the process and status
data compared to polling. This published data flows through the network gateway to control andmonitoring systems associated with the plant.

WirelessHART is architected and designed to meet the rigorous requirements associated with industrial process
automation environments. Unlike other IoT/IIoT protocols that are architected to cover a wider range ofenvironments and applications, WirelessHART was specifically architected for industrial applications and theirchallenging environments. In a single plant, there are many applications that may have solutions from multiple
vendors and technologies. WirelessHART was developed with interoperability and cybersecurity as cornerstones
that enable multiple solutions to exist and communicate on the same network reliably and securely. The
industrial environment often has a very high density and variability of obstructions and interference. This isaddressed by WirelessHART with the self‐organizing and self‐healing mesh network which ensures reliablecommunication when line‐of‐sight to the wireless gateways is not always possible and may change over time.
WirelessHART is built on the solid foundation of HART, which is a widely deployed and well understoodtechnology. Since the HART protocol was first developed as an open protocol in 1986, it has evolved to cover thewide range of applications found in the industrial environment. With an estimated 50,000+ networks operatingworldwide, WirelessHART is simple to install in both new and existing plants and is easily the most common
industrial wireless protocol in use today. For the developer, this can significantly reduce the amount ofengineering effort and ensures compatibility with existing systems. For the end‐user, it dramatically reduces theintegration effort and risk involved and leverages the existing skills and knowledge of their personnel.
Unlike other IoT/IIoT standard technologies, it is a holistic, top‐to bottom, system wide standard that defines alltechnical facets of the field instruments as well as supporting infrastructure devices including wirelessconnectivity, mesh routing, networking, security, application layer encoding, management as well as network
provisioning. This allows the developer to focus on their core capabilities and fitting it into the existing structure,
rather than diluting effort into non‐core areas such as cyber‐security, application layer definition and network
management functions.
With an installed base of over 50 million devices, the ecosystem for HART and WirelessHART is huge. This
provides many advantages as FieldComm Group offers in‐depth support for developers and end‐users. Not only
are clear detailed Protocol Specifications available but so are training workshops and technical support.
WirelessHART is a very deep protocol and both WirelessHART stacks and consultations are available frommultiple vendors located in all world areas. The same Application Layer is used in HART and WirelessHART,
which builds upon the know‐how end users already have and love. The installed base of Plant AssetManagement, control systems and maintenance tools are compatible with WirelessHART enabled
instrumentation.

Edition 1.0

Page 5 of 22©2022 FieldComm GroupHow to Develop and Register a WirelessHART Device

3 DEVELOPMENT AND REGISTRATION PROCESS QUICK REFERENCE GUIDE

Figure 1: Development and Registration Process Quick Reference Guide
Edition 1.0

Page 6 of 22©2022 FieldComm GroupHow to Develop and Register a WirelessHART Device

4 PRODUCT DEFINITION, ARCHITECTURE AND PROJECT PLANNING
Product planning is the fundamental first step that defines the vision for the product‐to‐be. The choices madehere influence the product development costs. Three main considerations discussed in this section arefunctional requirements, architecture and project planning.

4.1 CREATE FUNCTIONAL REQUIREMENTS
A clear definition of requirements is essential and assumes a basic understanding of the features andmechanisms offered by the HART/WirelessHART standard. This will allow the developer to map therequirements into WirelessHART standard mechanisms. It will also allow the developer to fully utilize andleverage the powerful connectivity, reliability and security mechanisms present in the WirelessHART standard.
A clear definition of the requirements is of vital importance as it will influence the anatomy and architecture of
the field instrument. It will also determine the optimal development approach that will minimize time‐to‐market.
When embarking on the journey of developing a WirelessHART field device, there are several important choicesthat the developer will have to make.
4.1.1 Device Type
WirelessHART products generally fall into three categories: field devices, adapters and gateways (see Table 1).
The WirelessHART protocol has specific requirements for each product category with field devices being thesimplest of the three. While this technical paper focuses on the development of a WirelessHART field device, it isalso broadly applicable to developing a WirelessHART adapter.
Table 1 ‐ WirelessHART Device Types
Device Type

Functional Description

Field Device

A WirelessHART field device combines wireless communications with traditional HART
field device functions. Since the field device resides on the mesh network it also
forwards/routes wireless packets on behalf of other network devices. The field device
must include a HART 4‐20mA maintenance port for commissioning andtroubleshooting. The overwhelming majority of field devices are battery and/or energy
harvester powered.

Adapter

The adapter connects to HART 4‐20mA and to the WirelessHART mesh network. The
adapter is essentially a single‐channel remote I/O providing wireless access to"stranded" HART 4‐20mA devices. Adapters typically get power from the 4‐20mA loop.

Gateway

Gateways collect and relay data to/from the wireless mesh field network, manage the
network devices and provide connectivity to the plant network. The Gateway typicallyaggregates four different functions.
Access Point: Provides wireless connectivity between the field mesh network and the
Gateway.

Edition 1.0

Page 7 of 22©2022 FieldComm GroupHow to Develop and Register a WirelessHART Device

Device Type

Functional Description

Gateway

Network Manager: Manages all connectivity and facets of the field devices andadapters.
Gateway: Responsible for application layer connectivity between the wireless fieldmesh network and the plant network.
Security Manager: Manages the security credentials (e.g., keys, identities) andmonitors the status of the network security.

4.1.2 Application Layer Functionality
Application Layer Functionality is the definition of the application specific behavior and functionality of thedevice that is being developed. This functionality includes (but may not be limited to):

What the inputs and outputs of the device are
How will the device be commissioned, configured and calibratedCan standard HART commands be used to configure/operate the device or must device specificcommands be created to enable functionality

Will the device need to provide any external alarms

Prior to defining the field device’s application specific functionality, it is important to understand the underlying
HART/WirelessHART standard based data models and command sets.
Dynamic Variables
The HART standard relies on a bursting (publishing) mechanism where dynamic variables are transmitted
periodically with a configurable periodicity. WirelessHART supports bursting of four variables namely a PV
(primary variable), SV (secondary variable), TV (tertiary variable) and QV (quaternary variable). These variables
can be reported to the WirelessHART Gateway via wireless data packets. Additional variables can also be sent
via the bursting mechanism, with field devices often supporting multiple burst data streams where different
variable sets are being sent with different periodicities. The bursting rates are configurable and the supported
reporting rates are 1, 2, 4, 8, 16, 32 seconds or 1 to 60 minutes depending on the Network Manager that is
managing the WirelessHART field mesh network.
The HART client‐server data model is supported over the wireless communication channels where the Gateway
can read or write parameters via a client‐server type data interaction. The data exchange is acknowledged end‐
to‐end between the client and the server devices.
Command Sets
HART supports various command sets that target different functional facets of the field device. All commands
are designed so that generic host applications can use the device without need for EDDs or device‐specificdrivers.

Edition 1.0

Page 8 of 22©2022 FieldComm GroupHow to Develop and Register a WirelessHART Device

Table 2 ‐ HART Command Sets Overview
Universal
commands

Used to read device identifiers, device variables as well as configure various
HART parameters. All HART‐Enabled Field Devices must support all Universal
Commands as specified.

Common Practicecommands

A broad set of commands applicable to many field devices. Primarily focused onfield device calibration, configuring ranges as well as reading and writing otherconfiguration parameters.

Non‐publiccommands
Wireless
Commands
Device Specificcommands

Used by manufacturers during the manufacturing of the field device itself andshould remain confidential.
Used to by WirelessHART field devices, adapters and networks to manage every
aspect of the wireless communication, including provisioning, bandwidth
allocation, security, wireless co‐existence, health reporting and more.
Provide functions that are unique to a particular type of field device.

When developing a field device, the developer must map the desired application layer functionality of the fielddevice to the various commands. If the field device includes specific functionality that is not available throughthe commands defined by the standard, the developer will need to map this unique functionality in device
specific commands. To maximize interoperability, it is highly recommended to try to map all the functionality ofa device to the standard commands and reserve device specific commands to truly unique device functionality
only when necessary. The list of commands available can be found in the Command Summary Specification andthe other detailed command specifications, which are available on the HART Protocol Specifications page on the
FieldComm Group Website.
The outcome of defining the application layer functionality of the field device should be a map of commands
that the field device will support to meet the functional requirements desired.
4.1.3 Sensors/Actuators
The choice of sensors or actuators for the field device is critical. First, the sensor/actuator must be powered,measured or controlled. This dictates the interface circuitry and ripples on through the product requirements.
Second, the sensor/actuator is not powered continuously. This is a major difference compared to traditional
instrumentation. Often developers have carefully validated models characterizing sensor/actuators over time,
temperature and process conditions. These usually assume the sensor/actuator is continuously powered. Since
WirelessHART devices sleep most of the time the sensor/actuator is now intermittently powered. Therefore
sensor/actuator selection is different and faces new challenges where development of new algorithms may beneeded.
Managing the sensor/actuator can consume up to 1/2 of the power budget for a wireless device.
Edition 1.0

Page 9 of 22©2022 FieldComm GroupHow to Develop and Register a WirelessHART Device
4.1.4 Powering the Wireless Device
The power source for a field device can be line power, battery power, energy harvester or any combination ofthese.
The vast majority of WirelessHART devices are battery powered to provide the end‐user with the easiest
and most cost‐effective installation.



If the developer opts for a line‐powered device, power consumption and energy budgeting are not aconcern, but more stringent noise immunity requirements should be considered. The cost of installation
associated with power wiring should also be considered.

Energy harvesters can also be used but they typically only augment battery power and they can raise
product costs. When opting for energy harvesters the same design considerations apply as for battery
powered devices.

The vast majority of commercially available WirelessHART field devices are battery powered and this section will
focus on battery powered design issues. Battery life requirements vary from 2 – 10 years with end users insisting
on prolonged battery life to minimize the cost and disruption to the process associated with battery
replacement. Battery replacement concerns are even more accentuated when the field device operates inhazardous, incendiary and/or remote areas.
When opting for battery power the aggregate power consumption of the field device is vital since it will
determine the battery life of the field device.
4.1.4.1 Battery PowerThe battery must be chosen to meet the target battery life. Consequently, environmental impacts (e.g., installed
temperature variations), affect the chemistry of the battery and the device power consumption must be
analyzed/modeled. Most field device developers opt for high‐density battery chemistries such as lithium‐thionyl‐
chloride or other lithium‐based chemistries.
The topology of the on‐board power supply will be determined by factors such as battery pack voltage andchemistry. The on‐board power supply can be of buck or buck‐boost type depending on battery life
requirements as well as the target COGS of the field device.
Battery leakage/self‐discharge and power supply efficiency/regulation are important factors in power
consumption and thus battery life.
If the battery can be replaced, then the associated mechanics and safety must be carefully considered anddesigned.
4.1.4.2 Power Consumption
Batteries only hold so many coulombs and understanding the coulombs needed for the different field device
operations is key to estimating battery life. Device operations affecting battery life include:Managing the sensor/actuator ‐ making process measurements

Publishing process and status dataPlant Asset Management and configuration changes

Network Management (advertising, forwarding packets, etc.)Servicing the maintenance port

Edition 1.0

Page 10 of 22©2022 FieldComm GroupHow to Develop and Register a WirelessHART DevicePower supply overhead

Each of the coulomb requirements for these should be characterized and used as inputs to the battery life
model. Some of these operations are under the control of the device developer while some are controlled by
the user and Network Manager.
The communication schedule of the field device is the main determining factor for the battery life of the fielddevice. Field devices spend most of their time in deep, battery conserving sleep to prolong battery life. They only
wake up when they need to transmit or receive a data packet or engage in measurement/monitoring/control.
The wake‐up schedule is determined by the Network Manager based on several factors:How often will the field device publish process and status data or be awake to receive acyclic
communications (e.g., from Plant Asset Management).



If an actuator, how often will it receive control data.

How often must it service the mesh network (e.g., route other packets, ping neighbors, advertise, etc.).

The actual communication overhead could consume as much as half the power budget. Radio and processor
technologies are rapidly improving so the requirements of this power consumer are declining continuously.
Using this information, the developer should create a battery life model for the field device that includes allthese considerations to ensure that the marketed and advertised battery life of the field device is met. Thismodel should include "typical" operating conditions and publishing frequency.
The communication and measurement/control frequency are controlled by the user and cannot be limited by
the device itself. All WirelessHART devices equally face this challenge. Fortunately, users are becoming savvier
about the way they are using WirelessHART devices and have a good understanding that additional data costs
power/battery usage.
4.1.5 Operation in Hazardous Areas
An important design decision is related to the environment that the field device will need to operate in. Many
field devices engaged in process monitoring and control will operate in hazardous areas with the potential
presence of explosive gases, incendiary liquids and/or dusts.
If the field device is intended for operation in hazardous areas the developer will need to define the hazardous
classification that the field instrument will need to be compliant and certified to. Once these requirements arewell defined, the developer can then opt for either an explosion proof or an intrinsically safe design andcertification approach.
Intrinsically safe devices rely on the principle that the field device is not capable of causing
an explosion. Explosion proof field devices rely on the principle that should an explosion occur, it will becontained within an enclosure. Both approaches have advantages and disadvantages from a design andcertification complexity as well as the impact on the final COGS of the field device.
When designing for operation in hazardous areas, it is important to consider how the user will replace thebattery and access the wired HART maintenance port terminal.

Edition 1.0

Page 11 of 22©2022 FieldComm GroupHow to Develop and Register a WirelessHART Device

4.2 IDENTIFY FIELD DEVICE ARCHITECTURE
Most field device suppliers are domain experts on specific types of sensors (monitoring) or actuators (control).
WirelessHART expertise will be needed by the product developers to support their customers and complete theproduct development. But developing a WirelessHART stack itself is a complex and resource intensive effort thatis risk/cost prohibitive for most instrument developers. Consequently, most WirelessHART field devices use atwo‐processor architecture as shown in Figure 2. The application processor and the wireless module areconnected via a serial interface.
The figure below depicts the typical anatomy and architecture of a WirelessHART field device.

Figure 2: Field Device ArchitectureThis approach has many benefits with the main ones listed below.


Wireless modules provide the communication stack that handles about 50 wireless commands.



It reduces the in‐house wireless expertise needed to develop a WirelessHART field device. Wirelessmodules have typically already gone through modular wireless testing, compliance and certifications
and are ready to be embedded and integrated in field devices. The need to acquire expensive RF
engineering equipment and conduct measurements is avoided.



Wireless module pre‐approvals by FCC, ISED, ETSI, etc. help reduce time‐to‐market.

Wireless modules provide serial command line interfaces to which the developer can connect anapplication processor that is responsible for the application functionality of the field device.

Edition 1.0

Page 12 of 22©2022 FieldComm GroupHow to Develop and Register a WirelessHART DeviceDevelopment kits from the wireless module vendors typically provide software/firmware frameworks
that speed up the development process and shorten the product time‐to‐market.



Developers can focus on their core competency and develop the application processor hardware andsoftware.
The typical responsibilities of the wireless module and application processor are summarized in Table 3.
Table 3 – Responsibilities of Entities
Application processor

Wireless module







Implements the HART Application Layer
Connects and manages the device's sensors
and/or actuators
Publishes process and status data to the
Gateway
Shares responsibility for a few WirelessHART
commands with the wireless module
Supports the maintenance port
Note: some commands must be passed
through to wireless module
Monitors battery‐life, estimates days ofbattery remaining













Implements the WirelessHART command set
Complies with IEEE 802.15.4‐2.4GHz
requirements
Precise time management needed by the
TDMA Data‐Link Layer
Ensures all communications are secure
Routes all packets per instructions from
Network Manager
Reports network health and RF health asmeasured by the field device
Joins the network, manages connection withthe mesh network and the field device's
neighbors

4.3 THE PROJECT TEAM
Developing a WirelessHART field device requires multi‐disciplinary engineering teams. It requires expertise in
the following disciplines:A solid understanding of the HART and WirelessHART protocols

RF expertise and engineeringHardware engineering (embedded systems, sensors, actuators)



Firmware and software engineeringSoftware engineering for the development of the EDD files or other files needed to integrate withentities that reside on the plant networkCompliance and certification expertise for hazardous locations, wireless communications, EMC andother safety compliance testing

The developer staff may be allocated to one or more of these areas or elements of the project team may beoutsourced to companies and teams that have expertise and experience in developing HART and WirelessHART
field instruments. For a list of providers of development and engineering services please visit:
http://go.fieldcommgroup.org/HART‐developers

Edition 1.0

Page 13 of 22©2022 FieldComm GroupHow to Develop and Register a WirelessHART Device
4.3.1 Training
The project team will need training and support. Several sources are available including the wireless modulesupplier/partner and the FieldComm Group. The FieldComm Group provides dedicated and specific training andtechnical support on the HART and WirelessHART protocols including:Protocol Specifications and technical papers

Developer/engineering workshops

Technical support

4.3.2 Tools
Various development and testing tools will be required. These include tools from the traditional embedded
device supply chain, the wireless module supplier and the FieldComm Group. Tools available from theFieldComm Group include: HART and WirelessHART Test Systems, Wi‐Analys, FDI Device Package IDE, FSK PHY
Test Kit and HART‐IP Clients.
HART Physical Layer Test Kit. This tool is used to assess HART Frequency Shift Keying (FSK) Physical Layer
conformance. In addition to this kit, it is recommended to purchase a bipolar power supply for impedance andnoise sensitivity testing on the maintenance port.
HART Test System. The HART Test System is a complete communication development and testing package for
HART 4‐20mA (FSK) field devices. The HART Test System includes an interactive, programmable host applicationthat can be used for ad‐hoc communication with the device early in the development process (via FSK). Included
is the univ‐ht.qas script (source code) that demonstrates how a Universal Command application can besupported using HART Test System tooling.
WirelessHART Test System. The WirelessHART Test System includes a simplified Gateway and Network
Management used for testing. It also allows for ad‐hoc communication to the field device throughout the
product development process (via the wireless channel) using the same techniques used with the HART Test
System.
Wi‐Analys. Wi‐Analys is a WirelessHART packet sniffer and network analyzer. Wi‐Analys simultaneously captures
and timestamps communication on all sixteen IEEE 802.15.4 frequency channels in the 2.4 GHz frequency band.
WirelessHART communications are extracted then deciphered and parsed for easy review and assessment.
FDI Device Package IDE. The FDI Device Package IDE is used to develop and test FDI Device Packages and EDDs.
Your product's FDI Device Package (and EDD) enable immediate, complete support of products in the large
installed base of HART‐enabled Plant Asset Management Systems, handhelds and other end‐user systems/tools.
HART‐IP Clients. FieldComm Group has posted a HART‐IP Client on GitHub. These are free tools that (among
other things) enable communications with WirelessHART field devices via commercial HART‐IP Gateways. The
clients include many standard commands and allow any command (e.g., device‐specific ones) to be manuallyconstructed and sent.
The HART and WirelessHART Test Systems include HART‐IP Servers for connecting to Token‐Passing or
WirelessHART networks. The HART‐IP Clients can connect to the test appliance and communicate with the fielddevice being developed via HART‐IP servers.

Edition 1.0

Page 14 of 22©2022 FieldComm GroupHow to Develop and Register a WirelessHART Device
4.3.3 Registrations and Certifications
Many registrations and certifications are needed by the field device. These include IS/Ex (hazardous area),
wireless communication, EMC and other safety compliance testing.
The FieldComm Group operates a Quality Assurance / Quality Control (QA/QC) program for WirelessHART fielddevices. It is based upon standardized test requirements and specifications developed by its membership. These
test requirements ensure products will interoperate with other WirelessHART devices and HART‐enabledapplications. The core objective is to reduce/mitigate (not eliminate) the need for field service and technicalsupport by the device developer to end user. Field device registration testing and assessment is comprehensive
and robust. Please contact FieldComm Group for more information.

4.4 ESTIMATE PROJECT DURATION AND COSTS
Once the functional requirements and architecture have been finalized the duration of the project and the costs
must be estimated.
The duration, effort and cost associated with each project phase should be estimated to get a clear picture of
the aggregate timeline and costs.

5 DEVELOP FUNCTIONAL PROTOTYPE
The next step in the development process is to develop a functional prototype. Developing a functional
prototype is strongly recommended both to mitigate risk and for developers to begin climbing the WirelessHART
learning curve. Acquiring a WirelessHART development kit from the selected wireless module vendor is asignificant project accelerator.
WirelessHART development kits include various training materials as well as engineering documentation related
to the integration of the WirelessHART module, and all the components required to set up a simple
WirelessHART field mesh network. This includes wireless modules, development boards and a WirelessHART
Gateway that can be used to set up a WirelessHART network. Once the developer is familiar with the operationof a WirelessHART mesh network the actual prototyping work can begin.
The developer can set up the development environment using the Integrated Development Environment (IDE)of choice. Once the development environment is set up, the user can load the application processors sourcecode and compile it. The developer can start tailoring the application processor source code provided to meetthe requirements of the field device that is being developed.
The application processor source code provides a framework for developing the HART Application Layer
including Universal and Common Practice Commands. Placeholders for linking application processes like
performing sensor measurements and control may also be supplied. Consequently, the prototype can be
expanded and used as a research vehicle for developing sensor signal conditioning, signal processing and otherkey elements specific to the product envisioned. The prototype can provide valuable direct feedback for thesubsequent Hardware and Firmware development.
The developer can map parameters of interest in the four dynamic variables (PV, SV, TV, QV) and use the burst
mechanism to see these variables being reported in the Gateway. At this stage, these parameters can be
hardcoded values or real values obtained from sensors and/or actuators connected to the application processor.

Edition 1.0

Page 15 of 22©2022 FieldComm GroupHow to Develop and Register a WirelessHART Device
The developer can also send various commands to the field device prototype to become familiar with thevarious types of commands and their associated functionality. Preliminary power consumption and current draw
measurements can also be made for the purpose of building a power model for battery powered instruments.

6 HARDWARE AND FIRMWARE DEVELOPMENT
6.1 HARDWARE DEVELOPMENT
Various decisions will have to be made at the start of the hardware development and engineering effort. The
complexity of the hardware design process will vary depending on the device’s intended function – whether it
would need to be explosion proof or intrinsically safe. Once all components are selected, the developer candesign the field device circuitry. In addition to the hardware decisions based on the core device functionality,
the following components will also need to be considered.
Battery
The developer will have to choose a battery that has enough capacity to meet the power budget required by thedesired battery life. The battery chemistry is an important consideration, as it will dictate the topology andefficiency of the power supply circuitry.
Maintenance PortAll end users have HART‐enabled handhelds and the maintenance port must interoperate with these user tools.
An actual HART FSK modem IC is the key element in the maintenance port. It will be in deep sleep mode until acarrier is detected. The maintenance port must wake up when a carrier is present and receive any
communications successfully. HART has detailed requirements for maintenance ports that must be met toensure a high quality user experience.
Antenna
The WirelessHART field devices must be able to transmit with an output power in the ‐10 dBm to +10 dBm range(10 mW). Hence, the antenna will have to be chosen based on the specifications of the wireless module
selected. The antenna propagation patterns and proof of compliance to IEEE 802.15.4 are required during the
FieldComm Group registration process.
Assessing the hardware design
When a prototype of the hardware is available, it is highly recommended to run HART maintenance port
compliance with the HART Test System. The FieldComm Group will confirm compliance as part of theregistration process.
Wireless range tests and In‐house (or wireless test‐house) wireless compliance testing are also recommended toensure that the surrounding circuitry does not affect the performance and modular certification of the wirelessmodule (for example, spurious emissions, harmonics and sensitivity).

Edition 1.0

Page 16 of 22©2022 FieldComm GroupHow to Develop and Register a WirelessHART Device

6.2 FIRMWARE DEVELOPMENT
Prior to starting the firmware development process, the developer should contact the FieldComm Group andrequest an assigned Manufacturer ID and Device ID as the Device ID will be required during the development of
the Device Descriptor file. Requests for IDs are accomplished via the technical support portal.
The firmware development process is focused on two main facets:
1. Integration of the wireless module with the application process, which is done in accordance with the
API documentation provided by the wireless module vendor.
2. Developing the field device specific application layer functionality on the application processor. The
sensing or control circuitry and parameters of interest will need to be mapped to HART commands andmechanisms.
Once the integration of the wireless module and the application processor development is completed, thedeveloper will have to focus on the power consumption of the entire field device. During this development
phase the developer will fine tune the current draw and overall power consumption of the field instrument.
Since both the application processor and wireless module should spend as much time in sleep mode as possible,
fine tuning and coordinating all of the field device’s internal entities, including the HART maintenance port will
have a significant impact on the battery life of the field instrument.
The FieldComm Group offers various tools that are invaluable during the development process.
The WirelessHART Wi‐Analys tool is a WirelessHART packet sniffer and network analyzer that is very usefulduring the development and debugging process. Wi‐Analys captures and deciphers WirelessHART
communications enabling product development and compliance assessment. Wi‐Analys includes a FieldComm
Group patented 16‐channel IEEE 802.15.4 receiver that captures radio communications on all frequency
channels simultaneously.

7 SOFTWARE SYSTEM INTEGRATIONA HART Device Descriptor file (DD file) and FDI Device Package are required and submitted as part of theFieldComm Group HART registration process.
The DD file enables the field device to interact with the WirelessHART Gateway as well as other software entities
running on the plant network (DCS, PCS, configuration and diagnostics software, historians, etc.). The DD filemodels all the capabilities of the field device, including:Commands supported



Configuration parameters

User interface

A comprehensive and well‐organized DD file is critical to the successful development of a WirelessHART device
as it will dictate the way end users interact with it and should be done in parallel with the firmware
development process. The DD file is developed and modeled using Data Definition Language (DDL). The DD
developer must have expertise in the operation, behavior and capabilities of the field device for which the DD isbeing written, to ensure all required functionality is configured correctly.

Edition 1.0

Page 17 of 22©2022 FieldComm GroupHow to Develop and Register a WirelessHART Device
The use of standard methods and commands is encouraged; however, device specific commands are also
allowed and are required in some cases to activate certain features on the device.
An Enhanced Device Descriptor (EDD) provides graphical elements that stand apart from the traditional
hierarchical text menus. A good DD design will greatly simplify device configuration and not overwhelm the user
looking to perform a specific task.
The Device Descriptor can be ported for use on a variety of host systems and integration testing with various
entities including asset management packages as well as handheld configuration tools are highly recommended.
It is a good idea to purchase the respective tools or simulate the Device Descriptor on a virtual device as a partof the development process. Several manufacturers provide virtual hosts and test kits so that the Device
Descriptor can be evaluated on the target platform.
The FieldComm Group offers all the software tools needed to develop and validate a DD file. The FDI Device
Package IDE makes writing, running and testing of FDI Device Packages and EDDs easier and more efficient by
providing a single tool for development and testing.

8 FIELDCOMM GROUP WIRELESSHART® FIELD DEVICE REGISTRATIONA core objective of the FieldComm Group is to assist in the development of compliant, interoperable HART‐
enabled products. The member‐developed protocol specifications are the first step. They are detailed anddesigned to ensure interoperability. The FieldComm Group also offers a QA/QC program to further ensure
successful device operation and integration into plant systems.
WirelessHART devices successfully completing the standardized QA/QC program become "HART Registered".
This badge indicates the field device meets all the protocol requirements needed for proper field operation as
well as interoperability with other WirelessHART field devices and host systems.
The figure below provides a snapshot of the steps that are part of the FieldComm Group HART registration
process. Utilizing the FieldComm Group QA/QC resources should accompany other steps in the development
process.

Join FieldComm
Group (FCG) as
MemberPurchase Test
Tools from FCG

Perform Internal
Registration Tests

Submit ProductRegistration Kit

Pass FCG
Registration Tests

Field Device
Registered and
ListedFigure 3: FieldComm Group HART Registration Process

Step 1: Join FieldComm Group
Joining the FieldComm Group as a member has many benefits. It provides an opportunity to contribute to andshape future IIoT technologies. It also provides discounted pricing to a large gamut of training, development,compliance testing and registration tools as well as access to the Protocol Specifications and standardized testplans (specifications). Members also have priority access to FieldComm Group’s technical support team.

Edition 1.0

Page 18 of 22©2022 FieldComm GroupHow to Develop and Register a WirelessHART Device
Step 2: Purchase Test Tools
The FieldComm Group offers a complete suite of protocol‐specific tools to help in product development. They
are extremely useful during the development process as they enable ad‐hoc field device testing and ensure
implementation is correct during every stage of the development process.
The test tools also include test automation. The test automation is run on top of the tools and align with themember‐developed test specifications.
Step 3: Perform Internal Pre‐registration Testing
The developer must perform Quality Control of the field device. QC includes both field device‐specific testing
and using the test automation provided with the FieldComm Group supplied tools. Table 4 below lists anddescribes the various QC tests the developer should perform and are required to obtain FieldComm Group HART
registration.
During the internal pre‐registration testing phase, the developer should collect all test logs and results since theymust be submitted as part of the registration package.
Table 4 ‐ Compliance Assessment
Test

Description

Physical Layer Testing

Confirms FSK maintenance port compliance

Data Link Layer Tests

Tests the Token Passing DLL used by the maintenance port

TDMA Data‐Link and Mesh
Network Layer (TML)

Assesses WirelessHART mesh network compliance. While the bulk ofthese are applicable to the wireless module there are somerequirements that must be fulfilled by the application processor.

Universal Command Testing Tests Universal Commands over both the maintenance port and thewireless channel.
Common PracticeCommand Testing

Tests the Common Practice Commands over both the maintenanceport and the wireless channel.

System Level Tests

Ensures interoperability and proper long‐term reliable operation withcommercial products (devices and Gateways). The System Level Test
must be performed in a multi‐hop multi‐vendor mesh network.

FDI Device Package Testing

Confirms that the EDD complies with all EDDL and HART Protocol
Requirements. Ensures the FDI Device Package is secure, well‐formed
and meets all FDI requirements.

The TML and System Level tests are arduous and require considerable WirelessHART knowledge. This QC step
can be contracted to the FieldComm Group for a nominal fee. It is highly recommended to have the FieldComm
Group run at least the System Level tests on behalf of the developer.

Edition 1.0

Page 19 of 22©2022 FieldComm GroupHow to Develop and Register a WirelessHART Device
Step 4: Submit Product Registration Kit
Once all internal pre‐registration tests have been successfully passed, the developer will collate the FieldComm
Group registration package. The registration package consists of:All test logs and resultsSupporting documentation for functional and standards compliancePassed wireless certifications



The DD file and FDI Device Package

Proof of Wireless PHY compliance must also be provided, including:IEEE 802.15.4 compliance test results

Wireless compliance test results (FCC, ETSI etc.)Antenna radiation patterns

Step 5: FieldComm Group Registration Testing Phase
The official registration process is triggered by the submittal of the registration package and a purchase orderthat lists the type of registration testing being requested. Upon receipt, the FieldComm Group team willschedule a test campaign and inform the developer of the start date of the test campaign. Two field instruments
will have to also be submitted to be used as “Devices Under Test” (DUT’s).
The developer must promptly respond to any requests received from the FieldComm Group team during thetesting process.
Step 6: Field Device Registered and Listed
Once the FieldComm Group confirms that all registration tests have been successfully passed and all
requirements have been met, the DD file will be sent out for testing with various host systems.
The field device will be registered and listed in the FieldComm Group repository and the DD file and FDI Device
Package will be available for download on the FieldComm Group website (fieldcommgroup.org).

9 REGULATORY COMPLIANCE AND CERTIFICATION
9.1 OPERATION IN HAZARDOUS AREAS
If the field device is designed for operation in hazardous areas, it will also need to go through various
compliance tests and certification processes. Field devices that need to operate in hazardous locations are
typically certified to operate in areas classified as Class 1 Division 1 and/or ATEX Zone 0 areas for various groupsof gases, liquids and incendiary dusts/fibers as needed.

9.2 WIRELESS CERTIFICATIONS
Any wireless device also must be compliant to various wireless regulations and obtain certifications in various
countries and regions of the world where it will be used.

Edition 1.0

Page 20 of 22©2022 FieldComm GroupHow to Develop and Register a WirelessHART Device
The WirelessHART wireless module will typically already have modular wireless certifications for operation invarious countries.
In the USA and Canada, additional product level wireless compliance testing is needed beyond the FCC Part 15
modular certification of the wireless module. The product will have to pass FCC/ISED Part 15, Unintentional
Radiators, Subpart B, Section 15.101. These compliance tests ensure that the wireless module’s supporting andafferent circuitry did not cause the already certified wireless module to operate outside the boundaries of its
modular certification.
No additional product level wireless compliance testing of certifications is needed in other regions and countriesof the world, such as the EU and Japan once the wireless module is certified (EU – ETSI 300 328, Japan
Certification Ordinance Article 2‐1‐19). The developer will have to conduct internal measurements and provide acompliance statement stating that the product relies on the wireless module’s modular certification.

9.3 ADDITIONAL REGULATORY COMPLIANCE AND CERTIFICATIONS
The field device will typically also have to pass various additional EMC, RF immunity, ESD and safety compliancetesting.
It is recommended that the product also be compliant and certified to:EN 301 489‐1 V2.1.1

EN 301 489‐17 V3.1.1



EMC emissions compliance per EN55032



ESD compliance per ESD 6100‐4‐2

RF Immunity per EN6100‐4‐3Safety compliance testing per LVD EN 60950‐1:2005 +A1:2009 +A2:2103 and EN62368

10 CONCLUSION
This tutorial presents a step‐by‐step approach for the development process of a WirelessHART field device. It
also identifies the main decisions that must be made during the development process.
Developing a WirelessHART compliance and registered field device does not have to be a daunting endeavor.
Once the development and certification process are well understood, the developer can optimally plan thedevelopment project to reduce time‐to‐market and minimize the costs involved. Once the device is designed,
developed and certified, the developer will have access to more existing industrial wireless field device networks
and host systems than any other IIoT protocol and will benefit from the trust and familiarity that end‐users havewith the WirelessHART Protocol.

11 ACKNOWLEDGMENTS
FieldComm Group would like to thank the following individuals for their invaluable contributions, expertise andassistance with creating this document.
Robert Assimiti – Centero
Edition 1.0

Page 21 of 22©2022 FieldComm GroupHow to Develop and Register a WirelessHART Device
Anthony Cerminara – United Electric Controls
Shane Hale – Emerson Automation Solutions
Eric Rotvold – Emerson Automation Solutions

12 REFERENCES AND RESOURCES
1.
2.
3.
4.
5.
6.

Romilly Bowden, HART® Technology – A Technical Overview, ISBN 9781549862274
Gerrit Lohmann, Wireless Technologies – WirelessHART® ‐ A Technical Paper
Emerson, Industrial IoT Devices: WirelessHART® and 5G
FieldComm Group, WirelessHART Bootcamp
FieldComm Group, WirelessHART Brochure
FieldComm Group, Intrinsically Secure WirelessHART® Field Device Networks and the Industrial Internetof Things (IIoT)
7. FieldComm Group, HART Specifications. https://www.fieldcommgroup.org/hart‐specifications
8. FieldComm Group, HART Device Testing Tools User Guide (FCG‐PS20066)

Edition 1.0

Page 22 of 22©2022 FieldComm Group