Rosemount Engineering Guide: System Engineering Guidelines IEC 62591 WirelessHART Manuals & Guides

System Engineering Guidelines

Engineering Guidelines

00809-0100-6129, Rev AB

February 2016

IEC 62591 WirelessHART

®

February 2016

1.1 Preface

These “System Engineering Guidelines” apply to end user adoption of WirelessHART self-orga­nizing mesh networks to automate process manufacturing. Following the guidelines will help
users take full advantage of WirelessHART systems.

The document provides complete technical guidance for using WirelessHART devices and
applications. The information presented applies to all IEC 62591 WirelessHART installations,
independent of brand. Vendor-specific ‘value added’ features are not included.

PART I of the guideline addresses use of WirelessHART technology in project execution from the

Appraise (conceptual design) stage through to the Pre-FEED (Front End Engineering and
Design), FEED, Execute and Operation stages. PART II describes the Field Network components
that comprise WirelessHART networks.

The guidelines describe WirelessHART system functions and capabilities, networks and alternate
modes of operation, and step-by-step procedures for system access and use. This document

assumes the reader is proficient with HART
unique aspects of deploying WirelessHART systems. Unless stated otherwise, the reader should
assume the project phases and steps are the same for HART and WirelessHART instrumentation.

Engineering Guidelines

00809-0100-6129, Rev AB

®

instrumentation. Therefore it focuses on the

This guideline summarizes the essential pre-requisites and general guidelines necessary for
smooth execution of the project that contains WirelessHART Technology. The guidelines are
applicable for small and large scale projects.

The technical guidelines are for use only by qualified personnel capable of observing the safety
instructions from device manuals. The document is provided on an “as is” basis only and may be
subject to future revisions without notice. The authors and contributors will not be responsible
for any loss or damage arising out of or resulting from a defect, error or omission in this
document or from personnel use or reliance on this document.

We want to hear from you

Your comments and suggestions will help us to improve the quality of system engineering
guidelines. If you have any suggestions for improvements, comments, recommendations or a
query, feel free to send feedback to a Wireless Specialist at [e-mail].

1.1.1 Definitions and acronyms

The following definitions are used within this document.

Ancillary device

Any device that does not contain measuring sensor or output to the process for actuation.

Gateway

Enables communication between wireless field devices and host applications connected to an
Ethernet, Serial, or other existing plant communications network; management of the wireless
field network; and management of network security. Conceptually, the Gateway is the wireless
version of marshaling panels and junction boxes. The Gateway functionality may also exist in
native WirelessHART I/O cards with field radios.

ii

Engineering Guidelines

00809-0100-6129, Rev AB

Host system

Any system accepting data produced by the WirelessHART Field Network (WFN). This could be a
DCS, PLC, RTU, Data Historian, asset management software, etc.

Join key

A 128 bit security key used to authenticate wireless field devices when joining the network,
including encryption of the join request.

A common Join Key may be used among all devices on a given network, or each device may have
a unique join key.

Note

When displayed in hexadecimal format via a browser or handheld, this results in a 32 character
hexadecimal field.

Network ID

February 2016

Each Gateway at a facility or location should be programmed with a unique Network ID. All
authenticated wireless field devices with the same Network ID will communicate on the same
network and Gateway.

Update rate

The user specified interval at which a wireless field device will detect a measurement and
transmit the measurement to the Gateway (i.e. sample rate). The update rate has the largest
impact on battery life due to the powering of the device sensor. Update rate is independent of
radio transmissions required for mesh peer-to-peer communication, “hopping” via multiple
devices to transmit a measurement back to the Gateway, and downstream communications
from the host system to the wireless field device.

Wireless adapter

Enables an existing 4-20 mA, HART-enabled field device to become wireless. Adapters allow the
existing 4-20 mA signal to operate simultaneously with the digital wireless signal.

Wireless field devices

Field device enabled with a WirelessHART radio and software or an existing installed
HART-enabled field device with an attached WirelessHART adapter.

Wireless field network

A self-organized network of wireless field devices that automatically mitigate physical and RF
obstacles in the process environment to provide necessary bandwidth for communicating
process and device information in a secure and reliable way.

Wireless repeater

Any wireless field device used to strengthen a wireless field network (by adding additional
communication paths) or expand the total area covered by a given mesh network.

iii

February 2016

1.1.2 Acronyms

The following acronyms are used within this document.

Abbreviation Description

™

AMS

CSSP Control Systems Security Program

DCS Distributed Control System

DD Device Descriptor

DSSS Direct-Sequence Spread Spectrum

FAT Factory Acceptance Test

FEED Front End Engineering and Design

HART Highway Addressable Remote Transducer

HMI Human Machine Interface

LOS Line of Sight

NFPA National Fire Protection Association

PDF Process Flow Diagram

P & ID Piping and Instrument Design

PLC Programmable Logic Controller

RF Radio Frequency

RSSI Received Signal Strength Indicator

SIT Site Integration Test

SPI Serial Peripheral Interface

SPL Smart Plant Layout

TSMP Time Synchronized Mesh Protocol

TSSI Temporal Single-System Interpretation

UDF User Defined Fields

WFN WirelessHART Field Network

Engineering Guidelines

00809-0100-6129, Rev AB

Asset Management System

iv

Reference Manual

00809-0100-3251, Rev AB

Contents

1Section 1: Introduction

2Section 2: Project Concepts

Contents

February 2016

1.1 Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii

1.1.1 Definitions and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii

1.1.2 Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv

1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

1.3 WirelessHART in project execution lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

2.1 Section overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

2.2 Traditional approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

2.3 WirelessHART approach: technology assessment. . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3Section 3: Appraise

3.1 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

3.2 Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

3.3 Operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.4 Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

3.5 Appraise phase documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.5.1 Reference documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

3.5.2 Deliverables from the philosophy document . . . . . . . . . . . . . . . . . . . . . . . . . 9

4Section 4: Pre-FEED

4.1 Section overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

4.1.1 WirelessHART for control and monitoring applications . . . . . . . . . . . . . . .12

4.2 Cost benefit study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

4.3 Preliminary design basis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

4.4 Project references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

4.5 Pre-FEED documentation and tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

4.5.1 Reference documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

Contents

4.5.2 Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

5Section 5: Front End Engineering Design

5.1 Section overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

5.2 Scope definition of engineering execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18

i

Contents

February 2016

Reference Manual

00809-0100-3251, Rev AB

5.3 Environmental considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

5.4 WirelessHART functional design requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

5.4.1 WirelessHART functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

5.5 WirelessHART infrastructure requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

5.6 Operational requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

5.7 Design inputs documents review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

5.8 Development of basis for design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

5.8.1 Design guidelines for WirelessHART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

5.8.2 Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

5.8.3 Proof of concept test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

5.9 Initial design review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22

6Section 6: Execute

6.1 Section overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

6.2 WirelessHART Field Network – Design Engineering Overview. . . . . . . . . . . . . . . .25

6.3 Design resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

6.4 Wireless device selection based on process measurement . . . . . . . . . . . . . . . . . .25

6.4.1 Process monitoring and control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

6.4.2 Equipment measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

6.4.3 Health and safety systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

6.4.4 Environmental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

6.5 Design criteria development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

6.6 Identify candidate measurement points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

6.7 Database field for wireless network assignment . . . . . . . . . . . . . . . . . . . . . . . . . . .27

6.8 Network design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28

6.8.1 WirelessHART field network – design guidelines . . . . . . . . . . . . . . . . . . . . .29

6.9 Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29

6.10Detailed design specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

6.10.1 Designing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

6.10.2 Post installation considerations for control and high speed networks . .37

6.10.3 Minimizing downstream messages for wireless output control devices.38

6.11 Spare capacity and expansion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38

6.12 Fortifying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38

6.13 WirelessHART availability and redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39

6.14 WirelessHART security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40

6.15 Alarm handling with WirelessHART devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40

6.15.1 Alarm recommendations for process plant . . . . . . . . . . . . . . . . . . . . . . . . .42

ii

Content s

Reference Manual

00809-0100-3251, Rev AB

Contents

February 2016

6.15.2 Alarm priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43

6.16 Data sheet parameters for WirelessHART transmitter. . . . . . . . . . . . . . . . . . . . . .43

6.17 Tools and documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44

6.17.1 Functional design specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44

6.17.2 Instrument index/database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44

6.17.3 Instrument data sheets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44

6.18 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44

6.19 Factory Acceptance Test (FAT). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45

6.19.1 Factory staging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45

6.19.2 Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45

6.19.3 FAT requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46

6.19.4 FAT network configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46

6.19.5 Wireless network troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46

6.19.6 FAT procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46

6.19.7 FAT tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47

6.19.8 FAT documentation and reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47

6.20 Site installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47

6.21 Site installation plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48

6.21.1 Installation considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48

6.22 Network installations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48

6.23 Wireless connection test procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49

6.24 Network checkout procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50

6.25 Lightning protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51

6.26 Device parameter configuration verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51

6.27 Loop checkout/site integration tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51

6.28 Bench simulation testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52

6.29 Provision of spares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52

6.30 Removal of redundant equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52

6.31 Pre-commissioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52

6.31.1 Pre-commissioning requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52

6.31.2 Defining WirelessHART pre-commissioning methods and acceptance .53

