(B. R. Mehta, Y. J. Reddy) Applying FOUNDATION Fie (B-Ok - CC)

Applying
FOUNDATION Fieldbus
By B. R. Mehta
and Y. J. Reddy
Notice
The information presented in this publication is for the general education of the reader. Because nei-
ther the author nor the publisher has any control over the use of the information by the reader, both the
author and the publisher disclaim any and all liability of any kind arising out of such use. The reader is
expected to exercise sound professional judgment in using any of the information presented in a particu-
lar application.
Additionally, neither the author nor the publisher has investigated or considered the effect of any
patents on the ability of the reader to use any of the information in a particular application. The reader is
responsible for reviewing any possible patents that may affect any particular use of the information pre-
sented.
Any references to commercial products in the work are cited as examples only. Neither the author
nor the publisher endorses any referenced commercial product. Any trademarks or tradenames refer-
enced belong to the respective owner of the mark or name. Neither the author nor the publisher makes
any representation regarding the availability of any referenced commercial product at any time. The
manufacturer’s instructions on the use of any commercial product must be followed at all times, even if
in conflict with the information in this publication.
Copyright © 2016 International Society of Automation (ISA)

All rights reserved.
Printed in the United States of America.

10 9 8 7 6 5 4 3 2
ISBN: 978-1-941546-71-0
No part of this work may be reproduced, stored in a retrieval system, or transmitted in any form or by
any means, electronic, mechanical, photocopying, recording or otherwise, without the prior written per-
mission of the publisher.
ISA
67 T. W. Alexander Drive
P.O. Box 12277
Research Triangle Park, NC 27709
Library of Congress Cataloging-in-Publication Data in process

Acknowledgment
I would like to express my sincere thanks and gratitude to the people whose
significant contributions and support helped me to prepare and publish this
book through ISA.
First, I would like to thank my co-author, Dr. Y. J. Reddy, who contributed

countless hours of effort to help make this book a reality. He had to work very
hard to meet the publishing schedule and to make quick corrections as and
when required. I would also like to thank cartoonist Mr. Parimal Joshi, who
created drawings based on the FOUNDATION Fieldbus theme and allowed us
to include them in this book.
I would like to express my sincere gratitude to the management of Reliance

Industries Limited, for adopting innovative FOUNDATION Fieldbus technology
in a large refinery and petrochemicals plant for the first time in India. I would
personally like to thank Mr. Mukesh Ambani, chairman and managing direc-
tor of Reliance, and Mr. Hital Meswani, executive director of Reliance, a com-
pany that has been chosen as a leader for control systems and instrumentation
for more than 30 years.
We would also like to thank a number of people from other organizations for
their encouragement and assistance. First, I would like to thank Richard Tim-
oney, president and CEO of Fieldbus Foundation organization. Next, I would
like to express my gratitude to the Invensys organization that implemented
FOUNDATION Fieldbus technology on a Foxboro IA distributed control system,
v
vi Applying FOUNDATION Fieldbus
and the excellent support from the entire development team and all their
experts. My thanks also go to John Eva, executive sponsor for Reliance, who
assisted us with smoothly implementing the technology.
I would like to thank the ISA organization and especially Susan Colwell, who
helped to edit and publish the book.
I would also like to express my appreciation for the on-going encouragement

and support of my family. I thank my parents and my wife, Dina, for being
constant sources of encouragement.
Dr. B. R. Mehta
About the
Authors
B. R. Mehta, PhD, is the senior vice president of Reli-

ance Industries Ltd., Mumbai, and has more than 43
years of experience in the refinery and petrochemicals
industry. He has worked on control systems and
instrumentation engineering projects for Patalganga,
Hazira, and Jamnagar Refinery & Petrochemicals
during his 30+ years with Reliance Industries. Before
joining Reliance, he worked for Agro-Chemical &
Food Co., Kenya, as chief instrumentation engineer
and for Indian Petrochemicals Ltd., Vadodara, for 11
years as instrument engineer. He is currently heading the design and engi-
neering department for control systems and instrumentation. He has worked
on basic engineering, detailed engineering, procurement, inspection, expedit-
ing, construction, testing, pre-commissioning and commissioning of various
petrochemicals, chemicals, co-generation power and refinery projects from
concept to commissioning. He is the nominated chairman of the End User
Council of Fieldbus Foundation in India and is a member of the End User
Advisory Council worldwide. Mehta became an ISA Fellow in 2013 for inno-
vative design and implementation of FF technology in major refinery and pet-
rochemical complexes. He is the district vice president of D14 for ISA. He has
a doctorate of professional entrepreneurship, majoring in engineering man-
agement, from the European Continental University. For his outstanding con-
tribution in the field of instrumentation he was awarded Global Achievers
Award at the House of Lords UK.
vii
viii Applying FOUNDATION Fieldbus
Y. J. Reddy, PhD, has a wealth of experience in the field

of industrial automation and control. He graduated with
a degree in electronics and instrumentation engineering
in 1997 from KITS, Warangal, has a master’s in software
systems from BITS, Pilani, and has a PhD in Instrumenta-
tion and Control Engineering from JNTUK, India. Earlier
in his career he worked for JOCIL Ltd, a subsidiary of
The Andhra Sugars Limited, as an engineer (instrumen-
tation), responsible for maintenance and project activities
of the instrumentation and control engineering team. He is currently working
as an engineering manager for process measurement and control systems at
HTS Labs India. He is a member of ISA and is a Certified Automation Profes-
sional (CAP).
Contents
Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .v
About the Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .vii
Chapter 1 Introduction to FOUNDATION Fieldbus . . . . . . . . . . . . . . . . . . . . . . . . . .1

1.1 The Evolution to FOUNDATION Fieldbus . . . . . . . . . . . . . . . . . . . . . . 2
1.2 History of FOUNDATION Fieldbus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
FOUNDATION Fieldbus – Current Outlook. . . . . . . . . . . . . . . . . . . . 6
FOUNDATION Fieldbus – The Future. . . . . . . . . . . . . . . . . . . . . . . . . 7
Primary Drivers for FOUNDATION Fieldbus . . . . . . . . . . . . . . . . . . 9
Lack of Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Lack of Standardization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Benefits of Standardization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Chapter 2 FOUNDATION Fieldbus Technology. . . . . . . . . . . . . . . . . . . . . . . . . . . .15

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
H1 FOUNDATION Fieldbus Benefits. . . . . . . . . . . . . . . . . . . . . . . . . 16
Multiple Variables with Bidirectional Communication . . . . . . . 16
Reduction in System Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Wiring Savings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
HSE Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Subsystem Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Function Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Control Backbone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Standard Ethernet Network Equipment . . . . . . . . . . . . . . . . . . . . 20
ix
x Applying FOUNDATION Fieldbus
2.2 Communications in FOUNDATION Fieldbus . . . . . . . . . . . . . . . . . . . 20

Physical Layer (31.25 Kbps) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
31.25-Kbps Fieldbus Signaling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
31.25-Kbps Fieldbus Wiring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Data Link Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
FOUNDATION Fieldbus Device Types . . . . . . . . . . . . . . . . . . . . . . . 26
Device Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Scheduled Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Unscheduled Communication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Function Block Scheduling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3 Fieldbus Access Sublayer (FAS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Client/Server VCR Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Report Distribution VCR Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Publisher/Subscriber VCR Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4 User Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Function Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Resource Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Transducer Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Application Function Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.5 Objects in Fieldbus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Link Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Trend Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Alert Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Multivariable Container Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
View Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Access Rights FOUNDATION Fieldbus . . . . . . . . . . . . . . . . . . . . . . . 41
2.6 Interoperability Test Kit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Device Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Host Interoperability Test in FOUNDATION Fieldbus . . . . . . . . . . 45
Host Interoperability Support Test Profiles . . . . . . . . . . . . . . . . . 46
Chapter 3 Function Blocks in FOUNDATION Fieldbus. . . . . . . . . . . . . . . . . . . . . .51

3.1 Analog Input (AI) Function Block . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Signal Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Block Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Alarm Detection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Status Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Contents xi
Advanced Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.2 Analog Output (AO) Function Block . . . . . . . . . . . . . . . . . . . . . . . . 62
Setting the Output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Set-Point Selection and Limiting . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Conversion and Status Calculation . . . . . . . . . . . . . . . . . . . . . . . . 66
Action on Fault Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Block Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Status Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.3 Proportional-Integral-Derivative Function Block . . . . . . . . . . . . . 68
Set-Point Selection and Limiting . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Feedforward Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Output Selection and Limiting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Bumpless Transfer and Set-Point Tracking. . . . . . . . . . . . . . . . . . 77
Reverse and Direct Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Reset Limiting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Status Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.4 Discrete Input Function Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
I/O Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Field Value Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Alarm Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Block Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Status Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Action on Failure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.5 Discrete Output Function Block. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Setting the Output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Action on Fault Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Block Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Status Handling/Action on Failure. . . . . . . . . . . . . . . . . . . . . . . . . 88
3.6 Application Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
xii Applying FOUNDATION Fieldbus
Application Example: Pressure Transmitter Used

to Measure Level in an Open Tank. . . . . . . . . . . . . . . . . . . . . . . . . 88
Application Example: Differential Pressure Transmitter
to Measure Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Application Example: Using an AO Block and a Valve
to Control Flow in a Pipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Application Example: Basic PID Block for Steam
Heater Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Application Example: Feedforward Control . . . . . . . . . . . . . . . . . 95
Application Example: Cascade Control with
Master and Slave Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Application Example: Cascade Control with Override . . . . . . . . 98
Chapter 4 Installation of FOUNDATION Fieldbus . . . . . . . . . . . . . . . . . . . . . . . . .101

4.1 Topologies of a FOUNDATION Fieldbus Network . . . . . . . . . . . . . 101
Point-to-Point Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Bus with Spurs Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Daisy Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Tree Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Combinations of the Above . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.2 H1 Bus Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.3 High-speed Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Bridge to H1-HSE Coupling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
4.4 Intrinsic Safety in FOUNDATION Fieldbus . . . . . . . . . . . . . . . . . . . 108
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Ignition Curves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Entity Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
FISCO Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Fieldbus Nonincendive Concept . . . . . . . . . . . . . . . . . . . . . . . . . 118
Live Working . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Energy-limited Fieldbus Topologies . . . . . . . . . . . . . . . . . . . . . . 119
Limitations of FISCO and FNICO . . . . . . . . . . . . . . . . . . . . . . . . 121
High Power Trunk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
FOUNDATION Fieldbus Physical Layer Monitoring
and Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
4.5 Wiring, Grounding and Shielding . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Wiring Practices in FF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Shielding and Grounding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Power Supply Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Contents xiii
Chapter 5 Engineering Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143

5.1 Engineering Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Selection of the Distributed Control System . . . . . . . . . . . . . . . . 143
Spare Capacity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Selection of Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Device Support Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Device Power Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Device Parameter Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Advance Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
5.2 H1 Segment Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Cabling Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Cable Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Cable Sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Grounding, Shields, and Polarity . . . . . . . . . . . . . . . . . . . . . . . . . 150
Terminators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Redundant FOUNDATION Fieldbus H1-Interface Cards. . . . . . . 152
Segment Power Supplies/Power Conditioners . . . . . . . . . . . . . 152
Surge Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Bulk Power Supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
5.3 Hazardous Area Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Nonhazardous Area (Safe Area) Design . . . . . . . . . . . . . . . . . . . 154
Risk Management and Segment Design . . . . . . . . . . . . . . . . . . . 154
Additional Segment Segregation . . . . . . . . . . . . . . . . . . . . . . . . . 156
5.4 Control Assignment/Location. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Temperature Multiplexer Transmitters . . . . . . . . . . . . . . . . . . . 159
Motor-operated Valves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
5.5 Device Function Block Configuration Parameters . . . . . . . . . . . . 160
User Application Blocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Resource Block. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Transducer Blocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Function Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
5.6 Control and Data Handling of FF Devices . . . . . . . . . . . . . . . . . . . 162
Fault Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Configured Fail State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Mechanical Fail State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Fault Handling in Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Remote Shed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Fault State Initiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
xiv Applying FOUNDATION Fieldbus
Mode Degradation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Failure Initiation Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Fault State Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Regulatory Process Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Set-Point Clamps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Anti-windup Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Control and Execution Monitoring. . . . . . . . . . . . . . . . . . . . . . . . 170
Factory Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Control Loop Execution Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
LAS and FB Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Optimizing Fieldbus Link Schedules . . . . . . . . . . . . . . . . . . . . . 171
Performance Optimization Opportunities. . . . . . . . . . . . . . . . . . 173
Prioritization of Schedule Elements . . . . . . . . . . . . . . . . . . . . . . . 179
5.7 Redundancy Options in FOUNDATION Fieldbus . . . . . . . . . . . . . . 180
Introduction to Redundancy Options in
FOUNDATION Fieldbus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Transmitter Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
High-speed Ethernet Redundancy . . . . . . . . . . . . . . . . . . . . . . . . 182
Controller Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Media Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Complete Network Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . 185
Valve Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Power Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
LAS Redundancy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
5.8 FOUNDATION Fieldbus – Control in Wire . . . . . . . . . . . . . . . . . . . . 189
Benefits of Control in the Wire . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Limitations of Control in the Field . . . . . . . . . . . . . . . . . . . . . . . . 202
Chapter 6 Device Integration Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . .205

6.1 Device Description (DD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Device Description Language (DDL) . . . . . . . . . . . . . . . . . . . . . . 205
Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
DDL Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
DDL Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Benefits of DD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Limitations of DD Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
6.2 Electronic Device Description Language (EDDL). . . . . . . . . . . . . 211
Matching Needs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Contents xv
Ease of Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

Empowering Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Operator Information and Interaction . . . . . . . . . . . . . . . . . . . . . 214
Addressing Engineering Requirements. . . . . . . . . . . . . . . . . . . . 216
EDDL Technology Independence. . . . . . . . . . . . . . . . . . . . . . . . . 217
EDDL Platform and Protocol Independence . . . . . . . . . . . . . . . 218
EDDL Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Intelligent Device Management: Device Diagnostics
Using EDDL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Device Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Device Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Device Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Transmitter Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
6.3 Field Device Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Introduction to FDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Basics of FDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Frame Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Device Type Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Communication DTM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Gateway DTM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Device DTM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Communication Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Process Channels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Host Data Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Benefits of Using FDT/DTM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Specifying FDT Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
6.4 Field Device Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
FDI Technology – FDI Package. . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Harmonization of EDDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
FDI Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
FDI Host Client Server Architecture . . . . . . . . . . . . . . . . . . . . . . 237
Stand-alone FDI Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
FDT-based FDI Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Benefits of FDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
6.5 Usability in FOUNDATION Fieldbus . . . . . . . . . . . . . . . . . . . . . . . . . 242
Chapter 7 Maintenance in FOUNDATION Fieldbus. . . . . . . . . . . . . . . . . . . . . . . .245

7.1 Introduction to FF Maintenance. . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
7.2 Advantages of Introducing Asset Management Systems . . . . . . 246
xvi Applying FOUNDATION Fieldbus
Reduction in Financial Losses Caused by

Unexpected Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Reducing Unnecessary and Nonurgent Maintenance . . . . . . . . 246
Remote Diagnostics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
FOUNDATION Fieldbus Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . 249
FOUNDATION Fieldbus–enabled Maintenance. . . . . . . . . . . . . . . 250
Asset Management–enabled Systems . . . . . . . . . . . . . . . . . . . . . 252
7.3 Calibration of Fieldbus Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Calibration versus Range Setting . . . . . . . . . . . . . . . . . . . . . . . . . 253
Performing Calibration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
7.4 FOUNDATION Fieldbus Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . 259
Fieldbus Device Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Temperature Transmitter Diagnostics . . . . . . . . . . . . . . . . . . . . . 261
Pressure Transmitter Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . 261
Control Valve Positioner Diagnostics. . . . . . . . . . . . . . . . . . . . . . 262
Diagnostics from Discrete Devices . . . . . . . . . . . . . . . . . . . . . . . . 262
Process Alarms from Fieldbus Devices . . . . . . . . . . . . . . . . . . . . 263
Information from Fieldbus Devices . . . . . . . . . . . . . . . . . . . . . . . 267
Replacing FOUNDATION Fieldbus Devices . . . . . . . . . . . . . . . . . . 267
NAMUR in FOUNDATION Fieldbus . . . . . . . . . . . . . . . . . . . . . . . . 269
Chapter 8 Benefits of Using FOUNDATION Fieldbus . . . . . . . . . . . . . . . . . . . . . .277

8.1 Project Lifecycle Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Cost of Purchase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Engineering Savings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Construction Savings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Maintenance Savings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Operations Savings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Lower Cost of Expansion and Change . . . . . . . . . . . . . . . . . . . . . 305
Chapter 9 Specifications List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .309
Bibliography. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .311
Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .315
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .323
1
Introduction to
FOUNDATION Fieldbus
The conventional signal connections from a sensor to a controlling device

requiring the sensed value (or from a controlling device to an actuator) are a
4–20 milliamp or 1–5 volt signal standard. Although they are very limiting in
nature (e.g., multiple wire connections, cost of cable laying, signal conver-
sions), these analog connections have worked for years. They do not permit
intelligent devices to “talk” to one another except to provide the single pri-
mary variable to be converted to an analog signal on the way out of one digi-
tal device and converted back to a digital value on the way into the other
digital device. Each conversion decreases accuracy and limits precision. Ana-
log signals are not very secure, and analog circuits are not as reliable as digital
circuits. A standard digital communications protocol that enables intelligent
devices to share primary values, parameters, display and trending informa-
tion, and even alarms and events is the need of the hour. Furthermore, a mul-
tidrop communications network would reduce new wiring costs significantly
and permit peer-to-peer communications. Fieldbus is a concept designed to
satisfy these very needs.
Let us attempt to understand the evolution of FOUNDATION Fieldbus, includ-

ing its history; primary drivers of such technology; how FOUNDATION Field-
bus works; different application scenarios; different rendering technologies
applicable in FOUNDATION Fieldbus; installation, engineering, and mainte-
nance considerations; benefits to the users; and economics of using FOUNDA-
TION Fieldbus in projects.
1
2 Applying FOUNDATION Fieldbus
1.1 The Evolution to FOUNDATION Fieldbus

In the beginning there was “local” control and monitoring. With local control
and monitoring, the various plants inside a complex were self-sufficient in
terms of the monitoring and control aspects. Some control rooms existed with
limited centralized control. Figure 1-1 illustrates the scenario where most of
the local control is handled by the control panels in each of these plants with
limited wiring to the central control room; again, the communications is by
means of analog signals only. The advantage of local control and monitoring
was the need for little wiring. But the disadvantages outweighed the advan-
tages, as there was not much control, not much monitoring, and not much in
the way of alarming.
Figure 1-1. Local Control and Monitoring
The minicomputer introduced the possibility of “centralized” control and

monitoring, with the sensors and actuators wired into a central computer.
This is referred to by some as direct digital control (DDC), wherein the local
control panels are replaced with massive centralized control using analog
communication across the breadth of the plant. DDC offered the advantage of
a central view and control of the process and much more flexible control,
monitoring, alarming, and even historic data capabilities. The disadvantages
were the cost of the complex wiring, the risk of operational loss in case of com-
puter failure, and the inability to easily expand the system once the capacity of
Chapter 1 – Introduction to FOUNDATION Fieldbus 3
the computer was reached. The flexibility and advantages are offset by the
high engineering and installation costs and system complexity. Figure 1-2
depicts the conceptual view of such an arrangement.
Figure 1-2. Centralized Control and Monitoring
With the advent of the microcomputers, distributed processing units were

located around the plant, closer to the process. They were connected to the
control room via proprietary digital communications lines called data high-
ways. The concept was called “distributed” control and monitoring. This
greatly reduced the wiring costs, limited the failure consequence, and reduced
the costs of adding more points. The disadvantages were that wiring costs
were still significant, and there was now a lack of interoperability between the
controllers/subsystems of various manufacturers. Figure 1-3 depicts such a
system where the local control is with the central monitoring and control via a
digital bus.
The next step in the evolution of the monitoring and control architecture is
driven by the emergence of a digital, multidrop communications protocol
standard. The digital communications link can interconnect the sensors and
Figure 1-3. Distributed Control
actuators to the control room; control can be located local to the devices; and
the digital devices can communicate directly to each other and mutually
exploit each other’s capabilities fully. The concept is called “fieldbus” control
and monitoring. The advantages include still lower wiring costs, still smaller
failure consequences, still smaller expansion costs (scalability), and multiven-
dor interoperability. Distributed control systems (DCSs) and programmable
logic controllers (PLCs) can be more easily and more tightly interconnected.
Manufacturers can take full advantage of the digital nature of the devices.
New features become feasible, which cannot be fully utilized without a digital
communications standard. Figure 1-4 represents the concept of control in the
context of digital communication buses.
1.2 History of FOUNDATION Fieldbus

The ISA50 committee initiated the effort to standardize the digital communi-
cation protocol for the process industries in the ‘80s. Significant effort was
expended to define the technical requirements and build a consensus for the
digital fieldbus standards. In the meantime, the leading process control sup-
Figure 1-4. Fieldbus Control System
pliers started to work on their proprietary digital communication standards.

The multiple efforts led to a handful of competing protocols that would not
integrate among themselves. The two parallel supplier consortiums in North
America—the Interoperable Systems Project (ISP) and WorldFIP (Factory
Instrumentation Protocol)—merged in 1994 to form the Fieldbus Foundation
(FF). The new organization brought the ability to create an internationally
acceptable digital fieldbus standard. Manufacturers, end users, academic
institutions, and other interested parties became members of the Fieldbus
Foundation and developed an open, nonproprietary specification known as
FOUNDATION Fieldbus. This advanced digital communication solution was
designed from the ground up to support mission-critical control applications
where the proper transfer and handling of data is essential. The standard was
created to replace incompatible networks and systems with an open, fully
integrated architecture for information integration and distributed, real-time
control.
With these standards and technologies, end users gained the power to imple-
ment tightly integrated digital control based on unified system architecture
and a high-speed backbone for plant operations. This in turn removed the pre-
vious constraints on device and subsystem interoperability. In the late 1990s,
the technology was recognized and adopted by the international governing
bodies, which were critical for its acceptance by the process industry. These
governing bodies included:
• American National Standards Institute (ANSI)/International Society of

Automation (ISA) as ANSI/ISA-50.2*
• International Electrotechnical Commission (IEC) as IEC 61158
• European Committee for Electrotechnical Standardization (CENELEC)

as EN 50170
*Note: For the current status of the noted standards and technical reports,
visit www.isa.org/standards and www.iec.ch.
FOUNDATION Fieldbus – Current Outlook

With the pioneering work of the past few decades, the FOUNDATION fieldbus
technology has now achieved standards status among end users. Implementa-
tion of the FOUNDATION Fieldbus systems architecture is growing at a fast rate
in diverse industries across the world.
There are many devices on the market that are tested and registered as fully
interoperable fieldbus devices. The list of approved devices is available on the
FF website and is continuously updated with the addition of new devices.
The Fieldbus Foundation established the host registration program in 2009,

and now the fieldbus hosts who successfully complete the test requirements
are authorized to bear the official product registration symbols. The host sys-
tems may include configuration tools, recording devices, alarm display pan-
els, human-machine interfaces (HMIs), or systems with a combination of
functionality.
Millions of FOUNDATION Fieldbus–compliant devices and hundreds of thou-

sands of fieldbus systems have been shipped or installed to date. Successful
FF technology-based installations can be found globally in industries such as
petrochemicals, refining, chemicals, oil and gas, metals and mining, water,
wastewater, life sciences, and pharmaceuticals.
FOUNDATION Fieldbus – The Future

To keep pace with industry requirements, the Fieldbus Foundation has under-
taken a series of exciting new initiatives to take the FOUNDATION Fieldbus sys-
tem architecture well into the 21st century.
For example, the Fieldbus Foundation and NAMUR, an international user

association for automation technology in the process industries, have collabo-
rated on enhancements to FOUNDATION Fieldbus technology. Considering the
NAMUR NE107 (Self-Monitoring and Diagnosis of Field Devices) recommen-
dations for diagnostic profiles support, the Fieldbus Foundation developed a
diagnostic profiles specification, enhancing organization and integration of
device diagnostics within FOUNDATION Fieldbus systems.
The FOUNDATION Fieldbus Diagnostic Profiles Specification identifies “role-

based diagnostics” for fieldbus equipment and defines a consistent set of
parameters for diagnostic alarming. This approach supports categorization of
diagnostics, according to NE107, thereby ensuring the availability of the right
diagnostic information to the right person at the right time. In addition, it
allows the most appropriate diagnostics to be applied to a particular plant
application, such as process control engineering or asset management and
maintenance.
Fieldbus Foundation, in cooperation with the world’s leading safety experts,

also developed FOUNDATION Fieldbus for safety instrumented functions (SIF),
technical specifications supporting the design and end user implementation of
safety technology compliant with IEC guidelines. The FOUNDATION Fieldbus
architecture, with its industry-proven distributed function blocks and open
communications protocol, is an ideal platform for advancing standards-based
safety system technology.
The Foundation for SIF technical specifications enables end users to take
advantage of open fieldbus technologies to improve integration and interop-
erability of safety instrumentation, while reducing system and operational
costs such as annual shutdowns for test and validation purposes.
In addition, FF has launched its FOUNDATION Fieldbus for Remote Operations

Management (ROM) initiative. This development is part of the FF’s continu-
ing initiative to design and deploy an infrastructure that accommodates
evolving wireless standards inclusive of Wireless HART® and ISA-100.11a.
FOUNDATION Fieldbus for ROM provides an interface to both technologies

and uses Electronic Device Description Language (EDDL) and function blocks
to ensure interoperability with other FOUNDATION Fieldbus for ROM devices.
H1 (field device level bus) and high-speed Ethernet (HSE) in the FOUNDATION
Fieldbus automation architecture provide a distributed function block capa-
bility with HSE serving as a larger pipeline with increased speed and through-
put. The FOUNDATION Fieldbus for ROM solution expands these capabilities
by establishing open, nonproprietary specifications for an interface to wireless
field device networks, a wired HSE backhaul, and a wireless HSE backhaul
integrating various wireless sensor networks. As part of this solution, FOUN-
DATION Fieldbus for ROM provides an efficient way to bring large concentra-
tions of discrete and analog field I/O back to the control room using HSE
communication.
FOUNDATION Fieldbus for ROM promises to change the world of remote oper-
ations management for pipeline supervisory control and data acquisition
(SCADA), tank farms and terminals, offshore platforms, and water/waste-
water facilities. This solution is key to the improved integration of critical
functional areas, including machinery health monitoring, safety interlocks,
fire and gas detection systems, and video surveillance.
The Fieldbus Foundation is also a part of the Field Device Integration (FDI)
Cooperation Project, partnering with leading automation technology consor-
tiums, suppliers, and end users. This effort is aimed at a uniform device
integration solution for the process industries across all host systems, devices,
and protocols. It is based on rigorous use case requirements, incorporates the
best aspects of each member technology, and eliminates redundancies where
they may exist. The FDI solution does away with double efforts for customers
and vendors and preserves backward compatibility and operating system
independence.
The Fieldbus Foundation has recently launched a new technology develop-

ment initiative intended to make the digital fieldbus automation experience
easier than conventional analog control systems in every conceivable way—
from device setup to device replacement and daily maintenance practices.
These initiatives drive an innovation strategy enabling plant owners to focus

more on what technology can do for them and their businesses, versus how
they manage the technology itself. The focus on standards-based solutions

also makes it easier for automation suppliers to develop new fieldbus-based
products and applications. In addition, the FF’S testing and registration pro-
cess is designed to ensure FOUNDATION Fieldbus devices, systems, and com-
ponents all work together as they should.
Primary Drivers for FOUNDATION Fieldbus

As previously discussed, the Fieldbus Foundation was formed to complete
the development of a single, open, international, and interoperable “fieldbus”
built by major control system user groups, process control and manufacturing
automation companies, and standards organizations. The Fieldbus Founda-
tion is an independent, not-for-profit organization based on the following
principles:
• Fieldbus technology is an enabling technology, not a differentiating

technology.
• Fieldbus technology is open and available to all parties.
• Fieldbus technology is based on the work of the IEC and the ISA50
standards committee.
• FF members support and work with the international and national

standards committees.
FOUNDATION Fieldbus is a growing field device network in process control

systems. The FOUNDATION Fieldbus network interconnects the sensors, actua-
tors, controllers, and HMI in the process control systems in the form of a bus.
The technology enables control and information to be exchanged among the
participating systems. The FOUNDATION Fieldbus−based control systems are
getting wider acceptance from end users and manufacturers; hence, the instal-
lation growth of such systems over the years. The following are some of the
needs that drove the instrumentation and control engineering community to
look for options from the instrumentation and control systems suppliers, stan-
dards-based organizations, universities, and process industries.
Lack of Interoperability
When digital communications first began to appear, every vendor invented its
own independent protocol. Soon many different proprietary protocols existed
in the market, drastically limiting interoperability. Moreover, documentation
on the operation of these protocols was typically not available, and patents
generally protected the technology. Other manufacturers would have to pay
high licensing fees to implement the technology in their products—if they
were allowed to do so at all.
This situation caused several problems. One was that no vendor had a range
of products wide enough to provide all the parts a plant required, so it was
always necessary to mix and match equipment from different suppliers.
Because the equipment from different suppliers used incompatible protocols,
a site was stuck with two undesirable options: either choose the preferred
device despite its poor integrating ability or settle for the less-than-best device
to gain better integration.
It was not possible to network the devices together most of the time, resulting
in isolated islands of automation. In one common scenario, a PLC and a DCS
would have to be connected, but digital integration of the system was impos-
sible since each component communicated using a different protocol.
If the manufacturers allowed licensing and provided proper documentation, a

communication driver could be developed; however, this would be done at a
great expense of time and money. A third party often developed the drivers,
and each party blamed the other in the event of communication problems. To
complicate matters further, a dedicated driver was required for every combi-
nation of hardware and software, producing an unmanageable situation for
suppliers too. Many times no communication at all was possible, and to pass
data, subsystems had to fall back on conventional analog and discrete signals.
Owing to protocol differences, third-party field instruments could not be inte-
grated with the DCS to fully benefit from their intelligence, nor could one sup-
plier’s hand-held terminal or other configuration tool work with a device
from another.
Once a proprietary system had been purchased, the plant was essentially
“locked in” by the manufacturer. To maintain system integration the plant
would have to purchase replacement transmitters from the system supplier,
who was also the only one that could do system expansions. Replacement
parts and extras were priced much higher than the initial system, as the sup-
plier had a monopoly. Many plants were aware of this but were still willing to
pay the price of being tied to a single manufacturer simply because of the high
cost of struggling with system integration in a situation where incompatible
protocols required drivers.
Many instrument suppliers were also displeased with the situation. Despite
the fact that they often had higher-performance products, the instrument sup-
pliers were unable to compete with the systems suppliers simply because of
the incompatibilities. Furthermore, adapting their products to myriad proto-
cols was extremely costly, driving up product prices. In the absence of stan-
dards, there was anarchy in the market.
Lack of Standardization
As the situation was clearly becoming intolerable, in 1985 industry experts
from users of instrumentation, organizations developing standards, consor-
tiums of suppliers, and universities began work on a vendor-independent
fieldbus standard. Networking is a key element of an open system, and the
development of an interoperable fieldbus supported by multiple vendors and
based on a freely available standard without licensing became imperative.
Standardization is an enormous task that not only involves the development

of a technology, but has economic and political implications for factories,
manufacturers, and sometimes even nations. Owing to the unique needs of
the process control environment, no existing networking standard could be
used. A new technology had to be developed for the standard that provided
bus power, intrinsic safety, and the ability to communicate long distances
over conventional instrument wires, and so on. This development process led
to an international fieldbus that could not move as fast as other networks that
used an existing platform from telecommunications or the automotive indus-
try. Nevertheless, it filled an important need.
Many of the systems suppliers who participated in developing the standard

had vested interests in the old technology and a comfortable market share in
the proprietary paradigm. Standards offer customers the freedom to move
away from being locked in to a particular supplier’s proprietary technology.
Therefore, these proprietary suppliers naturally hoped for the failure of the
fieldbus standard, so they could avoid tougher competition.
Some companies and nations wanted to see their existing technology and
national standards adopted as the international fieldbus standard. These fac-
tors further contributed to the delay in the ratification of the single fieldbus
standard. The world failed to agree on a single standard protocol, and as a
result several competing and noncompatible bus technologies were being
included in a multipart standard that continues to evolve and expand as the
original eight-part fieldbus standard is now up to 21 parts. (Refer to the bibli-
ography for the different parts of the standard.)
Benefits of Standardization
Once the FOUNDATION Fieldbus standards were in place, plants could truly
begin to benefit from integration without paying the high price of being tied
to a single manufacturer. FOUNDATION Fieldbus standards have already
resulted in compatible equipment now available from several suppliers. Now

many companies manufacture device types that are based on the FOUNDATION
Fieldbus technology. This has led to a competitive open market, a desirable
development because it reduced cost.
Plants that employ FOUNDATION Fieldbus are protected from proprietary

solutions that force them to be dependent on a single vendor. Similarly, the
plants that have adopted FOUNDATION Fieldbus have more options available
for devices and software. This enabled plant engineers to find specific solu-
tions for diverse application needs. These needs cannot be met by a single
supplier, but require equipment from several manufacturers. This translates
to device manufactures once again concentrating on true innovations rather
than tweaking communication protocols.
2
FOUNDATION Fieldbus
Technology
2.1 Introduction
FOUNDATION Fieldbus is an all-digital, serial, two-way communication sys-
tem. H1 (31.25 Kbps) interconnects “field” equipment such as sensors, actua-
tors, and I/O. High-speed Ethernet (HSE) (100 Mbps) provides integration of
high-speed controllers (such as PLCs), H1 subsystems (via a linking device),
data servers, and workstations. FOUNDATION Fieldbus is the only protocol
with the built-in capability to distribute the control applications across the
network. Management information system (MIS), enterprise resource plan-
ning (ERP), and human-machine interface (HMI) packages access the fieldbus
information via the data services.
The H1 fieldbus retains and optimizes the desirable features of the 4–20 milli-
ampere (mA) analog system such as:
• Single loop integrity
• A standardized physical interface to the wire
• Bus-powered devices on a single wire pair
• Intrinsic safety options
In addition, FOUNDATION Fieldbus enables:
• Increased capabilities from full-digital communications
15
• Reduced wiring and wire terminations due to multiple devices on one

wire
• Increased selection of suppliers due to interoperability
• Reduced loading on the control room equipment due to distribution of

control and input/output functions to the field devices
• Connection to the HSE backbone for the larger systems
The key features enabled by the FOUNDATION Fieldbus technology provide

several benefits to the users.
H1 FOUNDATION Fieldbus Benefits

Using the FOUNDATION Fieldbus leads to some of the following direct savings
in cost. In addition, there are various intangible benefits that are not listed
here.
• Reduced number of wires and marshalling panels
• Reduced number of intrinsic safety barriers
• Reduced number of input/out converters
• Reduced number of power suppliers and cabinets
• Reduced size of equipment rooms
• Remote configuration of field devices
• More information available for operations
• Increased accuracy of measurements
• Easier evolution due to standardized functional blocks
• Increased sophistication and flexibility of instrumentation
• Increased uptime due to less equipment, better self-diagnostics, and

remote diagnostics
Multiple Variables with Bidirectional Communication

The fieldbus allows multiple variables from each device to be brought into the
control system for archival, trend analysis, process optimization studies,
report generation, predictive maintenance, and asset management. The high
Chapter 2 – FOUNDATION Fieldbus Technology 17
resolution and distortion-free characteristics of digital communications

enables improved control capability, which can increase product yields. The
difference lies in the intelligence of the field devices in a FOUNDATION Field-
bus network: each participant device is like a controller in a traditional sense.
Intelligent field devices connected in the form of a bus bring the advantages
that an intranet has brought to the information technology world. Bidirec-
tional communication compared with traditional systems is depicted in
figure 2-1.
Figure 2-1. Fieldbus – Multiple Variables, Both Directions
Reduction in System Hardware

FOUNDATION Fieldbus uses standard “function blocks” to implement the con-
trol strategy. Function blocks are standardized automation functions. Field
devices use function blocks to perform many control system functions, such as
analog input (AI), analog output (AO), and proportional-integral-derivative
(PID). The consistent, block-oriented design of function blocks allows distri-
bution of functions in field devices from different manufacturers in an inte-
grated and seamless manner, thus reducing the risk of system failure.
Distribution of control into the field devices can reduce the amount of I/O and
control equipment needed, including card files, cabinets, and power supplies.
Figure 2-2 represents the new paradigm of control in the field with the func-
tion blocks being the residents of the devices and hence saving hardware
costs.
Figure 2-2. Hardware Reduction
Wiring Savings
The H1 Fieldbus allows many devices to connect to a single wire pair, result-
ing in less wire, fewer intrinsic safety barriers, and fewer marshalling cabinets
being required. Multiple point-to-point analog wires, each carrying a single
parameter across the plant, are being replaced by a single pair of wires acting
like a bus and carrying the whole set of parameters (bringing advantages such
as less wiring, installation, and engineering). Figure 2-3 depicts the concept at
a high level, and each of these benefits is covered in chapter 8.
HSE Benefits
In addition to the same life-cycle benefits as H1, HSE provides the control
backbone that integrates all of the systems in the plant. The typical subsys-
tems in the plant that are functionally based on the device data, such as pro-
cess controllers, PLCs, and batch controllers, are integrated in the same HSE
backbone. Some common examples are HMI stations, engineering stations,
and historians. FOUNDATION Fieldbus enables asset management functions,
such as diagnostics, calibration, identification, and other maintenance man-
agement operations, to “mine” massive amounts of information from field
devices in real time. Asset management enables proactive maintenance that
allocates resources to where they are really needed. Plants employing field-
bus-based field devices often have asset management software installed in
Figure 2-3. Wiring Savings
special computers connected over HSE. This improves the performance in

terms of the bandwidth, latency, throughput, and reliability.
Subsystem Interoperability
Plants are comprised of a number of subsystems. With HSE, subsystems for
burner management, gas chromatographs, paper web scanners, shutdown
systems, compressor controls, tank farms, etc., integrate easily because of the
open protocol. Users can mix and match subsystems for basic control, emer-
gency shutdown, paper quality control, advanced control, compressor con-
trol, etc., from different suppliers. HSE eliminates the need for custom
programming to access information. Users can select decimal subsystems to
keep cost low, while reducing the configuration effort. Data integrity, diag-
nostics, and redundancy management are part of HSE and work seamlessly
between devices from different manufacturers.
Function Blocks
The FOUNDATION Fieldbus function blocks used in H1 devices are used in
HSE devices. The same control strategy programming language can be used
throughout the entire system. The status associated with function block
parameters is generated by field instruments based on failed sensors, stuck
valves, etc., and is used for loop shutdowns, windup protection, and bump-
less transfer.
Control Backbone
HSE provides peer-to-peer communication capability. Devices communicate
with each other directly without having to go through a central computer.
This enables powerful, advanced control strategies involving variables
throughout the plant without the risk of a central computer failure, further
reducing the risk of single-point failures and the associated loss of informa-
tion, view, and control and shutdown in a plant. HSE can also bridge informa-
tion between devices on different H1 networks at different ends of the plant.
Thus, control can span between process cells and a plant area. HSE replaces
enterprise, control, and remote-I/O networking levels, thus flattening the
enterprise pyramid. The linking device (LD) brings data from one or more H1
fieldbus networks directly onto the HSE backbone.
Standard Ethernet Network Equipment

HSE devices use standard cable; no special tools or skills are required. Instal-
lation is simple and fast. HSE uses standard Ethernet network equipment
such as switches. Standard commercial off-the-shelf (COTS) Ethernet compo-
nents are made in extremely high volume. Cable, interface cards, and other
networking hardware are very low cost compared to proprietary networks.
Ethernet options for media include twisted pair, CAT5e fiber optics, and wire-
less. Networking hardware is available in both commercial and industrial
grades from many suppliers.
2.2 Communications in FOUNDATION Fieldbus

The significant differentiation in devices with FOUNDATION Fieldbus is the
ability to communicate with multiple devices on the same bus compared to
legacy device communication technologies. The concept of communications is
critical for understanding the protocol. FOUNDATION Fieldbus employs a sub-
set of the International Standards Organization’s (ISO’s) open systems inter-
connection (OSI) communications model. It uses layers 1 (Physical), 2 (Data
Link), and 7 (Application). It adds an additional layer called the “User Layer.”
This User Layer doesn’t really fit the typical model of communications,
because it is not message oriented. Instead, it models the process control data
structures needed to ensure interoperability of devices. It provides a “virtual
fieldbus device” (VFD), which presents the device’s functionality to the net-
work in a well-defined and understood manner, independent of how the data

is actually stored within the device.
The Physical Layer defines the electrical signal and its tolerances. It defines
“one” and “zero,” preamble characters, and frame check sequences.
The Data Link Layer defines the media access protocol—defining when a
device has the right to transmit on the multidrop network. It also defines the
sequences of messages to ensure reliable device-to-device transmission.
The Application Layer defines the data types (e.g., floating-point, 8-, 16-, and
32-bit integers, visible strings, octet strings, time, and date).
The User Layer, however, is the most important to the user. It defines process
control–specific structures, such as function blocks and their parameters,
modes of function blocks, statuses of variables, cascade initialization sequenc-
ing, anti-windup information, and event and alarm reporting methods. These
are all essential to enable a sensor from brand X to work with a controller of
brand Z.
However, any such detailed standard that ensures interoperability is likely to

impede innovation, because manufacturers will not be permitted to provide
features beyond the standard without violating the standard. Fieldbus
addresses this concern by providing a “meta-language” by which a device
may describe itself to the network for human interaction purposes. Such
Device Description Language or variable description syntax is a standardized
mechanism to provide nonstandard features. For example, although the PID
algorithm parameters are standardized by Fieldbus Foundation, vendors may
provide various self-tuning algorithms and their parameters. The PID param-
eters must be standard, but the self-tuning algorithms and their parameters
may differ. This meta-language describes to any other devices on the network
that there are nonstandard parameters, what they are named, what their data
types are, the ranges of the data, and even help information. A device descrip-
tion language is primarily intended to provide configuration, display and
entry information for a remote fieldbus node. It is not required for periodic or
aperiodic data transfers between peer devices.
FOUNDATION Fieldbus communication stack falls in line with the standards of

OSI layers and it consists of:
• The Physical Layer
• The Communication “Stack”
• The User Application Layer
This translates to the OSI layered communication model used to model these
components.
• The Physical Layer is OSI layer 1.
• The Data Link Layer (DLL) is OSI layer 2.
The Fieldbus Message Specification (FMS) and fieldbus access sublayer are
combined at OSI layer 7. Refer to figure 2-4 for the mapping of the layers in
the fieldbus with the OSI layers.
Figure 2-4. The Open System Interconnect Layered Communications Model

Physical Layer (31.25 Kbps)

The Physical Layer in FOUNDATION Fieldbus is an approved standard from
the International Electrotechnical Commission (IEC) and ISA. The Physical
Layer receives messages from the communication stack and converts the mes-
sages into physical signals on the fieldbus transmission medium and vice
versa. Conversion tasks include adding and removing preambles and start
and end delimiters. Refer to figure 2-5 for the image of voltage signaling of
the FF.
Figure 2-5. F OUNDATION Fieldbus Physical Layer (31.25 Kbps)
Fieldbus signals are encoded using the well-known Manchester biphase-L

technique. The signal is called synchronous serial, because the clock informa-
tion is embedded in the serial data stream. The receiver of the fieldbus signal
interprets a positive transition in the middle of a bit time as a logical “0” and a
negative transition as a logical “1.” Refer to figure 2-6 for the signal sequence
in FOUNDATION Fieldbus.
31.25-Kbps Fieldbus Signaling

Fieldbus DC supply voltage can range from 9 to 32 volts. However, for intrin-
sically safe (IS) applications, the allowed power supply voltage depends on
the barrier rating. Devices that are 31.25 Kbps can be powered directly from
Figure 2-6. Bit Sequences
the fieldbus and can operate on wiring previously used for 4–20 mA devices.
The 31.25-Kbps fieldbus also supports IS fieldbuses with bus-powered
devices.
31.25-Kbps Fieldbus Wiring

The 31.25-Kbps fieldbus allows stubs or “spurs.” The length of the fieldbus is
determined by the communication rate, cable type, wire size, bus power
option, and IS option. Figure 2-7 helps explain the naming conventions used
for wires in different parts of the bus.
Data Link Layer

The communication stack is comprised of layers 2 and 7 in the OSI model. The
fieldbus does not use OSI layers 3, 4, 5, and 6. The Fieldbus Access Sublayer
(FAS) maps the FMS onto the DLL.
The user application is not defined by the OSI model. The FOUNDATION Field-
bus has specified a user application model, significantly differentiating it from
other models. Each layer in the communication system is responsible for a
portion of the message that is transmitted on the fieldbus. Figure 2-8 refer-
ences the approximate number of eight-bit “octets” used for each layer to
transfer the user data.
Figure 2-7. Fieldbus Wiring
Figure 2-8. Fieldbus Message Format in Different Layers

FOUNDATION Fieldbus Device Types

The FOUNDATION Fieldbus technology defines two types of devices. They are:
• Basic Device
• Link Master Device
Before we can understand the difference between these types of devices, we

need to understand the concept called link active scheduler (LAS). Figure 2-9
depicts the concept of LAS, backup LAS, and the basic device in the context of
an H1 bus.
Figure 2-9. Backup LAS Devices
LAS operates at the Data Link Layer. It provides the following functions:
• It identifies and adds devices to the link.
• It eliminates the nonresponsive devices from link.
• It distributes data link and link schedule timings; the Data Link Layer
synchronizes the network-wide data link time. Link scheduling time is
a link-specific time represented as an offset from data link time. It is
used to indicate when the LAS on each link begins and repeats its
schedule. System management uses it to synchronize function block
execution with the data transfers scheduled by the LAS.
• It provides device polling at scheduled intervals for data.

Any device on the link capable of becoming the LAS is called a link master
device. All other devices are referred to as basic devices.
The important criterion is that there should be backup LAS support along
with the primary LAS. Ideal design is to have a link master, which can sup-
port both primary and backup link schedules. Normally the H1 link would be
a primary link master, and the link master capable device acts as backup link
master. In case of primary link connection failure, the backup link takes over
the communication and handles the schedule so that the communication
continues.
Upon startup or failure of the existing LAS, the link master capable devices on
the link bid to become the LAS. The link master that wins the bid begins oper-
ating as the LAS immediately upon completion of the bidding process. The
link master capable device with the lowest address usually wins the bid. Link
masters that do not become the LAS act as basic devices when viewed by the
LAS. They also act as LAS backups by monitoring the link for failure of the
LAS, and by bidding to become the LAS when a LAS failure is detected.
Only one device can communicate at a time. Permission to communicate on

the bus is controlled by a centralized token passed between devices by the
LAS. Only the device with the token can communicate. The LAS maintains a
list of all devices that need access to the bus. This list is called the “live list.”
The LAS uses two types of tokens. A time-critical token, compel data (CD), is
sent by the LAS according to a schedule. A non-time-critical token, pass token
(PT), is sent by the LAS to each device in ascending numerical order according
to address. The devices participate in the network and are controlled by a link
master device. Basic devices do not have the capability to become the LAS.
Device Addressing
Fieldbus uses addresses between zero and 255. Addresses zero through 15 are
reserved for group addressing and for use by the Data Link Layer. Each ven-
dor provides a range of device addresses to be available for the devices. If
there are two or more devices with the same address, the first device to start
will use its programmed address. Each of the other devices is given one of
four temporary addresses between 248 and 251. If a temporary address is not
available, the device will be unavailable until a temporary address becomes
available.
Table 2-1. FOUNDATION Fieldbus Node Addressing

0x10 – V(FUN) Address for link master class devices
0x F7 – (FUN)+V(NUN) Address for basic class devices
0xF8 – 0xFC Default address for devices with cleared address
Address for temporary devices such as handheld
0xFD – 0xFF
communicators
A temporary device, such as a hand-held communicator or a bus participating

monitors for troubleshooting, etc., has a node address in the temporary range.
If there is a conflict in the address of the two devices, the one that joined sec-
ond will be changed to the temporary address range. The system will allow it
to be changed to the permanent address range using configuration tools or a
hand-held communicator.
New devices that do not have an assigned permanent address in the available
node address range 20-247 also first appear in another reserved range of
addresses in nodes 248-251 inclusive. The result of having only four tempo-
rary addresses is that if more than four devices without permanent addresses
attempt to connect to the network at one time only the first four devices
detected will appear on the live list. The remaining non-reserved or accessible
node addresses 16-19 are reserved for the Permanent Host/DCS.
Scheduled Communication
The link active scheduler (LAS) has a list of transmit times for all data buffers
in all devices that need to be cyclically transmitted. When it is time for a
device to send a buffer, the LAS issues a compel data (CD) message to the
device. Upon receipt of the CD, the device broadcasts or “publishes” the data
in the buffer to all subscriber devices on the fieldbus. The device configured to
receive the data is called a “subscriber.” Scheduled data transfers are typically
used for the regular, cyclic transfer of control loop data between devices on
the fieldbus. Figure 2-10 provides a view of scheduled communication. Not all
devices on the network subscribe to all messages, but only those that are con-
figured as part of the control loop and the LAS (Host System).
Unscheduled Communication
All the devices on the fieldbus can send “unscheduled” messages between
transmissions of scheduled messages. The LAS grants permission to a device
to use the fieldbus by issuing a pass token (PT) message to the device. When
Figure 2-10. Scheduled Communications
the device receives the PT, it is allowed to send messages until it has finished
or until the “delegated token hold time” has expired, whichever is the shorter
time. Figure 2-11 depicts the concept of unscheduled communication.
Unscheduled communication is a client/server communication with a one-to-
one relationship for each message. The paths provided in the figure are possi-
ble ways for communications.
Figure 2-11. Unscheduled Communications
Function Block Scheduling

Figure 2-12 shows an example of a link schedule. A single iteration of the link-
wide schedule is called the macrocycle. When the system is configured and
the function blocks are connected or linked, a master link-wide schedule is
created for the LAS. Each device maintains its portion of the link-wide sched-
ule, known as the Function Block Schedule. The Function Block Schedule indi-
cates when the function blocks for the device are to be executed. The
scheduled execution time for each function block is represented as an offset
from the beginning of the macrocycle start time.
Figure 2-12. Example Link Schedule Showing Scheduled and Unscheduled Com-
munication
To support synchronization of schedules, periodically, link scheduling (LS)

time is distributed. The beginning of the macrocycle represents a common
starting time for all function block schedules on a link and for the LAS link-
wide schedule. This permits function block executions and their correspond-
ing data transfers to be synchronized.
2.3 Fieldbus Access Sublayer (FAS)

The FAS uses the scheduled and unscheduled communication features of the
Data Link Layer to provide communication services for the Fieldbus Message
Specification. Virtual Communication Relationships (VCR) describe the types
of FAS services. The VCR is like the speed dial feature on a memory tele-
phone. There are many digits to dial for an international call, such as the inter-
national access code, country code, city code, exchange code, and the specific
telephone number. This information only needs to be entered once and then a
“speed dial number” is assigned. After setup, only the speed dial number
needs to be entered to dial. Likewise, after configuration, only the VCR num-
ber is needed to communicate with another fieldbus device.
Just as there are different types of telephone calls, such as person-to-person,

collect, or conference calls, there are different types of VCRs.
• Client/Server
• Report Distribution
• Publisher/Subscriber
Client/Server VCR Type

The client/server VCR Type is used for queued, unscheduled, user initiated,
one-to-one, and communication between devices on the fieldbus. “Queued”
means that messages are sent and received in the order submitted for trans-
mission, according to their priority, without overwriting previous messages.
When a device receives a PT from the LAS, it may send a request message to
another device on the fieldbus. The requester is called the “client” and the
device that received the request is called the “server.” The server sends the
response when it receives a PT from the LAS. The client/server VCR Type is
used for operator-initiated requests such as set-point changes, tuning parame-
ter access and change, alarm acknowledgment, and device upload and
download.
Report Distribution VCR Type

The report distribution VCR Type is used for queued, unscheduled, user-initi-
ated, and one-to-many communications. When a device with an event or a
trend report receives a PT from the LAS, it sends its message to a “group
address” defined for its VCR. Devices that are configured to listen for that
VCR receive the report. The report distribution VCR Type is typically used by
fieldbus devices to send alarm notifications to the operator consoles. In most
cases all the devices on the network are configured to receive all reports, so
they are aware of the status of all devices to which they are connected.
Publisher/Subscriber VCR Type

The publisher/subscriber VCR Type is used for buffered, one-to-many com-
munications. “Buffered” means that only the latest version of the data is main-
tained within the network. New data completely overwrites previous data.
When a device receives the CD, the device will “publish” or broadcast its mes-
sage to all its subscriber devices on the fieldbus. Devices that wish to receive
the published message are called “subscribers.” The CD may be scheduled in
the LAS, or may be sent by subscribers on an unscheduled basis. An attribute
of the VCR indicates which method is used. The field devices use publisher/
subscriber VCR Type for cyclic, scheduled publishing of user application
function block input and outputs such as process variable (PV) and primary
output (OUT) on the fieldbus. Figure 2-13 provides a tabular view of the VCR
types.
Figure 2-13. Different Types of VCRs in F OUNDATION Fieldbus
2.4 User Application

FOUNDATION Fieldbus defines a standard User Application Layer based on
“blocks,” also called function blocks. This is often referred to as Function Block
Application Program (FBAP), whose structure is illustrated in figure 2-14. The
part of the FBAP that is standardized in fieldbus is called the function block
shell. For example, the block algorithms are not standardized. For each block
there is a set of parameters that, to a certain extent, define the minimum func-
tionality of a block. However, a manufacturer may implement such a block in
its own way. For example, in the PID control block there must be a GAIN
parameter, and the manufacturer may use this parameter as GAIN or
PROPORTIONAL BAND.
Figure 2-14. Structure of Application Layer
Function Block
The function block models the user-configurable part of the entire application.
Typically, these functionalities were previously available in individual physi-
cal devices, but software blocks now include many of these functionalities in a
single device. The different types of function blocks in a fieldbus system pro-
vide all the functionality necessary for most control systems. The function
blocks are linked together to build control strategies suitable for an applica-
tion. In general, function blocks use an algorithm and contained parameters to
process input parameters, and produce output parameters as results.
Again, the block is just an abstraction of software and data. There are no
blocks inside the device to be seen. The function block concept was designed
around the PID block, since it is the most complex block. The concept of local/
remote set point, automatic/manual output, cascade (remote set point) and the
algorithm has been carried on to other blocks.
A particular selection of set point and output is called the block mode. The
algorithm does not refer to the PID algorithm in the PID block alone, but in
general to the processing function of all blocks.
Each block is identified in the system by a tag assigned by the user. This tag
must be unique in the fieldbus system. Each parameter in a block has a name
that cannot be changed. All parameters in the system are uniquely defined by
the block tag plus parameter name. Blocks are representations of different
types of application functions.
A user application, for example, uses the following types of blocks, as shown
in figure 2-15:
• Resource block
• Transducer block
• Function block
Devices are configured using resource blocks and transducer blocks. The con-
trol strategy is built using function blocks.
Resource Block
A device can have only one resource block. The resource block describes char-
acteristics of the fieldbus device, such as the device name, type, revision, man-
ufacturer, and serial number.
Transducer Block
Transducer blocks read from physical sensors into function blocks. Trans-
ducer blocks decouple the function blocks from the hardware details of a
given device, allowing generic indication of function block input and output.
They contain information such as calibration date and sensor type. There is
usually one transducer block for each type of input or output function block.
The transducer block uses channels to link the raw data for each measurement
to each of the associated I/O blocks. The transducer block knows the details of
I/O devices and how to actually read the sensor or change the actuator. The
transducer block performs the digitizing, filtering, and scaling conversions
needed to provide the sensor value to the function blocks and/or make the
change in the output as dictated by the function block.
Figure 2-15. Function Blocks in F OUNDATION Fieldbus
Application Function Block

Function blocks (FB) provide the control system behavior. Each performs a
specific task, such as measurement or control with input and outputs con-
nected to other entities in a standard way. The input and output parameters of
function blocks can be linked over the fieldbus. The execution of each function
block is precisely scheduled. There can be many function blocks in a single
user application. The FOUNDATION Fieldbus defines multiple sets of standard
function blocks.
Fieldbus defines the following 10 standard function blocks for basic control.
Refer to the standard (list of standards is provided in appendix) for an
updated list of function blocks.
• Analog Input – AI
• Analog Output – AO
• Bias/Gain – BG
• Control Selector – CS
• Discrete Input – DI
• Discrete Output – DO
• Manual Loader – ML
• Proportional Derivative – PD
• Proportional Integral Derivative – PID
• Ratio – RA
Additional blocks, which are not common among all the devices, but among
specific devices are:
• Device Control – DC
• Output Splitter – OS
• Signal Characterize – SC
• Lead Lag – LL
• Dead Time – DT
• Integrator – (Totalizer) IT
• Set-Point Ramp Generator – SPG
• Input Selector – IS
• Arithmetic – AR
• Timer – TMR
• Analog Alarm – AAL
• Multiple Analog Input – MAI

• Multiple Analog Output – MAO
• Multiple Discrete Input – MDI
• Multiple Discrete Output – MDO
For example, a simple temperature transmitter may contain an AI function

block. A control valve might contain a PID function block as well as the
expected AO block. Thus, a complete control loop can be built using only a
simple transmitter and a control valve. Figure 2-16 represents the concept.
Figure 2-16. Control Loop Using Function Blocks
2.5 Objects in Fieldbus

A fieldbus device may have user applications that are independent from each
other and do not interact. A fieldbus device consists of virtual field devices
(VFD) for such individual applications.
A FOUNDATION Fieldbus device has at least two VFDs. One is the manage-
ment VFD where network and system management applications reside. It is
used to configure network parameters including VCRs, as well as to manage
devices in the fieldbus system. The other is a function block VFD, where func-
tion blocks exist. Most field devices have more than two function block VFDs.
A measurement or control application consists of function blocks connected to

each other. Function blocks are connected through link objects in the function
block VFD. A link object connects two function blocks within a device or a
function block to a VCR for publisher or subscriber.
The following objects are defined in the user application:
• Block/Link objects
• Trend objects
• Alert objects
• View objects
• Multivariable container objects
Link Objects
Control strategies can be built by linking function block outputs to the inputs
of other function blocks. When such a link is made, the input “pulls” the value
from the output, thereby obtaining its value. Links can be made between func-
tion blocks in the same device or in different devices (see figure 2-17). An out-
put may be connected to many inputs. These links are purely software, and
there is basically no limitation to how many links can travel along a physical
wire. Links cannot be made with contained variables. Analog values are
passed as a floating point in an engineering unit, but are scaled to a percent-
age (e.g., in the PID control block) to enable dimensionless tuning parameters.
Digital values are passed as Boolean, zero, or 255. The analog scaling informa-
tion may also be used in operator interfaces to provide bar-graph readout.
An output value is always accompanied by a status informing if it is suitable

for control (e.g., a value received from a sensor or forward path) or is suitable
as the feedback (backward path) informing if the status is determined by the
source (e.g., the output does not move the final control element). Note that the
pull system is used for backward paths, also enabling the receiving function
block to take appropriate action.
Figure 2-17. Function Block Linking Objects
Links are uniquely defined by the name of the output parameter and the tag
of the function block that they come from. It is therefore very easy for a user to
identify links. System management resolves the block tag + parameter name
construct into the short reference address + index to make communication
faster. Links may also be preconfigured directly using address and index. The
link management, such as link active schedules, automatically establishes the
connections upon power on.
Trend Objects
Trend objects allow local trending of function block parameters for access by
hosts or other devices at a scan rate faster than the bus communication cycle.
The device can perform trending using the trend object. This eliminates peri-
odic time-critical communication. Data are collected from 20 samples and are
accessed in a single communication. This reduces communication and net-
work overhead, leaving more time for time-critical transfers.
Alert Objects
Alert objects enable reporting of alarms and events. Many function blocks
have a built-in alarm function to detect high and low process variable and
deviation alarms. When alarms and other critical events occur, an alert object
automatically notifies the user. This eliminates the need for the operator inter-
face to perform periodic polling to determine if there is an alarm condition.
The physical and transducer blocks detect failures in hardware and overall
operation status. The alert object relieves these blocks of the alert handling so
that their execution remains unaffected.
The alert object also provides an acknowledgment mechanism to ensure that

the operator has been informed. If a reply is not received within a specified
time, the alert notification is repeated. The operator is also informed when an
alarm condition disappears.
Examples of events are:
• Mode is being forced for some reason
• Block tag has been changed
• Locked output/fail-safe conditions
• Feedback does not match desired output
The trip level, priority level, and deadband can be configured for the alarms.
The alert notification to the console includes: time stamp, reason, priority,
present status (the alarm may already have disappeared), and the trip value.
If a change is made to the configuration, an alert notification containing prior-

ity, configuration revision level, changed parameter, and time stamp is issued.
All alerts also inform which device and block is the source of the alarm and
provide an alert key for sorting by plant division and a type code identifying
enumerated messages to the operator. The messages may be among standard
messages or others specified by the manufacturer. There is also an alarm sum-
mary of up to 16 alerts for each block summarizing present status: if the alarm
has already been acknowledged, if it was not successfully reported to the
operator, or if it is disabled.
Multivariable Container Objects

Multivariable container (MVC) objects serve to “encapsulate” multiple func-
tion block parameters to optimize communications for publisher/subscriber
and report distribution transactions. It has a user-configured list to define the
required parameters, whose data values are referenced in a variables list.
View Objects
View objects are predefined groupings of block parameter sets that can be dis-
played by the human-machine interface. The function block specification
defines four views for each type of block. Figure 2-18 shows an example of
how common function block variables map into the views. Only a partial list-
ing of the block parameters is shown in the example.
• VIEW_1 — Operation Dynamic — Information required by a plant

operator to run the process (e.g., process variable)
• VIEW_2 — Operation Static — Information that may need to be read

once and then displayed along with the dynamic data (e.g., permitted
mode)
• VIEW_3 — All Dynamic — Information that is changing and may need

to be referenced in a detailed display (e.g., all inputs and outputs)
• VIEW_4 — Other Static — Configuration and maintenance information

(e.g., all alarm configurations)
Access Rights FOUNDATION Fieldbus

The operator at the console can grant or deny access to four sets of parameters
in a block to a local interface or to a higher-level device, such as a batch pro-
gram. Adjustments carried out from the console, locally, or by a batch pro-
gram appear the same to the function block.
The four groups for a higher level device are:
• Program — mode, set point, and output
• Tune — tuning parameters
• Alarm — alarm parameters for a hand-held terminal or local interface
• Local — mode, set point, and output

Figure 2-18. View Objects in F OUNDATION Fieldbus Technology
2.6 Interoperability Test Kit
Device Interoperability
Support for interoperability is one of the founding principles of FOUNDATION
Fieldbus. The Interoperability Test System (ITS) tests the black box behavior
of a device using only its interface to the network. Prerequisites to interopera-
bility testing are that the device under test must use a compliant communica-
tions stack and the physical layer of the device must have been tested for
specification conformance. The scope of testing depends upon the level of
conformity implemented by the device manufacturer. All function blocks in a
device that are implemented according to standardized block profiles are
tested to verify correct implementation. The ITS tests all Device Description
support files and high-level stacks.
The Fieldbus Foundation has released the latest version of the H1 Interopera-
bility Test Kit (ITK) 6.1.0, and manufacturers typically have approximately 18
months to incorporate resulting changes in their products. The ITK is nor-
mally issued with maintenance changes on an annual basis in the fall. This
tool tests the functionality of an H1 (31.25 kbps) fieldbus device and its confor-
mity with the FOUNDATION Fieldbus’ function block and transducer block
specifications. This includes new features to enhance device intelligence,

improve consistency in instrument configuration, and simplify replacement of
field devices from different automation suppliers. H1 ITK consists of a test
engine, communication stack, and function block interface card. It includes all
hardware and software required to ensure complete device interoperability.
H1 ITK 6.1.0 builds on the extensive library of FOUNDATION Fieldbus block

test cases, offering a series of standardized function blocks and transducer
blocks that enable increased test coverage for device developers. This includes
test cases for new blocks that were previously unavailable, such as flow total-
izer, analog alarm, control selector, and output splitter, which support
expanded device applications for control in the field (CIF). A new flow trans-
ducer block is intended to simplify device integration within FOUNDATION
Fieldbus networks. In addition, the release provides updated test cases for
existing blocks, including flow, pressure, temperature, analog positioner, and
discrete positioner.
The new H1 ITK test cases focus on backward compatibility among FOUNDA-
TION Fieldbus devices. This enhancement supports device replacement auto-
mation and enables the test kit to verify consistent behavior between device
and host implementations in fieldbus-based control systems. Automation of
device replacement enables the configuration in an existing field device to be
configured in a newer version of that instrument without manual interven-
tion. This plug-and-play solution ensures features are consistent between dif-
ferent generations of devices without reengineering the host configuration or
changing any other element of the H1 network other than the new instrument.
The use of common transducer blocks also improves interoperability and sim-
plifies device replacement by enabling a minimum level of configuration
across all types of instruments. This results in greater predictability in fieldbus
implementation, while reducing integration risks.
Table 2-2. Features and Functionalities for ITK

Function Transducer
Mandatory Features Optional Features
Blocks Blocks
• Resource Block • Analog Input • Pressure • Common Software
• Alarms and Events • Analog Output • Temperature Download
• Function Block • Discrete Input • Flow • Block Instantiation
• Linking • Discrete Output • Compatible Device
• Trending • PID Replacement
• Capability File • Arithmetic
• Device Description • Input Selector
• Multi-Bit Alert Reporting • Integrator
• Field Diagnostics • Multiple AI
• Device Description V5 • Multiple AO
• Enhanced Downloading • Multiple DI
Features • Multiple DO
• Signal Characterizer
• Totalizer
• Analog alarm
• Output Splitter
• Control Selector
The various ITK functionalities are added at different releases of the toolkit,
and the diagram shown in figure 2-19 represents this as well.
Figure 2-19. Functionalities in Different ITK Versions

Host Interoperability Test in FOUNDATION Fieldbus

Host Interoperability Support Test (HIST) provides generic test procedures
that would be performed or witnessed by qualified Fieldbus Foundation staff
on FOUNDATION Fieldbus (FF) to prove that the host has the adequate test pro-
cedure for each claimed feature. Each host is defined by the manufacturer to
provide specific functions within a fieldbus network. A host could be a config-
uration tool, a recording device, an alarm display panel, a human-machine
interface, or a combination of functionality.
FOUNDATION Fieldbus FF-569 defined a set of generic FF host features that

may be implemented within the host to implement a set of applicable test pro-
cedures. A host must conform to some, or perhaps all features, as defined by
the host feature checklist. However, because hosts can have various defini-
tions, not all features may be applicable to a host implementation. Therefore,
it is not expected that every host must support each feature.
Each feature contains a set of test procedures that are to be run against the
host or the fieldbus system using the host. The host must pass the test proce-
dures defined by the feature for a host to claim conformance to the feature.
The features themselves are generic; therefore, manufacturers develop test
cases, or actual implementation steps necessary to meet the requirements of
the test procedure. Many test procedures require features supported by both
the device(s) and the host.
The purpose of the HIST is to reveal and confirm features that are supported
by the host product being qualified against a particular HIST profile. Features
that are mandatory in the HIST profile (FF-569) are essential (within that pro-
file) to interoperability or successful adoption of the technology. A host candi-
date cannot achieve compliance with an HIST profile without meeting all
mandatory features.
Features that are optional in the HIST Profile Table in table 2-1 are not
required but are of interest to the users. Those hosts that implement and
achieve an optional feature are credited for it in the HIST profile conformance
report.
It is important to note that a test procedure failure may be a result of one or

many circumstances, which can include:
• Invalid device implementation

• Invalid host implementation or configuration
• Interdevice configuration problems
• Device profile incompatibilities
• Other unknown reasons
Host Interoperability Support Test Profiles

A host application consists of one or more hardware and software compo-
nents specified by the host manufacturer. For example, a Class 61 integrated
host may consist of a controller, engineering station, operation station, and
asset management station. Individually, these components may not conform
to a profile class, but collectively these components function as a single host
profile class. The host manufacturer must specify all components that collec-
tively meet the profile class. It is possible for a host to meet multiple profiles.
For example, a host may meet both Class 63 and Class 64. In this case, some
features in Class 63 are specified as mandatory and specified as prohibited in
Class 64. The manufacturer must document how those host features are
enabled in Class 63 while disabled in Class 64 (e.g., menu configuration). The
details of the profiles are provided in table 2-3.
Table 2-3. Host Interoperability Test Profiles

Group 6 Host Profile Classes Name Description
Primary, on process host that
manages the communication and
Class 61 Integrated Host
application configuration of all
devices on a network.
Temporary, on process host with
Class 62 Visitor Host limited access to device parame-
terization.
Group 6 Hosts
Primary, off process host for con-
Class 63 Bench Host figuration and setup of a non-
commissioned device.
Primary, off process host with
limited access to device parame-
Class 64 Bench Host
terization of an off-line, commis-
sioned device.
Class 61 - Integrated Host

The Class 61 integrated host is the primary on-process host. Its characteristics
are:
• Fixes H1 address, on process
• Sets and manages physical device TAGs (device name) for all devices
• Sets and manages the network configuration (device address, link

parameters, application time)
• Manages the distributed application configuration (link schedule, back-

link schedule, block instantiation, link objects, macrocycle, VCRs,
alerts)
• Full access to all resource block, transducer block, and function block
parameters.
• May maintain a backup/off-line database
• Confirms, manages, and handles device and process alerts
The profile is primarily used by the process control engineer (for configura-
tion and analysis), operator (for plant operation), plant management (for plant
management information), and maintenance personnel (for maintenance of
instrumentation, control system equipment, and process equipment). The typ-
ical use case for such a profile is a process operational host that configures and
operates instrumentation devices enabled with FOUNDATION Fieldbus.
Class 62 - Visitor Host

A visitor host is a secondary on-process host typically used for device mainte-
nance. The characteristics of a visitor host are:
• Visitor H1 address, basic mode, on process
• Does not manage the physical device TAG, network configuration, or

distributed application configuration
• May have read and write access to resource block and transducer
blocks
• May provide read-only access to function blocks
The primary users of the profile are instrumentation and maintenance person-
nel. The most commonly applied use case is a technician with hand-held
equipment or a portable PC/PDA that connects to the network for device

maintenance (temporary connection to bus), or a field support engineer who
connects to the bus with a specialized device application (e.g., online valve
diagnostics package).
Class 63/64 - Bench Host

The Class 63/64 bench host is the primary host on an off-process bench link for
maintenance and setup. There are two identified use cases for bench hosts,
which result in different profile classes. A host may conform to both profile
classes, but must document how each profile is managed (e.g., software set-
ting, user prompt).
A Class 63 bench host is the primary host for accessing and configuring non-
commissioned devices. The typical characteristics are:
• Fixed or visitor H1 address, off process
• May set the network configuration (device address, link parameters,

application time) for off-process testing
• May set a distributed application configuration (link schedule, back-

link schedule, block instantiation, link objects, macrocycle, VCRs,
alerts)
• May access all resource block, transducer block, and function block
parameters
Primary users are instrumentation and maintenance personnel. The usually

applied use cases are:
1. Testing of skid operation, the entire network at once: To test the skid
as an entity, the FF devices have to be commissioned at the start and
then decommissioned at the conclusion.
2. Setting up a new device for service or maintenance of a previously

configured and operating device removed from the process network:
The device may remain configured, in which case certain
configuration information must not be altered. Alternatively, the
device may be decommissioned, and then recommissioned upon
return to the on-process H1 link.
3. Setting up a new device for device replacement service: New device is

not yet commissioned.
4. Clearing used devices for potential reassignment: This is to render the

device “safe” by such actions as clearing PD_Tag, H1 address, VCR’s
LAS and function block schedules, link objects, and setting to basic
device type.
A Class 64 bench host is a primary host for access to a previously commis-

sioned device. A Class 64 bench host has nearly identical requirements to a
Class 62 visitor host with the exception of device address configuration. The
typical characteristics are:
• Fixed or visitor H1 Address, off process
• Does not configure physical device TAG, network configuration, or

distributed application configuration
• May have access to and write to resource block and transducer blocks
• May provide read-only access to function block parameters
The primary users are instrumentation and maintenance personnel. The most
commonly applied use case is a technician with hand-held equipment or a
portable PC/PDA that connects to the network for device maintenance (tem-
porary connection to bus), or a field support engineer who connects to the bus
with a specialized device application (e.g., online valve diagnostics package).
3
Function Blocks in
FOUNDATION Fieldbus
Function blocks, also known as application function blocks, are discussed in

section 2.4 from a technology perspective. In the current section, application
function blocks will be discussed from an application perspective. Application
function blocks are the foundation blocks used to build the application or con-
trol logic. In this section, some of the most commonly used application blocks,
their functionality, and some of the critical parameters and their descriptions
are discussed in detail. Note that not all the available function blocks are dis-
cussed in detail. Readers are suggested to refer to the specifications for more
information.
3.1 Analog Input (AI) Function Block

The analog input (AI) function block (figure 3-1) processes field device mea-
surements and makes them available to other function blocks. The output
value from the AI block is in engineering units and contains a status indicat-
ing the measurement quality such as good, bad, and uncertain. The measuring
device may have several measurements or derived values available in differ-
ent channels. It uses the channel number for defining the variables that the AI
block processes.
The AI block supports alarming, signal scaling, signal filtering, signal status
calculation, mode control, and simulation. In automatic mode, the block’s out-
put parameter (OUT) reflects the process variable (PV) value and status. In
manual mode, OUT may be set manually. The manual mode is reflected on
51
Figure 3-1. Analog Input (AI) Function Block
the output status. A discrete output (OUT_D) is provided to indicate whether

a selected alarm condition is active. Alarm detection is based on the OUT
value and user specified alarm limits. Figure 3-2 illustrates the internal com-
ponents of the AI function block, and table 3-1 lists the AI block parameters,
their units of measure, and their descriptions.
Simulation
To support testing, it is necessary to either change the mode of the block to
manual and adjust the output value or enable simulation through the configu-
ration tool and manually enter a value for the measurement value and its sta-
tus. In both cases, it is necessary to first set the software-based ENABLE
jumper on the field device for some devices or by some other mechanism as
defined by the transmitter manual. Note that most fieldbus instruments have
a simulation jumper. As a safety measure, the jumper has to be reset every
time there is a power interruption. This measure is to prevent devices that
went through simulation in the staging process from being installed with sim-
ulation enabled. With simulation enabled, the actual measurement value has
no impact on the OUT value or the status.
Chapter 3 – Function Blocks in FOUNDATION Fieldbus 53
Figure 3-2. Analog Input Function Block Schematic
Table 3-1. Definitions of Analog Input Function Block System

Parameters
Parameter Units Description
Used to set auto-acknowledgement for alarms. This
ACK_OPTION None parameter is also used to set the acknowledgement
options for the alarms.
The amount the alarm value must return within the
ALARM_HYS % alarm limit before the associated active alarm condition
clears.
Used to select the process alarm conditions that will
cause the OUT_D parameter to be set. It is a selectable
ALARM_SEL None
option for the users to have their condition of choice to
trigger the output.
The setting for the alarm limit used to detect the HI HI
alarm condition. If the control strategy is expecting to
HI_HI_LIM EU@PV_SCALE return an alarm for 90% of the level in a level transmit-
ter and if a percent is their engineering unit, then 90
needs to be entered as HI_HI_LIM.

Parameters
The priority of HI HI alarm. There are various levels of
priority that can be set to differentiate an alarm from the
HI_HI_PRI None others based on the priority as defined in the design.
The parameter can be seen as a basic block to build
the organizational alarm behaviors.
The setting for the alarm limit used to detect the HI
alarm condition. The value entered is similar to the HI
HI_LIM EU@PV_SCALE
HI LIM, but is seen as a first-level alarm before the con-
ditions worsen.
The priority of HI alarm and intent and behaviors is sim-
ilar to HI HI PRI. (There are various levels of priority
that can be set to differentiate an alarm from the others
HI_PRI None
based on the priority as defined in the design. The
parameter can be seen as a basic block to build the
organizational alarm behaviors.)
Allows the selection of input and output options used to
alter the PV. “Low cut off enabled” is the only selectable
IO_OPTS None option. The rest of the options are view only, and many
times are decided by the transmitter choice, operating
principles, etc.
Linearization type: Determines whether the field value
is used directly (direct), is converted linearly (indirect) or
is converted with the square root (indirect square root).
This can be used in different applications in distinct
ways. For example, if the direct pressure is measured,
L_TYPE None
then direct can be applied. If differential pressure is
measured with some scaling, then indirect can be used,
and if flow needs to be calculated, then indirect square
root can be used. In any case, the parameter cannot be
left blank for the transmitter to operate.
The LO alarm data, which includes a value of the alarm,
LO_ALM None
a time stamp of occurrence, and the state of the alarm.
The setting for the alarm limit used to detect the LO
LO_LIM EU@PV_SCALE alarm condition. Functionality is similar to HI LIM as
described earlier.
The LO LO alarm data, which includes a value of the
LO_LO_ALM None alarm, a time stamp of the occurrence, and the state of
the alarm.
The setting for the alarm limit used to detect the LO LO
LO_LO_LIM EU@PV_SCALE
alarm condition.
The priority of the LO LO alarm with behavior similar to
LO_LO_PRI None
other alarm priorities as described earlier.
The priority of the LO alarm with behavior similar to
LO_PRI None
other alarm priorities as described earlier.

Parameters
If the percentage value of the transducer input fails
below this, PV=0. Typical applications are differential
LOW_CUT %
pressure in flow applications. If DP is below a level,
then the strategy may need to stop the flow calculation.
The target, actual, permitted, and normal modes of the
block.
Target: mode to “go to”
MODE_BLK None
Actual: mode the “block is currently in”
Permitted: allowed modes that target “may take on”
Normal: most “common mode” for target
OUT EU@OUT_SCALE Discrete output value and status.
OUT_D None Discrete output to include a selected alarm condition
The high and low scale values, engineering unit code,
OUT_SCALE None and number of digits to the right of the decimal point
associated with it.
PV EU@XD_SCALE The process variable used in block execution.
The time constant of the first order filter. It is the time
PV_FTIME Seconds
required for a 63% change in the IN value.
A group of the data that contains the current transducer
value and status, the simulated transducer value and
SIMULATE None status, and the enable/disable bit. The most common
applications are during function block testing or display
testing.
The strategy field is used to identify the grouping of
STRATEGY None blocks. This data is not checked or processed by the
block.
The revision level of the static data associated with the
function block. The revision value will be incremented
ST_REV None
each time a static parameter value in the block is
changed.
The user description of the intended application of the
TAG_DESC None
block.
UPDATE_EVT None This alert is generated by any change in the static data.
The average absolute error between PV and its previ-
VAR_INDEX % of OUT Range ous mean value over that evaluation time defined by
VAR_SCAN.
VAR_SCAN Seconds The time over which VAR INDEX is evaluated.
The high and low scale values, engineering unit codes,
and number of digits to the right of the decimal point
associated with a channel input value. The XD_SCALE
XD_SCALE None
unit code must match the unit code of the measurement
channel in the transducer block. If the units do not
match, the block will not transition to MAN or AUTO.
Filtering
The filtering feature changes the response time of the device to smooth varia-
tions in output readings caused by rapid changes in input. The filter time con-
stant (in seconds) may be adjusted using the PV_FTIME parameter. The filter
time constant may be set to zero to disable the filter feature. Figure 3-3 illus-
trates the concept.
Figure 3-3. Analog Input Response to Set-Point Changes
Signal Conversion
The signal conversion type is set with the Linearization Type (L_TYPE)
parameter. The converted signal (in percent of XD_SCALE) can be viewed
through the FIELD_VAL parameter
Field Value = 100 × ( Channel Value – EU * 0% -)

---------------------------------------------------------------------------------------- (3-1)
( EU * @100 – EU * 0% )
*XD_SCALE Values
It is possible to choose from direct, indirect, or indirect square root signal con-
version with the L_TYPE parameter.
• Direct: Direct signal conversion allows the signal to pass through the
accessed channel input value (or the simulated value when simulation
is enabled). PV = Channel Value.
• Indirect: Indirect signal conversion converts the signal linearly to the

accessed channel input value (or the simulated value when simulation
is enabled) from its specified range (XD_SCALE) to the range and units
of the PV and OUT parameters (OUT_SCALE).
FIELD_VAL
PV =  ---------------------------------- × EU ** @100% – EU ** @0% + EU ** @0% (3-2)
 100 
** OUT_SCALE Values
• Indirect Square Root: Indirect square root signal conversion takes the
square root of the value computed with the indirect signal conversion
and scales it to the range and units of the PV and OUT parameters.
PV =  field_val
----------------------- × ( EU ** @100% – EU ** @0% ) (3-3)
 100 
**OUT_SCALE Values
When the converted input value is below the limit specified by the LOW_CUT
parameter, and the low cutoff I/O option (IO_OPTS) is enabled (true), a value
of zero is used for the converted value (PV). This option is useful in eliminat-
ing false readings when the differential pressure measurement is close to zero,
and it may also be useful with zero-based measurement devices such as flow-
meters. Note that low cutoff is the only I/O option supported by the AI block.
The I/O option may be set in manual or out-of-service mode only.
Block Errors
Table 3-2 lists conditions reported in the BLOCK_ERR parameter. The condi-
tions mentioned here are mere representations. Refer to specifications for
more information. Some of these conditions may not be applicable to the AI
block alone, and are provided for information purposes only.
Table 3-2. BLOCK_ERR Conditions

Condition
Condition Name and Description
Number
0 Other
Block Configuration Error: The selected channel carries a measurement that is
1 incompatible with the engineering units selected in XD_SCALE, the L_TYPE
parameter is not configured, or CHANNEL=0
2 Link Configuration Error
Simulate Active: Simulation is enabled and the block is using a simulated value
3
in its execution.
4 Local Override
5 Device Fault State Set
6 Device Needs Maintenance Soon
Input Failure/Process Variable has Bad Status: The hardware is bad, or a bad
7
status is being simulated.
8 Output Failure: The output is bad based primarily upon a bad input.
9 Memory Failure
10 Lost Static Data
11 Lost NV Data (Non-Volatile)
12 Read back Check Failed
13 Device Needs Maintenance Now
14 Power Up
15 Out of Service: The actual mode is out of service.
Modes
The AI function block supports three modes of operation as defined by the
MODE_BLK parameter:
• Manual (MAN), in which the block output (OUT) may be set manually
• Automatic (AUTO), in which the OUT reflects the analog input

measurement or the simulated value when simulation is enabled
• Out of Service (OOS), in which the block is not processed. FIELD_VAL

and PV are not updated and the OUT status is set to “Bad: Out of
Service.” The BLOCK_ERR parameter shows “Out of Service.” In this
mode, changes may be made to all configured parameters. The target
mode of a block may be restricted to one or more of the supported
modes.
Alarm Detection
A block alarm is generated whenever the BLOCK_ERR has an error bit set.
The types of block error for the AI block are defined above. Process alarm
detection is based on the OUT value. The alarm limits of the following stan-
dard alarms may be configured:
• High (HI_LIM)
• High high (HI_HI_LIM)
• Low (LO_LIM)
• Low low (LO_LO_LIM)
To avoid alarm chattering when the variable is oscillating around the alarm
limit, an alarm hysteresis in percent of the PV span can be set using the
ALARM_HYS parameter. The priority of each alarm is set in the following
parameters:
• HI_PRI
• HI_HI_PRI
• LO_PRI
• LO_LO_PRI
Alarms are grouped into five levels of priority as shown in table 3-3.
Table 3-3. Alarm Priorities

Priority Number Priority Description
The priority of an alarm condition changes to zero after the condition that
0
caused the alarm is corrected.
An alarm condition with a priority of one is recognized by the system, but
1
is not reported to the operator.
An alarm condition with a priority two is reported to the operator, but
2 does not require operator attention (such as diagnosis and system
alerts).
Alarm conditions of priority three to seven are advisory alarms of
3-7
increasing priority.
Alarm conditions of priority eight to 15 are critical alarms of increasing
8-15
priority.
Status Handling
Normally, the status of the PV reflects the status of the measurement value,
the operating condition of the I/O card, and any active alarm condition. In
AUTO mode, OUT reflects the value and status quality of the PV. In MAN
mode, the OUT status constant limit is set to indicate that the value is a con-
stant and the OUT status is Good.
The UNCERTAIN - EU RANGE VIOLATION status is always set, and the PV

status is set high- or low-limited if the sensor limits for conversion are
exceeded.
In the STATUS_OPTS parameter, the status handling may be controlled by

selecting from the following options:
• BAD if Limited – sets the OUT status quality to “bad” when the value is
higher or lower than the sensor limits
• Uncertain if Limited – sets the OUT status quality to “uncertain” when

the value is higher or lower than the sensor limits
• Uncertain if in Manual mode – sets the status of the output to

“uncertain” when the mode is set to manual
The instrument must be in manual or out-of-service mode to set the status

option. The AI block only supports the BAD if limited option. In some systems
implementation, unsupported options are not grayed out; they appear on the
screen in the same manner as supported options, leading to quality issues in
the later stages of the projects.
Advanced Features
The AI function blocks in some fieldbus devices provide added capability
through the following additional parameters:
• ALARM_TYPE – Allows one or more of the process alarm conditions

detected by the AI function block to be used in setting its OUT_D
parameter.
• OUT_D – Discrete output of the AI function block based on the

detection of process alarm condition(s). This parameter may be linked
to other function blocks that require a discrete input based on the
detected alarm condition.
• VAR_SCAN – Time period in seconds over which the variability index

(VAR_INDEX) is computed.
• VAR_INDEX – Process variability index measured as the integral of

average absolute error between PV and its mean value over the
previous evaluation period. This index is calculated as a percent of
OUT span and is updated at the end of the time period defined by
VAR_SCAN.
Troubleshooting
Troubleshooting is an important aspect of the engineering life cycle of the
devices. The intelligence in the devices coupled with FOUNDATION Fieldbus
technology enables the platform to implement diagnostics for easy trouble-
shooting. The following are some troubleshooting guidelines for the proper
operation of the devices (table 3-4).
Table 3-4. Troubleshooting

Symptom Possible Causes Corrective Action
Mode will not leave OOS Target mode not set Set target mode to something other than
OOS.
Configuration Error BLOCK_ERR will show the configuration
error bit set. The following are parame-
ters that must be set before the block is
allowed out of OOS:
• CHANNEL must be set to a valid value
and cannot be left at initial value of 0.
• XD_SCALE.UNITS_INDEX must
match the units in the transducer block
channel value.
• L_TYPE must be set to “direct,”
“indirect,” or “square root” and cannot
be left an initial value of “0.”
Resource Block The actual mode of resource block is
OOS. See resource block diagnostics for
corrective actions.
Schedule Block is not scheduled and therefore
cannot execute to go to target mode.
Schedule the block to execute.

Process and/or block Features FEATURES_SEL does not have alerts
alarms will not work enabled. Enable the alerts bit.
Notification LIM_NOTIFY is not high enough. Set
equal to MAX_NOTIFY.
Status Options STATUS_OPTS has propagated fault
forward bit set. This means the option
exists to set a bit before an alarm is
raised. This should be cleared to cause
an alarm to occur.
Value of output does not Linearization Type L_TYPE must be set to “direct,” “indi-
make sense rect,” or “indirect square root” and cannot
be left at initial value of “0.”
Scaling Scaling parameters are set incorrectly.
• XD_SCALE.EU0 and EU100 should
match that of the transducer block
channel value.
• OUT_Scale. EU0 and EU100 are not
set properly.
Cannot set HI_LIMIT, Scaling Limit values are outside the
HI_HI_LIMIT, LO_LIMIT OUT_SCALE.EU0 and
or LO_LO_LIMIT values OUT_SCALE.EU100 values. Change
OUT_Scale or set values within range.
3.2 Analog Output (AO) Function Block

The analog output (AO) function block assigns an output value to a field
device through a specified I/O channel. The block supports mode control, sig-
nal status calculation, and simulation. Figure 3-4 illustrates the internal com-
ponents of the AO function block, and figure 3-5 lists the definitions of the
system parameters.
The analog output block is also a critical function block in the building of a
control strategy. The block normally resides in a control valve. The most
advanced control valves have more such blocks to handle multiple control
requirements. The AO, along with the other blocks of the valve, makes more
stable and reliable control strategies. The back calculation of the AO block
provides a safe option for the block in the event of communication failures or
any other failures. The feature always provides a backward propagation of
information for the AO block and hence the valve to be in a safe state. The AO
block also has options to handle the direct, reverse actions of the valve posi-
tioners, and the associated transducer block supports most advanced diagnos-
tics like valve stiction, valve signatures, and several other diagnostics. The AO
Figure 3-4. Analog Output Function Block
block is again provided with a set of modes of operations to meet various con-
trol requirements. Refer to table 3-5 for the parameters of most of the AO
blocks in most popular devices and the description of each of them.
Figure 3-5. Analog Output Function Block Schematic

Table 3-5. Analog Output Function Block System Parameters

Parameters Units Description
BKCAL_OUT EU of PV_SCALE The value and status required by the BKCAL_IN input
of another block to prevent reset windup and to pro-
vide bumpless transfer to closed loop control.
BLOCK_ERR None The summary of the active error conditions associ-
ated with the block. The block errors for the analog
output block are simulate active, input failure/process
variable has bad status, output failure, read back
failed, and out of service.
CAS_IN EU of PV_SCALE The remote set-point value from another function
block.
IO_OPTS None Allows the user to select how the I/O signals are pro-
cessed. The supported I/O option for the AO function
block are SP_PV Track in MAN, Increase to Close,
and Use PV for BKCAL_OUT.
CHANNEL None Defines the output that drives the field devices.
MODE None Enumerated attribute used to request and show the
source of the set point and/or output used by the
block.
OUT EU of XD_SCALE The primary value and status calculated by the block
in auto mode. OUT may be set manually in MAN
mode.
PV EU of PV_SCALE The process variable used in block execution. This
value is converted from READBACK to show the
actuator position in the same units as the set-point
value.
PV_SCALE None The high and low scale values, the engineering units
code, and the number of digits to the right of the deci-
mal point associated with the PV.
READ BACK EU of XD_SCALE The measured or implied actuator position associated
with the OUT value.
SIMULATE EU of XD_SCALE Enables simulation and allows the user to enter an
input value and status.
SP EU of XD_SCALE The target block output value (set point).
SP_HI_LIM EU of PV_SCALE The highest set-point value allowed.
SP_LO_LIM EU of PV_SCALE The lowest set-point value allowed.
SP_RATE_DN EU of PV_SCALE Ramp rate for downward set-point changes. When
Per second the ramp rate is set to zero, the set point is used
immediately.
SP_RATE_UP EU of PV_SCALE Ramp rate for upward set-point changes. When the
Per second ramp rate is set to zero, the set point is used immedi-
ately.
SP_WRK EU of PV_SCALE The working set point of the block. It is the result of
set-point rate of change limiting. The value is con-
verted to percent to obtain the block’s OUT value.
Setting the Output

It is necessary to set the mode to define the manner in which the block deter-
mines its set point before setting the output for the AO block. In manual
mode, the value of the output attribute (OUT) must be set manually, and is
independent of the set point. In automatic mode, OUT is set automatically
based on the value specified by the set point (SP) in engineering units and the
I/O options attribute (IO_OPTS). In addition, the user can limit the SP value
and the rate at which a change in the SP is passed to OUT.
In cascade mode, the cascade input connection (CAS_IN) is used to update the
SP. The back calculation output (BKCAL_OUT) is wired to the back calcula-
tion input (BKCAL_IN) of the upstream block that provides CAS_IN. This
ensures a bumpless transfer on mode changes and windup protection in the
upstream block. The OUT attribute or an analog read-back value, such as
valve position, is shown by the process value (PV) attribute in engineering
units. To manually set the channel feedback for testing purposes, simulation
must be enabled. The AO function block does not support alarm detection.
To select the manner of processing the SP and the channel output value, the
user must configure the set-point limiting options, the tracking options, and
the conversion and status calculations. The OUT value in different modes is
shown in figure 3-6.
Figure 3-6. Analog Output Function Block Timing Diagram

Set-Point Selection and Limiting

The MODE attribute is used to select the source of the SP values. In automatic
(AUTO) mode, the local, manually entered SP is used. In cascade (CAS) mode,
the SP comes from another block through the CAS_IN input connector. In
remote cascade (RCAS) mode, the SP comes from a host computer that writes
to RCAS_IN. PV_SCALE attribute is used to define the range and units of
the SP.
In manual (MAN) mode the SP automatically tracks the PV value when SP-PV
Track is selected in the MAN I/O option. The SP value is set equal to the PV
value when the block is in manual mode, and is enabled (true) as default. This
option can be disabled in MAN or OOS mode only. The SP value is limited to
the range defined by the set-point high limit attribute (SP_HI_LIM) and the
set-point low limit attribute (SP_LO_LIM).
In AUTO mode, the rate at which a change in the SP is passed to OUT is lim-
ited by the values of the set-point upward rate limit attribute (SP_RATE_UP)
and the set-point downward rate limit attribute (SP_RATE_DN). A limit of
zero prevents rate limiting, even in AUTO mode.
Conversion and Status Calculation

The working set point (SP_WRK) is the set-point value after limiting. It is pos-
sible to reverse the conversion range, which will reverse the range of
PV_SCALE to calculate the OUT attribute, by selecting the “increase to close”
I/O option. This inverts the OUT value with respect to the set point based on
the PV_SCALE and the XD_SCALE.
In AUTO mode, the converted SP value is stored in the OUT attribute. In

MAN mode, the OUT attribute is set manually, and is used to set the analog
output defined by the CHANNEL parameter.
The actuator position associated with the output channel can be accessed
through the READBACK parameter (in OUT units) and in the PV attribute (in
engineering units). If the actuator does not support position feedback, the PV
and READBACK values are based on the OUT attribute.
The working set point (SP_WRK) is the value normally used for the
BKCAL_OUT attribute. However, for those cases where the READBACK sig-
nal directly (linearly) reflects the OUT channel, the PV may be used for
BKCAL_OUT by selecting the “use PV for BKCAL_OUT” I/O option.
Action on Fault Detection

The following parameters may be configured to define the state that the out-
put device or final control element, normally a valve, is to enter when the
CAS_IN input detects a BAD status and the block is in CAS mode:
• FSTATE_TIME: The length of time that the AO block waits to position

the OUT value to the FSTATE_VAL value upon the detection of a fault
condition. When the block has a target mode of CAS, a fault condition
is detected if the CAS_IN has a BAD status or if an “initiate fault state”
substatus is received from the upstream block.
• FSTATE_VAL: The value to which the OUT value transitions after

FSTATE_TIME elapses and the fault condition has not cleared. The
channel can be configured to hold the value at the start of the failure
action condition or to go to the failure action value
(FAIL_ACTION_VAL).
Block Errors
The following conditions are reported in the BLOCK_ERR attribute:
• Input failure/process variable has BAD status: The hardware is bad, or

a BAD status is being simulated.
• Out of service: The block is in out-of-service (OOS) mode.
• Output failure: The output hardware is bad.
• Read back failed: The read back failed.
• Simulate active: Simulation is enabled, and the block is using a

simulated value in its execution.
Modes
The analog output function block supports the following modes:
• Manual (MAN): The output to the I/O channel can be set through the
OUT attribute. This mode is used primarily for maintenance and
troubleshooting.
• Automatic (AUTO): The block output (OUT) reflects the target

operating point specified by the set-point (SP) attribute.
• Cascade (CAS): The SP attribute is set by another function block

through a connection to CAS_IN. The SP value is used to set the OUT
attribute automatically.
• Remote Cascade (RCAS): The SP is set by a host computer by writing to

the RCAS_IN parameter. The SP value is used to set the OUT attribute
automatically.
• Out of Service (OOS): The block is not processed. The output channel is
maintained at the last value and the status of OUT is set to “Bad: Out of
Service.” The BLOCK_ERR attribute shows out of service.
• Initialization Manual (IMAN): The path to the output hardware is

broken, and the output will remain at the last position.
• Local Override (LO): The output of the block is not responding to OUT
because the resource block has been placed into LO mode or fault state
action is active. The target mode of the block may be restricted to one or
more of the following modes: MAN, AUTO, CAS, RCAS, or OOS.
Status Handling
Output or read-back fault detection is reflected in the status of PV, OUT, and
BKCAL_OUT. A limited SP condition is reflected in the BKCAL_OUT status.
When simulation is enabled through the SIMULATE attribute, the value and
status for PV and READBACK can be set. When the block is in CAS mode and
the CAS_IN input goes bad, the block sheds (lowers down) mode to the next
permitted mode.
3.3 Proportional-Integral-Derivative Function Block

The proportional-integral-derivative (PID) function block combines all the
necessary logic to perform PID control. The block supports mode control, sig-
nal scaling and limiting, feedforward control, override tracking, alarm limit
detection, and signal status propagation. The block supports two forms of the
PID equation: standard and series. The FORM parameter should be used to
choose the appropriate equation. The standard ISA PID equation is the default
selection. To further customize the block for use in a specific application, fil-
tering, feedforward inputs, tracking inputs, set point and output limiting, PID
equation structures, and block output action can be configured. The standard
representation of the PID is shown in figure 3-7.
Figure 3-7. PID Function Block
The PID function block parameters and their description with units are listed
in table 3-6.
Table 3-6. PID Function Block System Parameters

ACK_OPTION None Used to set auto-acknowledgement of alarms.
ALARM_HYS % The amount the alarm value must return to within the
alarm limit before the associated active alarm condition
clears.
ALARM_SUM None The summary alarm is used for all process alarms in the
block. The first alert to become active will set the active
status in the status parameters. As soon as the unre-
ported status is cleared by the alert reporting task,
another block alert may be reported without clearing the
active status.

ALERT_KEY None The identification number of the plant unit. This informa-
tion may be used in the host for sorting alarms, etc.
ALG_TYPE None Selects filtering algorithm as backward or bilinear.
BAL_TIME Seconds The specified time for the internal working value of bias to
return to the operator set bias. Also used to specify the
time constant at which the integral term will move to
obtain balance when the output is limited and the mode is
AUTO, CAS, or RCAS.
BIAS EU of The bias value used to calculate output for the PD type
OUT_SCALE controller.
BKCAL_HYS % The amount the output value must change away from the
output limit before limit status is turned off.
BKCAL_IN EU of The analog input value and status from another block’s
OUT_SCALE BKCAL_OUT output that is used for backward output
tracking for bumpless transfer and to pass limit status.
BKCAL_OUT EU of The value and status required by the BKCAL_IN input of
PV_SCALE another block to prevent reset windup and to provide
bumpless transfer of closed loop control.
BLOCK_ALM None The block alarm is used for all configuration, hardware,
connection failure, or system problems in the block. The
cause of the alert is entered in the subcode field. The first
alert to become active will set the active status in the sta-
tus parameter. As soon as the unreported status is
cleared by the alert reporting task, another block alert
may be reported without clearing the active status (if the
subcode has changed).
BLOCK_ERR None This parameter reflects the error status associated with
the hardware or software components associated with a
block. It is a bit string so that multiple errors can be
shown.
BYPASS None Used to override the calculation of the block. When
enabled, the SP is sent directly to the output.
CAS_IN EU of
The remote set-point value from another block.
PV_SCALE
CONTROL_OPTS None Allows the user to specify control strategy options. The
supported control options for the PID block are track
enable, track in manual, SP-PV track in MAN, SP-PV
track in LO or IMAN, use PV for BKCAL_OUT, and direct
acting.
DV_HI_ALM None The DV HI alarm data, which includes a value of the
alarm, a time stamp of occurrence, and the state of the
alarm.
DV_HI_LIM EU of The setting for the alarm limit used to detect the deviation
PV_SCALE high alarm condition.
DV_HI_PRI None The priority of the deviation high alarm.

DV_LO_ALM None The DV LO alarm data, which includes a value for the
alarm.
DV_LO_LIM EU of The setting for the alarm limit used to detect the deviation
PV_SCALE low alarm condition.
DV_LO_PRI None The priority of the deviation low alarm.
ERROR EU of
The error (SP-PV) used to determine the control action.
PV_SCALE
FF_ENABLE None Enables the use of feedforward calculations.
FF_GAIN None The feedforward gain value. FF_VAL is multiplied by
FF_GAIN before it is added to the calculated control out-
put.
FF_SCALE None The high and low scale values, engineering units code,
and number of digits to the right of the decimal point asso-
ciated with the feedforward value (FF_VAL).
FF_VAL EU of
The feedforward control input value and status.
FF_SCALE
GAIN None The proportional gain value. This value cannot be zero.
GRANT_DENY None Options for controlling access of the host computers and
local control panels to operating, tuning, and alarm
parameters of the block. Not used by the device.
HI_ALM None The HI alarm data, which includes a value of the alarm, a
time stamp of occurrence, and the state of the alarm.
HI_HI_ALM None The HI HI alarm data, which includes a value of the alarm,
a time stamp of occurrence, and the state of the alarm.
HI_HI_LIM EU of The setting from the alarm limit used to detect the HI HI
PV_SCALE alarm condition.
HI_HI_PRI None The priority of the HI HI alarm.
HI_LIM EU of The setting for the alarm limit used to detect the HI alarm
PV_SCALE condition.
HI_PRI None The priority of the HI alarm.
IN EU of
The connection for the PV input from another block.
PV_SCALE
LO_ALM None The LO alarm data, which includes a value of the alarm, a
time stamp, and the state of the alarm.
LO_LIM EU of The setting for the alarm limit used to detect the LO alarm
PV_SCALE condition.
LO_LO_ALM None The LO LO alarm data, which includes a value of the
alarm.
LO_LO_LIM EU of The setting for the alarm limit used to detect the LO LO
PV_SCALE alarm condition.
LO_LO_PRI None The priority of the LO LO alarm.
LO_PRI None The priority of the LO alarm.

MATH_FORM None Selects equation form (series or standard form).
MODE_BLK None The actual, target, permitted, and normal modes of the
block.
Actual: the mode the “block is currently in.”
Target: The mode to “go to.”
Permitted: Allowed modes that target may take on.
Normal: Most common mode for target.
OUT EU of
The block input value and status.
OUT_SCALE
OUT_HI_LIM EU of
The maximum output value allowed.
OUT_SCALE
OUT_LO_LIM EU of
The minimum output value allowed.
OUT_SCALE
OUT_SCALE None The high and low scale values, engineering unit code, and
the number of decimals to the right of the decimal point
associated with OUT.
PV EU of
The process variable used in block execution.
PV_SCALE
PV_FTIME Seconds The time constant of the first order PV filter. It is the time
required for a 63% change in IN value.
PV_SCALE None The high and low scale values, engineering units code,
and the number of digits to the right of the decimal point
associated with PV.
RATE Seconds The derivative action time constant.
RCAS_IN EU of Target set point and status that are provided by the super-
PV_SCALE visory host. Used when the mode is RCAS.
RCAS_OUT EU of Block set point and status after ramping, filtering, and lim-
PV_SCALE iting that are provided to the supervisory host for back cal-
culation to allow action to be taken under limiting
conditions or mode changes. Used when mode is RCAS.
RESET Seconds per
The integral action time constant.
repeat
ROUT_IN EU of Target output and status that is provided by a supervisory
OUT_SCALE host. Used when mode is ROUT.
ROUT_OUT EU of Block output that are provided to a supervisory host for a
OUT_SCALE back calculation to allow action to be taken under limiting
conditions or mode changes. Used when mode is RCAS.
SHED_OPT None Defines the action to be taken on remote control device
time out.
SP EU of The target block’s set-point value. It is the result of set-
PV_SCALE point limiting and set-point rate of change limiting.
SP_FTIME Seconds The time constant of the first order SP filter. It is the time
required for a 63% change in input value.
SP_HI_LIM EU of
The highest SP value allowed.
PV_SCALE

SP_LO_LIM EU of
The lowest SP value allowed.
PV_SCALE
SP_RATE_DN EU of
Ramp rate for downward SP changes. When the ramp
PV_SCALE
rate is set to zero, the SP is used immediately.
Per second
SP_RATE_UP EU of
Ramp rate for upward SP changes. When the ramp rate is
PV_SCALE
set to zero, the SP is used immediately.
Per second
SP_WORK EU of The working set point of the block after limiting and filter-
PV_SCALE ing are applied.
STATUS_OPTS None Allows selection of options for status handling and pro-
cessing. The supported status options for the PID block is
target to manual if bad IN, etc.
STRATEGY None The strategy field can be used to identify the grouping of
blocks. This data is not checked or processed by the
block.
ST_REV None The revision level of the static data associated with the
function block. The revision value will be incremented
each time a static parameter value in the block is
changed.
STRUCTURE None
Defines PID equation structure to apply controller action.
CONFIG
TAG_DESC None The user description of the intended application of the
block.
TRK_IN_D None Discrete input that initiates external tracking.
TRK_SCALE None The high and low scale values, engineering units code,
and number of digits to the right of the decimal point asso-
ciated with the external tracking value (TRK_VAL).
TRK_VAL EU of The value (after scaling) from TRK_SCALE to
TRK_SCALE OUT_SCALE applied to OUT in LO mode.
UBETA % Used to set disturbance rejection versus tracking
response action for a 2.0 degree of freedom PID.
UGAMMA % Used to set disturbance rejection versus tracking
response action for a 2.0 degree of freedom PID.
UPDATE_EVT % The alert is generated by any changes to the static data.
Table 3-6 above lists the PID block parameters, their descriptions, and units of
measure, while figure 3-8 illustrates the internal components of the PID func-
tion block.
The PID equations that are used in the standard are provided below.
 1 τd s + 1 
Standard Out = GAIN × e ×  1 + ------- + --------------------------
- + F
 τ γ s α × τ d s + 1
1  τds + 1 
Series Out = GAIN × e ×  1 + ------- +  --------------------------- + F
 τγ s   α × τ d s + 1
where:
GAIN = proportional gain value

τγ = integral action time constant (RESET Parameter) in seconds
s = Laplace operator
τ_d = derivative action time constant (RATE parameter)
α = fixed smoothing factor of 0.1 applied to RATE
F = feedforward control contribution from the feedforward input
(FF_VAL Parameter)
e = error between set point and process variable
The schematics design of the PID, which is given in figure 3-8, provides a
graphical illustration of the behavior of the PID in FOUNDATION Fieldbus tech-
nology. This figure also provides information on the internal subsystems and
their interconnection.
Set-Point Selection and Limiting

The mode determines the set point of the PID block. The SP_HI_LIM and
SP_LO_LIM parameters can be configured to limit the set point. In cascade or
remote cascade mode, the set point is adjusted by another function block or by
a host computer, and the output is computed based on the set point.
In AUTO mode, the set point is entered manually by the operator, and the
output is computed based on the set point. In AUTO mode, the set-point limit
and the set-point rate of change can also be adjusted by using the
SP_RATE_UP and SP_RATE_DN parameters.
In MAN mode, the output is entered manually by the operator, and is inde-
pendent of the set point. In remote output mode, the output is entered by a
Figure 3-8. PID Function Block Schematic
host computer, and is independent of the set point. Figure 3-9 depicts the SP
selection in the PID process.
Filtering
The filtering feature changes the response time of the device to smooth varia-
tions in output readings caused by rapid changes in input. The filtering fea-
ture can be adjusted by using the FILTER_TYPE parameter, and the filter time
constant (in seconds) can be adjusted by using the PV_FTIME or SP_FTIME
parameters. The filter time constant should be set to zero to disable the filter-
ing feature.
Figure 3-9. PID Function Block Set-Point Selection
Feedforward Calculation
The feedforward value (FF_VAL) is scaled (FF_SCALE) to a common range
for compatibility with the output scale (OUT_SCALE). A gain value
(FF_GAIN) is applied to achieve the total feedforward contribution.
Tracking
The use of output tracking can be enabled using control options. Control
options can be set in manual or out-of-service mode only. The track enable
control option must be set to “true” for the tracking function to operate. When
the track-in-manual control option is set to “true,” tracking can be activated
and maintained only when the block is in manual mode. When track in man-
ual is set to “false,” the operator can override the tracking function when the
block is in manual mode. Activating the track function causes the block’s
actual mode to revert to local override. The TRK_VAL parameter specifies the
value to be converted and tracked into the output when the tracking function
is operating. The TRK_SCALE parameter specifies the range of TRK_VAL.
When the TRK_IN_D parameter is true and the track enable control option is
true, the TRK_VAL input is converted to the appropriate value and output in
units of OUT_SCALE.
Output Selection and Limiting

Output selection is determined by the mode and the set point. The PID control
equation computes the output in the automatic, cascade, or remote cascade
mode. In manual and remote output mode, the output may be entered manu-
ally. The output can be limited by configuring the OUT_HI_LIM and
OUT_LO_LIM parameters. Output selection is determined by the mode and
the set point. In automatic, cascade, or remote cascade mode, the output is
computed by the PID control equation. In manual and remote output mode,
the output may be entered manually. The output can be limited by configur-
ing the OUT_HI_LIM and OUT_LO_LIM parameters.
Bumpless Transfer and Set-Point Tracking

Tracking the set point is achieved by configuring the following control
options (CONTROL_OPTS):
• SP-PV Track in MAN: Permits the SP to track the PV when the target
mode of the block is MAN.
• SP-PV Track in LO or IMAN: Permits the SP to track the PV when the

actual mode of the block is local override (LO) or initialization manual
(IMAN). When one of these options is set, the SP value is set to the PV
value while in the specified mode. The Use PV for BKCAL_OUT
control option should be configured to select the value that a master
controller uses for tracking. The BKCAL_OUT value tracks the PV
value. BKCAL_IN on a master controller connected to BKCAL_OUT on
the PID block in an open cascade strategy forces its OUT to match
BKCAL_IN, thus tracking the PV from the slave PID block into its
cascade input connection (CAS_IN).
• When the Use PV for BKCAL_OUT option is not selected, the working
set point (SP_WRK) is used for BKCAL_OUT. Control options can be
set in manual or out-of-service mode only. When the mode is set to
auto, the SP remains at the last value (it will no longer follow the PV).
Reverse and Direct Action

The direct acting control option can be enabled to configure the block output
action. This option defines the relationship between a change in PV and the
corresponding change in output. With direct acting enabled (true), an increase
in PV results in an increase in the output. Control options can be set in manual
or out-of-service mode only.
Reset Limiting
The PID function block provides a modified version of feedback reset limiting
that prevents windup when output or input limits are encountered, and pro-
vides the proper behavior in selector applications.
Modes
The PID function block supports the following modes:
• Manual (MAN): The block output (OUT) may be set manually.
• Automatic (AUTO): The SP may be set manually, and the block

algorithm calculates OUT.
• Cascade (CAS): The SP is calculated in another block and is provided to

the PID block through the CAS_IN connection.
• Remote Cascade (RCAS): The SP is provided by a host computer that

writes to the RCAS_IN parameter.
• Remote Output (ROUT): The OUT is provided by a host computer that

writes to the ROUT_IN parameter
• Local Override (LO): The track function is active. OUT is set by

TRK_VAL. The BLOCK_ERR parameter shows local override.
• Initialization Manual (IMAN): The output path is not complete (for

example, the cascade-to-slave path might not be open). In IMAN mode,
OUT tracks BKCAL_IN.
• Out of Service (OOS): The block is not processed. The OUT status is set
to Bad: Out of Service. The BLOCK_ERR parameter shows out of
service. The MAN, AUTO, CAS, and OOS modes can be configured as
permitted modes for operator entry.
Status Handling
If the input status on the PID block is bad, the mode of the block reverts to
manual. In addition, the “Target to Manual if Bad IN” status option can be
selected to direct the target mode to revert to manual. The status option can be
set in manual or out-of-service mode only.
Troubleshooting
Table 3-7 can be referred to for troubleshooting problems.

Symptoms Possible Causes Corrective Actions
Mode will Target mode not set Set target mode to something other than OOS.
not leave Configuration error BLOCK_ERR will show the configuration error bit set.
OOS The following are parameters that must be set before
the block is allowed out of OOS:
1. Bypass must be off or on, and cannot be left at
initial value of “0.”
2. OUT_HI_LIM must be less than or equal to
OUT_LO_LIM.
3. SP_HI_LIM must be less than or equal to
SP_LO_LIM.
Resource Block The actual mode of the resource block is OOS. See
resource block diagnostics for corrective actions.
Schedule Block is not scheduled and therefore cannot execute
to go to target mode. Schedule the block to execute.
Mode will Back Calculation BKCAL_IN
not leave 1. The link is not configured (the status would show
IMAN “not connected”). Configure the BKCAL_IN link to
the downstream block.
2. The downstream block is sending back a quality of
“BAD” or a status of “not invited.” See the
appropriate downstream block diagnostics for
corrective action.
not change Input IN
to AUTO The link is not configured (the status would show “not
connected”). Configure the IN LINK to the block.
The upstream block is sending back a quality of
“BAD” or a status of “not invited.” See appropriate
upstream block diagnostics for corrective action.
not change Cascade Input CAS_IN
to CAS The link is not configured (the status would show “not
connected”). Configure the CAS_IN link to the block.
The upstream block is sending back a quality of
“BAD” or a status of “not invited.” See the appropriate
upstream block diagnostics for corrective action.
Mode sheds Remote cascade value Host system is not writing RCAS_IN with a quality and
from RCAS status of “good cascade” within shed time.
to AUTO Shed timer The mode shed timer, SHED_RCAS in the resource
block is set too low. Increase the value.

Mode sheds Remote output value Host system is not writing ROUT_IN with a quality and
from ROUT status of “good cascade” within shed time.
to MAN Shed timer The mode shed timer, SHED_RCAS, in the resource
block is set too low. Increase the value.
Process/ Features FEATURES_SEL does not have alerts enabled.
block alarms Enable the alert bits.
will not work Notifications LIM_NOTIFY is not high enough. Set equal to
MAX_NOTIFY.
Status options STATUS_OPTS has propagated fault forward bit set.
This should be cleared to cause an alarm to occur.
Refer to specifications for more details.
3.4 Discrete Input Function Block

The discrete input (DI) function block provides status from a field device and
makes it available to other function blocks. The discrete input function block
supports mode control, signal status propagation, and simulation. The block
provides the ability to configure inversion and alarm detection on the input
value.
Normally, the block is used in automatic (AUTO) mode so that the process
variable (PV_D) is copied to the output (OUT_D). The mode can be changed
to manual (MAN) to disconnect the field signal and substitute a manually
entered value for OUT_D. In this case, PV_D continues to show the value that
will become OUT_D when the mode is changed to auto. Refer to figure 3-10
for the function block.
To support testing, simulation can be enabled, which allows the measurement

value to be supplied manually through the SIMULATE_D parameter. Figure
3-11 illustrates the internal components of the DI function block, and table 3-8
lists the definitions of the system parameters.
Figure 3-10. DI Function Block
Figure 3-11. Internal Schematic of a DI Function Block

Table 3-8. Parameters of a DI Function Block

Parameter Units Description
BLOCK_ERR None The summary of active error conditions associated with the
block. The supported block errors in the discrete input func-
tion block are simulate active, input failure/process variable
has BAD status, and out of service.
DISC_LIM None The state of the discrete input that causes an alarm. Any
number from zero to 255 may be used. State 255 specifies
that no alarm indication be shown.
FIELD_VAL_D None The value and status of the discrete input from a field device.
CHANNEL None Defines the I/O input used for the field measurement.
IO_OPTS None Allows the selection of options for I/O value processing. The
supported I/O option for the Discrete input function block is
invert.
MODE None The mode record of the block. Contains the actual, target,
permitted, and normal modes.
OUT_D None The discrete output value and status.
PV_D None The discrete process variable used in block execution.
SIMULATE_D None Enables simulation and allows entering an input value and
status when SIMULATE_IN_D is not connected.
I/O Selection
To select the I/O associated with the discrete measurement, the value of the
CHANNEL attribute should be configured.
Simulation
To support testing, it is necessary to either change the mode of the block to
manual or adjust the output value, or enable simulation through the configu-
ration tool and manually enter a value for the measurement value and its sta-
tus. All fieldbus instruments have an ENABLE jumper, and in both cases, the
ENABLE jumper must first be set on the field device. As a safety measure, the
jumper has to be reset every time there is a power interruption. This measure
is to prevent devices that went through simulation in the staging process from
being installed with simulation enabled. With simulation enabled, the actual
measurement value has no impact on the OUT_D value or the status.
Field Value Processing

The invert I/O option (IO_OPTS) can be configured to process FIELD_VAL_D.
The invert option indicates whether or not the discrete input is logically
inverted (i.e., on to off, or one to zero) before it is stored in the process variable
(PV_D). The output of the invert processor is PV_D. This value goes to the
mode switch where it becomes OUT_D when the mode is AUTO. OUT_D is
also tested for an alarm state. This option might be chosen when the field con-
tact is normally closed, so an open contact or a broken wire represents the
active state of the condition being sensed.
Alarm Detection
The DISC_LIM attribute should be configured to select the state that initiates
an input alarm and to set discrete alarm substatus in the output. Any value
between zero and 255 can be entered. A value of 255 disables the alarm.
Block Errors
• Simulate Active: SIMULATE_D is enabled; OUT_D does not reflect

actual process conditions.
• Input Failure/Process Variable has BAD Status: The hardware is bad;

the configured channel is invalid; or a BAD status is being simulated.
• Out of Service: The block is not being processed.
Modes
The DI function block supports the following modes:
• Manual (MAN): The output (OUT_D) is disconnected from the field.
• Automatic (AUTO): The block algorithm determines OUT_D.
• Out of Service (OOS): The block is not processed. The output status is
set to Bad: Out of Service. The BLOCK_ERR attribute shows out of
service.
Status Handling
Under normal conditions, a “Good: noncascade” status is passed through to
OUT_D. The block also supports status action on failure and block error
indications.
Action on Failure
In case of hardware failure, FIELD_VAL_D, PV_D and OUT_D change to a
BAD status, and the BLOCK_ERR attribute displays Bad PV. When
SIMULATE_D is enabled, FIELD_VAL_D, PV_D and OUT_D change to a sim-

ulation status. When the block is set to MAN mode, OUT_D is set to Good:
noncascade, constant status.
3.5 Discrete Output Function Block

The discrete output (DO) function block processes a discrete set point and
saves it to a specified channel to produce an output signal. The high-level
symbol of the block is as shown in figure 3-12. The block supports mode
control, output tracking, and simulation. There is no process alarm detection
in the block. In operation, the DO function block determines its set point, sets
the output, and, as an option, checks a feedback signal from the field device to
confirm the physical output operation. Figure 3-13 illustrates the internal
components of the DO function block, and table 3-9 lists the system
parameters.
Figure 3-12. Digital Output Function Block

Figure 3-13. Internal Schematic of Digital Output Function Block
Table 3-9. Parameters of a Digital Output Function Block

BKCAL_OUT_D None The value and status required by BKCAL_IN_D input of
another block for output tracking.
BLOCK_ERR None The summary of active error conditions associated with the
block. The supported block errors in the discrete output
function block are simulate active, input failure/process
variable has BAD status, output failure, read back failed,
and out of service.
CAS_IN_D None The remote set-point value from another block.
IO_OPTS None Allows the user to select how the I/O signals are pro-
cessed. The supported I/O options for the discrete output
function block are SP_PV track in MAN, invert, and use PV
for BKCAL_OUT.
CHANNEL None Defines the output that drives the field device.
MODE None The mode record of the block. Contains the actual, target,
permitted, and normal modes
OUT_D None The discrete output value and status.
PV_D None The discrete process variable calculated from
READBACK_D.
Table 3-9. Parameters of a Digital Output Function Block

READBACK_D None The discrete feedback from the output.
SIMULATE_D None Enables simulation.
SP_D None The discrete target block output value (set point).
Setting the Output

To set the output for the DO block, the mode should be set to define the man-
ner in which the block determines its set point. In cascade mode, the set point
equals the input value (CAS_IN_D). In automatic or manual mode, the set
point must be entered manually. In remote cascade mode, the set point is
determined by a host computer that is writing to the RCAS_IN_D parameter.
To further customize the output, the SP_PV track in man, invert, and use PV
for BKCAL_OUT I/O options may be configured. It should be noted that
SP_PV track in man, invert, and use PV for BKCAL_OUT are the only I/O
options supported by the DO block. I/O options can only be configured in
manual or out-of-service mode.
The SP_PV track-in-man option permits the set point to track the process vari-
able when the block is in manual mode. With this option enabled, the set point
(SP_D) becomes a copy of the process variable (PV_D), and a manually
entered SP_D value is overwritten on the block’s next execution cycle. This
option can prevent a state change when transitioning from manual to auto-
matic mode. This option can be disabled in manual or out-of-service mode
only.
The invert option inverts the set point (SP_D) before it is stored in OUT_D.
OUT_D becomes an inverted copy of SP_D with this option enabled. With this
option disabled, OUT_D is a direct copy of SP_D. If discrete output feedback
is not supported by the field device, a copy of OUT_D is used in its place (with
a delay of one execution time) to become READBACK_D. The read-back value
is processed through the invert option to become PV_D, which normally
matches SP_D in AUTO, CAS, or RCAS mode.
The use PV for BKCAL_OUT option specifies that BKCAL _OUT equals the
value of the process variable (PV_D) instead of the set point (SP_D). If this
option is not enabled, BKCAL_OUT will equal SP_D.
Simulation
With SIMULATE_D enabled, the specified value and status are reflected in
READBACK_D. If SIMULATE_D is not enabled, and the mode is not out of
service, the value of OUT_D is sent to the hardware.
Action on Fault Detection

The following parameters should be configured to determine the state to
which the output goes if the block is in CAS mode and the CAS_IN input has
a BAD status:
• FSTATE_TIME: The length of time that the AO block delays before

setting OUT equal to FSTATE_VAL upon the detection of a fault
condition. If the block’s target mode is cascade, a fault condition will be
detected if the CAS_IN has a BAD status, or an initiate fault state
substatus is received from the upstream block.
• FSTATE_VALD: The value to which the OUT_D attribute transitions if

the length of time specified in FSTATE_TIME passes and the fault
condition has not cleared. The channel can be configured to hold the
value at the start of the fault action condition or to go to the fault action
value (FAULT_ACTION_VAL).
Block Errors
• Simulate active: SIMULATE_D is enabled; therefore, PV_D is not real.
• Input failure/process variable has BAD status: The read-back value is

bad.
• Output failure: The output hardware or the configured channel is

invalid.
• Read back failed: The hardware providing read back is bad.
• Out of service: The block is not being processed.
Modes
The DO block supports the following modes:
• Manual (MAN): The block output (OUT_D) may be entered manually.

• Automatic (AUTO): The block algorithm uses the local set-point value
(SP_D) to determine OUT_D.
• Cascade (CAS): The block uses a set point supplied by another function
block.
• Remote Cascade (RCAS): The block uses a set point supplied by a host
computer.
• Out Of Service (OOS): The block is not processed, and the output is not
transferred to I/O. The BLOCK_ERR attribute shows out of service.
Status Handling/Action on Failure

Under normal operating conditions, the output statuses (OUT_D and
BKCAL_OUT_D) are Good: Cascade. If the output hardware fails, the status
of BKCAL_OUT_D is set to “Bad: Device Fail,” and the BLOCK_ERR attribute
shows output failure.
If the hardware used for output feedback fails, the status of READBACK_D
and PV_D is set to “Bad: Device Fail,” and the BLOCK_ERR attribute shows
Bad PV and read back failed.
3.6 Application Examples

Many function blocks are available for configuring multiple controls. How-
ever, we confine ourselves to basic blocks of AI, AO, PID, DI, and DO. Here
are examples of loops that can be designed using these blocks.
Application Example: Pressure Transmitter Used to Measure Level

in an Open Tank
Situation 1
The level of an open tank is to be measured using a pressure tap at the bottom
of the tank. The level measurement is to be used to control the level of liquid
in the tank. The maximum level in the tank is 16 ft. The liquid in the tank has a
density that makes the level correspond to a pressure of 7.0 psi at the pressure
tap (see figure 3-14).
Figure 3-14. Situation #1 Diagram
Solution to Situation #1
Table 3-10 lists the appropriate configuration settings, and figure 3-15 illus-
trates the correct function block configuration.
Table 3-10. Analog Input Function Block Configuration for a Pressure

Transmitter Used in Level Measurement
Parameter Configured Values
L_TYPE Indirect
XD_SCALE 0 to 7 psi
OUT_SCALE 0 to 16 ft
Figure 3-15. Function Block Diagram for a Pressure Transmitter Used in Level
Control Loop
Situation #2:
The transmitter as shown in figure 3-16 is installed below the tank in a posi-
tion where the height of the liquid column in the impulse line, when the tank
is empty, is equivalent to 2.0 psi.
Solution to situation #2
Table 3-11 lists the appropriate configuration settings; the application configu-
ration is the same as above.
Figure 3-16. Situation #2 Diagram
Table 3-11. Analog Input Function Block Configuration for a Pressure

Transmitter Used in Level Measurement
L_TYPE Indirect
XD_SCALE 2 to 9 psi
OUT_SCALE 0 to 16 ft
Application Example: Differential Pressure Transmitter to Measure

Flow
Situation
The liquid flow in a line is to be measured using the differential pressure
across an orifice plate in the line, and the flow measurement will be used in a
flow control loop. Based on the orifice specification sheet, the differential pres-
sure transmitter was calibrated for 0 to 20 in H20 for a flow of 0 to 800 gal/min,
and the transducer was not configured to take the square root of the differen-
tial pressure.
Solution
Table 3-12 lists the appropriate configuration settings, and figure 3-17 illus-
trates the correct function block configuration.
Table 3-12. Analog Input Function Block Configuration for a Differential

Pressure Transmitter
L_TYPE Indirect square root
XD_SCALE 0 to 20 in.
OUT_SCALE 0 to 800 gal/min
Figure 3-17. Function Block Diagram for a Differential Pressure Transmitter Used
in a Flow Measurement Loop
Application Example: Using an AO Block and a Valve to Control

Flow in a Pipe
Situation
A regulating valve equipped with an air-operated actuator is connected to the
analog output channel to control flow in a pipe.
Solution
The AO function block is used with an AI and a PID function block. The con-
figuration differs depending on whether the valve actuator is designed to
allow the valve to fail closed or to fail open upon the loss of power. Table 3-13
lists the appropriate settings for each attribute, and figure 3-18 illustrates the
correct function block configuration.
Table 3-13. Analog Output Function Block Configuration

Configured Values
Attribute
Fail Closed Fail Open
PV_SCALE 0 to 100% 0 to 100%
XD_SCALE 0 to 100% 0 to 100%
IO_OPTS increase
Not selected Selected
to close
Figure 3-18. Analog Output Function Block Diagram

Application Example: Basic PID Block for Steam Heater Control
Situation
A PID block is used with an AI block and an AO block to control the flow of
steam used to heat a process fluid in a heat exchanger. Figure 3-19 illustrates
the process instrumentation diagram.
Figure 3-19. PID Function Block Steam Heater Control
Solution
The PID loop uses TT101 as an input and provides a signal to the analog out-
put TCV101. The BKCAL_OUT of the AO block and the BKCAL_IN of the
PID block communicate the status and quality of information being passed
between the blocks. The status indication shows that communications are
functioning and the I/O is working properly. Figure 3-20 illustrates the correct
function block configuration.
Figure 3-20. PID Function Block Diagram for Steam Heater Control
Application Example: Feedforward Control
Situation
In the previous example, control problems can arise because of a time delay
caused by thermal inertia between the two flow streams (TT100 and TT101).
Variations in the inlet temperature (TT100) take an excessive time to be sensed
in the outlet (TT101). This delay causes the product to be out of the desired
temperature range.
Solution
Feedforward control is added to improve the response time of the basic PID
control. The temperature of the inlet process fluid (TT100) is input to an AI
function block and is connected to the FF_VAL connector on the PID block.
Feedforward control is then enabled (FF_ENABLE); the feedforward value is
scaled (FF_SCALE); and a gain (FF_GAIN) is determined. Figure 3-21 illus-
trates the process instrumentation diagram, and figure 3-22 illustrates the cor-
rect function block configuration.
Figure 3-21. PID Function Block Feedforward Control
Figure 3-22. PID Function Block Diagram for Feed-Forward Control

Application Example: Cascade Control with Master and Slave

Loops
Situation
A slave loop is added to a basic PID control configuration to measure and con-
trol steam flow to a steam heater. Variations in the steam pressure cause the
temperature in the heat exchanger to change. The temperature variation is
later sensed by TT101. The temperature controller modifies the valve position
to compensate for the steam pressure change. This process is slow and causes
variations in the product temperature. Figure 3-23 illustrates the process
instrumentation diagram.
Figure 3-23. PID Function Block Cascade Control Solution
Solution
Controlling flow allows for steam pressure variations to be compensated
before they can affect the temperature of the heat exchanger. The output from
the master temperature loop is used as the set point for the slave steam flow
loop. The BKCAL_IN and BKCAL_OUT connections on the PID blocks are
used to prevent controller windup on the master loop when the slave loop is
in manual or automatic mode, or when it has reached an output constraint.

Figure 3-24 illustrates the correct function block configuration.
Figure 3-24. PID Function Block Diagram for Cascade Control
Application Example: Cascade Control with Override

The PID function block can be used with other function blocks for complex
control strategies. Figure 3-25 illustrates the function block diagram for cas-
cade control with override. If one of the PID function blocks connected to the
selector inputs is deselected when configured for cascade control with over-
ride, that PID block filters the integral value to the selected value (the value at
its BKCAL_IN). The selected PID block behaves normally, and the deselected
controller never winds up. At steady state, the deselected PID block offsets its
OUT value from the selected value by the proportional term.
When the selected block becomes output-limited, it prevents the integral term
from winding further into the limited region. When the cascade between the
slave PID block and the control selector block is open, the open cascade status
is passed to the control selector block and through to the PID blocks supply-
ing input to it.
The control selector block and the upstream (master) PID blocks have an
actual mode of IMAN. In case of failure of the instrument connected to the AI
block, the AI block is placed in manual mode, and the output is set to some
nominal value for use in the integrator function block. In this case, IN at the
slave PID block is constant and prevents the integral term from increasing or
decreasing.
Figure 3-25. PID Function Block Diagram for Cascade Control with Override
Users can focus on purchasing the hardware of their choice without worrying
about the compatibility with their control host, regardless of field device com-
munication technology. A common FDI solution allows device vendors to
focus their efforts and resources on a single technology rather than on sup-
porting both FDT and EDDL. Suppliers can focus on improving the function-
ality of their products instead of supporting multiple technologies to make
their applications work across different systems. Fewer interoperability chal-
lenges reduce manufacturing costs and time to market.
4
Installation of
FOUNDATION Fieldbus
4.1 Topologies of a FOUNDATION Fieldbus Network

There are several possible topologies for fieldbus networks. This chapter illus-
trates some of these possible topologies and their characteristics. Note that the
power supplies and terminators are omitted from the diagrams for the sake of
simplicity. As shown in figure 4-1, the networks can be called point-to-point,
daisy chain, bus with spurs, or tree/chicken foot.
Point-to-Point Topology
This topology, shown in figure 4-2, consists of a segment having only two
devices. The segment could be entirely in the field (a slave and host device
operating independently), for example, a transmitter and valve with no con-
nection beyond the two, or it could be a field device (transmitter) connected to
a host system (doing control or monitoring). Simple point to point (host and
one device per bus segment) would probably not be used often, as it has only
one measurement or control device per segment (as in 4–20 mA). As a result, it
does not take advantage of the maximum devices per bus segment capability.
Bus with Spurs Topology

With this topology, as shown in figure 4-3, the fieldbus devices are connected
to the bus segment through a length of cable called a spur. A spur can vary in
length from 1 m to 120 m. A spur that is less than 1 m long is considered a
splice.
101
Figure 4-1. Topologies of Fieldbus Networks
Figure 4-2. Point-to-Point Topology

Chapter 4 – Installation of FOUNDATION Fieldbus 103
Figure 4-3. Bus with Spur Topology
Daisy Chain
With this topology, the fieldbus cable is routed from device to device on the
segment and is interconnected at the terminals of each fieldbus device. If
used, installations with this topology should use connectors or wiring prac-
tices such that disconnection of a single device is possible without disrupting
the continuity of the whole segment.
Tree Topology
With this topology (sometimes called chicken foot), as shown in figure 4-4,
devices on a single fieldbus segment are connected via individual twisted
wire pairs to a common junction box, terminal, marshalling panel, or I/O card.
This topology can be used at the end of a home run cable. It is practical if
devices on the same segment are well separated, but are in the general area of
the same junction box. When this topology is used, the maximum spur length
must be taken into consideration.
Figure 4-4. Tree Topology
Combinations of the Above

Combinations of the above must follow all the rules for the maximum seg-
ment length and include the length of spurs in the total length calculation.
Although probably unlikely, a combined topology could occur, as indicated in
figure 4-5.
4.2 H1 Bus Installation

The following summary gives a brief overview of the basic values and fea-
tures of the H1 bus. For more details, refer to the respective Application
Guides of the FOUNDATION Fieldbus (e.g., AG-140, AG-163).
The H1 bus specification is based on the IEC 61158-2 standard. Manchester

coding is used for data transfer. The data transfer rate is 31.25 Kbps. It is
Figure 4-5. Combinations of Topologies
important for field devices to have enough voltage—a minimum of 9 volts—

to ensure proper communication. Software tools that calculate the resulting
currents and terminal voltages based on the network topology, the line resis-
tance, and the supply voltage should be used to ensure that this requirement
is met.
The H1 bus allows the field devices to be powered over the bus. The power
supply unit is connected to the bus line in the same way (parallel) as a field
device. Field devices powered by supply sources other than the bus must be
additionally connected to their own supply sources. With the H1 bus, the
maximum power consumption of power-consuming devices must be lower
than the electric power supplied by the power supply unit.
Network topologies used are usually line or bus topology, or when equipped
with junction boxes, they are also a star, tree, or a combination of topologies as
given in figure 4-5. The devices are best connected via short spurs using tee
connectors to enable connection and disconnection of the devices without
interrupting communication.
The length of a spur is limited to 120 meters and depends on the number of
spurs used as well as the number of devices per spur (refer to table 4-1).
Without repeaters, a maximum bus length of 1900 meters of cable can be

achieved for an H1 segment. By using up to four repeaters, a maximum of
5*1900 meters = 9500 meters is possible. The short spurs from the field devices
to the bus are included in this total length calculation.
Table 4-1. Number of Devices per Spur in Combinations

One device Two devices Three devices Four devices
No. of devices
per spur per spur per spur per spur
25–32 1m 1m 1m 1m
19–24 30 m 1m 1m 1m
15–18 60 m 30 m 1m 1m
13–14 90 m 60 m 30 m 1m
1–2 120 m 90 m 60 m 30 m
The number of devices per bus segment is limited to 32 by the standard in

explosive/hazardous areas; power supply limitations bring this number down
to only a few devices.
Various types of cables are usable for fieldbus (table 4-2). Type A is recom-
mended as preferred fieldbus cable, and only this type is specified for the
maximum bus length of 1900 m. The FOUNDATION Fieldbus cable specification
FF-844 is equivalent to type “A” cable, and it is recommended that this cable
with the associated FF “checkmark” be used for all new installations.
Table 4-2. Cable Types in FOUNDATION Fieldbus Networks

Type A Type B Type C Type D
Cable description Shielded twisted Single or multi- Multi-twisted pair Multi-core, with-
pair twisted pair with without shield out twisted pairs,
an overall shield without shield
Size 0.8 mm2 0.32 mm2 0.13 mm2 1.25 mm2
(AWG 18) (AWG 22) (AWG 26) (AWG 16)
Maximum length 1900 m 1200 m 400 m 200 m
including spurs
There must be two terminators per bus segment, one at or near either end of a
transmission line. It is not imperative that bus cables be shielded; however, it
is recommended to prevent possible interferences and for best performance of
the system.
4.3 High-speed Ethernet

High-speed Ethernet (HSE) is based on standard Ethernet technology. The
required components are therefore widely used and are available at a low
cost. HSE runs at 100 Mbps and can be run not only on electrical lines with
copper cable, but also on optical fiber cables as well.
Ethernet operates by using random (not deterministic) Carrier Sense Multiple

Access (CSMA) bus access. This method can only be applied to a limited num-
ber of automation applications, because it requires real-time capability. The
extremely high transmission rate enables the bus to respond sufficiently fast
when the bus load is low and devices are few. With respect to process engi-
neering requirements, real-time requirements are met in any case. The
advances in the digital communication technologies overcome these
limitations.
Ethernet switches are used to reduce the bus load due to the many connected
devices or if several HSE partial networks are to be combined to create a
larger network (see figure 4-6). A switch reads the target address of the data
packets that must be forwarded and then passes the packets on to the associ-
ated partial network. This way, the bus load and the resulting bus access time
can be controlled to best adapt HSE to the respective requirements in indus-
trial communications.
Bridge to H1-HSE Coupling

A communications network that consists of an H1 bus and an HSE network
results in a topology as illustrated in figure 4-6.
Bridges (linking devices or interface devices) are required to connect the com-
paratively slow H1 segments to the HSE network, coupling components. A
bridge is used to connect the individual H1 buses to the high-speed Ethernet.
The various data transfer rates and data telegrams must be adapted and con-
verted, considering the direction of transmission. This way, powerful and
widely branched networks can be installed in larger plants.
Figure 4-6. H1 and HSE Bridging
4.4 Intrinsic Safety in FOUNDATION Fieldbus
Introduction
Intrinsically safe (IS) refers to instrumentation design methodologies used for
ensuring the safety of electrical equipment in hazardous areas. The materials
that are commonly considered hazardous include crude oil and its deriva-
tives, alcohols, natural and synthetic process gases, metal dusts, carbon dusts,
flour, starch, grain, and fiber. Precautionary measures are mandatory to
ensure that flammable atmospheres containing these materials will not be
ignited.
Ignition prevention can be achieved by enclosing the electrical equipment in a

heavy, robust flameproof/explosion-proof enclosure designed to contain any
explosion that could occur. This is done by not allowing the flammable atmo-
sphere to access the equipment using techniques such as sand and oil filling. It
may also be achieved by encapsulating the equipment in an epoxy resin or
pressurizing the equipment so that the flammable atmosphere cannot enter.
It is obvious that application of any of these techniques results in increased

equipment size and weight and does not allow work on the equipment when
any degree of hazard is present. Some of the techniques also make the equip-
ment completely impossible to service or repair.
IS takes a different approach—the flammable atmosphere is allowed to come

in contact with the electrical equipment without introducing a potential haz-
ard. Safety is achieved by limiting the power and current values that could
create sparks or cause surface heating as a result of their normal operating
conditions or electrical charge that could cause an ignition.
This is possible because the system (including both the IS apparatus in the
hazardous area and the associated apparatus directly connected to it) has been
designed to be incapable of causing ignition in that atmosphere, even with
faults applied either to it or to the interconnecting cables. The electrical energy
available in hazardous area circuits is restricted to a level such that any sparks
or hot surfaces that occur as a result of electrical faults are too weak to cause
ignition. This approach enables easier maintenance of the equipment (using
suitably approved test equipment) and allows adjustments to be carried out
during plant operation. Equipment can also be removed or replaced while the
system is operating.
IS can be applied only to low-voltage, low-power equipment (up to a few

watts), but is the best approach for instrumentation where its operational ben-
efits are significant. Unlike most of the alternatives mentioned, it is also a tech-
nique where there is a large degree of international standardization. This
makes it possible for the same equipment and systems to be certified and
installed in most areas of the world.
Hazardous areas are classified by the degree of hazard (area classification)

and the flammable materials that are present (gas group). Area classification
categorizes areas according to the probability that an explosive atmosphere is
present, and this informs whether or not a particular explosion protection
technique can be used.
There are two different systems in use for area classification. These are the
zone classification system, as defined by IEC 60079-10, and the division classi-
fication system, as recognized by the American and Canadian national electri-
cal codes. The European standards follow the IEC approach. In addition, zone
classifications are also recognized in the United States and Canada as an alter-
native to division classifications.
The two area classification systems are summarized in table 4-3.
Table 4-3. Classifications of the Areas

IEC and CENELEC NEC (USA and Canada)
Zone 0: Division 1:
Explosive gas-air mixture continuously Hazardous concentration of flammable gases
present, or present for long periods. or vapors—or combustible dusts in
suspension continuously, intermittently, or
Common understanding more than 1000 h/a periodically present under normal operating
conditions.
Zone 1:
Explosive gas-air mixture is likely to occur in
normal operation.
Common understanding: 10 to 1000 h/a

Zone 2: Division 2:
Explosive, gas-air mixture not likely to occur, Volatile flammable liquids or flammable gases
and if it occurs, it will exist only for a short present, but normally confined within closed
time. containers or systems from which they can
escape only under abnormal operating or fault
Common understanding: less than 10 h/a conditions.
The IEC standards define two classifications of IS systems, depending upon

the number of components and the number of faults per component (one or
two) while the equipment remains safe; the North American standards define
only a single category of equipment that is safe with up to two independent
faults introduced. The two equipment categories are summarized in table 4-4.
Table 4-4. Classification of the Equipment

IEC and CENELEC USA & Canada
Ex ia: One category only:
Explosion protection maintained with up to Safety maintained with up to two faults in com-
two faults in components upon which safety ponents upon which the safety depends. IS
depends. IS apparatus may be located in, and apparatus may be located in, and associated
associated apparatus may be connected into, apparatus may be connected into, Divisions 1
Zone 0, 1, and 2 hazardous areas. and 2 hazardous locations.
Ex ib:
Explosion protection maintained with up to
one fault in components upon which safety
depends. IS apparatus may be located in, and
associated apparatus may be connected into,
Zone 1 and 2 hazardous areas.
Gases and combustible atmospheres are classified according to the spark

energy needed to ignite them. All IS equipment is designed and certified as
being safe for a particular group of gases, although in practice most IS systems
are designed to be safe with all the gas groups normally encountered, while a
few employ more power in certain defined environments. Again there is a
different classification of gases between IEC and North America. Refer to
table 4-5.
Table 4-5. Classification of Gases

Flammable gases, vapors, and mists are Flammable gases, vapors, and mists, and ignit-
classified according to the spark energy able dusts, fibers, and flyings are classified
required to ignite the most easily ignitable according to the spark energy required to ignite
mixture with air. Apparatus is grouped the most easily ignitable mixture with air.
according to the gases that it may be used
with. Surface industries:
Class I, Group A: acetylene
Surface industries: Class I, Group B: hydrogen
Group IIC: acetylene Class I, Group C: ethylene
Group IIC: hydrogen Class I, Group D: propane
Group IIB: ethylene Class II, Group E: metal dust
Group IIA: propane Class II, Group F: carbon dust
dusts, metals, flour, starch, fibers, flyings, Class II, Group G: flour, starch, grain
grain Class III, fibers and flyings
Mining industry
Group I: methane Mining industry
Unclassified: methane
The temperature classification of a piece of hazardous area equipment is

defined by the highest surface temperature reached within any part of it when
a specified amount of power is supplied to it under the fault conditions (at an
ambient temperature of 40°C or as specified). Temperature classification is
common across all the regions of the world. There is no connection between
the spark energy required to ignite a gas mixture and its susceptibility to igni-
tion by a hot surface.
Ignition Curves
The energy required to ignite the most easily ignitable mixture of a given gas
with air is called the minimum ignition energy of that gas. The current
required to sustain the ignition varies with the voltage level in the circuit.
Curves of permitted voltage and current for each gas group in a purely resis-
tive circuit are published as ignition curves in each of the intrinsic safety stan-
dards. They result from experiments performed over several years, and the
results are agreed upon internationally.
Additional curves have to be applied in circuits containing inductance and/or

capacitance. The curves are applicable only to linear circuits (i.e., those in
which current limiting is achieved by means of a resistor), as shown in figure
4-7. In practice many installations have nonlinear circuits in wiring for voltage
and current limitation. In this case, the curves in the figure must not be used.
There are several possible ways to determine the permitted values of voltage
and current for a given circuit. The local certification authority provides the
accepted method of specifying the limited values.
These factors typically restrict the operating region to below about 25 V and
250 mA, as shown in figure 4-7. Capacitance is treated as a lumped parameter,
and its permitted value is reduced sharply with an increase in system voltage.
This proves to be a stronger defining effect than the reduction of permitted
inductance as the current increases. This is because the increased inductance
of a system is always accompanied by an increased series resistance, the pres-
ence of which reduces its effect. Any item of IS-associated apparatus normally
has maximum specified values for permitted capacitance, inductance, and the
inductance to resistance (L/R) ratio that may be safely connected to its IS
terminals.
Figure 4-7. Practical Operating Regions with Ignition Curves
Devices and barriers for intrinsically safe areas are designed such that the
energy released by an electrical fault is insufficient to cause ignition, even in a
single or double failure condition. This ignition point is a function of power,
determined by voltage and current.
The amount of current allowed on an intrinsically safe segment—as well as

segment voltage, choice of barriers, and device count on each barrier—
depends not only on the type of hazardous atmosphere in which the devices
are located, but also on which intrinsic safety model is used.
For fieldbus, there are four models or models with technology variants that
are available for practical use:
• Entity Model: The entity model assumes that electrical parameters that
represent the characteristics of the wires are all concentrated at the
point of fault. In this model, the wire is considered the source of stored
energy. This conservative approach leads to a maximum DC current of
83 mA permitted in the wire and a maximum voltage of 18.4 V.
• FISCO Model: The fieldbus intrinsically safe concept (FISCO) model

considers the electrical wiring parameters to be distributed along the
entire length of the wire. This reduces the energy available at a fault
and results in a maximum current of 110 mA. This model permits more
devices on a wire pair in a hazardous area.
• FNICO Model: The fieldbus nonincendive concept (FNICO) model is a

derivative of FISCO and is specifically intended for fieldbus
installations in Zone 2 and Division 2 hazardous areas. It takes
advantage of the relaxed design requirements for nonincendive
(energy-limited) circuits compared to those for intrinsic safety. FNICO
enjoys the same benefits as FISCO in terms of simple safety
documentation and the elimination of cable parameter calculations,
and it retains the ability to connect and disconnect the field wiring in
the hazardous area while under power and without the gas clearance
procedures. The FNICO standard has now been incorporated into the
FISCO standard as another category, so the term FNICO is no longer
used.
• High Power Trunk: The high power trunk (HPT) concept is a new
approach to hazardous and general-purpose area fieldbus applications.
Unlike the FISCO/FNICO concepts, HPT does not limit the energy on
the fieldbus trunk cable to intrinsically safe or nonincendive levels,
instead the energy on the spur connections to the instruments is
limited.
• These four models are discussed in detail below.
Entity Model
The IEC 60079-11 standard defines the entity model as a method of validating
an installation of intrinsically safe and associated apparatus using intrinsically
safe parameters. In addition to the devices’ parameters, the cable capacitance
and inductance are assumed to be concentrated at the point of fault and have
to be considered too. Simplifications for fieldbus are not considered in this
specification, and the planners have no other option than to accept the com-
plex and time-consuming calculation efforts required to validate an
installation.
The first initiative to broadly define standardized IS parameters for fieldbus

was started by the release of the FOUNDATION Fieldbus FF-816 Physical Layer
Profile. The initiative was based on the conservative entity model this docu-
ment recommended; however the maximum available power of 1.2 W contin-
ued to be a safety parameter of Uo=24 V, Io=250 mA, and Po = 1.2 W for
power supplies used for gas group IIC (group A, B) applications. Developing
entity-compliant fieldbus products by observing these values is a tough limi-

tation, which prevented reasonable or extensive use.
There are only a few power supplies conforming to the entity model available
today; applying the entity model to fieldbus in practical applications is rare.
Such power supplies typically provide 10–12 V and 70–100 mA, which is just
enough to operate two to three field devices per segment (gas group IIC). In
the end:
• Entity provides power for segments with up to three instruments.
• Entity requires a significant calculation effort to validate intrinsic

safety.
• The solution meant for Zone IIB offers more power; however such
solutions and products are not suitable for applications requiring a
group IIC environment.
These limitations prevented the conservative customer base from adopting

intrinsically safe fieldbus when it was evaluated for use in hazardous areas.
This restraint was intensified by the high initial cost of intrinsically safe tech-
nology in general. The very nature of the electrical design, including double
(Ex ib) or triple (Ex ia) redundant circuits for current limitation and constant
voltage, together with galvanic isolations, required high effort with a direct
effect on the customer’s expense. The technology is not competitive compared
to the cost of using traditional protection methods such as Ex e and Ex d and
nonincendive field wiring.
FISCO Model
The fieldbus intrinsically safe concept (FISCO) was developed to supply addi-
tional power to a fieldbus segment, while still keeping the energy levels too
low to cause an explosion.
Many process industries have rapidly adopted fieldbus technology over the
past several years, yet end users are unsatisfied with the traditional solutions
for hazardous location applications, claiming that they cannot enjoy the same
benefits in terms of power, cable length, and number of devices and segments
in hazardous location applications compared to general-purpose applications.
This is due to the energy limitation on the trunk.
When fieldbus technology was introduced, the standard solution for hazard-
ous area applications was the entity concept, with cabinet-mounted barriers
and power supplies. This solution barely supplied enough power for two or
three instruments per segment, and it was cumbersome to match the entity
parameters of the devices and the power source. End users voiced their con-
cerns, and manufacturers responded with another solution for intrinsically
safe segments: FISCO.
Developed by the Physikalisch-Technische Bundesanstalt (PTB) in Germany,

FISCO is based on its experiments to find a way to provide more power over a
fieldbus in a hazardous location. In 2002, the published IEC 60079-27 standard
described the FISCO model.
FISCO is based on the following conditions:
• The fieldbus must be based on the Manchester bus–powered physical

layer in accordance with IEC 61158-2 (FOUNDATION Fieldbus or
Profibus PA).
• Only one active source (a power conditioner) is permitted per segment.

All other components act as passive current sinks (instruments).
• The basic current consumption of a field device is at least 10 mA.
The following must be ensured for each device, as shown in table 4-6:
Table 4-6. Specified Values for FISCO

Parameters Gas Group 11B/Gas Group 11C
Uo 14-17, 5V
Io In accordance with IEC 60079.11, but not
exceeding 380 mA
Po In accordance with IEC 60079.11, but not

exceeding 5-32 W
Ui 17, 5 V min.
Ii 380 mA min.
Pi 5, 32 W min.
Cable Length, Trunk 1900 m max.
1000 m
Cable Length, Spur 30 m max.
Table 4-6. Specified Values for FISCO

Cable Length, Splice 1m max.
Loop Resistance R 15 to 150 ohms/km
Loop Inductance L 0,4.1 mH/km
Loop Capacitance C 80.200 nF/km
Internal Capacitance of Field Devices 5 nF max.
Internal Inductance of Field Devices 10 mH max.
Terminator 90-102 ohms

Max. Field Devices 32
Simplifying the safety analysis is one of the merits of the FISCO model com-
pared with the entity model. Where each item of apparatus in a FISCO system
complies with the requirements of IEC/TS 600079-27:2002, the safety docu-
mentation may simply be a list of separate items. It is not necessary to estab-
lish compatibility between the electrical parameters of each field device and
the source of power, or to calculate cable parameters. Apparatus that complies
with IEC/TS 60079-27:2002 may be identified by the FISCO name on its
marking.
An exception to this rule is for apparatus certified before IEC/TS 60079-27:2002

was published. Such apparatus may be marked suitable for FISCO systems or
“in accordance with the FISCO model (fieldbus) and with the values of Ui, Ii,
Ci, and Li.” To include this kind of apparatus in a FISCO system, it is impor-
tant to ensure the compatibility of its electrical parameters with those of other
parts of the system. For example, the values of Ui, Ii, and Pi for a field device
must be compatible with Uo, Io, and Po of the source of supply.
In the case of intrinsic safety systems, the operating voltage may be limited to
comply with the certification requirements. In this case, the power supply is
located within the safe area, and its output voltage is attenuated by a safety
barrier or by an equivalent component.
In each IS fieldbus segment, only one active device, normally the associated
apparatus, is allowed to provide the necessary power for the fieldbus system.
The allowed voltage V0 of the associated apparatus used to supply the net-
worked nodes is limited to a range of 14–24 VDC.
All other equipment connected to the bus cable must be passive, meaning that
the devices are not allowed to provide energy to the system except for a leak-
age current of 50 microamps for each connected device.
Figure 4-8. FISCO-based IS Installation of F OUNDATION Fieldbus
Fieldbus Nonincendive Concept

Fieldbus nonincendive concept (FNICO) is based on FISCO. Both of these are
covered in IEC standards 60079-27:2005. As discussed above, FISCO is based
on work that was done by PTB in Germany that showed the IS requirements
for fieldbus systems could be relaxed without compromising safety. This
allows more current and voltage (energy) to be on the fieldbus cables, as long
as the fieldbus segment complies with some benign requirements such as hav-
ing two terminators and certain segment and spur length limitations. The lat-
est version of the IEC 60079-27 standard has incorporated the FNICO concept
as FISCO Ex ic.
FNICO is a derivative of FISCO and is specifically intended for fieldbus instal-

lations in Zone 2 and Division 2 hazardous areas. It takes advantage of the
relaxed design requirements for nonincendive (energy-limited) circuits com-
pared with those for intrinsic safety. FNICO enjoys the same benefits as
FISCO in terms of simple safety documentation and the elimination of cable
parameter calculations, and it retains the ability to connect and disconnect the
field wiring in the hazardous area while under power and without the need to
follow gas clearance procedures.
A fieldbus segment using a FNICO power supply would be energy limited in

its entire length (trunk and spurs). The entire segment can be maintained
while it is powered without risking ignition.
FNICO (and FISCO) also benefit from reduced design and documentation
requirements as compared to an entity-based design.
Live Working
“Live working” indicates that the system can be worked on (maintained)
while it is still energized. This also presumes that no gas sniffing was done,
and no “hot work permit” was completed. Live working is only attempted on
systems that are energy limited and only where permitted by local electrical
codes (Canadian electrical codes do not allow live working).
Even where live working is allowed, it must be done with care. Most
disasters occur during maintenance operations. In addition, for Class 1 Divi-
sion 2 (Zone 2) requirements, FM Approvals (a certification agency), only
evaluates one cable at a time. Multiple cable faults are not necessarily consid-
ered during the certification process. For improved safety, live working
should be performed carefully and in a limited fashion (e.g., not during major
maintenance).
Energy-limited Fieldbus Topologies

There are two topologies used for energy-limited fieldbus segments. The first
is to use a FNICO fieldbus power supply to power the entire segment. In this
case, the entire segment is energy limited and may be live worked if needed.
This is the most convenient and straightforward, but has some limitations
compared to high power trunk, the second approach, which is discussed
below.
Figure 4-9 shows an example system using a FNICO power supply. Voltage
and current are limited at the FNICO power supply to a safe level for Division
2 (Zone 2). Both the trunk and the spurs may be worked on while energized
without the risk of ignition. Depending on the FNICO power supply selected,
current is limited to 320 mA for gas group C (IIB) or 180 mA for gas group AB
(IIC). Voltage is typically limited to less than 15 VDC. The trade-off for a com-
pletely energy-limited segment is the cable length and the number of devices.
In addition, the FNICO power supply is a single point of failure.
Figure 4-9. FNICO Installation
As stated earlier, one of the benefits of the FNICO model is a simplified

design. The design was based on the basic requirements for a fieldbus seg-
ment. This includes a host, power supply (in this case FNICO rated), cable,
two terminators (usually built into the supply and a wiring block), wiring
blocks, and fieldbus devices. The following list shows the specific
requirements:
• FNICO-rated fieldbus power supply

• Cable
• Loop resistance 15–150 ohms/km
• Loop Inductance 0.4–1.0 mH/km
• Capacitance 45–200 nF/km
• Maximum spur length 60 m
• Maximum total cable length 1 km (IIC), 5 km (IIB)
• Wiring blocks
• Must be certified Ex-NL (energy limited) or IS (FISCO)
• Fieldbus devices
• Must be certified Ex-NL (energy limited) or IS (entity or FISCO)
Limitations of FISCO and FNICO

For many market applications, the FISCO and FNICO models have simplified
the parameter comparison of an entity-approved system in Class I, Division 1
(FISCO), and Class I, Division 2 (FNICO) areas and have allowed more power
in these areas, but they have their limitations. Although FISCO/FNICO offers
some additional power compared to the entity concept, users have been
unsatisfied with the traditional solutions for fieldbus applications in hazard-
ous location applications, because they cannot enjoy the same benefits as
when using fieldbus in a general-purpose configuration.
Typical FISCO power conditioners available today supply 12.8 V and 100 mA
for Class I, Division 1, groups A-D. In a real-world application, this results in
four-to-eight devices per segment. This is still far below the capabilities of a
general-purpose fieldbus installation, where users can connect up to 16 instru-
ments per segment. The overall cable length is theoretically limited to 1,000 m;
spurs are limited to 60 m; and the current and voltage levels are still very low,
which results in significantly shorter cable runs than the theoretical
maximums.
FNICO is similar to FISCO from a function point of view, but is used in Class
I, Division 2 applications. The same basic rules apply for FNICO; the major
difference is that FNICO uses a lower safety factor for its electrical values. Due
to this lower safety factor, it is possible to supply more current into a Class I,
Division 2 hazardous location. Typical values for FNICO are 12.3 V at 215 mA.
Unlike most general-purpose power conditioners, FISCO and FNICO power

conditioners do not offer redundancy (other than a single supplier) or any
online physical layer diagnostics. End users end up with more hardware in
their control room cabinets, because several FISCO/FNICO power condition-
ers might have to be connected together to maximize the number of instru-
ments on a single segment. This represents additional wiring cost and
installation time, ultimately adding to the overall project cost.
Installing additional hardware in a centralized control room also goes against

distributed fieldbus architecture. One of the benefits of fieldbus technology is
that it allows users to distribute equipment into the field and away from the
control room, saving expensive control room real estate.
Almost all field devices are FISCO compliant, and now that FNICO is part of
the FISCO standard they can be used in these applications.
These shortcomings pose a significant problem in the modern fieldbus world

where the number of field instruments required in a system continues to
increase, and the links between the control system and the field instruments
continue to grow. Machine builders who install fieldbuses as part of their con-
trol systems often need more power on the wire to connect needed devices
and instruments than usually is available in hazardous environments.
High Power Trunk

An alternative method that gives engineers the power needed to fully load
fieldbus segments for general-purpose and hazardous areas is the high power
trunk (HPT) concept introduced earlier. It works for all fieldbus applications.
It simplifies segment design, minimizes the amount of hardware used, sup-
ports a distributed architecture, allows live maintenance (live working) on the
spurs, and offers state-of-the-art power redundancy and online advanced
physical layer diagnostics.
Typically, fieldbus users do not need energy limitation on the trunk, because
they do not perform live maintenance. They do not want to lose an entire seg-
ment due to a single short. Unlike the FISCO/FNICO concepts, the high power
trunk concept does not limit the energy on the fieldbus trunk cable to intrinsi-
cally safe or nonincendive levels; instead the energy on the spur connections
to the instruments is limited. This allows the maximum number of devices on
a segment while also maintaining maximum cable lengths.
Depending on the application, the protection (energy limitation) is done in the

field, inside the segment protector or fieldbus barrier. By not limiting the
energy on the trunk, the high power trunk concept offers the same advantages
seen in general-purpose applications to hazardous locations. Typical values
for a high power trunk solution are 30 V at 500 mA.
Fieldbus barriers and fieldbus segment protectors make it easy to apply the
high power trunk concept even in the most hazardous environments. Fieldbus
barriers are used in Class I, Division 1 applications and provide intrinsically
safe, short-circuit-protected spur connections for either entity-based or
FISCO-based instruments. High power trunk connections to the fieldbus bar-
rier can be galvanically isolated from the IS spur connections.
Fieldbus segment protectors can also be used in general-purpose, as well as

Class I, Division 2, applications. They work exclusively on the Physical Layer
Level, which makes them independent of the fieldbus protocol. Segment pro-
tectors are used as junction boxes to connect nonincendive and general-pur-
pose fieldbus devices to a fieldbus trunk. Segment protectors provide short-
circuit, energy-limited (nonincendive) outputs. When used in a Division 2/
nonincendive application, barriers can connect to either a nonincendive field
wiring apparatus or to IS-rated devices, enabling the end user to connect or
disconnect instruments under power.
Both fieldbus barriers and segment protectors are typically mounted in a Divi-
sion 2 area, where the high power trunk connections are made following Divi-
sion 2 wiring methods. Division 2 wiring methods include open cable tray
with power-limited tray cable/instrument tray cable (PLTC/ITC), such as a
standard Type A fieldbus cable, armored cable, or conduit. Many end users
are moving away from using conduit in Division 2 fieldbus installations due
to cost and adopting open cable tray in combination with PLTC/ITC cable.
Fieldbus barriers and segment protectors move the energy limitation out of
the control room cabinet and into the field by combining short circuit–pro-
tected junction boxes with a built-in barrier. This enables users to distribute
their fieldbus equipment around the plant, taking full advantage of fieldbus
technology.
Another benefit of the high power trunk concept is that it gives the end user
the freedom to choose any type of instrument entity, FISCO, or FNICO.
In addition to fieldbus barriers and segment protectors, a new generation of

fieldbus power conditioners with built-in redundancy and online physical
layer diagnostics capabilities is also available. End users can monitor and
detect online:
• Noise levels on a segment
• Voltage and current levels
• Ground faults
This gives users a better picture of what is actually happening on a given seg-
ment at all times. Physical Layer diagnostic information is also very useful
during start up, commissioning, and troubleshooting. These barriers with
diagnostics provide information as to whether the fieldbus Physical Layer
conditions are changing over time; users can take action before a segment
fails.
In the fieldbus-enabled network designs, isolated fieldbus power supply

(FPS), which may also be redundant, is used to feed the trunk of the segment.
The FPS limits the voltage and current, but not to a level that is safe for live
working. The field-wiring block contains current limiters or spur guards (SG)
on each of the spurs and typically limits the current to 60 mA. At this point
with the voltage being limited by the FPS and the current being limited by SG,
the energy on the spur is below a level that would cause ignition if shorted.
This makes the spurs “live workable.” The trunk, however, is rated nonarcing
and must not be worked without powering down or getting a gas clearance.
Because most work needs to go on at the device and most users frown on
working on a trunk while energized (since a mistake there could take all
devices offline), the high power trunk method is widely used. It provides the
benefits of redundant power, long cable length (the FPS can supply voltages
as high as 28 VDC), and a maximum device count (the FPS can supply 350–
500 mA or more). A typical example of such a system is shown in figures 4-10
and 4-11.
The high power trunk concept allows fieldbus users to design segments that
are free of any power restriction. In fact, the only limitations are the control
system or the fieldbus specification. Now, engineers can enjoy the same bene-
fits in terms of power, cable length, and number of devices per segment in
hazardous location applications as they do in general-purpose applications.
Figure 4-10. High Power Trunks in Zone 1
The design requirements for a high powered trunk fieldbus segment are more
complicated and need additional effort. However, some feel the benefits out-
weigh the extra complications. Below are most of the requirements:
• Isolated fieldbus power supply
– May be redundant
– Current only limited by the trunk cable and wiring block ratings
– Division 2, Zone 2 rated maximum output voltage
• Trunk
– Design for nonarcing method of protection

Figure 4-11. High Power Trunks in Zone 2
– Any fieldbus-compatible cable will work
• Wiring blocks
– Must be certified and rated for energy limited spurs (entity

parameters)
– Certified input voltage rating must not be exceeded by the FPS

output rating
• Fieldbus devices
– FB terminals must be Ex nL, IS (entity), or IS (FISCO) certified (have

safety parameters)
– Certified voltage rating (V max) must not be exceeded by the FB

power supply
• Safety calculations
– Perform and document safety of each spur. Includes parameters

from wiring block, spur cable, and FB device.
– Because each FB has unique electrical characteristics, the calculation

tool to design the network must be the one provided by the
manufacturer being purchased or installed.
Table 4-7 provides a generalized performance summary of each of method.

There is much research underway to improve overall network safety at high
energy levels. Real-time performance measures of each of these models are
provided in table 4-8. More information can be gathered from specifications
and vendors, and this information must not be used for design purposes.
Some of these numbers are meant for illustration only.
Table 4-7. General Performance Summaries

(Key: + positive; - negative; -- very negative)
High Power
Entity FISCO
Trunk
Available Power -- 0 +
Validation of Explosion Protection - + +
Power Supply Redundancy - - +
Long-term Physical Layer Diagnostics - - +
Segment Design Mix - - +
Cabinet Space Requirements -- -- +
Power Supply Initial Cost -- -- 0
Trunk Live working + + --
Table 4-8. Values Calculated for Real-Life Application

FISCO High
Performance Indicator Entity Power DART
IIC IIB Trunk
Maximum output voltage 10.9 V 14 V 14.8 V 30 V 24 V

Output voltage under load 10.6 V 12.4 V 13.1 V 28.5 V 22 V
Maximum output current 100 mA 120 mA 265 mA 500 mA 360 mA
Effectively available current 55 mA 66 mA 177 mA 360 mA 248 mA
Real-life trunk length 180 m 570 m 290 m 670 m 670 m
Theoretical trunk length 1900 m 1000 m 1900 m 1900 m 1000 m
Real-life spur length 30 m 60 m 60 m 100 m 100 m
Theoretical spur length 120 m 60 m 60 m 120 m 120 m
Maximum number of field 2 4 8 12 12
devices
FOUNDATION Fieldbus Physical Layer Monitoring and Diagnostics

Several monitoring and diagnostics tools have been introduced in the market
in response to the criticality of the Physical Layer in the use of fieldbus tech-
nology. Some of these tools are permanently attached to the segment or bus,
and some of them are portable devices with the option to connect them when
needed. The tools typically measure the following parameters in a bus:
• Voltage per segment
• Segment noise
• Maximum fieldbus signal (communications) level
• Minimum fieldbus signal (communications) level
• Unbalanced to negative signal
• Unbalanced to positive signal
• Low resistance between shield and negative signal pole
• Low resistance between shield and positive signal pole
• Optional measurement includes:
• Fieldbus jitter on the segment
• Communication packet count
• Communication packet errors
If the online diagnostics tool is permanently installed as part of the FOUNDA-

TION Fieldbus power supply, additional information can be available such as:
• Minimum, maximum, and real-time bulk voltage supply to the

FOUNDATION Fieldbus supply voltage
• FOUNDATION Fieldbus power supply operational status
• Minimum, maximum, and real-time FOUNDATION Fieldbus current
The benefits of permanently installed diagnostics tools include the ability to

historize the data and provide real-time alarming and trending of the data.
Portable diagnostics tools assist in troubleshooting specific problems and may
present additional data not available with permanent diagnostics tools. Per-
manently installed diagnostics tools must only be considered if they are well
integrated with the host system. Table 4-9 shows some valuable tools used in
different diagnostics applications:
Table 4-9. Comparison of Various Diagnostic Tools

Hand- Advanced
Multi- Hand-held Bus
Measurements held Oscilloscope diagnostics
meter communicator analyzer
tester modules
Segment Voltage     x 
Segment Current  x x x x 
Segment Noise x    x 
(Low freq.)
Segment Noise x x x  x 
(High freq.)
Segment Signal Level x    x 
Instrument Signal Jitter x  x x x 
Instrument Signal Level x  x x x 
Instrument Signal Jitter x x x x x 
Instrument Noise x x x x x 
(Individual)
Fieldbus Termination x    x 
Segment Ground Fault x x x x x 
(Imbalance)
Device Communication x x  x  
Communication Fault x x x x  
Cable Degradation x x x x x 
(Trending)
Device Configuration x x  x  x
Remote Access x x x x x 
4.5 Wiring, Grounding and Shielding
Wiring Practices in FF
In the traditional analog transmission world of industrial automation, a pair
of wires usually carries a process variable in the form of current or voltage.
The electrical signal from the field has to be wired in a point-to-point mode for
all the transmitters/field devices to the host system in the control rooms. In the
digital communication world, a pair of wires can be a bus and carry multiple
parameters and information over the same cable. In FOUNDATION Fieldbus, as
discussed earlier, the pair of wires used for connecting the intelligent field
devices is called the H1 network, and the bandwidth for the same is
31.25 Kbps.
From an installation standpoint, let us compare the FF installation and con-

nections with the traditional 4–20 mA connections. Refer to figure 4-12 for the
traditional transmitter connections to the host systems/control systems over a
pair of wires.
Figure 4-12. 4–20 mA Current Loop Connection
Refer to figure 4-13 for the wiring of a FF device. In this case, the control sys-
tem is replaced with an interface module in the control system that acts like a
gateway or bus module. The traditional field device connects to the interface
module over the same pair of cables. In addition, there are terminators at the
interface module side and the device end. Sometimes, the terminator at the
interface module end might be an integrated component inside the module,
and hence there may be no need for any additional external terminators.
Now let us refer to figure 4-14 for the same bus network with additional
devices added. In this case, the devices are added to the same bus in a star or
daisy-chain form. There is no additional cable required and no additional
interface modules. It has to be noted that because each network requires two
terminators, there is no additional terminator as well, but rather the termina-
tor is relocated to within 120 meters of the final field device.
Figure 4-13. Simple FF Network
Figure 4-14. F OUNDATION Fieldbus Network with Additional Devices Added

OUNDATION Fieldbus
Now let us try to understand terminators (their purpose, etc.). Terminators

are like a resistor capacitor (RC) circuit and prevent distortion and signal loss.
Simply put, terminators are impedance-matching modules used at or near
each end of the transmission line. In general, only two terminators are used in
one trunk/segment. Refer to figure 4-15 for the terminator connections.
Figure 4-15. Terminators in F OUNDATION Fieldbus Network
The rule for locating terminators is one that may be bent. The right-hand ter-
minator, shown in figure 4-16, is located at the junction box. In theory it
should have been placed at the field device with the longest spur, but nor-
mally it is placed within the maximum spur length limits defined in the stan-
dards. Had one spur been significantly longer, then the terminator should
have been placed along that spur, thus effectively extending the trunk to the
new terminator location.
Before getting deeper into the installation concepts of FOUNDATION Fieldbus,

let us understand the definitions of certain terminology, such as trunks, spurs,
and bridges. A trunk is the longest cable path between any two devices on the
network. Once this cable stretch is identified, all the other connections to it are
called spurs. The rule of thumb is that terminators are typically installed at the
Figure 4-16. Terminators in Network
two ends of the trunks. In general, the terminators are placed at the junction of
the group of field devices.
Generally speaking, shorter spurs are better. The total spur length in a seg-
ment is fixed, and therefore, the longer the spur length, the lower the number
of spurs. A spur can be up to 120 m in length if there are few of them. If there
are 32 spurs, they should be 1 m or less. Because FF is wired in parallel, the
typical wiring, if done using conventional terminal blocks, resembles
figure 4-17.
Table 4-2 gives the different cables and their sizes as well as the restrictions in
terms of the maximum length of all the cable in the network segment. This
information provides the constraints that need to be considered while design-
ing the network. It is not always the case that the same cable will be used for
the entire segment, and it is possible to use a hybrid approach with mixed
cables as well. Figure 4-18 shows a classic example of wiring needs and types.
Shielding and Grounding

Grounding is essential for the safety of the equipment and people for any
installation. Grounding removes the stray voltage from natural and man-
made sources, such as electrostatic, lightning, ground faults, and welding.
Figure 4-17. Typical Wire Interconnection
Grounding must usually be <1 V except for voltages more than 5 kV. All the
equipment in the plants must have safe grounding designs.
In general all grounds are electrically noisy due to lightning, welding, cathode
protection, electric heating, high voltage power transmission, electric motors
with variable speed drives, and radio frequency interference. Most of the
ground noise is wide band in nature. Ground has high impedance for noise at
high frequency and long distance.
Shielding is meant for isolation. Shielding reduces the noise effect on signal
circuits. Shielding is effective if it is used in combination with insulation, bal-
anced line impedance, twisting, and line termination. Table 4-10 indicates the
different shield types and their impact on noise reduction.
The fieldbus system is highly susceptible to electrical noise that may be

induced by electromagnetic/electrostatic induction from radio waves or
ground potential differences. The proper signal grounding design and con-
struction methods are to be provided to prevent influence from any electrical
noise. This helps to maintain required fieldbus communication signal quality
on an H1 segment.
Figure 4-18. Wiring Interconnections of a Segment
Table 4-10. Shields and Noise Reductions

Installation/Shield Type Noise Reduction
No shield (open parallel wire) 0 db
Twisted pair balanced line with Mylar foil >10 db (depends on frequency and impedance
shield and drain wire tray match)
Above with braided copper shield 3 db better than foil
Nonferrous metallic conduit 6 db better than foil shield and drain wire tray
Ferrous metallic conduit 6 db better than nonferrous conduit
All fieldbus signal cores must be used differentially throughout the network,
as grounding either conductor could cause all fieldbus devices on that H1 seg-
ment to lose communication for the period that the conductor is grounded.
Typically the instrument shields of multipair trunk cable are terminated and
grounded at the DCS end of the H1 segment in the marshalling cabinet and
are not connected to ground at any other place.
The instrument shields of single-pair trunk cables are connected to the instru-
ment shield of a multipair trunk cable at the intermediate FOUNDATION Field-
bus junction box (JB).
The spur cable shields are connected to the trunk cable shield at the wiring
block inside the FF Spur JB and left unconnected at the fieldbus device. The
shields should be covered with heat shrink/tubing to avoid the possibility of
inadvertent grounding.
No connection may be made between the trunk or spur cable shields and the
fieldbus junction box. Safety (case) ground of FF devices, intermediate FF
junction boxes, and FF spur JBs are made at each component.
Fieldbus cable shields from different networks segments must not be con-
nected.
A spare pair from an intermediate junction box to the marshalling cabinet is

terminated in spare terminal box TB’s and is further connected to the panel
instrument shield bus bar. Refer to figure 4-19 for the grounding connections
in the JB side.
Figure 4-19. Grounding at JB Side

The network cable should be shielded to provide maximum immunity from

noise, but alternately, it may be placed inside a metal conduit. The shield must
cover at least 90 percent of the total wire length. Because plants are typically
large and widely distributed geographically, ground potential differences
usually exist. Therefore, the cable shield must only be grounded in one end,
usually at the negative of the power supply. In some cases, the shield can also
be connected to the protective earth (ground connection).
Specific grounding requirements may apply for intrinsic safety installations.
If multiple grounds are required in an excessively noisy environment, capaci-

tive grounding should be used. Capacitive grounding means that the connec-
tion to the ground is made through a capacitor rather than a wire, thus only
high frequencies are grounded. The shields of the spurs should be connected
to the shield of the trunk.
Because only the shield should be connected to the ground, signal wires must
not be connected to ground, and shield must never be used as a conductor. All
fieldbus devices have communication ports that are galvanically isolated.
The DC main power supply is normally separate from the power supply
impedance module. In this case, the negative of the DC power supply can also
be connected to ground if the design of the impedance permits.
Grounding either signal conductor may result in the loss of communications,

and in addition to the operations requirements, there may also be safety con-
siderations. The negative of the power supply impedance is a signal, and it
should not be connected to ground. Ideally the network power supply should
be modular with separate DC power and impedance units to help in main-
taining the single point of failure. The shield can then be grounded at the
power supply negative, while at the same time the output of the power sup-
ply impedance is free floating in a balanced mode; that is, the power supply
impedance must be balanced or galvanically isolated. Refer to figure 4-20.
If there is an unbalanced signal line, it can cause noise problems. This imbal-
ance converts common mode noise to differential mode signal noise. To avoid
this, the impedance to ground should be high and balanced, and signal line
impedance should be low and balanced.
Figure 4-20. Power Supply Grounding
Similarly if there are multiple grounds on a shield, the system experiences

current conduction in close proximity to signal conductors, which decreases
isolation and increases common mode noise. This situation often leads to an
increase in error rates on digital communications and does not cancel or
reduce the noise in balanced lines.
Refer to figure 4-21, figure 4-22, and figure 4-23 for various grounding options
available and acceptable to these networks.
The most typical and frequently best option to provide signal isolation for a
FOUNDATION Fieldbus H1 network from external influences, such as EMI/RFI,
is the star, tree or chicken foot topology with a single shielded ground. Typi-
cally, these topologies are connected at one end to the Master Ground at the
Host system using twisted-pair tray cable with Mylar foil (Type A cable). Fol-
lowing these guidelines provides almost zero errors in most environments.
Using a ‘floating’ FF Power supply also further helps reduce potential noise
problems.
Figure 4-21. Single Point Grounding
Figure 4-22. Alternative Single Point Ground

Figure 4-23. Multipoint Grounding
Power Supply Concepts

The majority of the field devices draw power from the bus network, which is
similar to the way they draw in analog field devices, such as a 4–20 mA com-
munications. The power supply device becomes a device similar to any partic-
ipating device, such as field devices or the communications devices of a
network. Refer to figure 4-24 for the network with the devices and power sup-
ply connected. Power supplies are specially designed for the FOUNDATION
Fieldbus network, and some vendors offer a built-in power supply to the
interface module. Any commercial, off-the-shelf power supply cannot be
used, as some of them may damage the network and can also damp the H1
signal. FF power supplies should have the FF certification “check mark” as
being compliant with standard FF-831.
There must be enough voltage to operate if two wire field devices are in the
network. Each device needs at least 9 volts to operate. Below are some impor-
tant points to consider:
• The current consumption of each device
• The location on the network
• The location of the power supply on the network
• The resistance of each cable section

Figure 4-24. Power Supply Connected to F OUNDATION Fieldbus Network
• The power supply voltage
A DC circuit analysis can provide a theoretical basis for an acceptable design

for the power supplies in the FOUNDATION Fieldbus networks.
5
Engineering
Considerations
5.1 Engineering Selection
Selection of the Distributed Control System

The successful implementation of FOUNDATION Fieldbus technology is highly
dependent on the appropriate selection of the distributed control system
(DCS). The various DCSs reflect different levels of FOUNDATION Fieldbus
development. FOUNDATION Fieldbus provides a conformance for a host sys-
tem and provides host interoperability support testing (HIST). However, the
use of HIST does not guarantee the required FOUNDATION Fieldbus perfor-
mance. End users must ensure the use of host systems approved for FOUNDA-
TION Fieldbus applications, as listed in the owner-approved vendor list. The
status of and the approved release information on DCS testing can be
obtained from the owner or managing contractor if the system is new or
revamped.
The DCS consists of the manufacturer’s standard hardware, systems, soft-

ware, and firmware that can be configured to meet the stated requirements.
Application software must be designed in a manner that requires no modifica-
tion to the system operating software. Software design must be such that
future revisions or updates of the system operating software do not affect the
successful operation of the system.
143
The DCS H1 network topology and settings must comply with the recom-
mended FOUNDATION Fieldbus practices to enable communication with all
targeted FOUNDATION Fieldbus devices.
Most DCSs have the following minimum FF functionality:
• automatic node addressing
• interoperability with any FF device in the network
• direct configuration of devices
• direct integration of FOUNDATION Fieldbus device operating,

maintenance, and diagnostic data
• tuning parameters, modes, alarms, and quality of data
• configurable field devices while the host system is operating, without

shutting down the network
• host system that enables new field devices to be added to an existing

network/segment (i.e., device tag/placeholder) and fully configured
without commissioning and start-up delays
The host system enables field device firmware to be updated without shutting
down or impacting the publish/subscribe cycle of that H1 segment. Uses only
standard FOUNDATION Fieldbus Device Description (DD) and Common File
Format (CFF) files or in some cases a library of standard DD and CFF files or
dedicated vendor files which are preinstalled (e.g., DTM files).
• supports the instantiation of function blocks in FF devices
• supports host profile registration to Class 61b or later
The DCS database holds all the FOUNDATION Fieldbus device parameters. This
is maintained as the master database. No other configuration tools may be
used that will bypass the DCS database. Integrated asset management pack-
ages can be used to handle the diagnostic information enabled by the FF
devices.
Spare Capacity
Note: These engineering guidelines are general practices followed in the indus-
tries using process control and automation. The following guidelines are
Chapter 5 – Engineering Considerations 145
the preferences of some users experienced in this technology. Readers are

encouraged to refer to the standards for base information.
Every project must include the preparation of a project-specific design specifi-

cation. This design specification will serve as the basis for the number of
devices per segment; voltage drop calculations should include spare capacity
for future expansion.
Spare capacity for a segment is calculated based upon the two conditions
given here, with the largest number of spare devices to be used for sizing.
Generally most users prefer to limit the maximum number of devices on any
segment (including future devices) to 12, as it still leaves additional capacity
upon project completion for future system growth.
Minimum spare capacity can be defined as 20 percent. Therefore, if the maxi-

mum number of field devices per segment for a project is 12, taking into
account spare capacity for future expansion, the maximum number of devices
to be installed in a segment must be 10 at the start of the project. This also has
to take care of the future addition of one control loop (i.e., one transmitter and
one final element). Therefore, each segment can be designed for a minimum of
two future devices.
For 20 percent spare capacity, additional current capacity must also be consid-
ered for future expansion. In addition, the segment macrocycle must be
designed for future device allowances as described in earlier chapters. That is,
the macrocycle should allow one transmitter to be added (analog input [AI])
and one valve positioner (final element) to be added (analog output [AO]) and
still ensure that the minimum free time of 50 percent is met. This is based on a
macrocycle with a default duration of one second. For fast loops, a different
macrocycle should be selected based on the needs of the process.
In all spare capacity calculations, the impact on the power requirements,

design of the field junction box, segment bandwidth constraints, etc., must be
considered and sized (i.e., the space, power, junction boxes) to allow for the
current and future number of devices per segment. The following are some of
the guidelines used during segment design and engineering:
• A critical loop from the process has to be distributed among different

segments to avoid risk of failure of more than one control loop on the
failure of any hardware in the system.
• Client/server communication time is also important. Engineering

should take care to not use more than 55 percent of macrocycle time for
unscheduled events and communications.
• In general, segment validations are left to the DCS supplier to perform

per the project functional design guidelines and other guidelines from
the users.
In large projects, it is advisable to include an additional maintenance station

other than the engineering station to perform all the additional FF configura-
tion, commissioning, and life-cycle activities. In the case of the common con-
trol room philosophy, this station can serve multiple units.
Selection of Devices
All selected FOUNDATION Fieldbus devices must comply with the require-
ments of the FOUNDATION Fieldbus specifications and be approved by the
Fieldbus Foundation. The Fieldbus Foundation issues a “check mark” logo on
such devices, which verifies interoperability. Project engineering should
ensure that all the FOUNDATION Fieldbus devices are certified as passing the
Interoperability Test Kit (ITK) 6.0 or later and include DD and CFF files.
It is important for system users to ensure that FOUNDATION Fieldbus devices

used in the project and the function blocks used within those devices are type
tested (HIST) by the DCS supplier.
The Fieldbus Foundation website lists all devices approved by and registered
with the Fieldbus Foundation. All devices have to be compliant with the latest
version of the FOUNDATION Fieldbus ITK.
Instrument data sheets must have the following line items (at minimum) spec-
ified by the vendor:
• Link active scheduler (LAS) capable (yes/no)
• Minimum operating voltage (VDC)
• Quiescent current draw (mA)
• DD revision
• Function blocks required

Device Support Files

FOUNDATION Fieldbus devices have three support files—FFO, SYM, and
CFF—which contain information necessary to configure the host systems.
Device support files can be obtained for each FOUNDATION Fieldbus device.
The support files include two Device Description files and one capability file,
as defined in FOUNDATION Fieldbus specification FF-940. The capability file
and the DD files are provided by the device vendor.
Users have to maintain proper records with regard to device and DD versions.
The DD file provides an extended description of each object in the virtual field
device (VFD). The DD file can be thought of as a “driver” for the device. The
DD file provides information needed for the HOST to understand the mean-
ing of the data in the VFD.
Device suppliers may also provide device type manager (DTM) files for their
devices and must develop these from the DD file when they are not available.
The DTM files are compatible with the host system using FDT/DTM technol-
ogy. Host systems also support Electronic Device Description (EDD) and/or
Field Device Integration (FDI). The overall aim is to ensure that the host sys-
tem and associated asset management system are equipped with the full func-
tionality of the device diagnostic and configuration capability.
Device Power Requirements

Most FOUNDATION Fieldbus devices can be powered directly from the
fieldbus. The DC supply voltage can range from 9–32 VDC. The transmitting
device delivers ±10 mA at 31.25 Kbps into a 50-ohm equivalent load to
create a 1.0-volt peak-to-peak voltage modulated on top of the DC supply
voltage.
Loss of power or disturbance to one power supply module must not result in
the reset of a field device under any circumstances, and hence the project engi-
neering has to ensure the fail conditions of each of these devices.
Device Parameter Settings

To optimize commissioning time, each fieldbus device is preconfigured by the
manufacturer with the following parameters, as indicated on the instrument
datasheet:
• Physical device tag (PD_Tag)

• Device class set to basic for all devices
• Channel setting where indicated on the datasheet
Advance Diagnostics
Field devices enabled with FOUNDATION Fieldbus technology provide infor-
mation for diagnostic purposes. The diagnostics of the following are being
made available in the system to help with diagnosing problems. Project engi-
neering has to ensure that the following diagnostics are considered in the
design:
• Device diagnostics
• Physical Layer diagnostics
• Network diagnostics
• Diagnostics at minimum includes:
– Power supply status
– Fieldbus segment voltage
– Noise in the low/fieldbus/high frequency
– Shield wiring shorting
– Communication signal amplitude for each device
– Self-monitoring and diagnosis of field devices in accordance with

NAMUR NE107
5.2 H1 Segment Design
Network Topology
Several FOUNDATION Fieldbus topologies are possible; use of each of the
topologies is specific to the project, and hence no specific guidelines are
required. Most of the installations use a hybrid approach.
Cabling Design
The FOUNDATION Fieldbus can be implemented using multipair trunk cables
from marshalling cabinets to intermediate junction boxes located within the
various plant areas. This method reduces the number of FOUNDATION Field-
bus cables entering the control rooms, with associated cost savings. All multi-
pair trunk cables contain only FOUNDATION Fieldbus signals. Each segment
from an intermediate junction box (JB) typically uses multipair cable for the
trunk (H1) to the FOUNDATION Fieldbus junction boxes. The multipair cable
runs between the intermediate FF JB and marshalling cabinets. A single-pair
cable runs between the intermediate FF JB and the FF spur JB.
The FOUNDATION Fieldbus spur junction boxes are of a split design, with the
high power trunk (non-IS) on one side and the FF barriers and associated
surge protection and/or terminals (IS) for the hazardous area on the other side.
For nonhazardous areas, FF barriers and the above JB configuration are not
required. For nonhazardous areas, a wiring hub compliant with the FF-846
field device coupler can be used. The wiring hub provides individual device
(spur) isolation; a fault in one device will not affect the segment. Spur junction
boxes are available in various configurations. To optimize the segment design
the main preference is to use three or four-channel (i.e., 75 percent or 25 per-
cent spare) field barrier spurs.
Cable Types
All H1 spur cables can be “Type A,” as specified in IEC 61158-2, that is, single
twisted pair with an overall shield. Type A also complies with FF-844 (H1
cable test specification). All H1 trunk cables can be multiple twisted pair, with
individual and overall shields.
All H1 trunk cables must meet the electrical parameters for Type A cables
specified in IEC 61158-2. The maximum allowable total cable length (trunk
plus all spurs) of a FOUNDATION Fieldbus segment should not exceed 1,900 m
for a project. Some users limit the maximum allowable trunk length to 1,000 m
or 1,200 m.
The maximum allowable spur length according to field barrier design is 120
m. Some users further limit spur length to no greater than 90 m or, if possible
60 m, to remain compliant with FISCO requirements.
Cable Sizes
All H1 spur cable should be 1 mm2 intrinsically safe single-pair cable to field
instruments and two-pair 1 mm2 IS to temperature multiplexer (MUX) JBs, as
they contain two MUX devices. H1 trunk cable is by default 1.5 mm2 non-IS
for trunk lengths of up to 1,000 m.
Grounding, Shields, and Polarity

Grounding and shielding were discussed in an earlier chapter. The following
are some of the considerations for project engineering.
Fieldbus systems are highly susceptible to electrical noise. The proper signal
grounding design and construction methods are provided to prevent influ-
ence from any electrical noise. This helps to maintain the required fieldbus
communication signal quality on an H1 segment.
All fieldbus signal cores are preserved differentially throughout the network,
as grounding either conductor would cause all fieldbus devices on that H1
segment to lose communications for the period that the conductor is
grounded.
The instrument shields of multipair trunk cable are terminated and grounded
at the DCS end of the H1 segment in the marshalling cabinet and are not con-
nected to ground at any other place. The instrument shield of single-pair
trunk cables is connected to the instrument shield of multipair trunk cable at
the intermediate FOUNDATION Fieldbus junction box.
The spur cable shields are connected to the trunk cable shield at the wiring
block inside the FF spur JB and are left unconnected at the fieldbus device.
The shields should be covered by heat shrink tubing or by a sleeve to avoid
any possibility of inadvertent grounding. For reference, see figures 5-1 and 5-2
for various wiring concepts.
The trunk or spur cable shields and the fieldbus junction box are not con-
nected. Safety (case) ground of FF devices, intermediate FF junction boxes,
and FF spur junction boxes is made at each component. Fieldbus cable shields
from different network segments are not connected.
Terminators
Terminators must be provided at both ends of an FF segment. The field termi-
nator can be installed in the FF spur junction box at the farthest end of the
trunk. No terminators can be installed in the FF device (due to the impact on
the whole segment should the device need replacement). The terminator at
Figure 5-1. Wiring Arrangement
Figure 5-2. Wiring Concepts of an FF-based System

the DCS side is incorporated into the FOUNDATION Fieldbus power supply
(FFPS) and enabled using a jumper or DIP switch.
Installing an end terminator in an unused or spare segment of H1 card on

some host systems is discouraged. An unused or spare segment needs to be
able to be individually powered on or off depending on its usage.
Note: Terminators prevent reflections at the ends of the FF cable. These “reflec-
tions” are a form of noise that distorts the signal. Some suppliers provide
barriers with built-in terminators, activated using a DIP switch. These
terminators are kept off to avoid signal strength attenuation.
Redundant FOUNDATION Fieldbus H1-Interface Cards

It is recommended that because of the risk associated with the loss of so many
devices in the event of the failure of a single H1 interface card that redundant
FOUNDATION Fieldbus interface (RFFI) cards be used on all segments. The pri-
mary LAS resides in the primary FFI card. The backup LAS resides in a sec-
ondary FFI card. The FFI manages the communication schedule of the
fieldbus. The H1 FFI cards can have two or four channels to drive two or four
segments, respectively. There are suppliers who can supply H1 FFI cards with
eight channels, and these designs can bring down the cost of implementation.
DCS systems exhibit bumpless changeover between primary and secondary
cards in case of fault.
Segment Power Supplies/Power Conditioners

A FFPS is required for each FF segment. This is normally mounted within the
I/O rack cabinets where the FOUNDATION Fieldbus interface cards reside. Each
FFPS has redundant power conditioners, current-limited outputs to the FF
trunks, and optional surge protection for each trunk. Each FFPS is supplied
from redundant feeds from the bulk power supplies.
The FFPS are fully “hot swappable.” Individual power conditioners and input
power supplies can be replaced without interrupting power or communica-
tion on the fieldbus segment.
Failure or trouble alarms of the FFPS have to be annunciated in the DCS.

Common alarms include:
• Low FFPS input voltage

• Low FFPS output voltage
• FF segment shorted
The FFPS should incorporate an online advanced diagnostics module for

monitoring and displaying segment physical parameters, network diagnos-
tics, and device diagnostics. Several permanently attached and portable
device options for online diagnostic tools are also available.
Surge Protection
Because of the risk of damage resulting from the large voltage transients aris-
ing across the length of a trunk cable, it is recommended that all trunks must
have surge protection at both ends (i.e., in the marshalling cabinet and the FF
spur junction box). In areas with a high susceptibility to lightning strikes, such
as tank farms, columns, and jetties, and areas where instrumentation is not
significantly shielded by the plant steelwork and pipe racks, surge protection
for every instrument is important. This is achieved by installing surge protec-
tors on each susceptible field device. Surge protectors are grounded to the
local protective ground.
Bulk Power Supply

Dual-redundant 24-VDC bulk power supplies installed in each FF cabinet pro-
vide power to each FFPS. Two separate, independent power circuits supply
power. The redundant bulk supply is fed from redundant uninterrupted
power supply (UPS) power sources.
5.3 Hazardous Area Design

As discussed in section 4.4, all field instruments having electrical or electronic
connections to be installed in a defined hazardous area must be certified
intrinsically safe FISCO.
Lately, some projects are using high power trunk “hybrid” concept, another
method of IS protection. This method uses the increased safety (Ex e) concept
of protection for the fieldbus trunk and has the benefit of delivering a higher
level of current to the fieldbus segment than is possible with intrinsic safety.
Intrinsically safe spurs are generated by using a field-mounted fieldbus bar-

rier to limit the power, voltage, and current available to the field device. This
type of implementation allows full access to the field devices when they are
energized inside the hazardous area. This solution is achieved with enclosures
that provide a bus-powered fieldbus barrier with no requirement for an exter-
nal power source through the use of special “live-disconnect” terminals, mak-
ing fieldbus barriers replaceable while they are energized in a hazardous area.
The spurs are galvanically isolated from the trunk and from each other, have
spur short circuit protection, and do not require a protective ground in the
field.
Nonhazardous Area (Safe Area) Design

For nonhazardous areas, FF barriers and split JB configuration is not required.
A wiring hub like Mega Block is used in nonhazardous areas. A wiring hub
provides individual device (spur) isolation, and a fault in one device does not
affect the segment.
Risk Management and Segment Design

Risk management is used in design, operations, and maintenance work pro-
cesses. The basic tool for risk management is a rating of device criticality.
Device criticalities are determined by failure mode effect analysis (FMEA)
processes.
Devices with high criticality typically have an immediate and significant

impact on plant operations, e.g., an impact of millions of dollars or a signifi-
cant health, safety, and environment (HSE) impact. This type of impact is nor-
mally associated with a valve or other final control element used to control a
sensitive part of a process.
The following are the general goals of risk management:
• Provide a way to segregate device alerts between operators and

maintenance
• Support device configuration
• Provide guidance for segment design
During project execution, criticality is typically analyzed as part of the process

and instrumentation diagram (P&ID), hazardous area operations plan
(HAZOP), safety integrity level (SIL) review process, or as a separate review
meeting. It is essential to have the involvement of people in operations in this
process to identify the effect of failures. As a minimum, these questions need

to be discussed:
• How does a failure affect the process?
• How much time does it take the process to recover from a failure?
• What are the actions taken, and can operators respond in time to
mitigate the problem?
• What is the physical location of the failure? (Same operating unit, top of
column, off-site, etc.)
• Will an operator have time to take corrective action if a failure is

diagnosed?
• What is the environmental impact of a failure?
• What is the financial impact of a failure?
• What is the health and safety impact of the failure?
A typical criticality-ranking example can be seen in table 5-1.
Table 5-1. Device Criticality Ranking

Criticality Ranking
Item
High Medium Low
Alert Target for Operator and Maintenance Maintenance
“Failed” Diagnostic Maintenance
Alerts
Examples Critical valves or Most information and Experimental devices,

control loops, heat control applications multiplexers
tracing failure
Segments Segregate Most segments Segregate
Existing Mainte- Scheduled and Condition-based Reactive

nance Ranking condition-based maintenance
maintenance
Device Options Enable all optional Enable standard Enable standard
diagnostics diagnostics, justify diagnostics
advanced diagnostics
Typical Distribution 10% of all devices 80% of all devices 10% of all devices
Additional Segment Segregation

Below are some of the additional benefits of proper segment segregation.
• Measurements with high lightning exposure
• Redundant equipment, such as parallel process trains and standby

equipment
• Redundant measurements for fault tolerance
• Redundant valves
Segment segregation is used to isolate risks that may be incompatible. How-

ever, segregation needs to be employed judiciously after the cost-benefit ratio
has been evaluated.
Initially, the preliminary layout of segments within each risk area is based
solely on the P&IDs and plot plan. The P&IDs are the basis for determining
which FF devices are related and are therefore assigned to the same segment
to limit cross-segment communication (note that in many cases both the con-
trolling element and the measuring device of a control loop are located adja-
cent to each other).
For high-density units, segment allocation can be split by macrocycle, that is:
Flow/pressure loops – 1000 msec

Temp/level loops – 1000 msec
Monitoring – 1000 msec
Temperature MUX – 2000 msec
A split of control and monitoring segments has the added advantage of

increasing the integrity of the control loops by ensuring that a monitoring
device failure does not impact the plant operation (either by its initial failure
bringing the segment down or subsequent maintenance activity).
Once all higher-density areas have had control devices assigned to segments,
only then should any remaining monitoring devices be added to “load” the
control segments, always keeping in mind the constraints limiting the number
of devices per segment. Based on the P&IDs, devices can be grouped on the
same segment if they are associated with a common piece of equipment. This
is because the devices are actually located adjacent to one another even with-
out the use of a plot plan.
Care should be taken when assigning devices to field barriers to avoid assign-
ing redundant/standby equipment and main equipment controls to the same
barrier, and if feasible, segment.
It is advised that one or more segments should be used to “pick up” all FF
devices on process equipment. It is advisable to avoid segments running
between distant vessels and across plots. This is recommended to avoid awk-
ward field cabling runs between process equipment and to maintain a single
crossover point from the main pipe rack to each vessel and its associated FF
devices. For repeat units, consideration of the original JB allocation can be
used to ensure enough field cable runs.
Now let us note some of the capacity-related maximum values considered by

some large installations.
Maximum fieldbus segment plus spur lengths must not exceed 1,900 m. For a
typical project this constraint results in the following design considerations as
a way to manage risk:
• Maximum fieldbus trunk length is 1,000 m.
• Segments must have 10 or fewer devices.
• Each segment may have no more than three final control elements.
• The criticality of loops must be identified and applied.
• No two critical loops may be placed on the same segment.
• Only one FOUNDATION Fieldbus device is permitted per spur.
• Maximum spur length is 90 m.
In some cases, cross-segment communication is required for complex loops,

since the number of devices exceeds the limit per segment. In those cases,
communication must be limited to a minimum. Cross-segment control has the
related segments on the same HOST controller and the same FOUNDATION
Fieldbus interface card (multiple ports), e.g., a split range controller with three
valves.
When a control loop has multiple inputs that are operator or auto-selected, the
input devices can be on the same segment, and the control must reside in the
HOST system. This also applies to cascade loops where the master/slave
resides on the same segment and takes the same criticality level.
Where flow loops have a correction factor such as pressure, temperature, or

density—which should all reside on the same segment as the primary mea-
surement—consideration can also be given to multivariable devices, provided
they are not part of a critical loop. There are instances where the cascade loop
input is an output from a separate loop or device on a separate segment; this is
acceptable particularly for larger complex loops.
5.4 Control Assignment/Location

Within FOUNDATION Fieldbus devices, control is contained in software entities
called control modules. The control module contains control blocks that are
interconnected by software. The control blocks can be a mix of both FOUNDA-
TION Fieldbus and other blocks. The fieldbus control blocks can be assigned to
run in a field device or in the DCS controller.
Some users prefer control in the field (CIF), because CIF optimizes communi-
cation. Less H1 communication is required, and control loops show lower
variability due to better synchronization.
CIF can be used for simple single loop and cascade PID control within the
same H1 segment. The PID function block can be located in the final control
element for a single loop. The system can be configured to allow the operator
to manipulate the control valve or final control element manually and provide
alarm of the condition when a transmitter is completely inoperative due to
local failure, such as power loss, communication loss, or complete electronics
failure.
Transmitters and control valve positioners typically have a PID function block
available, which raises the issue of where the PID function should be located.
It is important to consider issues such as H1 segment communications over-
head, execution speed, advanced diagnostics, failure mode, and operator
access when choosing where the PID block resides. However, the general con-
sensus is that the PID block should be located in the control valve positioner.
As with conventional control systems, it is important to determine loop and
device failure modes, and the proper course of fail action should be identified
for each control loop.
If all function blocks of a single PID control loop cannot reside on the same
segment, the PID control algorithm has to be placed in the DCS controller.
Cascade PID control can be implemented in the field if all function blocks for
both inner and outer loops reside on the same segment.
Complex control must be fully implemented in the controller. This restriction

may not apply, however, to systems supporting bridge capability between
FOUNDATION Fieldbus H1 networks. Note that bridging may be possible with
the use of HSE, but not all host systems with HSE support bridging.
Each FOUNDATION Fieldbus control strategy or module is named as shown on

the P&ID. The primary loop function block used for operator interface (AI or
PID) shares the module name. With some systems, using consistent tagging
conventions between devices and their associated loop can facilitate improved
access to device information.
Temperature Multiplexer Transmitters

Eight-way FF temperature multiplexer transmitters (MUX) are sometimes
used for temperature monitoring. These multiplexers are used where high-
density temperature measurements are required for DCS indication. Experi-
ence has shown that a reasonable guideline is four multiplexers/two multi-
plexers per JBs, and a maximum of 32 temperature measurements may be
connected to one segment. Each multiplexer JB is connected to the FF spur JB
via a two-pair IS cable. Segments dedicated to temperature multiplexers have
a macrocycle time of 2,000 milliseconds. Temperature multiplexers can be
configured to use multiple individual AI function blocks. The MAI function is
another option, where a maximum of 64 temperature measurements can be
recorded. The above can be doubled in a single FF segment. This has to be ini-
tially validated with the host system.
Motor-operated Valves
Where individual motor-operated valves (MOVs) are required in process
units, these shall be FF devices and hook up to the segment as a standard
device. Due to the non-IS protection of these devices, they must be assigned to
their own spur JB/segment.
5.5 Device Function Block Configuration Parameters
User Application Blocks

The user application blocks are also known as function blocks. Function
blocks handle the control strategy. The function block diagram is a graphical
programming language for building control strategies. There are two kinds of
blocks used in FOUNDATION Fieldbus devices: device application blocks and
configuration blocks.
Device application blocks: The execution of these blocks uses predefined

scheduling specified by the device manufacturer.
Configuration blocks are used to configure devices. These consist of:
• Resource blocks, describing device data
• Transducer blocks, holding the device diagnostic data
• Function blocks (FBs) whose schedule and usage is completely user

configurable
Resource Block
The resource block (RB) describes characteristics of the fieldbus device such as
the device name, manufacturer, and serial number. There can be only one RB
in a device.
Transducer Blocks
The transducer block (TB) contains information such as calibration date and
sensor type. TBs decouple FBs from the local input/output (I/O) functions
required to read sensors and command output hardware. This block carries
out parameterization, calibration, and diagnostics for the device.
There is typically one TB channel for each input or output channel of a device
(this may differ for some devices). Some devices have several TBs, where ded-
icated TBs are used for device diagnostics. Diagnostic coverage is all defined
in the TBs of the device. Interoperability of all TB parameters with the host
system is essential for asset management. Detailed descriptions of the device
diagnostics are provided in later chapters.
Function Blocks
Function blocks can be used in user-defined function block applications to
provide various functions required in a control system (e.g., input, output,
signal selection, and other control actions). The FOUNDATION Fieldbus has
defined several device profiles outlining the “root” requirement for several
device types. This profile includes the pressure transmitter, temperature
transmitter, valves, and some others. Devices that conform to these specifica-
tions are preferred in systems design.
FBs are built as needed into fieldbus devices to achieve the desired control
functionality. Some FBs can be built into the devices, and some can be instan-
tiated. The first option has been used, as it results in less confusion and config-
uration effort.
Unused FBs in some multivariable devices are tagged or even partly config-
ured to avoid nuisance alarms. Optimal configuration can be achieved by
referring to the manufacturer’s device manual. Some functionality needs
additional licenses, and care needs to be taken while enabling or disabling
such functionality.
The current ITK tick marking does not include all available FB types; how-
ever, not all FB types are required. Some FBs are needed only if control in the
field is applied. Then it is essential to make a considered choice when specify-
ing the function blocks to be included in various field device types.
Although appropriate to host system controllers, these blocks may be limited

to the following: AI for transmitters, AO and PID for valves, and DI/DO for
discrete devices. Further function blocks are available and are more likely to
be added to the devices in the future. It is therefore recommended that func-
tion block availability be checked with the instrument manufacturer at the
time of selection to ensure that the needed features are available for use.
However, the interoperability of other, nonessential FBs (AI, AO, DI, DO,
MAI, Mux, PID) is not guaranteed with every host system, thereby limiting
CIF applicability. The FOUNDATION Fieldbus tests of function blocks only con-
firm that they are present and how their external interface behaves, not how
well they work internally. Each manufacturer can configure the internal oper-
ations of function blocks as they wish, for a competitive advantage. It is thus
worthwhile to check which manufacturer gives the best result in terms of

macrocycle efficiency and the needs of the relevant process.
This is mainly required when CIF is applied or fast-loop execution is required.

For some MOVs, it may also be advisable to check the FB execution times. The
execution time of PID blocks differ according to vendor. Furthermore, each
manufacturer can implement the PID algorithm with unique equations while
still providing control in a PID block. In most cases the algorithm has no
impact on the loop performance, as at present only simple control may be
applied with CIF.
5.6 Control and Data Handling of FF Devices
Fault Handling
Fault detection and processing by ITK-approved FOUNDATION Fieldbus
devices comply with FOUNDATION Fieldbus standards. PV status is available
on a per tag basis. The status values are generated for physical inputs and cal-
culated variables. The PV status is set to uncertain or bad if any of the follow-
ing conditions are true:
• A value is out of range.
• A value cannot be measured or calculated.
• Device diagnostics have identified a failure (e.g., an open

thermocouple).
PV status is propagated through control schemes and to the historian. PV sta-

tus could be used as a logical input to initiate control algorithm changes.
When a control algorithm’s input is set to bad or uncertain, or in the event of

communications subsystem failure, it is possible to configure the output to fail
as follows:
• Configured fail state (hold last good value or shed to manual)
• Mechanical fail state (loss of air to positioner)
Configured Fail State

All final control elements have a configured fail state on loss of segment com-
munication. The configured fail state can be open, closed, hold last position,
or a directed percentage open. The control element can go to its configured

fail state on loss of communication or upon a configured event.
Communication failure is a new type of failure associated with FF; hence, the
preferable configuration of the fault state is hold at last position with control-
ler shed to manual for further operator action. The configured fault state value
can be 0 percent (closed) for fail-to-closed and 100 percent (open) for fail-to-
open valves. Note that some positioners offer fail to last position. However,
this is device specific and is addressed on a case-by-case basis. A configured
event may be:
• Loss of input signal to the valve PID block
• Process event (emergency trip) or diagnostic event (valve fault)
Mechanical Fail State

The fault-state time can be configured to hold the value at last position for as
long as possible (not all valve positioners support such a feature). A minimum
of 10 seconds or 3 times the macrocycle rate is recommended. This will hold
the last value (valve position) for 10 seconds or 3 times the macrocycle during
a communication failure, and thereby increase plant availability by providing
an opportunity to reestablish communications.
Fault Handling in Blocks

Faults on FF can be handled in multiple ways. On a high level, one way of
handling faults is by reporting alarms or a change in loop state and letting the
user interact and solve the problem. Another way is to let the FF infrastruc-
ture take care of the failure, but inform the user that there is a failure. Hence, it
can be solved and can be ready to be tolerant for another instance of failure.
This can also be translated as redundancy. More details on fault handling are
as follows:
Details of alarms during block errors and their descriptions are explained
under function blocks. There are three types of reactions to failures at inputs
to function blocks:
• Remote Shed
• Fault State Initiation
• Mode Degradation
Remote Shed
Remote Shed or simply “shed” is the term used when a “remote” input
(RCAS_IN or ROUT_IN) times out. These two connection types are Fieldbus
Message Specification (FMS) writes (as opposed to publisher/subscriber inter-
function block connections). The SHED_ROUT and SHED_RCAS parameters
in the resource block determine how long to tolerate missing updates.
Shed is controlled by the SHED_OPT parameter. There are eight options

selected by the output block’s SHED_OUT parameter:
• Normal shed, normal return (next operationally lower permitted

mode)
• Normal shed, no return (next operationally lower permitted mode)
• Shed to auto, normal return
• Shed to auto, no return
• Shed to manual, normal return
• Shed to manual, no return
• Shed to retained target, normal return
• Shed to retained target, no return
If it is in a control block and CAS_IN is left unconnected and no constant is

entered, it will have a status of Bad (not connected). If CAS is selected as a per-
mitted mode and STATUS_OPTS[1] (“IFS if Status of CAS_IN is Bad”) is set, a
failure of ROUT or RCAS will fail to CAS, which should immediately send
“initiate fault state” status to the downstream block. If properly configured,
the downstream block initiates the fault state and assumes an actual mode of
LO.
Fault State Initiation

Fault state initiation is a feature where, based on the selected features, the
fault state is initiated and subsequent behavior of the block is defined.
Fault state initiation, if supported in FEATURES and selected in

FEATURES_SEL, is an action taken under the following conditions:
• GoodC (InitiateFaultState) status is seen on ROUT_IN and the target

mode is ROUT, or is seen on RCAS_IN and the target mode is RCAS, or
is seen on CAS_IN and the target mode is CAS.
• A Bad (NoComm) is generated at a subscriber (due to loss of

periodically published signal) for CAS_IN at an output block (e.g., AO,
DO).

periodically published signal) for CAS_IN at a control block (e.g., PID,
PD), and the “IFS if Bad CAS_IN” option is set in STATUS_OPTS.
Then, GoodC (IFS) is passed in the block’s OUT to the downstream
block.

periodically published signal) for IN at a control block (e.g., PID, PD),
and the “IFS if Bad IN” option is set in STATUS_OPTS. Then, GoodC
(IFS) is passed in the block’s OUT to the downstream block.
• The SET_FSTATE parameter in the resource block is activated.
• A physical contact is changed to the fault state at the device, if

provided.
The output block’s IO_OPTS[6] parameter selects setting fault state to be

FSTATE_VAL[_D] or to freeze (i.e., hold last state/position). FSTATE_TIME
determines how long to tolerate the initiating condition before invoking the
fault state. Fault state changes the actual mode to LO.
The STATUS_OPTS[0] (“IFS if Bad IN”), STATUS_OPTS[1] (“IFS if Bad

CAS_IN”), and STATUS_OPTS[5] (“Target to Manual if Bad IN”) options
apply to control blocks like PID and PD.
Mode Degradation
Mode degradation, sometimes called “mode shedding,” but easily confused
with “shed,” is what happens when the communications that the current
mode is dependent upon are lost, and a degraded mode of operation is possi-
ble by using a less-functional input instead (e.g., modes could degrade from
ROUT → RCAS → CAS → AUTO → MAN).
If the fault state initiation rules apply, they take precedence over mode degra-
dation. Note that a Bad status on an input that is not “Bad (NoComm)” initi-
ates this mode degradation, not fault state.
The STATUS_OPTS[0] (“IFS if Bad IN”) and TATUS_OPTS [1] (“IFS if Bad
CAS_IN”) options apply to all substatuses of Bad per the FF specification.
However, few vendors devices allow Bad (OOS) to not generate IFS.
The mode shed for different conditions is provided in table 5-2.
Table 5-2. FF Device Failure Reactions

FF Device Failure Reactions
Current Mode Conditions Resulting Action

ROUT IFS on ROUT_IN and MODE_BLK. Activate fault state, go to LO mode
Target is ROUT for FSTATE_TIME
ROUT Time since last write to ROUT_IN Shed per SHED_OPT (to Auto or
exceeds SHED_ROUT Man, no return or normal return per
(Bad[NoComm] status) and SHED_OPT)
SHED_OPT is “Shed to Auto” or
“Shed to Man”
ROUT Time since last write to ROUT_IN Shed to next permitted mode (May
exceeds SHED_ROUT be Cas, Auto, or Man; may not be
(Bad[NoComm] status) and RCas)
SHED_OPT is “Normal”
ROUT Bad status on ROUT_IN (not stated, Shed per SHED_OPT (to Auto or
but probably means “other than Man, no return or normal return per
NoComm.” See two rows above) SHED_OPT)
ROUT Bad status on IN and Set IFS in OUT or OUT_D
STATUS_OPTS[0] (“IFS if Status of
IN is Bad”) is ON
ROUT SET_FSTATE entered as “Set” by Activate fault state, go to LO mode
operator
RCAS IFS on RCAS_IN and Activate fault state, go to LO mode
MODE_BLK.target is RCas, for
FSTATE_TIME
RCAS Time since last write to RCAS_IN Shed per SHED_OPT to next
exceeds SHED_RCAS permitted, Auto or Man mode
(Bad[NoComm] status) and
SHED_OPT is “Normal Shed”, “Shed
to Auto” or “Shed to Man,” each
either “No return” or “Normal return”

RCAS Time since last write to RCAS_IN Set IFS in OUT or OUT_D
exceeds SHED_RCAS
SHED_OPT is “Normal” and
CAS_IN is Bad”) is ON and Cas is a
permitted mode, but CAS_IN is not
connected and not a constant
RCAS Time since last write to RCAS_IN Shed per SHED_OPT to Cas, then
exceeds SHED_RCAS activate fault state, go to LO mode
SHED_OPT is “Normal shed, No
return” and {STATUS_OPTS[1] (“IFS
if Status of CAS_IN is Bad”) is ON
and Cas is a permitted mode and
CAS_IN is not connected and has
status of GoodC/IFS}
RCAS Time since last write to RCAS_IN Shed to next permitted mode (may
exceeds SHED_RCAS be Cas, Auto, or Man)
SHED_OPT is “Normal” and
{STATUS_OPTS[1] (“IFS if Status of
CAS_IN is Bad”) is OFF or not
available or Cas is not a permitted
mode or CAS_IN is connected or is a
constant}
RCAS Bad status on RCAS_IN Shed per SHED_OPT (to Auto or
Man, no return or normal return per
SHED_OPT)
RCAS Bad status on IN Shed mode to Man (whether permit-
ted or not)
RCAS Bad status on IN and Set IFS in OUT or OUT_D
IN is Bad”) is ON
RCAS SET_FSTATE entered as “Set” by Activate fault state, go to LO mode
operator
CAS IFS on CAS_IN and MODE_BLK.tar- Activate fault state, go to LO mode.
get is Cas, for FSTATE_TIME
CAS Bad(NoComm) status on CAS_IN for Activate fault state, go to LO mode
FSTATE_TIME
CAS Bad status (other than NoComm) on Shed mode to Auto. (Not stated, but
CAS_IN and MODE_BLK.target is probably means “next permitted,”
Cas. including Man. See row below)
CAS Bad status on CAS_IN and Shed mode to Next Permitted (Auto
MODE_BLK.target is Cas. (Not or Man)
stated, but probably means “other
than NoComm.” See row above)

CAS Bad status on CAS_IN and Set IFS in OUT or OUT_D
CAS_IN is Bad”) is ON
CAS Bad status on IN Shed mode to Man (whether Man is
permitted or not)
CAS Bad status on IN and Set IFS in OUT or OUT_D
IN is Bad”) is ON
CAS SET_FSTATE entered as “Set” by Activate fault state, go to LO mode
operator
AUTO Bad status on IN Shed mode to Man (whether Man is
permitted or not)
AUTO Bad status on IN and Set IFS in OUT or OUT_D
IN is Bad”) is ON
AUTO SET_FSTATE entered as “Set” by Activate fault state, go to LO mode
operator
Failure Initiation Types

• IFS status received in set point (CAS_IN)
• IFS status received in remote set point (RCAS_IN)
• IFS status received in remote output (ROUT_IN)
• Bad status (or communications time-out) on process variable (e.g., IN)
• Bad status (or communications time-out) on set point (e.g., CAS_IN)
• Bad status (or communications time-out) on remote set point (e.g.,

RCAS_IN)
• Bad status (or communications time-out) on remote output (e.g.,

ROUT_IN)
Fault State Operation

While fault state is active (FSA) in an output function block, actual mode is
local override (LO). The operator is locked out from changing OUT while in
LO. However, the operator can change the mode to “Man” to change the OUT
or can change the mode to “Auto” to change the SP. To clear FSA, the operator
may set the CLR_FSTATE parameter in the resource block. If a “no return”
form of SHED_OPT was selected, the operator must restore the target mode.
Regulatory Process Control

The following discussion introduces various settings that are possible in the
devices that are enabled with the FOUNDATION Fieldbus technology.
Algorithms
Standard FOUNDATION Fieldbus software algorithms perform regulatory pro-
cess control functions. These process control functions are performed using
predefined algorithms with configurable parameters. Standard FOUNDATION
Fieldbus control algorithms are identical regardless of whether they reside in
system controllers or the H1 field devices, but control algorithms are not stan-
dardized. For example, PID algorithms have different equations, but all the
parameter naming is the same.
Set-Point Clamps
Upper and lower clamps are available on all set points.
Anti-windup Protection
Control functions that include integral action are provided with windup pro-
tection. Windup protection inhibits the integral action when the control block
output is constrained by conditions such as:
• Output is at high or low limits of span.
• Output is at high or low clamps.
• Output is connected to the set point of a secondary controller that is

clamped.
• Output is not connected to any valid device or algorithm.
Output tracking is active unless the primary controller is connected to a sec-

ondary controller that is not in cascade mode, or if a controller loses commu-
nication with the output module due to hardware failure.
It is a good practice to make the windup protection status clearly visible to the
operator in a standard faceplate display, so the operator is aware of this condi-
tion. To achieve this, windup protection status is generally set as a parameter
that is accessible to graphic displays and application programs. Control func-
tions and computational functions include the ability to propagate the
windup parameter through multilevel control strategies.
Control and Execution Monitoring

The system provides a mechanism to view control strategies as defined in the
configuration while they execute in real-time, as well as the real-time input
and output values. When a device tag is selected, the operator is able to read-
ily access the control strategy. No additional configuration is necessary to pro-
vide this functionality.
Factory Configuration
FOUNDATION Fieldbus instruments are configured by the manufacturer and
include at least the following information:
• Serial number
• Tag name, recommended that it is continuous (without space or use of

hyphens)
In addition, it may be advisable to order devices with the correct FOUNDATION

Fieldbus address and with link master (LM) functionality turned off (use as
basic). This enables faster commissioning.
Control Loop Execution Time

The execution time of all the devices and function blocks used within a single
FOUNDATION Fieldbus segment is defined as that segment’s macrocycle time.
This is an accumulation of the execution time of each device function block
configured within the segment, plus allowance for the LAS and start-time off-
sets. The order of execution of fieldbus blocks or FF faceplate blocks is auto-
matically determined based on the connections between those blocks on the
fieldbus H1 segment.
Each function block within a device has an execution time that varies between
devices. The execution time also varies depending on the function blocks used
within each device. In general, the control response period dictates the seg-
ment macrocycle time based upon the DCS scan time. The control response
specification is based on a single PID loop. For more complex loops, particu-
larly master/slave or cascade control loops, the response time only applies to
the slave loop. It is preferred that the master and slave reside on the same seg-
ment. It is acceptable, however, if the master is on a different segment due to
macrocycle or geographical constraints.
LAS and FB Scheduling

The communication taking place on an H1 segment can be broadly placed into
two categories:
• Scheduled Communication (for function block execution and

communication between function blocks) – Publish/Subscribe VCR
• Unscheduled Communication (for event-driven or on-demand

communication) – Client/Server VCR
The LAS is responsible for scheduled communication—also known as the

publisher/subscriber model of communication between the various function
blocks. The H1 card or LM device contains an LAS algorithm that automati-
cally determines the macrocycle and then schedules all connected devices. No
manual intervention is required.
During macrocycle time, time other than scheduled communication time is

used for nondeterministic bus communications known as unscheduled com-
munication. During unscheduled communication alarm transmission, set-
point changes, etc., take place.
There should be sufficient spare time in the macrocycle to satisfy the general
spare philosophy of this project. The recommended unscheduled (free asyn-
chronous) time is 55 percent of the macrocycle (i.e., scheduled time is a maxi-
mum of 45 percent of the macrocycle). Of the available unscheduled time, 25
percent should be unallocated to defined tasks (i.e., function block views, etc.).
Optimizing Fieldbus Link Schedules

Before the benefits and opportunities for link schedule optimization are
described, it is important to understand the basics of the fieldbus link sched-
ule. Let’s start with a relatively simple configuration and its schedule (see
figure 5-3).
There is a transmitter with an AI function block and a PID control function

block and a valve with an AO function block on the same link. A configura-
tion tool schedules the AI block’s execution to occur first in the macrocycle.
(Timing attributes needed for the schedule are obtained from the device ven-
dor’s Device Description files.) Then the PID block is scheduled immediately,
accepting the AI block’s output internally, with no need to publish it. When
the PID has completed executing, it is scheduled to publish its control output,
Figure 5-3. An Elementary Link Schedule Showing a Schedule for a Transmitter

with an AI and a PID Block and a Valve with an AO Block
OUT. The valve subscribes to it, and the AO block is scheduled to execute
shortly after the publication is received. The AO block must publish its back
calculation output, BKCAL_OUT, so that its upstream block (the PID) can
confirm its operating status and use it for initialization if needed on the next
cycle.
Time synchronization is tightly controlled on the link, because all devices use
a common knowledge of time. Little margin is needed in the schedule to allow
for time variances between devices.
This example is intentionally simple. If this is all there was on the link, there
would be nothing to improve. There are only a couple of basic rules to keep in
mind for the schedule:
• Only one publication can be scheduled on a link at a time.
• Only one function block may execute at a time within a given device.
Performance Optimization Opportunities

When a second loop is added to the link, there is need for optimization.
Figure 5-4. Adding a Second Loop May Double the Scheduled Portion of the
Macrocycle
Figure 5-4 shows a common schedule that simply adds another “staircase” to
the schedule. For each loop, there is no opportunity to reduce latency (wasted
time between executions and publications) since there is no wasted time
between AI and AO block executions in each loop. However, the schedule
needlessly consumes macrocycle time because the additional devices are per-
mitted and required to have their function blocks execute in parallel with the
other devices. They simply cannot publish together, presenting the first opti-
mization opportunity:
Opportunity 1
Maximize the usability of the macrocycle by reducing the fraction of the mac-
rocycle scheduled by taking advantage of parallel execution of blocks when-
ever possible.
Imagine if there were four to six loops on the link. The macrocycle duration
may have to be significantly extended, reducing the controllability of the
loops or else fewer loops may be used on a given link. Since link interfaces
cost money, the more devices per link, the lower the “interface cost per
device.” This desire is moderated by “scale of loss” concerns and other band-
width limiting factors. Figure 5-5 shows that the scheduled portion of the
macrocycle can be reduced to almost half in this case. Leaving a significant
portion of the macrocycle free of publications permits the system to perform
other network functions like parameter access more rapidly, resulting in faster
display call-ups.
Figure 5-5. The Scheduled Portion of the Macrocycle is Reduced Via Parallel
Execution and Grouping of Publications
Figure 5-5 also reveals another benefit over figure 5-4. Since the publications
are “bunched together” instead of spread out, more bandwidth is available on
the link for other, longer messages. Fieldbus stacks look ahead at the schedule
and do not initiate an unscheduled message if it does not have time to com-
plete this task because of an impending scheduled publication. In other
words, it is better to bunch up publications consecutively than it is to spread
them out like a picket fence. The “gaps” in the fence increase performance—
the bigger the gap, the better. There is also a second optimization opportunity.
Opportunity 2
Maximize the availability of the macrocycle for unscheduled communications
by scheduling publications consecutively or close together whenever possible.
Figure 5-6 illustrates another opportunity. Here there are three transmitters
measuring process values and a valve employing an input selector (ISEL)
block to average or select the median. An ISEL, PID, and AO block reside in
the valve.
Figure 5-6. Three Transmitters Sample in Series and Provide Values for an Input
But figure 5-7 shows that the total latency from the execution of the first AI to
the final AO is reduced by taking advantage of parallel execution of the three
transmitters (simply skewed enough to permit their three publications to be
adjacent to one another). Reducing latency can improve control. Control sta-
bility issues are reduced. Actuator movement, hence, wear and tear, can be
reduced. Productivity can be increased if the reduced latency leads to tighter
control, which leads to the ability to operate closer to equipment design limits.
In addition to parallel processing, interference by scheduling other devices
can add latency to the control loop. This is well addressed by prioritizing the
Figure 5-7. Parallel Execution Can Reduce the Latency for a Portion of the Control
Loop
elements in the schedule such that the most important ones are scheduled
with the fewest possible conflicts. Hence, the third optimization opportunity
is as follows:
Opportunity 3
Minimize control latency via parallel execution and prioritized scheduling
whenever possible. Let’s look at a more complex example. Figure 5-8 shows a
tertiary loop consisting of AI3, arithmetic, PID3, and AO blocks. It executes at
a one-half second period. AI4 feeds the calculation in the arithmetic block, but
at two seconds. (It is associated with a slower moving variable such as tem-
perature.) A secondary sequence of AI2 and PID2 calculates the set point for
PID3 at a one second period. The primary sequence of AI1 and PID1 calculate
the set point for PID2 at a two second period. Clearly the most important ele-
ments to schedule with minimum latency are the AI3-arithmetic-PID3-AO
blocks. The innermost loop of a cascade has the tightest timing requirements.
The integrator block feeds on the output of the arithmetic block, but since its
output is not used in the control loop, its timing is much less important than
any blocks used for control.
Figure 5-8. The Triple Cascade Includes an Arithmetic Calculation and an

Integrator Block
The nonoptimized or “natural” schedule is shown in figure 5-9. It basically

lays the elements into the schedule as they are encountered without regard to
optimization. Owing to multiple execution periods for the blocks, the 2-sec-
ond macrocycle repeats the one-half second blocks four times and the one-
second blocks twice while the 2-second blocks appear once. This schedule
consumes 499 ms of the 500 ms available for the first 500 ms subschedule, so it
would not even be acceptable, because it does not allow any time for unsched-
uled client/server communications to occur. (A guideline of 55 percent free
time is typically used.) Using vertical bands, the figure also illustrates the
times that unscheduled traffic cannot use the bus. In addition, there is consid-
erable unnecessary latency in the schedule between the input processing and
the control action.
Figure 5-10 is an optimized schedule, taking into account priorities and other
factors. First, notice that the initial 500-ms subcycle is now only scheduled for
a 283-ms duration, instead of 499 ms, leaving more unscheduled time. Next,
notice that the vertical bands showing publications are better grouped, which
also provides better, unscheduled communications bandwidth. Back calcula-
tions are grouped with other publications where possible. Latency from input
to output is significantly reduced by priority scheduling of the elements into
Figure 5-9. The Natural Schedule for the Triple Cascade Consumes Most of the
Macrocycle and Leaves Little Time for Unscheduled Communications
the schedule. Because of timing complexities associated with combining mac-

rocycles of different periods, this practice must be used with caution.
Opportunity 4
Provide the best scheduling for the highest priority elements. Another oppor-
tunity for optimization comes with back-calculation publications. These publi-
cations notify the upstream control block of current values, limits, cascade
relationship indications, and data qualities. Since they are available as soon as
the downstream block executes, but are not needed until the upstream block
executes on the next cycle, there is usually a great deal of slack regarding
when they are to be scheduled.
Because a goal of schedule optimization is to provide the largest breaks

between publications for the unscheduled traffic, placing each additional pub-
lication in the schedule adjacent to a previously scheduled publication is less
disruptive than breaking an unscheduled time interval into two intervals. But
if it is necessary to break an unscheduled time interval into two intervals, it is
better to break the smallest eligible one and break it as unequally as possible.
Figure 5-10. The Optimized Schedule for the Triple Cascade Provides Much More
Time for Unscheduled Communications
This is generally preferable to breaking it equally, because long messages can

block the communications stack waiting for a long enough interval in the
schedule to be transmitted.
Opportunity 5
Scheduling of back-calculation publications can take advantage of a wider
time window of eligibility and should minimize disruption to the availability
of large, unscheduled communications intervals in the schedule. If the
upstream block that receives the back-calculation publication executes at a
slower period, the downstream publication need not be published after each
of its more frequent executions. It need only be published on the final execu-
tion that precedes the scheduled execution of the upstream receiving block.
Prioritization of Schedule Elements

It is essential to prioritize the scheduling of execution elements. When build-
ing the schedule, it is important to give the best “positions” to the most impor-
tant publication and execution elements. Since minimizing latency is an
important goal, all schedule elements involved with control are more impor-
tant than those involved only with monitoring. This means that the schedul-
ing mechanism needs to understand how each function block is used.
Next, where there are multiple execution periods on the same link, higher pri-
ority should be given to the faster blocks. It is assumed that since the control
engineer specified them to execute more frequently, they are associated with
an application function that demands faster action.
Where there are multiple loops executing at the same execution period, those
associated with the innermost loop of cascades are assigned the highest prior-
ity, because those dynamics are always faster. Then the next level of cascade
set-point calculation sequence is given a lower priority. This reducing of pri-
oritization continues to the outermost level of a cascade.
If all else is equal (control versus monitoring, execution period, level of cas-
cade), then the sequences that are going to contribute the most to the schedule
are given priority, since they need the least interference. The smaller contribu-
tions can deal better with the conflicts presented by the preceding
contributions.
5.7 Redundancy options in FOUNDATION Fieldbus

There are no approved specifications for media redundancy in FOUNDATION
Fieldbus H1; however, there are ways of achieving various levels of redun-
dancy within an H1 fieldbus system. The following are some concepts and
implementation techniques for redundancy in fieldbus systems.
Introduction to Redundancy Options in FOUNDATION Fieldbus

Many engineers see redundancy as just media redundancy: duplicate wires
running to a device. Given the number of possible failure points in a modern
control system, system redundancy is a much larger issue. Correct selection of
conduit and wire routes dramatically improves the dependability of the wire
media from the power supply to the transmitter to the valve or other final con-
trol element. System redundancy, on the other hand, depends on the reliabil-
ity of the power supply, the transmitter, the controller, the communications
scheduler, the valve actuator, and the wire. Of these failure points, the wire
has the lowest complexity level, and under normal conditions, has the lowest
failure rate.
FOUNDATION Fieldbus is a technology that enables a broader range of redun-

dancy types than is seen in more traditional control. From basic transmitter
redundancy, where the operator is presented with process variables from two
or more transmitters (along with the status of the variables) to advanced sys-
tem redundancy using specialized, distributed function blocks, FOUNDATION
Fieldbus can provide the appropriate level of redundancy for many
applications.
Transmitter Redundancy
Perhaps the simplest type of redundancy is the use of multiple transmitters.
The operators are allowed to choose the signal they feel is correct when pre-
sented with process information from multiple transmitters. However, with
FOUNDATION Fieldbus, each process variable has an associated status that tells
the operator whether the device has determined that the signal it is presenting
is good, bad, or uncertain. Furthermore, the device can alert the operator if it
has detected any one of a multitude of conditions that may cause a loss of con-
fidence in the information it is providing. And even beyond this, the device
can possibly (and probably will) contain diagnostic information that the oper-
ator or engineer can review to determine the health of the device.
Figure 5-11. Multiple Transmitters with Selector Block

It is useful to add a selector block that takes the process variables from several
transmitters and presents a single output (still with an appropriate status) to
the operator. In this case, the operator does not have to look at several process
signals, but can rely on the single output from the selector block. Bad inputs
are not considered in the decision to select an output (unless all the input sig-
nals are bad, in which case the selector block presents a BAD status on its out-
put). So, the operator can monitor a set of redundant transmitters by watching
a single signal, and if one transmitter fails, the output that the operator sees
will still be accurate. In addition, the operator can be informed of the failure
either by the device that failed, or by employing other means. Refer to the fig-
ure 5-11 for the block configuration of such a scheme.
High-speed Ethernet Redundancy

Ethernet has to be made industrial strength for use in factory and process
automation. FOUNDATION Fieldbus HSE is based on Ethernet and is used at
the host level of the control system. The host-level network ties the whole sys-
tem together, linking the various subsystems to the host. Thus, the visibility of
hundreds and perhaps thousands of loops depends on the host-level network,
as do any intra-area control loops. A complete failure could result in heavy
losses. High availability for the host-level network is therefore paramount.
HSE is the only open, Ethernet-based protocol to address the need for round-
the-clock availability of network and devices. Because device and port redun-
dancy requires interoperability beyond Ethernet and IP, other Ethernet solu-
tions do not support it.
HSE is the first standard protocol that enables the selection of a device from a
redundant pair and one of the redundant ports that a transmitting device
should address. Exchange of redundancy management information is part of
the standard protocol. HSE is built on standard Ethernet, originally a technol-
ogy for the office environment. However, industrial-grade hardware is avail-
able, and HSE has a number of functions built in to ensure fault tolerance.
The modern form of Ethernet uses unshielded twisted pair (UTP) wiring
using a hub-based star topology in which there is only one device per wire
segment. Therefore, devices can be disconnected and connected without dis-
rupting other devices, and any wire fault only affects a single device (i.e., the
impact of a fault is reduced somewhat). A shared hub is a multiple port
repeater that joins several segments into a single network. A switched hub is a
multiple-port bridge that joins several networks together. Fiber-optic media
can be employed to increase tolerance toward electrical noise and ground

potential differences, further increasing the robustness of the system. Indus-
trial grade hubs with redundant power supplies, wide temperature ranges,
and rugged enclosures are available for use in a tough plant environment.
The shutdown of a plant is extremely disruptive, and downtime means heavy

losses. At the host level, the network and devices are shared between many
loops, making these parts particularly critical to the operation of the plant. A
host-level network failure leads to the operators being unable to monitor and
supervise the plant, and therefore, causes many loops to be shut down. The
host-level network is also used for intra-area control loops that would have to
be shut down. Unlike the field-level where high availability is achieved by
distributing functionality, thereby isolating faults to a small sector, at the
rather centralized host-level, redundancy is instead used to achieve high
availability. Any Ethernet network can use media redundancy to achieve
some measure of increased availability, but HSE also supports complete
device and networking redundancy.
Controller Redundancy
FOUNDATION Fieldbus enables the application of control in the field. With
experience, users realize that distributing control to the field devices is more
reliable than maintaining control in a centralized DCS or PLC. The advantages
of using a PID controller in a field device are soon appreciated. Those slow to
make the transition to control in the field may use the device PID controller as
a backup to a host (DCS/PLC) PID controller. In the event of failure in the host
system, control switches to the field controller and the process continue with-
out incident or bump. This is accomplished by getting the host to write the
output from its PID to the ROUT_IN parameter of a PID in the field (see
figure 5-12).
The PID in the field can be put into ROUT mode, which directly transfers the
value written in its ROUT_IN parameter to its output. But, if the status goes
BAD on the data written by the host, or if the host gets too busy and does not
get a chance to write the data in the configured amount of time, the field PID
switches to an automatic mode (determined ahead of time) and continues
operation. There is no bump, because the PID continuously monitors the data
from the host system and the analog output block, and recalculates its internal
variables. It is ready to take over control when told to do so by an operator or
by a set of conditions as previously described.
Figure 5-12. Field PID as Backup to Host PID
Although the above configuration handles many problems and is sufficient

for a number of applications, an even higher level of redundancy can be
achieved with a more advanced block set.
Media Redundancy
Any Ethernet device, even one with a single port, can have simple media
redundancy using some form of port “splitter.” Splitters are implemented in
different ways, but basically work in the same fashion. A single port is split in
two, connecting devices together in a circle and providing alternate communi-
cation paths. If communication in one direction is not possible, communica-
tion is routed the other way (i.e., the network is “self-healing”).
The switch overtime is very short. Recovery is much faster than with the tradi-
tional spanning tree algorithm, and thus operations continue without any
data loss.
A splitter may be a transceiver handling a single port, requiring one at every

node, or it may be implemented between hubs in a ring topology.
Media redundancy works on the Physical Layer and is therefore independent

of the protocol used. Some solutions require a central redundancy manage-
ment device, which may become a weak point, whereas other solutions have
the redundancy management built into the hubs. Very often the media redun-
dancy ring is implemented using fiber optics. The ring is not a standard Ether-
net topology, and the special splitting hubs and transceivers usually use
standard media but employ proprietary mechanisms to manage the switcho-
ver. Therefore, all the splitters in the ring have to come from the same
manufacturer.
Simple media redundancy may be sufficient for some applications, but not all.
For example, some applications combine media redundancy with fully dupli-
cated networks and linking devices.
Complete Network Redundancy

The HSE protocol goes further than simple media redundancy. The HSE pro-
tocol that includes special integrity-checking diagnostics and redundancy
management in each device enables the use of two completely independent
networks, redundant communication ports, and also redundant device pairs.
All redundant Ethernet device pairs and the workstations are connected to
both Ethernet buses. When a single unit has two ports, these are named “A”
and “B.” The switchover is totally bumpless and transparent.
The redundancy scheme leaves several compatible device options open, for
example, a redundant device pair where primary and secondary have one
port each, a redundant device pair where primary and secondary have two
ports each, or a single device that has two ports. All parts of the network have
redundancy, including the hubs (there are two independent networks, ensur-
ing that communication can continue even if one network fails). This means
that the network can sustain multiple faults but still continue to function. Such
networking is extremely reliable, minimizing loss of data and unnecessary
shutdowns.
The philosophy of HSE redundancy is one of “operational transparency and

diagnostic visibility.”
This means that the control application sees either the primary or the second-
ary Ethernet device, depending on which one is active, whereas the system
diagnostics see both. Thus, the diagnostics ensure that even the inactive
devices are fully functional and ready to take over at any moment.
Wide diagnostics coverage is an integral part of the HSE protocol, going far
beyond mere hardware duplication. Every HSE device, including the host or
any “redundancy manager,” independently keeps track of the status of the
networks and all the devices on them. HSE is not only an Ethernet medium,
but also has a standard application layer; therefore, devices from different
manufacturers periodically exchange their view of the network with each
other using diagnostic messages through all ports on both networks, which
also serves as sign of life indication. Every device has a complete picture of the
network to allow it to intelligently select which network, device, and port to
communicate with. Failure detection includes late and lost messages and
duplication.
With exhaustive network diagnostics, every device knows the health of the
primary and secondary and communication port A and B of every other
device on the network. Diagnostics in each device detects failure, allowing the
device to respond to and circumvent these faults and notify the operator. No
other standard protocol has this level of redundancy capability. There is no
need for a centralized “redundancy manager,” because the redundancy man-
agement is distributed to each device. This helps in overcoming the weakness
of centralized architectures. Every communication port has a unique IP
address. The IP address does not change when the primary switches over to
the secondary. Depending on the health of the network segments, communi-
cation ports, and device pairs, the redundancy management in each device
picks the most suitable route to communicate with another device using the
appropriate IP address. Therefore, the system can sustain multiple faults and
still continue to operate. The network, device and port redundancy work
independently of the physical media. It is possible to use ring-topology media
redundancy at the same time.
Valve Redundancy
Valve redundancy is not as common as other types of redundancy. The sim-
plest way to achieve valve redundancy is to have two valves in line, both
receiving the same signal from a controller. The main valve would be pro-
grammed to fail open, and the backup valve would be programmed to fail
according to what would normally be done for the process. This solution is
elegant in its implementation simplicity.
Power Redundancy
The most critical point in most control systems is power. Both electrical and
pneumatic powers are usually needed to keep a process under control. We
will assume that the systems engineer has dealt with the problem of redun-
dant pneumatics or at least the system failure modes on the loss of air
pressure.
Electrical power is of immense importance, as without power, no device or

human can tell what the current process situation is nor can they take action to
rectify a problem.
The electrical power supply to a FOUNDATION Fieldbus segment has several

potential failure points. Although the power on the high-voltage main coming
into the plant is usually out of the control of the systems engineer, plugging a
second power supply into the same wall plug on the same circuit breaker on
the same supply transformer only addresses the failure of the power supply
itself. There are other possible points of failure that can be successfully
addressed for many applications using one or more of several available
techniques.
The first possibility is to have a backup power supply and battery backup in
the same location as the main supply, which is then switched on in the event
of a failure in the main supply. An audible alarm could sound when this
switch occurs. In addition, FOUNDATION Fieldbus enables the addition of intel-
ligence to the power supply. The power supply could contain a resource block
that generates an alarm under certain conditions. It could also contain a dis-
crete output block that sends a signal to the process when the battery is a con-
figured number of minutes from being drained. This signal may be used to
shut down the process in a known fashion before the battery in the power
supply is exhausted.
Another technique, which affords more protection, is a secondary power sup-

ply at a separate location from the main power supply. When this power sup-
ply detects that the fieldbus voltage has dropped too low, it adds a boost to
the bus. Of course, it could also contain alarms like the ones previously dis-
cussed. One of the benefits of having a backup power supply at a separate
location is the ability to continue operation if the cable to the control room is
accidentally cut.
There are many issues to be dealt with when using a separately located
backup power supply, such as where to put it and how to configure the termi-
nators. But, once these issues are properly worked out, this option provides a
limited level of media redundancy in H1 fieldbus that is generally not
recognized.
LAS Redundancy
The LAS in a fieldbus system is responsible for coordinating all communica-
tion on the fieldbus; that is, it is in charge of the token. There can be one or
more backup link active schedulers on a fieldbus segment, in addition to the
main LAS. If the active LAS fails, one of the backup LASs automatically takes
charge of the bus.
What needs to be considered is where to put the backup LAS(s). One possibil-
ity is in a secondary host, such as a backup operator console or in a configura-
tion device. This would provide a backup in case of a hardware failure in the
main host, but probably would not help in the event of a power failure to the
control system. Many people that the authors talk to believe that every valve
should have LAS capability, because without a valve, the process cannot be
controlled (we do a lot of work with continuous process control).
The role of the LAS is not a simple one and is very CPU process intensive.
Either the performance characteristics of the valve with LAS capability will
degrade to some extent when it takes over the role of LAS, or its performance
characteristics will always be degraded to some extent when compared to the
same valve without LAS capability. This performance degradation is not a
problem for many applications, but is something the user needs to seriously
consider when assembling a redundant fieldbus segment.
All that is stated here regarding valves and other final control elements is also
true for transmitters.
With current technology, the best place for a backup LAS is in a separate
device that does not have any measuring or controlling functions (i.e., a field-
based LAS whose only purpose is to take over the bus if the main LAS fails).
Furthermore, we believe that this backup LAS should be placed with each
power supply. Simply put, if a power supply is lost and there is no backup,
things will not work anymore irrespective of how many backup LASs there
are. But, by placing an LAS with each power supply, maximum protection is
achieved without adding more LASs than needed.
5.8 FOUNDATION Fieldbus – Control in Wire

By now we already know that FOUNDATION Fieldbus uses standard “function
blocks” to implement the control strategy. Function blocks are standardized
automation functions. Function blocks in field devices implement many con-
trol system functions, such as analog input, analog output, and proportional-
integral-derivative (PID) control.
The concept of control functions or function blocks is significantly different

and is a commercially viable option for the designers of control systems. The
consistent block-oriented design of the functions in the field devices is similar
in devices from different manufacturers. The blocks, when connected, are
integrated in a seamless manner, thus reducing the risk of system integration.
Distribution of control to the field devices can reduce the amount of I/O and
control equipment needed, including card files, cabinets, and power supplies.
One significant difference between FOUNDATION Fieldbus and other field-

level communication bus systems is that all the function blocks in a fieldbus
are time synchronized, executing their function at precisely the same time and
communicating (publishing/subscribing) for the best performance.
If all the function blocks are implemented in the same bus, share the same
time clock, and are executed in the same cycle (macrocycle), this is called con-
trol in wire (CIW) or control in the field. These names may be used inter-
changeably, but in this chapter we will use CIF. Control in the field is
commonly used in FOUNDATION Fieldbus technology to gain benefits, such as
reduced hardware, optimized communication, and reduced loop latency.
Figure 5-13. FF Control in the Field
Due to various reasons of the users and the initial adoption risks involved
with control technologies, there are other engineering options in which the
PID algorithm of the control is executed in the host system. This concept is
called control in the host (CIH) or control in controller (CIC). In this chapter,
we will use CIH.
In the system shown in figure 5-13, with the adoption of the FOUNDATION
Fieldbus, control functions such as PID are retained in the field devices, and
the AI and AO functions are distributed to the devices, such as transmitters or
valve positioners.
Control in the host is depicted in figure 5-14, where the AI and AO functions
of the traditional system are moved into the FOUNDATION Fieldbus device, but
the control function is retained in the traditional controller.
Figure 5-14. Control in the Host
Control in the field or control in the host provides flexibility in the design of
the system with its ability to execute the PID anywhere in the bus, including
the host. Most of the advanced FF transmitters and valve positioners bring
additional PID blocks in their block set and thereby provide options for users.
The PID can be executed anywhere, either in the transmitter, or in the valve
positioner or controller of the host system. Figure 5-15 depicts the control
options available for users.
The ability to execute the function blocks in any device on the network comes
to the forefront when considering the difference between a FOUNDATION
Fieldbus system and traditional systems. In traditional systems, AI and AO
functions are performed at I/O subsystems level or at the controller subsys-
tems level, and PID in all cases is executed at the controller level. The concept
is indicated in figure 5-16. Now, an equivalent of the traditional system using
FOUNDATION Fieldbus technology can have the PID block executed in multi-
ple locations. The optional locations are shown here as PID #1, which is an
option to have the PID and AO together in the same valve positioner. The sec-
ond option is AI and PID #2 together in the same transmitter. The third
Figure 5-15. Control Anywhere
option, PID #3, is when PID is executed in the host system, as shown in the
figure below.
Figure 5-16. Distribution of Functions with Options

Some vendors can supply the execution of the PID in the interface card, but
for the sake of discussion, this is considered a host controller.
The example strategy shown in figure 5-15 is the case of PID #3 in figure 5-17.
The PID block is executed in the host controller. The AI block periodically
publishes the data over the network, and the data is subscribed by the control-
ler in the host system. The host controller then publishes the data over the net-
work for the AO block to subscribe and take the corrective action. For safety
reasons, the AO block then feedbacks the signal (back calculation) for the PID
block in the control for safety consideration.
Figure 5-17. Control Strategies for CIH
If it is necessary to calculate control response time, the following should be

considered, as shown in figure 5-18:
1. Execute an analog input function block in the transmitter and publish

the process variable value on the fieldbus.
2. Receive the process variable at DCS/host and retransmit internally to

the controller.
3. Execute the PID algorithm.
4. Calculate the total bus transmission time to publish the calculated PID
output value on the fieldbus.
5. Execute an analog output function block.

Figure 5-18. Steps for Latency in Control in the Host
This means this option essentially adds more time to the loop latency because
of the additional steps two, three, and four, as well as the one or two “extra”
fieldbus communications involved. The additional loop latency is due to the
control being executed over the bus in a different system. In practice, the
latency might be more difficult to calculate. The problem is much more severe
in the case of completely asynchronous systems. In many commercial sys-
tems, the fieldbus network clocks and cycles will be completely different from
the host system controller cycles and scan rates.
If these two systems need to synchronize the data, the probability of the data
being sent to the controller in the same cycle will be probabilistic. The reason
is the expensive time synchronization in terms of CPU usage. Refer to
figure 5-19 below.
The latency can be improved if the two systems operate in the same cycle, but
that causes the control systems to be less efficient and to cost more, which is
economically not feasible. For lower latency, control in the field is the pre-
ferred choice.
If the control is executed in the wire or field, then there are two options with
PID and AO in the same device and AI being executed from the transmitter, as
shown in figure 5-20. This is represented in the physical devices view in
figure 5-21.
Figure 5-19. Multiple Cycles of System
Figure 5-20. Control in the Field with PID and AO options

Figure 5-21. FF Devices in Bus Mode Connected to DCS
The typical sequences of operations that take place in this case are as follows
and are shown in figure 5-22.
• Execute an analog input function block in the transmitter and publish

the process variable value on the fieldbus.
• Receive the process variable at the controller and execute the PID
algorithm.
• Execute the analog output function block.
Figure 5-22. Steps for Calculating Latency in Control in the Field 1

Similarly, the PID can be executed at the transmitter and its associated AI
function block, as depicted in figure 5-23.
Figure 5-23. Control in the Field with AI and PID options
For the system that is represented in figure 5-23, which consists of a pair of
control elements, a transmitter and valve with AI and PID in the transmitter,
and AO in the positioners, the typical sequence of operations is as follows (see
figure 5-24).
• Execute the analog input function block in the transmitter.
• Execute the PID controller function block in the transmitter and publish
the PID controller output value on the fieldbus.
• Receive the PID controller output value and execute the analog output.
Ultimately, there is no option that has complete benefits. The latency of the
systems seems to play a role in the case of control in the host. CIH is a typical
communication that occurs between two different systems not run by the
same clock. They are run asynchronously, which adds delays and probabili-
ties in communication. Control in the field causes the PID to be executed in
the same cycle, in the same bus controlled by the same clock, hence bringing
the determinism and fixed latency of the control. Some loops that are critical
and need to be executed on cycles should use control in the field, which pro-
vides additional benefits such as less controller memory and space.
Figure 5-24. Steps for Calculating Latency for Control in the Field 2
The practical latency of such systems is shown in figures 5-25 and 5-26. Con-
trol in the host has to wait for the sample data to be passed to the host control-
ler and has to wait for the cycle to complete for the action to take place. In the
case of control in the field, the same cycle executes the control action and
hence can see better latency values.
Benefits of Control in the Wire

Control in the field offers the following benefits compared to control in the
host:
Economy/lower cost
If a reduced communication load resulting from fewer links in CIF is not
required for a faster response period for the process, the leftover bandwidth
can be used to allocate more devices and control loops per fieldbus. This is
more applicable in case of slow loops like level and temperature, which
require less bandwidth. This translates into fewer H1 interface cards, fieldbus
power supplies, barriers, cables, couplers, junction boxes, and wire connec-
tions.
Deterministic control
Deterministic control in the case of CIF can be attributed to the streamlining of
scheduled data transfers and to giving enough time for unscheduled data
communication. It proves to be a better approach when determinism is
Figure 5-25. Macrocycle with Control in the Host with 4 Closed Loops
needed by the very nature of the time given for scheduled data communica-
tion in CIF.
Flexibility
One of the key aspects of CIF is its flexibility, and the major contributor of this
is block instantiation. Controllers are free to handle higher-level control func-
tions such as advanced control and optimization. FOUNDATION Fieldbus
allows for “dynamically instantiable function blocks,” meaning that function
blocks can be activated in different components of the system as required.
There is also a large library of different block types that can be used aside
from basic PID, such as switches and alarms.
Single-loop integrity
CIF does not rely on the system interface card, backplane, central controller,
or controller power supply. CIF depends only on the transmitter, valve posi-
tioner, fieldbus cable and coupler, and fieldbus power supply—all of which
must also be there for control in the host. Fewer components mean a higher
mean time between failures (MTBF). For CIF to be able to operate indepen-
Figure 5-26. Macrocycle with Control in the Field for Four Closed Loops
dent of the system, one transmitter per fieldbus is configured as backup LAS.
As long as cable integrity and power are maintained, the CIF loops remain
operational. This is often referred to as “single loop integrity,” because there is
no shared central controller. Note that the system interface card, central con-
troller, and controller power supply can also be built with redundancy for
high MTBF for CIH.
Dynamic performance
For CIH, a simple PID requires three communication links (VCR):
• The process variable from the transmitter to the controller
• The output from the controller to the valve positioner
• Feedback from the valve positioner back to the controller
However, for CIF, a simple loop with the PID in the valve positioner requires
only a single link: the process variable from the transmitter to the valve posi-
tioner. That is, CIF requires only one-third the number of communication
links, which are one-third the communication resources. This does not mean it
goes three times faster, but it does execute a little bit faster.
For applications that require fast response, such as for fuel to a heater, CIF is
beneficial. Measurements used for monitoring/indication and open-loop con-
trol need not be published. The system manages both monitoring PV (through
client/server) and other traffic, such as configuration download and advanced
diagnostics. It is in complete control of the fieldbus and paces the background
traffic in such a way that PV can be scanned and displayed “fresh” to the
operator. In addition, open loops can easily be published by creating a regular
function block link.
Communication time adds to the sampling time, and shorter sampling time
results in tighter control, that is, lower process variability, which in turn trans-
lates into better quality/yield, higher throughput, and other business results.
CIF can increase plant performance, because small performance improve-
ments on each loop of each process unit of the plant add up. With CIH the
response time is an aggregate of two-to-three bus cycles and one-to-two con-
troller cycles. That is, it will be longer than CIF and not precisely periodic. The
controller cycle can be shortened, improving the response time, but also
increasing controller loading.
A CIF loop is completely synchronized at a precisely periodic macrocycle,

ensuring a constant and minimized control response period. CIF enables a
true, 250-ms control response period, faster than 4–20 mA. Blocks and loops
are executed in different devices, simultaneously—this is parallel processing.
However, block execution time must be considered. Low-performance

devices have long function block execution time and do not support short
macrocycles, which can translate into poor performance.
Control performance
Control in the field features the best performance in both step response and
disturbance rejection in fast and medium speed processes. The faster response
and improved attenuation of the disturbance provided by CIF does, however,
require the actuators to be driven more aggressively. Consequently, such
improvements are only possible if an actuator can provide the necessary extra
speed and range defined by slew rate limits and saturation limits.
With only FOUNDATION Fieldbus communications involved, as stated earlier,

CIF can also eliminate some of the transmission of control-related data to the
DCS. This provides a corresponding reduction in control loop time delays,
which means faster updates, and can allow control that is much closer to the
set point. Applications with faster loops, such as fluid flow processes, experi-
ence the greatest performance benefit, owing to the increased speed of
response.
The communication features of FOUNDATION Fieldbus provide many benefits

when it comes to control loop timing and sequencing. FOUNDATION Fieldbus
is highly deterministic. The data rate of H1 fieldbus communications is fre-
quently a target for criticism, since it operates at a speed of 31.25 Kbps, but the
protocol provides extremely fast update rates at up 125 ms and sometimes
even less. Point-to-point communications between devices, actuators, and
controllers are supported.
Process integrity
One of the key advantages of CIF is process integrity. It provides better
response to set-point disturbances than control in the host; an example is the
trend plotted for a loop response for set-point disturbance.
Link active scheduler supports primary and backup LAS. Even when a link
fails, the backup LAS is available with a link master–capable device, so that
the loop does not go into a no-schedule state. This is one of the examples of
multiple redundant options available for sustaining the loop integrity in case
of failure. Practical experience indicates that the MTBF in case of CIF is 80 per-
cent better than with CIH.
One of the vital reasons for this is the reduced network traffic and the reduced
number of points on which the H1 link or the device has to integrate, ulti-
mately resulting in reducing the chance of failures. Network management and
link active scheduler maintain high network availability. In addition, fieldbus
safety system concept provides a path to higher process availability.
Limitations of Control in the Field

CIF is not for every control loop. There are some loops where it can be used,
and some loops where it cannot. Detailed implementation engineering can
decide the loops for which the CIF can be implemented based on the types of
devices, the complexity of the loops, safety considerations, and familiarity

with the host system. A few factors are described below.
Complex Loops
All devices must be connected to the same bus. This can usually be ensured at
the design stage, but is not always possible. This limits the complexity of the
control strategies that can be built. Complex loops often have cascades that
can be broken down into simpler master and slave loops where the master
uses CIH, and the slave loops use CIF. Complex loops involving many func-
tion blocks may perform faster with CIH. Systems suppliers guide the best
choice between CIH and CIF for a particular loop. Advanced control, such as
model predictive and neural networks is not possible with CIF due to lack of
such blocks.
Device Capability
Some devices only have limited “libraries” of function block types, maybe
only input and output, while missing the blocks required for CIF. Most loops
can be implemented as CIF simply using analog input, PID, and analog out-
put function blocks found in most fieldbus devices. Slightly more complex
loops may require arithmetic, selector/limiter, and other blocks. Some devices
execute their function blocks too slowly for practical use in all but the slowest
loops. Carefully selecting devices at the design stage can overcome this poten-
tial pitfall.
Non-Fieldbus
CIF is only for pure fieldbus loops. However, there are loops that have inputs
and outputs from conventional analog and on/off devices or devices using
other bus technologies. For example, the input may be from a 4–20 mA trans-
mitter; the output may be a variable speed drive on Profibus-DP; or there may
be hardwired discrete inputs from a conventional DI card used in the logic. In
these cases, CIH is the only option used, because not all signal sources are on
the fieldbus.
No PID Controller Redundancy

A valve positioner may be subjected to rain, hot sun, biting cold, sea spray,
humidity, a possibly corrosive atmosphere, or vibration. The chance of a posi-
tioner failing in this environment is higher than that of a controller module in
the climate-controlled control room. Moreover, the controller typically has
redundancy with a standby controller taking over in case of primary control-
ler failure. That is, if the control system PID fails (in the case of CIH), another
controller takes over.
If the valve positioner fails with CIF, there is no backup PID. However, the
PID in the positioner uses the same microprocessor and other electronics for
moving the valve to a configured safe state. Therefore, if the valve positioner
fails, it does not matter whether CIH with redundant PID is used, because the
valve does not move anyway. From the perspective of PID redundancy in
such a situation, there is no difference in availability between CIH and CIF.
Running Blind upon H1 Interface Card Failure

When CIF is used in combination with backup LAS and only a single H1 inter-
face card, control can continue even if communication to the control system is
lost. However, if that single H1 interface card fails, the operator cannot see
what is going on. This can be overcome using redundant H1 interface cards or
by installing an H1 interface/indicating device on the segment/network.
With a single H1 interface card, it may be preferable for the control loop to go
to its predetermined fault state in case the single control system H1 interface
card fails. This can be done by simply not enabling backup LAS for that bus.
This way, if the single H1 card fails, the control loop communication also fails,
bringing the loop to its fault state. Note that the FF fault-state mechanism is
passive residing in the valve positioner; it does not need the H1 card or
backup LAS to function. On communication loss, the valve goes to its prede-
termined fault state.
Running Blindly on Positioner Failure

If the operator faceplate displays, graphics, and trending take data from the
valve positioner with CIF, these do not display the process variable if the
valve positioner fails, thus leaving the operator blind. Even though the PID is
in the valve positioner with CIH, the control system uses the process variable
from the transmitter for trend, alarm, graphics, faceplate, etc., to ensure dis-
play on the operator console even if the positioner fails.
6
Device Integration
Technologies
6.1 Device Description (DD)

Device Description (DD) is an electronic file input prepared in accordance
with Device Description Language specifications. It describes specific features
and functions of a device, including details of menus and graphic display fea-
tures to be used by host applications (including hand-held devices) to access
all parameters and data in the device. The DD is written in a standardized
programming language known as Device Description Language (DDL). A PC-
based tool called the “Tokenizer” converts DD source input files into DD out-
put files by replacing key words and standard strings in the source file with
fixed tokens.
Device Description Language (DDL)

Device Description Language is a simply structured English language for
describing field devices. DDL collates all the information a host system needs
to operate with field devices. It presents the information as a clear, unambigu-
ous, consistent description of the field device.
DDL describes the meaning or semantics of user data. The DDL source is
human-readable text in its most basic form written by device developers to
specify all the information available at the network interface to their device.
Once a Device Description is written, it can be transformed into a compact
binary format. Upon arriving at the host application, this binary formatted
205
Device Description can be decoded and interpreted to provide a complete and

accurate human text interface to the connected device.
The first step for DD developers is to describe their devices using DDL source
language. This language is used to describe the core set of parameter defini-
tions and user group and vendor-specific definitions. Each device function,
parameter, or special feature can be described. The resulting DD source file
contains an application description of all of the device information accessible.
The Tokenizer is then employed to convert the DD source files into the com-
pact binary format.
The full benefits of DDL are realized when the host system supports a Device
Description Services (DDS) Library to decode and interpret the binary format
of the information. The information in the binary specifies the parameters con-
tained in the device and also how the parameters should be presented to a
user on a display. Examples of this include how to organize a menu, which
text strings should be displayed with an alarm event, and what steps should
be taken in the calibration procedure.
By using DD Services, the host system generates displays based on the infor-
mation contained in the DD binary; the host system can fully and accurately
configure a new type of device without any software upgrades. Using the DD
in this way provides several other very attractive benefits that are discussed
later in the chapter. The DDL system architecture consists of a collection of
specifications of DDL together with a set of tools, which are implemented fol-
lowing these specifications. Specifically, the DDL architecture consists of the
following components. Refer to figure 6-1 for an illustration of the concept.
Specifications
The specifications are used to describe the meaning of and the relationships
between device data available via the network, that is, the syntax of the lan-
guage used in DDL source files. They specify the standard encoding of the
DDL source file into a binary file format that can be transported over the
network.
Tools
The Tokenizer is a tool for converting the DDL into the binary file format. This
tool also checks for proper syntax and conformance to interoperability rules.
Chapter 6 – Device Integration Technologies 207
The DDS library is a tool for extracting information from the DD binary when
it is needed by the applications.
Figure 6-1. Overview of Device Description Language
DDL Model
Device Description Source

There are eight basic constructs of the DD Language: variables, commands,
menus, edit displays, methods, relations, arrays, and collections. Variables
describe parameters in the device. Menus and edit displays describe how the
data will be presented to a user by a host. Methods describe the execution of
complex interactions that must take place between host devices and the field
device (such as data transformation). Relations describe relationships between
variables. Arrays and collections describe logical groupings of data.
For example, some of the variables in a pressure transmitter are the primary
value (PV), the upper and lower range values, and the upper and lower sensor
limits. These variables are described by the variables construct. The format of
the request and response messages of FF command supported by the device,
and the responses returned with each of the messages, are described by com-
mand constructs. Menus and edit displays describe how the users see the lay-
out when they open the device for parameterization. Methods specify the
procedure used to trim the digital to analog converter and the procedure for
re-ranging the device.
Relations are used to specify which variables are unit codes and which vari-
ables have those associated units. Relations specify the dependency relations
among different variables, that is, when a variable with unit code changes,
what the dependent/associated variables are that the host is supposed to
refresh/read.
Each of the top-level constructs, with the exception of relations, has a set of
attributes associated with it. These attributes are used to define each con-
struct. For example, a menu has two attributes: items and label. A menu is
defined by specifying a definition for each of these attributes. Attributes may
also have subattributes, which refine the definition of the attribute and hence
the definition of the top-level construct.
DDL Usage
To achieve true device interoperability, the DDL must be an integral part of
both the device design phase and the operation phase of a device. The follow-
ing are some of the aspects of DDL during the design phase.
Design Phase
The design phase of the project begins with a specification of the device for
the device DD designer to implement. From this specification, the device
designer uses DDL to begin writing a formal specification, which fully
describes all of the information available via a network interface to the device.
FOUNDATION Fieldbus provides a number of Device Descriptions that define

common standards and interoperable device interfaces. These Device Descrip-
tions can be imported into the device-specific DD and provide the files, in an
effort to achieve device interoperability. Once imported, these standard
Device Descriptions can be modified, but only in a strictly defined way that
will not affect device interoperability. For example, a manufacturer may
change the help string attached to a variable to reflect device-specific imple-

mentation issues.
The device designer next begins writing descriptions for device-specific

parameters and procedures. The type and number of additions to standard
definitions is solely at the discretion of the device designer. When this is com-
pleted the designer has a complete description of all the information accessi-
ble at the network interface.
Once the DDL Source fields such as parameters of the device are developed,
the DDL Tokenizer is used to convert the source into binary format. Figure 6-2
illustrates this process.
Figure 6-2. Different Phases in the Usage of DD
Device Description Language Tokenizer

The Tokenizer converts the DD source into a compact binary encoded file. In
addition, the Tokenizer checks for syntactical errors and informs the designer
of any inconsistencies in the description (e.g., undefined information, multiple
definitions). After the tokenization process, the DD binary is registered with

the Fieldbus Foundation and ready to be distributed.
The Tokenizer also checks for redefinitions of the information imported from
the standard DDs that would lead to interoperability problems. An example
of this is redefining the type of variable from float to an integer.
After the source DD has been tokenized successfully, the resulting DD is

tested with the real device implementation. Once the DD has been validated
as accurate, it is ready for use in an operational environment.
Device Description Services

Binary on the host side, library functions called Device Description Services
are used to read the binary Device Descriptions. Note that DDS reads descrip-
tions, not operational values. DDS technology allows the operation of devices
from different suppliers on the same fieldbus with only one version of the
host human-machine interface program.
Benefits of DD
The key benefits of using DD for host integration with the field device are:
• The tightly coupled relationship that currently exists in traditional non-

fieldbus systems, between the release of new field devices and the host
applications, ceases to exist.
• Field device development schedules are not tied to host development

or revision schedules.
• Field device developers no longer need to verify the operation of the

host; they only need to verify their DD source file. Device developers
do not have to rely on expensive and infrequent software upgrades in
the host to support their device.
• The Device Description can be easily incorporated into a configuration

or control system.
• Device developers have maximum flexibility in introducing their

product and upgrading their installed customer base. The DD binary
files can reside in the field devices and therefore can always be
available. Upgraded DD binaries can be provided in modules that may
be inserted into the host. Upgrades may also be done by portable drives
or disks or downloaded into the host with PC software.
• Configuration system developers are no longer responsible for

validation testing of all devices supported in their products. They just
have to ensure that they interpret the Device Descriptions correctly.
Limitations of DD Technology
Below are some of the limitations of using DD technologies:
• There are limitations in the graphical representation of the device at the

user interface, and complex device signatures and graphical
representations cannot be achieved.
• Device diagnostics can only be represented as a parameter, not as a

dashboard.
• The solution is more complex than a traditional system in the initial

phases of project.
• Audit trails are not possible in DD.
6.2 Electronic Device Description Language (EDDL)

EDDL is enhanced DDL that supports more constructs to enable or enhance
the graphical representation to the user. EDDL is a text-based language for
describing the digital communication characteristics of intelligent field instru-
mentation and equipment parameters—device status, diagnostic data, and
configuration details—in an operating system and human-machine interface
(HMI) neutral environment.
EDDL-based technologies continue to evolve. EDDL is being enhanced to

extend the concept of interoperability to the HMI and diagnostic data. EDDL
technologies form the engineering and operating FOUNDATION Fieldbus on
which all major digital fieldbus protocols—FOUNDATION Fieldbus, HART, and
Profibus—construct Device Descriptions.
EDDL can be easily and effectively applied to any device and any fieldbus
protocol, because it is an open technology with international standard status.
The EDDL technology enables a host system manufacturer to create a single
engineering environment that can support any device from any supplier,
using any communications protocol, without the need for custom software
drivers for each device type.
Among EDDL extensions are improved device data organization, graphical

visualization consistency, and support for persistent data storage. The sim-
plicity, longevity, robustness, and operating system (OS) and HMI platform
neutrality of field devices conforming to IEC 61804-2 simplify software main-
tenance activities for a system administrator.
The architecture of EDDL technology makes it easy to use multiple communi-

cation protocols within the same HMI host application. It does not require
custom tools for configuration and maintains a common look and feel for
operators and maintenance technicians, regardless of the intelligent field
instrumentation or equipment being viewed.
With HMI host systems ranging from large process automation systems with
rich graphic displays to simple hand-held devices with limited display capa-
bilities, EDDL’s consistent-look-and-feel philosophy is an advantage for oper-
ator and maintenance personnel user training.
Because EDDL technology was designed to eliminate the need for special or
proprietary files in host systems, a single EDD file created for a full-featured
process automation system (PAS) works equally well in the hand-held device.
This design feature eliminates the requirement for intelligent field instrument
manufacturers to create, test, register, and maintain different files for different
HMI host systems, or a different operating system for a different revision of
the same host system. For users, this feature of EDDL technology greatly sim-
plifies changing, adding, upgrading, and evolving HMI host systems.
Matching Needs
Technologies and standards appear and disappear all the time. Those who
buy into a technology without a standard are often disappointed and incur
the unnecessary expense of replacing a “promising” (but unsupported) tech-
nology. Today’s process industry users have become cautious about buying
“technology hype,” especially when faced with choosing a technology that
must remain in place for a decade or more.
When discussing digital field automation technology architectures, users state

their concerns in a hundred different ways, but in the end, what users seek are
assurances that the technology platform they choose provides:
• Freedom of choice in plant floor instrumentation and equipment

independent of the host: valves, transmitters, motor starters, remote
I/O, etc.
• Consistency in how plant-floor instrumentation and equipment are

engineered
• Flexibility and efficiency in how plant-floor data is shared throughout

the enterprise
Ease of Maintenance
A seldom-mentioned yet important realization influencing a technology’s suc-
cess is its dependence on other technologies. It is desirable for a technology’s
architecture to be minimally dependent on underlying technologies. Such a
design helps manage risk and also frees up development time to enhance and
improve product features—something end users seek when evaluating simi-
lar products from different manufacturers.
EDDL technology can address the engineering and operating questions, con-
cerns, and needs of both end users and manufacturers.
Empowering Users
Marketing literature and sales presentations often state that end users insist
on a single engineering environment to manage, commission, and configure
any field device, from any manufacturer, to any fieldbus protocol. Similarly,
the engineering environment is often the focus at industry and user group
meetings in the form of a multipart question: During the lifetime of a PAS,
what percentage of time will it take to:
• Develop the initial database and control logic?
• Perform software maintenance and upgrades?
• Make periodic engineering improvements and enhancements?
Undoubtedly, engineering, configuring, and managing activities are impor-

tant. Furthermore, when those activities are compared to the amount of time
operators use the system, experienced users also ask, “How consistent can we
make our HMI systems, so our operators can confidently and efficiently use
them?” Depending on the data source, it is usually agreed that operations per-
sonnel use the PAS 70–85 percent of the time, with other activities sharing the
remaining 15–30 percent.
While engineering, installation, development, and improvement activities are

fundamental, it is equally important to understand how EDDL technology is
being enhanced to meet the daily needs of operators and maintenance
personnel.
Operator Information and Interaction

EDDL technology creates source files containing only content relevant to a
specific manufacturer’s intelligent field instrument or device. The OS- and
HMI-neutral philosophy eliminates the need to expend resources designing
and writing software to support operator interfaces—specifying fonts, sizing
windows, selecting colors, etc.—for different manufacturers’ HMI products
and platforms.
For end users, EDDL’s neutrality philosophy ensures that operators are pro-
vided information with a consistent look and feel. Some might argue that con-
tent is more important than consistency; this may be correct for operating
information that users access several times an hour. However, EDD file con-
tent provides access to “normal” and “abnormal” operating information. EDD
file content is about access to information contained in intelligent field devices
and equipment, the sort of information viewed by operators during all sorts of
process operations. Because abnormal process operations occur infrequently
(every few days, weeks, or months), presentation consistency does become
important. For example, most of us have experienced the “use-it-or-lose-it”
software phenomenon: the one where we revisit a software application we
once knew well, only to find we have forgotten a lot of what we once knew.
That is exactly what the EDDL design philosophy avoids.
The efficiency and effectiveness of the technology are most “realized” by pro-
cess operators and maintenance technicians; therefore the technology must
work toward making these individuals comfortable.
Let us consider the example of a FOUNDATION Fieldbus-based temperature

transmitter. Figure 6-3 shows the parameters as they would appear on an
HMI, if read directly from the EDD without any parametric organization
Figure 6-3. DD-based Information Display
Figure 6-4. EDDL-based Information Display
applied. Figure 6-4 shows how those same parameters could be organized on
the HMI by using EDDL enhancements. In this case, the host system supplier
has chosen to use dialog boxes with identifying tabs.
Figure 6-5 shows an alternate display organization of the parameters using

the same EDD. In this case, an explorer view of the temperature transmitter
contents is shown. The enhancements to EDDL give the host system supplier
flexibility to organize the parameters of a field device in the manner optimal
for the field device, but consistent with the look and feel of the host system’s
HMI.
EDDL technology is designed to address engineering, startup, and daily oper-

ations requirements, with special emphasis on ensuring that operators and
maintenance technicians are comfortable using the technology to make critical
operational decisions.
Figure 6-5. Display of Parameters in Different Form
Addressing Engineering Requirements

EDDL technology addresses the engineering requirements of end users and of
intelligent field devices. The engineering requirements of both groups are
similar, each seeking solutions that:
• Ensure operating system independence
• Support multiple fieldbus protocols
• Provide a consistent look and feel across different host vendors

• Avoid special, proprietary, or executable files for different host system

platforms
• Support multiple country codes and international languages
• Use standardized testing and validation procedures and tools
• Allow efficient configuration entry
• Use a robust, consistent, easy-to-identify revision control methodology
• Include third-party testing and registration
Besides meeting all of these engineering requirements, EDDL technology also

has international standards status as IEC 61804-2.
EDDL Technology Independence

With the adoption of “open system” technologies by control and automation
systems, software maintenance (with mandatory and voluntary software
upgrades) increased dramatically. Installing mandatory software upgrades or
OS security patches two or more times a month is fairly common. EDDL neu-
trality eliminates the need for end users to worry about what happens to EDD
files as a result of software upgrades. EDDL technology does not install or cre-
ate any executable files in the HMI host application; therefore, EDDL-based
technologies eliminate the need to relink applications or communications, and
incompatible EDD files do not exist.
One feature PC users have come to appreciate is the “plug-and-play” technol-

ogy known as universal serial bus (USB). From a user’s perspective, USB
appears quite simple. Regardless of the device manufacturer or the device
type that has been plugged in, what appears on the user’s screen is consistent
for Windows users and different, yet consistent, for Macintosh users. Behind
the scenes, USB shares a number of similarities with EDDL technology. Both
use Device Description files and both use Device Description Services embed-
ded in the host platform to provide users with a consistent information pre-
sentation format.
Similar to the efforts that produced USB, representatives of Fieldbus Founda-

tion, HART Communication Foundation (HCF), and Profibus Nutzerorgan-
isation e.V. (PNO) met in February 2003 to extend the capabilities of the IEC
61804-2, Electronic Device Description Language standard. For already over-
worked control system engineers and technicians, eliminating software main-

tenance worries is a welcome benefit of deploying safe, secure, easy-to-use
EDDL-based fieldbus technologies.
EDDL Platform and Protocol Independence

One of the reasons why the EDDL technology is used in hand-held or PC-
based host applications is its platform and protocol independence. The diffi-
culties of getting device software drivers to work following a host platform
operating system upgrade are well documented. EDDL was specifically
designed for the EDD file to avoid this issue. The IEC 61804-2 standard is not
only operating system and HMI-independent, but also fieldbus communica-
tion protocol–neutral.
It is this extended neutrality that allows device manufacturers to confidently

develop a single EDD source file for a given fieldbus-based device and be
assured that it will safely and consistently perform on a variety of host appli-
cation platforms. It is equally reassuring for an end user to know that a host
workstation change from UNIX to LINUX or from Windows NT to Windows
XP or a port to Windows CE will not require modification of the existing EDD
files.
The way EDDL technology retains its platform and protocol independence is
simple. Each EDD file is uniquely numbered and contains only the descrip-
tions needed by the host application. Any methods included in the EDD file
are interpreted by the host application using a method interpreter, thus pro-
viding a safe area or “sandbox” to execute methods.
Security and reliability are also assured, because, as mentioned above, the
installation of an EDD file does not initiate installation of Win32-based
dynamic linking library, ActiveX, or similar executable software, thus avoid-
ing the problems associated with incompatible versions, revised path names,
etc.
EDDL technology is designed to encourage worldwide use and includes sup-

port for multiple languages as defined by the International Organization for
Standardization (ISO). Under the EDDL architecture, developers create EDDL
source files that incorporate multiple language text strings, each conforming
to ISO 639 for language codes and to ISO 3166 for country codes. The EDD
host application interprets the EDD file to display user information.
Avoiding host application conflicts and maintaining a consistent look and feel
are important to operators/users; the host application generates the screens
based on constructs provided by the EDD file. This permits information con-
tained in the EDD files to seamlessly integrate with a specific host applica-
tion’s capabilities.
For intelligent device manufacturers, the platform and communication proto-

col independence of the IEC 61804-2 Electronic Device Description Language
standard ensures that:
• Specifications exist for defining the architecture of the application,

syntax (form), semantics (meaning), and user interface structure.
• Capabilities exist to implement a single version of a product-specific

EDD file containing the device’s configuration, maintenance, and
functionality.
• Flexibility exists for deploying the same product, and its associated
EDD file, on different fieldbus protocols.
For end users, knowing that manufacturers of IEC 61804-2-conforming

devices are developing, testing, and maintaining a minimum number of EDD
files provides additional peace of mind when facing PAS upgrades, patches,
and even operating system changes.
EDDL Extensions
As mentioned above, in February 2003, representatives of FF, HCF, and PNO
met in a collaborative project to extend the capabilities of the IEC 61804-2 stan-
dard. The scope of the project was to add robust organization and graphical
visualization of device data as well as support for persistent data storage fea-
tures to IEC 61804-2.
Sophisticated devices with hundreds of configuration, calibration, and diag-

nostic parameters such as control valves, radar level gauges, and variable fre-
quency drives, greatly benefit from the new user interface enhancements.
These new extensions further unified the HMI environment and eliminate the
need for custom configuration software packages. Familiar dialog boxes are
used to present text, dynamic variables, pictures, charts, and archived data to
operators in a consistent, familiar format. Graphs, such as control valve signa-
tures, may incorporate pan/zoom functionality for inspecting specific detail.
In addition, EDDL extensions support user interaction with device content,

such as permitting adjusting filter values.
One EDDL extension that end users asked to be included is support for persis-
tent data storage. This new feature will permit device manufacturers to
instruct the host application to store device or local data. This implementation
method eliminates the need for the intelligent device manufacturer to learn
the underlying file system nuances of different host applications; how data is
stored is left to the host application.
Persistent data storage enables a variety of new applications using EDDL

technology. For example, valve diagnostic software, developed using EDDL
technology, can archive valve signatures for later review by support
personnel.
The benefit of IEC 61804-2’s neutrality is again shown with the addition of the
new EDDL extensions.
For more complex devices, developers can use an existing EDD file as the
starting point to create the extended EDD file. EDDL is being enhanced, but it
is maintaining backward compatibility with the millions of devices that have
been installed over the past few years. Because an extended EDD file contains
additional field device information, PAS host systems must be updated with a
new EDDL host services module. It is available from the respective fieldbus
protocol organization and can be procured by all PAS suppliers. More impor-
tantly, the host service module is backward compatible with plant floor
devices using older EDD files. Extending EDDL technology without “touch-
ing” existing EDD files ensures minimal risk when deploying new intelligent
field instruments with extensions.
Intelligent Device Management: Device Diagnostics Using EDDL

Device diagnostics can be carried out using a hand-held communicator in the
field or a laptop in the workshop, or from intelligent device management soft-
ware as part of an asset management solution, either from a dedicated mainte-
nance console or an integrated-in-the-operator console. Electronic Device
Description Language (EDDL) is the technology used by device manufactur-
ers to control how the device diagnostics are displayed to the technician.
EDDL makes diagnostics of intelligent devices easier with user guidance such
as wizards and help, and provides consistency of use compared to DD.
Device Diagnostics
The device itself performs the diagnostics (i.e., self-diagnostics or self-tests).
FOUNDATION Fieldbus can be used to communicate the result of the self-diag-
nostics to a hand-held communicator or to intelligent device management
software. Each protocol performs differently, as it has a different mechanism
for reporting diagnostics. In the vast majority of cases, diagnostics is embed-
ded in the device itself as firmware so that the device is monitored continu-
ously. In some rare cases when the device is unable to perform the test,
computer software conducts the test, with the drawback that it is not continu-
ous; it is active only when the computer software is running.
Device Integration
Plants have a mix of simple and sophisticated (complex) devices from differ-
ent manufacturers using different communication protocols, and therefore the
diagnostics depends on the type of device:
• Pressure transmitter: sensor failure, plugged impulse line, sensor

temperature limits exceeded
• Temperature transmitter: sensor failure, thermocouple degradation
• Valve positioner: partial stroke testing, travel histogram, step-response,

valve signature, pressure sensor failure, abnormal drive current, travel
deviation, reversal count alert, accumulated travel alert, I/P (current to
pressure) converter plugged, pneumatic relay leak, valve stuck,
actuator leak, low supply pressure high supply pressure, position
feedback sensor failure, etc.
• Flowmeter (Coriolis, magnetic, ultrasonic etc.): flow tube stiffness,

magnetic field strength, coil resistance, electrode resistance, grounding,
noise, empty pipe, flow profile, turbulence, speed of sound
• pH analyzer: glass electrode impedance, reference electrode

impedance. The diagnostics vary greatly from one manufacturer to
another.
Original DD technology from 1992 enabled the troubleshooting of all devices

using the same hand-held field communicator or laptop software. Before DD
only proprietary solutions existed. The original DD technology from 1992
already included “wizards” (aka “methods”), which are a kind of script cre-
ated by the device manufacturer to guide the technician through more sophis-
ticated test procedures. An example is a valve step response test requiring the
steps to be predefined and last a prompt validation sequence before the self-
test actually starts. Wizards thus make diagnostics and troubleshooting easy.
Help and conditionals were also part of original DD technology. (Wizards,

conditionals, and help are explained further on the EDDL website,
www.eddl.org.) However, not all devices had wizards in their DD file and not
all intelligent device management software supported wizards. On many sys-
tems and for many types of devices, advanced diagnostics in the past was not
so easy; however, for some devices, the manufacturer could choose to display
test results graphically, such as a valve signature, vibration spectrum, or sig-
nal waveform. This was not supported by the original DD technology, and
therefore diagnostics of some devices was not supported using DD. This
included graphics, menu systems, wizards, and conditionals.
Device Troubleshooting
EDDL technology gives the device manufacturer a vast array of possibilities
to organize the diagnostics display and make the device user friendly, and
also to add graphics such as waveforms for valve signatures and vibration
spectra. Depending on the type of device, the manufacturer may use different
EDDL elements. EDDL supports both basic and advanced diagnostics for sim-
ple as well as sophisticated (complex) devices. Following are a few examples
of devices that are easy and fast to troubleshoot and repair. Thanks to EDDL
wizards, device diagnostics for FOUNDATION Fieldbus is now just as easy as
with HART. See figure 6-6 for such a diagnostics display.
Details of the problem are revealed at the click of a button, permitting the
technician to determine that the problem is not with the transmitter but with
the sensor. Problem areas are highlighted, saving lots of time. In the past, tem-
perature transmitters were primitive devices with rudimentary diagnostics to
diagnose if the sensor was dead or alive. Today, temperature transmitters
have sophisticated diagnostics to detect if the temperature sensor is slowly
degrading, and to alert before the sensor fails completely.
Transmitter Diagnostics
In the past, pressure transmitters, as with temperature, were primitive devices
with rudimentary diagnostics to diagnose if the sensor was dead or alive.
Today, pressure transmitters have sophisticated diagnostics to detect if the
impulse line is plugging and to detect other abnormal conditions, such as
Figure 6-6. Temperature Transmitter Diagnostics Indicate Sensor Failure
unexpected liquids in the gas flow, unexpected aeration in liquids, loss of agi-
tation, and leaks. Older pressure transmitters were not as intelligent, and orig-
inal DD did not have the graphics display capability. Back then, intelligence
and display for diagnostics had to be in dedicated programs or plug-in soft-
ware that ran in a computer (e.g., plug-in software for plugged impulse line
detection). Devices are getting ever more intelligent, and they can perform all
functions internally around the clock. The result is graphically presented
using EDDL without the need for external software. Refer to figure 6-7 for an
illustration of this.
Visual dial gauges are one-way devices manufacturers choose to present the
information. Numeric values are accurate, but numeric values that are run-
ning up and down make it hard to see if the value is increasing or decreasing,
or changing faster or slower. For a pneumatic valve positioner, dial gauge
graphics make it easy to visualize how the actuator chambers vent or fill with
air, just like the mechanical gauges do on the positioner itself. Thus, EDDL
graphics help resolve problems with pneumatics. Refer to figure 6-8 for such a
display.
A valve positioner also tracks operational statistics, such as total travel and
the number of reversals (cycles). This is used as a more accurate estimate of
actual wear and tear to more precisely predict remaining life and schedule
maintenance, such as replacement, stem packing, or seat.
Figure 6-7. Strip Charts for Standard Deviation and Mean for Process Noise
Visualization
Figure 6-8. EDDL Dial Gauge Graphics Visually Show Actuator Pressure Change
6.3 Field Device Tool
Introduction to FDT
Field device tool (FDT) is a specification on interface definition that standard-
izes the data exchange between field devices and control systems or engineer-
ing and asset management tools. This is a specification for software
applications to follow. It enables easy device access and configuration through

any host system that supports FDT interfaces.
FDT technology can be used for device access of any communication protocol.
FDT is vendor independent and was established as an open publicly available
specification. FDT can be used during all phases of the plant life cycle: engi-
neering, installation, commissioning, production, and maintenance.
FDT Group (the keeper of the FDT technology standards) has certified hun-
dreds of device type managers (DTMs) that support more than 3,000 different
devices from most of the world’s leading measurement and control suppliers.
Many more continue to be developed and are in various stages of certification.
In addition, frame applications that are a part of a process automation or asset
management system are available to help users maximize device intelligence
by providing actionable information. DTMs display information that is rele-
vant and timely, improving asset performance.
End users prefer a single engineering environment for all types of activities
such as managing, commissioning, and configuring any field device, from any
device manufacturer, and connected to any fieldbus communication protocol.
FDT has the flexibility to select any supplier’s product, as they all follow a
common FDT specification. This open technology allows users to preserve the
investments made in installed field devices by avoiding the need for replace-
ment of the installed base.
This technology enables the user to make use of any field device without
restrictions. That means the user can select the best device to fit the applica-
tion and can access all the powerful native features of modern devices, with-
out any restriction imposed by the host system.
An FDT-based system can be compared with a driver for an external flash

drive or printer. These drivers are developed compliant with predefined stan-
dard interfaces, allowing any application to make use of them seamlessly.
Similarly, in FDT, the field device is delivered with the device type manager
driver, which is compliant with predefined standard FDT interfaces. The soft-
ware application or tool equivalent here in FDT technology is FDT frame
application, which is generally bundled into the engineering system or asset
management tool.
Preventing unplanned shutdowns, reducing downtime, and lowering mainte-

nance costs are significant financial benefits. One way to achieve these bene-
fits is to make certain that all installed assets are used to the best of their
ability. FDT technology can be easily used in existing or new plants and can
bring significant operational and financial benefits throughout the plant life
cycle.
This is particularly true with regard to intelligent measurement and control

instrumentation. It is good to more closely tie asset performance to corporate
goals, such as improving compliance, plant and workforce safety, sustainabil-
ity, and other critical issues, while increasing plant availability. Moving fixed
cost to a variable cost using available technology may also be desirable. For
more than a few decades, the majority of instrumentation purchased and
installed around the world has been intelligent and can provide information
beyond just the process variable (PV). Likewise, control systems (DCS, PLC,
and others) have become more intelligent, being able to access and use the
information from these field devices.
From our experience, over the past several years, FDT technology has been
available in the majority of distributed control systems and smart field
devices. FDT technology, an IEC international standard (IEC 62453) and an
ISA standard (ISA-103 Field Device Tool Interface), provides a standard
means to easily access intelligent device information independent of the field
communication protocol or control system supplier. By being supplier and
protocol neutral, FDT technology is viewed by many companies as on its way
to becoming a universal, life‐cycle management tool that is supported by
device and automation systems suppliers around the globe. This level of
adoption goes beyond international or regional standardization, because it is
quickly becoming a de facto device standard in both the process and factory
automation industries.
Basics of FDT
FDT technology provides a standardized communication interface between
field devices and control or monitoring systems used to configure, operate,
maintain, and diagnose intelligent field instrumentation for both factory and
process automation applications. The versatility of FDT technology makes it
suitable for communication protocols deployed in all industry segments, and
it allows user access to intelligence from a wide variety of process equipment.
The key features of FDT are its independence from any communication proto-
col and the software environment of the host system. FDT technology allows
any FDT-enabled device to be accessed from any compliant host using any
field communication protocol.
The technology consists of two main components:
• The frame
• The DTM
The frame is either an embedded component of the control system suite or a

stand-alone application, whereas the DTM is a device‐specific application that
launches within the frame itself. Simply put, DTMs give device manufacturers
complete control of the attributes displayed for their devices in any of more
than 15 host frame applications, thus providing users with access to the full
power and capabilities of their devices. Without FDT technology, device
information access may be restricted by the host/control system supplier and
may not offer full access to device capability. Refer to figure 6-9 for an exam-
ple of DTM graphical visualization.
Figure 6-9. Example of DTM Graphical Visualization
Frame Application
A frame application is a software window that provides the user interface
between the device DTM and various applications, such as device configura-
tion tools, engineering workstations, operator consoles, or asset management
tools. A DTM is displayed or accessed from a frame application. The frame
application initializes the DTM and connects it to the correct communication

gateways. A single FDT frame application supports more than 15 of the
world’s most popular field communication protocols including HART, Profi-
bus, FOUNDATION Fieldbus, Modbus, DeviceNet, Interbus, AS‐Interface, Profi-
net, IO‐Link, and CC‐Link. A mixture of any number of networks is
supported by FDT technology, and communications can tunnel through any
number of networks to reach the end device.
FDT frame is a container application (generally integrated with the DCS host
system) or a stand-alone executable. It is also known as FDT container, and it
instantiates other FDT components as well as maintains communication
among all other FDT components that are instantiated or created by FDT
frame. Frame application acts as the entry point for the user to interact with
FDT-based components. None of the FDT components can be standalone
without a frame application. Though there are out-of-process DTM applica-
tions possible as per the FDT specification, they can also still be controlled by
frame application. Depending on the user action on the FDT frame applica-
tion, it uses varying functions of the DTM to perform tasks.
Device Type Manager

A device type manager is a software component specific to a device that con-
tains the application software that defines all of the parameters and capabili-
ties included in that device (similar to a device driver for a printer). The DTM
provides the access and the graphical interfaces needed to configure simple or
even complex devices. It further aids the user when commissioning devices by
preventing costly trips to the field and permitting maintenance of devices
with sophisticated diagnostic tools.
Using a single frame application can minimize technician training and avoid
mistakes, since all DTMs operate using a similar menu and visualization
scheme. Because the device manufacturer provides the DTM, the user is
granted access to the full device capabilities.
All DTMs work in a common frame application, but not all DTMs are the
same. Some suppliers develop innovative DTMs with broader functionality
that helps users improve troubleshooting and maintenance, therefore allow-
ing the manufacturer to further differentiate their products from their
competition.
There are three kinds of device type managers as per specifications: communi-
cation, gateway, and device. One DTM is enough for each device type, and
sometimes a single DTM installation exposes multiple contained DTM capa-
bilities (one for each device type). The choice of how to achieve this is left to
the device or DTM supplier. DTM encapsulates all device-specific data, pro-
prietary logic, functions, and business rules and gives the best option to show-
case a range of graphical user interfaces for setting device parameters and
making the user interfaces intuitive. It can also be used to accommodate
highly sophisticated applications that can perform extensive calculations for
diagnostic or maintenance purposes, thereby keeping the end user from hav-
ing to do complicated calculations.
Communication DTM
A communication DTM refers to a DTM with direct access to a communica-
tion module. A communication DTM is a root DTM component in a network
of devices, as communication modules are the parent/root modules to the net-
work.
The capabilities of a communication DTM include communicating directly

with the communication module, scanning the physical network and identify-
ing all child/slave modules to build the logical topology with corresponding
DTMs, and routing all gateway/device DTM requests built in an exclusive
DTM or within the frame application. Either way, the child DTM (gateway/
device, see below) is hidden from that fact and expects the capabilities of a
communication DTM from its parent, frame, or communication DTM.
Gateway DTM
Gateway modules convert one protocol into another protocol (e.g., HART
over Profibus modules or Profibus PA–DP modules). DTMs developed for
gateway modules are referred to as gateway DTMs. A gateway DTM does not
have direct communication with the physical gateway module. A gateway
DTM uses the capabilities of a parent communication DTM or a frame having
communication capabilities to communicate with the physical gateway
module.
A gateway DTM has the capability to have both parent DTM and child DTMs;
additionally, a child DTM could be another gateway or device DTM. As far as
communication with the physical module is concerned, it is similar to device
DTM. In addition to this, a gateway DTM can have scanning capabilities like a
communication DTM to identify the physical network information and to

build an equivalent logical DTM topology.
Device DTM
A DTM that represents a field device is called device DTM. A device DTM
interacts with a communication DTM or gateway DTM to access its corre-
sponding physical field device. A device DTM generally is one element in the
logical topology of DTMs in a frame application. This indicates that the device
DTM cannot have another child DTM unless it is developed to have one.
Block type managers (BTMs) are the DTMs that can be child DTMs to a device
DTM, which is not so prevalent in the FDT-based systems. A BTM is a type of
DTM typically developed to represent virtual modules within a device like
function blocks in FOUNDATION Fieldbus, but is not restricted only to function
blocks.
The DTMs are typically supplied with the device. As mentioned above, a
DTM is not a stand-alone tool and always needs a frame application to create,
use, and release/destroy it. A typical DTM contains a user interface, user dia-
logs, and a help system necessary for the application it represents. Multilin-
gual support in user interface/dialog is not mandatory, but making it
multilingual is easy and is an advantage of FDT technology.
The frame application, communication DTM, gateway DTM and device DTM
are independent of each other and yet seamlessly collaborate with each other.
All that is needed for these DTMs to communicate with each other and pro-
vide critical device information is for each DTM to be developed by the corre-
sponding module or device vendor and then put on a frame application
developed or hosted in a DCS system.
Vendor-developed DTMs are packed with device-specific business logic and a

thorough parameter validity check. An FDT frame application, as per specifi-
cation, should be protocol independent, allowing any protocol DTMs to be
supported without any modifications.
A DTM can include the capabilities of parameterization, configuration

(sophisticated calibration), advanced diagnostic check, predictive mainte-
nance, and alarm or event notification. A DTM can support one or more field-
bus protocols or any custom protocol, and this information is exposed for the
frame application to allow the user or the frame application itself to make the
right choice of DTM selection during topology/network creation in the frame
application.
Communication Channels
In a physical network, the communication channel is the application channel
for DTMs to send data to the corresponding device or module. When a DTM
has to communicate to the field device, the FDT frame application provides
the communication channel to the DTM. The communication channels can be
provided by the FDT frame application itself, the communication DTM, or the
gateway DTM, based on the logical topology, which generally mirrors the
physical topology.
As mentioned above, an FDT frame application can have built-in communica-

tion channel capabilities and act as if it has a communication DTM in it, which
means a frame application with those capabilities has full control over com-
munication. The communication DTMs can be used to monitor or filter com-
munication messages. This is the typical case in a DCS system that extends
FDT support. Such a host would have both frame and communication DTM
capabilities, and hence can control traffic if needed. The communication chan-
nel ensures that the DTM can easily be integrated into a system and can
extend support to various protocols.
Process Channels
A DTM can be used to provide process values (input and output signals) from
a device that can then be integrated into the function planning of the control
system. These channels offer I/O signals of a device, such as the temperature
or flow rate, as appropriate, and other critical process values. The process
channel, like the communication channel, is an application channel that can be
used to communicate such process-related information. A process channel is
typically used for addressing and data-type information. These values can be
protocol specific.
These FDT interfaces and channels (process/communication) allow end users

to select the device best fitting the demands of their applications without hav-
ing to worry about vendor-specific information in the device and the effort
needed for engineering and maintenance of these devices. This allows the end
user to focus on the investment and leave the application integration to the
FDT specification.
Host Data Integration

Today’s modern control and host applications can access intelligent device
information, because they include FDT technology. This capability allows
easy access to device information from within the host application.
Table 6-1. DTM Function Comparison with Internet
Item As Applied to the Internet As Applied to FDT Technology
Internet Independent of Internet access method: Independent of automation

Connection Dial up, DSL, T1, Ethernet, Wireless, protocol: HART, FF, Profibus, etc.
etc.
Web Page Created by the owner of the web page to Created by the owner of the device
look the same, independent of the to look the same, independent of
browser or connection method the control or frame application;
DTM defines device visualization
Browser Created by a browser supplier, selected Created by an application supplier,
by the user to properly display web page selected by the user to properly
and page functionality: Internet Explorer, display device capability: frame
Firefox, Chrome, etc. application or host application
Think of your computer accessing the Internet, and then think of the informa-
tion on a particular website. The computer (the host system) is using the Inter-
net via dial up (DSL, etc.). Similarly, a technician is using a field
communication protocol such as HART, FF, or Profibus, opening a browser
like Internet Explorer (a frame application) to access the valuable information
located on a website (a DTM accessing the device). See table 6-1 for more
details. The website owner wants the website to be displayed in a certain way,
independent of the browser used by the computer. Likewise, a device supplier
wants its device information displayed and presented the same way, indepen-
dent of the control or asset management system.
The Case for Device Information Access

The information sitting in intelligent field devices is most often accessed only
during device configuration or troubleshooting. The full benefit of this infor-
mation is only realized when devices are regularly scanned to verify the reli-
ability of the process measurement or device health, or to identify potential
process problems. Users around the world have discovered the significant
benefits of improved asset management when they use FDT technology to
help manage their intelligent field assets. Instead of a manual, routine health
check of devices, users can put their assets to work and better manage them
using FDT technology, increasing workforce availability to allow them to

focus on the critical issues.
Allowing FDT-enabled asset management to help identify and assist the user
to effectively schedule appropriate work orders can increase reliability of
assets, while reducing labor and maintenance costs independent of the field
communication protocol used to access the device.
Benefits of Using FDT/DTM

Here are a few of the benefits of FDT/DTM:
• Faster device configuration and commissioning
• Reduced maintenance cost by only repairing devices that need repair

(e.g., control valves, transmitters) rather than following a
predetermined maintenance schedule
• Reduced downtime
• Reduced commissioning time
• Enhanced change management
• Reduced training and development cost
• Avoiding unscheduled shutdowns
• Reduced number of trips into the field—improving safety
• Improved product quality
• Superior scheduling of the operation
In many cases, these benefits can be realized with little investment and little
risk. As previously mentioned, FDT technology may be included with the sys-
tems or devices already in place. If not, new applications can be added with-
out requiring a complete replacement of any existing control system or field
devices. More information on FDT can be accessed from the website,
www.fdtgroup.org.
Specifying FDT Technology

To ensure getting FDT-certified and tested equipment, it is recommended that
the following basic requirements be included in device or system purchasing
specifications:
• Supplier will support FDT technology and will be an FDT group

member.
• All DTMs will be certified by the FDT Group.
• Frame application will be certified by the FDT Group.
• Product will comply with IEC 62453 and ISA-103 standards.
• Device DTMs will be the latest revision available.
• Frame application will include the current DTM library.
• DTMs will be available for download from the supplier’s website or the
FDT group website.
• Control systems and host applications will be DTM‐enabled (preferred)

or support a platform-independent frame application.
• Asset management and configuration applications will be

DTM‐enabled.
The devices currently on a project’s approved product lists will most likely
not change, since most devices are provided with DTMs. However, it cannot
be automatically assumed that the products are compliant. Articulation of the
specific project requirements is essential to ensure the success of the project.
6.4 Field Device Integration
Introduction
Both simple and complex devices need integration. Functions and information
from devices can be made accessible at a higher level (in a central location)
through device integration. Efficient and economically viable device integra-
tion requires multiprotocol, standardized technology, so that device informa-
tion can be made available across different manufacturers. In the past, the
development of such uniform technology was inhibited by too many different
interests from organizations and automation manufacturers, which resulted
in different technical solutions being created. The current solutions—Elec-
tronic Device Description Language in various formats and FDT—have their
strengths and weaknesses, but also overlap to a large extent, leading to addi-
tional expense for users and manufacturers and in standardization. Globally
leading control system and device manufacturers, such as ABB, Emerson,
Endress+Hauser, Honeywell, Invensys, Siemens, and Yokogawa, along with
the major associations FDT Group, Fieldbus Foundation, HART Communica-

tion Foundation, OPC Foundation, Profibus and Profinet International, are
supporting and driving forward the development of the FDI technology
together.
FDI combines the advantages of FDT with those of EDDL. It takes account of
the various tasks over the entire device life cycle of both simple and complex
devices, including configuration, commissioning, diagnosis, and calibration.
The installed base of fieldbus devices, and indeed of all intelligent field
devices, continues to grow significantly. Intelligent devices, however, can
pose an information management problem, especially when they are devices
on different networks with different underlying technologies for displaying
and managing information. FDI promises a common set of development tools
and a single path to managing the flood of information from intelligent
devices across different networks to the applications and ultimately, to the
people who need it. It offers standardization, transparency, and reduced cost.
The Fieldbus Foundation is committed to the long-term success of FDI.
FDI Technology – FDI Package

The scalable FDI package is the core of FDI technology. The FDI package is a
collection of files: the Electronic Device Description, the device definition,
business logic, and user interface description (UID). It is based on Electronic
Device Description Language. The optional user interface plug-in (UIP) has
freely programmable user interfaces familiar from FDT and based on Win-
dows Presentation Foundation. Via the FDI device package, the device manu-
facturers define which data, functions, and user interfaces are stored on the
FDI server.
The device definition describes the field device data and the internal structure
(e.g., blocks). The business logic primarily ensures that the device data
remains consistent (e.g., to refresh data when a unit is changed). The dynamic
dependencies, in particular, play a part here. These include options and
ranges that depend on prior selection of other settings, such as only showing
temperature units if the temperature value is chosen or only displaying cus-
tom settings if custom probe is selected.
User interface descriptions and user interface plug-ins define the field device
user interfaces. Product documentation (protocol-specific files) is added to the
FDI package as an attachment. FDI has defined a single protocol, independent

encoded file format, for the EDD part of the FDI package.
Harmonization of EDDL
The Electronic Device Description Language as a basis for FDI is specified in
the international standard IEC 61804-3. Furthermore, the standard defines in
profiles which constructs from the overall language scope and which library
functions can be used for the HART, FOUNDATION Fieldbus, and Profibus pro-
tocols. Accordingly, the protocols in question use a subset of the language
standard.
To a certain extent, this is due to differences in the protocols or the underlying

device models. However, a much more substantial component of the differ-
ences cannot be traced to protocol-specific requirements, but is a consequence
of the history of the language, which until 2006, existed in independent speci-
fications of the fieldbus organizations. This indicates that device manufactur-
ers have to create three different EDDs instead of one core EDD with three
separated communication descriptions for a device type with HART, Profi-
bus, and FOUNDATION Fieldbus protocols.
In FDI technology, EDDL is largely harmonized and standardized across the

protocols. A uniform EDDL is the foundation for uniform multiprotocol FDI
package development tools, FDI Integrated Development Environment (FDI
IDE), and uniform host components such as EDD Engine (interpreter) and the
client-side components UID Renderer and UIP Hosting. The result is sustain-
able strengthening of the key factors of interoperability and quality. At the
same time, cost savings can be achieved for device and system manufacturers,
fieldbus organizations, and end users.
FDI Host
An FDI host could be device management software as part of a process control
or asset management system, a device configuration tool on a laptop, or a
hand-held field communicator. The FDI architecture allows for different kinds
of host implementations, including an FDT-based host system that ensures
interoperability with FDT. In any case, an FDI host always supports all fea-
tures of an FDI device package. See figure 6-10 for the overall architecture of
host systems in various applications.
Figure 6-10. FDI Host Systems in Various Applications
FDI Host Client Server Architecture

In client/server architecture, a server provides services that various clients
(often distributed) access. The FDI architecture is based on the information
model used in the OPC Unified Architecture (OPC UA), which has advan-
tages such as platform independence. The FDI server imports FDI device
packages into its internal device catalog. This makes version management of
FDI packages much easier, as they are managed centrally within the FDI
server. As FDI packages do not require registration in the sense of a software
installation, there are no unpleasant side effects.
The representation of device instances in the FDI server takes place in the
information model. The information model maps the communication topol-
ogy of the automation system by representing the entire communication infra-
structure and the field devices as objects. This is also where the data,
functions, and user interfaces of the devices are stored. If an FDI client wishes
to work with a device, it accesses the information model, and, for example,
loads the user interface of the device in order to display it on the client side in
a similar manner to a web browser. By interpreting the EDD in its EDD
engine, the FDI server always ensures that the device data remain consistent.
If OPC UA communication is used between client and server, OPC UA
authentication and encryption mechanisms take effect and prevent unauthor-
ized access. Other (non-FDI) OPC UA clients (e.g., a manufacturing execution
system [MES]) applications can also access the device parameters in the infor-
mation model without a device-specific user interface. Refer to figure 6-11 for
such architecture.
Figure 6-11. FDI Host – Client/Server Architecture
Stand-alone FDI Host

FDI hosts do not have to implement the client/server architecture. The FDI
architecture allows for the implementation of stand-alone tools. Refer to fig-
ure 6-12 for such a system.
FDT-based FDI Host

FDI reused FDT 2.0 interfaces for the FDI UIP. FDI packages can be processed
in two system architectures: one a purely FDI host (as in figure 6-12) and one
an FDT-based FDI host (as in figure 6-13).
Figure 6-12. FDI Host – Stand-alone Tool
In the FDT-based architecture, from the viewpoint of the FDI package, the FDI
DTM acts as an FDI host; for FDT framework applications, it acts as a DTM.
For many FDT frame manufacturers, this opens up an economically attractive
migration route to FDI. The FDT 2.0 frame is retained without changes and is
simply supplemented with an FDI DTM.
The interoperability with FDT allows all system and tool manufacturers to
support FDI, meaning they can process FDI packages. This primarily benefits
device manufacturers who currently have to provide a DTM and an EDD for
one device. Instead, device manufacturers need deliver only an FDI package.
Over the longer term, this reduces the device drivers needed per device type,
and thus also leads to significant savings in product development and mainte-
nance. Ultimately, the end users benefit from the improved interoperability
and smaller range of versions.
Figure 6-13. FDT-based FDI Host
Benefits of FDI
FDI combines the tried-and-tested concepts of both EDDL and FDT and thus
provides benefits for control system manufacturers, device manufacturers,
and users.
For control system manufacturers, the client/server architecture simplifies the

use of device data and functions in powerful, distributed control systems. In
addition, transparent access to device data and functions facilitates the inte-
gration of other applications (e.g., connection of a MES). Furthermore, central
management of data prevents inconsistencies and the automatic loading of
user interfaces by the client, which means client-side installation is no longer
required.
FDI reduces effort and saves costs for device manufacturers, because in the
future, only an FDI device package has to be created for one device, instead of
the current EDD variants and DTM. Another advantage is the scalability of
the FDI device package. Simple devices get along with a simple device pack-
age. By their nature, complex devices require a more complex device package.
An integrated development environment and standard host components

ensure interoperability and cost efficient development of FDI device packages
and host systems.
For the end user, the main benefit of FDI lies in the standardized integration
of field devices through a future-proof standard that ensures unrestricted
interoperability of device packages from a wide variety of device manufactur-
ers with FDI systems (FDI hosts) from many different control system manu-
facturers.
FDI promises to address key requirements of end users and suppliers, both of
whom are seeking a single solution for management of information from a
wide range of intelligent devices. FDI aims to present real-time data in a con-
sistent format that helps plants operate efficiently and safely without confu-
sion. FDI integrates the complementary strengths of EDDL and FDT/DTM
technologies with the advantages of the structured OPC UA standard IEC
62541. FDI cooperation is developing a solution that is:
• Platform and operating system independent
• Host system independent
• Compatible with existing EDDL and FDT/DTM technologies
• Protocol independent
• An open specification and an international standard
• Able to provide access to the full capability of the field device, from
simple to complex devices
• Compatible with OPC UA technology
FDI technology is scalable; users can deploy it in applications from simple

configuration to complex management of the most sophisticated field devices
for tasks associated with all phases of their life cycle. FDI is a unified
approach, addressing end-user requirements across the spectrum, and essen-
tially eliminates the need for different solutions for different devices.
Users can focus on purchasing the hardware of their choice without worrying
about the compatibility with their control host, regardless of field device com-
munication technology. A common FDI solution allows device vendors to
focus their efforts and resources on a single technology rather than on sup-
porting both FDT and EDDL. Suppliers can focus on improving the function-
ality of their products instead of supporting multiple technologies to make
their applications work across different systems. Fewer interoperability chal-
lenges reduce manufacturing costs and time to market.
6.5 Usability in FOUNDATION Fieldbus

The users of the FOUNDATION Fieldbus technology are different at distinct use
case levels. For example, the process data consumer is different from the oper-
ators who are generally experts in the process technologies, but not on instru-
mentation technologies. The users of the diagnostics can range from
technicians to engineers with varying skill sets and academic backgrounds.
These variations pose a significant challenge to the usability of any of these
breakthrough technologies.
Technologies like FOUNDATION Fieldbus are expected to improve the user’s

feel for the information presentation, ease of configuration, ease of installa-
tion, ease of repair, etc. FOUNDATION Fieldbus technologies have many fea-
tures that have built-in capabilities for ease of operations, such as automatic
device detection, minimum click commissioning, function block–based con-
trol strategies, and better diagnostic information, coupled with standards like
NAMUR. Many more similar features will be introduced in the future. Any-
thing that helps the users to improve their effectiveness (how accurately the
job is done), efficiency (how fast and at how much cost), and satisfaction (how
much of a good experience they have) can be combined and called “usability.”
In a usability design, the user becomes the center of all the use cases, and
bringing the above to the user becomes the goal. Refer to figure 6-14 for the
usability dimensions of any product in general and of FOUNDATION Fieldbus
specifically.
Worldwide, many products used in industrial instrumentation are moving

toward a transformation to designing user-centric products. The features that
are offered by the technologies like FOUNDATION Fieldbus are helping the
manufacturers develop products and systems that are much more user-
centric.
Figure 6-14. Usability Dimensions of F OUNDATION Fieldbus

7
Maintenance in
FOUNDATION Fieldbus
7.1 Introduction to FF Maintenance

Productivity enhancement is the ultimate goal in plant operation. There are
two approaches to achieving this goal: maximization of production efficiency
and optimized use of plant assets through operation and maintenance
activities.
Plant systems range from distributed control systems (DCS) to field sensors,
such as flowmeters, differential pressure, absolute pressure, and temperature
transmitters, to software packages for operational support, advanced control,
and operation efficiency improvement. When the production facilities are
maintained appropriately, the plant operation runs smoothly; however, the
plant maintenance is supported largely by the efforts, experiences, and exper-
tise of the engineers along with detailed and documented maintenance proce-
dures, tools, software, and hardware systems.
For instance, a few decades ago, conventional sensors transmitted a measur-

ing value only in 4–20 mA analog signals from the field to the DCS. Innova-
tions in the field of digital technology in recent years have made it possible to
have reciprocal communications between the DCS and the field devices. Intel-
ligent functions of the field sensors and control valves have enhanced
diagnostics.
245
7.2 Advantages of Introducing Asset Management Systems

Field device management systems, also known as asset management systems,
introduce an ease of maintenance for the field devices enabled with FOUNDA-
TION Fieldbus. The key benefits of using such systems are reducing unman-
aged risk; improving health, safety, environment, and operations
performance; managing the complexity of troubleshooting field devices;
achieving sustainability; ensuring adequate human, financial, and infrastruc-
ture resources; and reducing maintenance cost.
Reduction in Financial Losses Caused by Unexpected Failures

Predictive diagnosis is one of the asset management solutions. It enables the
detection of future device failure in advance. For example, a diagnosis of a
restricted impulse line on a differential pressure transmitter notifies operators
that the line is about to clog before it is completely blocked. Conducting the
necessary maintenance work before a device fails enables uninterrupted plant
operation. Predictive diagnosis contributes significantly to preventing plant
operational losses and securing plant safety and environmental regulations.
Reducing Unnecessary and Nonurgent Maintenance

Figure 7-1 shows the statistical survey result of maintenance time for instru-
mentation in the chemical industry. The survey reveals 63 percent of the total
maintenance work is occupied by “routine check” (i.e., a conventional check
of instrumentation) and “no problem” (i.e., no problems were found in the
Chapter 7 – Maintenance in FOUNDATION Fieldbus 247
instrumentation). In other words, too many hours are spent only to confirm
that there is no problem with the instrumentation.
Figure 7-1. Typical Field Instrument Maintenance Statistics
Asset management systems use the diagnostic and predictive diagnostic func-
tions of field devices (i.e., sensors and valves) to allow a shift from time-based
maintenance into condition-based maintenance for conventional field devices.
These functions can drastically reduce the time spent on maintenance work,
while sustaining plant safety and ensuring plant productivity. In addition,
asset management remote monitoring reduces the number of trips and travel
time for routine checks or alarm acknowledgement in the field.
Remote Diagnostics
Field digital technologies such as FOUNDATION Fieldbus enable intercommu-
nications between the field devices and control systems and also allow remote
online handling of field device parameters and diagnostic information (figure
7-2) other than control signals.
Figure 7-2. Fieldbus Diagnostics
Maintenance and asset management for fieldbus deals with the health of the
instrumentation, and to some extent the networking hardware, but does not
involve the control strategy. However, asset management indirectly improves
control, because it can be used to ensure that the devices are in a better condi-
tion to perform control. Troubleshooting installation problems and debugging
the control strategies can be performed using asset management systems.
FOUNDATION Fieldbus has standard parameters for diagnostics, operational

statistics, calibration, and identification information—this is what makes the
fieldbus technologies a comprehensive technology ranging from networks to
control, not just I/O networks. This feature is used by software that can
retrieve this information without custom programming, data mapping, or dis-
play. Asset management functions like calibration and diagnostics may be
included as part of the configuration tool or they may be performed by stand-
alone software.
FOUNDATION Fieldbus Diagnostics

A wider range of diagnostics is one of the key features of FF in addition to the
others referred to in figure 7-3; some possible additional diagnostics are listed
below and shown in figure 7-3.
The following are some of the additional diagnostics available from FF

devices:
• Elimination of D/A and conversion delay and inaccuracy
• Elimination of range mismatch
• Closed-loop digital control
• High-density devices
• Complex devices
• Remote firmware downloads
Figure 7-3. Diagnostic features in FF

Additional diagnostics helps to reduce unnecessary plant trips for the techni-
cians and engineers. Refer to figure 7-1 for the statistics on this.
Network-enabled management of instrument assets, such as asset manage-

ment systems, in almost all the plants that are independent of the mainte-
nance schemes became a practice. Fieldbus technologies are used in such
systems to obtain information from the field devices that simplify mainte-
nance and make it more efficient. Ultimately, it is a good idea to use network-
enabled asset management to switch to a proactive maintenance program as
discussed in the next section.
FOUNDATION Fieldbus–enabled Maintenance

When a plant embarks on the first project involving fieldbus technologies, it is
a good idea to work with the quality assurance department to define how
maintenance tools will be used and how to make it an integral part of the cali-
bration and service procedures. This is primarily driven by the fact that there
are additional diagnostics available in field devices that can change the main-
tenance procedures.
• Reactive maintenance: Reactive maintenance is a scheme in which a

device is only fixed after it is broken, or rather only after it has been
found to be broken. This kind of maintenance can be dangerous since
depending on the application of the device, the plant may not be safe
while the device is malfunctioning. A failed device, depending on its
application, may also cause production to stop or reduce the product

quality to below the acceptable level. Device time available to perform
its intended function is also referred to as availability. The devices that
are not maintained well become less available.
Low availability leads to loss of production time. Shut down due to

failures is normally very expensive as quantities of product are often
destroyed and production capacity may be reduced for a long time.
Stopping and restarting the process every time there is a failure is also
frustrating as it leads to wasted time, raw materials, and energy and
other resources. If the process goes wrong, it can be time consuming to
clean up the mess.
Although reactive maintenance is far from the preferred maintenance

scheme, fieldbus technologies may be used to improve the situation by
relying on the field instruments’ ability to report faults to the host
through standard means. This will make it possible for maintenance
technicians to take quicker actions.
• Preventive maintenance: Preventive maintenance is a scheme in which

devices are serviced at a chosen interval whether they need it or not. In
general, the plant maintenance philosophy and criticality of the devices
in addition to the impact of such devices on the process operations,
safety, and yield of the product decides such devices. This approach
improves safety and availability since surprise stops are in many cases
avoided. However, this scheme is also costly because resources like
time and spare parts may be wasted on many devices that actually
need no attention (i.e., unnecessary maintenance may not be
performed).
The preventive maintenance may be disruptive since production may

not be able to run normally while the maintenance is carried out.
Although, with preventive maintenance, availability is not at its
optimal level if not performed as per the plan. Fieldbus technologies
can be used to store and retrieve information about the last calibration
or service in the field device, which is a critical input for the preventive
maintenance plans.
• Predictive maintenance: Predictive maintenance is also a scheme in

which periodic servicing may be performed whether the device needs
it or not. However, the service interval is optimized using failure rate
and drift statistics gathered for each device type over long periods of
time. There is still some waste of resources, but less of it since

unnecessary maintenance is reduced. Fieldbus technologies can be
used to more accurately determine when devices fail and how much
they drift.
• Proactive maintenance: Proactive maintenance is a scheme in which

service is targeted toward the instruments that need it (i.e., based on
the condition of the device). Resources are not wasted on devices that
need no maintenance. This scheme requires a minimum of resources,
has the lowest possible cost, and offers the most efficient use of
manpower. Using fieldbus technologies in addition to diagnostics to
continuously monitor “leading indicators,” such as stress, extreme
ambient conditions, and the number of operations, makes it possible to
predict future faults without the need for manual data collection and
entry. Network-enabled asset management is faster and easier than
manual data collection and entry as there is no delay between the time
diagnostics data is created and the moment when it reaches the asset
management software.
Asset Management–enabled Systems

Asset management is a software-centric approach to maintenance and calibra-
tion. Adding fieldbus interface cards to the distributed control system (DCS)
hardware does not open up the great potential of these technologies. To fully
benefit from fieldbus technologies, the engineering tool or dedicated asset
management software should be permanently connected to all the field-level
networks so there is continuous online overview and monitoring of the
devices even while the plant is operating.
Diagnostics, configuration, identification and the like can be done any time.
Although a stand-alone or temporarily attached configuration tool may work
for a small pilot plant, it may not be effective in the utilization of the tool for
asset management in a larger plant. Inconsistencies between the control and
device databases often occur as a result and it may be inconvenient to have to
move between different workstations.
It is a good idea to leave the maintenance software running continuously on

the same workstation as the process visualization software. When a “bad” sta-
tus, block error, or abnormal mode is indicated in the operation screen, staff
can check the maintenance tool to see what is going on without having to
leave the station. Figure 7-4 illustrates the above concept.
Figure 7-4. Asset Management Systems with FF
7.3 Calibration of Fieldbus Devices

Calibration is typically carried out on a workbench in the instrument work-
shop. Some simple calibrations that do not require bulky reference standard
equipment can be performed in the field. Since detailed diagnostics and cali-
bration require communication with the device, communication facilities
should be available in the instrument workshop. For a large installation, it is
possible to justify a small stand-alone maintenance station consisting of a
workstation and simple interface with power supply. This is easily done using
a linking device that has integrated power.
A dedicated system for the workshop may not be justifiable for a small instal-
lation. In this case, an alternative is to run one field level network from the
main system into the instrument shop for the sole purpose of calibration and
maintenance. Similarly, the host level network can also run into the shop to a
workstation dedicated to maintenance tasks. It is a good idea to have the
maintenance station connected to the host level network so configuration
changes and calibration record entries are stored in the same database.
Calibration versus Range Setting

Fieldbus technologies do not change the concept of calibration. Calibration is
the correction of sensor reading and physical outputs so they match a stan-
dard. Therefore, calibration means that a known external standard input has
to be applied when performing input calibration and that the output has to be
measured for output calibration. In other words, calibration cannot be per-
formed remotely because it requires someone to connect the external stan-
dard. Calibration is used when the primary value reading does not match the
applied input. Since the primary value reading is later scaled to obtain the
percentage reading, sensor calibration indirectly affects the percentage
reading too.
Calibration must not be confused with range setting; they are two different
things. For analog transmitters, calibration and range setting were performed
using the same set of potentiometers. Therefore, the terms calibration and
range setting have often been confused.
To separate the two functions, true calibration in HART is called trim. In FF,
true calibration is called calibration, whereas range setting is called scale. For
example, transducer block calibration is not used to cancel pressure from a
“wet leg” in level or flow measurement; instead, this is done with the trans-
ducer scale in the analog input function block.
While range setting can be done remotely, calibration requires connection of a

standard reference input. Calibration must occur at the device in order to
apply different known input values one by one to calibrate against. Because
HART transmitters and control valve positioners have 4–20 mA output and
input, respectively, the loop current can also be calibrated, though this is
rarely done. Therefore, HART devices have a “current trim.” This is not the
same case for FF because there is no current signal involved for the
communications.
Range setting for HART transmitters is done primarily to tell the transmitter
the values at which the loop current will be 4 mA and 20 mA. For FF transmit-
ters, range setting is typically done for applications of inferred measurements.
Range can be set remotely without applying any input or measuring the out-
put. Range setting is advisable when the percentage reading is incorrect.
Range setting does not affect the primary value reading.
Note that it is possible to detect a calibration error by changing the range for a
HART transmitter; this is often the practice. The engineering unit reading may
be wrong but the 4–20 mA output is still correct.
Performing Calibration
The advantages of “smart” field instruments containing microprocessors have
been a great advance for industrial instrumentation. These devices have built-
in diagnostic ability, greater accuracy (due to digital compensation of sensor
nonlinearities), and the ability to communicate digitally with host devices for
reporting of various parameters. Refer to figure 7-5 for an illustration of this.
Figure 7-5. Simplified Block Diagram for “Smart” Pressure Transmitter
The term “calibration” in the context of smart/intelligent transmitters is often

misunderstood. There is a big difference between analog and smart transmit-
ters. In analog transmitters, calibration refers to applying a physical input and
turning the trim potentiometers to adjust the sensor so that the output current
becomes correct according to the desired measurement range. In smart trans-
mitters, the “calibration” process is divided into three parts:
• Sensor trim (input trim)
• Range setting (re-ranging)
• Current trim (output trim)
The reason for separating these functions is that the range can be changed
without applying a physical input. This is a huge time and cost saver and is
one of the major reasons for the rapid adoption of smart transmitters. How-
ever, “sensor trim” should not be confused with “range setting.” Both are part
of calibration, but are two different things.
Sensor Trim
All sensors show some drift over long periods. Depending on the type of sen-
sor, it may be due to extreme pressure or temperature, vibration, material
fatigue, contamination, or other factors. Sensor readings may also be offset
due to mounting position.
Sensor trim is used to correct the digital reading as seen in the device local
indicator LCD and received over the digital communication medium. For
instance, if the pressure is 0 bar but the transmitter reading shows 0.03 bar,
then sensor trim is used to adjust it back to 0 bar. Sensor trim can also be used
to optimize performance over a smaller range than was originally trimmed in
the factory.
Sensor trim requires a physical input to the transmitter. Therefore, either the
technician must do sensor trim in the field at the process location or the trans-
mitter has to be brought back into the workshop to perform sensor trim. This
applies to 4–20 mA/HART, Wireless HART, and FOUNDATION Fieldbus, as
well as Profibus transmitters. Sensor trim in the field is performed the easiest
using a hand-held communicator, which is supported by 4–20 mA/HART,
Wireless HART, and FOUNDATION Fieldbus.
Typically, there are three forms of sensor trim:
• Zero sensor trim
• Lower sensor trim
• Upper sensor trim
Zero trim requires the physical input applied to be zero; this is often used
with pressure transmitters. For best accuracy, sensor trim should be per-
formed at two points: one close to the lower range value and the other close to
the upper range value. This is where lower and upper sensor trim is used. A
known physical input is applied to the transmitter to perform the sensor trim,
the technician keys in the applied value (on a computer or hand-held commu-
nicator) communicated to the transmitter, allowing the transmitter to correct
itself. The physical input values applied for lower and upper sensor trim are
stored in the transmitter memory and are referred to as lower sensor trim
point and upper sensor trim point, respectively. Accurate sensor trim requires
applying a very accurate input.
Range Setting (Re-ranging)

Range setting (re-ranging) refers to setting the scale for the 4 mA and 20 mA
points for analog transmitters. Range setting defines at what input the trans-
mitter output should be 4 mA—this is the lower range value (LRV), often
referred to as “zero” meaning 0 percent—and at what input should it be 20
mA—this is the upper range value (URV), sometimes called “full scale” mean-
ing 100 percent.
Note that “span” is not the same as URV. Span is the magnitude of the differ-
ence between URV and LRV.
If the sensor trim and current trim are perfectly done then transmitter range
setting is carried out without applying input and therefore can be done
remotely from the control room. The range setting is now dependent on turn-
down ratio (or) range ability, which is defined as the ratio of maximum to
minimum allowable span. For 4–20 mA systems, the range is set in both the
transmitter and the controller. FF transmitters do not have a 4–20 mA output;
therefore, there is no need to set 4 mA and 20 mA range points. For FF and
Profibus, the range is set in the controller or relevant function blocks.
These LRV and URV values are set in the transmitter by “direct numeric
value” entry or by “to applied input.” Direct numeric value entry means that
the desired lower and upper range values are simply keyed in from device
software or a hand-held field communicator and sent to the transmitter.
Range setting to the applied input requires a physical input corresponding to
the desired range value to be applied to the transmitter. This is often used in
level measurement applications. The Set PV LRV and Set PV URV commands
are equivalent to pushing the “zero” and “span” buttons, respectively, found
on some transmitters.
Calibrating Fieldbus Transmitters

In fieldbus terminology, calibration is often used to mean the configuration of a
transmitter. According to metrology, calibration refers to comparing the trans-
mitter to a traceable measurement standard and documenting the results, so it
is not possible to calibrate a fieldbus transmitter using only a configurator or
configuration software. It is also not possible to calibrate a fieldbus transmit-
ter remotely.
Fieldbus transmitters must be calibrated in the same way as conventional

transmitters, which are done by placing a known physical input into the trans-
mitter and simultaneously reading the transmitter output to see that it is mea-
suring correctly. The input is measured with a traceable calibrator but there
must also be a way to read the output of the fieldbus transmitter. Reading the
digital output is not always an easy thing to do. When fieldbus is up and run-
ning, one person has to be in the field to provide and measure the transmitter
input while another person is in the control room reading the output. Natu-
rally these two people need to communicate with each other in order to per-
form and document the calibration.
When fieldbus and process automation systems are idle, it is necessary to find
other ways to read the transmitter’s output. In some cases, a portable fieldbus
communicator or a laptop computer with dedicated software and hardware is
used for calibration. Calibrating a fieldbus transmitter can be difficult and
time-consuming and often requires an abundance of resources.
As described below, there are some fieldbus calibrators available in the mar-
ket, where the calibrator becomes a participant in the network to communi-
cate and feed the value back to the system.
Documenting Process Fieldbus Calibrator

Some vendors have introduced a documenting process for a fieldbus calibra-
tor, which is a combination of a multifunction process calibrator and a field-
bus configurator. The documenting process calibrator can be used for
calibrating FOUNDATION Fieldbus H1. The documenting process fieldbus cali-
brator can calibrate a fieldbus pressure or temperature transmitter, as it can
simultaneously generate and measure the transmitter input and also read the
digital fieldbus output of the transmitter.
The documenting process calibrator can also be used to change the configura-
tion of a fieldbus transmitter. If the fieldbus transmitter fails in calibration, the
calibrator may be used to trim or adjust the fieldbus transmitter to measure
correctly.
Being a documenting calibrator, it automatically documents the calibration

results of a fieldbus transmitter in its memory, whereupon the results can be
uploaded to calibration management software. This eliminates the time-con-
suming and error-prone need for manual documentation using traditional
methods. The documenting process calibrator is a compact, easy-to-use, and

field compatible calibration solution that offers a lot of other functionality.
Advantages of the Fieldbus Calibrator

The most important advantage of the documenting fieldbus calibrator is the
ability to calibrate, configure, and trim the fieldbus transmitters using a single
unit. Because it is a combination of a calibrator and a fieldbus configurator,
the documenting calibrator performs traceable calibration on fieldbus
transmitters.
Fieldbus configurators and configuration software can only be used to read

and change configurations. The documenting fieldbus calibrator is able to cal-
ibrate stand-alone transmitters or when they are connected to a live fieldbus
as with the FOUNDATION Fieldbus. A separate power supply is not needed
because the documenting calibrator includes an integral power supply for
powering up a stand-alone transmitter during calibration. Therefore, the doc-
umenting calibrator can also be used during commissioning and at other
times when the fieldbus and control systems are still idle.
7.4 FOUNDATION Fieldbus Diagnostics

Here are some of the frequently available diagnostics found in FOUNDATION
Fieldbus–based devices. The specific diagnostics available in a device are ven-
dor dependent.
Fieldbus Device Diagnostics

The devices participating in the network and the accessories need to be moni-
tored for proper operation of the system. The following are some of the diag-
nostics that may be expected from an FF technology–based system:
Device diagnostics: Device diagnostics provide key information on the ability

of the device to measure or control the process, including but not limited to
basic device failure diagnostics and advanced diagnostics. The diagnostics
should be designed by device vendors as per NAMUR NE-107 guidelines. The
following types of diagnostics are generally available:
Basic Diagnostics: Basic diagnostics are device failure diagnostics that are
viewable from any process control host system. They help determine common
problems with the device, communication path, and host system. Diagnostics
that indicate a device failure force the affected loop into Manual (MAN) for
transmitters and IMAN for the PID block in the output device, typically a
valve.
Advanced Diagnostics: Advanced diagnostics include full device diagnostics

so that the device’s health can be determined without removing it from the
process. Advanced diagnostics come in two forms: online and offline.
Online: Online diagnostics perform their function while the device is perform-
ing its normal function and provide the capability to alert Operations in real
time if a problem needs attention. This function provides one of the primary
benefits of FF and should be supported by all field devices.
Offline: Offline tests provide limited benefits and may not justify their cost. FF
devices should be capable of supporting incremental upgrades of the device
description (DD) for extra functionality and/or software revisions in device
memory. Device provides the following diagnostics and key information on
the impact that an output device has on the process, including but not limited
to:
• Position accuracy
• Operating resolution
• Total valve travel
• Packing friction and hysteresis
• Static and sliding friction
• Deadband
• Operating temperature
Dedicated software packages to analyze the positioner data for a valve posi-
tioner are available and fully interoperable with the host system.
Note that the selection of host system asset management, positioner type
(including diagnostic coverage), and interoperable software package is key for
enabling successful diagnostics from FF positioner/valve combinations.
In addition, the power system needs to be monitored since two-wire, bus-

powered devices have more power (>10 mA) for more electronics and more
frequent testing. The powerful microprocessor and sophisticated firmware

can provide additional diagnostics on the power usage as well.
Temperature Transmitter Diagnostics

Refer to figure 7-6 for the diagnostics that can be seen in a representative tem-
perature transmitter. Note that the diagnostics are specific to the vendor and
the figure may not represent all the diagnostics.
• Extreme temperature tracking such as very high temperature, very low

temperature recorded, etc.
• Detects if excess heat from integral sensor is connected to the

transmitter housing, such as sensor electronics temperature
• Captures transients, etc.
Common Diagnostics: Common temperature transmitter diagnostics include

process temperature or cold junction temperature sensor failure, sensor drift,
hot backup warning, calibration error, process temperature or cold junction
temperate reading degraded, electronics or memory failure, configuration
error, and hardware/firmware incompatibility.
Figure 7-6. Temperature Transmitter Diagnostics
Pressure Transmitter Diagnostics

Some of the key diagnostics that are available from a pressure transmitter
using FF are shown in figure 7-7. Typical diagnostics reported via a pressure
transmitter include leaks in impulse lines and manifold, liquid carry-over in
gas streams, plugged impulse line before the reading seizes up, pressure or
temperate sensor failure, electronics or memory failure, pressure or temperate

reading degraded, or local operator interface error. These can be combined
with more versatile statistical process monitoring, diagnostics based on pro-
cess noise, flame instability, pulsations indicating compressor damage,
entrained air causing measurement errors, distillation column flooding, etc.
Figure 7-7. Diagnostics Available from a Pressure Transmitter
Control Valve Positioner Diagnostics

Below are some diagnostics that can be expected from valve positioners.
However, they are vendor-specific and actual information can be gathered
from their manuals. Refer to figure 7-8 for an example diagnostics page.
Common Diagnostics: The most common diagnostics available in the control

valves are partial valve stroke, travel histogram, step response, valve signa-
ture, pressure sensor failure, abnormal drive current, travel deviation, rever-
sal count alert, accumulated travel alert, low supply pressure, high supply
pressure, position feedback sensor failure, etc.
Advanced Diagnostics: In addition, some of the valves provide performance-

based advanced diagnostics, such as actuator/tubing leakage, air supply avail-
ability, calibration shift, etc.
Diagnostics from Discrete Devices

The following are the some of the diagnostics seen from the discrete devices,
which are helpful in maintenance.
• Open/close travel time, indicates poor valve performance

Figure 7-8. Valve Positioner Diagnostics
• Cycle counts, the leading indicator of mechanical stress to drive

maintenance scheduling
• Stuck valve; hand operation required
Process Alarms from Fieldbus Devices

Fieldbus devices have more diagnostics compared to the legacy technology-
based devices, because they have more processing power coupled with
advanced communication capabilities and standards. Since all the devices are
digitally integrated, predictive and proactive maintenance is possible by col-
lating information from multiple sources in the network. Fieldbus integrates
diagnostics from advanced devices and subsystems; previously, fieldbus used
proprietary protocols and software.
Fieldbus devices also report diagnostic alarms faster compared to the earlier
systems. In earlier technologies, since it was hardwired device polling, only
limited tags per hour were possible based on the architecture. This limited the
early warning indicators and some intermittent problems could be missed.
In the case of FF, diagnostics are pushed to the system almost instantaneously
and this early warning gives operators more time to take action before a
device problem affects the process. The alarms generated are time stamped,
with sequence of event recording instantaneous, smart diagnostics. These
alarms can be incorporated into daily work processes. The following are some
critical information that operators can see:
• Normal operation
• Device failure
• Faceplates
• Diagnostics (no device configuration by operator)
When it comes to the real-time process alarms, fieldbus distinguishes device

problems from process problems with real-time status in control strategy. Ear-
lier when devices drive current <4 mA or >20 mA on device failures, the con-
troller may consider the situation as a process problem and PID counteracts
the situation by tripping the loop. In general, the operator cannot distinguish
the difference between a process alarm and a device alarm. Whereas in FF,
device health is indicated by associated status, the controller holds last posi-
tion on device failure, the shutdown is optional, and the operator can easily
distinguish a process problem from a device problem.
Network-enabled diagnostics can help in troubleshooting devices that have

already failed the engineering tool. FF devices have several parameters that
are dedicated to diagnostics, which simplifies troubleshooting. The diagnos-
tics capability is used to spot device failures early so they can be rectified ear-
lier. In other words, early detection enables the minimization of breakdown
time, avoiding unnecessary process downtime. It is a good idea to configure
the process visualization software to display the parameter status and notify
the operator when faults in the field devices are detected. Devices based on
fieldbus technology have wide diagnostics coverage and use additional sen-
sors, other electronics, and self-diagnostics firmware algorithms that can
detect faults based on manufacturer experiences with the failure modes of a
device.
The transmitters detect the failure of external sensors such as thermocouples

or even faulty or poor wiring. Ambient conditions like temperature that
exceed operating limits may also be reported. When the operator is notified of
the fault, he or she can immediately attend to it, which ensures good transmit-
ter performance. It is recommended to use the asset management features to
do as much of the maintenance tasks as possible from the control room. Doing
so lowers the exposure to dangerous plant environments and minimizes the
number of work permits required.
Reducing Unnecessary Maintenance

The biggest advantage of continuous device diagnostics is the ability to
inform operators of failures by the devices themselves. The diagnostics pro-
vided by the field devices can help in assessing whether troubleshooting is
required. After ruling out the devices that are functioning, it is possible to
troubleshoot the remaining devices or the process. It is also possible to review
the results of the diagnostics to determine if the problem is a device problem
or a process problem. This reduces the number of times a device from the field
is taken to the shop, only to be tested and found OK.
Reducing Repair Time

The engineering tool should be used to pinpoint the instrument that has failed
and to determine in greater detail what the problem is before technicians go
into the field. When technicians are provided with information, the right
spares and tools can be taken into the field the first time and perhaps the prob-
lem can be corrected on the spot rather than having to bring the instrument
back to the workshop. For FF, the block error (BLOCK_ERR) parameter is
ideal for gaining a diagnostics overview and is used by the asset management
software to check device health. The information is provided in asset manage-
ment systems with a clear problem and possible repair actions. This will
reduce the repair time for the device.
Predicting Failure in Fieldbus Devices Using Operational Statistics

Continuous operational statistics enable the plant to move to a proactive
maintenance scheme rather than relying on diagnostics. Diagnostics indicate
that a device has already failed, but leading indicators collected in the field
instruments, such as mechanical and electrical failures, etc., that exceed oper-
ating conditions can be used to trip maintenance alarms before the device
fails. The operational statistics can be used to more accurately predict when
maintenance is due since different failures are measured rather than estimated
on an average. Statistics predict degrading device performance that can cause
inaccuracies and faults. Plants can therefore use operational statistics to target
maintenance resources on devices that may soon be in need of repair.
Operational statistics are stored in the transducer blocks. A control valve posi-
tioner is a good example of a device that collects a large amount of operational
statistics. Examples of these are the total valve travel (odometer) and the num-
ber of reversals. Plants can use such information to predict the time of failure
by comparing these statistics to the life expectancy data for critical parts as
provided by the manufacturer. For example, FF valve positioners have stan-

dard parameters for the total travel on the equivalent number of full strokes
and a total travel limit at which maintenance should be performed.
Devices that trigger an alarm when a set limit for the operational statistics has
been exceeded provide early warning indicators. As part of the maintenance
procedures, personnel should use these tools to tap into the information on
these instruments for instant access to the status of any device at any time and
to provide a complete picture of the entire plant.
Maintenance should obtain information from the equipment manufacturers

on the recommended number of cycles before replacement is needed and con-
figure that number into the device’s predictive maintenance alarm. Using the
engineering tools, it is easy to determine when several devices may be rela-
tively close to needing service. It is also important to configure the host to
annunciate maintenance alarms to the operators.
The maintenance procedures should include a step for keeping a record. For
example, a record should be kept of the number of reversals performed
between services and the statistics counters should be reset after repair.
If the manufacturer recommends valve stem packing replacement after a cer-

tain number of reversals, this number should be keyed into the positioners as
an alarm limit. When the limit is exceeded, the alarm alerts the technician that
service is due. This can drastically reduce the number of unscheduled shut-
downs caused by unforeseen failures. Knowing about imminent failure in
advance helps reduce the chances of a surprise shutdown and allows for
spares to be ordered beforehand. Maintenance can be proactively scheduled
at a convenient time when all the devices on a unit can be serviced together.
Spotting Process Variability Using Operational Statistics

Operational statistics provide the ability to spot poorly tuned control loops.
For example, a rapid increase in the number of reversals is a clear indication
that the loop is oscillating. Operational statistics can thus help not only in
maintenance but also in optimizing the process by indicating that it’s time for
tuning or for a different control strategy. It is therefore a good idea to review
the operational statistics from time to time in order to spot unstable behavior
and reduce process variability.
Information from Fieldbus Devices

Fieldbus devices store data pertinent to themselves and their process applica-
tions. This information does not affect the operation of the devices but is use-
ful for improving maintenance practices.
Identification
FF has standard parameters for the device tag and manufacturer, description,
device type, revision, serial number, unique ID, and so on. The configuration
tool can be used at the time the device is commissioned and during nodal
operation to identify the device. It is good practice to always enter the device
tag, description, and message and to update it whenever changes are made.
Materials of Construction
It is possible to retrieve other useful information like materials of construction
for the parts wetted by the process in a pressure transmitter from fieldbus
devices. This information can be used to order identical devices or to assess a
device’s suitability for a certain application. Standard parameters in FF
include the material for the sensor diaphragm and the fill fluid. Specific
parameters are used in the HART protocols, as well as for other parts. It is
good practice to update these parameters with any changes that have been
made in the actual parts (as happens at the time of replacement of some parts)
to keep the record current.
Valve and Actuator Information

FF valve positioners have standard parameters for storing information not
only about themselves but also about the rest of the valve packages they are
part of. The FF transducer block contains standard parameters for the manu-
facturer, model, and serial number of the valve and actuator.
Replacing FOUNDATION Fieldbus Devices

FF instruments do fail from time to time and all will eventually need to be
replaced. Once a new device has been connected, it is necessary to download
the configuration to it. In this situation, it is only necessary to download the
configuration for the replaced device without having to download it into all
the devices on the network. Since the device’s entire configuration is down-
loaded at one time, the device can be quickly brought online. There are speci-
fications from the FF on the host system’s ability to handle the device
replacements with like devices, unlike devices, etc.
When the plant maintenance identifies a need to replace a device, it may be

with an “identical device,” a “like device,” or an “unlike device.” If there is a
need to replace a device with the same type of device from the same vendor,
etc., then it may be called an identical device replacement. If the replacement is
the same device with an upgraded version, then it may be called a like device. If
the replacement is performed with a different type of device or is from a dif-
ferent vendor, etc., it may be called an unlike device replacement. Table 7-1
defines these terms and the different changes that might occur in the device
after the replacement.
Table 7-1. Device Replacement Differences

Characteristic Identical Device Like Device Unlike Device
Manufacturer Same Same Different
Device Type Same Same Different
Device Revision Same Newer Different
Capability Level Same Same Different
Device replacement is crucial in the maintenance of the FF considering the

critical need for replacement of the devices in late hours and also the complex-
ity involved compared to the legacy 4- to 20-mA-based signal communication.
Reducing the complexity and improving automation allows things to happen
more smoothly on off-shifts. Technicians need assistance with preloaded con-
figuration, simplified offline configuration, template-based approaches, wiz-
ard-based approaches, etc. The ultimate goal is to have the device replacement
experience to the technician be much better than with the legacy system.
Interoperability versus Interchangeability

When a failed device is replaced with an identical model, it is possible to sim-
ply download the configuration. However, if a “different” device or even a
“like” device takes the place of the failed device, it is necessary to consider the
portability of the configuration. For FF, basically every kind of device has a
specific extension to the standard set of parameters in the transducer block. If
a “like” device type replaces an existing one, it is necessary to create a new
transducer block on the configuration, which is easy as only a few parameters
have to be set (often only the mode). The resource block usually has no exten-
sions and is supported by all devices. This is most unlikely to cause any
interoperability problems.
Many devices, however, have enhanced function blocks for special functions.
If it is necessary to replace a device in which a manufacturer-specific block is
being used with a device that does not have such a block, the function block
can be allocated to another device with such blocks available in the network.
Alternatively, the control strategy can be changed to perform the same func-
tion by using an equivalent block or set of blocks. The same applies for blocks
that have proprietary parameters, though this involves additional work. It is
therefore a good idea to use standard blocks from the protocol because other
devices often support the same blocks. Likewise, different devices support
different types and quantities of the function blocks that make up the control
strategy.
Some FF device types have a limited set of function blocks in their library and
a fixed quantity of each that is supported. It may be difficult for a device with
a fixed block set to replace another device because the two devices may not
support the same blocks. However, a device of type “different” that supports
dynamically instantiable blocks usually has a larger library of function blocks.
As a result, there is a greater chance that the new device supports the blocks
used in the old device. This is particularly true if the standard FF blocks are
used.
NAMUR in FOUNDATION Fieldbus

Better diagnostics is one of the great promises of digital networking technol-
ogy for field devices. All “intelligent” devices provide some level of diagnos-
tics. There are several key differences with FF that make it unique in its ability
to provide diagnostics. Two of these key differences are the sheer volume and
the frequency of diagnostic data provided. FF devices can handle multivari-
able measurements and the transmission of multiple diagnostics data at the
same time.
The diagnostics do not stop at the sensor/actuator. Diagnostic data can be pro-
vided for electronic failures, configuration, or servicing failures that are pri-
marily human intervention issues and application issues or process issues that
affect the measurement. These multiple levels of diagnostics add up until the
point is reached where there could be over 20 diagnostic parameters for FF
devices, with more complex devices and actuators having hundreds of
parameters.
It is necessary to ensure proper management and organization of this data to

get useful information out of these diagnostics. Some diagnostics parameters
are manufacturer specific and can pose a real challenge. Parameters from
device to device may not be the same. Based on the root cause of a problem,
however, diagnostics can be categorized or assigned to different functional
areas such as electronics, configuration, application and so on.
FF also has a publish/subscribe architecture. Data is continuously transmitted

to any source that subscribes to it. The role-based diagnostics (as shown in fig-
ure 7-4) provided by FF facilitates the right people getting the right informa-
tion at the right time. FF also supports alarm and event notification.
Diagnostic data and alerts can be provided instantly, status can be constantly
updated, and information can be constantly recorded and time stamped.
These features are also unique to FF. Time stamping ensures that users know
exactly when a problem occurred even if the actual diagnostic information is
received at a later time. These elements of increased volume and frequency of
diagnostic data provide many advantages, but care must be taken to turn the
data into useful information and careful attention must be paid to managing
this information.
Not every diagnostic alert should be considered an alarm for the operator to
act upon. For example, according to the ISA-18.2 standard for alarm manage-
ment, an alarm must require a response from the operator. The increased vol-
ume and frequency of information means that mechanisms must be put into
place to filter and contextualize information to make it easier for users to man-
age, so that people only see what they need to see, when they need to see it.
The FF specification is a continuously evolving open specification. The stan-

dard can adapt to changes in technology as they come into the marketplace. A
need that was identified early during the development of FF was to update
the specification to address the management of diagnostics data and make it
easier for end users.
The Fieldbus Foundation developed the Field Diagnostic Profile portion of the
specification to describe a base parameter set and characteristics common to
all devices supporting the Field Diagnostic features. Rather than introduce
significant changes to the current FOUNDATION Fieldbus protocol, the new
Field Diagnostic Profile specification builds on the existing diagnostic capabil-
ities of FOUNDATION Fieldbus equipment and at the same time, adds a greater
degree of organization so field instruments can represent their diagnostics in a

more consistent way.
The FOUNDATION Fieldbus Field Diagnostic Profile specification was defined

to make it easier for users to access and configure the diagnostics in fieldbus
devices, regardless of which manufacturer’s device or system is used. The
Diagnostic Profile includes a standard and open interface for reporting all
device alarm conditions and provides a means of categorizing alert conditions
by severity. The technology facilitates the routing of alerts to appropriate con-
soles based on severity categories selected by the user. In other words, it sends
the right information to the right person at the right time without flooding the
operator with alarms that are irrelevant to his duties. The Field Diagnostic
Profile also provides recommended corrective actions and detailed help, in
addition to indicating the overall health of the device. The Field Diagnostic
Profile specification puts in place all the mechanisms needed to provide con-
text to diagnostic data and turn it into useful information.
NAMUR is an international association of process automation industry end

users that publishes recommendation documents to help end users by sharing
best practices and guiding suppliers and industry foundations on future tech-
nology and product development. NAMUR represents approximately 15,000
process control experts, of whom approximately 300 are active in 33 working
groups. Member companies include names like Novartis, BASF, Bayer,
Evonik, Shell and Clariant.
The roles of the operator and maintenance technician as well as their impacts
on plant reliability and uptime is of particular concern to NAMUR.
Unplanned downtime is one of the primary concerns for the process indus-
tries. According to ARC Advisory Group (www.arcweb.com), unplanned
downtime accounts for around 20 percent of all production in the process
industries. A single unplanned shutdown can wipe out a plant’s profit for the
year.
In the same piece of ARC research, it stated that 40 percent of unplanned

downtime events could somehow be traced back to the operator or the human
in the loop. It is not appropriate to always blame the human in the loop, how-
ever, since that person may be working on faulty information or may not have
the right information presented to them at the right time. NAMUR NE107 cat-
egorizes internal diagnostics into four standard status signals, which are
described below.
Each of these categories can also contain greater detail. In the case of failure,
for example, can the failure be traced to the device or the process? Is mainte-
nance required immediately or is the requirement more for long-term mainte-
nance? The ultimate result of this is a series of new field diagnostic alarms that
correspond to the four primary diagnostic categories outlined by NAMUR in
its document. Several standardized and therefore manufacturer-independent
parameters are available to configure the NAMUR category, the priorities,
and the filter mechanisms for the alarms. With NAMUR NE107 diagnostics
built in, unwanted diagnostics can be turned off and it is possible to configure
how the diagnostics are reported. This supports the configurability mandate
of NAMUR NE107. Providing recommended actions and enabling simulation
allows the information to be presented in greater context.
The Field Diagnostic specification stipulates that diagnostic data be provided

in primary groupings that correspond to the NAMUR NE107 recommenda-
tions. As shown in figure 7-11, the four primary alarm and alert categories
according to NAMUR NE107 are:
• Failure
• Out of Specification
• Maintenance Required Check Function
• Function Check
Table 7-2. Definitions of NAMUR NE107 Status Signals

Failure Output signal invalid due to malfunction in the field device or its
peripherals.
Cause of failure: internal or external

Out of Specification Out of specification means that the device is operating outside its
specified range or that an internal diagnostic indicates deviations
from measured or set values due to internal problems in the device or
process characteristics (e.g., bubble formation in flow metering or
valve sticking).
The device is being operated out of specification, uncertain value due

to process and environment influences.
Table 7-2. Definitions of NAMUR NE107 Status Signals

Maintenance Required Although the output signal is valid, the wear reserve is nearly
exhausted or a function will soon be restricted due to operational con-
ditions; e.g., build-up of deposits.
Maintenance needed short term or midterm.

Function Check Output signal temporarily invalid (e.g., frozen) due to ongoing work
on the device.
Change of configuration, local operation, substitute values, etc.
Figure 7-9. NAMUR Status Descriptions and Symbols
When implemented as a function in the DCS, providing these details makes it

possible for the operators and service personnel to trigger various actions.
All field devices must categorize the internal diagnosis results into the status
signals as per the alarm categories. Configuration should be free as user reac-
tion to a fault in the device may be different depending on the user’s require-
ments. It should also be possible to switch off individual diagnostics as
required. However, the manufacturer should always set up a standard

configuration.
The status signal refers to the device. In multivariable devices, it can also be
allocated to the individual measurements. The aim of this categorization is
that the plant operator is not inundated with measurement details, which
might distract him and make him lose oversight of the plant, or at any rate,
not take action as needed. That is why it is important for the plant operator to
see only these status signals.
The action the operator might take, besides informing a specialist, might
include switching the faulty loop to manual operation. If a “maintenance
required” warning comes up, the appropriate action is initiated either auto-
matically or by the operator. When a function check is indicated, a DCS might
conceivably maintain the relevant variable constant or a manual analysis
might be appropriated. Detailed information can be read out by the device
specialist (e.g., someone from the maintenance workshop) who will then initi-
ate the appropriate action. This detailed information is available to the main-
tenance person in text form.
It is also valuable to make a distinction between instrument conditions and

process conditions. The ability to differentiate between instrument and pro-
cess conditions can prevent an unplanned shutdown and result in signifi-
cantly increased process reliability. Instrument conditions include problems
with the sensor, electronics, and configuration. Process or environment condi-
tions include those related to the process itself, while instrument failures due
to operating outside of specified operating conditions should be grouped with
instrument failures.
Diagnostic information from FOUNDATION Fieldbus devices is required by a

variety of different host systems, from DCS hosts to plant asset management
systems and hand-held devices.
Field Diagnostics should provide enough information through its use that the
first level of response can be determined without additional documentation.
The Device Description (DD) help or text displayed for the enumerated value
associated with the Recommended Action contains information to support
this.
Some hosts use the alert mechanism to direct the Field Diagnostics to different
locations. The Maintenance and Check Function may go to the maintenance
console and/or a maintenance log file. The Failed and Off Specification may
pop up in front of the Operator. This is for the host and user to decide.
Even with all the structure placed in the Field Diagnostic Profile, the condi-
tions are not expected to identify explicitly the root cause of the problem, but
rather to identify actions to be taken to fix the problem, including the
following:
• Replacing the device
• Replacing a part of the device
• Correcting a configuration problem
• Fixing something outside of the device
FOUNDATION Fieldbus provides a 32-bit bitstring for suppliers to allow them

to distinguish between 31 levels of device failures in increasing level of prior-
ity at the bit level. If there are more than 31 device diagnostic events, the
developer must group them by definition into these bits. Then, by using the
FOUNDATION Fieldbus “extended” parameters in the resource block, more
detailed information can be made available about these conditions to allow
maintenance or operations to determine the root cause of the problem.
For example, bit 31 could be related to an additional 32-bit parameter that

could represent a diagnostic event. The relationship between the high-level
standard 32-bit string of parameters and the extended parameters is some-
thing that is hard coded in the firmware. The device vendor may add as many
of these parameters as are necessary to describe what lower-level conditions
may be the root cause.
8
Benefits of Using
FOUNDATION Fieldbus
8.1 Project Lifecycle Benefits

Using FOUNDATION Fieldbus technologies in projects offers various benefits
conceptually, as indicated below. It is important to articulate the benefits on
both a quantitative and a qualitative basis to justify the cost of purchase and
deployment in upcoming projects. Engineers can use this information to
derive the benefits and convert the same into dollars on a case-by-case basis.
• Interoperable products & systems
• Elimination of proprietary protocols
• Technology enables innovation by manufacturers
• Device diagnostics
• Lower installation costs
• More information from the final control elements
• Multiple inputs from one device
• Easier to add new instrumentation
• Reduced wiring
• Reduced terminations
• Reduced commissioning time
277
• Ability to implement control in the field
• Reduced control room space
• Instrument diagnosis
FF technology has features that can lead to huge initial and long-term savings,
but it is easy to miss the big picture. The savings on the cable are the most vis-
ible, but there is more cost reduction that can be achieved using FOUNDATION
Fieldbus. The initial savings include lower cost for purchase, engineering, and
installation. The long-term savings include lower costs for maintenance and
operations using asset management and also lower costs for expansion and
change.
Cost savings for a project using FOUNDATION Fieldbus vary with the labor
costs of the country in which the plant operates, the plant size, and the nature
of the plant. There is no standard way to calculate the savings. The savings in
cost and time for the plant may be analyzed in terms of its unique conditions
based on the possibilities offered by the fieldbus technology.
Because long-term savings are greater than procurement and installation sav-
ings, the return on investment on Fieldbus-based instrumentation and control
is certain over a period of time. It therefore also makes sense in some cases to
re-instrument an existing site with fieldbus. FF devices are slightly more
expensive than the conventional counterparts, which offset some of the sav-
ings fieldbus provides, but overall there are still significant cost savings.
Preparing a business case and doing an economic analysis between conven-

tional and FF systems assists in identifying potential savings and is worth the
effort, but there is no standard way so far to do it.
In general, the phases of a project’s lifecycle include engineering, installation,

operations, and maintenance as shown in figure 8-1. The costs are divided as
Capital expenditure (CAPEX) and Operation expenditure (OPEX) based on
the phase of the project.
The savings in each phase have a different impact on the plant financials than
the others based on the type of the expenditure. Some are one-time large
expenses and others are small but repetitive expenses. The FOUNDATION Field-
bus benefits offered in each of these lifecycle phases are listed in figure 8-1.
Chapter 8 – Benefits of Using FOUNDATION Fieldbus 279
Note that they are indicative, not specific, and are meant to trigger the
thoughts of users in deriving the actual numbers.
Figure 8-1. Project Lifecycle Phases
From figure 8-1, the benefits of a plant enabled with FF technology can be
organized into four general categories:
• Engineering benefits
• Installation benefits
• Operational benefits
• Maintenance benefits
As a practical matter, no one vendor can meet all of a user’s needs. Fieldbus
ensures interoperability, allowing the user to choose the best device for each
application. Fieldbus allows mixing and matching to do the job. All these ben-
efits translate to savings and offer a competitive advantage to the user.
Installation benefits include lower wiring costs, remote configuration, and

multiple suppliers. There is less wiring because of the multidrop capability.
Fieldbus access to parameters of the device and its function blocks permit a
device to be configured remotely, over the wire. This means that configura-
tion software can perform legitimacy checks, prepare a complex database, and
automatically document the configuration.
Operational benefits include higher accuracy, more precision, better control,

safer control, more information, reliable and secure operation, and less down
time. Digital transmission avoids the losses in accuracy caused by analog con-
version. IEEE floating-point representation provides seven digits of precision,
much more than with analog transmission. The ability to detect a bad signal
yields better and safer control. Whereas an analog signal could be in error by a
significant amount (e.g., 20 percent), and the error could go undetected. No
such error can be introduced and go undetected with digital transmission.
Transmission security checks ensure detection of transmission errors and
recovery techniques ensure reception of data or at least the knowledge that
data was lost. Again, all these benefits translate to savings and offer a compet-
itive advantage to the user.
Maintenance benefits include increased reliability (digital circuits are more

reliable than analog), remote diagnostics, and competitively priced replace-
ments. Remote access to parameters permits devices that diagnose themselves
to be able to present the diagnostic information over the wire and even to pro-
vide alarm and event notification where needed. This will save many trips to
locations that are high, hot, wet, dangerous, hard to get to, or otherwise inac-
cessible. Refer to figure 8-2 for the systems enabled with FF for their ability to
give remote diagnostics.
Figure 8-2. Remote Diagnostics from F OUNDATION Fieldbus
New features will be created as fieldbus enables innovation by allowing the

microprocessor capabilities to be exploited in a useful manner. Since the stan-
dard ensures interoperability, when a fieldbus device needs to be replaced,
competition will permit the selection of the best device for an application.
Again, all these benefits translate to savings and offer a competitive advan-
tage to the user.
The key savings in each phase of the project when FF is the choice of the tech-
nology are:
• Plan and Installation
– Reduction in cost for wiring, barrier, marshalling rack, and junction

box
– Reduction in cost for control system: I/O interface
– Reduction in cost for power supply unit and number of cabinets
– Reduction in control room size
• Operation
– Increased information for better operation
– Improved accuracy of measurement and control
– Enhancement in control function and performance
– Fewer process upsets
– Improved throughput
• Maintenance and Improvement
– Online diagnosis enables true proactive maintenance
– Reduction of instrument stock for maintenance
– Increased asset intelligence methods to enhance variable cost

management
Cost of Purchase
FF technology helps lower total installed project cost and reduce commission-
ing time for field instruments and DCS components. The cost benefits from
the engineering, construction, commissioning, and startup phases in the life-
cycle of the projects or the benefits seen in the planning and installation in the
instrumentation project phases can be considered as CAPEX savings.
Host System and Devices

To compare apples to apples, host system and field device prices should be
compared between a conventional and FF system selected for the project. On
the host system or DCS side, the price for software and hardware with licens-
ing fees, costs for different I/O cards, costs of termination panels, and costs of
I/O card carriers should all be considered. In general, the cost of fieldbus
devices is slightly higher than conventional 4−20 mA devices, but the need for
fewer I/O cards offsets some of the cost increase associated with fieldbus
devices. Most of the hosts have FF interface cards, which can support two or
four segments per I/O card with 16 to 32 devices per segment. That way the
footprint for DCS I/O cards is smaller, as one FF interface card can support 32
to 64 I/O points per card.
In addition, the multivariable measurement capability of newer FF devices

can increase the I/O count per FF interface card. Figure 8-3 illustrates where
the multivariable transmitters reduce the number of transmitters and there-
fore the associated costs of all the interfacing hardware.
Figure 8-3. FF Network Using Multivariable Transmitters

For example, a new multisensor temperature transmitter supports eight tem-

perature measurements per device, so with one FF H1 interface card, it is pos-
sible to measure 48 temperature points. The above can be practical
considering all measurement points have a scan time of 3–4 seconds.
The list of multivariable devices registered at Fieldbus Foundation is growing

day by day. FF implementation brings additional costs for the power supply/
conditioner and terminators per segment. For a true comparison, the cost of
these components should be included in the cost analysis.
The requirement for hazardous area classification should also be considered.

This may bring additional savings since one barrier can be used for a complete
segment in FF.
Because of its modular architecture, a system that is based on fieldbus tech-

nology requires a plant to purchase and install significantly less hardware
than a traditional system. However, the manufacturer’s development cost for
conventional systems is low due to their long-time presence, which can
reduce the price of a system. Nevertheless, a conventional system is more
expensive to operate in the long run, resulting in a higher total cost of
ownership.
The savings apply to the part of a system that is purposely built for fieldbus
technology. Other sections of a site that use conventional technology reduce
the average savings. Some systems may be built on architecture that prevents
some savings from being achieved such as Control in Host, entity-based
Intrinsic Safety barrier, etc. Each installation is different and therefore the total
savings vary, but significant savings can be expected.
Fewer Parts
With fieldbus technology, reduction in hardware is seen at all levels of the
system architecture, from field instruments to workstations. Fieldbus technol-
ogy largely eliminates the need for I/O subsystems. As the number of compo-
nents that are needed is reduced, the panels that are installed also become
fewer and smaller. The large panels associated with the traditional systems
are no longer required. Fewer, smaller, and lighter components also mean
reduced shipping costs.
Because fieldbus-based systems can fully utilize multivariable transmitters

and valve positioners, the number of devices and associated wiring and I/O
can be reduced. For example, in a density measurement in a tank, a single FF
transmitter can replace as many as three conventional transmitters. Installing
a single temperature transmitter with two independent inputs reduces the
number of transmitters to one-half, resulting in a 50 percent cost saving.
The only means analog systems have to detect device fault is using discrep-
ancy checking to compare the signal from two redundant transmitters—a
solution too costly for all but a few critical control loops. Devices using field-
bus technologies detect their own faults and communicate their health. As a
result, one device can be used instead of two, reducing the cost by 50 percent
for critical loops.
The possibility of multidropping multiple devices on a single pair of wires

dramatically reduces the amount of cable required. The amount of cable
reduction depends on the wiring scheme, the number of devices installed on
each network, the distances, and whether or not the installation is in a
hazardous area.
The main cable reductions are seen on the multicore home run cables from the
field junction box to the IO marshalling panels. By putting 12 devices, some
control, and some monitoring on each of the FF H1 networks, the cabling and
most importantly, the associated number of terminations, is already reduced
by more than 90 percent. This concept still leaves room for more devices. The
cost reduction is significant, especially for armored cable (see figure 8-4).
Additional related hardware savings are gained since fewer conduits, cable
trays and ladders, and cable glands are required than in a conventional sys-
tem, as shown in figure 8-5.
Using the multidrop capability, several devices may be connected to a safety

barrier, thus reducing the number of barriers required in an intrinsically safe
installation. The number of devices per barrier depends on the device’s power
consumption, the barrier’s current capacity, and the intrinsic safety methods
being followed, among other factors. Using the traditional Entity concept that
considers the cable to be a concentrated capacitance and uses a linear barrier,
some four devices can typically be connected to each barrier, but using the
Figure 8-4. Savings in Wiring
Figure 8-5. Fewer Terminations

Fieldbus Intrinsically Safe Concepts (FISCO), increases it to as many as eight

devices per segment.
At the same time, it also allows for longer cable (i.e., in terms of quantity in the
reduction in cable is 75 to 87 percent). However, because of the price differ-
ence, the dollar savings are slightly lower compared to a conventional barrier.
Cable length is a critical factor since longer cable allows the safety barriers to
be mounted outside the classified area where special enclosures are not
required (see figure 8-6).
Figure 8-6. Savings in Barriers
Similarly, the marshalling panel also becomes smaller and simpler because
the number of wires is reduced as a result of multidropping. Use of digital
communications eliminates the requirement of costly analog inputs and out-
put modules. A typical scenario would consist of a single linking device pro-
cessor module with four integrated fieldbus ports connected directly to 64
devices in a safe area or 48 devices in a hazardous area. Such a scenario
reduces the cost significantly compared to a conventional system, which
would require eight analog I/O modules of eight channels each.
The simplification is greater for the loops where redundancy is required.

Depending on the fieldbus versus conventional mix, the analog I/O reduction
can approach 100 percent. As the number of modules is reduced, the associ-
ated racks, nests, I/O network, and other mounting hardware are eliminated,
as are the power supply components for all the modules. The termination
cards used for conventional I/O are not required for fieldbus communication.
The I/O subsystems for fieldbus devices are therefore much simpler and less
expensive than for a conventional solution.
In a system based on standard fieldbus technology, the needs for gateways

between different network protocols is greatly reduced and often eliminated.
Similarly, there is no need to develop custom device drivers, eliminating a
large expense.
Using the FOUNDATION Fieldbus capability to distribute control strategy exe-

cution into the field devices enables plants to drastically reduce the amount of
centralized CPU processing power required. Hence the number of controller
modules can be cut since they are basically only needed for the less computa-
tion-intensive discrete control tasks, resulting in great savings.
Less Expensive Parts

A system based on open standards such as fieldbus technology further helps
to lower system cost by not being tied to a single manufacturer. Independent
of which host system is chosen for the system, the field instruments and other
system components and software can be sourced from a variety of other sup-
pliers. Selecting the devices with the best cost/performance ratio is recom-
mended; open competition lowers prices.
This compares favorably to traditional proprietary systems where field

devices have to be bought from the host vendor in order to achieve better inte-
gration. Having locked in the customer, the supplier could charge a higher-
than-normal market price.
Host-level networks based on Ethernet use standard interfaces and other net-
work hardware that utilizes standard communications software embedded in
a workstation operations system. Ethernet components are sometimes called
commercial-off-the-shelf (COTS) products, which are available just about any-
where at extremely competitive prices, promoting the economies of scale that
can only be attained by sales volumes in the millions of units per year, com-
pared to proprietary networking parts, which are assembled only in the
hundreds.
Less Spare Capacity and Fewer Spare Parts

Adding control loops or monitoring to a conventional system means adding
lots of hardware. Installing additional equipment to accommodate later modi-
fications from the original plan is troublesome and disruptive; hence, the sys-
tem suppliers charged high rates for engineering changes. As a result, in the
past plants purchased systems with lots of spare capacity for I/O modules,
rack slots, controller’s memory, and processing capacity. This over-capacity
meant that plants were buying a system far bigger and costlier than they ini-
tially needed just to be on the safe side.
Expanding or changing fieldbus-based systems is much cheaper and simpler

because they have much less hardware compared to the traditional systems,
eliminating the need to invest in spare capacity.
A lean system has less hardware that can fail in the first place. Therefore,
fewer spare parts need to be kept in the inventory, which further reduces the
overall system cost. In addition, standards-based equipment is provided by
many second sources, so if a spare transmitter cannot be delivered in time
from one supplier, another brand with shorter lead time can be used in its
place. As a result, keeping spare parts and stock on hand is less critical and
expensive contracts for the manufacturer to provide on-time stock may be
avoided.
Less Space
The reduction in hardware means smaller panels and consequently a smaller
space requirement. Since the wiring is reduced there is often no need for ele-
vated floors. This can add noticeably to the savings, especially on rigs or other
locations where space is at a premium.
Engineering Savings
Engineering cost savings can come from configuration and documentation
savings. Sometimes, however, it is difficult to justify savings in configuration,
as it may need the same amount of time to configure a FF DCS as a traditional
DCS. FF field devices can be preconfigured at the factory. The upload capabil-
ity of the DCS to bring field device information into the DCS database can
have significant savings on the DCS configuration side, which converts into
savings for engineering efforts. Engineering savings from loop drawings to
segment drawings is simple compared to the traditional DCS configuration
with I/O assignment, etc. The savings become more in the case of changes
done to the segment after the completion of engineering. Refer to figure 8-7
for the simplified segment design.
The simpler hardware architecture and reduced complexity in a fieldbus sys-

tem greatly simplify project engineering and design work from the conceptual
design stage, through the detail engineering and documentation phases to
installation and so on. Fewer engineering hours spent means lower cost. Proj-
ects can be run “fast track” to get the plant up and running sooner and this
starts paying back the loan sooner.
Figure 8-7. Less Hardware Engineering

Faster System Design

It is easier to define host I/O requirements for fieldbus devices than for con-
ventional systems. The only requirement is to get an estimate for the complete
systems by estimating the communications port count for the plant and the
number of fieldbus devices the system will support. Unlike with a conven-
tional system, all fieldbus devices are alike in terms of communications and
the methods of interfacing with the host systems, so it is not necessary to spec-
ify if FF devices are analog or discrete, input or output, single or multivari-
able, or used for monitoring or control. With fieldbus in these cases, there is
no need to select different types of I/O modules either, thereby reducing con-
ceptual design time. The detail design phase is also shorter, owing to the elim-
ination of calculations for I/O modules, power consumption, and the like.
Simpler panels may be designed faster.
In the case of FF, the functional requirements for control are also much easier
to define. Previously, it was necessary to explicitly define every required func-
tion in lengthy specifications; for example, it was necessary to define that the
conventional PID block should have functions, such as reset windup protec-
tion, cascade set point, override, deviation alarm, and so on. Now program-
ming languages define the standard function block features in FF. Therefore,
the only thing that needs be specified is which of the blocks is required since
the block features are implicit.
Faster Vendor/Device/Instrument Selection

With conventional systems, selecting a particular brand of host and controller
for a system means that the bulk of the field instruments have to be bought
from the same supplier to ensure compatibility. Selecting that one supplier
could be a difficult compromise; for example, it can mean choosing between
the most powerful controllers and the most accurate transmitters or the quiet-
est valve. Controller features and device performance for different systems
have had to be weighed against each other.
The fieldbus standard simplifies the selection process since the best devices of
each type can interoperate with one another, which makes it possible to finish
the bill of materials faster. Moreover, one type of positioner is used for all
fieldbus devices, reducing the types that must be chosen. Similarly, a single
safety barrier type works for all fieldbus devices, eliminating the tedious pro-
cess of comparing entity parameters. When multivariable capabilities of
devices are used instead of individual units, the number of devices that needs
to be specified is reduced.
Faster Control Strategy Configuration

FF technology reduces configuration, development, and entry time at all lev-
els of the system, from field device to host. For example, ranging is not neces-
sary for field devices in most applications because FF uses the engineering
units when they digitally communicate with a controller rather than scaled
ranges such as 4–20 mA. Unlike a conventional system, if the value in fieldbus
is 200 kPa, two hundred is transmitted, not X% or Y mA, etc.
Since scaling is eliminated, device configuration and verification work is

reduced. All device strings such as sensor type selection can be made offline
before the device is manufactured and downloaded during commissioning.
This allows configuration to start immediately upon project kickoff.
The analog I/O modules are essentially eliminated and therefore there is less
need for I/O subsystems configuration. This saves time in comparison to a
conventional system where racks, modules, and channels must be configured.
I/O module auto detection is not a solution for projects on the fast track since
the engineering is often completed before the hardware is manufactured and
eliminating I/O altogether is the faster solution. A standard fieldbus protocol
eliminates the need to program proprietary drivers and map custom data,
both of which are time consuming, subject to error, and can cause costly
delays in projects.
For a host using FF, the standard programming language facilitates the devel-
opment of the control strategy and reduces configuration time. Many of the
interlocks require absolutely no additional configuration effort, which mini-
mizes configuration time and configuration entry time. Automatic device
identification and address assignment enables configuration work based
entirely on tag. It is more intuitive, less subject to error, and infinitely faster
than the mapping of device addresses and memory registers as in the older
systems.
Less Documentation
Reduced hardware translates to reduced project documentation. Fewer
instrument specifications, indexes, and data sheets have to be generated
owing to the use of multivariable devices instead of many single point units.
Multidrop wiring means that one network drawing can be made per network
instead of 16 individual loop drawings as in the point-to-point scheme. This
reduces effort by as much as 90 percent.
Since the I/O subsystem is gone, there is no associated cross-reference listing.

The configuration tool instrument database stores a copy of the fieldbus
device configuration data, such as sensor types and ranges, ready for print out
or export to, for example, Microsoft Excel. During commissioning, the
changes made are also stored, creating an updated “as built” configuration
database electronically. Such documentation features are not possible in DCS
where a handheld is used for device configuration.
Construction Savings
The less hardware there is to install and wire up, the greater the savings.
Faster Fabrication
Reduced equipment means smaller panels that have less marshalling, termi-
nation, I/O modules, and power suppliers inside. This makes them faster to
build and wire. Using a linking device with built-in device power and proces-
sor results in a solution that is significantly more compact and faster than con-
ventional I/O.
Easy System Verification

Since I/O subsystems requiring a calibration check are eliminated in a fieldbus
system, there is no such test, drastically reducing the total verification time. A
simple check of the communications to verify the integrity of the communica-
tions is sufficient. There is a much less pressing need to check the consistency
of scaling between devices, controllers and workstations, since values are
transmitted in engineering units. This is also a key time saver since in the past
such checks were also done on different software tools and a handheld. This
characteristic of fieldbus technologies reduces the risk of alarm and shutdown
trips not working when they should. Since communications is based on tags,
this system eliminates the process of verifying parameters mapping to the
device address and memory registers.
Less Installation Works

Multivariable devices cut the number of devices to be installed for certain
applications by a factor or two or three. Fewer pipe stands and process pene-
trations means a reduction in installation time. Depending on the ambient
conditions, the associated heat tracing or shades are reduced, too. With field-
bus, it is possible to install devices where they previously would never be
installed because gaining access to check them would be too difficult. Fieldbus
allows remote diagnostics so that the devices need to be physically checked
less frequently, which makes easy access less critical. Improved performance
may be an additional bonus. Since the data from a hard-to-reach or hard-to-
see device can be transmitted to any other device, it is possible to have the
indication on a more visible device if field display is desired. These features
provide more flexibility to the installation works and hence reduce the com-
plexity of the installations.
Less Cable Run and Termination

The reduced wiring made possible by fieldbus device multidropping and
multivariable capability means that fewer cables need to be pulled. Using
fieldbus reduces what for conventional systems is a major logistical effort to a
simple task. With fieldbus, fewer cable conduits are required for protection or
to make the installation flameproof.
A reduced number of cables also translates into reduced man-hours spent to

install all of these elements compared to what is required for a conventional
wiring scheme. Reduced wiring also means fewer terminations; that is, fewer
wires to cut, strip, crimp, label, and connect. By using fieldbus, as many as 10
terminations per loop can be eliminated, counting from device to marshalling
panel. Each termination takes a couple of minutes and this becomes a major
cost reduction in comparison with a conventional system, especially in view
of the large number of devices found even in a medium-size installation. A
simple example of the difference in cable runs and terminations is shown in
figure 8-8 and figure 8-9.
Faster Commissioning
Unlike a traditional system where commissioning is a manual and labor-
intensive task, a fieldbus device, once connected to the network, can be com-
missioned from the workstation in the control room. This makes the commis-
sioning procedure simple and fast, and for the most part, one person can carry
it out. Once the host is connected to the fieldbus network, all field devices on
the network are automatically detected on a per-linking module and the tags
are automatically displayed on the host’s “live list” for each network. This is
far easier than the finding of instruments one by one that is performed for tra-
Figure 8-8. Traditional Terminations
Figure 8-9. FF Terminations

ditional systems. That process requires people in the field equipped with sim-
ulators who maintain radio contact with the control room to verify correct
wiring.
Fieldbus asset management features available in control systems are helpful

during the commissioning process. It is easy to identify a device by checking
the manufacturer, device type, version, tag, serial number, and description.
Likewise, the fieldbus device configurations are verified from the workstation
and any configuration or range changes that have been done are automati-
cally recorded in the database. The typical “as built” documents for any proj-
ect, which maintain the documentation after the commissioning, are ready for
printout or export if the FF-enabled control and asset management systems
are used.
The configuration for all devices can be downloaded with a single click. With
the conventional systems, changes made using a hand-held terminal need to
be manually updated. The chances of spotting a range mismatch between the
transmitter and controller are slim, which opens the possibility of an incorrect
reading and subsequently a nonfunctioning control loop and trip points.
Remote commissioning of 16 devices in a safe area or 12 devices in a hazard-

ous area, at a time, speeds up the process. The simulation function may be
used to verify that the system has the correct response by safely testing nor-
mal, abnormal, and dangerous process conditions. This is easily done without
needing to apply any physical input and even without using a simulator,
which is a requirement in conventional systems.
Maintenance Savings
The cost of maintenance can be reduced in many ways, for example, by pre-
empting failure without unnecessary expenditure on preventive maintenance
and by being better prepared when something does occur. The advanced self-
diagnostic tests and operational statistics information that can be retrieved
from devices throughout the plant owing to fieldbus technology may be used
for asset management to anticipate failure, suspect drift, confirm malfunction,
and verify configuration, etc. These features are embedded in each device and
software, requiring little or no configuration and ensuring benefits directly
without the need for expensive consultants or long implementation periods.
Maintenance savings can be achieved provided that the maintenance tool is

an integral and permanent part of the system so that diagnostics are continu-
ous and asset management functions can be carried out in a way similar to
normal operation. Hand-held terminals and temporarily connected software
are obstacles to efficient practices. This form of network-enabled asset man-
agement is not available in traditional systems and is not possible without
fieldbus.
Less to Maintain
The leaner and less complex system based on fieldbus technology has fewer
parts than can fail in the first place and fewer parts to maintain. The elimina-
tion of an intermediate 4–20 mA signal means that there is no need to check
and calibrate I/O cards, transmitter current outputs, and positioner inputs.
Reduced Field Trips

In a networked system, several maintenance tasks are carried out remotely
from the workstations overcoming the need for local field trips with a hand-
held terminal. Using the computer as the most powerful maintenance tool
reduces time-consuming field trips and cuts maintenance costs. The host
retrieves information from the field devices for asset management and dis-
semination throughout the enterprise, independent of device manufacturer.
Traditional systems with proprietary field instrument communication do not
have this capability.
Figure 8-10. Multilayered Systems with Device Diagnostics

The operator screens display the simple status in a fieldbus host as soon as the
device diagnostics detect a fault. Detail diagnostics is done using a mainte-
nance tool. From the “live list,” it is easy to tell when a device is disconnected,
loses power, has communications problems, or fails. Remote performance
testing exposes weaknesses and future problems; for example, it is easy to test
if a valve is able to respond to small demands by actuating the valve in small
steps, while simultaneously remotely monitoring to check that the valve is
really moving. This was not possible in the past, as most positioners did not
have position feedback to the control room. Remote maintenance is not a lux-
ury, it is a necessity for savings as many problems can be solved remotely by
simple configuration changes such as direct or reverse action, damping, or
tuning. See figure 8-10 for an illustration of this, in which different types of
errors are propagated upwards to derive the problems, root causes, and possi-
ble solutions using multilayered systems.
Preempt Failures
Network-enabled asset management features allow a proactive maintenance
scheme in which operational statistics are used to estimate the device status.
Information about exceeded operating conditions along with this health data
determines how much longer a device can operate before requiring mainte-
nance. It is possible to more accurately anticipate and schedule a repair or
degrading device performance before it causes inaccuracies and faults. Deter-
mining if a device may need to be repaired soon or even based on the manu-
facturer life expectancy data for critical parts minimizes costly surprises and
shutdowns, and reduces unnecessary maintenance costs. Fieldbus drastically
reduces surprise shutdowns caused by unforeseen failures and makes it possi-
ble to plan maintenance for many devices on one convenient occasion. This
could not be done by systems in the past. Refer to figure 8-11 for predictive
intelligence and applicability in plant situations.
Faster Repair
The Fieldbus network communicates defined faults more precisely and imme-
diately upon detection. This enables technicians to more accurately pinpoint
the source of the problem and pick the right replacement parts and tools
before going into the field, and this solves the problem faster.
Fieldbus also makes it easy to retrieve information on a device’s materials of

construction when a suitable replacement part must be selected. Traditional
systems do not provide sufficient levels of diagnostics details to allow doing
Figure 8-11. Predictive Intelligence in FF Devices
this. Moreover, once technicians have installed replacement devices, they can
download the configuration and put the device into operation quickly.
Timely Calibration
Drift occurs over time and may also be caused when ambient condition limits
are exceeded. Each FF device stores a record of the last calibration where it
will not be misplaced. Operators may review the record to determine the cali-
bration status of the device to ensure that calibration is neither overdue nor
done unnecessarily early. Sensor temperature can be monitored for suspected
drifts because limits have been exceeded, and if necessary, calibration can be
performed earlier or later depending on process availability than originally
scheduled. Positioner self-calibration for valve travel can also be invoked
remotely. In fieldbus, it is easy to gain an overview of which devices in the
plant are due for calibration. Conventional systems do not enable such cali-
bration management.
No Unnecessary Maintenance
Detailed device diagnostics make it possible for operators to quickly deter-
mine whether a process problem is caused by the device or by the process.
Using fieldbus, it is possible to remotely check to see if the problem is genuine
before going into the field; thus, maintenance is only performed when it is
really needed. In the past, technicians went to the field on false alerts to bring
back an instrument for testing often to find that it was OK. The time and cost
saved by not having to bring only a few transmitters into the workshop is
enormous. Less money is wasted checking and repairing devices that are OK.
By referring, for example, to the number of reversals, a technician can decide
whether or not to tear down a valve so as to replace the valve stem packing.
Conventional systems provide no means for achieving comparable results.
Market-based Replacement Part and Maintenance Prices

A system based on open standards, such as fieldbus, also offers the benefit
that failed components can often be replaced by components from other sup-
pliers if the original parts are overpriced. Open standards technology means
less reliance on a single supplier. It is not necessary to get tied up with the
costly maintenance contracts associated with proprietary systems.
Operations Savings
Asset management does not deal directly with process control. Its focus is on
improving maintenance, which indirectly improves control because when
devices perform better and with fewer failures, better plant performance
results.
Less Process Downtime

It is difficult to operate any plant efficiently in the presence of recurrent device
problems. Shutdowns caused by failures are normally very expensive because
entire batches of products are often destroyed, and production capacity may
be reduced for extended periods of time. When the process is not running,
money is being lost. Maintenance schemes that use network-enabled asset
management features result in fewer interruptions caused by surprise device
failure shutdowns. Knowledge about an imminent failure prompts ordering
replacement parts in advance.
Systems can respond to faults faster and reduce repair times, as well as plant
down time. Early warning makes it possible to solve problems before they
adversely affect plant output. With equipment in good condition, the process
is kept online longer. Systems that lack proper network infrastructure in the
field do not offer these benefits.
An advantage of fieldbus technology offers over traditional DCS architecture

is that it minimizes the number of I/O modules, controllers, and other compo-
nents, which reduces the probability of failure. The architectural simplicity of
a fieldbus system thus contributes to its availability. There are simply fewer
parts to fail.
It is prudent to prevent control for the loop from continuing if the transmitter
fails. An instrument failure indication means that the loop will be shutdown.
Conventional transmitters and DCS don’t have the means to accurately
exchange status information because of the limitations of 4−20 mA. Typically,
a transmitter output current below 3.8 mA or above 20.5 mA is the only fast
way to indicate a fault and to make the interlocks shut the loop down.
For analog systems, valve positioner faults are even more difficult to detect.
Because analog systems make no distinction between severe and minor faults,
even a small problem would stop the process. Furthermore, an under range of
a mere 1 percent could also trigger a stop. Such unnecessary trips disrupt pro-
duction, increasing downtime and reducing profits. Fieldbus devices, on the
other hand, are better equipped to communicate the severity of the fault and
detect that the problem is genuine. This superior data validation results in a
reduced number of spurious shutdowns.
In traditional systems, the I/O for as many as 100 loops could be communi-
cated on one bus from the I/O subsystems to the controllers. Supervision for as
many as 1000 loops could also be communicated on just one bus from the con-
trollers to the host. The failure of such a bus would trip all these loops,
undoubtedly halting most of the plant. The field-level network for FOUNDA-
TION Fieldbus is highly distributed in comparison to the network technologies
used at the I/O and control levels of earlier systems.
This distribution leads to better availability. At the very most, eight but typi-
cally four loops rely on a single network. This reduces the number of loops
that would have to be shutdown in the event of failure. Production standstills
are rare. Costly one-to-one redundant I/O subsystems and networking would
be needed to achieve the same availability in a conventional system, yet in
most cases the backplanes and intermediate I/O switching board would
remain weak points.
In the past, control systems had centralized controllers that handled dozens or
even up to 100 loops. Control distributed to the field devices is one of the keys
to the high availability of the FCS architecture that can be built using FOUNDA-
TION Fieldbus. The Fieldbus-based Control System (FCS) architecture is highly
distributed: a transmitter and valve positioners make up the typical loop, and
the PID algorithm normally executes in the positioners, achieving single loop
integrity. Because there is no centralized controller, a single fault does not
affect any large number of loops. Costly one-to-one controller redundancy in
addition to I/O redundancy would be required to achieve the same availabil-
ity in a conventional system.
Less Process Variability

Factors like long-term drift, imprecision due to mechanical friction, and poor
tuning cause deviation and instability in process variables, which ultimately
results in variation in the final product. Fieldbus-based systems are com-
pletely digital, which leads to eliminating noise (with proper installation prac-
tice) and many other sources of errors.
Operational statistics, such as counting the number of reversals of the valve

actuators, also provide another major benefit. The ability to identify poorly
tuned positioners and control loops is one of the major advantages. A valve
with a large number of reversals is a clear indication that the loop is oscillat-
ing, calling for retuning. With fieldbus, it is thus possible to access this infor-
mation in the positioners to identify the malfunctioning devices behind the
variability and target those responsible to fix it.
Fieldbus also allows critical parameters to be monitored in real time without

needing to go into the field. This makes it possible to fine-tune the loop for
optimal production output. Calibration management also promotes the timely
checking and calibration of instruments to maintain accuracy. A control
valve’s capacity response to small demands is important for tight control and
can be verified remotely. These features play a vital role in achieving a more
uniform product because they remove the sources of variability one by one.
They are not available in conventional system architecture.
Higher Quality
Tighter product consistency is achieved through asset management based on
the diagnostics and operational statistics received over the fieldbus network.
Such consistency ensures product quality within specified limits. The status
and diagnostics retrieved from the devices enable operators to quickly stop
production in the event of failure before any out-of-specification product con-
taminates good quality product. Less time, raw materials, energy, and other
resources are wasted to produce lower-grade product or product that cannot
be sold. The FOUNDATION Fieldbus Function Block Programming allows the
transfer of the process data and status between the blocks. This seamless com-
munication helps engineer the process to safe state in the event of failure. The
improved calibration scheme made possible by network-enabled asset man-
agement features makes it easier to remain in compliance with quality and
environmental management procedures. There is no alternative means to
achieve the same benefits.
Greater Safety
Accidents carry high costs. It is obviously desirable to minimize the risk of
harm to people, environment, and equipment. To avoid accidents, control
must stop when a failure occurs. For regular controls, fieldbus technologies
have several characteristics that plants may use to improve the safety of basic
control system throughout the plant lifecycle to a level well above that of con-
ventional systems.
Undetected faults in field devices are very dangerous because the control is
not shutdown. In an analog system, a fault often goes unnoticed, and danger-
ous control may continue because of an untrue value from a failed transmitter.
Such a failure is detected and communicated instantly in fieldbus technology,
which allows the loop to be shut down. Diagnostics is indicated as part of the
status that is communicated with the measurement and control variables
passed between devices.
Fieldbus also distinguishes between minor “uncertain” and severe “bad”

problems, avoiding unnecessary shutdowns.
Interlocks may initiate a shutdown by using the status received with the pro-
cess variable from the transmitter in the basic control strategy. This can be
done by setting the status in the manipulated variable to the valve positioners
or final control elements accordingly. If the FOUNDATION Fieldbus program-
ming language is used, such shutdown logic is already built in and only needs
to be enabled. Thus, the field devices themselves automatically ensure grace-
ful shutdown without the need for central controllers. For example, a sensor
failure, such as a burned-out thermocouple, would be detected by the self-
diagnostics of temperature transmitters and a bad status would be propa-

gated throughout the control strategy. Control would stop and status would
be further propagated to the valve positioners, which would move to a prede-
termined position.
Similarly, the device diagnostics detects bad communications, which allows

shutdown action to be taken. Therefore, multidropping devices on a network
is not dangerous. Manually configuring and verifying such a safety interlock
in a conventional system would be complex and conducive to error. The crude
diagnostics in traditional systems makes it difficult to balance safety and
availability. Using fieldbus technology for basic controls is a good idea
because it allows some of the features and characteristics previously only
found in a full-fledged safety-related system to be used in basic control.
Less Training
Training is costly, but standards make it possible for devices and software to
function and operate in the same basic way. This reduces the need for ongoing
training of personnel in the use of different equipment and tools while at the
same time reducing confusion and mistakes. Interoperability makes it possi-
bility to use only a single tool to configure devices from different manufactur-
ers, giving everything a common and user-friendly look and feel. FF also
specifies programming languages, which makes it possible to build a control
strategy using controllers from different manufacturers and then executing
the strategy in transmitters, positioners, or centralized controllers.
Lower Cost of Expansion and Change

For the same reasons that fieldbus-based systems are cheaper to buy and
deploy, they are also cheaper to expand and modify. However, there are addi-
tional benefits that make them even more advantageous in this respect.
Scalability
Increased product demand may force a plant to expand, calling for an
improvement in production. If a network is not fully loaded, field instruments
can be added even without pulling new cable. Each leftover communication
port can handle 16 new devices. Expansion of the plant devices becomes
expensive and difficult in traditional systems. Building large systems is a mat-
ter of concern if it involves linking more field-level networks to the host-level
network.
The FCS architecture is the key to the ability of a system to expand at little
additional cost because there are no expensive central units. In a traditional
system, when a site adds loops, an additional I/O subsystem or controller is
soon required because there are not enough I/O channels or processing power.
Adding that loop may be very expensive, which may cause an idea to be can-
celled or put on hold.
Previously expensive simple improvements become feasible using bus tech-

nology. The fundamental limitation of the scalability of the traditional system
architecture is that its resources are overloaded with the addition of loops.
Every instrument added consumes some of the finite resources of the systems.
The limits for the controller, memory capacity, I/O counts, controller address
range, and the like are soon approached. As more and more loops are added
to keep costs down, the CPU is loaded and performance suffers.
Another restriction to be aware of is that older proprietary protocols often

have a limited bandwidth of perhaps 500 Kbps for the I/O network and 1
Mbps for the control level network. Ethernet at the control level running 10/
100 Mbps overcomes this limit. In contrast to the traditional system, adding a
device in an FCS means adding resources. In the FCS, adding instruments also
means adding more CPUs, more memory, and more computing power to the
system. Although this may seem counterintuitive at first, the constraints
become more powerful as the system is loaded. This means that the system
can be continuously expanded and handle ever more advanced control strate-
gies without a corresponding loss of performance.
The FCS architecture is built from smaller decentralized components, thereby

enabling the addition of instruments by plants one by one without having to
add major components. For the same reason, systems can economically start
small and gradually expand as the demands grow. Since there is no heavy
investment in a large central component, it is even economically feasible to
build a system with only a handful of loops.
Ease of Modification
Plants often have to adapt to market requirements by changing product and
production methods. Such modification is easier in a fieldbus system because
a new configuration can simply be downloaded, preparing the device for the
new application. This provides a great deal of flexibility to respond to quickly
changing production demands, material conditions, and equipment

situations.
Unused functions can be put into use at a later stage. For example, operators
can put feedback from a valve positioner into use without having to modify
the valve positioner, running wires, or adding of any AI points to the control
system, as was necessary in the days of analog feedback. With a fieldbus-
based system, it is easier to make small changes. Thus, small improvements
can constantly be made without costly change orders to the suppliers.
Protected Investment
A great obstacle to improvement is conventional systems bought only a few
years ago being replaced by newer models, requiring a complete replacement
or expensive gateways, software upgrades, and services for integrating the
new with the existing. However, systems based on standards don’t change
very quickly and therefore, manufacturers are forced to go that extra mile to
follow the standard when inventing new features and improving perfor-
mance so products remain compatible with existing equipment. The stability
of fieldbus technologies therefore protects the investment made in a control
system from the obsolescence that often occurs with proprietary technologies.
Future compatibility is ensured and the threat of the need for complete
replacement and reinvestment is removed.
9
Specifications
List
FF-103 Foundation Specification – Common File Format
FF-131 Foundation Specification – Standard Tables
FF-581 Foundation Specification – System Architecture
FF-586 Foundation Specification – HSE Presence
FF-588 Foundation Specification – Field Device Access (FDA) Agent
FF-589 Foundation Specification – HSE System Management
FF-593 Foundation Specification – High Speed Ethernet Redundancy
FF-801 Foundation Specification – Network Management
FF-803 Foundation Specification – HSE Network Management
FF-806 Foundation Specification – Data Link Protocol Specification Bridge

Operation Addendum
FF-816 Foundation Specification – 31.25 Kbps Physical Layer Profile
FF-821 Foundation Specification – Data Link Services Subset
309
FF-822 Foundation Specification – Data Link Protocol Specification
FF-831 Fieldbus Power Supply Specification
FF-870 Foundation Specification – Fieldbus Message Specification
FF-875 Foundation Specification – Fieldbus Access Layer (Services and

Protocol)
FF-880 Foundation Specification – System Management
FF-883 Foundation Specification – System Management Addendum for

Software Download
FF-890 Foundation Specification – Function Block Application Process Part1
FF-900 Foundation Specification – Device Description Language
FF-940 Foundation Specification – Communication Profile
FF-941 Foundation Specification – HSE Profile

Bibliography
Books and Standards

AG-140. Wiring and Instrumentation 31.25 Kbit/s, Voltage Mode, Wire Medium
Application Guide. Austin, TX: Fieldbus Foundation, 1996.
AG-163. 31.25 Kbit/s Intrinsically Safe Systems Application Guide. Austin, TX:
Fieldbus Foundation, 1996.
AG-181. FOUNDATION Fieldbus System Engineering Guidelines. Austin, TX: Field-

bus Foundation, 2004.
AN9027. FNICO Non-Incendive Field bus System. MTL Instruments Application

Note, June 2004.
ARC Advisory Group. www.arcweb.com.
Berge, J., Fieldbuses for Process Control: Engineering, Operation, and Maintenance.
Research Triangle Park, NC: International Society of Automation, 2001.
Electronic Device Description Language. www.eddl.org.
Emerson Process Management. www.emersonprocess.com.
FDI Cooperation. www.fdi-cooperation.com.
311
FDT Group. www.fdtgroup.org.
Fieldbus Foundation. www.fieldbus.org.
Fieldbus Application Guidelines for Process Industry. London, UK: Engineering

Equipment and Material Users Association, 1997.
Fieldbus Book: A Tutorial. Technical information bulletin, TI38K02A01-01E,

Tokyo, Japan: Yokogawa Electric Corporation, May 2001.
Fieldbus Preliminary Application Note on Intrinsic Safety. Revision 1.1. Austin,

TX: Fieldbus Foundation, 1995.
IEC 61158-2. Industrial Communication Networks – Fieldbus Specifications – Part

2: Physical Layer Specification and Service Definition. International Engineering
Consortium, Chicago, IL, 1993.
IEC 65C/178/CDV – IEC 61158-3. Data Link Layer-DLL Service Part 3. Interna-
tional Engineering Consortium, Chicago, IL, 1999.
IEC 65C/178/CDV – IEC 61158-4. Data Link Layer-DLL Protocol Part 4. Interna-
tional Engineering Consortium, Chicago, IL, 1999.
Honeywell International Inc. www.honeywell.com.
International Society of Automation. www.isa.org.
ISA-50.02-1992 Part 2. Fieldbus Standard for Use in Industrial Control Systems –

Part 2: Physical Layer Specification and Service Definition. Research Triangle
Park, NC: International Society of Automation. Withdrawn in response to the
release of IEC 61158 standards.
ISA-50.02-1997 Part 3. Fieldbus Standard for Use in Industrial Control Systems –

Part 3: Data Link Service Definition, Research Triangle Park, NC: International
Society of Automation. Withdrawn in response to the release of IEC 61158
standards.
ISA-50.02-1997 Part 4 – Fieldbus Standard for Use in Industrial Control Systems –

Part 4: Data Link Protocol Specification, Research Triangle Park, NC: Interna-
Bibliography 313
tional Society of Automation. Withdrawn in response to the release of IEC

61158 standards.

Part 5: Application Layer Service Definition, Research Triangle Park, NC: Inter-
national Society of Automation. Withdrawn in response to the release of IEC
61158 standards.

Part 6: Application Layer Protocol Specification, Research Triangle Park, NC:
International Society of Automation. Withdrawn in response to the release of
IEC 61158 standards.
ISA-TR50.02, Part 9-2000. Fieldbus Standard for Use in Industrial Control Systems;
User Technical Report. Research Triangle Park, NC: International Society of
Automation.
Verhappen, Ian, and Augusto Pereira. FOUNDATION Fieldbus, Fourth Edition.

Research Triangle Park, NC: International Society of Automation, 2006.
Acronyms
AI—Analog Input
ALPDU—Application Layer Protocol Data Unit
ANSI—American National Standards Institute
AO—Analog Output
AP—Application Program/Process
Auto—Automatic
AWG—American Wire Gauge
BG—Bias/Gain Station
Cas—Cascade
CD—Compel Data
CFF—Capability/Common File Format
CIF—Control in the Field
CIH—Control in the Host
CIW—Control in Wire
CNF—Confirmation
Config—Configuration
315
CONN—Connection-Oriented
COTS—Commercial Off the Shelf
CS—Control Selector
CSMA/CD—Carrier Sense Multiple Access/Collision Detect
DA—Digital Alarm
DAP—Device Application Process
DC—Device Control
DCS—Digital Control System
DCS—Distributed Control System
DD—Device Description
DDC—Direct Digital Control
DDL—Device Description Language
DDS—Device Description Services
DevId—Device Identifier
DHCP—Dynamic Host Configuration Protocol
DI—Discrete Input
DL—Data Link
DLCEP—Data Link Connection End Point
DLL—Data Link Layer
DLPDU—Data Link Protocol Data Unit
DMA—Direct Memory Access
DO—Discrete Output
DS—Data Structure
DT—Deadtime
DTM—Device Type Manager
DTU—Data Transfer Unconfirmed

Acronyms 317
DUT—Device Under Test
EDDL—Electronic Device Description Language
EFD—(High Speed) Ethernet Field Device
EGP—Exterior Gateway Protocol
ERP—Enterprise Resource Planning
FAS—Fieldbus Access System
FB—Function Block
FBAP—Function Block Application Program
FCS—Fieldbus Control System
FDI—Field Device Integration
FDT—Field Device Technology
FFB—Flexible Function Block
FIP—Factory Instrumentation Protocol
FISCO—Fieldbus Intrinsically Safe Concept
FMS—Fieldbus Message Specifications
H1—Fieldbus Low Speed Data Network
HART—Highway Addressable Remote Transducer
HIST—Host Interoperable Support Test
HMI—Human-Machine Interface
HPT—High Power Trunk
HSE—High-Speed Ethernet
I/O—Input/Output
ICMP—Internet Control Message Protocol
ID—Identifier
IDE—Integrated Development Environment
IEC—International Electrotechnical Commission

IEEE—Institute of Electrical and Electronics Engineers
IGMP—Internet Group Management Protocol
Iman—Initialization Manual
IND—Indication
IP—Internet Protocol
IR—Initialization Request
IS—Intrinsically Safe
IS—Input Selector
ISA—International Society of Automation
ISO—International Standards Organization
ISP—Interoperable Systems Project
IT—Information Technology
ITC—Instrument Tray Cable
ITK—Interoperable Test Kit
ITS—Interoperable Test Systems
IUT—Implementation Under Test
LAN—Local Area Network
LAS—Link Active Schedule
LD—Linking Device
LLC—Logical Link Control
LM—Link Master
LO—Local Override
LRE—LAN Redundancy Entity
LS—Link Schedule
LSB—Least Significant Bit
LUV—Last Usable Value

Acronyms 319
mA—milliamps
MAC—Medium/Media Access Control
MAI—Multiple Analog Input Block
Man—Manual
MAO—Multiple Analog Output Block
MAU—Medium Attachment Unit
Max—Maximum
Mbps—Megabits per second
MDI—Multiple Discrete Input Block
MDO—Multiple Discrete Output Block
MDS—Medium Dependent Sublayer
MIB—Management Information Base
MIS—Management Information System
MSB—Most Significant Bit
Msg—Message
MVC—Multi-Variable Container Object
NAMUR—Standardization association for measurement and control in

chemical industries
NIS—Non-Intrinsically Safe
NM—Network Management
NMA—Network Management Agent
NMIB—Network Management Information Base
NST—Network Status Table
NTP—Network Time Protocol
OD—Object Dictionary
OLE—Object Linking and Embedded

OOS—Out Of Service
OPC—OLE for Process Control
OPC UA—OPC Unified Architecture
OS—Output Splitter Block
OSI—Open System Interconnection
PD—Proportional Derivative
PD—Physical Device
PD Tag—Physical Device Tag
PDU—Protocol Data Unit
PHY—Physical Layer
PID—Proportional Integral Derivative (Control Algorithm)
PLC—Programmable Logic Controller
PLTC—Power Limited Tray Cable
PN—Probe Node PDU
PS—Preliminary Specification
PT—Pass Token
PTB—Physicalisch Technische Bundesanstalt
RA—Ratio
RB—Resource Block
RCas—Remote Cascade
RED—Redundant
ROM—Remote Operations Management
ROut—Remote Output
Rout—Remote Output
RT—Return Token
SCADA—Supervisory Control And Data Acquisition

Acronyms 321
SIF—Safety Instrumented Functions
SM—System Management
SMI—Structure and Identification of Management Information
SMIB—System Management Information Base
SNMP—System Network Management Protocol
SNTP—Simple Network Time Protocol
SP—Set Point
SS—Signal Splitter
STP—Shielded Twisted Pair(s)
SUT—System Under Test
TCP/IP—Transmission Control Protocol/Internet Protocol
TD—Time Distribution
UDP—User Datagram Protocol
UTP—Unshielded Twisted Pair(s)
VCR—Virtual Communication Relationship
VCRL—Virtual Communication Relationship List
VDC—Volts Direct Current
VFD—Virtual Field Device
XML—eXtensible Mark-up Language

INDEX
Index Terms Links
31.25 Kbps fieldbus

signaling 23
wiring 24
access rights 41
advanced diagnostics 260
alarm detection 59 83
algorithms 169
analog input (AI) 17 51
modes of operation 58
status 60
troubleshooting 61
analog output (AO) 17 62
status 68
anti-windup protection 169
application function block 35
application layer 21
areas
classification 110
asset management systems 246–247 252
availability 251
This page has been reformatted by Knovel to provide easier navigation.

Index Terms Links
basic control 36
basic diagnostics 259
benefits
installation 280
maintenance 281
operational 280
bidirectional communication 16–17
block errors 57–58 67 83
87
block type manager (BTM) 230
bridges 107
buffered 31
bulk power supply 153
bumpless transfer 77
bus diagnostics 249
cable
design 148
sizes 149
types 149
calibration 253–255 257
carrier sense multiple access (CSMA) 107
checkmark 106
clamps 169
Class 61 - Integrated Host 47
Class 62 - Visitor Host 47
Class 63/64 - Bench Host 48
client 31

Index Terms Links
communication 28
channel 231
DTM 229
failure 163
stack 22
compel data (CD) 27
complex loops 203
configured fail state 162
construction savings 293
control and execution monitoring 170
control and monitoring
centralized 2
distributed 3
fieldbus 4
local 2
control in the field (CIF) 158
control in wire 189–190 198
control loop 170
control modules 158
control performance 201
control valve positioner diagnostics 262
controller 183
conversion 66
cost 198
cost of purchase 282
cost savings 278
data link layer 21 24 26–27

DD 205 210–211
DDL 21 205 207–209
delegated token hold time 29

Index Terms Links
deterministic control 198

device
addressing 27
capability 203
description (DD) 205 210–211
description language (DDL) 21 205
diagnostics 259
DTM 230
failure reactions 166
function block configuration parameters 160
type manager 228
device types
basic 26
link master 26
diagnostics 148 220–221 252
discrete devices 262
digital communications protocol 1
direct acting 77
direct digital control (DDC) 2
discrete input (DI) 80
status 83
discrete output (DO) 84
status 88
distributed control system (DCS) 143
DTM 233
dynamic performance 200
electronic device description language (EDDL) 8 211 212–220

236

Index Terms Links
energy-limited fieldbus segments 119

engineering cost savings 290
entity 113–114
equipment
classification 111
factory configuration 170

failure 83
fault detection 67 87 162
fault handling 163
fault state initiation 164
fault state operation 168
FDI 235–237 239–241
FDT 224–228 233
feedforward 76
field device integration (FDI) 234
cooperation project 8
field device management systems 246
field device tool (FDT) 224–228 233
field value processing 82
fieldbus
access sublayer (FAS) 22 24 30
device diagnostics 259
message specification (FMS) 22
Fieldbus Foundation 5–9 21 42
45 146 210
217 235 270
284
filtering 56 75
FISCO 113 115–117 121–122
flexibility 199

Index Terms Links
FNICO 114 118 120–122

FOUNDATION Fieldbus 1–2 6–7 9
15
communication 22
communications 20
history 4
frame application 227
function blocks 17 19 32–33
36 51 62
68 80 84
161 189
application program (FBAP) 32
scheduling 29
shell 32
gases
classification 111
gateway DTM 229
grounding 133 137 150
group address 31
H1 8 15–16
bus installation 104
interface card failure 204
interoperability test kit (ITK) 42
segment 148
hazardous area design 153
high power trunk 114 122 125
high-speed Ethernet (HSE) 8 15 107
182

Index Terms Links
host data integration 232

host interoperability support test (HIST) 45 143
profiles 46
hot swappable 152
HSE 18 20
hybrid 153
I/O selection 82
identical device 268
ignition 112
increase to close 66
installation benefits 280
integration 221
intelligent devices 269
interchangeability 268
International Electrotechnical Commission (IEC) 23
International Standards Organization (ISO) 20
interoperability 10 19 42
268
interoperability test system (ITS) 42
intrinsic safety 108
intrinsically safe (IS) 23
ISA-100.11a 7
ITK 42 44
LAS 26–27 171

lifecycle benefits 277
like device 268
limitations 202

Index Terms Links
limiting 66 74 77
link active scheduler (LAS) 28
link scheduling (LS) 30
live list 27
live working 119
maintenance 245–246 266

benefits 281
savings 297
Manchester biphase-L technique 23
mechanical fail state 163
meta-language 21
mode degradation 165
mode shedding 165
motor-operated valves 159
NAMUR 269 271

NAMUR NE107 7 272
natural schedule 177
network topology 144 148
node addressing 28
non-fieldbus 203
nonhazardous area design 154
objects
alert 40
link 38
multivariable container (MVC) 41

Index Terms Links
objects (Cont.)
trend 39
view 41
offline 260
online 260
open systems interconnection (OSI) 20
operational benefits 280
operational statistics 266
operations savings 301
optimization 171 173
output 65 86
selection 77
parameter settings 147

pass token (PT) 27
peer-to-peer communication 20
physical layer 21–23 128
PID
controller redundancy 203
status 78
troubleshooting 79
positioner failure 204
power requirements 147
power supply 140 152
predictive diagnosis 246
predictive maintenance 251
pressure transmitter diagnostics 261
preventive maintenance 251
prioritization 179
process alarms 263

Index Terms Links
process channel 231

process integrity 202
proportional-integral-derivative (PID) 17 68
publish 28 32
queued 31
range setting 253 257

reactive maintenance 250
redundancy 180–181
complete network 185
controller 183
high-speed Ethernet 182
LAS 188
media 184
power 187
transmitter 181
valve 186
redundant 152
remote
diagnostics 247
operations management (ROM) 7
set point 34
shed 164
replacing FF devices 267
re-ranging 257
reset limiting 78
resource block 34 160
risk management 154

Index Terms Links
safe area 154

safety instrumented functions (SIF) 7
segment design 154
segment segregation 156
selection 146
sensor trim 256
server 31
set-point selection 66 74
set-point tracking 77
shed 164
shielding 134 150
signal conversion 56
direct 57
indirect 57
indirect square root 57
simulation 52 82 87
single-loop integrity 199
spare capacity 144–145
standardization 12
status calculation 66
subscriber 28 32
support files 147
surge protection 153
synchronous serial 23
temperature
multiplexer transmitters 159
transmitter diagnostics 261
terminators 150

Index Terms Links
tokenizer 209
topologies for fieldbus networks 101
bus with spurs 101
daisy chain 103
point-to-point 101
tree 103
tracking 76
transducer block 34 160
transmitter diagnostics 222
troubleshooting 222
unlike device 268

usability 242
user application blocks 160
user application layer 22
user layer 20–21
VCR
publisher/subscriber 31
report distribution 31
virtual field devices (VFD) 20 37
Wireless HART® 7
wiring 129
savings 18

(B. R. Mehta, Y. J. Reddy) Applying FOUNDATION Fie (B-Ok - CC)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

(B. R. Mehta, Y. J. Reddy) Applying FOUNDATION Fie (B-Ok - CC)

Uploaded by

Copyright:

Available Formats

Applying

Copyright © 2016 International Society of Automation (ISA)

Printed in the United States of America.

Library of Congress Cataloging-in-Publication Data in process

First, I would like to thank my co-author, Dr. Y. J. Reddy, who contributed

I would like to express my sincere gratitude to the management of Reliance

I would also like to express my appreciation for the on-going encouragement

B. R. Mehta, PhD, is the senior vice president of Reli-

Y. J. Reddy, PhD, has a wealth of experience in the field

About the Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .vii

Chapter 1 Introduction to FOUNDATION Fieldbus . . . . . . . . . . . . . . . . . . . . . . . . . .1

Chapter 2 FOUNDATION Fieldbus Technology. . . . . . . . . . . . . . . . . . . . . . . . . . . .15

2.2 Communications in FOUNDATION Fieldbus . . . . . . . . . . . . . . . . . . . 20

Chapter 3 Function Blocks in FOUNDATION Fieldbus. . . . . . . . . . . . . . . . . . . . . .51

Application Example: Pressure Transmitter Used

Chapter 4 Installation of FOUNDATION Fieldbus . . . . . . . . . . . . . . . . . . . . . . . . .101

Chapter 5 Engineering Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143

Mode Degradation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Chapter 6 Device Integration Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . .205

Ease of Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

Chapter 7 Maintenance in FOUNDATION Fieldbus. . . . . . . . . . . . . . . . . . . . . . . .245

Reduction in Financial Losses Caused by

Chapter 8 Benefits of Using FOUNDATION Fieldbus . . . . . . . . . . . . . . . . . . . . . .277

Chapter 9 Specifications List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .309

The conventional signal connections from a sensor to a controlling device

Let us attempt to understand the evolution of FOUNDATION Fieldbus, includ-

1.1 The Evolution to FOUNDATION Fieldbus

Figure 1-1. Local Control and Monitoring

The minicomputer introduced the possibility of “centralized” control and

Figure 1-2. Centralized Control and Monitoring

With the advent of the microcomputers, distributed processing units were

Figure 1-3. Distributed Control

1.2 History of FOUNDATION Fieldbus

Figure 1-4. Fieldbus Control System

pliers started to work on their proprietary digital communication standards.

• American National Standards Institute (ANSI)/International Society of

• International Electrotechnical Commission (IEC) as IEC 61158

• European Committee for Electrotechnical Standardization (CENELEC)

FOUNDATION Fieldbus – Current Outlook

The Fieldbus Foundation established the host registration program in 2009,

Millions of FOUNDATION Fieldbus–compliant devices and hundreds of thou-

FOUNDATION Fieldbus – The Future

For example, the Fieldbus Foundation and NAMUR, an international user

The FOUNDATION Fieldbus Diagnostic Profiles Specification identifies “role-

Fieldbus Foundation, in cooperation with the world’s leading safety experts,

In addition, FF has launched its FOUNDATION Fieldbus for Remote Operations

FOUNDATION Fieldbus for ROM provides an interface to both technologies

The Fieldbus Foundation has recently launched a new technology develop-

These initiatives drive an innovation strategy enabling plant owners to focus

they manage the technology itself. The focus on standards-based solutions

Primary Drivers for FOUNDATION Fieldbus

• Fieldbus technology is an enabling technology, not a differentiating

• Fieldbus technology is open and available to all parties.

• FF members support and work with the international and national

FOUNDATION Fieldbus is a growing field device network in process control

If the manufacturers allowed licensing and provided proper documentation, a

Standardization is an enormous task that not only involves the development

Many of the systems suppliers who participated in developing the standard

resulted in compatible equipment now available from several suppliers. Now

Plants that employ FOUNDATION Fieldbus are protected from proprietary

• Single loop integrity

• A standardized physical interface to the wire

• Bus-powered devices on a single wire pair