6.32 Site Acceptance Test (SAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53

6.33 Commissioning and start-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54

Contents

6.33.1 Wireless network integration with HMI and loop check . . . . . . . . . . . . . . .54

6.33.2 Integrating host and field networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54

6.33.3 On-site wireless network reliability tests. . . . . . . . . . . . . . . . . . . . . . . . . . . .55

iii

Contents

February 2016

Reference Manual

00809-0100-3251, Rev AB

7Section 7: Operate

7.1 Section overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57

7.2 Asset monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57

7.3 Alarm and alerts philosophy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58

7.3.1 Configure process alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58

7.4 Data management concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58

7.5 Maintenance practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58

8Section 8: Project Management

8.1 Section overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59

8.2 WirelessHART project management overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . .59

8.2.1 Customer requirements, compliance, and assumptions . . . . . . . . . . . . . .59

8.3 Work breakdown structure and cost estimation . . . . . . . . . . . . . . . . . . . . . . . . . . .59

8.4 Subcontractor scope management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60

8.5 Project scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60

8.6 Responsibility and skills matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60

8.7 Managing project change requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61

8.8 Progress reviews and reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61

8.9 Customer deliverables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61

8.10 Training. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61

8.11 WirelessHART procurement and contract plan. . . . . . . . . . . . . . . . . . . . . . . . . . . .61

8.12 Material requisitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61

8.13 Documentation requirements in project execution. . . . . . . . . . . . . . . . . . . . . . . .62

8.13.1 ISA documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62

9Section 9: Field Device Requirements

9.1 Support for WirelessHART functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64

9.1.1 Device diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64

9.2 Mounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65

9.2.1 Device mounting considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65

9.2.2 Antenna position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65

9.2.3 Mounting high gain remote antenna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65

9.3 Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65

9.3.1 Batteries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65

9.3.2 Energy harvesting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66

9.3.3 Wired power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67

9.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67

iv

Content s

Reference Manual

00809-0100-3251, Rev AB

10Section 10: Ancillary WirelessHART Devices

11Section 11: Measurements and Choosing WirelessHART

Contents

February 2016

9.5 Approvals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

9.6 Accessibility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

9.7 Manufacturer documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

10.1 Section overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

10.2 Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

10.3 Wireless repeaters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

10.4 WirelessHART adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

10.5 WirelessHART handheld communicator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Devices

11.1 Use of WirelessHART® for multivariable process measurements . . . . . . . . . . . 73

11.2 Use of WirelessHART in various process applications. . . . . . . . . . . . . . . . . . . . . . 74

12Section 12: Host System Requirements

12.1 Use of standard protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

12.2 Wireless host system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

12.3 Host integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

12.4 Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

12.5 Host system support for WirelessHART functionality . . . . . . . . . . . . . . . . . . . . . 78

12.6 Device descriptions files (DD). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

12.7 Configuration tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

12.8 Control system graphics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

12.9 Node addressing and naming conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

12.10 Alarms and alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

12.11 Maintenance station and asset monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

12.12 Historian. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

13Section 13: Documenting in Intergraph SPI 2009

13.1 Section overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

13.2 User defined fields (UDF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

13.3 Filtered views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Contents

13.4 Creating instrument types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

13.5 Loop drawings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

13.5.1 Loop drawings for WirelessHART adapters . . . . . . . . . . . . . . . . . . . . . . . . . 87

v

Contents

February 2016

Reference Manual

00809-0100-3251, Rev AB

13.5.2 Gateway cable block drawings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87

13.6 Drawings in smart plant layout (SPL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88

13.7 Documenting security information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89

AAppendix A: Example ISA Specifications

BAppendix B: Design Resources

B.1 Section overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93

B.1.1 Network design tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93

CAppendix C: Wireless Spectrum Governance

DAppendix D: References

vi

Content s

Engineering Guidelines

00809-0100-6129, Rev AB

WirelessHART® Project Execution

Section 1: Introduction

February 2016

PART I

Introduction

1

Section 1: Introduction

February 2016

Section 1 Introduction

WirelessHART is a global IEC-approved standard (IEC 62591) that specifies an interoperable
self-organizing mesh technology in which field devices form wireless networks that dynamically
mitigate obstacles in the process environment. The WirelessHART field networks (WFN)
communicate data back to host systems securely and reliably, and can be used for both control
and monitoring applications.

Engineering Guidelines

00809-0100-6129, Rev AB

The similarities between traditional HART
training of existing process organizations when adopting WirelessHART. As a result, change is
minimized. In addition, the reduced installed cost of WirelessHART extends the benefits of
automation to end user applications that previously were out of reach since they could not
justify the costs associated with typical wired capital projects.

The opportunity for long-term benefit makes it compelling for end users to expand process
manufacturing project planning to evaluate the impact of WirelessHART on maintenance,
safety, environment, and reliability. Additionally, by removing the physical constraints of wiring
and power as well as reducing weight and space, wireless networks increase flexibility in project
execution, providing solutions which can mitigate risk and improve project schedules.

1.1 Purpose

This IEC 62591 WirelessHART System Engineering Guideline applies to end user adoption of
WirelessHART self-organizing mesh networks to automate process manufacturing projects of
any size. The guidelines are intended to help users take full advantage of WirelessHART systems.

1.2 Scope

The guidelines apply to use of WirelessHART technology through all stages of project execution
as well as throughout the lifecycle of facility operation.

®

and WirelessHART allow end users to leverage the

Differences between HART and WirelessHART specifications and device types are highlighted.

1.3 WirelessHART in project execution lifecycle

Figure 1-1 illustrates a typical framework for project execution. It will be used as a basis for

describing application of WirelessHART in each phase of a project. Although WirelessHART can
be introduced at any phase, a strategic benefit is realized by its introduction during the early
part of the project execution cycle.

Figure 1-1. Project Execution Lifecycle

2

Introduction

Engineering Guidelines

00809-0100-6129, Rev AB

Section 2 Project Concepts

Section overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 3

Traditional approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 3

WirelessHART approach: technology assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 4

2.1 Section overview

As described in this section, use of WirelessHART® over traditional technology reduces project
risk during execution and provides greater flexibility and benefits to the plant during its life
cycle.

2.2 Traditional approach

Section 2: Project Concepts

February 2016

Traditional methods of wired control networks make use of conventional communications like
4-20 mA, HART

Installation of these wired networks is complex due to inflexibility of wiring. Significant effort is
required in the pre-FEED and FEED phases for planning long run cables including room for spares
to accommodate changes during project execution. Beyond laying long run cables, wired
system complexities include cable routing, connectors, and additional materials associated with
wired technology that are greatly simplified with wireless.

Use of traditional technology also restricts measurement of parameters in locations inaccessible
to cable trays and therefore wired connection. Such wired measurements could improve
operations but are eliminated from the design process as being too costly to implement.

Since use of wired connections reduces the number of measurements and instruments during
the initial execution phase, modifications may be needed to add some of these at a later stage.
Increased spares would be needed to allow the expansion. In a typical project environment,
frequent changes in I/O database, addition/deletion or reallocation of instruments, change in
instrument types, delayed or late changes in package vendor data etc negatively impact project
time and cost.

If instruments and therefore I/O points need to be added/changed/moved during operation,
then lengthy procedures need to be followed for wired signals such as HSE, work permits,
correct isolation procedures, and requisite cabling to connect the field instrument to the
control system. These activities require coordination between multiple plant departments.
Furthermore, routine inspection to ensure that the cable and associated infrastructure continue
to operate trouble free, can be costly and time consuming and divert valuable resources away
from operating the plant.

®

, FOUNDATION™ Fieldbus, PROFIBUS® and other bussed solutions. Planning and

Project Concepts

3

Section 2: Project Concepts

February 2016

Engineering Guidelines

00809-0100-6129, Rev AB

2.3 WirelessHART approach: technology assessment

WirelessHART technology may provide an opportunity to execute and build a more efficient
plant compared to the traditional approach.

The project technical authority can decide whether to use wireless based on the following
criteria:

 Economic advantages

 Application capability

 Operational savings

 Benefits of additional process insight from new measurements previously out of reach

economically or physically - example: monitored safety showers

 Benefits of flexibility in project execution – example: ease of moving or adding I/O

points during construction to cost effectively manage onsite changes

The high cost of traditional field wiring limits the number of points that are able to be connected
in a project for process monitoring, control and safety applications. However, as the project
proceeds and over the lifecycle of the plant, additional points may need to be added to resolve
critical problems. Since WirelessHART does not require wires for communication or power, the
lower costs enable inclusion of more process points during the project. The financial
impediment in determining whether a point is automated or not is redefined,

Special consideration should be given to automation needs of new process plants. WirelessHART
may provide significant advantages in enabling automation to ensure they meet stricter safety,
environmental, reliability and performance criteria. Below are a few examples:

 Many new plants are designed to operate with fewer personnel. Upgrading simple

gauges to wireless field devices can automate the manual collection of data from the
field in order to increase worker productivity and reduce field trip exposure to
hazardous environments.

 Many existing facilities have been modified in order to meet emerging environmental

regulation. Real time monitoring of volatile organic compound release (VOC) from
wireless monitoring of pressure safety valves and of conductivity and temperature of
effluent waters can ensure environmental compliance.

 Wireless remote monitoring of safety showers and gas detectors during construction

and operation can provide new levels of safety response.

 New environmental regulation often requires redundant monitoring systems on assets

like tanks that were not required in the past. WirelessHART can provide a cost effective,
reliable secondary communication and monitoring method.

 Wireless monitoring of steam traps and heat exchangers can provide real time

information for minimizing plant energy consumption.

Cost effective field information accessible via WirelessHART field devices enables non-traditional
end use of automation to be considered in the FEED and design phases. A designer should be
aware of initiatives for safety, environmental protection, energy consumption, and reliability in
addition to the traditional considerations for process automation. The WirelessHART
architecture extends the benefits of automation to multiple plant initiatives without the need
for multiple forms of I/O infrastructure.

4

Project Concepts

Engineering Guidelines

00809-0100-6129, Rev AB

Traditional wired architecture is limited in ability to mitigate risk of project execution.
Innovative WirelessHART architecture provides greater flexibility with minimum engineering
effort and greater savings in cost and time during any project phase, as compared to the
traditional approach.

Active projects should optimize measurement and control technology by establishing design
rules to define which points are suitable for WirelessHART versus traditional technology. These
design rules will help to enable consistent and efficient engineering for subsequent project
phases.

Section 2: Project Concepts

February 2016

Project Concepts

5

Section 2: Project Concepts

February 2016

Engineering Guidelines

00809-0100-6129, Rev AB

6

Project Concepts

Engineering Guidelines

00809-0100-6129, Rev AB

Section 3 Appraise

Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 7

Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 8

Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 8

Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 8

Appraise phase documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 8

The Appraise phase (conceptual design) requires high level customer requirements or project
constraints as input. In this phase a simple statement of requirements with identified
constraints or objectives will suffice. Selection of wireless technology in this phase allows a
simple generic design philosophy statement to be made on how the architecture can be used to
meet the needs of both the business and the project. Figure 3-1 shows the inputs and outputs of
the Appraise phase.

Figure 3-1. Conceptual Design Phase

Section 3: Appraise

February 2016

During the Appraise phase it is likely that a summary of the technology and its application will
be required by the project stakeholders in order for them to formulate a practical view of
applicability to the project. Plant personnel engaged in the early phase of the project should
also be part of this appraisal.

3.1 Application

WirelessHART® can be applied to a wide variety of process applications in all process industries
spread over differing geographical terrain. Evaluate the following factors for potential
WirelessHART application:

 Process monitoring and measurements which are remote and uneconomical to

consider for wired monitoring

 Equipment health monitoring

 Environmental monitoring, energy management, regulatory compliance

 Extreme environmental conditions for wired installations (hot, wet and corrosive)

 Moving rails and test skids

 Rotating equipment

Appraise

7

Section 3: Appraise

February 2016

 Asset management, diagnostics and predictive maintenance

 Simple closed-loop control (when appropriate)

 API seal flush plans

 Secondary systems

3.2 Technology

Evaluate the following factors for benefit by application of WirelessHART technology:

 Minimizing the cost

 Ease of installation

 Reduced time for installation and commissioning

 Ease of maintenance

 Ease of expansion for future I/O points (scalability)

Engineering Guidelines

00809-0100-6129, Rev AB

3.3 Operations

WirelessHART field networks can help optimize contiguous or remote process operations by
collecting data in organized manner and enabling operators, shift supervisors, production/field
management, and facilities engineers to collaborate. Delivery of the right information to the
plant operations team helps them make the right decisions to improve plant throughput.

Evaluate WirelessHART operations for benefits in each of the following:

 Access to monitoring points which are normally unavailable to plant operators

 Increased safety by minimizing plant operator rounds in hazardous locations

 Better alarm handling and reporting

 Better insight by use of wireless transmitters for trending rather than gauges and

switches

3.4 Maintenance

There are no special maintenance requirements for WirelessHART devices apart from changing
the batteries. Diagnostic information provided to the Asset Management System alert
technicians of the need for maintenance.

WirelessHART devices provide advantage for maintenance in hazardous areas. The batteries are
intrinsically safe and power-limited, so they can be changed with the device locally without risk
of causing a source of ignition.

3.5 Appraise phase documentation

The Appraise phase documentation presents conceptual design that is referenced to customer
and project requirements, supported by economic analysis, and satisfies project imperatives.

8

Appraise

Engineering Guidelines

00809-0100-6129, Rev AB

3.5.1 Reference documents

 Customer requirement specification (customer statement of requirements)

 Project constraints

3.5.2 Deliverables from the philosophy document

 Conceptual design philosophy/architecture

 Economic analysis of technology and solutions

 Project imperatives

Section 3: Appraise

February 2016

Appraise

9

Engineering Guidelines

00809-0100-6129, Rev AB

Section 3: Appraise

February 2016

Appraise

10

Engineering Guidelines

00809-0100-6129, Rev AB

Section 4 Pre-FEED

Section overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 11

Cost benefit study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 12

Preliminary design basis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 14

Project references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 15

Pre-FEED documentation and tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 15

4.1 Section overview

In Pre-FEED, the requirements, philosophies and imperatives established in the Appraise phase
are further elaborated. Deployment of WirelessHART

explored and verified in further detail during this phase. Figure 4-1 shows the inputs and
outputs of the Pre-FEED phase.

Section 4: Pre-FEED

®

for identified applications can be

February 2016

Figure 4-1. Pre-FEED Phase

An integrated approach should be used for incorporating wireless into a project. Wireless should
be merged with wired technology in the project procedures. It is essential to use the right field
device technology for the right application. New end user communities may be added as the
cost advantages of wireless expand applications during the FEED process.

Pre-FEED

11

Section 4: Pre-FEED

February 2016

Engineering Guidelines

00809-0100-6129, Rev AB

4.1.1 WirelessHART for control and monitoring applications

WirelessHART is designed for both control and monitoring applications. Most current use cases
emphasize monitoring applications due to conservative adoption of new technology in the
process manufacturing industry. The use of wireless control applications is continuing to evolve
with the introduction of discrete output devices for performing simple control functions. The

Ta bl e 4 -1 provides a high level summary for selection of the right protocol when factoring in

loop criticality; cost to engineer and implement; and location of field devices relative to main
process areas and host systems.

Table 4-1. Selecting the Right Protocol

Safety

systems

Critical
control

On-off

control

In-plant

monitoring

Conventional

Fieldbus

WirelessHART

Legend Based on technical and/or cost considerations

Most appropriate solution

Appropriate in some cases

Lease effective solution

Ta bl e 4 -2 shows the available technology solution for different signal types.

Table 4-2. Selecting Signal Types with the Right Protocol

Analog inputs Analog output Digital inputs Digital outputs

Conventional

Fieldbus

WirelessHART

   
   
 N/A  

Remote

monitoring

4.2 Cost benefit study

WirelessHART and wired solutions need to be evaluated during the Pre-FEED phase for
comparison from a cost and time perspective. Furthermore, assessments on the benefits to
schedule improvement (by phase) and of change management should be an input to this cost
benefit study.

The following factors can be considered for this comparison:

 Main junction box requirements

 Secondary junction box requirements

 Main cable tray requirements

 Secondary cable tray requirements

12

Pre-FEED

Engineering Guidelines

00809-0100-6129, Rev AB

 Multi-core cable requirements

 Mechanical and civil work for cable routing

 Power supply in system cabinets

 System cabinet requirements

 Marshalling cabinets

 3D modeling review for cable tray routing, cable tray engineering, and location of

 Cost of change request management

 Time and efforts for installing cable trays and cables

 Power consumption requirement

 Space requirements

 Material weight reduction

 System design time requirements

 Material consideration based on area classification and protection concept

Section 4: Pre-FEED

February 2016

junction box

In addition to the above criteria, accommodating changes is cheaper and more efficient with
WirelessHART during any project phase. Typical case studies for cost, time, power, space and
weight savings are shown in Figure 4-2 and Figure 4-3. These case studies should consider the
criteria listed above.

Figure 4-2. Case Study for Cost and Time Savings

Pre-FEED

13

Engineering Guidelines

00809-0100-6129, Rev AB

Figure 4-3. Case Study for Power, Space, and Weight Savings

Section 4: Pre-FEED

February 2016

4.3 Preliminary design basis

Determine a preliminary design basis using the Customer Requirement Specification updated in
the Appraise phase along with the preliminary conceptual design documents available from
Appraise like site plan/layout, P&IDs, instrument index etc. This includes the quantity of
WirelessHART instruments, Gateways and repeaters needed to create a pervasive sensing
network. Assumptions on the basis of experience for similar plants/units can be made in
absence of requisite inputs.

Considering requirements of WirelessHART for indoor, outdoor and remote locations, develop a
preliminary network topology for the Wireless Field Network.

Develop a suitable interface solution for connection of the multiple Wireless Field Networks to
the host system and asset management system.

Verify spectrum approvals for the end-user and any intermediary locations. Refer to Appendix A:

Example ISA Specifications for more details.

Pre-FEED

14

Engineering Guidelines

00809-0100-6129, Rev AB

4.4 Project references

Previous projects operating with WirelessHART are a rich source of information and reference for
new planned WirelessHART implementation. Look towards these references as the first line of
help to overcome specific issues encountered in new installations.

4.5 Pre-FEED documentation and tools

Documentation from the Pre-FEED phase records use of conceptual design reference inputs to
develop high level functional design deliverables.

4.5.1 Reference documents

 Initial plot plan

 Initial 3D layout drawings

 Initial P&ID

 Instrument index

 Customer specification documents

Section 4: Pre-FEED

February 2016

 Proposal documents for cost estimates

4.5.2 Deliverables

 Initial wireless field network system architecture

 Measurement signal types

 Bill of quantity

Pre-FEED

15

Section 4: Pre-FEED

February 2016

Engineering Guidelines

00809-0100-6129, Rev AB

16

Pre-FEED

Engineering Guidelines

00809-0100-6129, Rev AB

Section 5: Front End Engineering Design

February 2016

Section 5 Front End Engineering Design

Section overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 17

Scope definition of engineering execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 18

Environmental considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 19

WirelessHART functional design requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 19

WirelessHART infrastructure requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 19

Operational requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 20

Design inputs documents review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 20

Development of basis for design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 20

Initial design review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 22

5.1 Section overview

Front End Engineering Design (FEED) is an important stage where key deliverables exist for
wireless including cost estimation, design guidelines, and specifications. Collaborative efforts
put in by all stakeholders during FEED, will help in capturing all project specific requirements and
avoiding significant changes during the Execution phase.

The following factors can be evaluated during the FEED phase for WirelessHART

®

deployment in

the project.

 Environmental considerations

 WirelessHART functional design requirements

 Scope definition of engineering execution

 WirelessHART infrastructure requirements

 Operational requirements

 Design inputs documents review

 Development of basis for design

 Risk assessment and initial design philosophy review

Figure 5-1 shows the inputs and outputs of the FEED phase.

Figure 5-1. FEED Phase

Front End Engineering Design

17

Section 5: Front End Engineering Design

February 2016

Engineering Guidelines

00809-0100-6129, Rev AB

5.2 Scope definition of engineering execution

Stakeholder meetings are important to ensure all disciplines understand the scope of wireless
applications. Agenda items should include the following:

 Review potential benefits in key areas of the work structure

 Put in place appropriate training and strategy to achieve potential benefits.

 Clearly distribute project work to optimize dependencies within the project team so

that schedule efficiencies can be achieved.

 Identify In-house wireless network requirements to define the scope of Integration of

WFN and WPN network.

 Clearly define wireless communication network availability, redundancy, WirelessHART

equipment supply, installation, configuration and commissioning site work activities,
and spare requirements scope

Define and include in the scope: overall wireless network architecture design, wireless device
location, minimum distance and coverage between access points, network coverage and
performance requirements.

Identify and include in the scope: supplementary wireless network devices such as WirelessHART
handheld communicator, mobile worker supply.

Determine the field device types and WirelessHART signal types for project implementation,
including consideration of the following signal and device types (refer to Emerson

™

Process

Management literature for the most up to date measurement types and innovations).

 Pressure

 Tem p er at ur e

 Flow

 Level

 Tuning fork level

 Conductivity

 pH

 Corrosion

 Tank gauging

 Guided wave radar

 Discrete position monitoring

 Discrete inputs

 Discrete outputs

18

 Acoustic (steam trap and PRV monitoring)

 Vibration

 Flame detection

Front End Engineering Design

Engineering Guidelines

00809-0100-6129, Rev AB

Section 5: Front End Engineering Design

February 2016

5.3 Environmental considerations

Check for compliance with hazardous area classification requirements, temperature class, and
ambient temperature of plant.

Ensure compliance with regional and country specific RF frequency usage norms.

5.4 WirelessHART functional design requirements

During the initial stage of FEED, translate owner-operator’s functional requirements into a
network infrastructure, device characteristics, host interfaces, and applications. Document
these in the design specification; also include boundary conditions (e.g. all monitoring points on
this project will be wireless) associated with WirelessHART applications.

5.4.1 WirelessHART functional requirements

Develop the WirelessHART design, including the following:

 Network environment and area classification

 WirelessHART system architecture

 Operational requirements

 Data requirements

 Interfaces

 Te st in g

 Spares consideration

 Documentation requirements

 Training

 WirelessHART network Security, reliability and interoperability requirements

5.5 WirelessHART infrastructure requirements

Conduct plot plan reviews and determine the infrastructure requirements for the following:

 System architecture

 Wireless

 Field network design including IEC62591 WirelessHART Field Instruments

 Automation

 Host system interface

 Process control network interface

 Asset management system diagnostics including those for field device and the field

Front End Engineering Design

network configuration

19

Section 5: Front End Engineering Design

February 2016

5.6 Operational requirements

Determine operational requirements for the following:

 Process monitoring and signal types

 Device diagnostics

 Loop response time

 DCS HMI

 Redundancy

 WirelessHART network components

 Reduction in field inspections of physical wired infrastructure (IECC60079)

 Elimination/reduction of operator rounds

5.7 Design inputs documents review

Collect initial design documents that describe project requirements including plot plans,
equipment layout plans, preliminary instrument index, and three-dimensional layout drawings.

Engineering Guidelines

00809-0100-6129, Rev AB

Project team shall make sure inputs are sufficient to define the project initial design philosophy.
If documentation is inadequate then project team needs to seek technical clarification from the
facility owner-operator.

5.8 Development of basis for design

5.8.1 Design guidelines for WirelessHART

During the FEED process, all project stakeholders should be made aware of the capability and
benefits of WirelessHART so that design engineers can identify potential application candidates.
The project team should develop a wireless design and circulate to all project stakeholders.

For example, the process design engineer can use a set of criteria as shown in Ta b le 5 - 1 to
identify wireless application candidates.

Table 5-1. Example Criteria of Wireless Application Candidates

Safety

systems

WirelessHART

Critical
control

On-off

control

In-plant

Monitoring

Remote

Monitoring

20

Legend Based on technical and/or cost considerations

Most appropriate solution

Appropriate in some cases

Lease effective solution

Front End Engineering Design

Engineering Guidelines

00809-0100-6129, Rev AB

Ideally, WirelessHART application candidates are identified early in the FEED process design
phase. This could be during development of the Process Flow Diagram (PFD) or Piping and
Instrument Design (P&ID) Diagram. However, if an early decision is not taken, this should not
preclude the use of the technology later in the project.

The basis for WirelessHART design should be shared among all stakeholders so that other
technical design authorities can identify potential wireless applications and benefit from the
installed wireless infrastructure. Furthermore, this process ensures consistent implementation
across all design authorities and allows for an efficient decision process for use of wireless
technology.

Include the following steps when developing the WirelessHART design guidelines:

 Determine which categories of points are eligible to be wireless: safety, control,

 Determine if new users are eligible for automation: process efficiency, maintenance,

 Determine percent spares required and necessary spare capacity.

 Factor in distance considerations between Gateways and wireless field devices.

Section 5: Front End Engineering Design

February 2016

monitoring, and local indication.

reliability, asset protection, health/safety/environmental, and energy management.

Distance considerations are elaborated on in Section 0, Designing.

 Determine whether WirelessHART field network backhaul is required.

5.8.2 Specifications

Specifications for WirelessHART field devices are nearly the same as for wired HART® devices.
See Appendix B: Design Resources for key differences.

Table 5-2. Differences Between Wired and WirelessHART

Specification field Typical HART specification Ty pi ca l WirelessHART specification

Output signal 4-20 mA HART IEC 62591 WirelessHART

Power supply 24V DC Loop Powered Intrinsically Safe Battery

Update rate 1 second 1 second to 60 minutes

Protection/enclosure Explosion Proof Intrinsically Safe

IEC 62591 WirelessHART is an international standard for wireless process automation devices.
Devices that comply with the standard include advanced provisions for security, protocol, and
other features essential to wireless networks and therefore specification of such attributes
covered in the standard are not necessary.

Appendix A: Example ISA Specifications provides example specifications for a WirelessHART

Gateway and wireless adapter that can be generically specified as transceivers/receivers.

5.8.3 Proof of concept test

WirelessHART is well established in a comprehensive range of process plants and environments.
On occasion it may be necessary to conduct a proof of concept test to familiarize stakeholders
with the capability and applications of the technology; this can be done in a workshop setting.

Front End Engineering Design

21

Section 5: Front End Engineering Design

February 2016

5.9 Initial design review

Upon completion of site plot plan review, gather the report results from various WirelessHART
tools, proof of concepts and compliance to customer requirements, and discuss these with all
stakeholders. Also discuss any requirement changes, deviations or assumptions with the
stakeholders. Since WirelessHART is extremely flexible it is easy to incorporate necessary
architecture changes.

Engineering Guidelines

00809-0100-6129, Rev AB

22

Front End Engineering Design

Engineering Guidelines

00809-0100-6129, Rev AB

Section 6 Execute

Section overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 23

WirelessHART Field Network – Design Engineering Overview . . . . . . . . . . . . . . . . . . . . . page 25

Design resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 25

Wireless device selection based on process measurement . . . . . . . . . . . . . . . . . . . . . . . . page 25

Design criteria development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 27

Identify candidate measurement points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 27

Database field for wireless network assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 27

Network design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 28

Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 29

Detailed design specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 33

Spare capacity and expansion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 38

Fortifying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 38

WirelessHART availability and redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 39

WirelessHART security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 40

Alarm handling with WirelessHART devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 40

Data sheet parameters for WirelessHART transmitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 43

Tools and documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 44

Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 44

Factory Acceptance Test (FAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 45

Site installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 47

Site installation plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 48

Network installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 48

Wireless connection test procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 49

Network checkout procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 50

Lightning protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 51

Device parameter configuration verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 51

Loop checkout/site integration tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 51

Bench simulation testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 52

Provision of spares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 52

Removal of redundant equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 52

Pre-commissioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 52

Site Acceptance Test (SAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 53

Commissioning and start-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 54

Section 6: Execute

February 2016

6.1 Section overview

During the Execute phase (Detailed Design and Testing) of a project, the engineer must account
for WirelessHART

to the project database, and follow wireless field network design procedures to ensure best
practices are implemented.

This section addresses the following aspects of Execute Detail design phase.

 Design resources

Execute

®

devices per the guidelines established in the FEED, add wireless specific fields

23

Section 6: Execute

February 2016

Engineering Guidelines

00809-0100-6129, Rev AB

 Design guidelines

 Wireless field networks design description

- Key components of the wireless field network solution

- Wireless devices and Gateway

- Wireless device selection criteria and data sheets

 Field network deployment

- Project environmental considerations, intrinsic safety requirements

- Equipment environmental specification

- Radio regulatory compliance

- Plant areas and candidate areas for further wireless deployments

 Host system interface

- Host/DCS components and architecture

- Network identification

- Asset management software interface

 Third party interface

 Wireless field network infrastructure

- Typical architecture,

- Equipment location

- Power specification and power distribution philosophy

- Cable specifications and types

- Field data backhaul philosophy and backhaul specification

 Design philosophy deployment

- Topology, wireless field network control philosophy

- Monitoring, closed loop control

- Module design and scan rates

- Alarm and status Information

Figure 6-1 shows the inputs and outputs of the Execute-Detailed Design phase.

Figure 6-1. Execute-Detailed Design Phase

24

Execute

Engineering Guidelines

00809-0100-6129, Rev AB

6.2 WirelessHART Field Network – Design Engineering Overview

Follow these three key steps for designing a network:

1. Scope – Decide if you need to reference wireless field networks by process unit or

subsection of a process unit. Factors include:

 Number of devices in the process unit

 Update rates need for wireless devices

 Capacity of the Gateway

2. Design – Apply design rules to ensure optimum connectivity.

3. Fortify – Identify and correct any potential weaknesses in the network design.

The three basic steps apply for all process environments in all industries, although the context
may vary slightly depending on the physical structure of the process environment. The basic
steps also apply regardless of the vendor of the WirelessHART devices. Since WirelessHART
networks become stronger as more devices are added, the Scope step is the most critical for
high density applications.

Section 6: Execute

February 2016

WirelessHART is designed for both control and monitoring applications. Refer to Section 2:

Project Concepts for detailed recommendations on using wireless control systems and devices.

In general, control with WirelessHART is appropriate for most cases of open loop control that
require manual interaction with the process and some cases of supervisory control for set point
manipulation and process optimization. Applications for closed loop regulatory control of a
critical loop may be evaluated case by case.

6.3 Design resources

See the Design Resources Appendix for more information. Contact your respective
WirelessHART vendor for automated design tools to aid:

 Wireless network planning

 Network design

 Gateway capacity planning

 Device type availability and battery life estimation

6.4 Wireless device selection based on process measurement

Execute

WirelessHART devices are available for various process measurement applications including
those described below.

25

Section 6: Execute

February 2016

6.4.1 Process monitoring and control

 Hard to reach locations

 Process efficiency calculations

 Better insight into the process

 Ad-hoc measurements

 Additional measurements from multivariable devices

 Calculated variables in devices

6.4.2 Equipment measurement

 Vibration

 Corrosion

 Oil pressure

 Air flow

6.4.3 Health and safety systems

 Gas detectors

 Analyzers

Engineering Guidelines

00809-0100-6129, Rev AB

6.4.4 Environmental

 Steam traps (energy usage)

 Water/discharge treatment

 Flow

 pH

 Stack emissions

 Relief valves

WirelessHART devices can be deployed in harsh environments and hazardous areas. Table 6-1
lists examples of WirelessHART application deployment. For a comprehensive list of

applications, refer to the Wireless Application Guide available through your local Emerson
Project Specialist.

Table 6-1. WirelessHART Applications

Steam Cracker Diesel and Kerosene Production Monitoring

Trea ted Water Usage Rotating Calciner

Filter Condition Pipeline Leak Detection

Pipeline System Compressor Emissions Compliance

Remote Storage Tanks Rotating Roaster

Cold Box Boiler and Heater Gas Flow

Steam Distribution Lines Bitumen Tank Farm

Rotating Alumina Kiln Gas & Diesel Tank Inventory Management

Power Industry Applications NOx Emissions

Storage Tank Monitoring System Critical Oil Movement Tank Gauging

Pipelines Sugar Bin Motor Monitoring

Fuel Supply Systems Gas Storage

Remote Tanks Steam Trap and PRV Monitoring

™

26

Execute

Engineering Guidelines

00809-0100-6129, Rev AB

6.5 Design criteria development

Each wireless field network should be scoped to a single process unit.

Minimize the number of hops to the Gateway in order to reduce latency. A minimum of five
wireless instruments should be within effective range of the Smart Wireless Gateway.

A mesh network gets its reliability from multiple communication pathways. Ensuring each
device has multiple neighbors within range will result in the most reliable network. Each device
in the network should have a minimum of three devices within range to provide a potential
communication path.

Include 25 percent of each network’s wireless instruments within effective range of the Smart
Wireless Gateway. Other enhancing modifications include creating a higher percentage of
devices, up to 35 percent or more, within effective range of the Gateway. This clusters more
devices around the Gateway and ensures fewer hops and more bandwidth available to
WirelessHART devices with fast scan rates.

6.6 Identify candidate measurement points

Section 6: Execute

February 2016

Using the wireless guidelines established in the FEED, the design engineer should segregate all
points in the project database to identify the eligible wireless I/O points. For example, if
monitoring is deemed to be an eligible category, these points should be sor ted from the control
and other points. Afterwards, further requirements of the field devices can be applied. For
example, some control and monitoring points may be excluded from wireless eligibility because
the required update rate exceeds either the desired life of the battery or the capability of the
field device.

Typical control applications may require 1 second or faster update rates. There is a trade-off for
wireless devices between update rate and battery life; the faster the update rate, the lower the
battery life will be. It is recommended that the update rate of the measurements shall be three
times faster than the process time constant. As an example, a typical update rate for measuring
temperature changes with a sensor inside a thermowell can be 16 seconds or longer given how
much time is required for heat to penetrate the thermowell.

6.7 Database field for wireless network assignment

Each wireless field device must be assigned to a Gateway that manages a specific wireless field
network.

Each Gateway will manage its own wireless field network and can have an assigned HART Tag
like any HART device. Each wireless field network in a plant must have a unique Network ID to
prevent devices from attempting to join the wrong network. In order to ensure the desired
security level is achieved, a decision must be made whether to use a common join key for all
devices in a given field network, or unique join keys for each field device. The combination of
these two parameters provides identification and authentication down to the field device.

Execute

Ta bl e 6 -2 presents definitions of network Parameters when using a common Join Key, including

examples of a Gateway HART Tag, Network ID and Common Device Join Key.

27

Section 6: Execute

February 2016

Engineering Guidelines

00809-0100-6129, Rev AB

Table 6-2. Definitions of Network Parameters When Using a Common Join Key

Parameter Parameter options Example Technical details

Gateway HART

Ta g

Network ID Integer 10145 Integer between 0 and 65535

Field UNIT_A_UA_100 32 characters – any in ISO Latin-1

(ISO 8859-1) character set

The Join Key is the most important parameter for implementing security. Users can know the
Gateway HART tag and the Network ID for the network that the Gateway manages, but a
wireless field device cannot join the network without a Join Key. The design engineer should be
sensitive to the security policies of the design firm and the security policies of the future
owner-operator and, as a minimum, treat the Join Key with the same sensitivities as a password
for a server to a DCS or database. For this reason, storing the join key as a field in a design
database is not prudent.

Fields should be added to the project database to indicate that a field device is wireless and to
describe its association with a Gateway by using the Gateway HART tag or other labeling
convention. Parameters required to be managed confidentially should be controlled in a secure
means in alignment with established security policies. Staff members with IT security or process
security responsibilities are well suited to provide consultation into the handling of sensitive
information.

Finally, the design engineer should be aware of available WirelessHART devices. Many come with
multiple inputs, enabling fewer devices to satisfy the total number of points in a project. For
example, several vendors have a multiplexed WirelessHART temperature device that reduces
costs.

6.8 Network design

Once wireless candidate devices have been identified in the instrument database, the field
network design can begin.

Ideally wireless points should be organized by process unit and by subsection of process unit as
typically depicted in the master drawing. This information can be used to determine the
number of Gateways required. Additional Gateways can be added to ensure spare I/O capacity
per guidelines or other project requirements. From here, the Gateways should be logically
distributed throughout the process unit like junction boxes. Wireless field devices should be
assigned to the closest Gateway, or to the Gateway that is assigned to the process unit adjacent
to the unit where the field devices reside. Once this is complete, network design best practices
should be checked to ensure reliability of the network. This will be covered in detail in the
WirelessHART Field Network Design Guidelines.

Drawings should be created per existing standards. In most instances, a wireless field device is
treated identically to a wired HART device. Most drawings do not indicate wires or the type of
communication protocol, thus nothing unique needs to be done for wireless field devices.

Section 10: Ancillary WirelessHART Devices provides examples unique to WirelessHART such as

Gateways and wireless adapters. Fundamentally, it will be up to the design engineer to adhere to
or provide a consistent convention that meets the needs of the contractor and the owner­operator as is true for wired HART projects.

28

Existing HMI (human-machine interface) design guidelines for integration also apply to wireless
with no change required since data points connected from the Gateway into the host system are
managed like any other source of data.

Execute

Engineering Guidelines

00809-0100-6129, Rev AB

6.8.1 WirelessHART field network – design guidelines

The WirelessHART network specification enables a reliable, secure, and scalable architecture.
Contrary to legacy systems and point-to-point wireless networks, WirelessHART is a truly
scalable automation technology that gets more robust as more devices are added to an existing
network. Design guidelines support the deployment of small networks with less than 10
WirelessHART devices for monitoring and control, as well as installations supporting thousands
of devices.

This section includes recommendations to support the long-term, sustainable adoption of
wireless applications including WirelessHART as well as Wi-Fi, Wi-Max, and more.

The best practices for network design are applicable for networks operating with a mix of
WirelessHART devices for monitoring and control with update rates from 1 second to 3600
seconds (60 minutes). A site survey is not normally required or even possible in the case of a
Greenfield site. For an overview on spectrum usage refer to Appendix C: Wireless Spectrum

Governance.

6.9 Scoping

Section 6: Execute

February 2016

The same design rules that govern the segmentation of wired HART networks apply to
WirelessHART. From a very simple perspective, all process facilities have an architecture that
organizes the infrastructure as well as the automation and the people. WirelessHART not only
self-organizes to the process environment, but also to this inherent organization of the process
facility. For example, the process facility shown in Figure 6-2 is organized into seven process
units separated by roads.

Figure 6-2. Example Process Facility

Execute

29

Section 6: Execute

February 2016

Engineering Guidelines

00809-0100-6129, Rev AB

If the process facility is not an outdoor production environment, there is still a natural
organization that should be used for scoping networks. For example, power plants and
biopharmaceutical manufacturing facilities are typically completely enclosed with multiple
floors. One option is to scope WirelessHART field networks to a floor. If there are seven floors,
then there are potentially seven WirelessHART networks.

The benefits of scoping a WirelessHART field network to a process unit are:

 Aligns the data flow from the WirelessHART devices through the Gateway to the host

system with existing data architecture.

 Aligns WirelessHART tagging convention with wired HART tagging convention.

 Aligns WirelessHART documentation practices with the process unit and support device

location. If you know device A is on Network A and in process unit A, then one should
not look in process unit B to find device A.

 Aligns work processes of managing WirelessHART device lifecycles with wired HART

lifecycles including organizational responsibilities.

 Sets reasonable expectations for range between WirelessHART devices. Most process

units do not have a footprint greater than a few hundred feet (<0.2km) by a few
hundred feet (<0.2km).

While scoping the number of networks and Gateway placement, the design engineer should
factor in considerations for Gateway capacity and spare capacity. At a minimum, each process
unit should have its own Gateway with spare capacity for problem solving in real time. If a
project is small and application focused and total numbers of I/O points are less than the
capacity of Gateways, then typically a single Gateway is required. If the project is large or has
wireless field devices with update rates faster than four seconds, use the following process to
determine the total number of Gateways and modify the scope of a network.

1. Filter the Instrument Index List by process unit and determine how many I/O points are

in each process unit that are wireless so that the WirelessHART networks can be
segmented by process unit.

 For example, out of 700 total I/O points, let's assume process unit A has 154 wireless

points requiring 154 WirelessHART devices. We need to determine how many Gateways
are needed.

Note

Some WirelessHART devices support more than one wireless point and so there may be
instances when fewer devices are required to satisfy the number of measurement points. A key
example is a WirelessHART temperature transmitter where two or more temperature elements
are used as inputs. Networks can support a mix of device types and update rates. The method
outlined here is a simple method that determines max capacity with very limited design
information.

2. Identify the necessary update rate of each WirelessHART device to meet the

specifications of the application as well as battery life.

30

 Ty pi ca l WirelessHART devices can update from once per second to once per hour.

 The update rate should be 3-4 times faster than the time constant of the process for

monitoring and open loop control applications.

 The update rate should be 4-10 times faster than the time constant of the process for

regulatory closed loop control and some types of supervisory control.

Execute

Engineering Guidelines

00809-0100-6129, Rev AB

 The faster the update rate, the shorter the battery life. Use an update rate that meets

 Update rates faster than four seconds can impact the total number of wireless devices

3. Determine the capacity of the Gateway determined by the maximum update rate to be

Note

Some Gateway vendors have advanced capacity planners that can provide detailed capacity
estimate based on the required updates of individual update rates. WirelessHART networks can
support a mix of device types and update rates. The method outlined here is a simple method
that determines max capacity with very limited design information.

4. Determine and apply any guidelines on spare capacity. If the design rules for the project

Section 6: Execute

February 2016

the needs of the application, but does not oversample in order to maximize battery life.

that can be put on a Gateway. Consult the specification of the Gateway vendor for
additional constraints and consultation.

used in the network. Be conservative and assume all devices are operating at the same,
fastest update rate network for the purpose of estimation. Example output: 100
WirelessHART devices per Gateway if all devices are updating every eight seconds or
slower and the Gateway can support 100 devices at eight seconds.

state that I/O components should have 40 percent spare capacity, then note this value
for the following calculation.

5. Use the following calculation to determine the number of Gateways:

For the example above, three Gateways are needed.

This formula can be entered into Microsoft

®

Excel®.

6. Scope the number of required Gateways into subsections of the process unit. If more

than one Gateway is needed per process unit, then the design engineer should segment
the networks such that the Gateways are distributed in the field like marshaling panels
and junction boxes. In Figure 6-3, the master drawing, the process unit has 16
subsections labeled L-2 through L-17 that should be logically segmented for coverage
by Gateways. Not every Gateway needs to have the same number of wireless points. If
redundant Gateways are to be used, then double the number of Gateways based on the
output from the above formula.

Execute

31

Section 6: Execute

February 2016

Engineering Guidelines

00809-0100-6129, Rev AB

Figure 6-3. Process with Three WirelessHART Networks and Good Gateway Placement

This example shows three WirelessHART Gateways supporting three WirelessHART networks in
the same process. This is analogous to having three F

OUNDATION

™

Fieldbus segments in the same
process unit. In this example, the process unit subsections were grouped horizontally instead of
vertically to minimize the distance of the process unit. A key consideration is that the Gateways,
regardless of manufacturer should always be in the process space for which they supply I/O
capacity. Figure 6-4 shows an image of what not to do.

Figure 6-4. Process with Three WirelessHART Networks and Poor Gateway Placement

32

Execute

Engineering Guidelines

00809-0100-6129, Rev AB

Do not place all Gateways in the same location just because connecting into the host system is
convenient. The next section on network design will show that this is inefficient and can lead to
unreliable networks in the long term. The Gateway should be centralized to the field network to
maximize the number of connections to wireless devices.

WirelessHART networks can be logically aligned with existing documentation and automation
engineering practices following this procedure.

Key things to remember:

 Scoping is the most important design rule. Use it to ensure wireless capacity, long term

 Every WirelessHART Gateway in a facility must have a unique Network ID to properly

 The output from the scoping phase should be a scaled drawing showing the relative

Section 6: Execute

February 2016

scalability, high reliability, and alignment of WirelessHART devices and management
with existing process facility, organization, and work practices.

segment the WirelessHART field networks.

locations of assets and processes to be automated and potential integration points for
the WirelessHART Gateways.

6.10 Detailed design specifications

Upon completion of site study report review, prepare detailed design specifications in
accordance with the control system requirements. Detailed design covers the following:

 Overall wireless mesh architecture including the detailed network infrastructure

 WirelessHART devices and network hardware and software specifications

 Network integration method

 Network security specification

 Network monitoring tools

 Documentation requirements

6.10.1 Designing

Effective device range

The following design rules are intended to be very conservative and are based on real-world
deployments of WirelessHART field networks. The effective range of a device is the typical linear
distance between WirelessHART field devices when in the presence of process infrastructure.
Typically, if WirelessHART devices have no obstructions between them, have clear line of sight
(LOS), and are mounted at least 6 feet (2 meters) above the ground, then the effective range
with 10 mW/10 dBi of power is approximately 750 feet (228 m). Obstructions decrease the
effective range. Most process environments have high concentrations of metal that reflect RF
signals in a non-predictable manner bouncing the signal off of the metal of the surrounding
environment. The path of an RF signal could easily be 750 feet (230m) even though the
neighboring device separation is only 100 feet (31m) away. Below are three basic classifications
for effective range in the process environment.

Execute

 Heavy obstruction – 100 ft. (30 m). This is the typical heavy density plant environment;

where a truck or equipment cannot be driven through.

33

Section 6: Execute

February 2016

Engineering Guidelines

00809-0100-6129, Rev AB

 Medium obstruction – 250 ft (76 m). This is the less light process areas where lots of

space exists between equipment and infrastructure.

 Light obstruction – 500 ft (152 m). Typical of tank farms. Despite tanks being big

obstructions themselves, lots of space between and above makes for good RF
propagation.

 Clear line of sight – 750 ft (228 m). The antenna for the device is mounted above

obstructions and the angle of the terrain change is less than five degrees. Some
WirelessHART vendors provide options and techniques for obtaining even further
distances for long distance applications.

These values are practical guidelines and are subject to change in different types of process
environments. Conditions that significantly reduce effective range are:

 Mounting field devices close to the ground, below ground, or under water. The RF

signal is absorbed and does not propagate.

 Mounting field devices inside or outside of a building relative to the main network and

Gateway. RF signals do not propagate well through concrete, wood, etc. Typically, if
there are wireless devices nearby on the other side of the enclosure, no special design
rules are needed. If there is a high volume of WirelessHART devices isolated from the
network by an enclosure, consider scoping a network inside of the facility. Small,
fiberglass instrument and device enclosures often deployed in very dirty or harsh
environments show minimal impact on propagation of RF signal and can be used. Large
Hoffman-style metal enclosures will prevent RF signals and are not recommended
without additional engineering considerations.

The low power nature of WirelessHART devices allow operation for several years without
replacing a battery module, but also limit the output power of the radio and maximum range.
Because WirelessHART devices can communicate through each other to send messages to the
Gateway, the self-organizing mesh naturally extends the range beyond that of its own radio. For
example, a wireless device may be several hundred feet or meters away from the Gateway, but
power efficient “hops” through neighboring devices closer to the Gateway ensure reliable,
extended range.

The effective range is used to test the validity of network design by applying the following
design rules.

There are four fundamental, recommended network design rules.

1. “Rule of Five Minimum” - Every WirelessHART network should have a minimum of five

WirelessHART devices within effective range of the Gateway. Networks will work
properly with less than five WirelessHART devices but will not benefit from the intrinsic
redundancy of a self-organizing mesh network and may require repeaters. In a well
formed, well designed network, new WirelessHART devices can be added to the interior
or perimeter of the network without affecting operation or extensive consideration for
design.

Figure 6-5 is a simple design example. The network has been properly scoped to a

process unit and four WirelessHART devices have been placed with a Gateway on a
scaled process drawing. The red circle around the Gateway represents the effective
range of the Gateway. We see in this example, the “Rule of Five Minimum” is broken in
that there are only four devices within effective range of the Gateway. This network will
likely perform to specification, but it is optimal to fortify for long term scalability and
reliability by adding more devices.

34

Execute

Engineering Guidelines

00809-0100-6129, Rev AB

Figure 6-5. Process with Rule of Five Broken

2. “Rule of Three” – Every WirelessHART device should have a minimum of three neighbors

Section 6: Execute

February 2016

with in effective range. This ensures there will be at least two connections and the
potential for connections to change with time.
Continuing on from the previous example, we fortified the network by adding another
field device within the effective range of the Gateway and added another device as
another measurement point. Now, as shown in Figure 6-6, the red circle represents the
effective range of the WirelessHART device that does not have three neighbors. For
reliability, it is essential for every WirelessHART to have two paths during operation to
ensure a path of redundancy and diversity. The “Rule of Three” when designing ensures
concentration of devices.

Figure 6-6. Process with Rule of Three Broken

Execute

35

Section 6: Execute

February 2016

Engineering Guidelines

00809-0100-6129, Rev AB

3. “Rule of Percentages“– Every WirelessHART network with greater than five devices

should have a minimum of 25 percent of devices within effective range of the Gateway
to ensure proper bandwidth and eliminate pinch points. WirelessHART networks can
work with as little as 10 percent, and actual implementation may yield less than 25
percent, but experience shows this is a practical number. Example, a 100 device
network implies 25 within effective range of the Gateway.

 Networks with greater than 20 percent of wireless devices with update rates faster than

two seconds should increase the percentage of devices with in effective range of the
Gateway from 25 to 50 percent.

4. “Rule of Maximum Distance“– Wireless devices with update rates faster than two

seconds should be within two times the effective range of wireless devices from the
Gateway. This rule maximizes speed of response for monitor and control applications
requiring high-speed updates.

Applying network design recommendations

WirelessHART devices are located according to their process connection. Only an approximate
location is required for location on the scaled drawing since the self-organizing mesh
technology will adapt to conditions as they exist and change from the point of installation. The
design rules ensure a concentration of WirelessHART devices for ample paths between the
devices. This allows the self-organizing mesh to optimize networking in a dynamic environment.

When the “Rule of Three” is broken, it can be fortified by adding more devices. As networks
grow, “Rule of Five Minimum” and “Rule of Three” become irrelevant as there are many devices
in the process space. “Rule of Percentages” becomes dominant for large networks to ensure
there is ample bandwidth for all devices in the network. Figure 6-7 shows an example of a
network design where “Rule of Percentages” is broken.

Figure 6-7. Process with Rule of Percentages Broken

36

Execute

Engineering Guidelines

00809-0100-6129, Rev AB

A deviation from the “Rule of Percentages” can be resolved in several different ways. Below are
three options to fortify this network design, each with its own consideration.

1. Add more devices within the effective range of the Gateway. While this is a good

2. Move the Gateway into a more central location relative to the distribution of

3. Add another Gateway. This increases overall capacity for the process unit, addresses the

Figure 6-8. Process with Two Gateways

Section 6: Execute

February 2016

solution, there may not be more points of value within effective range of the Gateway.

WirelessHART instrumentation. In this case, there may not be a convenient host system
integration point at the center of the network.

needs of that specific concentration of field devices, and ensures long-term,
trouble-free scalability. There may still be the issue with convenient host system
integration point as with option 2.

If a wireless device requires update rates faster than two seconds or is used for control and does
not meet the “Rule of Maximum Distance”, consider adding a Gateway as shown in Figure 6-8 or
moving the existing Gateway closer to the wireless device. If the process control loop is tolerant
of latency, or if it was previously a form of manual control, it may be acceptable to have devices
further from the Gateway.

6.10.2 Post installation considerations for control and high speed
networks

It is recommended that wireless field devices used for control and high speed monitoring have a
higher path stability than general monitoring devices with updates slower than two seconds.
Path Stability is the measure of successfully transmitted messages on any given path relative to
the attempted transmissions. General requirements are 60 percent path stability, but 70
percent is recommended for control and high speed monitoring. The addition consideration
provided in this text ensures higher path stability that can be confirmed once the network is
deployed. Most WirelessHART vendors provide the means to verify after installation.

Execute

37

Section 6: Execute

February 2016

Engineering Guidelines

00809-0100-6129, Rev AB

6.10.3 Minimizing downstream messages for wireless output
control devices

Digital control signals sent from a host system to a wireless output control device via the
Gateway require a downstream message. In order to minimize the time for the downstream
message to arrive at the wireless control device, downstream messages initiated by non-control
applications should be minimized. Maximum downstream message time form Gateway to
wireless control device is independent of the update rate and should be no more than 30
seconds when network design best practices are followed.

Techniques for limiting miscellaneous downstream messages are as follows:

 Limit remote configuration of wireless devices when control is in service.

 Limit device scans by asset management software.

 Limit other actions that require a remote poll and response from the wireless field

device.

The update rate of the wireless control device determines how fast the host system receives
notification that the control command was received and executed.

6.11 Spare capacity and expansion

During a typical project there is often a requirement to provide installed spare hardware
(marshaling, I/O cards, and terminations) and additional spare space. Typically these figures
could vary between 20 and 30 percent. The consideration when designing with wireless is
different as no cabinetry marshaling, I/O cards, and terminations are required. Additional
Gateways can be added to the network to increase capacity.

6.12 Fortifying

It is recommended to stress test the network design by altering the effective range of devices in
order to identify potential weaknesses in the network design. To stress test the network, reduce
the effective range of the devices in 10% increments. For example, suppose an effective range of
250 feet (76m) was used for initial design. Reducing effective range by increments of 25 feet
(8m) (10%) could reveal where the weak spots will exist. It is the discretion of the network
designer to determine what level the network will be stressed; there is a limit of diminishing
return.

The example shown in Figure 6-9 reveals that one WirelessHART device fails the Rule of 3 under a
20% stress test of the effective range. Effective range is set to 250 feet (76m) for the design test
on the left and 200 feet (61m) for the stress test on the right.

38

Execute

Engineering Guidelines

00809-0100-6129, Rev AB

Figure 6-9. Process Standard Design (Left) and Stress Tested (Right)

The self-organizing mesh technology allows for more WirelessHART field devices to be added to
a network for the purposes of automation, and provides the means for simple design correction
to also exist. A stress failure can be fortified by moving the Gateway location, adding a new
Gateway to segment the network, adding more devices or adding repeaters.

Section 6: Execute

February 2016

Repeaters are an alternative to support the fortification of a network. Instead of another
WirelessHART device with a specific measurement purpose, any WirelessHART device can be
used specifically for the purposes of providing more connection within the network. Repeaters
can be used effectively within dense infrastructure if they are placed above the infrastructure to
maximize the effective range while maintaining connection with wireless devices in the infra­structure. WirelessHART adapters may make cost-effective repeaters if local power is available

6.13 WirelessHART availability and redundancy

The WirelessHART field network is inherently redundant between the wireless field devices and
the Gateway if the network design recommendations are applied. The user should expect no
less than 99 percent reliability in the flow of data from each WirelessHART field device with
typical performance approaching 100%.

The following are considerations for maximizing system availability between the host system
and the WirelessHART Gateway:

 Always properly ground Gateways and field devices per local/national electrical codes

and manufacturer recommendations.

 Always employ proper lightning protection on Gateways.

 Always use an uninterrupted power supply (UPS) to power the Gateway. This is the

primary source of Gateway failure.

 Deploy redundant Gateways for the field network if measurements are critical.

 Make host systems connections to Gateways redundant, especially if redundant

Gateways are used. This includes physical connections, Ethernet switches and power
supplies.

Execute

39

Section 6: Execute

February 2016

6.14 WirelessHART security

WirelessHART (IEC62591) is a single purpose standard in which devices have been specifically
designed to take process measurements and communicate those measurements securely
through a mesh network. Industry experts, device vendors, and end users have collaborated to
ensure the protocol was built with security measures and features in mind from the very start.

WirelessHART is a multivendor, interoperable protocol that is secure out of the box with no user
configuration. The WirelessHART protocol keeps data secure by implementing strong AES-128
bit encryption (NIST/IEEE compliant) with multiple encryption keys. The confidentiality of
device data is ensured as the data travels through the mesh network. Even though a field device
may route data from a neighboring device, it won’t have access to the encryption keys and
therefore cannot read the data as it passes through the device.

Although no user action is required for secure communication, there are some mandatory
actions required before a device can join a network. When designing networks, every network
must have a unique network ID and join key before a device can join the network. This join key
can be common for each device on the network or it can be unique to each device, creating an
Access Control List (ACL). Emerson strongly recommends using an ACL since this will add an
additional layer of security. Emerson WirelessHART networks also support network key rotation
as a risk mitigation strategy. Using the secure web interface, the user can select the timeframe
for network key rotation.

Engineering Guidelines

00809-0100-6129, Rev AB

Use the following best practice guidelines to maintain and manage the WirelessHART network:

 Never use default keys. Default keys are generally not as safe as a strong, randomly

generated key so it is recommended that randomly generated keys are used.

 Use robust key management measures. Treat encryption keys as private and

confidential information and protect them against unauthorized access.

 Do not neglect physical security. Physical security is a vital part of any security

program and fundamental to protecting your system. Restrict physical access by
unauthorized personnel to protect end users’ assets. This is true not only for
WirelessHART systems but all systems used within the facility. Unauthorized personnel
can potentially cause significant damage to end users’ equipment. This could be
intentional or unintentional and needs to be protected against.

 Use an Access Control List. It is best practice to use a unique Join key for each device;

reconfigure existing networks that use a common join key to use an ACL.

6.15 Alarm handling with WirelessHART devices

Most modern industrial complexes will have a range of different methods for bringing sensor
related data back in to the central automation system. This may range from conventional analog
(4-20mA) and discrete signals to more sophisticated digital transmission methods such as

F

OUNDATION Fieldbus, PROFIBUS

degree of fallibility the important consideration should be that whatever technology is used, a
process deviation is correctly detected, communicated and acted upon in a timely manner.

®

and WirelessHART. While all signaling methods have some

40

Digital devices have rich features which are not traditionally available with non smart 4-20mA
devices. Smart devices using HART or Foundation Fieldbus technologies are capable of
providing predictive alerts to warn of potential sensor failure which may lead to degraded

Execute

Engineering Guidelines

00809-0100-6129, Rev AB

process and operations. Additional non process related stresses may also impact the
measurement quality; for instance:

 Crushed cables

 Excessive length

 Mechanical fatigue

 Poor glanding

 Cable routing complexity

 Routing between moving components

 Supporting cable weight

 Grounding

Intermittent and potentially unrevealed failures can be difficult to trace, costly to fix and lead to
poor decisions by operators

Wireless technology is also susceptible to environmental influence; for instance:

 Propagation

 Attenuation

 Distortion

Section 6: Execute

February 2016

 Interference

The benefit of IEC62591 WirelessHART is that failures are detectable. Erroneous data is not
possible due to corruption of the data payload as measuring integrity checking indicates bad
data. The sensing technology and process interface arrangements are identical to wired sensor
transmitters therefore sensor erosion/drift issues are the same as conventional analogue non
smart devices. As previously mentioned IEC62591 WirelessHART provides a predictable
capability to detect and advice on potential failure.

In either case wired or wireless, utilizing best practice recommendations can reduce the
probability of failure.

Execute

41

Section 6: Execute

February 2016

Engineering Guidelines

00809-0100-6129, Rev AB

Figure 6-10. Alarm Propagation to the System

6.15.1 Alarm recommendations for process plant

Wireless devices have periodic updates which vary from one second to many minutes. For the
purpose of this discussion it is considered that the wireless point will have a fixed scan rate. That
is, a pre-configured rate at which the device sensor is energized and a reading of the process is
made (i.e. smart updates are not applicable). When assigning an alarm to a process variable
consider the following factors when determining an appropriate scan rate (DCS control
algorithm or wireless device):

 Process time: what is the expected rate of change for the process variable? How rapidly

does a process variable approach abnormal operating conditions? This should
accommodate sudden process swing which may move the process variable outside the
normal operating range.

 Operator response time: what is the time for an operator to respond to an alarm and

correct the fault?

Generally to satisfy the conditions, the device scan rate must be at least {4} x times the process
time constant (including dead time). In practice the operator response time is likely to be
several scans longer than this and does not need to be included in this calculation.

Factors affecting the multiplier are:

 Ability to synchronize communications with alarm processing functions

 Ability to send data by exception

42

Execute

Engineering Guidelines

00809-0100-6129, Rev AB

6.15.2 Alarm priority

Assignment of alarm priority must follow the criteria as defined in the alarm philosophy for the
plant (refer to Ta b l e 6- 3 ). The subsequent alarm rationalization exercise will define the purpose,
intent and consequence of each alarm.

Table 6-3. Alarm P r i ority

Section 6: Execute

February 2016

Priority EEMUA

Low 80 Wireless possible: monitoring and assessed control loops

Medium 15 Conventional wired

High 5 Conventional wired

1 EEMUA 191 (The Engineering Equipment and Materials Users’ Association Publication 191 for Alarm Systems).

Generally between 65 and 80 percent of alarms will be low priority with minimal risk and
consequence, and therefore these points are all possible candidate points for WirelessHART
devices.

(1)

%

Comment

6.16 Data sheet parameters for WirelessHART transmitter

Shows part of a typical WirelessHART transmitter specification section of a data sheet.

Figure 6-11. Part of WirelessHART Transmitter Specification of Data Sheet

Execute

Note

Inclusion of “join key” in the data sheet above is optional.

43

Section 6: Execute

February 2016

6.17 Tools and documentation

This section explains the input documentation and tools required in the detailed design phase.

6.17.1 Functional design specifications

Use the Functional Design Specifications developed in the FEED stage as reference for detailed
design.

6.17.2 Instrument index/database

Refer to SPI 2009 documentation for recommendations for additional fields not typically
included in wired HART specifications.

6.17.3 Instrument data sheets

Use standard data sheets created for wired HART devices. Update the specification fields shown
in Ta bl e 6 - 4 to reflect WirelessHART.

Table 6-4. WirelessHART Specifications for Instrument Data Sheets

Engineering Guidelines

00809-0100-6129, Rev AB

Specification field Typical HART field

Update Rates 1, 2, 4, 8, 16, 32, 64+ sec

Power Supply Intrinsically Safe, Field Replaceable Battery

Communication Type IEC 62591

No special ISA or other specification sheets are required since the same sheets can be used to
specify HART, F

Specifications for a specification sheet example for a WirelessHART Gateway.

6.18 Testing

This section explains the WirelessHART testing during Factory Accepting Testing (FAT), site
installation and commissioning, and Site Acceptance Testing (SAT).

The testing phase is important to confirm that the delivered WirelessHART solution meets the
customer requirements and design references used in the project. Prepare the test plan which
shall include a description of the stages of WirelessHART scope testing, hardware FAT, software
FAT, and 3rd party interface testing.

Figure 6-12 shows the inputs and outputs of the testing steps within the execute phase.

OUNDATION Fieldbus, or WirelessHART. See Appendix A: Example ISA

44

Execute

Engineering Guidelines

00809-0100-6129, Rev AB

Figure 6-12. Execute–Testing

6.19 Factory Acceptance Test (FAT)

FAT requires establishing a connection between the Gateway and the host systems.
WirelessHART Gateways typically have standard output communication protocols that directly
connect to any host system. The design team should keep a library of these integration options
for reference.

Section 6: Execute

February 2016

The key deliverable of a FAT is the integration of data from WirelessHART instruments into the
host system via the Gateway. The scope of the FAT should be agreed with the end user. Typically,
only a subset of the field devices and Gateways to be installed is used during the FAT.

6.19.1 Factory staging

The following are basic requirements for factory staging:

 Include a sample of all applications, Gateways and WirelessHART devices.

 Use an approved test plan, test procedure and test acceptance criteria.

 Verify a HART Field Communicator and user interface to the WirelessHART Gateway.

6.19.2 Assumptions

Below are assumptions for FAT:

 Network topology testing is covered as part of the SAT.

 WirelessHART network design does not need to be tested at the factory if network

design recommendations are implemented. The conservative nature and ability to
fortify the network with repeaters upon installation ensures high confidence of reliable
operation.

Execute

45

Section 6: Execute

February 2016

6.19.3 FAT requirements

The following are key requirements of the FAT:

 Physical connection between the Gateway and the host system is verified. Can the

Gateway be accessed from the host system with the proper security policy in place?

 Protocol connection between the Gateway and the application that resides on the host

system is verified. Can the data seen in the Gateway be seen in the application? Can the
standard parameters be properly mapped?

 Gateway can support all necessary connections to all required applications with

appropriate timing.

 Device Descriptor (DD) for all field devices in any asset management solution is tested.

This ensures the correct DD is installed and valid. This is especially important for
WirelessHART devices that are new to the market.

6.19.4 FAT network configuration

WirelessHART device shall be configured with the Network ID and Join Key and sufficient time for
network polling. The transmitter shall be detected by the network. To verify connectivity, open
the host interface and check if WirelessHART device is available.

Engineering Guidelines

00809-0100-6129, Rev AB

 FAT network shall cover testing aspects for hardware, configuration, communication,

security.

 Before setting up the network, carry out the pre power up check for each component

on the network.

6.19.5 Wireless network troubleshooting

If a WirelessHART Device is not joining the network then follow steps listed below.

1. Verify network ID and join key.

2. Wait longer (30 min.).

3. Enable high speed operation (Active Advertising) on Smart Wireless Gateway.

4. Check battery.

5. Verify device is within range of at least one other device.

6. Verify network is in active network advertise.

7. Power cycle device to try again.

8. Verify device is configured to join. Send the Force Join command to the device.

6.19.6 FAT procedure

46

Since there are no physical IO modules, software testing is performed by simulation of I/O at the
processor level. This level of simulation is adequate to verify the application software within the
host control system.

As per IEC 62381 standards on FAT, general guidance as described for testing of bus interfaces
and subsystems shall apply. A subset of instruments (at least one of each type) shall be

Execute

Engineering Guidelines

00809-0100-6129, Rev AB

connected to the Gateway as a proof of concept demonstration of integrated system
functionality. This test should ideally verify the connectivity of the field device to the Gateway
and from the Gateway to the host systems.

Where physical devices will not be tested at the factory, emulation of the interface will be
performed if required.

Below is a high level procedure for performing FAT.

1. Power the Gateway.

2. Add one of each type of WirelessHART device to the network and verify proper

3. Create first physical connection to the first required host system application.

4. Verify connectivity between the Gateway and the host system application.

5. Integrate necessary data from each sample WirelessHART device into the host system

Section 6: Execute

February 2016

connectivity. All Gateway fields for data from the WirelessHART device should be
properly populated.

application.

 Optional additional procedure is to change process variables in the WirelessHART device

through direct stimulation or through simulation. All devices, once properly connected
to the Gateway, should integrate identically over protocols like Modbus

6. Repeat Step 4 through Step 6 while adding host system connections to the Gateway

until all expected connections to the Gateway are complete.

7. Test integration into an asset management solution if applicable.

a. Verify each WirelessHART device can be properly accessed and configured via the asset

management solution.

8. Add any additional procedures to verify control narratives and monitoring narratives.

6.19.7 FAT tools

 Handheld communicator

 Multi-meter

 Computer setup with Gateway/card interface software

6.19.8 FAT documentation and reports

 FAT plan

 FAT procedure

 FAT checklist

®

and OPC.

6.20 Site installation

In general, WirelessHART devices are installed exactly like wired HART devices. Emphasis should
always be placed on making the best possible process connection for accurate measurement.
The self-organizing mesh technology in WirelessHART enables wireless field devices to self-route
through the process environment and reroute when the environment changes. Always refer the

Execute

47

Section 6: Execute

February 2016

Engineering Guidelines

00809-0100-6129, Rev AB

instruction manual of the WirelessHART device for specific considerations. This is covered in
detail in WirelessHART Field Network Design Guidelines.

WirelessHART adapters are typically installed on an existing HART enabled device or somewhere
along its 4-20 mA loop. Refer the manual of the WirelessHART adapter for specific consider­ations.

WirelessHART Gateways are typically placed 6 feet (2 meters) above the process infrastructure
(typically above cable trays) and located in the process unit where the maximum number of
direct connections with wireless field devices can be achieved. Gateways may have an
integrated or remote antenna for installation flexibility.

WirelessHART repeaters are typically mounted 6 feet (2 meters) above the process infrastructure
and should be located in areas of the wireless network that need additional connectivity.

It is recommended to install the Gateway first in order to allow host system integration and
wireless field device installation and commissioning to commence in parallel. Wireless field
devices can be commissioned as soon as process connections are in place and a device is joined
to a network. Once the wireless device is activated with proper configuration, update rate, and
security provisions for Network ID and Join Key, it will form a network that compensates for the
current condition of the process unit and will adapt as the unit is built. The project manager can
have wireless device installation occur in parallel with construction to maximize project time
buffers or pull in the project completion date.

6.21 Site installation plan

6.21.1 Installation considerations

 Use the device specific instrument manuals for installation instructions.

 Install instruments and process connections. Take cautions to keep the antenna from

being directly mounted against metal surfaces.

 Fiberglass instrument enclosures provide no significant impact to wireless

performance.

 If wireless instruments are mounted inside a building, relative to the majority of the

wireless instruments, a passive antenna or additional repeaters should be used to
ensure good connectivity.

Installation practices for WirelessHART devices follow very closely to the installation practices of
wired HART instruments. Since there are no wires, WirelessHART devices can be installed as soon
as the asset or infrastructure is in place and secure.

6.22 Network installations

Always install the Gateway first so that integration and field network installation and
commissioning can occur in parallel.

Field devices can be commissioned into the Gateway and then commissioned into the host
system application.

48

In general, WirelessHART devices are installed per the practices of wired HART devices. Always
refer the product manual for details.

Execute

Engineering Guidelines

00809-0100-6129, Rev AB

WirelessHART devices close to the Gateway should always be installed and commissioned first to
ensure connections for potential devices that cannot directly connect to the Gateway. This is the
easiest way to establish the self-organizing mesh.

WirelessHART devices can be installed in close proximity to each other without causing
interference. The self-organizing mesh scheduling of WirelessHART ensures devices in close
proximity to each other are silent, talking to each other, or talking on different RF channels when
other devices are communicating.

If a WirelessHART Gateway antenna or WirelessHART device antenna is to be mounted near a
high power antenna of another wireless source, then the antenna should be mounted at least 3
feet (approximately 1 meter) above or below to minimize potential interference.

For achieving better network bandwidth check for the following:

 Reduce update rate on transmitters

 Increase communication paths by adding more wireless points

 Check that device has been online for at least an hour

 Check that device is not routing through a “limited” routing node

 Perform wireless connection test procedure

Section 6: Execute

February 2016

6.23 Wireless connection test procedure

Before beginning the wireless connection test procedure, verify the WirelessHART device has
basic connectivity to the network either through the Gateway interface, a local user interface on
the device, or a local connection via a HART Field Communicator. If the device is not joining the
network within a reasonable time period, verify the presence of power and the use of proper
Network ID and Join Key. This assumes the Gateway is installed properly, powered and
accessible, that the network is designed per best practices, and that there are devices to which
the new device being commissioned can connect.

1. Wait a minimum of at least one hour from initial powering of the WirelessHART device

before performing the wireless connection test procedure. This dwell time ensures the
device has had time to make several connections for self-organization. Multiple devices
can be tested at the same time. Since they rely on each other, it is optimal to have as
many on the network as possible for initial connection testing.

2. Verify that network diagnostics indicate proper bandwidth of the device. The Gateway

should have an indication.

3. Verify each device has a minimum of two neighbors. The Gateway should have an

indication.

4. Verify device reliability is 99 percent or greater. Statistics may need to be reset and

re-certified to remove any anomalies incurred during start up and not indicative of long
term performance. Allow at least one hour for the network to gather new network
statistics.

Execute

5. Verify sensor configuration per the loop sheet or other form indicating designed

configuration.

6. Perform any necessary zero trims for sensors.

49

Section 6: Execute

February 2016

Engineering Guidelines

00809-0100-6129, Rev AB

7. Repeat for each device in the network.

If a device does not pass the wireless connection test, follow the basic steps below:

1. Wait until entire network is built and operating for 24 hours before considering further

action. This will give the Gateway time to maximize its self-organization for best
communication. If 24 hours is too long to wait, allow a minimum of four hours.

2. For the non-compliant device, verify proper path stability and RSSI values. Path

stabilities should be greater than 60 percent and RSSI should be greater than -75 dBm.
Wireless control devices and devices with update rates faster than two seconds should
have a path stability of 70 percent or greater. If all the devices on the network have very
low path stabilities, but high values for RSSI, this could be an indication of broadband
interference.

3. Look at the location of the non-compliant device in the network. Verify there is not a

broken network design rule or an unexpected installation resulting in poor RF signal
propagation.

a. Add repeaters if necessary to fortify the network if the device is isolated from the

network with poor connections.

4. Verify the device has proper power and is working properly as a sensor.

5. Verify the device update rate is not faster than the fastest allowed by the Gateway.

6. Either reduce the update rate of the field device or increase the fastest allowed update

rate on the Gateway.

6.24 Network checkout procedure

Below are basic steps for checking out a network. Allow a minimum of four hours for the
network to self-organize (24 hours is preferred).

1. Verify that all devices connected pass the wireless connectivity test. The Gateway

should have an indication.

2. Verify a minimum of 15 percent of devices are directly connected to the Gateway. The

design parameter is 25 percent; the minimum acceptable is 10 percent. Networks with
more than 20% of devices with update rates faster than two seconds or wireless control
devices have a design parameter of 50 percent and 40 percent should be connected
after installation. The Gateway should have an indication.

3. Verify overall network reliability is greater than 99 percent. The Gateway should have an

indication.

50

Execute

Engineering Guidelines

00809-0100-6129, Rev AB

6.25 Lightning protection

1. Ensure the WirelessHART device bodies are correctly grounded.

2. The installation manuals of all WirelessHART devices should be consulted prior to

installation.

3. In general, WirelessHART devices should not be the tallest feature in the plant to

maximize protection against lightning.

4. Ensure adequate protection is provided between the WirelessHART Gateways and host

system connection as a lightning strike could damage more than just the WirelessHART
Gateway.

5. In general, wireless devices may provide better protection of the system than wired, as

the energy from a lightning strike will not be able to travel through the wiring and cause
potential damage to other components. Standards such as NFPA 780 provide
classification for zones of protection from lightning as well as techniques for proper
implementation.

Section 6: Execute

February 2016

6.26 Device parameter configuration verification

Device parameter verification is important before putting in to service. Device parameter list
will change based on device type. However, following is the list of common WirelessHART
parameters that can be used for verification. These parameters can be verified along with device
datasheet specifications.

 TAG  Number of advertisements heard  Revisions
 Device ID  Number of Join attempts  Radio
 Network ID  Manufacturer  Sensor information
 Network Join status  Device type  Electronics temperature
 Wireless mode  Device revision  Supply voltage
 Join Mode  Software revision  Supply voltage status
 Number of available

neighbors

 Hardware revision

 Identification

 Last update time

6.27 Loop checkout/site integration tests

Once WirelessHART devices are connected to the Gateway and the network is checked out, the
loop checkout may not be necessary in the traditional sense.

Wireless connection testing verifies that each field device has the proper configuration. Since
there are no wires to get confused and swapped, there is no need to do the traditional loop
check. Alternative loop checks could be to ensure each field device is reporting to the correct
Gateway and each Gateway is connected into the correct host system. Traditional applications
of sensor stimulus can be performed for confidence, but are less valuable in a pure digital
architecture if there is complete assurance a field device was commissioned with the correct tag
and configuration.

Execute

51

Section 6: Execute

February 2016

6.28 Bench simulation testing

Each WirelessHART field device is compliant with the IEC 62591 protocol which has provisions for
simulation. Each device can be put into a simulation mode. Bench simulation testing should also
verify that all HART Field Communicators have the proper configuration and device descriptors
(DDs) for accessing the local user interface of field device when in the field.

6.29 Provision of spares

Below are the recommended spares to have on-site:

 Spare lightning arrestor components for Gateways, if lightning protection is used

 Spare Gateways should be kept according to spares policy for host system equipment

(e.g. I/O cards). Configurations for Gateways should be convenient for rapid
replacement if necessary.

 Spare battery modules

 Spare field devices as determined by the policy for wired field devices. Consideration

should be given for additional devices to be used as repeaters, if necessary.

Engineering Guidelines

00809-0100-6129, Rev AB

6.30 Removal of redundant equipment

Repeaters used temporarily to fortify a network can be removed and reused if the WirelessHART
network grows to a point where repeaters are no longer needed.

6.31 Pre-commissioning

6.31.1 Pre-commissioning requirements

1. Determine which WirelessHART instruments and WirelessHART Gateways are installed

correctly. Crosscheck instrumentation against Instrument Data Sheets.

2. Conduct site walk-through to determine WirelessHART Gateway location and any

infrastructure barriers. Ensure local power is available for WirelessHART devices and
Gateways and Plant Network radios.

3. Determine smart wireless Gateway connection back to host system (Serial, Ethernet,

Wi-Fi Network).

4. Determine if other forms of existing wireless present in and around the location that

may cause interference (cell phone towers, high power radio transmitters)

52

Execute

Engineering Guidelines

00809-0100-6129, Rev AB

Section 6: Execute

February 2016

6.31.2 Defining WirelessHART pre-commissioning methods and
acceptance

Define the pre-commissioning activities for the following:

Devices

Confirm device installation and configuration as per customer requirements and specifications.

Network

Confirm the network is up and running in the smart wireless Gateway. Verify each device is
connected and network meets best practices (neighbors, hops etc.).

Security

Verify security set-up and configure. Configure firewall as per requirements (optional).

Power up sequence

The battery should not be installed on any wireless device until the wireless Gateway is installed
and functioning properly. Wireless devices should also be powered up in order of proximity from
the wireless Gateway, beginning with the closest. This will result in a simpler and faster network
installation. Enable active advertising on the Gateway to ensure that new devices join the
network faster.

6.32 Site Acceptance Test (SAT)

The site acceptance shall cover primarily all WirelessHART infrastructures, associated hardware,
software and operational checks.

1. Verify the installed infrastructure as BOM.

2. Verify network communication.

3. Verify the correct configuration of WirelessHART network components.

4. Verify data communications between wireless devices and DCS.

5. Verify faceplates and all HMI elements for connected wireless devices.

6. Prepare SAT report and sign off with owner-operator.

Documentation for site acceptance test documentation:

Execute

 SAT plan

 SAT procedure

 SAT checklist

53

Section 6: Execute

February 2016

Engineering Guidelines

00809-0100-6129, Rev AB

6.33 Commissioning and start-up

WirelessHART Gateways segment the commissioning process. Since Gateways connect the
wireless field devices to the host system, WirelessHART devices can be commissioned to the
Gateway to ensure proper connectivity independently of verifying integration into the host
system. A wireless loop check can confirm connectivity from the wireless field device through
the Gateway to the host system. Interaction with the process and the WirelessHART device can
confirm the device is operational.

6.33.1 Wireless network integration with HMI and loop check

Verify device variables in the smart wireless Gateway. Also check parameters like TAG, Device ID,
network ID, network Join status and device status. Verify device operation from three places:

1. At the device via the local display

2. Using the handheld communicator

3. Host system user interface

6.33.2 Integrating host and field networks

1. Configure the wireless Gateway or wireless interface network ID and join key and verify

connection.

2. Check the installation of the wireless Gateway and power up.

3. Host integration of Gateways through Ethernet connectivity.

4. Host integration of Gateways through Serial connectivity.

5. Host integration Gateways through fiber optics.

6. Host integration over Wi-Fi link.

54

Execute

Engineering Guidelines

00809-0100-6129, Rev AB

6.33.3 On-site wireless network reliability tests

 At device level check:

- Join status

- Wireless mode

- Join mode

- Number of available neighbors

- Number of advertisements heard

- Number of Join attempts

 Duration based tests (carry out the following tests):

- Loop response time

- Consistency in process data update

- Network and device uptime confirmations

- Obstruction tests

- Network uptime test for 2,4,8,12, 24 Hours

 Wireless site execution (maintain the records for the following topics):

- System files (including diagnostics)

Section 6: Execute

February 2016

- Diagnostics

- Validation form

- Wireless deviation register

- Punch lists

- Final bill of material list

Execute

55

Section 6: Execute

February 2016

Engineering Guidelines

00809-0100-6129, Rev AB

56

Execute

Engineering Guidelines

00809-0100-6129, Rev AB

Section 7 Operate

Section overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 57

Asset monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 57

Alarm and alerts philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 58

Data management concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 58

Maintenance practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 58

7.1 Section overview

Operate phase for WirelessHART® network covers aspects like WirelessHART asset management,
data management concepts, maintenance practices, etc.

Figure 7-1 shows inputs and outputs of the operation phase.

Section 7: Operate

February 2016

Figure 7-1. Operate Phase

7.2 Asset monitoring

Operate

With the use of wireless asset management applications, users can plan, customize, visualize
and manage smart wireless networks. The asset management system handles predictive
diagnostics, documentation, calibration management, and device configuration for managing
field instruments. The asset management system allows changing, storing, comparing, and
transferring device configurations without ever going into the field. Streamline the calibration
by defining device test schemes, scheduling device calibration, and managing device calibration
data.

57

Section 7: Operate

February 2016

With the asset management system, wireless diagnostics are organized across multiple wireless
Gateways. The asset management system provides detailed reports. Below are the lists of fields
you can use in your reports:

 Device tag/Gateway

 Battery voltage

 Update rate

 Ambient temperature

 Status

 Parents/children/neighbors

7.3 Alarm and alerts philosophy

7.3.1 Configure process alerts

Process alerts allow the transmitter to indicate when the configured data point is exceeded.
Process alerts can be set for process variable and secondary variable. For example, for pressure
transmitter, process alerts can be set for pressure, temperature, or both. The alert will reset
once the value returns within range.

Engineering Guidelines

00809-0100-6129, Rev AB

Device Alert displayed:

 On the Field Communicator

 On the Asset Management System Status screen

 In the error section of the LCD display of instrument

The following alarms configuration can be used for WirelessHART device:

 HI HI Alarm

 HI Alarm

 LO Alarm

 LO LO Alarm

7.4 Data management concepts

Maintain WirelessHART system configuration data during normal operation. Periodic system
backup should be used from system software. Maintain device configuration and audit trails.

Use maintenance, calibration, and inventory documentation requirements from host system
capabilities.

7.5 Maintenance practices

Maintain each WirelessHART device per the device manual.

The network will self-organize and provide alerts for changes requiring intervention. The
Gateway should have an indication of performance issues in the network or field devices.

58

Operate

Engineering Guidelines

00809-0100-6129, Rev AB

Section 8: Project Management

Section 8 Project Management

Section overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 59

WirelessHART project management overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 59

Work breakdown structure and cost estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 59

Subcontractor scope management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 60

Project scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 60

Responsibility and skills matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 60

Managing project change requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 61

Progress reviews and reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 61

Customer deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 61

Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 61

WirelessHART procurement and contract plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 61

Material requisitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 61

Documentation requirements in project execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 62

February 2016

8.1 Section overview

This section explains project management aspects for WirelessHART® projects.

8.2 WirelessHART project management overview

This section summarizes the overall concept of WirelessHART project management.

8.2.1 Customer requirements, compliance, and assumptions

Customer requirements document should be evaluated thoroughly based on parameters like
past project knowledge base, system and technology capabilities, project best practices etc.
Regional and country specific requirements must be understood correctly.

Prepare compliance to customer requirements document. Use valid assumptions and discus
uncertain information with the owner-operator.

8.3 Work breakdown structure and cost estimation

Vendors of WirelessHART field devices may have cost calculators and capital project studies that
can be referenced and compared to support the cost justification of wireless in a project or an all
wireless project. For a large capital projects, wireless can reduce costs by switching wired
monitoring points to wireless.

Project Management

Design Engineers should assess and incorporate the following factors in their project cost
estimating calculation model:

 Reduced engineering costs (including drawing and documentation, and Factory

Acceptance Test)

59

Section 8: Project Management

February 2016

 Reduced labor (field installation, commissioning, supervision)

 Reduced materials (terminations, junction boxes, wiring, cable trays/conduit/trunking,

power supplies, and control system components)

 Reduced cost of change order management (including adding, removing, and moving

field devices)

 Reduced project execution time (including commissioning of wireless field device

simultaneously with construction)

 I/O capacity management (each WirelessHART Gateway essentially provides spare I/O

capacity)

8.4 Subcontractor scope management

Wireless enables simplified subcontractor scope management. Packages can be easily tested
and commissioned separately, requiring only minimal integration and testing to occur.
Additionally, the subcontractors will also benefit from fewer components and engineering.
Tender contracts should be amended to recognize reduced complexity and eliminated work.

Engineering Guidelines

00809-0100-6129, Rev AB

8.5 Project scheduling

1. Review schedules to recognize.

a. Limited infrastructure installation and hence reduced material and installation scope.
b. Remove some electrical and instrumentation checkout processes.

2. Amend contracts to reflect simplified installation handover processes.

3. Simplify installation schedule management.

4. Reduce material coordination management and simplified construction schedule.

5. Eliminate scheduling and expediting associated with marshaling cabinets.

6. Reflect in the schedule: eliminated activities and simplified FAT, SAT, and SIT (site

integration test) on areas where wireless has been extensively deployed.

8.6 Responsibility and skills matrix

1. Amend roles and responsibility matrix to reflect reduced/eliminated responsibilities.

2. Ensure engagement of all project stakeholders/sub-contractor so that wireless can be

applied efficiently to improve schedule and material costs.

60

3. Develop a responsibility and skills matrix for each phase of the project.

 End user, EPC Contractor, and Main Automation Vendor shall define the roles and

responsibility matrix for each task of the project lifecycle like pre-FEED, FEED and
Execute phase of project.

Project Management

Engineering Guidelines

00809-0100-6129, Rev AB

4. Assign stakeholders with role description like:

 Responsible

 Accountable

 Consulted

 Informed

Section 8: Project Management

8.7 Managing project change requests

For project change orders and other late design changes, wireless should be considered as the
primary solution unless other design considerations exist. Using wireless will result in the fewest
changes to the documentation, I/O layout and other detailed design as well as faster
commissioning since you can move wireless devices without having to also re-engineer the
wiring.

8.8 Progress reviews and reporting

February 2016

Define the project execution stages for review. Prepare review reports and inform all
stakeholders.

8.9 Customer deliverables

Prepare the list of documentation to be submitted to customer.

8.10 Training

Include the training requirements for plant operators, maintenance team and engineering
team.

8.11 WirelessHART procurement and contract plan

Check completeness of contract documents like technical specifications, delivery requirement
(time and location), quote requirement (expected date and validity, regional regulations for
WirelessHART other T&C’s), and documentation and certification requirements.

8.12 Material requisitions

Project Management

Given the need for security and RF emissions, vendors must acquire approvals for importation
to the country of end-use for compliance with local spectrum regulation and encryption
regulation. The vendor can verify whether importation compliance exists for any given country.

The batteries are commonly made using a high energy compound using Lithium Thionyl
Chloride. The Material Safety Data Sheet or equivalent should always be available as well as
awareness of any shipping restriction; notably most countries do not allow the transportation of
lithium batteries on passenger aircraft.

61

Section 8: Project Management

February 2016

Engineering Guidelines

00809-0100-6129, Rev AB

8.13 Documentation requirements in project execution

 Equipment 3D layouts

 Site plan

 Drawings

 Control narratives

 Project management plan

Every project will require the establishment of local standards for implementing consistent
documentation.

See Section 13: Documenting in Intergraph SPI 2009 for a complete treatment of
documentation.

8.13.1 ISA documentation

The American National Standard document ANSI/ISA-5.1-2009: Instrumentation Symbols and
Identification provides basic guidelines for wireless instrumentation and signals.

Key points

 There is no difference in the symbol between a HART

WirelessHART device. An instrument is an instrument.

 The line style for indicating a wireless signal is a zig zag and not a dash.

Below is an image from the ISA-5.1 document showing some comparative examples. Reference
ISA-5.1 for complete details.

 Site execution plan

 Testing (FAT and SAT)

 Installation procedure and checklists

 Commissioning and start-up checklists

 Sign off documents

®

, FOUNDATION™ Fieldbus, and

62

Figure 8-1. ISA 5.1 Wireless Drawing

 The implementation of WirelessHART requires far fewer components, making drawings

simpler.

Project Management

Engineering Guidelines

00809-0100-6129, Rev AB

Section 9: Field Device Requirements

February 2016

PART II

WirelessHART® Field Network Components

Field Device Requirements

63

Section 9: Field Device Requirements

February 2016

Engineering Guidelines

00809-0100-6129, Rev AB

Section 9 Field Device Requirements

Support for WirelessHART functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 64

Mounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 65

Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 65

Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 67

Approvals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 68

Accessibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 68

Manufacturer documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 68

9.1 Support for WirelessHART functionality

All WirelessHART devices support methods to allow remote access to device configuration,
backwards compatibility with existing field communicators, full implementation of
WirelessHART security provisions, and WirelessHART interoperability.

9.1.1 Device diagnostics

HART® diagnostics

WirelessHART devices contain similar or a subset of all of the diagnostics of wired HART devices.
Diagnostics information is available through HART commands as well as accessible through
Device Descriptions (DD) either locally through a field communicator or remotely using asset
management software.

Wireless field device network diagnostics

Every WirelessHART field device should have diagnostics that indicate whether or not the device
is connected to a network.

Wireless field device power diagnostics

Wireless field devices may have one of three power options: battery, energy harvesting
(including solar), or line power. Batteries will have a life determined by the update rate of the
wireless field device, network routing for other wireless field devices, and efficiencies of the
sensor and electronics.

Typically, the primary consumer of power is the process sensor and electronics in the wireless
field device. Using the WirelessHART radio or acting as a repeater for other WirelessHART field
devices requires minimal power. Wireless field devices report their battery voltage and have
integrated low voltage alarms such that the user can either schedule maintenance or take a
corrective action.

64

Gateway network diagnostics

Gateway network diagnostics should indicate whether field devices are connected and
functioning properly, and whether devices are missing from the network. In order to be
connected properly, appropriate bandwidth must be allocated based on the update rate of the
device. A device connected but with service denied may indicate the device has an update rate

Field Device Requirements

Engineering Guidelines

00809-0100-6129, Rev AB

that is too fast for the network capability or the network conditions. With Gateways capable of
serving 100 devices or more, clear indication of device availability is crucial.

Additionally, Gateways should be able to detect, regardless of host system integration, whether
a wireless field device is connected. This information should be continually updated and indicate
if network or device reasons are responsible for a device to not be connected. Simple device
states should be made available for integration into the host system to indicate online/offline
status regardless of output protocol from the Gateway.

9.2 Mounting

9.2.1 Device mounting considerations

Verify the process application such as gas, liquid and steam flowing through the process lines.

Check for device process connection requirements and ensure the process line isolation before
installation.

If the transmitter installation requires assembly of the process flanges, manifolds, or flange
adapters, follow Device Manual assembly guidelines to ensure a tight seal for optimal
performance characteristics of the transmitters.

Section 9: Field Device Requirements

February 2016

9.2.2 Antenna position

Position the antenna vertically, either straight up or straight down. The antenna should be
approximately 3 ft. (1 m) from any large structure or building to allow clear communication to
other devices.

9.2.3 Mounting high gain remote antenna

The high gain, remote antenna options provide flexibility for mounting the WirelessHART device
based on wireless connectivity, location, and lightning protection requirements.

Choose a location where the remote antenna has optimal wireless performance. Ideally this will
be 15-25 ft (4.6 - 7.6 m) above the ground or 6 ft (2 m) above obstructions or major infrastruc­ture.

Check for weather proofing/lightning arrester requirements.

9.3 Power

Wireless field devices may have one of three power options: battery, energy harvesting
(including solar), or line power and there may be several options with in each category.

9.3.1 Batteries

The most common will be the use of a battery for low power field devices due to ease of
deployment. Most vendors will use battery cells incorporating Lithium Thionyl Chloride
chemistry since it has the highest energy density, longest shelf life, and widest working
temperatures that are commercially viable. Although typical cells look like battery cells for
consumer electronics, precautions should be taken to ensure batteries are safely transported

Field Device Requirements

65

Section 9: Field Device Requirements

February 2016

and introduced into the process environment. Refer to “Vendor documentation” for safe
handling practices.

Battery requirements include the following:

 Cells should be assembled by a manufacturer into a battery module to ensure safe

handling and transportation.

 Module should prevent a depleted cell being introduced in a circuit with a charged cell,

since this can cause unintended electrical currents and heat.

 Module should provide ease of replacement. Battery replacement should take minimal

time and training.

 Module should be intrinsically safe and not require removal of the wireless field device

for replacement.

 Module should prevent intended and unintended short-circuiting that could lead to

heat or spark.

 Module should be designed for the process environment with mechanical properties

that provide drop protection and operation over normal process temperatures
expected for devices.

Engineering Guidelines

00809-0100-6129, Rev AB

 Module should come with necessary Material Safety Data Sheets (or equivalent) and

warnings and be disposable per local governmental regulation.

 Module should not be capable of connecting to consumer electronics or non-designed

applications to prevent a high-capacity supply from being connected to incompatible
electrical systems.

 Modules should be applicable to several WirelessHART field devices to maximize

inventory management efficiencies in the local warehouse for spare parts.

The design engineers and end users of the wireless field network should use update rates that
maximize the life of the battery module and minimize maintenance.

For achieving longer battery life check for the following recommendations:

 Check that Power Always On mode is off.

 Verify device is not installed in extreme temperatures.

 Verify device is not a network pinch point.

 Check for excessive network rejoins due to poor connectivity.

9.3.2 Energy harvesting

Vendors may provide energy harvesting options as alternatives to batteries that may include
solar, thermal, vibration, and wind solutions. Current energy conversion techniques for thermal
and vibration are relatively inefficient. In many cases, energy harvesting solutions also utilize
rechargeable batteries to maintain constant back-up power supply. Today’s rechargeable
batteries have a life expectancy of only several years during which they can maintain a full
charge and are often sensitive to temperature change for supplying power and recharging.

66

Requirements for energy harvesters are as follows:

 Energy harvesting device should have a designed connection to the wireless field

device.

 Energy harvesting device should have means for providing multiple days of back-up

power in the event the energy source is discontinued for several days.

Field Device Requirements

Engineering Guidelines

00809-0100-6129, Rev AB

 Energy harvesting device should be mounted such that it is not negatively impacted by

changes in the season, process conditions, and according the vendor
recommendations.

 Energy device should be intrinsically safe and installation should follow local practices

for low voltage wiring.

 Energy harvester should have the means for the user to know the state of the device via

the wireless field device.

 The lifetime and maintenance of rechargeable batteries should be understood and

incorporated into a maintenance routine.

9.3.3 Wired power

A wired power option for wireless field devices is an emerging option from vendors since the
cost of local power can be less than the cost of a control signal wire with power or a power
module. Some WirelessHART adapters may harvest power off of the 4-20 mA loop to wired HART
devices. Applications with high power sensors may need to be wireless to meet a
communications specification, but require more power than a battery or energy harvester can
provide.

Section 9: Field Device Requirements

February 2016

Requirements for a wired power option are as follows:

 WirelessHART adapters harvesting power from the 4-20 mA signal of the wired device

should not affect the 4-20 mA signal during normal operation or failure mode.

 Low voltage powered wireless devices (<30 VDC) should be capable of operating over a

range of voltages – example: 8-28V using standard low voltage wiring practices.

 Wired powered option may require the use of Intrinsically Safe barriers between the DC

voltage source and the wireless field device.

9.4 Security

Security is a new consideration for wireless field devices that is driven by an increased focus on
the protection of critical infrastructure by governments and other security authorities.

The requirements for wireless field device security are as follows:

 Wireless devices should be compliant with all WirelessHART security provisions

including correct usage of Network ID and Join Key.

 The user or unintended user should not be able to physically or digitally read the Join

Key from the wireless device. The Join Key(s) should be treated as confidential and
subject to the requirements of any local security policy.

 The wireless device should be receptive to security changes initiated by the Gateway,

including Network ID, Join Key, and the network, session, and broadcast keys that
validate packets sent through the network and prevent tampering and eavesdropping.

 The Gateway and any management program connected to the WirelessHART network

 Wireless field devices should not have a TCP/IP address in order implement a layered

Field Device Requirements

through the Gateway should protect all security parameters according to a local
security policy.

security policy. The exception is the Gateway with a TCP/IP connection to the host
system via a firewall.

67

Section 9: Field Device Requirements

February 2016

9.5 Approvals

Every WirelessHART device must have the appropriate hazardous area approval to meet the
conditions of the process environment as well as the appropriate spectrum and encryption
approvals. Spectrum and encryption of wireless signals are regulated by government agencies,
such as the FCC in the United States. Typically, verifying with the WirelessHART device
manufacturer that the device has proper approval for importation into the country of usage is
sufficient. Spectrum and encryption approval are a procurement issue and do not represent a
design parameter like a hazardous area approval.

9.6 Accessibility

WirelessHART devices are subject to the same mechanical and electrical specifications as wired
HART devices are they operate in the same process environments.

General requirements for WirelessHART field devices are as follows:

 WirelessHART devices shall be locally accessible with HART field communicators that

support wired and WirelessHART devices.

 WirelessHART devices shall be manageable with remote asset management systems

that access the WirelessHART device via the Gateway and through the WirelessHART
network.

Engineering Guidelines

00809-0100-6129, Rev AB

 WirelessHART adapters shall extend the benefits of a WirelessHART network to wired

HART devices that may or may not be operated on a 4-20 mA loop.

9.7 Manufacturer documentation

Every WirelessHART device should have the proper documentation, including a manual, as
would be expected with a wired HART device.

68

Field Device Requirements

Engineering Guidelines

00809-0100-6129, Rev AB

Section 10: Ancillary WirelessHART Devices

February 2016

Section 10 Ancillary WirelessHART Devices

Section overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 69

Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 69

Wireless repeaters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 70

WirelessHART adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 70

WirelessHART handheld communicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 71

10.1 Section overview

An ancillary device is defined as any device that does not contain a measuring sensor or output
to the process for actuation. These include wireless Gateways, local indicators, wireless

repeaters, and/or WirelessHART

®

adapters.

10.2 Gateways

The Gateway enables communication between wireless field devices and host systems
connected to an Ethernet, serial, or other existing plant communications network.
WirelessHART manufacturers have typically chosen to integrate the network manager, security
manager and access point functionalities into one product. Conceptually, the Gateway is the
wireless version of marshaling panels and junction boxes

Figure 10-1. Gateway System Architecture

Ancillary WirelessHART Devices

69

Section 10: Ancillary WirelessHART Devices

February 2016

Requirements for a WirelessHART Gateway are as follows:

 Provide an easy to manage solution for enabling Gateway, network management, and

security management functionality.

 Have controlled access for a security policy. Gateway should have multiple user

accounts with differing access to critical security and configuration parameters such
that there can be secure network administration.

 Have multiple output protocols to ensure integration to a range of host applications. In

any given process facility, there can be several types of DCS, PLC, and data historians
requiring multiple protocols. Multiple output protocols allow convenient connectivity
with a standard Gateway.

 Support multiple connections and, in effect, act like a server. Typical WirelessHART

applications require data to be sent to multiple host applications in order to provide
data to multiple end users.

 Support the secure transfer of all protocols over an Ethernet connection through a

robust encryption process.

 Be interoperable and support the network management of WirelessHART devices from

multiple vendors.

Engineering Guidelines

00809-0100-6129, Rev AB

10.3 Wireless repeaters

There are no special requirements for a WirelessHART repeater. If a repeater is a WirelessHART
device with a configurable update rate, then minimizing the update rate shall maximize the life
of the battery module without impacting the network reliability.

If a vendor chooses to develop a WirelessHART device for the specific purpose of acting as a
repeater, then that repeating device should be managed like any other WirelessHART device and
subject to all the specifications of a WirelessHART device. WirelessHART adapters can be used

effectively as repeaters if local power or a wired HART

10.4 WirelessHART adapters

WirelessHART adapters connect to wired HART devices that are not inherently wireless and
provide parallel communication paths through the 4-20 mA loop and the WirelessHART field
network. The four main use cases for WirelessHART adapters are as follows:

 Access HART diagnostics that are not accessible due to limitations of the host system

which may not detect the HART signal on the 4-20 mA loop.

 Provide wireless communications for HART devices which are not natively wireless.

 Enable device information to be accessed by multiple users who may not have direct

access to the control system. In this scenario, the 4-20 mA signal is sent to the control
room while the WirelessHART signal is used to access parametric and diagnostics data
by maintenance or other personnel.

 Act as a wireless repeater.

®

device is available.

70

Ancillary WirelessHART Devices

Engineering Guidelines

00809-0100-6129, Rev AB

Section 10: Ancillary WirelessHART Devices

WirelessHART adapter specifications are as follows:

 Should not affect the 4-20 mA signals under normal operation or in failure mode.

 Should operate like any other WirelessHART field device in the WirelessHART field

network.

 Should have a HART tag.

 Should pass through the wired HART device process variable as well as remote access

for configuration and calibration.

 Should employ the same security functions and methods as a standard WirelessHART

device.

10.5 WirelessHART handheld communicator

The handheld communicator is useful for the following:

 Carrying out device configuration

 Viewing network diagnostics and health reports

 Installing session keys

February 2016

Ancillary WirelessHART Devices

71

Section 10: Ancillary WirelessHART Devices

February 2016

Engineering Guidelines

00809-0100-6129, Rev AB

72

Ancillary WirelessHART Devices

Engineering Guidelines

00809-0100-6129, Rev AB

Section 11: Measurements and Choosing WirelessHART Devices

February 2016

Section 11 Measurements and Choosing

WirelessHART Devices

Use of WirelessHART® for multivariable process measurements . . . . . . . . . . . . . . . . . . page 73

Use of WirelessHART in various process applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 74

11.1 Use of WirelessHART® for multivariable process measurements

WirelessHART multivariable transmitters provide benefits including the following:

 Lower installed cost

– Cost savings since fewer instruments are needed and the number of pipe

penetrations is reduced.

 Increased accuracy

– Accuracy improvement due to single transmitter.

 Multivariable measurements

– Differential pressure

– Static pressure

– Tem pe ra tu r e

 Calculation parameters for multivariable transmitter

– Density gas expansion

– Velocity discharge coefficient

– Viscosity velocity of approach

– Beta ratio Reynolds Number

 Parameters available to read at HMI

– Mass flow

– Volumetric flow

– Energy flow

– Totalized f l o w

– Differential pressure

– Static pressure

– Tem pe ra tu r e

Measurements and Choosing WirelessHART Devices

73

Section 11: Measurements and Choosing WirelessHART Devices

February 2016

Engineering Guidelines

11.2 Use of WirelessHART in various process applications

WirelessHART devices are available for pressure, flow, level, valve position, pH, conductivity,
vibration, temperature, multi-input temperature, acoustic monitoring, level switches and
contact inputs. Applications include:

 Safety and environmental monitoring

– Pressure relief and safety valves

– Monitor safety shower activation

– Accurately measure emissions

– Ensure environmental compliance

– pH monitoring on effluent waste water

– Rotating equipment

 Tough installation conditions for wires/remote locations

– Hot

– Corrosive atmosphere

– Wet

00809-0100-6129, Rev AB

 Movement

– Rail cars

– Skids

– Flexible manufacturing

 Asset monitoring applications

– Bearing and lube temperature

– Filter differential pressure

– Vibration monitoring on rotating equipment

– Surface temperature

74

Measurements and Choosing WirelessHART Devices

Engineering Guidelines

00809-0100-6129, Rev AB

Section 12: Host System Requirements

Section 12 Host System Requirements

Use of standard protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 75

Wireless host system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 75

Host integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 77

Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 78

Host system support for WirelessHART functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 78

Device descriptions files (DD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 79

Configuration tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 79

Control system graphics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 79

Node addressing and naming conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 79

Alarms and alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 80

Maintenance station and asset monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 80

Historian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 80

February 2016

12.1 Use of standard protocols

Standard protocols should be used to ensure the most cost effective installation – examples
include OPC, Modbus

convert data from the WirelessHART field network into the desired protocol and physical layer
needed for integration into the host system.

®

TCP, Modbus RTU, HART® IP, etc. The WirelessHART® Gateway should

12.2 Wireless host system

Data from WirelessHART field networks can be integrated into any existing host system.
However, many wireless automation applications are not for control or process monitoring and
may not be required to be accessed by the DCS or PLC system. This information may be useful to
non-control room based personnel including reliability engineers, maintenance personnel, and
energy engineers. Careful consideration should be observed for determining which information
should be placed on control operations screens to prevent the dilution of critical information.

For example, suppose a wireless field network is used to replace a manual inspection round
where a maintenance technician manually collects temperature and vibration data from a series
of pumps and then manually enter the collected data into a data historian. Using WirelessHART,

Figure 12-1 shows one possible way the Gateway can be integrated into the application, in this

case a historian, for the automated collection of data.

Host System Requirements

75

Section 12: Host System Requirements

February 2016

Figure 12-1. Gateway Integration into Host System

For WirelessHART networks that support users in different roles, the potential exists for each end
user to have their own application for collecting and analyzing data. For users who manually
collect data, WirelessHART provides the missing piece to automation.

For long term scalability, where there may be 1000’s to 10,000’s of WirelessHART devices in a
single plant. It is important to have a coordinated effort and standard process to enable end
users with different roles and responsibilities to share the I/O capacity of Gateways. Representa­tives from maintenance, utilities, operations, health/safety/environmental, and asset
management can share WirelessHART network resources.

Engineering Guidelines

00809-0100-6129, Rev AB

One architecture to consider is a centralized historian and centralized asset management
program shown in Figure 12-2. In this scenario, multiple Gateways are connected on the same
Ethernet network and server. The data from multiple WirelessHART networks is sent to a
centralized historian who can then be connected to the applications for each of the end users. In
this way, host system resources can be shared, all WirelessHART instruments can report to the
same asset management solution, uniform security policies can be enforced, and end users can
see WirelessHART data in applications specific to their roles

Figure 12-2. Gateway Information Integrated Into Many Applications

76

Host System Requirements

Engineering Guidelines

00809-0100-6129, Rev AB

Developing a host system integration and data management strategy is essential to maximizing
return on investment for wireless that is adopted on a large scale. Successful implementation
means that data is going to the right people and being turned into information for action. Often
times, multiple users will see the same data, but in the context of their applications. This also
means that every time a new WirelessHART device is introduced to the plant, host system and
integration issues do not need to be solved again and again.

WirelessHART is truly scalable; WirelessHART devices can be added to a network without
disrupting operation and more Gateways can be added to increase I/O capacity. This ability
allows automation to be added and expanded to solve problems without large project budgets
once wireless network infrastructure is in place. For example, a WirelessHART device can be
connected in minutes, configured in minutes, and integrated in minutes if a host system
strategy is in place.

12.3 Host integration

Integration of data originating from the wireless Gateway into a host control system is normally
performed in one of two ways - through native connectivity directly to the host system or using
standard protocols such as Modbus or OPC.

Section 12: Host System Requirements

February 2016

For native connectivity including vendor specific I/O cards, contact the host vendor.

OPC and Modbus are non-proprietary protocols and use standard data exchange and
integration techniques to map data from the Gateway into the host control system. Typical data
that is mapped to the host are process variables (PV, SV, TV, QV), time stamps (if using OPC),
and overall device status. Diagnostic information is typically passed to an asset management
system via Ethernet. Check with the Gateway vendor for compatible asset management
packages.

Often, existing host systems can be a combination of legacy DCS and PLC components and
modern data management solutions such as data historians. WirelessHART Gateways should
support multiple connections into multiple host systems over multiple protocols. This enables
WirelessHART networks to support modernization of an existing host system. For example,
suppose the existing DCS has no spare capacity and can only receive the 4-20 mA signal from
wired HART devices. A WirelessHART network could be connected to the DCS to bypass the need
for more Analog Input Cards to receive more process variables, while in parallel, HART
diagnostics flow to an asset management program from existing wired HART devices with
WirelessHART adapters. This type of modernization project could enable incremental
modernization with an older host system and when the scheduled turnaround occurs to
upgrade the DCS, the existing WirelessHART networks would transition to the new host system
(see Figure 12-3 for an example transitional architecture).

Host System Requirements

77

Section 12: Host System Requirements

February 2016

Figure 12-3. WirelessHART Gateway to Bridge Information from Non-HART Host

A key output from working with host system administrators is an integration strategy to
incorporate a plant-wide wireless infrastructure. If doing a small application, a key output is the
physical locations of where to connect the Gateways. These will be needed for the network
design process.

Engineering Guidelines

00809-0100-6129, Rev AB

Key outputs for network design include:

 Identifying a host system administrator and system integrator who supports

integration of WirelessHART data into the host system

 Potential physical connection points for WirelessHART Gateways

12.4 Interoperability

Converting WirelessHART data from the Gateway into standard protocols like Modbus and OPC
ensures interoperability of all WirelessHART networks with all host systems. Host systems based
on proprietary protocols will be more difficult to implement, maintain, and expand.

12.5 Host system support for WirelessHART functionality

A WirelessHART Gateway typically performs all management of the WirelessHART network and
manages communications to and from the WirelessHART field devices. The host system should
not require any special software to support the WirelessHART field network.

78

Host System Requirements

Engineering Guidelines

00809-0100-6129, Rev AB

Section 12: Host System Requirements

12.6 Device descriptions files (DD)

Host system, asset management system, or a handheld field communicator to communicate
with a device needs to know the type of data exchange that takes place between host and
device. It is also essential to know how to represent it on the user interface. DD file for the device
provides this function.

WirelessHART DD files can be downloaded from the following HCF link:

HartCommProduct.com/Inventory2/index.php?action=list

12.7 Configuration tools

WirelessHART devices are based on the HART protocol; therefore, existing HART Field
Communicators will work for configuration of the field devices. Field Communicators will
require the proper device descriptor for configuration, which is the same for any other new
HART device, wired or wireless. Host system configuration will be dependent on the host
system. HART vendors with asset management software may extend the benefits of remote
management from wired HART to WirelessHART devices connected to the Gateway.

February 2016

12.8 Control system graphics

Not all data collected from the WirelessHART field network belongs on the operator screen as
part of control system graphics. The risk is that non-pertinent information distracts the operator
from critical information.

The host system integration should be configured such that data from a WirelessHART field
network is delivered to the proper end-user even though network resources are shared. To give
some examples:

 Data collected on consumption of power from rotating equipment should go to the

utilities manager.

 Data collected on vibration spectrums of rotating equipment should go to asset

management.

 Data collected on temperature alarms for rotating equipment should go to operators in

a non-obtrusive way and to the reliability manager.

Properly defining an integration strategy will ensure an efficient collection of data from
WirelessHART network and dissemination to proper end-users. Many end users are not typically
receptive of the benefits of automation and have application specific databases into which data
is manually collected and uploaded. With the ability to integrate WirelessHART data using
standard interface protocols, these existing end-user specific databases can be automatically
populated.

12.9 Node addressing and naming conventions

A WirelessHART device should follow naming conventions of wired HART devices.

Host System Requirements

79

Section 12: Host System Requirements

February 2016

Engineering Guidelines

00809-0100-6129, Rev AB

12.10 Alarms and alerts

Alarms and alerts should be directed to the appropriate end-user and their associated
application and software. Alarm and alert dissemination should be reflective of the end user and
their responsibility. For more details refer to “Alarm recommendations for process plant” on

page 43.

12.11 Maintenance station and asset monitoring

WirelessHART devices provide internal diagnostics and process variables like any wired HART
device. Additional local diagnostics for network connectivity should be accessible locally via a
HART Field Communicator with the correct Device Descriptor for the WirelessHART field device.

The WirelessHART Gateway should also provide additional diagnostics for network performance.
The data from WirelessHART devices will not propagate to the host system if the data is deemed
questionable from either a HART diagnostic or due to an extended delay in reception at the
Gateway from the WirelessHART field device. The Gateway can notify the host system if
communication problems exist. Additionally, the Gateway is responsible for WirelessHART
network management and network diagnostics.

Diagnostics between the Gateway and the host system will depend on the host system and the
Gateway.

12.12 Historian

Historic data collection can be treated the same as any conventional source (e.g. OSIsoft PI or
any DCS historian package).

80

Host System Requirements

Engineering Guidelines

00809-0100-6129, Rev AB

Section 13: Documenting in Intergraph SPI 2009

February 2016

Section 13 Documenting in Intergraph SPI

2009

Section overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 81

User defined fields (UDF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 81

Filtered views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 82

Creating instrument types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 83

Loop drawings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 86

Drawings in smart plant layout (SPL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 88

Documenting security information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 89

13.1 Section overview

WirelessHART® devices can be fully documented in Intergraph SPI with minimal customization.
Below is an example of how to document WirelessHART in a logical, linear order and assumes the
reader is skilled in working with Intergraph SPI. This is just an example to illustrate the
methodology. Ultimately, it is the responsibility of project management to create and reinforce
the application of standards and guidelines within the project environment.

13.2 User defined fields (UDF)

The first step is to create user defined fields that allow for the accounting of WirelessHART
engineering parameters that are necessary for defining whether a point is wireless and how that
point will be connected to a network.

Global UDFs should be created as illustrated in Figure 13-1.

Figure 13-1. : SPI UDF for WirelessHART

Documenting in Intergraph SPI 2009

81

Section 13: Documenting in Intergraph SPI 2009

February 2016

Type refers to the type of value that can be entered for the value of the UDF. In the case of all the
WirelessHART parameters, these are all just CHAR (or characters, also meaning text). Likewise,
the length refers to the max length that can be entered into the field

Detailed definitions of WirelessHART SPI UDFs are presented in Tab l e 1 3- 1 .

Table 13-1. Definitions for WirelessHART SPI UDFs

UDF Field type example Purpose

WirelessHART
(Y/N)

Update Rate Char

1, 2, 4, 8, 16, 32, 64+

Gateway Char

WirelessHART
Adapter

Network
Design Layout

Char

Y

GWY002

Char

WHA001

Char

A101.DWG

Engineering Guidelines

00809-0100-6129, Rev AB

Identify a point as wireless at a high level. Will be used for
quickly applying design guidelines to determine what is and
what is not wireless.

WirelessHART devices will not all scan at 1 second like wired
HART® devices. This value will be important for determining
what devices may be WirelessHART as well as setting
configuration parameters.

Defines which Gateway a WirelessHART device is to be
associated.

Defines which WirelessHART adapter a wired HART device is
associated with if a device does not have integrated
WirelessHART capability.

This is a reference field to a drawing or document that was
used to validate network design best practices.

If the user chooses, SPI rules can be created such that these custom fields only appear for points
that are HART or checked to be WirelessHART. This minimizes exposure to non-pertinent
information for non- WirelessHART devices.

13.3 Filtered views

A custom view of the Instrument Index will be useful for applying design guidelines for selecting
the instruments that are to be wireless as well as for seeing the organization of networks.

Figure 13-2 is a sample view leveraging the UDFs shown in the previous section.

Figure 13-2. Custom View of SPI’s WirelessHART UDFs

82

Documenting in Intergraph SPI 2009

Engineering Guidelines

00809-0100-6129, Rev AB

The “Criticality” and “Update rate” are foundations for any engineering guidelines that
determine whether a device is WirelessHART. Some low criticality loops may have update rates
faster than four seconds; include these with the design guidelines. Note that because
WirelessHART devices primarily run on batteries, WirelessHART may not be suited for all fast
update rate applications.

At a high level, using the “Criticality” and “Update Rate”, engineers can determine whether a
device should be WirelessHART. If wireless, the device will need to be associated with a Gateway.
If a device can only be specified as a wired HART device and requires a WirelessHART adapter,
then the “WirelessHART Adapter” tag information should be defined.

Validate every WirelessHART field network against network design best practices. “Network
Design Layout” provides a reference field to link to the drawing on which network design best
practices were checked.

Section 13: Documenting in Intergraph SPI 2009

13.4 Creating instrument types

Early in the process, define symbols and instrument types and develop a WirelessHART
instrument library. Figure 13-3 illustrates the basic modifications to a HART device to create a
WirelessHART instrument type.

February 2016

Figure 13-3. Defining WirelessHART Instrument Type In SPI

The first step is to create a new device with a new description. In this example, a WirelessHART
flow transmitter is created. Please note that if the device will be specified as a wired HART device
with a WirelessHART adapter, no new instrument types are necessary

Documenting in Intergraph SPI 2009

83

Section 13: Documenting in Intergraph SPI 2009

February 2016

Figure 13-4. Defining a New WirelessHART Instrument in SPI

Engineering Guidelines

00809-0100-6129, Rev AB

Nothing needs to change on the general tab. Be sure to leverage that the device is a HART AI or a
HART AO so that all of the basic parameters of HART apply. Manage the wiring, or lack of wiring
separately. The fact that WirelessHART is based on HART allows leverage of these pre-defined
variables.

Figure 13-5. Defining Wiring Types in SPI

84

Check the box to include the wiring. If this box is not checked when SPI generates loop drawings,
the device cannot be added to loop drawings. This also allows for flexibility for different wiring
configurations, to be defined elsewhere. Examples include wiring WirelessHART adapters in
series with the loop and line power for WirelessHART devices. This process should be repeated
for each unique WirelessHART instrument type.

Documenting in Intergraph SPI 2009

Engineering Guidelines

00809-0100-6129, Rev AB

There are only two instrument types that are unique to WirelessHART and could be considered
ancillary - the WirelessHART Gateway and the WirelessHART adapter. To create these instrument
types, it is recommended to use the symbols YG for a WirelessHART Gateway and YO for a
WirelessHART adapter.

Once the instrument type is defined, the device panel properties can be modified to include
reference symbols. It is recommended to assign symbols for both the Enhanced SmartLoop and
the cable block drawing.

Figure 13-6. Assigning Symbols In SPI

Section 13: Documenting in Intergraph SPI 2009

February 2016

Basic symbols can be created in SPI using the editing tools. Below are examples for WirelessHART
field devices and a WirelessHART Gateway. The zig-zig symbol shown below is defined by ISA. For
more documentation, nothing special is required since signaling is typically not well indicated.
For auto-generated documents, it may be useful to include the update rate by referencing the
UDF, although this is not an absolute requirement. Most importantly, the project management
team decides on a symbol convention and remains consistent throughout the project.

WirelessHART Gateway Symbol WirelessHART Device Symbol

WirelessHART devices can be connected to a WirelessHART Gateway using the User Defined
Field. This type of drawing does not show the path through the WirelessHART network, but does
show the relationship of the WirelessHART device and the WirelessHART Gateway; Figure 13-7 is
an example from the ISA-5.1.

Documenting in Intergraph SPI 2009

85

Section 13: Documenting in Intergraph SPI 2009

February 2016

Figure 13-7. ISA 5.1 Drawing Example

Note that inclusion of update rates and the wireless signal symbol are optional. The authors of
this document found the practice of including such information supportive of adopting and
managing the unique attributes of WirelessHART.

13.5 Loop drawings

Given that WirelessHART field devices do not require signal cabling, the documentation of the
equivalent of wireless loop drawing is very simple to create.

Engineering Guidelines

00809-0100-6129, Rev AB

The key information is to relate each wireless field device to the respective Gateway. It is
recommended that a basic wireless loop drawing show the traditional tag information as well as
the WirelessHART UDFs. This way, it is very clear to see which wireless devices are associated to
which WirelessHART Gateway. Currently, Intergraph SPI 2009 does not have the means to
implement this in a specific drawing, thus it is recommended to use the Instrumentation Index
showing the WirelessHART UDFs.

Figure 13-8. Filtered View of WirelessHART Tags

86

This list can then be filtered and printed by Gateway. A key piece of information is the link to a
drawing verifying that best practices have been verified which can also include physical
instrument location.

Documenting in Intergraph SPI 2009

Engineering Guidelines

00809-0100-6129, Rev AB

Figure 13-9. Tag View Filtered By Gateway

Section 13: Documenting in Intergraph SPI 2009

February 2016

13.5.1 Loop drawings for WirelessHART adapters

A WirelessHART adapter is an accessory to a loop and should be treated as a loop accessory like a
multiplex or transient protection. Loop accessories are traditionally not indicated on the loop
drawing and are installed on site. It is recommended for simplicity that there are no
modifications for the loop drawing of a wired HART device to reflect the presence of a
WirelessHART adapter.

The WirelessHART adapter would be properly documented and accounted for on the Wireless
Loop Drawing that shows the Gateway and all associated WirelessHART devices.

13.5.2 Gateway cable block drawings

A useful drawing to create is a Gateway cable block drawing (refer to Figure 13-10) showing the
Gateway power and communication connections. All WirelessHART Gateways, regardless of
vendor, should have uninterruptable power supplies to maximize system reliability.

Figure 13-10. Gateway Cable Block Diagram

In addition to a cable block diagram, another useful drawing could show all Gateways assigned
to an area on the same document.

Table 13-2 documents WirelessHART configuration parameters.

Documenting in Intergraph SPI 2009

87

Section 13: Documenting in Intergraph SPI 2009

February 2016

Table 13-2. WirelessHART Configuration Parameters

Specification field Typical value

Update rate 4, 8, 16, 32, 64+

Power supply Intrinsically safe, field replaceable battery

Communication type WirelessHART

Since WirelessHART is derived from wired HART, other specification fields should be completed
as if it is a wired HART device.

Figure 13-11. WirelessHART Instrument Specification Sheet

Engineering Guidelines

00809-0100-6129, Rev AB

13.6 Drawings in smart plant layout (SPL)

All WirelessHART devices can be indicated in drawings without deviation from the practices used
for wired HART devices.

WirelessHART Gateways should be located according to the network design guidelines.

88

Documenting in Intergraph SPI 2009

Engineering Guidelines

00809-0100-6129, Rev AB

Section 13: Documenting in Intergraph SPI 2009

13.7 Documenting security information

The WirelessHART security parameters of Net work ID and Device Join Key(s) should not be a par t
of a wireless loop drawing or in the SPI design environment. These are security parameters used
to protect the network and should be managed per a local security policy implemented by the
Owner/Operator. The Network ID and Device Join Key(s) are not required for the design. The
wireless loop drawing associates the WirelessHART device with the WirelessHART Gateway tags.
Separately, secure documents containing WirelessHART security provisioning including the
WirelessHART Gateway tag can be used to cross reference the Network ID and Join Key(s).
Remember, all Network IDs and common Device Join Keys (if used) should be unique for every
Gateway and every WirelessHART field network. This type of security management is similar to
the management of security information for control systems and servers.

February 2016

Documenting in Intergraph SPI 2009

89

Section 13: Documenting in Intergraph SPI 2009

February 2016

Engineering Guidelines

00809-0100-6129, Rev AB

90

Documenting in Intergraph SPI 2009