ISA - TR50.02 Part 9-2000 Fieldbus Standard For Use in Industrial Control Systems User Layer Technical Report

TECHNICAL REPORT
ISATR50.02, Part 92000
Fieldbus Standard for Use in

Industrial Control Systems:
User Layer Technical Report
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Approved 01 January 2000

TM
ISAThe Instrumentation,
Systems, and
Automation Society
--```,``-`-`,,`,,`,`,,`---
Copyright The Instrumentation, Systems, and Automation Society

Reproduced by IHS under license with ISA
No reproduction or networking permitted without license from IHS Not for Resale
ISA would like to thank the former Chairman of SP50
--```,``-`-`,,`,,`,`,,`---
and current SP50.4 member Cullen Langford for his

outstanding contribution in editing ISATR50.02, Part 9,
User Layer Technical Report, and for his integral role in
converting the text into a suitable electronic format.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
--```,``-`-`,,`,,`,`,,`---
ISA-TR50.02, Part 9-2000, Fieldbus Standard for Use in

Industrial Control Systems: User Layer Technical Report
ISBN: 1-55617-718-6
Copyright 2000 by the Instrument Society of America. All

rights reserved. Not for resale. Printed in the United
States of America. No part of this publication 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 permission of the Publisher.
ISA 67 Alexander Drive P. O. Box 12277

Research Triangle Park, North Carolina 27709

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
--```,``-`-`,,`,,`,`,,`---

v
Preface
This preface, as well as all footnotes and annexes, is included for information purposes
and is not part of ISA-TR50.02, Part 9-2000.
This document has been prepared as part of the service of ISA, the international society
for measurement and control, toward a goal of uniformity in the field of instrumentation.
To be of real value, this document should not be static but should be subject to periodic
review. Toward this end, the Society welcomes all comments and criticisms and asks that
they be addressed to the Secretary, Standards and Practices Board; ISA; 67 Alexander
Drive; P. O. Box 12277; Research Triangle Park, NC 27709; Telephone (919) 549-8411; Fax
(919) 549-8288; E-mail: standards@isa.org.
The ISA Standards and Practices Department is aware of the growing need for attention to
the metric system of units in general, and the International System of Units (SI) in
particular, in the preparation of instrumentation standards. The Department is further
aware of the benefits to USA users of ISA standards of incorporating suitable references
to the SI (and the metric system) in their business and professional dealings with other
countries. Toward this end, this Department will endeavor to introduce SI-acceptable
metric units in all new and revised standards, recommended practices, and technical
reports to the greatest extent possible. Standard for Use of the International System of
Units (SI): The Modern Metric System, published by the American Society for Testing &
Materials as IEEE/ASTM SI 10-97, and future revisions, will be the reference guide for
definitions, symbols, abbreviations, and conversion factors.
--```,``-`-`,,`,,`,`,,`---
It is the policy of ISA to encourage and welcome the participation of all concerned
individuals and interests in the development of ISA standards, recommended practices, and
technical reports. Participation in the ISA standards-making process by an individual in
no way constitutes endorsement by the employer of that individual, of ISA, or of any of
the standards, recommended practices, and technical reports that ISA develops.
CAUTION ISA ADHERES TO THE POLICY OF THE AMERICAN

NATIONAL STANDARDS INSTITUTE WITH REGARD TO PATENTS. IF ISA
IS INFORMED OF AN EXISTING PATENT THAT IS REQUIRED FOR USE
OF THE STANDARD, IT WILL REQUIRE THE OWNER OF THE PATENT TO
EITHER GRANT A ROYALTY-FREE LICENSE FOR USE OF THE PATENT
BY USERS COMPLYING WITH THE STANDARD OR A LICENSE ON
REASONABLE TERMS AND CONDITIONS THAT ARE FREE FROM UNFAIR
DISCRIMINATION.
EVEN IF ISA IS UNAWARE OF ANY PATENT COVERING THIS

STANDARD, THE USER IS CAUTIONED THAT IMPLEMENTATION OF THE
STANDARD MAY REQUIRE USE OF TECHNIQUES, PROCESSES, OR
MATERIALS COVERED BY PATENT RIGHTS. ISA TAKES NO POSITION
ON THE EXISTENCE OR VALIDITY OF ANY PATENT RIGHTS THAT MAY
BE INVOLVED IN IMPLEMENTING THE STANDARD. ISA IS NOT
RESPONSIBLE FOR IDENTIFYING ALL PATENTS THAT MAY REQUIRE A
LICENSE BEFORE IMPLEMENTATION OF THE STANDARD OR FOR
INVESTIGATING THE VALIDITY OR SCOPE OF ANY PATENTS BROUGHT
TO ITS ATTENTION. THE USER SHOULD CAREFULLY INVESTIGATE
RELEVANT PATENTS BEFORE USING THE STANDARD FOR THE USERS
INTENDED APPLICATION.
HOWEVER, ISA ASKS THAT ANYONE REVIEWING THIS STANDARD WHO

IS AWARE OF ANY PATENTS THAT MAY IMPACT IMPLEMENTATION OF
THE STANDARD NOTIFY THE ISA STANDARDS AND PRACTICES
DEPARTMENT OF THE PATENT AND ITS OWNER.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
vi
ADDITIONALLY, THE USE OF THIS STANDARD MAY INVOLVE

HAZARDOUS MATERIALS, OPERATIONS OR EQUIPMENT. THE STANDARD
CANNOT ANTICIPATE ALL POSSIBLE APPLICATIONS OR ADDRESS ALL
POSSIBLE SAFETY ISSUES ASSOCIATED WITH USE IN HAZARDOUS
CONDITIONS. THE USER OF THIS STANDARD MUST EXERCISE SOUND
PROFESSIONAL JUDGMENT CONCERNING ITS USE AND APPLICABILITY
UNDER THE USERS PARTICULAR CIRCUMSTANCES. THE USER MUST
ALSO CONSIDER THE APPLICABILITY OF ANY GOVERNMENTAL
REGULATORY LIMITATIONS AND ESTABLISHED SAFETY AND HEALTH
PRACTICES BEFORE IMPLEMENTING THIS STANDARD.
The following people served as members of ISA Subcommittee

SP50.4:
H. Dammeyer, Managing Director The Ohio State University
G. Wood, Managing Director Graeme Wood Consulting
R. Appleby Du Pont
*T. Blevins FisherRosemount Systems Inc.
*E. Bristol Foxboro Company
J. Carmody Honeywell, Inc.
R. Caro Automation Research Corporation
F. Charles Consultant
T. Craeco Consultant
E. dela Hostria Rockwell Automation
U. Doebrich Siemens AG
P. Early Texas Instrument
M. Giraudi Consultant
*J. Gray Foxboro Company
C. Gross Dow Chemical Company
W. Hawkins HLQ Limited
F. Jaye Consultant
M. Kazahaya MMK International Inc.
R. Ketcham Union Carbide Corporation
C. Langford Cullen G. Langford, Inc.
R. Lasher Bailey Controls Company
M. Ledier Schneider Electric
K. Lindner Endress+Hauser
T. Madden Exxon Company
E. Messano Deceased
*R. Prescott Foxboro Company
F. Russo ENEL-Ricerca/PEA
*J. Scarlett Honeywell Inc.
E. Skabowski Tendent Consulting
R. Szanyi Mobil Technology Company
*C. Van Haren James River Corporation
M. Wozniak Bailey Controls Company
W. Wright Moore Products Company
The following people served as members of ISA Committee SP50:
R. Caro, Chairman Automation Research Corporation

H. Dammeyer, Managing Director The Ohio State University
G. Wood, Managing Director Graeme Wood Consulting
C. Akiyama Yokogawa Electric Corporation
J. Aliperti Chromatech Consultoria Limited
W. Baker KML, Inc.
L. Beckman HIMA Americas, Inc.
--```,``-`-`,,`,,`,`,,`---

vii
G. Beusch Absolute Control Inc.

M. Borges Petrobras Cenpes Supen Diprom
*R. Bowden FisherRosemount Ltd.
S. Boyer Iliad Engineering Inc.
*R. Breithaupt Siemens
*P. Brett Honeywell, Inc.
P. Burton Holwell Consulting
E Butteriss Global Tradelinks Corp.
*R. Canfield Square D Company
A. Capel Comgate Engineering, Ltd.
B. Casner Miller Electric Manufacturing Company
*S. Cavalieri Universita Degli Studi di Catania
R. Crowder Ship Star Associates, Inc.
M. Dajani Phillip Morris
E. dela Hostria Rockwell Automation
*U. Doebrich Siemens AG
J. Dohoney Jet Propulsion Laboratory
B. Dumortier Schneider Electric SA
*J. Elias Honeywell, Inc.
T. Feindel R. Stahl, Inc.
M. Giraudi Consultant
*R Glaser Dow Chemical Company
*J. Gray Foxboro Company
*P. Griem, Jr. Honeywell IAC
B. Gross General Motors Corporation
*C. Gross Dow Chemical Company
A. Gupta Ficon Technology
H. Hasler Adelcontrol
*T. Holland Square D Company
*J. Howard Foxboro Company
S Hwang Automation Systems
*T. Ito Fuji Electric
*V. Jacobson Ronan Engineering Company
J. Jamison Bantrel Inc.
*K. Kakizakai Fuji Electric Company, Ltd.
M. Kazahaya MMK International Inc.
*R. Ketcham Union Carbide Corporation
*K. Krivoshein FisherRosemount Systems Inc.
M. Kross RoviSys
*Y. Kumeda Yamatake Industrial Systems
T. Kuusisto Consultant
*T. Laine Alstom Technology
H. Landet FINT
C. Langford Cullen G. Langford Inc.
*R. Lasher Bailey Controls Company
A. Lesh AMP Inc.
P. Leviti Marconi Italiana Automazione
K. Lindner Endress + Hauser GmbH
T. Madden Exxon Company USA
--```,``-`-`,,`,,`,`,,`---
*A. Mathur Bailey Controls Company
*G. Mazzola ENEL
A. McCauley, Jr. Chagrin Valley Controls, Inc.
F. McKenna FMcK Associates, Ltd.
R. Meeker Process Control Solutions, Inc.
M. Melton KOSA
A. Meol Macromicro
D. Merriman MerTech, Inc.
E. Miller, Jr. SouthWest Research Institute
N. Miller Intuitive Technology Corp.
*O. Mirabella Universita Degli Studi di Catania
*D. Modell ABB Bailey Controls
A. Mukherji Systems Automation International Inc.
*G. Nachev Isomatic Laboratories

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
viii
L. Natiello Merck and Company Inc.

*L. Neitzel FisherRosemount Systems Inc.
H. Newman Cornell University
A. Nokkonen Valmet Automation Inc.
*P. Noury Cegelec
H. Ostling Yokogawa Industrial Auto Inc.
*E. Pageler FisherRosemount Systems Inc.
P. Patel V Automation
*T. Phinney Honeywell Inc.
J. Polon Neles-Jamesbury
A. Poschmann Ifak
D. Quy Rosemont Inc
D. Rundle AAMP Inc
*F. Russo ENEL-Ricerca/PEA
K. Schwarz Schwarz Communication Consult
*E. Sederlund Dow Chemical Company
D. Serang MX Communications
Y. Shimanuki Toshiba Corporation
E. Skabowski Tendent Consulting
J. Slavinsky Czech Standards Institute
D. Sniezek Lockheed Martin Federal Services
J. Sprague Saudi Aramco Oil Company
R. Squires Measurement Technology Ltd.
H. Storey Equilon Enterprises LLC
R. Szanyi Mobil Tech Company
P. Thiessmeier Klockner-Moeller
--```,``-`-`,,`,,`,`,,`---
*C. Thurston Union Carbide
*N. Tobol Ronan Engineering
*A. Tresset Cegelec
C. Vaidya Sun Microsystems
C. Van Haren James River Corporation
*J. Weiss Electric Power Research Institute
C. Williams Eastman Kodak Company
G. Winchester National Electrical Manufacturers
Assoc.
*D. Wroblewski Bailey Controls Company
*M. Zielinski FisherRosemount Systems Inc.
This technical report was approved for publication by the ISA Standards and
Practices Board on 1 January 2000.
M. Zielinski FisherRosemount Systems, Inc.

D. Bishop Chevron Petroleum Technology Co.
P. Brett Honeywell, Inc.
M. Cohen Senior Flexonics, Inc.
M. Coppler Ametek, Inc.
B. Dumortier Schneider Electric SA
W. Holland Southern Company
A. Iverson Ivy Optiks
R. Jones Dow Chemical Co.
V. Maggioli Feltronics Corp.
T. McAvinew Instrumentation & Control Engineering
LLC
A. McCauley, Jr. Chagrin Valley Controls, Inc.
G. McFarland Honeywell, Inc.
R. Reimer Rockwell Automation
J. Rennie Factory Mutual Research Corp.
H. Sasajima Advanced Architecture and Technologies
R. Webb Altran Corp.
W. Weidman Parsons Energy & Chemicals Group
J. Weiss EPRI

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
ix
J. Whetstone National Institute of Standards &

Technology
M. Widmeyer EG&G
R. Wiegle CANUS Corp.
C. Williams Eastman Kodak Co.
G. Wood Graeme Wood Consulting
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
vii
Table of Contents
PREFACE.......................................................................................................................................................2
INTRODUCTION ........................................................................................................................................12
CONFORMANCE CLASSES......................................................................................................................13
REFERENCES .............................................................................................................................................16
SP50 USER LAYER GUIDE SHEET..........................................................................................................17
USER LAYER STRUCTURE .....................................................................................................................21

DATA OWNER STRUCTURE HARDWARE.........................................................................................................22
DATA OWNER STRUCTURE LOGICAL NODES .................................................................................................45
BLOCK MODES ............................................................................................................................................72
STATUS BYTE ..............................................................................................................................................86
Status Byte - Attach 1 Bit 3-5 State Diagram ..........................................................................................98
Status Byte - Attach. 1 State Diagram - Bits 5, 4, and 3 ..........................................................................98
Status Byte - Attach 2 - Remote Handshake ..........................................................................................104
AGENTS ....................................................................................................................................................107
Agent- Attach. 1 Discrete Agent Logic ..................................................................................................126
FUNCTION BLOCK STRUCTURE ...................................................................................................................132
Attach. 1 Status Logic ( vacant) ............................................................................................................167
Attach. 2 Fast Initialization Procedure .................................................................................................167
APPLICATION SUPPORT SERVICES INTERFACE..............................................................................................190
Attach. 1 Support Services ....................................................................................................................210
Attach. 2 Extended Parameters.............................................................................................................224
DATA BASE WRITE SERVICE.......................................................................................................................230
Attach. 1 Complex Write.......................................................................................................................244
--```,``-`-`,,`,,`,`,,`---
Attach. 2 Logic .....................................................................................................................................259

ALERT FUNCTION ......................................................................................................................................280
Attach. 1 Logical Node Alert Extensions...............................................................................................309
Attach. 2: Function Block Extensions For Specific Block Types............................................................310
FIELD DEVICE START AND RESTART ...........................................................................................................314
HUMAN INTERFACE CONSIDERATIONS -HIF................................................................................................335
Attach. 1 Auto-Formatting ....................................................................................................................353
Attach. 2 - Material Description ...........................................................................................................407
ARRAY OF BASIC PARAMETERS ..................................................................................................................441
FUNCTION BLOCKS: ..............................................................................................................................468
INTRODUCTION TO FUNCTION BLOCKS ........................................................................................................468
OPEN BLOCKS ...........................................................................................................................................470
GENERIC BLOCK ........................................................................................................................................472
Interoperable Generic Block.................................................................................................................472
Interworking Generic Block ..................................................................................................................489
ALTERNATE AND STANDARD BLOCKS:........................................................................................................492
Standard Function Block Functions ......................................................................................................492
Null Algorithm......................................................................................................................................512
ANALOG ...................................................................................................................................................513
Analog Input.........................................................................................................................................513
Analog Output ......................................................................................................................................551
Counter ................................................................................................................................................597

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
viii
Dynamic Compensation ........................................................................................................................605

Math.....................................................................................................................................................609
PID Control..........................................................................................................................................617
Property Conversion.............................................................................................................................624
Signal Capture......................................................................................................................................633
Signal Characterizer.............................................................................................................................637
Signal Selector .....................................................................................................................................643
Splitter..................................................................................................................................................649
Timer....................................................................................................................................................654
Totalizer ...............................................................................................................................................661
DISCRETE ..................................................................................................................................................671
Device Control .....................................................................................................................................671
Discrete Input Function Blocks.............................................................................................................677
Discrete Output ....................................................................................................................................681
Discrete Register ..................................................................................................................................685
EXPLANATION OF TIMER FUNCTIONS:...........................................................................................688
Human Interface...................................................................................................................................697
Logic ....................................................................................................................................................704
Program Control ..................................................................................................................................728
Register Interface Block .......................................................................................................................739
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
SERIAL ......................................................................................................................................................750
Serial Communication ..........................................................................................................................750
Serial In Conversion.............................................................................................................................752
--```,``-`-`,,`,,`,`,,`---
APPENDIX .................................................................................................................................................758
Explanation of Field Bus Function Block..............................................................................................759
Explanation of Fieldbus Topologies......................................................................................................764
Explanation of Generic & Open FB ......................................................................................................771
Timed Standard Node Design ...............................................................................................................780
Fundamental Control Structure ............................................................................................................784
LO Mode Explanation...........................................................................................................................804
Bad Values ...........................................................................................................................................815
Block Structure for Cascading ..............................................................................................................820
Cascade Initialization & Recover .........................................................................................................825
Explanation Of ASK, BASK, Acquirer...................................................................................................832
(Original) App Layer Services ..............................................................................................................837
Explanation Of Alarm Function............................................................................................................850
Explanation of Discrete I/O ..................................................................................................................855
Thermocouple Multiplexer & A/I ..........................................................................................................858
AO MSP Data.......................................................................................................................................860
Explanation of Selector Bias.................................................................................................................870
Explanation of Timer Block ..................................................................................................................874
Explanation of Device Control Block....................................................................................................881
GLOSSARY ...............................................................................................................................................902
COMMENTS, PHOENIX..........................................................................................................................918
INDEX ........................................................................................................................................................980

ix
Table of Figures
Figure 1: Preface, Figure 1, Protocol Models ....................................................................................................5
Figure 2: Node .................................................................................................................................................6
Figure 3: Diagram: Function Blocks / P&ID....................................................................................................9
Figure 4 Conformance Classification..............................................................................................................14
Figure 5 Conformance Classification (cont.)...................................................................................................15
Figure 6: Modes by Bit ...................................................................................................................................17
Figure 7: Hardware Point types.......................................................................................................................17
Figure 8: Status Info. by Bit............................................................................................................................17
Figure 9: Block Algorithms ............................................................................................................................18
Figure 10: User Layer Terms..........................................................................................................................19
Figure 11:Cascade Structure...........................................................................................................................20
Figure 12:A Field Device on Fieldbus.............................................................................................................43
Figure 13 A Complex Fieldbus Device ...........................................................................................................44
Figure 14: Data Owner Structure, Figure 1, Timed Standard Cycle Structure .................................................60
Figure 15: Attribute / Access Limits ...............................................................................................................85
Figure 16: Figure 1 Status State Diagram .....................................................................................................103
Figure 17: State Transition Diagram ............................................................................................................106
Figure 18: Agents Figure 1: Discrete Active Agent Logic .............................................................................131
Figure 19: Function Block ............................................................................................................................132
Figure 20:Discrete Active Agent Logic (path marked in red) ........................................................................160
Figure 21: Function Block Structure: Figure 1, Generalized Analog Block ...................................................164
Figure 22: Function Block Structure: Figure 2, Data Structures ....................................................................165
Figure 23: Function Block Structure: Figure 3, Analog Status Parameter Detail ...........................................166
Figure 24: Generic Conditional Writes .........................................................................................................257
Figure 25: Generic Conditional Writes (cont.) ..............................................................................................258
Figure 26: DBWS Figure 1, Buffer Service Logic .........................................................................................268
Figure 27: DBWS Figure 2, Static & Auto-format Data Base Revision Number............................................269
Figure 28: DBWS Figure 3, Log./Phy. Node Values .....................................................................................270
Figure 29: DBWS Figure 4, Mode ................................................................................................................271
Figure 30: DBWS Figure 5, Data Base Values..............................................................................................272
Figure 31: DBWS Figure 6, Data Base Values (cont.)...................................................................................273
Figure 32: Application Layer - Writing to Buffer..........................................................................................278
Figure 33: Application Layer, Figure 2, Clipboard Revision Number Logic ..................................................279
Figure 34: Alert Figure 1, Multiple Hardware Failure Suppression ...............................................................308
Figure 35: Field Device Start and Restart, Figure 1, Physical Node Power-Up ..............................................332
Figure 36: Field Device Start and Restart, Figure 2, Logical Node Power-Up ...............................................333
Figure 37: Field Device Start and Restart, Figure 3, Communications Interface Power-Up ...........................334
Figure 38:HIF Figure 1, Auto-Formatting Parameter Layout ........................................................................367
Figure 39:HIF Figure 2, Auto-Formatting Parameter Header ........................................................................368
Figure 40: HIF Figure 3, Auto-Formatting Detail Words ..............................................................................369
Figure 41: Analog Input, Figure 1 Analog Input Algorithm....................................................................... ...531
Figure 42: Analog Output, Figure 1, Analog Output System Diagram ..........................................................578
Figure 43: Analog Output, Figure 2, Illustration of Characterization Types ..................................................579
Figure 44: Counter Figure 1, Counter Block .................................................................................... ............603
Figure 45: Counter, Figure 2, Counter Data Flow................................................................................ .........604
Figure 46: Properties Conversion, Figure 1, Property Block..................................................................... .....632
Figure 47: Timer, Timer Algorithm..............................................................................................................659
Figure 48: Timer, Timer 0 Logic ................................................................................................ ..................660
Figure 49: Totalizer Block..................................................................................................... .......................669
Figure 50: Totalizer Data Flow.....................................................................................................................670
Figure 51: Device Block ........................................................................................................ .......................676
Figure 52: Discrete Register, Figure 1, Discrete Register Block ................................................................ ....694
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
x
Figure 53: Discrete Register, Figure 2, Discrete Point...................................................................................695

Figure 54: Discrete Register, Figure 3 Discrete Value Flow..........................................................................696
Figure 55: Human Interface, Figure 1, Local HI/F Block ..............................................................................703
Figure 56: Logic, Figure 1, Logic Algorithm ................................................................................................722
Figure 57: Logic, Figure 2, SPx Logic, Version 0 - Independent...................................................................723
Figure 58: Logic, Figure 3, SPx Logic, Version 1 - On/Off/Rev. ..................................................................724
Figure 59: Logic, Figure 4, Logic Block - Instruction Definition Word.........................................................725
Figure 60: Logic, Figure 5, Logic Block - Detail Words................................................................................726
Figure 61: Logic, Figure 6, Logic Icons - Basic Shape .................................................................................727
Figure 62: Program Algorithm .....................................................................................................................738
Figure 63: Register Interface, Figure 1, Register Interface Block ..................................................................748
Figure 64: Register Interface, Figure 2, Discrete Interface ............................................................................749
Figure 65: Serial Communication, Figure 1, Serial Communication Block ...................................................757
Figure 66: Function Block, Figure 1, ............................................................................................................762
Figure 67: Function Blocks, Matrix of Defined Block types ..........................................................................763
--```,``-`-`,,`,,`,`,,`---
Figure 68: Fieldbus Topologies Figure 1 Simple Field Loop .........................................................................767
Figure 69: Fieldbus Topologies, Figure 2, Central Control............................................................................768
Figure 70: Fieldbus Topologies Figure 3 Field Multiplexer...........................................................................769
Figure 71: Fieldbus Topologies Figure 4 Unit Controllers.............................................................................770
Figure 72: Generic & Open Blocks, Figure 1, Cyclic Scenarios ....................................................................783
Figure 73: Fundamental Control Structure, Figure 1, Mode Concept ............................................................800
Figure 74: Fundamental Control Structure, Figure 2, Mode - Control ...........................................................801
Figure 75: Fundamental Control Structure, Figure 3, PID Block Fundamentals ............................................802
Figure 76: Fundamental Control Structure, Figure 4, Example Block Cascade .............................................803
Figure 77 LO Mode, Figure 1, Case Definitions .................................................................................. .........814
Figure 78 Figure 1 Cascade Structure ........................................................................................... ................821
Figure 79: Block Structure for Cascading, Cascade Structure .................................................................... ...824
Figure 80: Cascade Initialization & Recovery, Figure 1 ................................................................................831
Figure 81: Selector Bias, Process Model ........................................................................................ ...............873
Figure 82: Device Control Block, Figure 1, Device Block ........................................................................ .....901
Figure 83: Mascot........................................................................................................... ......................983

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
2
Preface
FIELD BUS PROCESS CONTROL USER LAYER TECHNICAL REPORT
The Field Bus being developed simultaneously by ISA SP50 and IEC SC65C/WG6 is
intended to be applied to time-critical applications in process control,
distributed data acquisition and some areas of factory automation. While
generally we planned to follow the "spirit and intent" of international data
communications standards, our first priority is to these time-critical or real-
time applications. Explicitly, we provided a standard to satisfy user needs.
This Technical Report defines the details of the field bus process control
user layer for continuous and batch process control applications, as well as
typical sequential and interlock control applications in the process industries.
It is usable in other industries wherever similar applications exist. It
establishes a data communications structure for implementing all types of field
bus devices. This structure is required to achieve interoperability and
interchangeability of field devices.
This paper includes the following sections:

BACKGROUND
FIELD BUS REQUIREMENTS
USER LAYER DEFINITION
DIFFERENCES BETWEEN DCS AND FIELD BUS
FUNCTION BLOCKS
ABOUT PROGRAMMABLE LOGIC CONTROLLERS
FIELD BUS DEVICES
USER LAYER CONCEPTS
OBSERVATIONS AND CONCLUSIONS
BACKGROUND:
The top layer of the ISO (International Standards Organization) OSI (Open
Systems Interconnection) Reference Model (ISO 7498-1, 1987) is numbered seven
(7), and is called the "Application Layer." Above this is generally called "the
application." Therefore, the Application Layer provides communications services
specific to the type of application using the open system. The ISO/OSI seven
layer architecture, is intentionally vague about the definition of the contents
of the Application Layer, while the functions of all lower six layers are well
defined in the general data communications environment. The vagueness allows
application needs to define the functions of the seventh layer.
In 1986, the MAP (Manufacturing Application Protocol) Steering Committee of

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
the MAP Users' Group requested that the major applications of interest to
manufacturing should prepare "companion standards" to support the core (general)
work being done at ISO. This work supports all applications, and is called MMS,
Manufacturing Messaging Service, ISO 9506. The major functions of MMS are as
follows:
o Uploading and downloading
o Task (function) management
o Variable and data access (read, write)
o Semaphore management
o Event management
o Journal management
o File management
o Status and identification query
o Clock synchronization
SP-50 User Layer Technical Report Preface

--```,``-`-`,,`,,`,`,,`---

3
The four companion standards are being (have been) prepared by the following
organizations:
Process Control ISA SP72

Robotics Robotics Institute of America (RIA)
Programmable Logic Control NEMA (National Electrical Manufacturer's
Association)
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Numerical Machine Control EIA (Electronics Institute of America)
In 1985, the ISA approved the charter for the SP50 committee to develop a
digital Field Bus. One of the primary directives for the Field Bus was to enable
digital communications for instrumentation and control to the same level of
interchange that has been achieved by analog (4-20 ma) transmission. After the
first few meetings, it became obvious that digital and logical device
communications were also necessary.
After review of MMS, ISA S72.02 and the other companion standards, ISA SP50,
the Field Bus committee, decided that a fresh approach was required.
Specifically, it was decided that the end users' needs must be considered in the
definition of the application layer services. While the MMS services were
probably good for low level (programmer) use of the Field Bus, more work was
required to define a high level interface for the types of functions and services
necessary to serve the distributed process control environment of the late
1990's.
FIELD BUS REQUIREMENTS:

The Field Bus committee began by developing a priority-ordered list of
requirements that a Field Bus must satisfy. These requirements led to the
definition of a two-level physical layer to satisfy both the needs of the
following:
o H1 slow speed traditional process control using existing wiring,
meeting intrinsic safety requirements, and delivering field
device power on the same wires, and
o H2 high speed process and logical control using new wiring and, if
possible, deliver power on the same wires and meet intrinsic
safety requirements.
Many of the user requirements for Field Bus do not appear in the body of the
standard, because they do not directly affect either the form or function.
However, these user requirements do affect our understanding of the form and
function of both the physical and user layers, and "why" the standard functions
and features exist. Some of this information is contained in the first chapter
of the appendix.
Many of the requirements were expressed in terms of process control

functionality, rather than reduced to "communications language." Very soon, the
Applications Layer subcommittee split into two organizations:
o Applications Layer Subcommittee -- to define the OSI Application Layer
(7) functions required to support user functions, and
o User Layer Subcommittee -- to define the user needs.
In order to define the actual needs of users, it was determined that a model
of the user layer software was required complete with its functionality and
algorithmic behavior. From this model, the services that would be needed to
support such software that corresponds to the "application" noted in the OSI
model could be defined. This procedure differs from the procedures used in other
communications standards which assume the "application" is only a generic systems
programming environment. The functionality and real-time data structures
developed for the user layer model require extensive services from the
application layer.

--```,``-`-`,,`,,`,`,,`---

4
Just what is the user layer model? We have attempted to project from today's
smart transmitter environment, to the next level of smartness for field devices.
It was clear in 1987, that one or more vendors would move the final closed loop
control calculation to a field device; a transmitter or a valve positioner. We
didn't expect these products so soon, but they are already for sale and were
exhibited at the 1990 ISA Conference and Exhibit.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
--```,``-`-`,,`,,`,`,,`---

5
PROTOCOL MODEL
OSI-ISO Model Field Bus Model

User Application Programs (not SP-50 Other
Part of the OSI Model) User User
Layer Layers
SP-50
UL
Services
7 Provides all services for 7
Application Application Programs.
Presentation
6 Presentation Restructures data to/from
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Format used in Network
5 Session Name/address translation Access security

and Synchronizes data
4 Transport Provides transparent, re-

liable transfer, end to end.
3 Network Provides message routing For data

transfer between adjacent nodes.
Data Link Hardware interface - for- Mats and un- Data Link 2
2 formats packets and controls link access.
1 Physical Handless the transmission Physical

and reception of raw bits. 1
Physical Link
Figure 1: Preface, Figure 1, Protocol Models

--```,``-`-`,,`,,`,`,,`---

6
NODE
Field Bus
Physical Node
Name Descriptor
Bus Address etc.
I/O Logical Node 0 Logical Node n
Hardware
Logical Node Logical Node
Name, Descriptor Name, Descriptor
etc. etc.
Function Block 0 Function Block 0

**
* *
* Block n
Function * Block n
Function
--```,``-`-`,,`,,`,`,,`---
Figure 2: Node
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

7
So far these products still depend upon the use of either Proprietary or limited
availability bus technology working together with 4-20 ma transmission, however,
their control parameters are available on those vendors' systems products for
remote tuning and control mode selection.
The ISA Field Bus User Layer is oriented about the process control problem
assuming a complete distribution of the scan and control functions all within
Field Bus devices. The capability is provided for measurement, control
--```,``-`-`,,`,,`,`,,`---
calculation and final actuation in the same or separate nodes on the Field Bus,
as necessary. Rather than taking a generalized message passing structure, the
User Layer has used a complete distributed object-oriented approach modeled after
several existing distributed control systems (DCS) and programmable logic
controllers (PLC) in common use. The choice of this model was very pragmatic --
the DCS architecture has evolved from centralized computer control with
increasing distribution of functions and has been field proven to work. A model
constructed using only message passing without a semantic message structure would
require the invention of an unproven mechanism. The committee has chosen to
adapt its semantic model from those in common use. In addition, the architecture
for communicating with PLC's has been included in this same model. Methods used
to configure or program DCS's and PLC's are not in the scope of this model.
USER LAYER DEFINITION:

How can the User Layer semantic model be described? In other words, what
syntactical format can be used to express the process control semantic model? We
have settled upon a two level procedure to describe the Field Bus User Layer as
follows:
1. A description of the User Layer Machine; a description of the
implementation of the User Layer on a hypothetical high level language
computer base.
2. A document abstracting the User Layer Machine into a set of equivalent

requirements which contain all of the critical elements of the
referenced machine, but without the specific design content.
The first document is called the "User Layer Technical Report." It was written
by a committee interested in preserving the design of distributed control systems
(DCS) which have proven to be useful and sufficient for a wide variety of time-
critical applications in data acquisition and process control. The format of the
document is that of a software design specification or an implementation
description, simply because it was easier for the committee to write. It reads
similar to system descriptions of distributed control systems since this is the
primary source material within the experience of the committee. Since
considerable criticism has been offered about the "over-specification" of the
Technical Report, the subcommittee has decided to prepare a separate standard
document.
The second document is the true standard for the User Layer. It is written
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
in "requirements language", but without an implied implementation. Where the
method(s) of implementation are important to achieve the objectives of the
standard, they are explicitly stated. This is the document which will be
submitted for ISA (and eventually IEC) approval, but it will be incomplete
without the Technical Report which provides examples and much of the rationale.
The technical content of both documents are intended to be identical. The
Technical Report will always be updated to reflect the current status of the
standard for the User Layer.
DIFFERENCES BETWEEN DCS AND FIELD BUS:

The Field Bus Process Control User Layer provides an application environment
not unlike that of a distributed control system (DCS). The intent was not to

8
replace the DCS, but to define the architecture necessary for a DCS to
communicate with smart field devices when control actions occur in those devices.
There are many differences between Field Bus User Layer functions and those
typically performed by a DCS.
It has always been expected that the Field Bus would remove the functions of
process variable processing from the DCS. Similarly, processing of outputs to
proportioning process control valves and other actuator mechanisms is also
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
included. DCS's operating with Field Bus devices will acquire process variables
in engineering units form. Likewise they will send a desired valve output as a
percentage.
Inclusion of control objects within Field Bus devices changes DCS

functionality more substantially. We expect that many smaller systems will not
require the traditional DCS at all, but will only require DCS-like operator
console(s). Larger systems, which will require a DCS, will use it to provide the
upper level cascade controls and feedforward controls. While Field Bus User
Layer provides some capability to build complex cascades and feedforward loops,
these are intended to provide the backup to more complex loops built in the DCS.
In all cases, we attempted to keep the Field Bus simple. For example, there
is no "ramp and soak" algorithm, because the committee felt that any algorithm we
could design would be inadequate to fulfill the needs of true batch control.
Yet, we decided to provide simple setpoint ramping, determining that this time-
critical function was best administered at the Field Bus level. Only one PID
algorithm was chosen, to keep it simple. Our guideline was always to include the
time-critical items at the User Layer, but to eliminate the supervisory and high
level calculation functions.
FUNCTION BLOCKS:
--```,``-`-`,,`,,`,`,,`---
The architectural base of Field Bus is the function block, which performs the
work of data acquisition, control and output. Every function block contains an
algorithm, a formula or rule, and a data base that is used by the algorithm. The
parts of the data base that are permitted to be accessed through communications
are called "attributes" or parameters. Each function block has a user-defined
name, called a block tag, which must be unique. Function block data is addressed
over field bus via TAG.PARAMETER.
The User Layer Standard defines a "function block" to be a process- related

data structure with a "data part" and a "rule part", as described in the
following illustration:
Function Block Type
A class of user elements consisting of
(1) The definition of a data structure partitioned into
input, output, and internal variables, (data part,
also called "data base") AND
(2) A set of operations to be performed upon the variables
of the data structure when the element is invoked (rule
part, also called "algorithm").
Function Block
An identifiable and distinct instance of a function block type.
There are four classes of function blocks as follows:

o Standard -- the attributes and the algorithm are fully defined
within the standard such that both the dynamic and
static performance are known. Both the algorithm and
data base may be extended as long as the standard
function remains.
o Alternative -- the attributes include those of a standard block, but

the algorithm may not provide the same static or dynamic
performance as the corresponding standard block.
o Generic -- the attributes are defined only in generic terms such

9
that any system may access them through the use of these
attributes. The algorithm is not defined by the
standard
o Open -- the attributes and the algorithm are not defined within
the standard.
The intent of the function block structure is to allow devices to be

delivered with pre-defined algorithms requiring only the data base to be
downloaded for configuration into a specific control application. These are the
Standard and Alternative blocks. A vendor may also deliver a Generic or a unique
Open block complete with the algorithms pre-defined. In contrast, a vendor may
--```,``-`-`,,`,,`,`,,`---
also provide a start-up procedure, outside of the User Layer, to download

algorithms to any type of function block, although this model is intended for use
only with Generic and Open blocks.
Standard function blocks, which have been included, also provide

interchangeability for the functions they define. The standard function block
definitions allow extensions (i.e., functionality and parameters beyond those
defined in the standard) and alternate function blocks (which use a different
algorithm but the same parameters as a standard block). Extensions and alternate
blocks, of course, may not be interchangeable. Generic and open function blocks
accommodate both vendor-proprietary functionality and new field-device functions
which are not practical to implement using combinations of standard function
blocks. These classes of function blocks are not intended to be interchangeable.
However, extensions and function blocks of any class which follow the user layer
requirements for standard blocks, will be interoperable via field bus. The user
layer also includes features of extended tag addressing and auto-formatting,
which facilitate interoperability of extensions and "non-standard" blocks.
The following diagram shows the equivalency between "function blocks and
conventional process and instrumentation diagrams (P&ID's):
Figure 3: Diagram: Function Blocks / P&ID
SP
Input Output Output
PV FIELD
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
AI PV
PID SP
AO BUS
FT FC FCV
P&ID
ABOUT PROGRAMMABLE LOGIC CONTROLLERS:

In the past five years, programmable logic controllers (PLC's) have become
indispensable elements of all classes of process control systems. They are used
to implement safety interlocks in continuous control and as the primary sequencer
in batch control. Their low cost, flexibility and high energy I/O are as
specialized for these applications, as the multifunction controllers of DCS's are
for regulatory control of continuous processes. Therefore, the User Layer
provides a rudimentary capability to communicate with PLC's modeled on the

10
available PLC interface techniques already in use. The PLC interface capability
does not reflect the needs which might be developed in a User Layer for factory
automation or machine control.
FIELD BUS DEVICES:

The Field Bus will allow many different types of devices to be logically
interconnected on a single communications link. The following is a partial list
of the types of devices that are anticipated:
oSensors and transmitters

oValve, damper and other position actuators
oSingle and multipoint regulatory loop controllers
oProgrammable logic controllers
oDual and triple modular redundant regulatory and programmable logic
controllers
o Safety shutdown systems
o Multipoint data acquisition systems, analog and digital
o Historical archiving devices
o Operator (human) interface workstations
o Chart recorders
o Dedicated indicators and displays
o Gateways to higher level communications networks
o Bridges to other Field Bus segments
o Temporarily connected devices
- Hand-held human interface terminals
- Communications link test devices
-
At first, devices similar to present-day field devices, such as "smart"
transmitters, positioners, single-loop controllers and indicators, and hand-held
diagnostic devices will appear on field bus. In the future, new devices will
appear that take full advantage of the capabilities of a standard digital field
bus.
USER LAYER CONCEPTS:

The User Layer addresses a wide variety of real-time applications, but is
designed specifically to support applications in closed loop process control.
--```,``-`-`,,`,,`,`,,`---
The control applications may be very simple arrangements of sensors, controllers,
actuators and display devices all on the same Field Bus segment, or the devices
can exist together in any combination. Any of the devices may also exist on a
different Field Bus segment, however, it is understood that a performance or
response time penalty may occur. We have also planned for the orderly connection
of classical DCS or supervisory computer systems that are driven by a timing
authority not under Field Bus control, yet provide essential target information.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
All Field Bus devices are addressed at the User Layer by a tag name, rather
than the low layer address necessary for the operation of the Data Link Layer.
The translation of tag name to address is provided by the Application Layer based
on User Layer definitions. The physical devices and function blocks all have
unique tag names. This concept extends to initialization in which the physical
device installed into the Field Bus can exist with only a unique tag name and
expect that the data required to begin operation can be downloaded across the
Field Bus identified only by that tag name. If a physical device contains only
one logical node and only one function block (e.g. as in a single-measurement
field transmitter), the device tag, node tag, and the block tag will be the same.
"Data ownership" is a primary concern of the process control user layer. It

is essential from a user standpoint that there be one, and only one, location
where all data for a given point exists. That location must be at the source of
the data. Field devices will typically be the original source of information,
and therefore the "data owner". All associated data resides in the field device,
and not in a central controller, bridge, or gateway device. Each logical node or

11
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
"data owner" on field bus has a data dictionary which describes the data items
"owned" by that node.
While the Data Link and Application Layers provide for a method of
synchronous scheduling of function blocks, the User Layer provides its own method
of scheduling centered on the time critical needs of control function blocks.
Each control block reads the data it requires from a limited number of locations,
and writes its output after completing its calculation. The time cycle of a
control block is fixed by its configuration (data base), but the User Layer
provides for an orderly recovery of missed cycles based on the process control
model.
The functions defined for the field bus user layer support simple field
sensors and actuators. The user layer function blocks provide for the essential
interchangeability of simple field sensors and actuators, and at the same time
enable manufacturers to establish product differentiation through functional
enhancements. The function blocks defined in the field bus user layer also
anticipate the development and use of field bus control devices. They provide a
means to integrate "continuous" control, "analog" monitoring, and "discrete"
status monitoring and logic control in the same system. The user layer function
blocks provide a means of interoperability for presently-defined and future
control devices from different manufacturers.
OBSERVATIONS AND CONCLUSIONS:

The Field Bus Application and User Layers are now emerging into a model for
communications standards that has not previously been achieved. The transition
from today's diverse process control architectures to a Field Bus architecture
well integrated with a DCS will not be done overnight. We believe this change
will be gradual over the next five to seven years, not because of the lack of
technology, but more due to the conservative nature of the industry. This is the
model for the field portion of that architecture.
--```,``-`-`,,`,,`,`,,`---

12
--```,``-`-`,,`,,`,`,,`---
Introduction
INTRODUCTION
FIELD BUS PROCESS CONTROL USER LAYER TECHNICAL REPORT
The User Layer Technical Report is written as a functional design document

for a hypothetical process control system. As such it is very complete in its
description of data base structures and algorithmic implementation. The
experience of the committee creating the User Layer was more easily focused on a
document in this form. From the fixed structure and language in this Technical
Report, the User Layer Standard could be formed by determining which parts of the
"design" were the hard requirements and which reflected a model of an
implementation. The completeness of the definition was also more easily tested
using a model complete design, although the testing was primarily a "desk check".
The Technical Report can thus be considered to be a model of an

implementation. That model is assumed to also form the base for the later effort
of preparing a conformance test suite. Any implementation of a Field Bus device
that responds to the conformance test in the same way as the model will be
completely acceptable.
Document Arrangement
The immediately preceding Preface provides a brief history of the Field Bus
and the User Layer as well as a tutorial overview. Immediately following this
Introduction is a "Guide" to the Field Bus User Layer. The Guide is a very
condensed "cheat sheet" that compresses many of the important data structures and
concepts that are often necessary while referring to several sections. (The
guide is not a part of the Hypertext version.)
The body of the Technical Report is divided into three main sections:
o Environment -- Each paper describes a major concept and its construct.

The concepts are roughly sequential, and often build upon previously
introduced concepts.
o Function blocks (algorithms) -- The first paper describes functions and

features available to all standard function blocks. Then each standard
function block is separately described with the exceptions to the shared
features and the specific additional features necessary to define the
block. The specific block algorithm follows. The language of the
algorithm is a stylized form of structured BASIC, that should be very
clear to any high level language computer programmer, although there is
no exact language definition or an attempt to formally adhere to one.
o Appendix -- The Appendix provides illustrations and rationale necessary

to understand each major concept and provides in-depth analysis. There
is nothing in the Appendix that is not contained in the first two
sections. Much of the Appendix are the working papers used by the
committee to prepare the Technical Report, and often explains "why" a
particular concept was chosen over alternatives.
SP-50 User Layer Technical Report Introduction

//^:^^#^~
13
Conformance Classes
CONFORMANCE CLASSIFICATION
--```,``-`-`,,`,,`,`,,`---
The Process Control User Layer (PCUL) is not intended to be a rigid standard,
but is designed to allow vendors to implement some of the features, but not all
of the features, and still conform. However, vendors choosing to implement less
than all of the features defined by the PCUL must be able to declare their level
of conformance so that users will have a rational expectation for such a system.
It is not the intent of this standard to imply that the highest level of
conformance is necessarily better than any other level. Our intent is to define
these levels in unambiguous terms.
It is the intent of this Conformance Classification to link to the

definitions of "interchangeable", "interoperable", "interworkable", and
"interconnectable" as defined in the paper "Data Owner Structure - Logical
Nodes", pages 2 and 3.
In order that users may have an even clearer understanding of conformance

classes, the diagram which follows provides for sub-classes of each of the main
classes defined above. It should be noted that devices which do not meet the
requirements for at least interconnectable are classified as "No Class", and
cannot reliably be operated on the same Field Bus with any conforming device.
Figures 1 and 2 detail the system that is to be used to describe the

specific level of conformance.
13SP-50 User Layer Technical Report Conformance Classes 13

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
14
CONFORMANCE CLASSIFICATION
Start
No
Physical Node (PN) has a "TAG" name and a "Data Record" and No
Operates with the UL.SS (DOS-LN, pg 1&2 Class
Yes
Meets Class 1a Is "Interconnectable"
PN appears to have 1 or more "Logical Nodes", each having a "Tag" No

Name and a "Data Record" and each LN having 1 or more Class
associated "Function Blocks" (FB) where the FBs in 1LN have 1a
a common scheduling algorithm. Each FB has a "TAG" name and a
Yes
Meets Class 1b Is "Interconnectable"
No
--```,``-`-`,,`,,`,`,,`---
Each PN and LN supports the minimum data items and each FB meets the Class
"Open" requirements? (ABP, pg 19-22) 1a
Yes
Meets Class 2a Is "Interworkable" Cont.
Figure 4 Conformance Classification
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

15
CONFORMANCE CLASSIFICATION-cont.
Cont.
No Class
Each FB supports the minimum data items? (APB, pg 23)
2a
Yes
Meets Class 2b Is "Interworkable"
No
Each FB meets the requirements of the "Interoperable Generic" Class
Block and each LN is one of the defined LN types? (DOS-LN pg 3) 2b
Yes
Meets Class 3a Is "Interoperable"
Each PN and LN supports the minimum data items and each FB meets No Class
the "Open" requirements? (ABP, pg 19-22) 3b
Yes
Meets Class 3c Is "Interchangeable" Class
3c
--```,``-`-`,,`,,`,`,,`---
Figure 5 Conformance Classification (cont.)

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
16
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
References
References
NORMATIVE REFERENCES:
The following standards contain provisions which, through reference in this

text, constitute provisions of this part of this Technical Report. At the time of
publication, the editions indicated were valid. All standards are subject to
revision and parties to agreements based on this part of this Technical Report
are encouraged to investigate the possibility of applying the most recent
editions of the standards listed below. Members of IEC and ISO maintain
registers of currently valid International Standards.
IEC 1158 Field Bus Standard

ISO 8824 Definition of ASN.1
ISO 8825 Basic Encoding Rules for ASN.1
ISO 7498/1 Open Systems Interconnection - Basic Reference
Model
ISO 646 Binary Encoding for Visible Characters [Probably
this will disappear in favor of our own list due
to recent revisions of ISO 646.]
IEEE 754-1985 Binary Representation for Floating Point Numbers,
ISO<**??
ISA S5.1 Instrumentation Loop Naming Standards
DENORMALS DEFINITIONS:
The handling of the denormal floating point numbers in Standard Field Bus
devices will be as specified here:
--```,``-`-`,,`,,`,`,,`---
- the 32 and 64 bit representations of -0 will be considered

semantically equivalent to +0
- the 32 and 64 bit representations of - infinity and + infinity
will be considered semantically equivalent.
- the 32 and 64 bit representations of NaN (all bits set in
exponent, 1 or more mantissa bits set) will be retained.
- a negative NaN will be considered semantically equivalent to
a positive NaN.
This Technical Report will define the handling of NaN.
16SP-50 User Layer Technical Report References 16

17
SP50 User Layer Guide Sheet
SP50 User Layer Guide Sheet
Bit Mode (Priority Order)

7 O/S - Out of Service
6 Iman - Initialization Manual
5 LO - Local Override
4 Man - Manual
3 Auto - Automatic
2 Cas - Cascade
1 Rcas - Remote Cascade
0 Rout - Remote Output
Figure 6: Modes by Bit
HARDWARE POINT TYPES

Ct - Counter Inputs
DR - Discrete Registers
HI - Human Interface
ME - Foreign Memory
PO - Pulse Outputs
SI - Scalar Inputs
SO - Scalar Outputs
SR - Serial Comm. Ports
VD - Voted Discrete Out
VS - Voted Scalar Out
Multiplexors
CO - Composition
TK - Tank Gauging
Figure 7: Hardware Point types

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Bit Status Info

00 No-Com - No Communication
11 Bad - Bad Value
22 NFP - Not from Process
33 Spl - Remote Blk; Hedw - LO
44 Fail - Failure in Path to Proc.
55 No-Path - No Path to Proc.
66 ATW-h - Wound-up-High
77 ATW-l - Wound-up-Low
Figure 8: Status Info. by Bit
SP-50 User Layer Technical Report Data Owner Structure - Logical Nodes
--```,``-`-`,,`,,`,`,,`---

18
Environment
BLOCK ALGORITHMS:
Analog Blocks Discrete Blocks:

Analog Input Device Control
Analog Output Discrete Input
Counter Discrete Output
Dynamic Compensation Discrete Reg. I/O
Math Human Interface
On/Off Control Logic
PID Program Control
Property Conversion
Pulse Width Modulated Special Blocks:
Signal Capture Batch Collector
Signal Characterizer Composition
Signal Selector Tank Gauging
Splitter
Timer Serial
Totalizer Serial Communications
Tuner Serial In Conversion
Memory I/F:
Scalar (4)
Register I/F
--```,``-`-`,,`,,`,`,,`---
Figure 9: Block Algorithms
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

19
LOGICAL NODE TYPE:

MASTER NODE
Undefined DATA
Unscheduled Standard Mfg. Set:
Cycle / Phase Std MX=min exp
Cycle/Phase MB=Maximum #
CBX & PN by Block Blocks
Timed Standard MBC=Max # blocks/cycle
Cyclic Standard User Set:
Cyclic CX=Time exp.
CBC= current blocks/cycle
BLOCK TYPE: CYCLE TIME=

Standard (base) 2CX sec
Alternate(data of base, rule part -----------or-------
free) 2(CX+BX) sec & phase = PN
Generic (min. data part defined
generically, rule part free)
(Any of the above can be
Extended)
Open (data and rule parts free).
Figure 10: User Layer Terms

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
--```,``-`-`,,`,,`,`,,`---

20
RCas RCas
SP S (Rest) Status
e
Status Value(EU)
Device, t
Value(EU) Ladder, and Cas
Program only p ROut
Mode
Null A o Status
Immediate n i Value(EU)
W/ Stat. Results y n
(Output only) t
Writeable p SP Auto Out0
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Required o p Status Cas Status
Active * i t' RCas Value(EU)
Value(EU)
On-Block n r
On-Block Ctd. t s
Physical Hdwr. e
On-Node @ r Combined into
s #0 Block
Off LN, On PN @ Input 0 Out1
Off-Node @
#1 Calculation
Pointer in
#2 Algorithm
Off-Node &FB @ Most blocks
Options:
* On-Con=Bad?
@ & w/Rev.#
Figure 11:Cascade Structure
--```,``-`-`,,`,,`,`,,`---

21
USER LAYER
--```,``-`-`,,`,,`,`,,`---
STRUCTURE
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Overall structure of the data-owning
field devices and their interaction with
the data consumers on Field Bus

22
Data Owner Structure Hardware
Each of the devices that will connect to Field Bus will be a "physical node".
From the perspective of Field Bus, it will have one Field Bus connection and a
single bus address.
Some of the devices that connect to Field Bus will contain a set of data that
pertains to a "tagged object". When those devices need to make the tag's data
available to other Field Bus devices, they will be known as "data owners". This
paper will define the physical node of a "data owner": the physical process
connections, the structure and timing of the process input and output signals,
and certain data and services pertaining to the whole device.
This paper is divided into the following sections:

PHYSICAL NODE
COMPLEX DEVICE
LOGICAL NODE
PHYSICAL PROCESS DATA CONNECTIONS
PROCESS SIGNAL ACCESS
PROCESS I/O SERVICE TIMING
Input Execution - CT Points
I/O Execution - DR Points
I/O Execution - FM Points
I/O Execution - HI Points
I/O Execution - PO, SI, and SO points
I/O Execution - SR Points
Input Execution - CO
Input Execution - TK points
Output Execution - VD and VS
PHYSICAL NODE I/O PARAMETERS
UNUSED PHYSICAL OUTPUT HARDWARE
FAIL-SAFE TRIGGERS
PHYSICAL NODE CYCLE TIME
SYSTEM CLOCK
Field Bus Time
Private Clock
Independent User Layer Engine
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Alarm Clock
Basic Alarm Clock
Alarm Clock Retention
Time Parameters
PHYSICAL NODE OPTIONS BIT STRING
MISCELLANEOUS PHYSICAL NODE VARIABLES
MISCELLANEOUS HIGHER LEVEL SYSTEM VARIABLES
Figure 1 - A Field Device on Field Bus
Figure 2 - A Complex Field Bus Device
PHYSICAL NODE:
Any device connected to Field Bus will be considered, from the perspective of
the Field Bus, as having one, and only one, physical connection to a particular
Field Bus. Such a device will be identified as a "physical node". A physical
node is uniquely related to a Field Bus physical media connector. The
application layer protocol will define the mechanism that is employed to assign a
Field Bus ADDRESS to a physical node. From the perspective of the User Layer,
there is only one address for a total physical node. (The "address" stored in
the User Layer memory will have the "node number" in the high byte and the
"Subnode Number" in the lower byte - see the lower communication layers for
definitions.)
--```,``-`-`,,`,,`,`,,`---

23
There will be certain data that will be accessible to Field Bus that is
related to the physical node itself, not to any subordinate structures.
Therefore, the physical node will contain, and relate uniquely, to a particular
data record. The data items will be addressable by the physical node "TAG" plus
the appropriate "parameter code".
The physical node TAG will conform to the naming conventions of the Field Bus
protocol. Specifically, the TAG will be a contiguous string of up to 16 visible
characters, padded to a full 16 characters with blanks (character 32[10]) in the
right-most character positions. The only visible characters that can be used in
the TAG are the upper case Latin letters (visible characters 65[10] - 90[10]),
the 10 numbers (visible characters 48[10] - 57[10]), and a dash ("-", visible
character 45[10]). In addition, the dash can not be the first nor the last
character in the tag name and at least one of the visible characters must be a
Latin letter or a dash. The TAG will be set using the special Application Layer
service (see the paper "Application Support Services Interface"). A thirty-two
character visible string variable, "TAG_DESC", will be supported for every
physical node; it will be a User entered descriptor of the node.
There is much controversy about the use of the dash in the tag name.
Specifically, the dash is interpreted by some parsers as a minus sign. On the
other hand, ISA S5.1 specifically recognizes the dash. This Field Bus Standard
is in accord with S5.1: it specifically accepts the use of the dash and requires
the absence of the underbar in all tag names in all field devices. However, some
higher level systems will intercept all "upward" transmissions of tag names and
--```,``-`-`,,`,,`,`,,`---
convert all dashes to underbars (and likewise change underbars to dash in all
"downward" transmissions). It is strongly suggested that Field Bus human
interfaces such as hand held communicators should provide a method of selecting
(on a universal basis) between the two characters in any display or entry of a
tag name. The ultimate requirement for the field device's memory, however, is
the dash, NOT the underbar.
The parameter code will be a 13 bit integer with three attribute bits
associated with it. Many parameters are defined in the papers "Array of Basic
Parameters" and "Array of Standard Block Parameters".
COMPLEX DEVICE:
Two or more physical nodes may be associated together to form a "complex"
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
device. In such an arrangement, each physical node is associated with its own
Field Bus physical connection and unique address and has its own data records.
The complex device will not be known to the Field Bus in that it will not have an
address nor data records nor any accessible data.
Two types of hardware connections will be defined below, the voted discrete
output and the voted scalar output, that will recognize that the output hardware
signals of the physical nodes are voted by the complex device and the result of
the vote is the actual output of the device. In addition, certain input signal
connections will be defined in a later paper (Off Field Bus Agents in the paper
"Agents"), that allow parameters to be accessed across physical nodes in one
complex device.
LOGICAL NODE:
Within a physical node, there will be one or more "logical nodes". From the
perspective of the Field Bus, each logical node will be a separate software
structure in the Field Bus environment.
Each logical node within a physical node will have an assigned TAG. This name
will conform to the naming conventions of the Field Bus protocol. It will be
entered as the value of a parameter of the physical node. Once the logical

24
node's TAG is configured, the data parameters of the logical node will be
addressable by the logical node's TAG.
One or more "Function Blocks" will be coordinated by a logical node. The

function blocks execute a set of rules (their "algorithm") against their inputs
and data items to generate a set of outputs.
A separate document ("Data Owner Structure - Logical Nodes") defines the

Logical node structure.
PHYSICAL PROCESS DATA CONNECTIONS:

The process data will be modeled as connected to the physical node. The
Field Bus Standard recognizes the following classes of process signal physical
connections to a Field Bus physical node:
CT - Counter Inputs PO - Pulse Output
DR - Discrete Registers SI - Scalar Inputs
FM - Foreign Memory SO - Scalar Outputs
HI - Human Interface SR - Serial Communication Ports
The Standard incorporates provision for devices that are data multiplexers.
These provisions include special node types and special blocks designed for the
following types of data/applications:
CO - Composition
PS - Property Scanners
TK - Tank Gauging
The standard Analog Input block and the standard Scalar Input physical point type
can be used in a multiplexed AI system as defined.
The Standard also recognizes two classes of physical outputs that can be used
in (and only in) a complex device. They are:
VD - Voted Discrete Outputs
VS - Voted Scalar Outputs
There can be uncertainty in definition for several of the I/O classes:
The Counter Input is intended to refer to a connection that

includes a counting register that counts the number of OFF TO ON
transitions of the input between executions of the associated block and
reports the INCREMENTAL counts, not the current state, to the block.
Any field device that counts off to on PLUS on to off transitions will
be non-standard. The design is based on the assumption that there are
many counts per logical node cycle. There may well be cases where a
discrete signal is connected to a block that, itself, counts
transitions. However, in such a case, the transitions must occur at a
rate that is slower than the cycle time of the node; such signals would
be classified as Discrete Register inputs, not counter inputs, despite
their ultimate use.
A Discrete Register can contain up to 16 discrete points. The

manufacturer defines the exact number. For example, the manufacturer
might choose to divide 16 discrete points across 4 registers of 4 points
each. The discrete points are modeled as being configurable by point
for either input or output service but the manufacturer can force the
definition.
--```,``-`-`,,`,,`,`,,`---
The Foreign Memory class refers to an association with the contents

of a register or discrete in a memory that is remote from Field Bus and
is not designed according to the Field Bus model. An agent for a
function block will identify the specific location in the foreign memory
using only an integer. The agent will be able to read and/or write to
the foreign memory.

//^:^^
25
The Pulse Output shares many characteristics with a single point in

a discrete register. As with the Counter, the difference is a matter of
timing. The Pulse Output is intended for applications where the
hardware can or does manipulate the output signal on a time basis that
can be faster than the logical node scan time. The term "manipulated"
implies an action more complex than a simple delay-off timer.
The "Scalar" hardware types are those hardware connections that

connect 1 primary scalar variable to the physical node. There may be
secondary variables associated with the primary variable but those
secondary variables will not automatically have their own tag names.
The scalar hardware type does NOT include variables interfaced using
industry standard serial data communication protocols.
The Composition and Tank Gauging blocks are not only designed for
multiplexer service but are also designed for a specific class of
application.
From the perspective of a physical node, the VD class is

essentially the same as the DR class except all of the points in the VD
class are output signals and the complex device is known to be voting
the outputs of two or more physical nodes to determine the final
physical output. Therefore, there are different alarm conditions to be
detected and reported.
The VS class is similar to the SO class except that the complex

device is known to be voting the outputs of two or more physical nodes
and, as for the VD points, there are different alarm conditions.
If an interoperable Field Bus physical node is built with any of the above
classes of physical connections and they will be addressed by the structures
within the logical nodes, then the external physical connections will be labeled
on the physical device with a hierarchical structure of the form:
{signal class}.{connection number}.{subidentifier} The "signal
class" will be an identification consistent with, or an extension of, the above
signal classes. The "connection number" will be the index number of the signal
within the class of signals, starting with the number zero. The "subidentifier"
will be used for compound signals and for the individual points in a discrete
register.
A complex device will use labeling that is consistent with the above rules.
Each array of output points will be clearly labeled as being associated with one
of the physical nodes (i.e., of a class other than VD or VS) or as being a voted
output (i.e., of the VD or VS class). The output points that are brought
together by voting must have the same identification in each of the individual
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
physical nodes (i.e., each VD-x for the complex device must correspond with the
same VD-x in each physical device in that complex device where x is a single
integer - zero based). If one or more of the physical devices in one complex
device does not participate in the voting, then those particular physical devices
must not use the corresponding VD or VS connection number.
The attached Figure 1, "A Field Device on Field Bus", illustrates the over-
all arrangement of an interoperable Field Bus physical node. Note that the
primary hardware signals do not explicitly connect to any Field Bus visible data
base structure. Rather, specific block configuration data are used to identify
the connections. As shown by the dotted lines, some of the physical node data
will be mapped into each of the logical node's data bases. Figure 2, "A Complex
Field Bus Device", illustrates the arrangement of three physical nodes into one
complex device. Note that the three Field Buses are separate and that one output
connection is shown as being voted.
--```,``-`-`,,`,,`,`,,`---

26
PROCESS SIGNAL ACCESS:

Each of the process signal "connections" will appear to Field Bus software
structures as single entities. They will normally be addressed by the "blocks"
(see the separate paper "Data Owner Structure - Logical Nodes" for a description
of blocks) within the associated logical node as:
{connection number}
The block hardware pointers do not have to explicitly identify the signal class
because that is implicit in the block algorithm. All Standard block types that
can address hardware are limited to addressing only one type of hardware.
The connections can only be made between the process connections and hardware
type agents (i.e., blocks) 1) of the appropriate signal type and 2) from blocks
within the same physical node. For example, the connection between an AI block
and its physical data, an SI input, is made with one hardware type agent. The
agent's pointer definition resides in the AI block data base. A number of values
are probably transmitted in both directions over that single connection. The
data structure of the software connections to the process signals need not be
defined by Field Bus since the connection is within the physical node: the
manufacturer has complete control of both ends of the connection.
The connections in one signal class will be defined in the physical node as a
single dimensioned array. It will frequently be assumed, for variable definition
purposes, that each output has a feedback self-check circuit (this does not mean
a feedback from the process, only from the device's own outputting circuit).
Also, some signals will be assumed to have multiple external variables associated
with them. For example, there might be a feedback of the valve stem position
associated with a modulated valve output; it will be labeled on the hardware as
--```,``-`-`,,`,,`,`,,`---
associated with the primary scalar output using the "subidentifier" notation.
Some system designers may wish to design the scalar physical hardware so that
the user can configure it as either an input point or an output point. This will
be allowed and implemented in the following way. The physical point will be
designated as SI/SO-x where x is a zero based integer. In that physical device,
all values of x are then eliminated from the numbering scheme for the simple SI's
and SO's. For example, if there is an SI/SO-3, there can not be an SI-3 nor an
SO-3. The user then can configure either an AI or an AO function block to SI/SO-
3 but not both.
The discrete points will be structured in sets of up to 16 individual points.

A set will be called a "register". The "subidentifier" designator will identify
the discrete point within the set of 16; it will be an index number starting with
zero and will be referred to as "bit".
The Discrete Register block is defined on the basis that the discrete points
within a register can be identified by the user as inputs or outputs on a per-
point basis. If that is not the case, the data base identifier for this option
(within the connected Discrete Register block's data base) can be forced by the
manufacturer to be read-only and fixed at the predetermined value providing a
write to that location receives a response indicating that that value is "read-
only". In addition, a Discrete Input block must not be allowed to be connected
to any I/O connections that are Output only and vice versa (a violation will
generate a "configuration" notification).
The Discrete Register block is also defined on the basis that the discrete
points, when configured to be outputs, will be able to be configured to implement
feedback checking of the discrete output on a point by point basis. This
checking is assumed to be a check of the output circuit of the physical node, not
a feedback from the process equipment being driven by the discrete output. It is
assumed that this checking can be optionally disabled. The "disable checking"
option is a defined data base item within the connected block's data base. If
the manufacturer chooses to not offer the checking option, he can force the
disable option to always be true providing a write to that location receives a
response indicating that that value is "read-only".
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

27
PROCESS I/O SERVICE TIMING:

The timing of the physical input and output of data is loosely defined for
some applications but it is carefully defined for applications in which it is
desirable to be able to "interchange" Field Bus devices from different
manufacturers. The following discussion will indicate the sections of the I/O
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
design that, with careful design, can achieve interchangeability.
In the following discussions, all references to "block time" will be

understood to refer to the block's scheduled time period as defined by the
current configuration of the block cycle times and number of blocks.
Input Execution - CT Points:

The physical capture of counter input data will be driven by the
execution of the logical node cycle of the logical node in which the
associated blocks reside, not the individual execution of the blocks
associated with the I/O. It follows, then, that this timing definition
can not apply to the cycle/phase nor the unscheduled node types. In
those nodes, the timing will be defined by the manufacturer and the
device will not be interchangeable.
The incremental count value will be captured after the start of the
logical node cycle but before the execution of Block 0. The capture for
all counters in the physical node that have their associated blocks in
one logical node will occur "at the same time". The incremental value
will be available to any number of function blocks in the same logical
node that wish to access it. However, if a block in any other logical
node in this physical device attempts to access the same hardware, the
second access will cause an immediate block configuration error
notification and O/S mode for the second block. However, the user must
be able to change the hardware pointer(s) on the block(s) in the first
logical node and then address the physical hardware point from a
function block in a different logical node in the same physical node
without receiving an alert.
These points are potentially "interchangeable".
I/O Execution - DR Points:

The Standard defines three different types of blocks that can
interface to discrete I/O. One of those blocks can interface to a
complete discrete register, the other two can interface to a sub group
of the points (1 to 16 bits wide) in a single register or across
adjacent registers. Two of the blocks are unidirectional (Input only or
Output only) while one can contain a mixture of both Input and Output
discretes within its one register. The manufacturer is expected to
support all of the variations required by the algorithms that are
offered in the node.
A discrete register can contain up to 16 discrete points. The

manufacturer defines the exact number. For example, the manufacturer
might choose to divide 16 discrete points across 4 registers of 4 points
each. If there are only 4 points in a register, then the associated
Discrete Register block would service 4 points, not 16. It is required
by the Standard that the hardware type agent of the Discrete Register
block addresses a single, full register. That register may contain
fewer than 16 discretes; the "first" discrete in the register
corresponds to bit position 0 in the block's register. The succeeding
bits follow in order. The Discrete Register block includes a mask that
--```,``-`-`,,`,,`,`,,`---

28
can mask off one or more of the bits but the mask can not shift the
positions of the bits. The Discrete Input and Discrete Output blocks
can define the number of bits in their groups and the location of the
first bit. The range thus defined can span across adjacent I/O
registers.
It is required that the (user) configuration of the device must

arrange the blocks associated with the discrete I/O in such a way that
each discrete register is accessed by blocks from only one logical node.
If a block in any other logical node in this physical device attempts to
access the same hardware, the second access will cause an immediate
block configuration error notification and O/S mode for the second
block. However, the user must be able to change the hardware pointer(s)
on the block(s) in the first logical node and then address the physical
hardware point from a function block in a different logical node in the
same physical node without receiving an alert.
The physical capture of discrete input data (as distinct from

output feedback data) will be driven by the execution of the logical
node cycle, not the execution of the blocks associated with the I/O.
The raw input values will be captured after the start of the logical
node cycle but before the execution of Block 0. All discrete input
signals in a physical node that have their associated blocks in a
particular logical node will be captured "at the same time". However,
the "finished" data values in the discrete input function blocks must
not be available to the ultimate user blocks until the input blocks
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
execute.
The physical output of discrete data can occur at any time in the
logical node cycle between:
1) the start of the execution time of the discrete I/O function
block driving the output
AND
2) the start of the execution time of function block 0 in the
immediately next cycle of the logical node.
The acquisition of the output feedback data can occur at any time
in the logical node cycle as determined by the manufacturer. There may
be cycles in which feedback checking can not be done because a recent
change in the output may not have returned in the feedback circuit. The
Field Bus functionality model assumes that the miscompare data is
available at the beginning of the block execution time of the discrete
I/O block.
The input and output of data associated with discrete physical I/O
will involve the execution of procedures by both the hardware and the
block and will also involve the transfer of data to/from the physical
I/O. If a second block, in this logical node or any other logical node
in the physical device, attempts to access the same hardware later in
the same cycle, the second access will cause an immediate block
configuration error and O/S mode for the second block. Note that this
restriction applies to each discrete individually and must recognize the
mask that is provided in the Discrete Register block. (The discrete
register block allows selected bits in a hardware register to be masked
out so they can be addressed by the Discrete Input and Discrete Output
blocks).
I/O Execution - FM Points:

The function blocks that use hardware agents that access foreign
memory are based on a model in which the foreign memory assess is
accomplished by one of two methods:
1) "prefetching" and "poststoring", just like communications
over the Field Bus.
--```,``-`-`,,`,,`,`,,`---

29
2) the use of a "read handler" in the node that can execute

the "remote read" as part of the communications service.
The exact timing of reading and writing from/to the foreign memory is
not defined by Field Bus. It is not anticipated that the devices that
use this type of hardware agent can be interchangeable devices.
There is no requirement that the Field Bus device must assure that
--```,``-`-`,,`,,`,`,,`---
access to the foreign memory data items is unique.
I/O Execution - HI Points:

The exact timing of signal capture and release in a Human Interface
block is not defined by Field Bus. However, if a second block, in this
logical node or any other logical node in the physical device, attempts
to access the same hardware later in the same logical node cycle, the
second access will cause an immediate block configuration error and O/S
mode for the second block.
These points are potentially "interchangeable" since the

application will not require tight timing.
I/O Execution - PO, SI, and SO points:

The PO, SI, and SO data types will be driven by the execution of
their associated block. Consider an Analog Input block and the SI
hardware to which it points. The actual physical "snap" of the SI
measurement is to occur after the start of the execution of the AI block
but before the end of the first 10% of the block's time. This
requirement recognizes that there may be an analog filter ahead of the
A/D converter: its effect is not included in the requirement. Also,
if the A/D conversion uses any kind of counting mechanism, the "snap"
refers to the termination of the count.
For an AO function block, the conversion of the digital output to

its physical form is to take place before the end of the first 25% of
the block's execution time. However, it is acceptable that the physical
circuit not have completed slewing to the indicated value before the end
of this time limit.
For a Pulsed Output point, the physical output will be operating

according to the new request from the block by the end of the first 25%
of the block's execution time subject only to the constraints of the
definition of the pulse.
It is assumed that the execution associated with the PO, SI, and SO
physical hardware will involve both the execution of procedures by the
hardware and the block and also the transfer of data between the block
and the hardware. If a second block in this logical node, or a second
block in any other logical node in this physical node, attempts to
access the same hardware, the second access will cause an immediate
block configuration error notification and O/S mode for the second
block. However, the user must be able to change the hardware pointer on
the first block and then address the physical hardware point from a
different function block in any logical node in the physical node
without receiving an alert.
I/O Execution - SR Points:

The exact timing of signal capture and release is not defined by

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
30
Field Bus, even for interchangeable devices. The Standard Serial

communication blocks assume that the hardware port is "freerunning" and
may or may not have room in its buffer for an outgoing message and may
or may not have an awaited response. They also include provision for
several blocks driving the same port, each block with its own "channel"
number. All of this applies across all logical nodes within the same
physical node. However, if a second block with a hardware pointer to
the same port and the same channel number is executed later in the same
logical node cycle, the second access will cause an immediate block
configuration error notification and O/S mode for the second block. Of
course, if the manufacturer does not support channel numbers, then any
second access will cause the error condition.
These points are potentially "interchangeable" since the

application will not require tight timing.
Input Execution - CO:

The composition point is assumed to reside in "unscheduled" type
logical nodes. Therefore, these points do not have defined timing for
their input and are considered "interoperable".
If a second block in this logical node attempts to access the same

component, the second access will cause an immediate block configuration
error notification and O/S mode for the second block. However, the user
must be able to change the component pointer on the first block and then
address the component from a different function block in the logical
node without receiving an alert.
Input Execution - TK points:

The TK input type is assumed to be multiplexer type data. Its
associated function blocks are assumed to be in a cycle/phase type node.
Each point will be input in the logical node cycle specified by the
cycle and phase data configured into the associated individual function
blocks. The exact time within the logical node cycle is not defined.
Therefore, these points are considered "interoperable".
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
It is assumed that the execution associated with the TK physical
hardware will involve both the execution of procedures by the hardware
and the block and also the transfer of data between the block and the
hardware. If a second block in this logical node attempts to access the
same hardware, the second access will cause an immediate block
configuration error notification and O/S mode for the second block.
However, the user must be able to change the hardware pointer on the
first block and then address the physical hardware point from a
different function block in the logical node in without receiving an
alert.
Output Execution - VD and VS:

The voted outputs, both VD and VS, are modeled as being voted
external to the operation of the individual physical/logical nodes.
Therefore, the output from a particular physical node (going to its
voting "circuit") will follow the timing constraints of the
corresponding non-voted output as defined above.
There are no defined constraints on the timing of the output signal

going through the voting "circuit". The individual I/O algorithms will
--```,``-`-`,,`,,`,`,,`---
assume that the physical node hardware will handle, in a manufacturer

defined way, the timing considerations of the feedback checking signals.

31
PHYSICAL NODE I/O PARAMETERS:

It is expected that manufacturers will design a method of calibrating the
physical node's hardware. If the user is to interact with the calibration data,
there must be a defined method of accessing it. This will be supported using a
special data type called the "auto-formatting variable"; it will be defined in
the "Human I/F Considerations" paper.
There may be one of these parameters in the physical node's data base for EACH
physical hardware point and/or one for each TYPE of hardware. They are called
I/O_AF and I/O_TYPE_AF respectively in the "Array of Basic Parameters" paper.
The method of indicating the presence of this data will be defined in the
"Application Support Services Interface" paper.
The "Application Support Services Interface" paper will also define the
method of indicating the presence of an additional (3 times 64) auto- formatting
variables that can be in the physical node's data base. These variables are not
defined in association with the physical node's hardware. They are labeled
PN_AF_x in the "Array of Basic Parameters" paper.
There may be a need for another addressable parameter in the physical node's
data base for a hardware point. Consider a device design in which it is possible
for the block execution to fail but communication services to survive the
failure. In that case, it may be advantageous to provide a communication path
from the Field Bus directly to the hardware. Given such a path, the user could
retain emergency control of the process. This path
is supported by an optional defined parameter in the physical node that can
directly address the hardware. The parameter can only be written when the
computing engine driving the function block processing is stopped.
Support for this parameter will be indicated by a method defined later in

this paper. The data format of this parameter will be defined in the
function blocks that connect to the particular hardware. The parameter number
will be defined in the "Array of Basic Parameters" paper.
UNUSED PHYSICAL OUTPUT HARDWARE:

A service must exist in the physical node to set all physical outputs that
are not addressed by a function block to their no-power state. This is of no
significance to the communication port or to foreign memory interfaces but it is
significant to the Discrete Registers, the Human Interface, the Pulse Output, and
the Scalar Outputs.
The logic defined in the "Field Device Start and Restart" paper includes a
detailed description of the logic that determines if any output hardware points
are unaddressed and sets them to their no-power state if it can be done safely.
That logic is automatically done at start-up of the physical node.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
A single discrete value called "CLEAR_OUT" will exist in the physical node's
dynamic data base. When that value is set, the physical node will:
1) Reset CLEAR_OUT
If the physical node contains any DR, DO, PO, or SO hardware, then
2) execute the data base checking portions of the start-up logic
necessary to confirm that all function blocks have a valid data
base,
If all data bases are valid, then
3) determine if any physical hardware capable of outputting are
unaddressed.
If any are unaddressed, then
4) set them to their no-power state.
--```,``-`-`,,`,,`,`,,`---

32
This operation will be executed when "CLEAR_OUT" is set. It is expected that

time to execute this infrequent function will be generated by having all of the
logical nodes in the physical device suspend for a short time.
FAIL-SAFE TRIGGERS:
The manufacturer of a Field Bus device may optionally include the capability
to connect discrete signals to the device that can be configured to cause the
outputs in the device to assume their "fail-safe" state.
The external fail-safe trigger signals will be attached to the physical

device in such a way that they will not be confused with the discrete register
process signals. There may be a single external signal that will trigger all of
the logical nodes of the device or there may be separate external signals for
each (or selected) logical node. If an external signal does not trigger all
logical nodes in a physical node, it will be labeled with the logical node number
(a simple index number starting with 0).
The Fail-safe Logical will be a parameter associated with each logical node.
There will be no "Fail-safe" logical in the physical node. The logical will be
set by the manufacturer optional hardware input signal or may be written over
Field Bus. See the paper "Data Owner Structure - Logical Nodes", page 20 for the
details of the software implementation of the Fail-safe function.
Although the physical node does not appear to control the Fail-safe logic,
there are two parameters associated with the Fail-safe logic that are housed in
the physical node's data base - SFAIL-SAFE and RESTART. See the paper "Field
Device Start and Restart" for descriptions of these parameters. These two
parameters must be supported by every physical node. Note, however, that SFAIL-
SAFE is self-defining; a manufacturer can indicate in it that it does nothing.
The RESTART parameter is another discrete that must exist but the SFAIL-SAFE
parameter can define that it does nothing.
When the external signal OPENS (current flow below some manufacturer set
minimum), the logical will be set by the leading edge of the change in current
flow. The logical will not reset when the external signal closes. Rather, the
logical will remain set until a Field Bus command resets it. In the paper "Field
Device Start and Restart", the details will be given for the operation of the
Fail-safe system during a device restart. Briefly, in either a "warm" or "cold"
restart, but not during a "hot" restart, the logical will be initialized based on
the external signal's STATE. That is the only time that the logical's operation
will depend on the state.
PHYSICAL NODE CYCLE TIME:

Most of the work of a physical node is scheduled by and within the logical
nodes. However, the paper "Alert Function" will define a method for the physical
node to report its alerts. As part of that method, there is a need for the
concept of a cycle time for the physical node (see the section "Buffer Overload
Indicator" in the paper "Alert Function"). The "alert cycle time" variable in
the physical node's data base will define the time period of the major self
checking diagnostics of the physical node.
This standard does not define nor require any physical node self diagnostics
- it only provides a method of communicating such alerts if needed. Within that
scope, it is assumed that there are two types of self diagnostics conducted by
the physical device. One might be called "slow speed" - it is assumed to involve
a relatively long series of tests, perhaps conducted as a background function, to
check the memory of the device and other low priority or calculation intensive
operations. The other might be called "high speed" - it is assumed to involve
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
33
relatively frequent checking of the physical I/O, the microprocessor itself,

power supply levels, etc.
Every physical node will have a read only, 8 bit signed integer variable "AX"
in its data base. To define AX:
IF the physical node does high-speed self diagnostics, then
let x = the high speed self diagnostic cycle time, in seconds
ELSEIF the physical node checks for changes in the value of TIME_BIAS
defined in the next section, then
let x = the frequency of those checks, in seconds
ELSE
let x = 2**-127
ENDIF
AX = an integer such that
2**(AX-1) < x <= 2**AX
SYSTEM CLOCK:
The primary basis for "time" in a Field Device will be the time information
--```,``-`-`,,`,,`,`,,`---
that is available from the communication services (see the paper "Application
Support Services Interface"). In addition, the manufacturer may optionally
support a "private" clock. This section will detail how that data will be used.
In addition, the manufacturer's option to allow the User Layer logic engine to
operate even though the communication engine has failed generates some clock
duties for the physical node. Finally, there is an option for an "alarm clock"
service.
Field Bus Time:

The "time" recognized by the Field Bus system will be based on the
current International Standard Time. It will not be concerned with local
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
time nor with any form of daylight saving time. The system's concept of
the current International Standard Time is called "Social_Time". It is
the total time since January 1, 1970 at 00:00 AM International Standard
Time till the current time, measured in 1/32 of milliseconds.
Two parameters that relate to system time will be available from

the communication services. They are:
1) NODE_TIME = the elapsed time since the physical device was
last powered up
2) NODE_TIME_OFFSET = the difference in time between January 1,
1970 at 00:00 AM, International Standard Time
(i.e., the arrival of the new year, Greenwich
Mean Time), and the last start-up of the physical
node of the field device.
Both of these values are 48 bit integers expressing time in one-thirty-
seconds of milliseconds (rollover after 279 years). Note that the base
of January 1, 1970 is the same base used by UNIX systems.
There are no Standard function blocks that can access 48 bit

integer values that are defined here.
At initial power-up, the communication service (see optional

enhancement below) will reset both of these values, then begin to "tick"
the NODE_TIME as defined in the Link Layer Standard. Since
NODE_TIME_OFFSET can never have a legitimate value of zero, the reset
value will be the indicator to all users that communication has not been
established.
When communication is established, it is assumed by this paper that

NODE_TIME_OFFSET will be set by the communication services.

34
The alert reporting system, the primary User Layer user of time,
will access the communication layer service to get NODE_TIME for
inclusion in each alert report that it prepares. The access will be
done as part of the servicing of the alert at the time it is discovered.
The time reported in alerts will be a 29 bit integer value formed by
shifting the 48 bit time four bits to the right and using the resulting
29 low bits (a value that has a resolution of one-half of a millisecond
and rolls over after 3.1 days). See the paper "Alert Function" for the
details of the various alert reports to be issued by the physical node.
The physical node will inspect the value of NODE_TIME_OFFSET at

least every "AX" cycle (see section above for the definition of AX) and
report on any significant change using the alert reporting system. To
support this operation, there will be a 16 bit integer parameter in the
physical node's data base, called OFFSET_DB (required if alert reporting
is supported), that will define the deadband on the reporting of changes
in NODE_TIME_OFFSET. OFFSET_DB will also be expressed in terms of
one/quarter of milliseconds, thus giving a maximum possible dead band of
16 seconds. If OFFSET_DB is reset, it will be changed to 1B.
In order to clarify the meaning of these terms and to show a

minimum existence proof of the concept, assume that there is a value
local to the physical node that stores the last reported
NODE_TIME_OFFSET - call it "LR_OFFSET". Then:
At power up,
LR_OFFSET = 0
Once each cycle:
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
access NODE_TIME_OFFSET from the communication layer.

IF NODE_TIME_OFFSET is available, then
TEMP = (NODE_TIME_OFFSET - LR_OFFSET)
TEMP = Absolute(TEMP)
Shift TEMP right 4 bits
IF OFFSET_DB = 0, then
OFFSET_DB = 1
IF TEMP > OFFSET_DB, then
generate an alert report of the type defined in the
paper "Alert System".
LR_OFFSET = NODE_TIME_OFFSET
END IF.
END IF.
Private Clock:
There is a manufacturer's option to support a "private" clock.
This clock will be assumed to be running independent of the Field Bus
clock and will be associated with a LOGICAL node, not the physical node.
ALL time references in the Standard will be based on the Field Bus
clock EXCEPT for a single logical node variable. That variable will be
called PRIVATE_OFFSET and will be reported as a 32 bit signed integer.
Assuming PRIVATE_CLOCK is expressed in the same terms as Field Bus time,
it will be the value of (PRIVATE_CLOCK - NODE_TIME -
NODE_TIME_OFFSET). Its low order bit will correspond to 1/32 of a
millisecond.
If the manufacturer supports a PRIVATE clock and the alert system

in the same logical node, the variable P_OFFSET_DB will be supported.
It will be used to send an alert concerning the adjustment of the
private clock by an amount greater than P_OFFSET_DB. The meaning of
P_OFFSET_DB and the alert will be exactly the same as defined above for
the corresponding system clock alert; a logical node code and subcode
will be used for the alert.
--```,``-`-`,,`,,`,`,,`---

35
Independent User Layer Engine:

There is a manufacturer's option to provide a logic engine for the
User Layer that is separate from the communication service(s). This
option affects the time and alert reporting services; its existence will
will be shown in the physical node's "option string" defined below.
When this option is present, the design of the entire User Layer of
the device will be such that at least 128 bytes of alarm records can be
accumulated while the communication services engine is not functioning.
See the paper "Alert Function" for details concerning the alert system.
As defined above, when a physical node powers up, NODE_TIME will be

reset. If the User Layer engine is separate, then, as soon as the User
Layer is ready to process function blocks, but before doing so, the User
Layer will request NODE_TIME from the communication layer(s). If none
of the communication layers is able to supply NODE_TIME, the User Layer
will begin to function and to "tick" the NODE_TIME. It will do so the
best it can (to the quoted resolution and accuracy of its "User Layer
clock"). When any Field Bus communication layer is ready to start, it
will send a request to the User Layer for its NODE_TIME. If the User
Layer has a non-zero node time, it will pass it to the requesting
communication layer and, from then on, use the NODE_TIME from that
communication layer.
If any communication layer can supply NODE_TIME when the User Layer
starts, then the User Layer will use the NODE_TIME of that communication
layer rather than its own.
If, during normal operation, NODE_TIME becomes unavailable from the

communication layer, then the User Layer will try to get it from any
other communication layers in the physical device. If it is not
available anywhere, the User Layer will again use its own clock.
The detailed service will be defined based on the assumption that

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
there is a local variable called TEMP_TIME in the physical node's data

base. It is assumed to be a 48 bit integer but not available to Field
Bus. No such variable is actually required but the device must function
AS IF the following logic were present. Once each cycle:
At physical node start-up,
TEMP_TIME = 0
At start up and every physical node cycle thereafter,
IF NODE_TIME is available from the communication service that
was used at the last cycle, then
TEMP_TIME = NODE_TIME
ELSE
attempt to find other communication services that have a
NODE_TIME.
If available, then
At every event occurrence,
IF NODE_TIME is available from the communication service that
was used at the last cycle, then
use it for the alert time stamp.
ELSE IF NODE_TIME is available from another communication
service, then
use it for the alert time stamp.
ELSE
use TEMP_TIME.
The physical node is assumed to "tick" TEMP_TIME at all times.
It is assumed that, when there is more than one communication layer

in a physical device, they will coordinate among themselves so that
there is only one value each for NODE_TIME and NODE_TIME_OFFSET.
--```,``-`-`,,`,,`,`,,`---

36
The User Layer will generate (probably into a static buffer!) an

alert when it starts its own NODE_TIME that records that event
(actually, this alert will be a RETURN of alert code 0). When
the User Layer first gains access to a communication services version of
SOCIAL_TIME, that event will generate another alert report (actually,
this alert will be a RETURN of alert code 2).
Alarm Clock:
Since the time values discussed above can not be accessed by any of
the standard function blocks, there is a need for some way for them to
recognize and operate on a social time basis. That is accomplished by
the optional "alarm clock".
Basic Alarm Clock:
This service requires two additional parameters. One of those

parameters, "ALARM_TIME", is a 48 bit unsigned integer and the
other, "ALARM", is an 8 bit binary string that can be accessed by
function blocks. Bit 0 of the string will be set any time
"ALARM_TIME" is non-zero and less than the sum of NODE_TIME and
NODE_TIME_OFFSET, ELSE it will be reset.
Alarm Clock Retention:
In order to provide the highest degree of integrity for the

alarm clock service, there will be a suboption associated with the
alarm clock - called "alarm clock retention". In general, this
feature will attempt to retain its clock setting through a short
power outage and to retain the alarm service in spite of
--```,``-`-`,,`,,`,`,,`---
communication isolation after restart. If it fails to do so, Bit 1
in "ALARM" will be set. Bit 1 can be reset by a masked write. It
will also be reset by the "Data Base Write Service" any time that
ALARM_TIME is written.
This feature will be described on the assumption that there

are internal variables called "TEMP_TIME and "TEMP_BIAS". No such
variables are required; they are used to illustrate the required
functionality. These 48 bit integers are assumed to normally
contain the NODE_TIME and NODE_TIME_OFFSET from the last physical
node cycle and are not accessible from Field Bus. The physical
node may or may not be "ticking" TEMP_TIME.>
This option is best defined as a chain of logic:

IF the communications layer can provide NODE_TIME_OFFSET, then:
TEMP_BIAS = NODE_TIME_OFFSET
ELSE
IF this is the first cycle of the User Layer after starting up,
then
IF (the User Layer has a method of determining that its
TEMP_TIME and TEMP_BIAS were retained during the outage)
AND [the "Warm Restart Timer" did not expire during the
outage (see the paper "Start and Restart")], then
TEMP_BIAS = "Retained" TEMP_BIAS +
"Retained" TEMP_TIME + b
where b = the minimum time that it takes this
User Layer, in this device, to
execute a restart.
TEMP_TIME = 0
ELSE

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
37
--```,``-`-`,,`,,`,`,,`---
TEMP_BIAS = 0.
TEMP_TIME = 0
set Bit 1 in ALARM.
END IF.
If the User Layer can not assure that its physical node
static data base was retained, then
ALARM_TIME = 0
reset Bit 0 in ALARM.
set Bit 1 in ALARM.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
ELSE
IF the physical node does not tick TEMP_TIME, then
TEMP_TIME = TEMP_TIME + physical node cycle time
END IF.
END IF.
IF the communications layer can provide NODE_TIME, then
Time Parameters:
The actual parameters in the physical node data base will be:
- NODE_TIME
+ required
+ reports time since the Field Device started.
+ 48 bit unsigned integer.
+ time in 1/32 milliseconds since device start-up till present.
+ defaults to zero.
+ stored in the physical node's dynamic data base.
+ read-only from Field Bus.
- PRIVATE_OFFSET
+ required if private clock supported
+ reports (private time - Field Bus time).
+ 32 bit signed integer.
+ defaults to minus full scale.
+ read-only from Field Bus.
- OFFSET_DB
+ required if physical node supports alerts.
+ dead band for reporting changes in the NODE_TIME_OFFSET (and
the private clock if there is one).
+ 16 bit unsigned integer.
+ differential time expressed in one-quarter of a millisecond.
+ defaults to 3/4 millisecond.
+ stored in the physical node's static data base.
+ read/write from Field Bus.
- ALARM_TIME
+ optional (existence of option given in the "options bit string".
+ if present:
@ must be readable and writeable from Field Bus
@ a constant stored by the physical node of the field device.
@ 48 bit unsigned integer.
@ is considered inactive when set to exactly zero.
@ is stored in the physical node's static data base.
- ALARM
+ required if the ALARM_TIME option is present.
+ an 8-bit binary string - only 2 bits defined.
+ stored in the physical node's dynamic data base and reset at
device restart (may be immediately set as a result of the above
logic calculation).
+ Bit 0 is controlled by the field device every physical node cycle
as follows:
@ reset at physical node power-up unless the dynamic memory
is known to have survived the outage.
@ IF ALARM_TIME <> 0, then
IF NODE_TIME and NODE_TIME_OFFSET available and
neither are = 0, then
IF (NODE_TIME + NODE_TIME_OFFSET) > ALARM_TIME),

38
then
Set Bit 0 of ALARM
ELSE Reset Bit 0 of ALARM
ELSE IF TEMP_TIME and TEMP_BIAS available and neither
are = 0, then
IF (TEMP_TIME + TEMP_BIAS) > ALARM_TIME, then
Set TIME_EVENT
ELSE Reset Bit 0 of ALARM
+ bit 0 is forced to be read-only from Field Bus by the "Data Base
Write Service".
PHYSICAL NODE OPTIONS BIT STRING:

Every physical node connected to Field Bus will have a "time critical"
options bit string, "TIME_CRIT0". Standard physical nodes will use the following
definition for the 16 bit TIME_CRIT0:
Bit 0 = set if this physical node is part of a complex device (see
above).
Bit 1 = set if this physical node supports a User Layer logic engine
that can run independent of any communication engines (see
above).
Bit 2 = set if this physical node supports restart timers and Fail-safe
(see the paper "Field Device Start and Restart").
Bit 3 = set if an "alarm clock" is supported.
Bit 4 = set if "alarm clock retention" is supported (see above).
Bit 5 = set if the physical node supports a clipboard (see the paper
"Human I/F Considerations" for a description of this option).
Bit 6 = set if the physical node supports an associated clipboard (see
the paper "Human I/F Considerations" for a description of this
option).
Bit 7 = set if primary clipboard "coded" (i.e., all material of
construction information in coded form) (see "Human I/F
Considerations" paper for a description of this option).
Bit 8 = set if primary clipboard "complete" (i.e., all parts that
normally contact the "process fluid/material" have materials of
construction identified) (see "Human I/F Considerations" paper
for a description of this option).
Bit 9 = set if associated clipboard "coded" (i.e., all material of
construction information in coded form) (see "Human I/F
Considerations" paper for a description of this option).
Bit AH = set if associated clipboard "complete" (i.e., all parts that
normally contact the "process fluid/material" have materials of
construction identified) (see "Human I/F Considerations" paper
for a description of this option).
Bit BH = set if this physical node supports direct writes to output
hardware when the block processor is stopped (only defined for
DR, PO, and SO type hardware).
Bits CH - EH = reserved for future standards.
Bit FH = set if this physical node supports any extended parameters. If
this bit is set, parameter EXP0 must exist in the Data
Dictionary. See Attachment 2 to the paper "Application Support
Services Interface".
MISCELLANEOUS PHYSICAL NODE VARIABLES:

There are several additional parameters that are required in the physical
node's data base for Standard physical nodes plus other parameter names that are
defined for possible use beyond the Standard. Some of the parameters are
conveniently defined in subsequent papers of the Technical Report. Others will
be defined here; all of them are combined in the "Array of Basic Parameters"
paper.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"
--```,``-`-`,,`,,`,`,,`---

39
The following data items are required in the data record of all standard
physical nodes:
MFG_NAME - a 32 bit visible string that gives the manufacturer's
name. It is assumed that each manufacturer will ensure
that the name that is used is unique world-wide.
There is no limit on the characters that can be used in
the visible string (see the "Human Interface" paper for
--```,``-`-`,,`,,`,`,,`---
the definition of the fonts available and their

representation).
MODEL_NUMBER - a 32 bit visible string that gives the model "number"
of the physical device. It is assumed that each
manufacturer will control the model numbers so that the
concatination of the manufacturer's name and the model
number will uniquely define a class of physical devices.
There is no limit on the characters that can be used in
the visible string (see the "Human Interface" paper for
the definition of the fonts available and their
representation).
SERIAL_NUMBER - a 32 bit unsigned integer. It is intended that this
number will be a serialized counter whose value is
unique for each instance of a particular model of
physical device. If that assumption is true, then:
- the value will never be zero.
- the concatenation of MFG_NAME + MODEL_NUMBER +
SERIAL_NUMBER will yield a world-wide unique
identification of a particular instance of a
physical device.
- the concatenation can be used as an identifier by
the Application Layer for purposes of restoring
a lost address and physical node tag name to a
device (see the service "Address Recovery" in
Attachment 1 to the paper "Application Support
Services I/F").
IF the above assumption is not true, then:
- the value will be zero.
- the "Address Recovery" service will not function.
The SERIAL_NUMBER will always be displayed and printed
as an integer with no implied decimal point (or a
decimal point at the end).
FIELD_BUS_REV - a 16 bit unsigned integer that gives the revision number
of the Field Bus standard to which it is designed (see
the paper "Human I/F Considerations" for the display
format for this parameter). All devices manufactured to
the August, 1992 version of this Technical Report will
use a revision number of 0.10. This number will be
totally defined by the Field Bus Standard to which the
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
device was designed; it must not include any
manufacturer's subset or superset indicator nor any
other manufacturer's uniqueness.
DEVICE_REV - a 16 bit unsigned integer that gives the revision number
of the physical device (see the paper "Human I/F
Considerations" for the display format for this
parameter).
The concatenation of manufacturer's name, model number,

and revision number will identify a set of devices that
appear to be identical, with respect to the data base
and apparent functional performance, when viewed from
the Field Bus. By definition, a change in the
FIELD_BUS_REV will require a change in the DEVICE_REV.
Note particularly that the sequence of serial numbers

defined above is assumed to continue without repetition
(but perhaps with a break) across device revision

40
numbers.
FB_POWER - a 32 bit floating point number that gives the average
power consumed from the Field Bus by the physical node,
expressed in milliWatts.
FB_CAPAC - a 32 bit floating point number that gives the
capacitance of the Field Bus device at the designed
(or selected) Field Bus communication frequency,
expressed in microFarads.
FB_INDUCT - a 32 bit floating point number that gives the
inductance of the Field Bus device at the designed
(or selected) Field Bus communication frequency,
expressed in milliHenrys.
MIN_TC0 - a 16 bit string parameter that gives the "minimum"
acceptable value for the previously defined TIME_CRIT0.
This value will be initialized, by the Field device

during a startup in which the static data base was lost,
to the current value of TIME_CRIT0. The Field device
will maintain this parameter in its static data base and
allow free R/W access. Otherwise, it will not use nor
change its value.
A higher level device may download a different value as

part of a data base restore operation or it may simply
change the value at any time.
The intent is that the higher level system can confirm

that a field device supports the options that are needed
for a particular service. It would do that by comparing
TIME_CRIT0 (the options that are actually present) with
MIN_TC0 (the options that are needed). If any bits are
set in MIN_TC0 and the corresponding bit is reset in
TIME_CRIT0, then the higher level system would report
that situation.
The following parameters are given partial definitions in the paper "Array of
Basic Parameters" - they may be used by physical nodes that add extensions or
alternatives to the standard physical nodes:
- Two additional time critical bit strings, TIME_CRIT1 and TIME_CRIT2.
The length of these bit strings is not defined.
- Three non-time critical bit strings, N_TIME_CRIT0 to N_TIME_CRIT2.
The length of these bit strings is not defined.
A parameter called COUNT_TIME and 12 associated parameters are defined in the

paper "Array of Basic Parameters" for use by the Management Layer in reporting
data to the User through the normal user interface. All of these variables must
be supported in the dynamic memory by a standard physical node. COUNT_TIME
defines the time period over which errors have been collected, TOT_MESSAGES
defines the total messages during that time, and seven of the associated
parameters are counters for the total number of errors during that period. All
of the errors described by the counters will be counted - even errors that are
cleared by retries.
Three additional parameters support an error rate alarm.
The set of parameters are defined as follows:

- COUNT_TIME
A parameter expressed in the same format as NODE_TIME. It is set
equal to NODE_TIME when the device is powered up with a lost
dynamic physical node data base. It can be "reset" by a Field Bus
command where "reset" means it is set equal to the then-current
--```,``-`-`,,`,,`,`,,`---
NODE_TIME. When it is reset, the Data Base Write Service will

also reset the 9 associated counter parameters.
If any of the 9 counter parameters roll over, the other 8 counter
parameters will be set to zero and COUNT_TIME will be set equal to
the then-current NODE_TIME.
- TOT_MESSAGES

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
41
Total messages to or from this physical node. Set to zero when the
device is powered up with a lost dynamic physical node data base.
- APPL_FAIL
Total number of failures associated with the Application Layer:
the sum of all schedule request failures, association request
failures, define parameter group request failures, read and write
service failures not caused by physical layer failures, subscribe
service request failures, etc. In short, all failures not covered
by the following 6 companion error counters.
Set to zero when the device is powered up with a lost dynamic

physical node data base.
- CRC_ERROR
CRC errors in messages written to this physical node. Set to zero
when the device is powered up with a lost dynamic physical node
data base.
- FRAMING_ERROR
Framing errors in messages written to this physical node. Set to
zero when the device is powered up with a lost dynamic physical
node data base.
- PARAM_NOT
The total number of messages received addressed to a parameter that
was not supported by the TAG'ed entity addressed. Set to zero when
the device is powered up with a lost dynamic physical node data
base.
- WRITE_BUF_FUL
Write messages to this physical node that had to be rejected
because the write buffer was full. Set to zero when the device is
powered up with a lost dynamic physical node data base.
- ALERT_BUF_FUL
The total number of instances in which an alert was discovered but
could not be accepted by the alert handler. This parameter will be
be supported and set to zero if this physical node does not support
alerts. It will be set to zero when the device is powered up with a
lost dynamic physical node data base.
- READ_HAND_BSY
Messages to this physical node requesting a read that had to be
rejected because the read handler was busy. This parameter will be
be supported and set to zero if this physical node does not support
a read handler. It will be set to zero when the device is powered
up with a lost dynamic physical node data base.
- CYCLE_OVERRUN
This integer will count the number of times that the write handler
buffer is not emptied in a complete physical node cycle.
The counter will operate as if the following method were used. The
physical node will set a flag at some time in the physical node's
"AX" cycle. The write handler will reset the flag any time that
it finds the buffer empty. At the next "AX" cycle, if the flag is
not reset, this counter will be incremented. Then the flag will
be again set and the cycle repeats. This counter will be set to
zero when the device is powered up with a lost dynamic physical
node data base.
The above parameters are concerned with total messages and errors since the
start of counting. It is necessary to originate an alarm if there are too many
of some of these errors but the alarm can not be based on the total of the number
of errors. Therefore, there will be the following additional required parameters
to support notifications:
- ERROR_RATE
The total number of framing plus CRC errors (maximum of 1 error per
message) that occur in one period of time divided by the number of
communications in that period. The update of the number will be
skipped if there are no communications in the period. This value
will be a 4 byte floating point number that is initialized to 0.
when COUNT_TIME is reset.
- FILTER
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
42
The time constant for the first order filter for updating the above
rate value. This parameter will be an 8 bit unsigned integer
giving the filter time constant in whole seconds. This value will
be initialized to 255 when the device is first powered if the
physical node static data base was lost.
- ERROR_RATE_LIM
The maximum value of ERROR_RATE above which an alarm will be
generated for this communication port - a 4 byte floating point
number.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
This alarm will be supported with the normal alarm structure as defined
in the "Alert" paper.
In the array of basic parameters, one set of these twelve parameter names are
followed by the number 0. They are the required set and are associated with the
#0 Field Bus connection. If a physical node has a second Field Bus connection,
then a second set of parameters, ending with the number 1, must be supported and
must be associated with Field Bus #1. The counter CYCLE_OVERRUN will NOT be
--```,``-`-`,,`,,`,`,,`---
supported in this second set.
MISCELLANEOUS HIGHER LEVEL SYSTEM VARIABLES:

The Field Bus field devices' data bases have been designed to allow them to
serve as full data owners in a total control system. However, there are probably
certain variables that pertain only to higher level devices that must be stored
in the data owners or in "image" data bases somewhere in the higher level system.
The latter alternative is considered unattractive. Therefore, a Standard Field
Bus tagged object (any physical or logical node or function block) is required to
support a limited number of variables that can be used by a higher level system.
It is assumed, and therefore required, that all of these variables should be
stored in the static data base, be under the revision number of the static data
base, and should be freely writable. The variables are fully defined in the
paper "Array of Basic Parameters"; their names and data types are:
FREE_FLOAT0 - 32 bit floating point number
FREE_FLOAT1 - 32 bit floating point number
FREE_STRING0 - 16 bit binary string
FREE_STRING1 - 16 bit binary string
FREE_LABEL0 - 16 character visible string
FREE_LABEL1 - 16 character visible string
None of the parameters will have the "status bytes" to be defined later.

43
A FIELD DEVICE ON FIELD BUS

Field Bus
Physical Node
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Name Descriptor
Bus Address etc.
Logical Node 0 Logical Node n
Type xx Logical Node Logical Node

Hardware Name, Descriptor Name, Descriptor
etc. etc.
Function Block 0 Function Block 0

**
Type yy * *
Hardware
* Block n
Function * Block n
Function
Hardware Types:
Composition Foreign Memory Serial Communications
Counter Inputs Pulse Outputs Tank Gauging
Discrete Registers Scalar Inputs Voted Scalar Out
Human Interface Scalar Outputs
Figure 12:A Field Device on Fieldbus

--```,``-`-`,,`,,`,`,,`---

--```,``-`-`,,`,,`,`,,`---
44
A COMPLEX FIELD BUS DEVICE
Complex Device Field Bus C
Field Bus B Off-

Field Bus
Field Bus A Agents
Physical Physical Physical

Node Node Node
A B C
Voter
VALVE
Figure 13 A Complex Fieldbus Device

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
45
Data Owner Structure Logical Nodes

Some of the devices that will connect to Field Bus will contain sets of data
that pertain to "primary variables". When those devices need to make that data
available to other Field Bus devices, they will be known as "data owners". A
separate paper ("Data Owner Structure - Hardware") describes the "physical node"
of a data owner. This discussion will build the definition of the rest of the
"User Layer" structure within such devices, particularly the "logical nodes" and
the "function blocks".

PRIMARY STRUCTURE
TO TYPES AND SUBTYPES
SUPPORTED ALGORITHM STRING
LOGICAL NODE TYPES
UNDEFINED
UNSCHEDULED STANDARD
CYCLE/PHASE STANDARD
Logical Node Cycle Time
Blocks Per Logical Node And Per Cycle
Individual Block Cycle Time And Phase
Reconfiguration
CYCLE/PHASE
TIMED STANDARD
Blocks Per Cycle
Memory Available For Blocks
Cycle Time Arrangement
Parameter Interdependency Summary
Block Execution Timing Constraints
Block Timing Rule Exceptions
Off-Logical-Node Communication
Logical Node Discrete Variables
Logical Node Scalar Variables
Summary Illustration
Example
CYCLIC STANDARD
CYCLIC
FAIL-SAFE FUNCTION
Fail-Safe Logical
Isolation_Timer
--```,``-`-`,,`,,`,`,,`---
Deactivate Fail-safe
FAIL-SAFE Parameter
LOGICAL NODE NOWRITE
LOGICAL NODE OPTIONS BIT STRINGS
CYCLE SYNCHRONIZATION
START CYCLE STROBE
Table 1 - Listing of TO Types
Figure 1 - Timed Standard Cycle Structure
PRIMARY STRUCTURE:
Each data owner connected to Field Bus will be a "physical node". The
physical node will contain a data record that contains information pertaining to
the whole physical node. The physical node will have a "tag name" and the data
in its data record will be addressed on Field Bus as "TAG.PARAMETER" where
"parameter" is a 16 bit unsigned integer value. Devices that support the
communication layers of the Field Bus protocol and meet these minimal structural
constraints at the "User Layer" will be called "Interconnectable".

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
46
All data owner devices connected to Field Bus will appear to have one or more
"logical nodes" executing within the 1 physical node. The logical nodes will
appear to be numbered in order, starting with 0. Each logical node within a
physical node will have an assigned "tag name", called "TAG". These TAG names
will be arranged as a single indexed parameter LN_TAG (i) in the physical node's
data base where the index is equal to the logical node number. Each logical node
will contain a data record that contains data associated with the total logical
node. Each logical node will have a parameter in its data base, called LN_NUM,
that will indicate the zero based index of the logical node in the physical node.
Also, each logical node will have a parameter called TAG_DESC in its data base
that will support a 32 character visible string entered by the User.
If there is only 1 logical node in a physical node, then the logical node
data record will be merged with the physical node data record and the two
entities will have a common tag name.
Note further merging.

The logical node will facilitate the execution of one or a set of "function
blocks". Each function block will contain data associated with a "primary
variable". Each function block will also contain, directly or by reference, a
set of rules, called its "algorithm", for executing its procedure.
The function blocks will appear to be numbered in order, starting with 0.

Each function block within a logical node will have an assigned "tag name",
called "TAG". These TAG names will be arranged as a single indexed parameter
FB_TAG (i) in the logical node's data base where the index is equal to the
function block number. Each function block will contain a data record that
contains data associated with the function block. Each function block will have
a parameter in its data base, called LN_NUM that will indicate the index number
of the logical node in which the function block is located. Also, it will have a
parameter called FB_NUM, that will indicate the index number of the function
block in the logical node. Finally, each function block will have a parameter
called TAG_DESC in its data base that will support a 32 character visible string
entered by the User.
If there is only 1 function block permitted in a logical node by its design,

then the logical node data record will be merged with the function block data
record and the two entities will have a common tag name.
Each logical node will have a variable, LN_OOS, that will be TRUE if the
logical node is currently not executing any of its function blocks. Any time
that LN_OOS is TRUE, all function blocks in that logical node will be forced to,
and held in, O/S mode.
All three of the structural elements discussed here will have a tag name,
either unique or shared due to the merging that is defined. Any one or
combination of these structural elements will be referred to as a "tagged object"
or "TO". By definition, a TO has a tag name.
Logical nodes are identified by type; there is one type called "undefined"
that, as its name implies, has no definition. There are two types of function
blocks that are provided, called "Open" and "Interworkable Generic" that provide
no definition or very little definition. Interconnectable devices (see
definition, previous page) that meet these additional structural requirements at
the "User Layer", including the standard identification of their logical nodes at
least as "Undefined" and their function blocks at least as "Open" or
"Interworkable Generic", will be call "Interworkable".
There is another function block type, called "Interoperable Generic", that

has substantial definition of the structure of the data base but no definition of
the block's algorithm. Interworkable devices that meet at least the constraints
of that block for all of their function blocks, and use one of the defined
logical node types, will be called "Interoperable".
A set of function blocks will be defined, usually with extensive detail; they
will be referred to as "standard" blocks. Several of the Standard function
blocks do not have a defined algorithm (for example, the "Physical Property"
SP-50 User Layer Technical Report Block Modes

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~

47
block) but they are always sufficiently defined to enable a complete human and
control system interface. Standard blocks often have a number of manufacturer
options but those options are fully defined.
If a manufacturer chooses to provide a function block with a different

algorithm, but a fully standard data base, then that function block will be
referred to as "Alternate".
If a manufacturer chooses to provide extra or different functionality in a

function block, in such a way that the changes default to the standard (i.e., if
the block operates as "standard" when an unsuspecting user totally ignores any
block parameters or parameter values not included in the standard block
definition), then that field device will be referred to as "Extended Standard" or
"Extended Alternate", as appropriate.
Field Bus devices that meet all of the requirements of "Interoperability" as

defined above and include only "standard" or "extended standard" function blocks
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
implemented in "timed standard" type logical nodes (to be defined below) will be
referred to as "Interchangeable" devices. See the paper "Conformance Classes"
for the full classification system.
TO TYPES AND SUBTYPES:

All three of the structural elements discussed here - physical nodes, logical
nodes, and function blocks - will have a "TO_TYPE", a "TO_MFG_ SUBTYPE", and a
"TO_USER_SUBTYPE". The first two will be 8 bit unsigned integers and the third
will be a 16 bit unsigned integer. The exact values (or acceptable ranges) of
TO_TYPE are given in Table 1.
The intended use of these three values will be given here in terms of a
function block but it applies to all three TO's. The TO_TYPE is the basis for
determining an explicit identifier of the type of function block. If it is a
standard value, it will be an explicit code taken alone. If it is in a
"manufacturer's range" (i.e., has a '*' footnote in Table 1), then it will be
explicit when concatenated with the manufacturers name and model number of the
field device.
It is recognized that several of the ranges of codes available in the

definition of TO_TYPE are relatively small. Therefore, a mechanism is
established to indicate the existence of a second code: TO_TYPE1. As can be seen
by an inspection of the codes in Table 1, the last number in several ranges
provides a notification of the existence of TO_TYPE1. That parameter will be an
8 bit unsigned integer that, if it exists, will be entered into the block's Data
Dictionary (see the paper "Application Support Services Interface") as the
separate Data Dictionary parameter "TO1". When it is used, it will allow
additional extended, alternate, etc. blocks to be uniquely identified. When it
is used, the concatenation of manufacturer's name, model number, TO_TYPE, and
TO_TYPE1 will be an explicit identifier of the block's structure and algorithm.
The "TO_MFG_SUBTYPE" is intended to define the display style that a human

interface (made by another, and possibly unknown, manufacturer) should use. For
standard function blocks, it will be the same as the TO_TYPE. Consider as an
example, however, an "alternate" function block which has a TO_TYPE of A0H (see
Table 1). Since the manufacturer of the field device knows that this function
block happens to be very similar to the Math function block (in fact, it might
simply have a different algorithm) then he would enter 2AH in the MFG_SUBTYPE. A
hand held communicator made by a different manufacturer would inspect the TO_TYPE
and find a number that meant nothing to it. Turning to the MFG_SUBTYPE, it would
find the familiar 2AH and use the Math block display (presumably with a note to
the user to "beware - alternate"). The MFG_SUBTYPE is read-only.
The value that is entered into the TO_MFG_SUBTYPE MUST be a code that has
"public" meaning to an independent manufacturer. Therefore, the following are
the only allowed codes until further standards are available:

--```,``-`-`,,`,,`,`,,`---

48
01H = physical node

10H = null logical node
11H - 18H = the eight defined types of logical nodes
20H = null function block
21H - 40H = defined function blocks
80H = one bit in a Discrete Register function block.
B0H = interoperable generic block
C0H = interworkable generic block
Note that it is required that the TO_MFG_SUBTYPE be one of the codes in the range
of 20H to 40H plus 80H for all extended and alternate blocks. The exact code is
the one that, in the opinion of the manufacturer, would be the closest
approximation to the actual block in terms of display format and content.
The TO_USER_SUBTYPE inserts one step of User control into the process. It may
be used to identify a specific display on a higher level control system that
should be used to display this particular function block. It may be used to
override the MFG_SUBTYPE and thus control the hand held communicators if it was
not needed for the higher level system. With careful design, it may be used for
both purposes.
The TO_USER_SUBTYPE is a 16 bit unsigned integer. It defaults to the same

value as the MFG_SUBTYPE but can be changed by the user. It will be inspected
before the MFG_SUBTYPE by both hand held communicators and higher level systems.
By definition, hand held communicators will ignore the top 8 bits of the value.
If the TO_USER_SUBTYPE has meaning to the display device, it will be used to
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
select the display and the MFG_SUBTYPE will be ignored. Note that hand held
communicators will normally ascribe meaning to the low 8 bits of the value only
if the value is in the list given immediately above.
These three parameters have been set up primarily to serve the human
interface devices but they are useful to higher level devices in a number of
circumstances. Because of this general interest, these three variables are
included in the Data Dictionary (see the paper "Application Support Services
Interface") and will be available to higher level devices without requiring
direct communication on Field Bus. Since the TO_MFG_SUBTYPE can never be set by
the user and it is available in the Data Dictionary parameter LN, it is never a
data base parameter by itself. For the same reason, the TO_TYPE of a standard
physical node is never a data base parameter; it is given in the Data Dictionary
parameter PN.
SUPPORTED ALGORITHM STRING:

The model of the field devices that has been used to design this standard
visualizes that many logical nodes will include a "library" of algorithms. The
user could then configure the algorithm number into the variable "TO_TYPE" for a
function block. As a result of that action, the function block would incorporate
the defined algorithm and initialize its data base to the structure and default
values defined by the algorithm. Such a library is not required.
The data base problem that follows from the library concept is to identify
the exact algorithms that are supported without doing a "random search" during
configuration. Two variables will be defined here to solve that problem.
Each logical node will contain a parameter, called ALGO_STR, that will
indicate the algorithms supported in the algorithm library of the logical node.
There will be 256 bits in this string (32 bytes) - one for each algorithm listed
in Table 1. The bit corresponding to a supported algorithm will be set. If all
of the bits are reset, then the function blocks that exist in the device have
fixed algorithms that can not be changed, even to "Null" [TO_TYPE and TO_TYPE1
(if it exists) are read-only].
If TO_TYPE1 is supported in the Data Dictionary of the logical node in

question, then one or more of the bits corresponding to TO_TYPE 9FH, AFH, BFH,
CFH, or FFH must be set in ALGO_STR. Also, in that case, a second parameter,
--```,``-`-`,,`,,`,`,,`---

49
called ALGO_STR1, will exist and will indicate the algorithms supported in the
"extended" algorithm set. Note that there can be no definition of the algorithm
identified by a particular bit in ALGO_STR1 since they are totally defined by the
manufacturer.
LOGICAL NODE TYPES:

A manufacturer may force a logical node to have a particular type or the
manufacturer may allow the user to select the type from a set of possibilities.
If the type is fixed, the logical node's "TO_TYPE" will have a fixed value in it;
the standard values are given here. If the type is configurable, the initial
value can default to a particular value or it can initialize to the default value
given here.
The allowable TO_TYPEs for logical nodes are:
TO_TYPE 10H - Null

the logical node does not execute and no function blocks
in it can be transitioned from O/S mode.
TO_TYPE 11H - Timed Standard
the block execution is fully defined by the Field Bus
Standard and results in the blocks being executed in
block number order, in strictly serial fashion, with all
blocks executed each scan cycle. The scan cycle is
controlled by the user within bounds set by the
manufacturer.
--```,``-`-`,,`,,`,`,,`---
When standard function blocks are implemented in timed
standard logical nodes, the fully defined timing of the
block execution allows direct application substitution
across manufacturers and is said to provide
"interchangeability".
TO_TYPE 12H - Cyclic Standard
the block execution is similar to Timed Standard but
the dead time within a block and within the logical node
cycle itself is not defined.
This type of logical node can not be considered to be
"Interchangeable" but may be "Interoperable".
TO_TYPE 13H - Cyclic
the block execution is similar to Cycle Standard but the
blocks need ot execute in order within a cycle.
TO_TYPE 14H - Cycle/Phase Standard
the Field Bus Standard defines a method by which the user
defines the base cycle time of the logical node, the
cycle time of each block, and the phase of the execution
of each block, all within limits imposed by the
manufacturer. The exact timing of the blocks within the
cycle is not defined.
TO_TYPE 15H - Cycle/Phase
the block execution is similar to Cycle/Phase Standard
but the blocks need not execute in order within a cycle.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

TO_TYPE 16H - Unscheduled Standard
the blocks appear to never execute. The data in the
blocks are inserted independent of the Field Bus and on a
time basis unknown to the Field Bus.
TO_TYPE 17H - Multicomponent/Multistream Analyzer - a special instance
of TO_TYPE 16H.

50
TO_TYPE 18H - Property Scanner - a special instance of TO_TYPE 16H.

TO_TYPEs 19H through 1BH - Reserved for future standards.
TO_TYPEs 1CH through 1FH - Undefined (available for manufacturers)
the block execution scheme is defined by the manufacture.
The TO_TYPE of logical nodes is assumed to normally be read-only. However,

the logical node options bit string to be defined below will indicate when it can
be written. A write to this value must be directed through the Data Base Write
Service (to be defined in a separate paper). The DBWS will recognize the write
and, if it changes the actual value of the TO_TYPE, the DBWS will set the
requested mode (to be defined in a separate paper) of every function block in the
logical node to Out-of-Service.
UNDEFINED:
The process blocks in a logical node that uses the "undefined" block
execution scheme can be executed in any order as defined by the manufacturer or
as defined by configuration entered by the user following rules defined by the
manufacturer. They will identify their TO_TYPE using any one of types 1CH
through 1FH.
For purposes of characterizing the alert reporting services that may be used
by an undefined logical node, every such node will contain an 8 bit signed
integer called "AX". AX will define the repeat rate of the major alert detecting
services. The value of AX is defined by:
IF the logical node does not support alert reporting, then
x = 2**-127
ELSEIF the logical node has a defined processing cycle that
includes most of the alert detection logic, then
x = that cycle time, in seconds
ELSE
let x = the repeat rate of the major alert detecting services,
in seconds
--```,``-`-`,,`,,`,`,,`---
ENDIF
AX = an integer such that
2**(AX-1) < x <= 2**AX
Refer to the section "Buffer Overload Indicator" in the paper "Alert Function"
for a description of how AX is used.
UNSCHEDULED STANDARD:
The process blocks in a logical node that uses the "unscheduled standard"
block execution scheme will not have a scan time controlled by Field Bus. The
blocks will have data updated in them from time to time by a source unknown to
the Field Bus.
It is assumed that there will be a limit on the total number of function

blocks that can be serviced in the one logical node. That maximum number will be
called "MB". The logical node will include a 16 bit unsigned integer parameter
containing MB as a read-only item in the node's data base. The MB blocks will be
considered to exist in a single dimensioned array where the array extends from
block 0 to block (MB-1).
An unscheduled standard logical node may have provision for configuring

"primary measured variables" into some or all of its function blocks. The
parameter "MV" will be defined as a manufacturer set, read-only, 16 bit unsigned
integer value expressing the number of primary measured variables. By definition,
MV <= MB
Note that MV may be dynamically redefined by the manufacturer.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
51
In the absence of a data base at start-up, a function block will have the
default TO_TYPE of 20H. At any instant in time, the user may have defined
algorithms for some of the blocks in the set of MB blocks but possibly not for
all of them. By definition, the parameter "CB" will be set by the field device
to be equal to the number of function blocks included in the range starting with
block 0 and extending through the last block that has a TO_TYPE other than the
default value. By definition,
0 >= CB <= MB
This type of logical node is based on the concept that there is no defined
node cycle time, at least from the direct perspective of the Field Bus. However,
the alert reporting function has need for a "cycle time" that expresses the time
required to cycle through the majority of the alert detection logic of the
logical node (see the section "Buffer Overload Indicator" in the paper "Alert
Function"). Therefore, an unscheduled logical node will have a data base value,
called AX, that indicates the time necessary for the logical node to cycle
through the majority of its alert detection logic.
When the cycle time is determined by a mechanism unknown to the Field Bus, AX
may reflect the cycle time determined by that mechanism. The value (read only)
of AX is defined by:
let x = the cycle time of the off-field bus mechanism, in seconds
then, AX = an integer such that
2**(AX-1) < x <= 2**AX
This block type is designed for field devices that generate data according to
some independently defined method and make it available to the Field Bus at a
time determined independent of the Field Bus. Two examples of this node type are
so important that they have been given their own logical node types in Table 1: a
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
multicomponent/multistream analyzer and a property scanner.
--```,``-`-`,,`,,`,`,,`---
A multicomponent/multistream analyzer might determine the concentration of
components in a process stream using a complex analysis method such as
chromatography. When the analysis becomes available, the results are placed in
the function blocks where each block represents a component in the stream. The
value MV would then be the maximum number of component values that the device can
produce for this stream (perhaps considering an analyzer program that is defined
in the field bus data base). The value of "x" used to calculate AX would be the
program cycle time being used by the analyzer. The "Composition" function block
will define the logical node parameters for this particular type of logical node.
A property scanner might make physical property or dimensional measurements

across a sheet of steel, cloth, plastic, paper, etc. There might be several
different properties measured at several different physical positions. The
parameters that control the scanner will be a part of the logical node's data
base. The individual measurements will be the Output's of analog input blocks,
one block for each measurement at each position.
These two particular logical nodes will include parameters in their data base
that are specific to their applications. The details for each type of logical
node are given in the separate papers in the "Unscheduled Logical Nodes" section
of this Technical Report.
CYCLE/PHASE STANDARD:
Logical Node Cycle Time:

The process blocks in a logical node that uses the "cycle/phase
standard" block execution scheme will have a scan time for each block
controlled by Field Bus. Each device will be identified by its
manufacturer as having a value MX (manufacturer exponent) equal to the
minimum possible value of CX (current exponent) where:
Base cycle time = 2**CX seconds

52
CX = user set integer where [MX <= CX <= +7]

MX = manufacturer set integer where [MX <= +7]
The following table quantifies the cycle time for each value of CX
but is not intended to define the minimum value of CX:
CX = -10, cycle = 0.98 ms CX = 0, cycle = 1.0 sec.
-9 1.95 1 2.0
-8 3.9 2 4.0
-7 7.8 3 8.0
-6 15.6 4 16.
-5 31.2 5 32.
-4 62.5 6 64.
-3 125. 7 128.
-2 250.
-1 500.
The manufacturer will define the value identified above as MX and

display that value as a read-only item in the logical node's data base.
The user will enter CX as a data item in the same data base.
Blocks Per Logical Node And Per Cycle:

The manufacturer will define the number of blocks that are
supported by the logical node's data base. This value will be labeled
the "maximum blocks" (MB). The logical node will include that value as
a read-only item in the node's data base. The MB blocks will be
considered to exist in a single dimensioned array where the array
extends from block 0 to block (MB-1).
In the absence of a data base at start-up, a function block will have

the default TO_TYPE of 20H. At any instant in time, the user may have
defined algorithms for some of the blocks in the set of MB blocks but
possibly not for all of them. By definition, the parameter "CB" will be
set by the field device to be equal to the number of function blocks
included in the range starting with block 0 and extending through the
last block that has a TO_TYPE other than the default value. By
definition,
--```,``-`-`,,`,,`,`,,`---
0 >= CB <= MB
The program for the logical node will include the ability to define
the number of blocks per cycle that can be supported by the logical node
at the current value of CX. This value will be labeled the "maximum
blocks per cycle" (MBC). The logical node will include that value as a
read-only item in the node's data base.
The value of CX determines the basic cycle time of the logical

node. A set of (MBC) blocks could be selected by the user and the
device would be able to execute all (MBC) blocks at the cycle time CX;
however, the other (MB - MBC) blocks could never be executed.
Individual Block Cycle Time And Phase:

The user will define a value BX in each block that will determine
the cycle time of the block relative to the basic cycle time according
to the following definition:
Block cycle time = 2**(CX + BX) seconds
where:
BX = user set integer where [0 <= BX <= +4]
When BX is non-zero, the phase of the block must be specified. The

variable Phase Number (PN) is defined as:
PN = user set integer where [0 <= PN < 2**BX]

//^:^^#^~^^"~~:~"~

53
If BX is equal to zero, PN has no functional significance. If BX is

equal to one and PN is equal to zero, the block will be executed every
other basic cycle starting with the initial execution. If PN is equal
to one, the block will still be executed every other basic cycle but
starting with the second execution. When BX = four, there are 16 phases
for the execution of the blocks (0 <= PN < 16).
The node block will contain a table of 16 8-bit integer values

under 1 parameter name; this table will be known as the "PHASE_MAP".
The entries will show the actual number of process blocks that are
scheduled in each of the possible phases.
By definition of this logical node type, the blocks that are to be executed
in a given phase, as shown in the phase map, will be executed in strict order
with the lowest number block being executed first, then the next higher number
block. Each block will store its results in the field bus accessible data base
before the next block executes. If a particular block accesses data output by
the block that processes immediately before it in the phase map, that block will
receive the results of the latest execution of the referenced block. Note that
the only blocks that execute in a phase are those defined for that phase by the
phase map. Also, there is no constraint on the execution timing of the function
blocks within the phase other than their order.
The alert reporting function has need for a "cycle time" that
expresses the time required to cycle through the majority of the alert
detection logic of the logical node (see the section "Buffer Overload
Indicator" in the paper "Alert Function"). A cycle/phase logical node
will have a data base value, called AX, that indicates the time
necessary for the logical node to cycle through the majority of its
alert detection logic. AX will be set equal to CX + 4 where the "4" is
the maximum value for BX.
Reconfiguration:
Upon the receipt of a change in the value CX, the node will execute
a complete restart procedure and, in the process, calculate and store in
accessible memory the 16 item table defined above plus, if necessary, a
new value for MBC (this value may be a function of CX). During this
restart, the modes of the process blocks will not be changed unless more
blocks are scheduled for a cycle than is permitted. In this case,
enough blocks will be marked as OS mode as is necessary to reach the MBC
limit. The higher index number blocks in any offending cycle will be
chosen to be changed to O/S. The limit will be checked and the
offending blocks changed to O/S mode during the restart procedure.
This node type is designed for field devices that are of the
"multiplexer" type. Such a device may have a large number of inputs.
The desirable scan time for each block may vary widely and the device
may not be designed to measure all of its inputs at the maximum possible
frequency. Selected inputs, however, could be scanned at the maximum
frequency.
CYCLE/PHASE:
The above description of the "Cycle/Phase Standard" logical node
required that the blocks within one phase be executed in number order. In a
"Cycle/Phase" logical node, that restriction is eliminated.

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
54
TIMED STANDARD:
The process blocks in a logical node that uses the "timed standard" block
execution scheme will all have a constant scan time where that time is fully
controlled by the User within bounds set by the Manufacturer and the Field Bus
Standard. Each device will be identified by its manufacturer as having a value
MX (manufacturer exponent) equal to the minimum possible value of CX (current
exponent) where:
Cycle time = 2**CX seconds
CX = user set integer where [MX <= CX <= +7]
MX = manufacturer set integer where [MX <= +7]
The manufacturer will define the value identified above as MX and display
that value as a read-only item in the node's data base.
The user will enter CX as a data item in the same data base. If CX is not
within the range defined above, the value of CX will be forced into range and a
node configuration fault notification will be set.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
The alert reporting function has need for a "cycle time" that expresses the
time required to cycle through the majority of the alert detection logic of the
logical node (see the section "Buffer Overload Indicator" in the paper "Alert
Function"). A timed standard logical node will have a data base value, called
AX, that indicates the time necessary for the logical node to cycle through the
--```,``-`-`,,`,,`,`,,`---
majority of its alert detection logic. AX will be set equal to CX.
Blocks per cycle:

Upon the receipt of a change in the value CX, the node will execute
a complete restart procedure and, in the process, calculate and display
a value defining the maximum number of blocks that the node can execute
at the speed CX: the maximum number of blocks per cycle (MBC). This
value will also be displayed as a read-only item in the node data base.
The user can respond with a second entry defining the actual number
of blocks to execute in the cycle: current blocks per cycle (CB) where
CB is:
1 <= CB <= MBC
If the value of CB is not within the range allowed, the value of CB

will be forced into range and a node configuration fault notification
will be set. If the value of CB is changed, the node will once again
execute a complete restart and will fix the time cycle to have the user
defined number of blocks. Each of the restart procedures will force all
control process blocks to their Man mode if they are in a lower priority
mode (or Auto if Man is not permitted). Note that I/O blocks do not
change their modes.
Memory Available for Blocks:

The manufacturer will define the number of blocks that are
supported by the logical node's data base. This value will be labeled
the "maximum blocks" (MB). The logical node will include that value as
a read-only item in the node's data base.
Since the number of blocks that a device can execute in one cycle
may well be a function of the cycle time and in any event may be reduced
by the user, there may be memory available for more blocks than are
being processed in the cycle. The device will, by definition, process
blocks starting at the first block (block 0) and stopping at the number
of blocks defined by the user. The remaining block memory will be
available for access by the field bus for data base build or retrieval.
However, the number of blocks/cycle and possibly the cycle time will

55
have to be changed to have the "extra" blocks execute. The mode of all
such blocks will be forced to "Out of Service" by the logical node every
cycle.
The block execution time cycle is totally defined for timed

standard logical nodes. For logical nodes that are being executed
slowly, it may be appropriate to allow the user to actually schedule
more blocks in a cycle than there are memory resources to support. This
will be allowed for timed standard logical nodes. The value of MB may
be smaller than CB. In that case, block 0 will still be executed first
and immediately after the 20% overhead time, block 1 next, etc. through
block (MB-1). Then, for the rest of the (CB - MB) blocks, the block
time will be allocated to the "dummy" block just as it was allocated to
the real blocks.
Cycle Time Arrangement:

As just defined, each "timed standard" logical node will execute a
fixed number of blocks during one cycle of its operation. The cycle
time will be fixed and every block will execute each cycle. The node
will also have other functions to perform such as on-line diagnostics,
discrete I/O, and the cascade initialization defined for some of the
algorithms. Therefore, we will define the cycle as being composed of CB
equal length time slots in which CB blocks are executed and a single
time period of exactly 20% of the cycle time that is devoted to the
other functions which we will refer to as "system overhead". The
processing of the node blocks will appear as if in a single tasking
mode. One block's time slot can not begin until the previous time slot
has finished. If a block contains an algorithm that is of the type
"Null", an algorithm in O/S mode, or if the algorithm requires only a
small fraction of its allowed time, the fixed cycle time will still be
forced. The overhead operation will occur between block (CB-1) and
block 0. Other node tasks may be executed as parallel or interrupt
driven operations. An example of operations included in this latter
category are field bus communications.
There are two totally different reasons why a user may wish to
operate a field bus device at a cycle time slower than MX. First, he
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
may wish to set up a particular field bus device so that it is

interchangeable with another similar but slower device. This must be
accomplished with minimum change in control response at constant tuning
of the devices. Alternately, he may wish to slow down the device so
that the field bus communication load is reduced.
Parameter Interdependency Summary:

Each field bus timed standard node will be able to execute MBC
blocks in the 80% of the time cycle available at any integer value of CX
between and including MX and +7. The value of MBC may be a function of
CX. Given a value of CX, MBC evaluates to an integer. At CX = +7, MBC
>= MB; at CX = MX, MBC >= 1.
Block Execution Timing Constraints:

The time at which certain functions are executed within the block
time is to be fixed. The constraints take two forms: constraints on
the block timing when CX = MX and constraints on the lengthening of the
block time when CX > MX. When CX = MX,
1) the sampling time of the scalar input hardware will be constrained
to be within the first 10% of the block time.
--```,``-`-`,,`,,`,`,,`---
2) the beginning of the slew of the scalar output hardware signal will

56
be constrained to be within the first 25% of the block time.

3) the setting of the pulse output hardware will be constrained to be
within the first 25% of the block time.
4) all of the parameter values that are recalculated as part of the
block execution will be stored into the Field Bus accessible data
base after the 90% point in block time.
When CX > MX, the block time will be longer than when CX = MX. The
extra block time will be inserted into the block execution procedure
after the above three actions occur and after all of the input values
from the data base have been acquired and before any outputs are
released to the data base.
Block Timing Rule Exception:

The cycle time arrangement and the block execution timing
constraints given above are defined based on the assumption that there
is more than one function block in the logical node AND that one or more
of the function blocks have active agents (to be defined in the paper
"Agents"). If that assumption is wrong, the timing of the execution of
the function blocks need not specifically follow the rules as given
above; the above requirements can be simplified.
The above rules define:

- a "block" time for any value of CX (current exponent) and
CB (current blocks per cycle).
- a dead time between the first three actions defined in the
"Block Execution Timing Constraints" section and the
time that the resulting block values are entered into the
data base.
This results in a minimum dead time between the writing of data base
values and the time that the resulting block output values appear in the
--```,``-`-`,,`,,`,`,,`---
data base.
When there is only one function block (CB = 1) in a Timed Standard

Logical Node OR when no function blocks in a Timed Standard Logical Node
support active agents (bit 8 = Reset in the parameter N_TIME_CRIT0 to be
defined on page 24) any block scheduling that retains the above block
dead times is valid.
*********
(Note to first-time reader: most of the rest of this
paper requires an understanding of functions to be defined
in later papers. You might want to skip the rest of this
paper except for "Summary Illustration" (p16) and "Example"
and the Cycle Standard and Cyclic logical node definitions.
*********
Off-Logical-Node Communication:
There are two different mechanisms by which off-logical-node
communications can be configured for Field Bus Standard Blocks. They
are: 1) off-logical-node block input and output word agents and
2) logical node registers.
The input and output word agents are defined by each Standard
algorithm. They all have the same general structure; several types of
these agents can point to off-logical-node data. No distinction is made
between agents that acquire their data from another logical node in the
same physical node and an agent that acquires its data from a logical
node in a different physical node.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
57
When a block is to be processed, the logical node will anticipate

the need for off-logical-node reads and have them accomplished before
the beginning of the node execution time. The reads will be done only
far enough ahead of time that the reads can be accomplished with the
worst case Field Bus conditions and with no retries. At the end of the
block execution, the block algorithm will have placed all off-logical-
node writes in the Application layer communication buffers before the
end of the block execution time.
Several aspects of the off-logical-node block agents deserve

special attention. The discrete writes will be done with a write mask
that is automatically set by the algorithm. The mask will be reset when
the local node receives an "ACK" from the receiving node. If the write
fails, the mask will not be reset; it will be used for the succeeding
write attempt (i.e., the next cycle of block execution) so that the
output values are not lost. However, after enough failures occur to set
the "No-Com" status bit (see page 4 of the paper "Status Byte"), the mask
will be reset. For both discrete and analog blocks, it is assumed that
the write of the Output word arrives at the destination memory location
before the read of the location for the next execution of the block.
This is not necessarily true if the local node is fast relative to the
messaging speed of the bus.
Logical Node Discrete Variables:

An alternate method of handling off-logical-node access can be
optionally provided in any logical node except for the unscheduled
type and must be provided in any logical node that meets all of the
following:
1) MB > 1
2) is a Timed Standard node
3) supports off-logical-node access
4) supports a Standard algorithm (other then discrete I/O
types) that has bit pointers in addition to those for the
Setpoint and the PV Function.
The presence of the alternate method in a logical node will be
indicated in the logical node's options bit string defined below.
The alternate method involves 5 16-bit Output registers,

called LN_VARx, that are a part of the logical node's data base.
(Note: see the immediately next section of this paper for a
qualifier of the "5".) These 5 registers will have their own agents
(see the later paper "Agents"). The values with non-null agents
will be fetched before the execution of the "20%" time and the
values to be written will be passed to the communication service
before the midpoint of the 20% time. The node will generate masks
for each value based on the bits that were written (not necessarily
changed) to the registers by on-node bit agents or Output Words
during the cycle. The off-logical-node read will be done for the
bits that were not written during the previous cycle and the
off-logical-node writes will be done only for the bits that were
written during the previous cycle. The mask will be reset by a
successful write but retained (and added to) during retries; it
will be reset when retries count out and result in a No-Com error.
These registers, by design, offer two advantages over the

on-block input and output words. First, they allow one Field Bus
access to a register that may be used by several blocks within a
logical node. If each block used its own input and output
registers, many more Field Bus accesses would be needed. Second,
they assume that the write of the outputs could not get to the
target registers before the read for the next cycle so they always
do the masked read and retain the bits that were set by the local
blocks during the previous cycle. This results in an available
window of [(0.9 * cycle time) - prefetch time] for the write to get

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
58
to the data base of the receiver. This latter alternative could be

very important in a situation where the local logical node has few
blocks and is operating at a fast cycle time relative to the bus
speed The block agents allow a window of [0.2 * cycle time +
{(CB-1)/CB} * 0.8 * cycle time - prefetch time]. If CB is less
than 8, this is less time than the logical node register allows.
Logical Node Scalar Variables:

There may be applications in which several function blocks in
a logical node input a common scalar value. It would be convenient
to access the scalar value once per logical node cycle using a
logical node variable, then use the value in each function block
without off-node accessing. This function is provided by the
logical node scalar variables.
Two logical node scalar variables can be optionally provided

in any logical node except for the unscheduled type. They must be
provided in any logical node that meets all of the following
conditions:
1) MB > 1
2) supports off-logical-node access
3) supports a standard tank gauging algorithm that measures
the liquid level by using hydrostatic pressure and is
capable of correcting the measurement for the actual
measured atmospheric pressure and temperature.
The agents that will support these variables will simply read the
value and store it in the variable. They will not store the value
back to the remote location at the end of the logical node cycle.
If a logical node supports both scalar and discrete logical

node variables, there will be 2 scalar variables (numbers 0 and 1)
--```,``-`-`,,`,,`,`,,`---
and 3 discrete variables (numbers 2, 3, and 4). The logical node

options bit string will indicate the combination of logical node
variables that are implemented. The paper "Agents" will specify
which "agent types" must be supported.
Summary Illustration:
The attached Figure 1 - "Timed Standard Cycle Structure"
illustrates one cycle of a timed standard node. The horizontal
axis represents time, one cycle time is represented as the
horizontal distance from the beginning of one "20%" to the
beginning of the next "20%".
If the node supports counter inputs, they will be read

simultaneously after the beginning of the cycle and before the
beginning of Block 0 and their incremental counts will be stored
such that they are available to the function blocks. If the node
supports discrete inputs, their values will be captured after the
beginning of the cycle and before the beginning of Block 0. If the
node supports discrete outputs, they can be physically output any
time between the beginning of the execution of the discrete output
block and the beginning of the execution of block 0 on the next
logical node cycle.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
If the node supports node variables, they will be read before

the start of the node cycle time but only far enough ahead that the
Field Bus communication services have time to complete the
communications under worst case conditions with no retries. The
communication supporting the writing of the node discrete variables
will be set up and passed to the field bus communication service
before the end of the first 10% of the node cycle time.

59
The time slot devoted to a block (Block 1 is shown as the

example in the figure) will be defined as follows:
1) The off-logical-node fetching of inputs needed for a
particular block can occur before the start of that block's
time slot but only far enough ahead that the Field Bus
communication service has time to complete the
communications under worst case conditions with no retries.
2) The on-node fetching of inputs needed for a particular
block can not occur until after the start of that block's
time slot.
3) If a block has a scalar hardware input agent, the input
sampling time shall occur within the first 10% of the
block's time slot (when CX = MX, shorter as CX increases).
4) If a block has a scalar output hardware agent, the scalar
output value must be set into the hardware so that the
actual slew of the output signal can begin within the first
25% of the block's time slot (when CX = MX, shorter as CX
increases).
5) If a block has a pulsed output hardware agent, the
controlling signal for the output pulse generation must be
set into the hardware so that the pulse signal can be
generated on the new basis within the first 25% of the
block's time slot (when CX = MX, shorter as CX increases).
6) The digital calculation of the block outputs based on the
block's inputs will occur between the beginning and the end
of the block's time slot.
7) The insertion of adjustable delay time to slow down block
execution will be after steps 1 - 5 above and before any
output storing.
8) The storing of the block's output on-node will be complete
before the end of the block's time slot.
9) If a block has a discrete output hardware agent, the
outputs must be driven (if relays, then power to the first
coil) before the beginning of the next execution of block 0.
10) The communication of the block's outputs off-logical-node
will be set up and passed to the field bus communication
service before the end of the block's time slot.
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
60
TIMED STANDARD CYCLE STRUCTURE
Block 20% Block Block Block 20%

n-1 of 0 1 n-1 of
Cycle Cycle
time Time
--```,``-`-`,,`,,`,`,,`---
Overhead and Communications
SI In SO orPD Out
On-Node Fetch* On-Node Store
Block Off-Node Store in Comm. Buf.

1 Off-Node Fetch* Cycle Time Pad
DO Out DO Out
Logical Node Reg. Fetch

Node
Node Reg. Store in Com. Buf.
CI & CI &
Physical DI In DI In
Node Time (sec.)
0 Notes: * = Inputs and Outputs 2CX
Figure 14: Data Owner Structure, Figure 1, Timed Standard Cycle Structure

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
61
Example:
As an example of a simple field bus device, assume that MX = 0
(1 second cycle time is the fastest the device will operate).
Further assume that CB = 2 (the device will execute 2 blocks per
cycle). Then, if the user chooses to set CX = MX the time cycle
could be represented as:
Each cycle = 1 sec.
Each Block = 0.8 * cycle time / # of blocks = 0.4 sec.
--```,``-`-`,,`,,`,`,,`---
0.2 sec. - On-line diagnostics and prefetch Block 0
0.4 sec. - Do Block 0 and prefetch Block 1
0.4 sec. - Do Block 1
0.4 sec. - Do Block 0 and prefetch Block 1
.
.
Now assume that the user changes the device's data base so
that CX = 1. As a result, the time allocated to execute each of
the base blocks will double. The new cycle can be represented as
follows:
Each cycle = 2 sec.
Each Block = 0.8 * 2 sec. / 2 = 0.8 sec.
0.8 sec. - Do Block 0, with an embedded 0.4 sec. time delay,
and prefetch Block 1
0.8 sec. - Do Block 1 with an embedded 0.4 sec. time delay
0.8 sec. - Do Block 0, with an embedded 0.4 sec. time delay,
and prefetch Block 1.
.
.
Finally, assume that the user also changes the device's data
base so that the number of blocks/cycle (CB) = 1 with the cycle
time still at CX=1. As a result, twice as much time will be
allocated for the execution of the only scheduled block,
represented as follows:
Each cycle = 2 sec.
Each block = 0.8 * 2 sec. / 1 = 1.6 sec.
.
.
In these three cases, the device, originally manufactured to

run at a cycle time no faster than one-second, is operated at an
effective cycle time of first one second, then 2 seconds, then 2
seconds. In case two, the control will be degraded from what would
have been obtained if the device had been run at one second.
However, the data base for the operation in case two can be
transferred to another device that was manufactured to operate at a
cycle time no faster than two seconds (MX = 1) and the control will
be identical. Finally, in case three, the field bus has been
unloaded by another factor of two by reducing the number of tags
being executed per cycle. Note that, in case 3, there is at least
1 tag data base beyond the one executing that is available to be
configured but it can not be run unless the cycle constants are
changed.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
62
CYCLE STANDARD:
The above definition of the Timed Standard logical node required that certain
dead times be maintained in the block execution timing in order to achieve
"Interchangeability". These dead times degrade control performance The "Cycle
Standard" type of logical node is defined exactly the same as "Timed Standard"
except that there are no requirements placed on block dead times and there is no
requirement for the fixed (20%) logical node time. The blocks must still be
executed in order and any parameters passed from block "n" to block "n+1" must
represent the results of the current cyclic execution of block "n". A device
that includes a "Cycle Standard" logical node can not be expected to be
--```,``-`-`,,`,,`,`,,`---
CYCLIC:
The above definition of a "Cycle Standard" logical node required that the
function blocks execute in order and updated parameters must be passed from block
"n" to block "n+1". In certain applications, this may not be needed. The
"Cyclic" logical node has no constrains on block execution timing. It only
requires that all blocks that are currently being executed (the first CB blocks)
must execute once per cycle time. A device that includes a "Cyclic" logical node
can not be expected to be "Interchangeable" but may be "Interoperable". In
addition, unpredictable dead times may result when a block is configured to use
the results of other blocks in the same logical node.
FAIL-SAFE FUNCTION:
Fail-Safe Logical:
A logical value called "Fail-safe" may optionally be provided in

each logical node. The value will be initialized reset. It will be
designed to be set from Field Bus or from a block agent in a block that
has a discrete Output. The value can optionally be designed to be set
from a physical hardware input. If the physical hardware input is
implemented, the value will be initialized as defined in the paper
"Field Device Start and Restart". If not, it will be initialized to
reset.
When the logical value transitions to set, any and all blocks in
the logical node that support the "Fail-safe" functionality will assume
their fail-safe condition within one logical node cycle time. The
fail-safe condition will exist until the logical node receives a proper
signal to reset the Fail-safe logical.
A Field Bus write to reset the actual value of Fail-safe will not
be allowed. Fail-safe can only be reset by setting a second associated
logical value. Even resetting Fail-safe properly may not clear the
fail-safe conditions from the blocks: the algorithm and its
configuration for each function block will determine how the block
responds to fail-safe. However, the blocks will typically respond in
the same way as they respond after recovering from a single block
failure. In general, the block will 1) go into Man or Auto mode or 2)
pass the failure state up the cascade to a higher block (typically a PID
or Device Control Block) that will go into Man mode. In case (2), the
local block will resume its former mode.
A manufacturer can optionally include discrete hardware inputs in

the physical node structure that are specifically designated as

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
63
"Fail-safe Discrete"'s. Such a discrete input can serve all logical

nodes in the physical node or the manufacturer can provide a separate
input for each logical node. These discretes, if provided, will be
arranged on the physical node in such a way that they are distinct from
the discrete register inputs. They will be labeled with an indication
that they serve the whole physical node or the logical nodes that they
do serve (identified by the logical node number starting with 0).
When discrete Fail-safe inputs are provided, an "Open" input will

cause a reset Fail-safe logical to RISE. The "Closing" of this input
will NOT cause the Fail-safe logical to reset.
Isolation_Timer:
A manufacturer can optionally include an "Isolation Timer" (IT)

that compliments the Fail-safe trigger. In general, the IT is started
when any cascade structure in the logical node "counts out" (as defined
in later papers) and is reset by any write to the logical node. If the
time expires before being reset, the Fail-safe logical is set. This is
a very simple mechanism that has been set up to allow a Field Bus
function block in a cascade structure to wait a relatively long time
after communication has been lost before it changes its own output to
its Fail-safe value.
If the IT is implemented, it will be implemented in the following

fashion. There will be a 16-bit integer value in the logical node's
dynamic data base that will serve as a timer location. This value will
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
be available for reads and writes from Field Bus. The value will
indicate time in centiseconds and will be decremented by the logical
node once per cycle any time that it contains a value other than zero.
The value will not be decremented "through" zero.
There will be a second integer value in the logical node's static

data base called the ISOLATE_TIME. This value will be available for
reads and writes from Field Bus. The ISOLATE_TIME will normally be
moved into the IT to start the timer. Note that, if ISOLATE_TIME = 0,
it will not impact the operation of the logical node because the action
is triggered by the transition to zero, not a value of zero.
When the IT value is transitioned to zero by the decrementing from

the logical node, the Fail-safe discrete will be set. The Fail-safe
discrete will NOT be set if a non-zero value is changed to a zero value
by a write command.
If the logical node restarts with a good static data base but
having lost its dynamic data base, it will reset the IT value to zero.
It will NOT set the Fail-safe logical at that time.
See the "Mode" paper, p15, for the basis for starting the IT based
on CASCADE count-out. See Attachment 2 to the "Data Base Write
Service" paper (p1 and Figure 1) for the basis for resetting the time
to zero when there is a write to the logical node. See the paper
"Function Block Structure", Table 1 for the logic for resetting IT for
writes that do not go through the Data Base Write Service. In addition,
specific algorithms may, under conditions defined within the algorithm,
set the IT.
Deactivate Fail-safe:
Since Fail-safe is driven directly by hardware inputs or can be

driven by configured logic blocks that the operator does not understand,
it is necessary that the Fail-safe operation be able to be inactivated.
However, the disconnection of a Fail-safe function is inherently a risky

--```,``-`-`,,`,,`,`,,`---

64
situation. Therefore, the act of disabling Fail-safe is tied to a

special logical node alarm. When Fail-safe is inactive, the logical
node will repeatedly issue an alarm so indicating. The user can
configure the repeat rate of the alarm in the logical node parameter
FS_REPEAT.
--```,``-`-`,,`,,`,`,,`---
The Fail-safe function is deactivated by setting the parameter

FS_KILL (data type discrete) in the logical node's static data base.
When that discrete is set, the logical node will issue an alarm every
FS_REPEAT minutes.
The parameter FS_REPEAT will be an 8 bit integer stored in the

static data base. It will set the alarm repeat rate in minutes.
However, if it is set to 00H minutes, the alarm function will be turned
off. The accuracy of the repeat rate is not defined nor implied by this
standard.
It is expected that the designers of human interfaces that serve

Field Bus devices will consider requiring a level of access above that
of "operator" in order to change FS_REPEAT or to set the FS_KILL
parameter. It is expected that FS_KILL could be reset at any access
level.
FAIL-SAFE Parameter:
The Fail-Safe logical will be bit 0 of an 8-bit binary string that

combines several indicators of the functionality of the fail-safe
system. The name of the 8-bit parameter will be "FAIL-SAFE" and it will
be required in all logical nodes. This parameter will be in the static
data base (under a "check-sum" type validity check if one exists, but it
will NOT be under the "static data base revision number" - see the paper
"Array of Basic Parameters"). The meaning of the individual bits in
the parameter FAIL-SAFE are:
Bit 0 - Fail-safe value itself
+ reset every cycle if not functional.
+ can be written to from field bus but only to set the
value, never to reset it.
1 - Force reset of Fail-safe
+ when set, and Fail-safe is set, the logical node will
reset both bits.
+ does nothing if Fail-safe is not functional.
+ can be written to from field bus but only to set the
value, never to reset it.
+ reset every cycle by the logical node if Fail-safe is
not functional.
+ reset every cycle by the logical node if Fail-safe is
reset.
2 - Set by the node if the Fail-safe hardware input is deactivated
(i.e., if FS_KILL is set).
3 - Set if Fail-safe was triggered by a hardware input. Reset
when Fail-safe is reset.
4 - Set if Fail-safe was triggered by the isolation timer. Reset
when Fail-safe is reset.
5&6 - Fail-safe design code:
+ 0 = Fail-safe not implemented.
+ 1 = Fail-safe implemented but no hardware inputs.
+ 2 = Fail-safe implemented and connected to a hardware
input - 1 per physical node.
+ 3 = Fail-safe implemented and connected to a hardware
input - 1 per logical node.
7 - Set if IT is implemented.
One and only 1 of bits 0 or 1 can be written in any one Field Bus write
message. Therefore, a write to FAIL-SAFE must always be a masked write.
In addition, those bits can only be set, never reset. The rest of this
byte is read-only.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
65
The total definition of the Fail-safe related values are:

1) FAIL-SAFE - 8-bit binary string (dynamic data base) (required).
--```,``-`-`,,`,,`,`,,`---
2) FS_KILL (data type discrete) (static data base) (required if

either of bits 5 & 6 of FAIL-SAFE are set).
3) FS_REPEAT - 8-bit integer (static data base) (required if
either of bits 5 & 6 of FAIL-SAFE are set).
4) IT - 16-bit integer for time (centiseconds) (dynamic data base)
(required if bit 7 in FAIL-SAFE is set).
5) ISOLATE_TIME - 16-bit integer for time (centiseconds) (static
data base) (required if bit 7 in FAIL-SAFE is set).
Note: there is a similar value, called SFAIL-SAFE, that is defined
in the Start-Restart paper. It's operation complements the
operation of Fail-safe.
LOGICAL NODE NOWRITE:

It is anticipated that some Field Bus devices will be used in applications in
which write access to the entire logical node must be strictly controlled. For
example, access to the mode and configuration of a custody transfer meter might
need to be controlled during a transfer. A parameter will be provided in all
standard logical nodes to support this function.
The function will typically be operated as follows:

- At or before the beginning of a time period during which the NOWRITE
function is to be active, an automatic procedure will define the
permissible level of access to the function itself. It will also
reset a "tattle" bit.
- At the start of the restricted time period, any device, including a
human I/F, will set the primary NOWRITE bit.
- If the primary NOWRITE bit is set, write access to most of the data
base in the entire logical node is blocked by the field device.
- The tattle bit will be set by the field device if any device resets
the primary NOWRITE bit.
- At the end of the time period, the automatic procedure will inspect
the tattle bit, then reset the primary NOWRITE bit.
- If the tattle bit was set, it is known that the logical node data base
may have been violated during the time period.
To implement this procedure, there will be an 8 bit binary string, called

"NOWRITE", that will always be present in a logical node. The parameter will be
stored in the static memory area. The 8 bits will have the following meaning:
Bit 0 - set if there can be no write access to the entire logical node.
If this bit is set, the Field Device itself will prevent Field
Bus writes through the Data Base Write Service (see the later
paper by that name) to all parameters in the entire logical
node except for writes to "NOWRITE" itself, any writeable
agent (see "Agents" paper), any CASCADE transfer location
(see "Standard Block Functions" paper), and any alarm
acknowledge words.
This bit is reset during a node restart if any of the static
data base was lost (so that it can be downloaded quickly).
Bit 1 - set if portable access to bit 0 is prevented.
Any Human I/F that is conformant to the Field Bus standard and
is designed to be portable will prevent access to bit 0 if bit
1 is set. For purposes of this statement, "portable" will
mean a device that is designed to be lifted and carried by the
normal user but will not refer to a device that is moved by
sliding or rolling a table-like device. Also, "portable" will
include any Human I/F that is powered by drawing power from
the Field Bus itself, or by internal batteries, or by a
portable battery pack.
Bit 2 - set if operator access to bit 0 is prevented.
Any Human I/F that is conformant to the Field Bus standard and

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
66
which provides levels of access control will prevent bit 0

from being reset when bit 2 is set unless its access level is
"higher" than operator level.
Bit 3 - set if Human I/F access to bit 0 is prevented.
Any human I/F that is conformant to the Field Bus standard
will prevent access to bit 0 if bit 3 is set.
Bit 4 - Free
Bit 5 - set if Human I/F's at the operator access level must prevent the
resetting of bit 7.
Bit 6 - set if Human I/F's at the operator level must prevent all
(i.e., set, reset, and read) access to bit 7.
Bit 7 - the NOWRITE "tattle" bit.
This bit is set by the Field Device any time bit 0 is reset.
This bit is NEVER reset by the Field Device except as the

result of a Field Bus message or an output from a function
block.
This bit is set by the Field Device when the Field Device is
initialized. During a node restart, this bit will be left in
its prior state if:
+ all input blocks in the logical node retained their
static data
+ all other blocks in the logical node retained their
dynamic data
+ the physical node hot restart timer did not expire
Otherwise, it will be set by the Field Device.
(see the paper "Field Device Start and Restart" for details).
Special Restriction - a Field Device that is conformant to the Field Bus
Standard will:
- require that all writes to the parameter be "masked"
writes (see the "Application Layer Services" paper).
- never allow bit 7 to be written if any other bit is
written (i.e., if any of bits 0-6 in the write mask are
set and bit 7 in the mask is also set, the write will
be rejected.
- set bit 7 any time bit 0 is reset by a Field Bus write.
- set bit 7 when the Field Device is initialized.
It will manipulate bit 7 during restart as defined in
the paper "Field Device Start and Restart".
- never reset bit 7 except as the result of a Field Bus
message or an output from a function block.
Human I/F Restriction - a Human I/F Device that is conformant to the
Field Bus Standard:
- will obey bits 1-3, 5, and 6.
- will never allow bit 3 to be reset.
- and is "portable" as defined above will:
+ not allow resetting of bits 1-4.
+ not display nor allow writing of bits 5-7.
LOGICAL NODE OPTIONS BIT STRINGS:

Every TO in Field Bus has one to three "time critical" options bit strings.
Standard logical nodes will include the following 16 bit time critical options
bit string as TIME_CRIT0:
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Bit 0 = set if this logical node supports a read handler (see paper
"Application Support Services Interface").
Bit 1 = set if this logical node supports logical node variables 0
and 1 as analog (must be reset if logical node = unscheduled).
Bit 2 = set if this logical node supports logical node variables 0
and 1 as discretes (must be reset if logical node =
unscheduled).
Bit 3 = set if this logical node supports logical node variables

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
67
2-4 (discretes) (must be reset if logical node = unscheduled).

Bit 4 = set if this logical node supports FAIL-SAFE.
Bit 5 = set if this logical node supports an "isolation timer"
Bit 6 = set if this logical node supports a private clock (see "Data
Owner Structure - Hardware" paper for a description of this
option).
Bits 7 - CH = reserved for future Standards.
Bits DH & EH = manufacturer specific.
Bit FH = set if this physical node supports any extended parameters. If
this bit is set, parameter EXL0 must exist in the Data
Dictionary. See Attachment 2 to the paper "Application
Support Services Interface".
Every logical node in Field Bus has one to three "non-time critical" options
bit strings. Standard logical nodes will include the following 16 bit non-time
critical options bit string as N_TIME_CRIT0:
Bit 0 = set if this logical node can operate as a manufacturer defined
type of LN.
Bit 1 = set if this logical node can operate as a Timed Standard LN
Bit 2 = set if this logical node can operate as a Cyclic Standard LN
Bit 3 = set if this logical node can operate as a Cyclic LN
Bit 4 = set if this logical node can operate as a Cycle/Phase Std. LN
Bit 5 = set if this logical node can operate as a Cycle/Phase LN
Bit 6 = set if this logical node can operate as an Unscheduled LN
Bit 7 = set if this logical node can operate as a Multicomponent/
Multistream Analyzer LN.
Bit 8 = set if this logical node can operate as a Property Scanner LN
Note: if more than one of bits 0 - 8 is set, then the user can
configure the TO_TYPE accordingly. If only one of those bits
is set, the TO_TYPE will be read-only. It is illegal to have
no bits set.
Bit 9 = set if this logical node supports active agents (see paper
"Agents").
Bit AH = set if this logical node supports off-physical node agents
(see paper "Agents").
Bit BH = set if this logical node supports off-Field Bus agents (see
paper "Agents").
Bit CH = set if this logical node supports hardware input to the
fail-safe logical value.
Bit DH = set if this logical node does "Fast Initialization". See
Attachment 2 to the paper "Function Block Structure" for this
procedure.
Bit EH = set if all function blocks in this logical node that support
triggered calibration also enter the data record into the
clipboard.
Bit FH = set if all function blocks in this logical node support all of
the configuration and error checking shown in the pseudocode
for their block types.
Consult the paper "Array of Basic Parameters" for the parameter number of this
string.
Logical nodes that are extended or alternate to the Standard logical nodes
may use one of the four additional option bit string names that have been defined
in the "Array of Basic Parameters": TIME_CRIT1 and 2 and N_TIME_CRIT1 and 2.
Their string length is not defined.
All standard logical nodes will provide for two additional parameters in
their data bases that allow higher level systems to confirm that a logical node
supports the necessary options required for the service it is in. The two
parameters are:
MIN_TC0 - a 16 bit string parameter that gives the "minimum"

acceptable value for the previously defined TIME_CRIT0.


--```,``-`-`,,`,,`,`,,`---

68
to the current value of TIME_CRIT0.
MIN_NTC0 - a 16 bit string parameter that gives the "minimum"

acceptable value for the previously defined
N_TIME_CRIT0.

to the current value of N_TIME_CRIT0.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
The Field device will maintain these parameters in its static data base and
allow free R/W access. Otherwise, it will not use not change these values.
A higher level device may download a different value as part of a data base
restore operation or it may simply change either value at any time.
The intent is that the higher level system can confirm that a field device
supports the options that are needed for a particular service. It would do that
by comparing TIME_CRIT0 and N_TIME_CRIT0 (the options that are actually present)
with MIN_TC0 and MIN_NTC0 (the options that are needed). If any bits are set in
MIN_TC0 or MIN_NTC0 and the corresponding bit is reset in TIME_CRIT0 or
N_TIME_CRIT0, then the higher level system would report that situation.
CYCLE SYNCHRONIZATION:
Each logical node is basically assumed to be operating asynchronously
relative to any other logical node on the Field Bus. However, at times it would
be desirable to adjust the execution times of one or more logical nodes to
minimize the dead time in a control scheme that spans multiple logical nodes.
This section will define a simple (required) method of achieving that
synchronization under certain limited conditions.
--```,``-`-`,,`,,`,`,,`---
The scheme will allow a logical node to adjust the beginning of its execution
cycle to minimize the dead time between the scheduled reading (or writing) of an
I/O word or a transfer location in a selected function block in that logical node
and the generation (or use) of that value by the block.
There will be three data base items to support the synchronization scheme:
SYNC_POINT = static data base, indirectly writeable at any time.
= 16 bit bitstring containing two integers.
Bits 3-0 indicate which parameter to monitor:
0 = INPUT0 4 = INPUT4 8 = ROut TL CH = OUTPUT3
1 = INPUT1 5 = INPUT5 9 = OUTPUT0 DH = OUTPUT4
2 = INPUT2 6 = Cas TL AH = OUTPUT1 EH = OUTPUT5
3 = INPUT3 7 = RCas TL BH = OUTPUT2 FH = none
Bits 16-4 indicate the number of the function block in
the logical node to monitor (a value between 0 and FFFH).
The default value of SYNC_POINT =

0 in bits 16-4
IF the physical node in which the logical node exists
supports inputs and the logical node allows
function blocks that support any of those types
of input hardware, then
bits 3-0 = 9H
ELSE bits 3-0 = 6H.
SYNC_TOL = static data base, indirectly writeable at any time.
= 16 bit integer that defines the synchronization tolerance
in milliseconds. The default value of SYNC_TOL will be
set by the manufacturer.
RESYNC_COUNT = read-only parameter in physical node data base.
= one value covering all logical nodes in the physical
node.
= count of logical node resynchronizations since the
communication counters for Field Bus 0 were reset

69
(see the paper Data Owner Structure - Hardware, page 23

for a description of how the counters work).
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Each logical node will appear to implement the following logic (independent
of any other logical nodes in the same physical node):
IF the low three bits of SYNC_POINT = FH, then

BREAK
IF any function block in the logical node has an active agent, then
IF any of the active agents is off logical node, then
IF any of the active agents is an [(on physical node) OR (on Field
Bus agent)], then
BREAK
ELSE
IF the indicated parameter is an I/O word and has a null agent, then
BREAK
IF the indicated parameter is an I/O word and has an active agent,
then
BREAK
IF the indicated parameter is an I/O word and has a physical
hardware agent, then
BREAK
IF SYNC_POINT < 9, then
IF the indicated function block was in a mode with a higher
--```,``-`-`,,`,,`,`,,`---
priority than Cas any time during the cycle, then
BREAK
IF there was not exactly 1 direct write to the parameter since
the last cycle, then
BREAK
TEMP = (time at which the value was written into parameter) - (time
at which the value was accessed by this block) in
milliseconds.
'Note: "the time at which the value was written" will
' be taken to be the time at which the function
' block's memory was made available to Field Bus
' access after the write, not the instant of
' writing the value itself.
IF TEMP > SYNC_TOL, then
Delay the start of the next logical node cycle by (TEMP -
SYNC_TOL) time.
'Note: in a timed standard logical node, the delay of
' the next cycle must occur after the last
' function block that is executed in one logical
' node cycle and before the beginning of the first
' function block that is executedd in the cycle
' after the delay.
ELSEIF SYNC_POINT > 8, then
IF the indicated function block was in a mode with a higher
priority than Auto any time during the cycle, then
BREAK
IF there was not exactly 1 cyclic read of the parameter since the
last cycle, then
BREAK
TEMP = (time at which the value in the parameter is cyclically
read) - (time at which the value was written by this block)
'Note: "the time at which the value was written" will
' be taken to be the time at which the function
' block's memory was made available to Field Bus
' access after the write, not the instant of
' writing the value itself.
IF TEMP > SYNC_TOL, then
Delay the start of the next logical node cycle by (TEMP -
SYNC_TOL) time.
'Note: in a timed standard logical node, the delay of
' the next cycle must occur after the last
' function block that is executed in one logical
' node cycle and before the beginning of the first

70
' function block that is executedd in the cycle

' after the delay.
ENDIF
ENDIF
END
START CYCLE STROBE:

This paper and the paper defining the physical nodes have stated requirements
for the Standard Field Bus devices in terms of timing relative to the start of a
logical node's cycle. In order to test the devices for conformance to the
standard, it will be necessary for the testing personnel to have access to
electrical signal's that are strobed by the start of the cycle time for each
logical node. The signals must be suitable for strobing a triggered
oscilloscope.
Since the signals are to be used only during conformance testing, access to
them may require the disassembly of the device's enclosure. The exact circuit
interface must be defined by the manufacturer for conformance testing. The
signal for each logical node will be independent and will have two states. One
state will exist continuously during the 20% of logical node overhead; the other
state will exist continuously all during the time that the function blocks are
executing.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

--```,``-`-`,,`,,`,`,,`---

71
Table 1 LISTING OF TO_TYPES

The 256 numbers in the TO_TYPE are defined as follows:
00 = null physical node
01 = standard physical node
02 - 07 = physical node values reserved for future standards
08 - 0FH = physical node values available for manufacturers *
10 - 1FH = Logical Nodes
10H = null 15H = cycle/phase
11H = timed standard 16H = unscheduled
12H = cyclic standard 17H = multicomponent /
13H = cyclic multistream analyzer
14H = cycle/phase standard 18H = property scanner
19H - 1CH = logical node values reserved for future standards
1DH - 1FH = logical node values available for manufacturers*
20H -FH = Standard Function blocks:
20H = null function block.
21H = Analog Input 31H = Splitter
22H = Analog Output 32H = Tank Gauging
23H = Composition 33H = Timer
24H = Counter 34H = Totalizer
25H = Dynamic Compensation 35H = Tuner
26H = Interface - 16 bit int. 36H = Device Control
27H = Interface - 32 bit int. 37H = Discrete Input
28H = Interface - 32 bit float 38H = Discrete Output
29H = Interface - 64 bit float 39H = Discrete Register I/O
2AH = Math 3AH = Discrete Register Output
2BH = On/Off 3BH = Human Interface
2CH = PID 3CH = Logic
2DH = Property Conversion 3DH = Program Control
2EH = Pulse Width Modulated 3EH = Register I/F
2FH = Signal Capture 3FH = Serial Commmunication
30H = Signal Selector 40H = Batch Collector
41H through 7FH = reserved for future standard function blocks.
--```,``-`-`,,`,,`,`,,`---
80H = one bit in a Discrete Register function block.

81H through 9EH = reserved for tag names within function blocks.
90H through 9EH = extended versions of TO_TYPEs 21H through 8FH. *
9FH = indicator to refer to TO_TYPE1 for extended block detail codes
A0H through AEH = alternate versions of TO_TYPEs 21H through 8FH. *
AFH = indicator to refer to TO_TYPE1 for alternate block detail code.
B0H through BEH = interoperable generic function (IoGFB). *.
BFH = indicator to refer to TO_TYPE1 for IoGFB detail code.
C0H through CEH = interworkable generic function block (IwGFB). *
CFH = indicator to refer to TO_TYPE1 for IwGFB detail code.
D0H through EFH = reserved for future defined function blocks.
F0H tthrouth FEH = open functioin block. *
FFH = indicator to refer to TO_TYPE1 for open block detail code.
Notes: * Each manufacturer will ensure that his manufacturer's name,

Concatenated with the field device's model number plus this
Value will uniquely identify a particular TO type.
TO = Tagged Object. (ed)

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
72
Block Modes
Standard Field Bus devices will support a mode service for each function
block within a logical node. The mode service uses 6 bytes of parameter storage
per block. The following is a description of those 6 bytes, their assigned
meaning, and their interaction.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
HyperReader Note: click on the words "Mode" or "Block" in the

above paragraph, just for kicks.
All references to "block" for the remainder of this description will refer to
function blocks, not physical or logical nodes. The physical and logical nodes
do not have a "mode".
It is intended that the individual status bits that are defined for the 6
bytes be arranged in their bit strings exactly as described. The bit strings can
be considered an enumeration if desired. Alternately, they can be considered bit
strings and the individual bits can be manipulated. Certain Field Bus algorithms
can do such manipulation.

MODE BYTE
REQUESTED MODE BYTE
MODE INTERPRETATION
MODE PERMITTED BYTE
ATTRIBUTE/ACCESS BYTE
Attributes (Bits 0-2)
Operator Access (Bits 3-5)
ACQUIROR Summary (Bits 6&7)
Explanation of Figure 1
TATTLE BYTE
FREE MODE BYTE
GENERATION OF THE ACTUAL MODE
SUMMARY RULES
Figure 1 - Attribute/Access Limits
MODE BYTE:
The operational mode of a SP-50 block will be reported by the states of 8
bits arranged in 1 byte. The bits are defined below in priority order (highest
priority and most significant bit position first). The highest priority bit set
is the operative mode but lower priority bits will frequently be reported to
indicate the basis for restoring modes, for the higher level nodes to interact
properly, and for the operator interface.
Out of Service - Block not operationally functional. All blocks on field

(O/S) bus must allow O/S. If the block was in service, the
block simply does not execute any further output
operations. The exact state of the physical output
directly controlled by a block after its mode is changed
from operational to O/S is defined by the block
algorithm. Certain simple data base status enforcement
may be done in O/S mode. This is the only mode in which
certain selected configuration data can be changed.
Initialization - The output of this block is being adjusted by a lower

Manual block in initialization. The details of the action
(IMan) within a block in this mode will be defined by each
algorithm.

--```,``-`-`,,`,,`,`,,`---

73
Local Override - Applies to blocks that drive physical outputs and to

(LO) blocks whose algorithms specifically define the LO mode.
For output blocks, the ultimate output is locked in the

last position and most writes to the block are inhibited
by the data base write service in the field device. The
Local Override mode state in output blocks can only be
cleared:
1) if the field device is equipped with a local method
of output locking, that lock is cleared.
If such a lock is not provided, then
2) if a human interface device on the field bus
supports an access priority level higher than the
operator's, then LO can only be cleared from the
human interface when the higher priority level is
in effect.
If neither of the above is provided, then
3) the user's operation practices dictate when the
operator can clear the LO mode.
Manual - Neither the input-to-output transfer function of the

(Man) block nor the ROut transfer location {defined below} is
controlling the output.
Automatic - The output of this block is under the control of the

(Auto) defined algorithm or of the by-pass function if the
algorithm provides for by-pass. The Set Point is not
being changed by any configured structure.
Cascade - The output of this block is under the control of the

(Cas) defined algorithm or of the by-pass function if the
algorithm provides for by-pass; the Set Point is being
obtained from another block using a data base agent or it
is being pushed by a field bus block that is the next
higher block in a cascade structure. There may be an
associated no-communication count-out function that
causes the value to be marked as having a "No-Com"
status (see page 21 of the paper "Agents").
Remote - The output of this block is under the control of the

Cascade defined algorithm or of the by-pass function if the
(RCas) algorithm provides for by-pass; the Set Point is being
pushed to this block by a higher level device in a
cascade structure. This mode will enable a count-out
gate and will normally shed to Cas with the RCas bit
still set (there will be defined conditions in which it
will shed to Auto or even Man).
Remote Output - The input-to-output transfer function of the block is not

(ROut) controlling the output; the output is being pushed to
this block by a higher level device in a cascade
structure. This mode will enable a count-out gate and
will normally shed to Cas with the ROut bit still set
(there will be defined conditions in which it will shed
to Auto, or even Man).
The Mode byte is maintained in dynamic memory, under the name "ACTUAL_MODE",
by the function block algorithm and will be referred to as the "actual" or
"dynamic" mode. It is readable but is not writeable by any other entity. The
default dynamic data base for all algorithms will have this mode set to O/S but
the value is changed based on the "requested" mode {see below} before it is used
by the algorithm.

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
74
REQUESTED MODE BYTE:

The "requested" mode byte, called REQ_MODE, is maintained in static memory
and is the mode byte that is manipulated by the operator, control programs, or
other control blocks. Only one of the 8 bits in REQ_MODE can be set at one time.
Under certain conditions defined in each algorithm, the algorithm itself may
change this byte but it too will leave only 1 bit set. Bit 6 (IMan) can never,
under any circumstances, be set. The algorithm will read REQ_MODE during the
block execution and adjust ACTUAL_MODE accordingly.
The default versions of the static data base for all algorithms will have
this mode set to O/S.
REQ_MODE will change less frequently than ACTUAL_MODE because it does not
indicate temporary override conditions. ACTUAL_MODE will be generated from
REQ_MODE every block cycle based on the prevailing conditions in the control
strategy at the time.
MODE INTERPRETATION:
The "mode" of a function block can be considered to be a state descriptor
that can assume any one of eight states. Each bit in the mode bytes described
above correspond to one of the possible states.
The REQ_MODE always corresponds to one of the eight states and defines the
state (mode) that the function block "should" assume.
In actual fact, there may be state variables that prevent the block from
assuming the requested state. It is forced into some other, higher priority,
state (mode).
The ACTUAL_MODE can be considered to be a complex state descriptor that shows

several sets of information simultaneously:
1) the actual mode of the block (the highest priority mode bit set)
2) the requested mode (the lowest priority mode bit set)
--```,``-`-`,,`,,`,`,,`---
3) the modes that the block could assume if the limiting state variables
were removed (the mode bits set between the highest and lowest
priority mode bits).
4) the transition path that the block mode would traverse if the
limiting state variables were removed in priority order (the mode
bits set between the highest and lowest priority mode bits and in
that order).
It is the intent of this Standard that a higher level device be free to

display the ACTUAL_MODE information, or any part thereof, in whatever format is
considered optimum.
If enumerations are applied to the REQ_MODE, there are only seven

enumerations possible (IMan can never be requested). The ACTUAL_MODE, taken in
its entirety, would require 96 enumerations (all reset is not possible, O/S can
not coexist with any other mode, and RCas and ROut can not coexist).
MODE PERMITTED BYTE:

To provide an optional limit on the number of algorithm modes, there will
also be a mechanism provided, using the parameter MODE_PERMIT, to allow the user
to prevent selected requested modes. MODE_PERMIT will be an 8 bit binary string:
the function block will permit only those modes that correspond to set bits. The
following rules apply:
In the Null algorithm (Algo 20H), only O/S mode will be allowed and the

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
75
Null algorithm itself will enforce that situation at every cycle.
The default static data base for all other algorithms will have most of
these bits set. However, the bits corresponding to modes not supported
by that algorithm will be reset and the algorithm itself will enforce
that state every cycle of operation, even in O/S mode. Many output
algorithms do not support ROut mode (Bit 0). Bit #5 (corresponding to
LO) will be reset for the several algorithms that do not have a defined
LO state. Any algorithm that does not support a cascade structure will
have the Cas, RCas, and ROut bits reset. The algorithm will reset bit 6
(IMan) every block cycle.
As for all modes, if the IMan or LO permitted bit is reset, a Field Bus
command to set the LO mode will be rejected. However, even if and while
the IMan or LO permitted bit is reset, the owning block can set the
corresponding mode in ACTUAL_MODE. Note that IMan mode will ALWAYS be
set in combination with some other mode.
If the algorithm supports Man mode but the user chooses to deny
permission to set Man mode, then Man mode can not be set over Field Bus
or by a discrete block in the device. However, Man mode may still be
set in ACTUAL_MODE as a result of algorithm rules that default to Man
under certain conditions.
MODE_PERMIT is stored in the static memory.
ATTRIBUTE/ACCESS BYTE:
A separate byte, called the "ATT_ACCESS" byte, will also be provided. The low
order 3 bits will contain the 3 mode attribute bits. Bits 3 through 5 will be
used to indicate required human interface access levels while bits 6 and 7 will
indicate the status of the block variable "ACQUIROR". Any conformant SP-50 field
device will have all 8 bits reset in the default data base of all algorithms. It
will not otherwise manipulate the low six bits unless so configured in a discrete
control block.
Attributes (Bits 0-2):

The following describes the three low order bits in the byte,
starting at the lowest order position:
Program (P) - When set, this bit indicates that the operator has turned
Bit 0 over his authority to change the set point, output, and
mode to a higher level, non-cascade program. The
operator has the authority to reset this bit and regain
control of the three variables.
Tuning (T) - When set, this bit indicates that the operator has given
Bit 1 his approval for a higher level program to manipulate the
tuning constants of this block. The data base variables
that constitute the tuning constants are defined by each
algorithm.
Alarm (A) - When set, this bit indicates that the operator has given
Bit 2 his approval for a higher level program to manipulate the
alarm limits of this block. The data base variables that
constitute the alarm limits are defined by each
algorithm.
The standard has assigned specific parameters to each of the three

attributes: they are identified in the paper "Array of Standard Block
Parameters". There is no mechanism to "unassign" the parameters that

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
76
are assigned to the three attributes by the standard, nor to add to

those assigned.
Any SP-50 conformant human interface device must support the 3

attribute bits. Specifically, when such a device displays a data base
variable in a display environment that allows operator inputs, it must
determine if the corresponding attribute bit is set. If so, it must:
1) be capable of displaying that fact in some way
2) prevent the human from changing the value until the attribute
bit is reset.
3) provide a way for the human to set and reset the attribute bit.
When the human does cause the attribute bit to be reset, the
field device will automatically set the corresponding tattle bit
(see below).
Each variable that is assigned to the Tuning or Alarm attribute by

the standard (but NOT those assigned to the Program attribute) will have
two copies of its value in the field device's data base - one in static
memory and one in dynamic memory. Each version will have its own
parameter name.
When a device starts up with a default dynamic data base, it will

--```,``-`-`,,`,,`,`,,`---
copy the static value into the dynamic value.
When the attribute is set, the dynamic value will be used. When
the attribute is reset, the static value will be written into the
dynamic value and used.
Either copy of each variable can be written at any time. All Field
Bus conformant Human Interface devices will only allow writing to the
static data base variable. It is intended that only higher level
control programs, such as batch control programs and automatic tuning
programs, that intend to make multiple changes to the value, would
change the dynamic value.
It is anticipated that many applications of the Tuning and Alarm

attributes will find situations in which the human operator may want to
stop the automatic adjustment of the parameters under the attribute but
to continue to use their current (dynamic) values, not the old static
value. A Human I/F could easily offer an option under which the I/F
device itself copied the dynamic value to static memory before resetting
the attribute.
Operator Access (Bits 3-5):

Bits 3 through 5 in the ATT_ACCESS byte will be assigned the
following functions:
Bit 3 - set if a high access level is needed to change any tuning
parameter.
4 - set if a high access level is needed to change any alarm
parameter.
5 - set if the access level is to be changed by the "User"
access level feature.
The user will have the ability to define any variables in the data
base - up to 5 - as being under the "User access". The data for these
assignments will be entered in the logical node variable "ASSIGN_USER".
That parameter will be in two parts. Part (1) will be an 8 bit binary
string built in the following format:
bits 0 - 2 - these three bits form an integer whose value must be
between 0 and 5. The value defines the number of 16
bit integers to follow immediately. Each 16 bit
integer will be a parameter number.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
77
If the value of the integer = 0, then bits 3-7 will be

meaningless and there will be no part (2).
bits 3 - 7 - one bit for each parameter, bit 3 for the first one,
that defines if the access level is to be lowered (0)
or raised (1) for that parameter.
If the integer in bits 0-2 of the above string is not equal to 0, then
the above string will be followed by n 16 bit integers where n is the
value found in bits 0-2 above. Each one will be a parameter number of a
parameter that is "defined to be under the User access". The parameters
can be any parameter number; they do not even have to be parameters
supported by this tag. It is assumed that the integer has meaning to
the higher level operator interface.
Note: the Field Device must supply enough room for 5 parameters in each
function block.
Note: the total length of the User feature can be between 1 and 11 bytes
long in the Data Dictionary variable FB.
The parameter "FB" in the logical node's "Data Dictionary" in the

communications interface will automatically include the user-assigned
parameter numbers (see the paper "Application Support Services
Interface").
The operation of the tuning and alarm access bits is quite simple.
They will initialize reset but can be set by a higher level device. If
they are set, they are an indication to any SP-50 conformant human
interface that the human interface must be at an access level above the
normal operator's access level in order to change the associated
parameters.
When the User access bit is set, a higher level device is directed
to the Data Dictionary information, contained in item FB, that
describes up to 5 changes to the access level. The identified parameters
can be individually assigned a high access level or a low access level.
They will override the access level assigned by the tuning or alarm
access bits or any access level assignments made totally within the
higher level operator station unless they are made on an individual tag
basis.
--```,``-`-`,,`,,`,`,,`---
Note particularly that the attribute bits control access by a
higher level program vs. the operator. The access bits control access
to the parameters by operator access level. An operator can take access
rights away from a higher level program (by resetting the mode attribute
bit) BUT MAY NOT BE ABLE, HIMSELF, TO CHANGE THE PARAMETERS BECAUSE OF
BITS 3 - 5. In addition, a conformant human interface may allow the
operator to accept the current (i.e., dynamic memory) parameters or the
original parameters (i.e., static memory) when resetting one of the mode
attribute bits even though that parameter is under limited access due to
bits 3-5.
ACQUIROR Summary (Bits 6 & 7):

Bits 6 and 7 serve as a simple summary of the current value of the
parameter "ACQUIROR". The 16 bit unsigned integer block variable
"ACQUIROR" is included in every Standard function block. It will
indicate the status of the relationship between the function block and
any high level program. ACQUIROR will default to zero. For a further
description of the use of this variable, see the Appendix paper
"Explanation of ASK, BASK, and Acquiror".
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Although outside of the scope of Field Bus, it is assumed that all

higher level programmed systems will respect the ACQUIROR number.

78
No Field Bus device will be allowed to write a non-zero value to

ACQUIROR unless it is currently reset. The complex conditional write
(see the paper "Data Base Write Service", Attachment 1) allows a higher
level system to confirm that the ACQUIROR number has not been changed.
If any of the low 15 bits of ACQUIROR are set, then the function
block has been "acquired" by one high level entity and no other program
entity can access the variables under the mode attribute bits defined
above. However, access contention between the operator and the
acquiring entity is still controlled by the attribute bits. Stated
another way, when the operator gives "a" higher level program access to
block parameters by setting a mode attribute bit, ACQUIROR determines
WHICH higher level program.
If the high order bit of ACQUIROR is set, all conformant human

interface devices will require that the operator interface be at an
access level higher than the normal operator access level in order to
reset any of the three attribute bits. Note that bit 7, when set, makes
the higher level program more powerful than the normal operator but it
remains less powerful than the "high access rights" operator. When
reset, the normal operator is more powerful than the batch program.
THIS IS A VERY IMPORTANT DISTINCTION FOR THE USER - IT PROFOUNDLY
AFFECTS THE OPERATOR'S ABILITY TO HANDLE AN EMERGENCY.
Bits 6 and 7 in the ATT_ACCESS byte will summarize the status of

the parameter ACQUIROR. The following defines the high two bits of the
byte:
Bit 6 - any time any of the low order 15 bits of the block
(acquired) parameter ACQUIROR are non-zero, this bit will be set. A
human interface device can display this information to an
operator to indicate that a high level program has
"acquired" this function block.
Bit 7 - any time the high order bit of the block parameter
(limited) ACQUIROR is set, this bit will be set. A human interface
device can display this information to an operator to
indicate that a higher level of access is needed to reset
any of the 3 attribute bits. Note particularly that bit
7 can be set even though bit 6 is reset.
ACQUIROR will normally only be changed by Field Bus writes; it

should not be changed at any time by the processes of the field device
block algorithm itself unless the algorithm number is changed. When the
algorithm number is changed, ACQUIROR will be reset by the Data Base
Write Service (DBWS).
Any time ACQUIROR is changed, the DBWS will copy the high order bit
of ACQUIROR into the high-order bit of ATT_ACCESS. At the same time,
bit 6 of ATT_ACCESS will be set if any of the low-order 15 bits of
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
ACQUIROR are set, ELSE bit 6 of ATT_ACCESS will be reset.
Since the two high-order bits in ATT_ACCESS contain the necessary

information about ACQUIROR, it is not necessary for a human interface to
access ACQUIROR to support normal displays. The access limitation is
put in place if bit 7 of ATT_ACCESS is set and the fact that the block
is "acquired" can be indicated if bit 6 is set.
A SP-50 conformant human interface will enforce the attribute bits

as described above. In addition, it will prevent resetting of any of
the three attribute bits if bit 7 in ATT_ACCESS is set and the
interface is not currently at an access level higher than "operator". If
the human interface does not support the concept of access levels, then
--```,``-`-`,,`,,`,`,,`---
the interface will prevent any write access to ATT_ACCESS that resets ANY
bit. Note that this restriction applies directly to a "hand held
communicator" type human interface. If a particular instance of such a
communicator does not support operator access levels, it essentially can

79
not be relied on as an emergency operator interface since it would be

blocked by mode attributes.
A SP-50 conformant human interface will always do a masked compare

conditional write (see the paper "Data Base Write Service") when it
changes any variable under any one of the three attribute bits. The
masked compare must check, at the time of the write, to be sure that the
appropriate one of the three attribute bits is still reset.
Likewise, a SP-50 conformant human interface will do a masked

compare check conditional write when it changes any of the three
attribute bits if the interface is at the normal access level. It must
be sure that the high order bit is still reset.
Finally, a SP-50 conformant human interface will not accept a

command to write any one of the three access bits if it is not at an
access level above the normal operator access level and it will never
write to bits 6 and/or 7.
A SP-50 conformant higher level programed device must obey the

restrictions placed on it and must use the compare check conditional
write when it changes any of the values under the mode attributes. It
must be sure that the mode attributes are set when it writes to the
parameter values.
--```,``-`-`,,`,,`,`,,`---
Explanation of Figure 1:
The rules associated with the ATT_ACCESS byte are summarized in
Figure 1. In this figure, four sources of write commands are depicted
across the top - an operator with normal access authority, with high
access authority, a configured higher level control system, and a
programmed higher level control system. The state of the appropriate
attribute, access, and ACQUIROR limited bits are shown just below the
command sources. Below the arrows are symbols showing when a write to
any one of 8 destinations is permissible.
For example, consider the first write illustrated (the first column
of symbols on the left). The case is defined to be an operator with
only normal access attempting a write while:
1) the associated attribute bit is reset. (Figure 1)
2) the associated access bit is reset.
3) the ACQUIROR Limited bit is reset.
(These all follow from the absence of "1"'s at the top of the column).
The symbols below the arrow, stated in descending order, show that:
a) a particular attribute bit can be set (it is currently reset as
given above).
b) a particular access bit can be set (it is currently reset as
given above).
c) it is "redundant" to reset the attribute bit (it is currently
reset).
d) it is "redundant" to reset the access bit (it is currently
reset).
e) the parameters under a particular attribute bit (it is currently
reset as given above) can be written.
f) the parameters under a particular access bit (it is currently
reset as given above) can be written.
g) the operator can clear ACQUIROR (its high bit is not set as
given above).
h) the operator can write a value to ACQUIROR (its high bit is not
set as given above).
(Figure 1)
In column two, a particular attribute bit is set. Therefore, the
operator can reset the attribute bit (it is redundant to set it) but he
can not write to the parameters under that attribute bit (shown by the

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
80
"X" in the column).
The last four columns show the possible cases for a higher level
control program.
Under normal control, a higher level program would not manipulate

the attribute bits and would not need to manipulate the access bits.
However, there are higher level programs that "set up" the tags for a
batch and so would need free access to the attribute bits. Also,
programs are sometimes used to enforce the access bits. Therefore, a
higher level program is shown as having access to both the attribute and
access bits. The actual specification of this area is outside of the
scope of Field Bus.
Note that the control program is unconstrained by the access

limits.
(Figure 1)
Symbol "2" indicates that program writes to parameters under the
attributes while the attribute bits are set are permitted only if the
ACQUIROR value is the unique value assigned to the program doing the
write. Likewise, a program is only allowed to clear "its own" ACQUIROR
value. Symbol "3" is consistent with the above assumption that a
program will only write a non-zero value to ACQUIROR if it is currently
zero.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
ATT_ACCESS is stored in the static memory.
TATTLE BYTE:
Another separate byte, called the "TATTLE" byte, will also be provided. The
low order three bits will contain the three attribute tattle bits that correspond
to the three attributes in ATT_ACCESS; they will be arranged in the same order.
Bits 3 through 5 will contain the three access tattle bits that correspond to the
three access bits in ATT_ACCESS; they will be arranged in the same order. Bits 6
and 7 will be referred to as the auto-tuner control bits. The whole byte will be
set at power-up by the node. All bits in this byte will be set in the default
version of the data base of all algorithms.
The appropriate one of the six low-order bits will be set by the data owning
node any time the corresponding ATT_ACCESS bit is reset. These bits will never
be reset by the node. Rather, they will be reset and then monitored only by a
higher level program that needs to determine if an attribute bit has been reset.
Bits 6 and 7 will be manipulated by the function block every cycle using the
following logic:
IF the block is actually executing in Auto, Cas, or RCas mode, AND
The block is not executing an initialization pass, AND
The block algorithm is not wound up high, AND
The block algorithm is not wound up low, AND
[(The by-pass option is NOT set) OR (the by-pass option is not
supported)], THEN
Reset bit 6.
ELSE
IF bit 6 is reset, THEN
Set bit 7.
Set bit 6.
Bit 6 will never be written from the Field Bus and there is no reason to ever set
bit 7 from Field Bus. Notice that the function block never resets bit 7. See
the description of the "Tuning" algorithm for the use of these two bits.
In the above logic, the term "algorithm is not wound up" was used twice.
These wound up states correspond exactly to the wound up states of a discrete
Setpoint as entered in the Setpoint value bits 6 and 7. They also correspond to

--```,``-`-`,,`,,`,`,,`---

81
the wound up states of an analog Setpoint as entered in the Setpoint status byte,
bits 6 and 7, EXCEPT that the Setpoint limits of the local function block are not
considered in the determination of the wound up state (see page 21 of the paper
"Function Block Structure").
Any SP-50 conformant human interface device must not display nor allow the
manipulation of any of the bits of the tattle byte in the normal operator
priority level.
The TATTLE byte is stored in the dynamic memory.
FREE MODE BYTE:
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Finally, an undefined byte, stored in static memory, must be provided for use
by a higher level device. This byte, called FREE_MODE, must be fully supported
by the field device: it must be able to be read and written over field bus; it
must be maintained under the static data base revision counter exactly the same
as REQ_MODE; it must be supported during power up and data base configuration as
is the requested mode byte; it must not be independently used by the field
device.
GENERATION OF THE ACTUAL MODE:

The block algorithm will generate the actual mode every cycle based on
REQ_MODE and the current situation in the control structure. Attachment 1 to the
paper "Function Block Structure" gives the detailed logic that will be used for
setting the actual mode in Standard blocks.
The fact that the actual mode can be generated from the requested mode and
the control structure conditions is the basis for part of the logic of the
restart procedure.
The algorithm may set IMan mode based on the prefetched value of its output.
It may set the LO mode based on several different conditions. It may set Man,
Auto, or Cas mode in situations in which cascade transfer locations have counted
out or values have been marked "Bad" or NaN.
The algorithm has the option of changing the requested mode when there is a
cascade failure and when particular Inputs are marked "Bad". It will never set
the requested mode to IMan and it will only set it to O/S mode in the restart
logic. When it does set the requested mode, there is no automatic recovery
method provided.
When the requested mode is set to RCas or ROut, the fail-over mode will
always be set until the Remote handshake is accomplished
SUMMARY RULES:
The above presents all of the data base tools for the control of mode and
mode attribute. ACTUAL_MODE and TATTLE will be maintained in dynamic memory.
The other 4 bytes will be in static memory. The following rules will be enforced
in any writing to the 6 bytes that constitute the mode structure:
The field device itself will ensure that any write from the field bus or from
a peer block within the node or from the block's own configured logic (but not
from the operation of the block algorithm itself):
- ACTUAL_MODE:
+ Can not be written.

--```,``-`-`,,`,,`,`,,`---

82
- REQ_MODE:
+ Can never set IMan Mode (bit 6).
+ Can not set a mode bit that corresponds to a reset mode permitted
bit.
+ If a write would result in 0 bits set or more than 1 bit set,
reject the write.
+ Can not set O/S mode in an Output block that is keylocked.
- MODE_PERMIT:
+ Can never set the IMan bit (bit 6).
- ATT_ACCESS:
+ Any write must be a masked write.
+ Any time there is a write that resets any of the low three bits,
the field device will set the corresponding bits in the TATTLE
byte.
+ Bits 6 and 7 can never be written.
- TATTLE Byte:
+ Bit 6 can never be written from Field Bus.
- FREE_MODE:
+ No constraint.
In addition, the field device will, on its cyclic basis, set ATT_ACCESS, bits 6
and 7, based on the then-current value of ACQUIROR and will generate the actual
mode.
In addition, the following constraints apply to specific sources on Field

Bus:
From a SP-50 conformant human interface:
- REQ_MODE:
+ Without the correct authorization, the operator can not
write when LO is set (even O/S).
+ Can not write if the mode attribute is set.
- MODE_PERMIT:
--```,``-`-`,,`,,`,`,,`---
+ Without the correct authorization, the operator can not

change MODE_PERMIT.
- ATT_ACCESS:
+ An operator can not manipulate the block set point, output,
nor mode if the program attribute is set.
+ An operator can reset the program attribute at any time if
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
bit 7 of ATT_ACCESS is reset but the tattle bit will
automatically be set by the field device. (A human
interface device might provide the user with the option of
always requiring a higher level of authorization to reset
the program attribute bit.)
+ If bit 7 of ATT_ACCESS is set, a human I/F must be at an
access level above "operator" to allow a write to reset the
mode attribute bit. If the human I/F does not support
levels of access, then it can not reset the bit under this
condition.
+ In a directly analogous way, the interface will support the
other two attributes.
+ An operator can not manipulate any of the parameters defined
as being under the tuning attribute if the tuning access bit
is set unless the operator interface is at an access level
above the normal operator access level.
+ An operator can reset the access bit only if the operator
interface is at an access level above the normal operator
access level. When it is reset, the tattle bit will
auttomatically be set by the field device.
+ In a directly analogous way, the interface will support the
other two access bits.
- TATTLE Byte:
+ An operator can not see nor manipulate the tattle bits but a
user with a higher level of access may be able to.
+ No human interface should set bits 0-2 nor bit 7.
- FREE_MODE:
+ Not defined.

83
From a higher-level control block in cascade to RCas or ROut:

- Does not need to directly manipulate any element of the mode
structure.
From a Non-Cascade Control Program:

- REQ_MODE:
+ Can not manipulate the requested mode if O/S or LO is
set.
- MODE_PERMIT:
+ Can set the mode permissible bits.
- TATTLE Byte:
--```,``-`-`,,`,,`,`,,`---
+ No constraint
- FREE_MODE:
+ Not defined.
- It is anticipated that a non-cascade control program would have
two modes of operation: one in which it is "powerful"
for initial set-up and one in which it follows more
constraining rules. In the constrained operation, it
should obey the following rules:
+ ATT_ACCESS:
@ Can not manipulate the block set point, output, nor
mode if the program attribute is reset.
@ Can not manipulate tuning constants if the tuning
attribute is reset.
@ Can not manipulate alarm limits if the alarm attribute
is reset.
From a block with discrete outputs anywhere on Field Bus:

- REQ_MODE:
+ Can not manipulate modes if O/S or LO is set.
- MODE_PERMIT:
+ No additional constraint.
- ATT_ACCESS:
+ No additional constraint.
- TATTLE Byte:
+ No constraint.
- FREE_MODE:
+ No constraint.
Each Field device that implements the cascade modes will support a count-out
function. The function will manipulate the actual mode based on the following
general rules (these rules are imbeded in the more complete logic given in
Attachment 1 to the paper "Function Block Structure"):
Note: the following action does NOT cover situations where parameters
change to NaN nor where they have a Bad Value but not No-Com.
IF an ROut transfer location is counted out:

- IF the ROut mode is requested, then
+ IF [Cas permissible AND Input #0 agent not type Null],
then
set Cas mode.
ELSE
IF Input #0 agent is of type "block point (counted)"
OR Input #0 agent is of type "required
writeable"), then
Set Logical Node Isolation_Time into the Logical
Node Isolation_Timer.
IF Auto permissible, then
set Auto.
IF Input #0's agent type has its low bit set,
then
Requested mode = Auto.
ELSEIF Man permissible, then
set Man.
then

//^:^^#^~^^"~
84
Requested mode = Man.

ELSE
leave the ROut mode.
ENDIF.
ENDIF.
ENDIF.
IF an RCas transfer location is counted out:
- IF the RCas mode is requested, then
+ IF [Cas permissible AND Input #0 agent not type Null],
then
set Cas mode.
ELSE
IF (Input #0agent is of type "block point (counted)"
OR Input #0 agent is of type "required
writeable"), then
Set Logical Node Isolation_Time into the Logical
Node Isolation_Timer.
set Auto.
then
set Man.
then
ELSE
leave the RCas mode.
ENDIF.
ENDIF.
ENDIF.
IF a Cas transfer location is counted out:
- IF the highest priority ACTUAL_MODE bit set is Cas, then
IF (Input #0 agent is of type "block point (counted)" OR
Input #0 agent is of type "required writeable"),
then
--```,``-`-`,,`,,`,`,,`---
Set Logical Node Isolation_Time into the Logical Node

Isolation_Timer.
IF the low order bit in the Input #0 agent's type is set,
then,
set Auto.
then
set Man.
then
ELSE
leave the Cas mode.
ENDIF.
Note: in all three cases, the transfer location's status is set to

No-Com. by the logic given in the paper "Application Support
Services Interface".

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
85
Figure 15: Attribute / Access Limits
Figure 1
ATTRIBUTE /ACCESS LIMITS
Operator Higher Level Control
Normal AL. Hi AL. Configured Programmed
Attrib./Access Bits:
Bit 0, 1, or 2 Attribute 1 1 1 1 1 1 1 1
Bit 3, 4, or 5 - Access 1 1 1 1 1 1 1 1
Bit 7 - ACQUIROR Limited 1 1 1 1 1 1 Any Any 1 1 1
____________________________________________________

Set Attrib/Access Bits:
Bit 0, 1, or 2-Attribute @ ? ? @ @ @ @ ? ? @ @ @ @ ? ? @ ? ?
Bit 3, 4, or 5 _ Access @ @ @ ? ? @ @ @ @ ? ? @ @ ? ? ? ? @
Reset Attrib/Access Bits:

Bit 0, 1, or 2-Attribute ? @ x ? ? ? ? @ @ ? ? ? ? @ @ ? @ @
Bit 3, 4, or 5 _ Access ? ? ? x x ? ? ? ? @ @ ? ? @ @ @ ? @
Write Parameters:
Bit 0, 1, or 2-Attribute @ x x @ @ @ @ x x @ @ @ @ @ 2 x 2 2
Bit 3, 4, or 5 _ Access @ @ @ x x @ @ @ @ @ @ @ @ @ @ @ @ @
Clear ACQUIROR @ @ x @ x x @ @ @ @ @ @ x x 2 2 2 2
Non-Zero Write to ACQ. @ @ x @ x x @ @ @ @ @ @ x x 3 3 3 3
________________________________________________________
Symbols: 1 = bit set 2 = only if ACQ. = own value
@ = write permitted 3 = only if ACQ. Is reset
? = redundant x = blocked
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
86
Status Byte
All inputs and outputs of all blocks executing standard algorithms will have
a "status byte" to indicate certain status information about the value. This rule
applies equally to all data types, including analog, discrete, and visible
strings. In addition, certain internal parameters of many standard blocks, such
as the Setpoint, also have status bytes.
When a value that has a status byte is exchanged between 2 blocks or is

exchanged between a block and a higher level device, the status byte of that
value can optionally be included with the value as part of the single parameter.
Specifically, all values with status bytes will have multiple parameter names.
The parameter names will determine if the status byte is included in the
transfer. If it is included, it will be transmitted second. If a status byte is
not included in a write to a field bus parameter that has a status byte, the
receiving node will generate a suitable status byte for the value.
It is intended that the individual status bits that are defined for the
status byte be arranged in their bit string exactly as described. The bit string
can be considered an enumeration if desired. Alternately, it can be considered a
bit string and the individual bits can be manipulated. Certain Field Bus
algorithms can do such manipulation.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
STATUS BITS
SUMMARY OF BIT FUNCTIONS
CONDENSED STATUS BYTES
GENERATED STATUS BYTES
DETAILED DESCRIPTION OF EACH BIT
CALCULATION OF BITS
Attachment 1 - State Diagram - Bits 5, 4, and 3
Figure 1 - Status State Diagram
Attachment 2 - Remote Handshake
Figure 2 - State Transition Diagram - Transfer Location
Status Byte
STATUS BITS:
The "nicknames", the full names, and the general meanings of the eight status
bits in the status byte are:
bit 0 - "No-Com" = No communication:
The value has a questionable status because the block can not
communicate with the proper source or destination of the value.
1 - "Bad" = bad value:

The value has been marked as having a bad status.
2 - "Override" or "Not-from-Process" = not affected by the process:

Normal Case:
The value is not directly affected by any process
information. Analog example: an analog input block can be
placed in manual mode and the output set by the operator.
In this case, bit 2 of its output's status byte is set and,
if the value is used as the Input 1 of a PID algorithm, the
PID block will stop processing (it will show doubly wound
up). Discrete example: the digital input may be in input
override. Bit 2 can be used in logic blocks as a means of
detecting overrides.
Cascade Structures:
The value is being controlled by the lowest control function
block that has been designated as "independent". This bit
is used as input information by the Selector block and by a
--```,``-`-`,,`,,`,`,,`---
SP-50 User Layer Technical Report Status Byte

87
"valve position controller" PID block. It can also be used

by user-programmed logic functions. The bit is originally
set in the output of the lowest control block (PID or
Device Control) that has been configured as an "independent
controller" and is controlling.
3 - "Special" = Special Status Bit: Reserved for two special uses:

a) for the RCas and ROut transfer values in blocks with analog
Setpoints - the secondary will set this bit if the cascade is
not made up.
b) for cascade structure values - this bit set indicates that a
block has its LO mode set or the physical hardware itself has a
"local override" lock set.
4 - "Failed" = Output failed:

The value is normally connected, directly or indirectly, partly or
completely, to a hardware connection or a communication link
that has failed.
5 - "No-Path" = No output path:

Bits 3 and 4 Reset:
The output does not have an initializable (i.e., cascade)
path. For example, the last block downstream may be storing
its output into a data base item. This bit is also set by a
lower block that is in O/S mode.
Bits 3 or 4 Set:
When bits 3 or 4 are set, bit 5 drops its normal meaning and
becomes a companion for the other bits. For bit 3, the
extra information carried by bit 5 indicates the direction
of the flow of the LO information - up or down the cascade.
For bit 4, the extra information carried by bit 5 is a
handshake that informs the block with the failure that the
"primary" in the cascade has received the failure
information and has acted on it. (Primary here means the
first block going up in the cascade that can acknowledge the
failure.) When both bits 3 and 4 are set, the failure
information has higher priority.
6 - "ATW-h" = Anti-windup hi:

Analog values: the lower blocks in the cascade can not respond
to upward movement in this value.
OR: the measured value is upward limited.
For discrete values: the lower blocks in the structure would
prevent a logical 1 from going to its
ultimate destination.
7 - "ATW-l" = Anti-windup low:

Analog values: the lower blocks in the cascade can not respond
to downward movement in this value.
OR: the measured value is downward limited.
For discrete values: the lower blocks in the structure would
prevent a logical 0 from going to its
ultimate destination.
SUMMARY OF BIT FUNCTIONS:

As seen above, the definitions of the analog and discrete status bytes are
almost the same. In both cases, there are five groups of functions served by
these bits:
1) bit 0 concerns an immediate configuration or communication problem;
the input (or prefetched output) value can not be obtained or the
output can not be stored.
2) bits 1 and 2 indicate if the value is reported as being valid and if
the value is influenced by the process. This information flows from

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
88
the process to the control system inputs, then "down" to the blocks.
3) bit 3 is a special handshaking bit for Remotes or indicates that LO
mode has been set in a cascade.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
4) bit 4 describes information that is being passed with a measurement

value to data consumers.
5) bits 4 through 7 describe information that is being passed up in the
control structure from the output block. One exception is the use of
bit 5 in conjunction with bits 3 and 4; this is described later in
Attachment 1 and the details of its use are given in Attachment 1 to
the paper "Function Block Structure". The second exception is the
use of bit 7 in the Remote cascade structure handshake that will be
described in Attachment 2.
CONDENSED STATUS BYTES:

Discrete variables can be addressed as a single bit or as a bit string
containing up to 16 discrete values. When a single bit is addressed, the status
byte of that discrete can optionally be exchanged. When a bit string is
exchanged, there are three options available to the user. They are to exchange:
1) the 8 by 16 array of status bits
2) one status byte that is the transverse "OR" of the 16 status bytes -
the receiving block simply enters the same status for each of the 16
discrete values.
3) no status information; the receiving block will use a standard
default status byte for each of the bits.
GENERATED STATUS BYTES:
--```,``-`-`,,`,,`,`,,`---
When a control structure points an input or output agent to a data value in a
block data base, the agent must generate a status byte for the value since data
base values do not have status bytes. A status byte must also be generated when
the status information is not included in the parameter identified by an agent's
pointer or in an I/O word value written from a higher level device. The
generated status byte will always be the following:
Bit 0 - No-Com - Set if the communication was
unsuccessful, else reset.
1 - Bad - Set if the data value was NaN OR (Set
if the communication was unsuccessful
and the pointer type sets Bad on
No-Com);
ELSE reset.
2 - Override - Set
3 - Special - Reset
4 - Failed - IF "Bad" is set, then
set.
ELSE
reset.
5 - No Path - Set
6 - ATW-h - Reset
7 - ATW-l - Reset
Note that a value that will become the Input 1 of a standard PID block can
not be communicated using this method because the Override information will stop
the PID. Secondly, this type of connection can not exist in a cascade structure
that has a standard PID block "above" the connection because the "No Path" will
stop the PID. Third, the use of a parameter that does not carry status will
effect the handling of NaN and Bad values in the Outputs of some standard
algorithms. Fourth, since the Special bit is always reset, the LO status can not
be carried across such a connection. Finally, control blocks located "above" such
a connection in a cascade or below such a connection in a measurement path can
not warn of failures.

89
DETAILED DESCRIPTION OF EACH BIT:

bit 0 - "No-Com" = No communication:
This bit will initially be reset in all I/O Word status bytes.
If the value has not been properly updated due to communication
problems in the Field Bus system for several consecutive block
cycles, this bit may be set by the block. The configurations of
the agent and the algorithm will determine the control response
to the situation. If a write has a status byte with this bit
set, the receiving node will reset this bit, set Not-from-
Process, and optionally (forced if an indirect write) set Bad
and Failed. If the response to a read has no communication
problems but has a status byte with this bit set, the agent
service will reset this bit, set Not-from-Process, and
optionally set Bad and Failed.
There is one other circumstance in which the No-Com status bit

is set. If a Field device is designed in such a way that the
communication interface may still operate when the User Layer
logic engine has failed, a service run by the communication
layer interface must set the No-Com bit in all status bytes in
the memory of the failed User Layer. In this special case, bits
2, 4, and 5 (see below) are also set.
It is intended that a block would set an alarm when this bit is

set because it only occurs at the source of the problem.
However, this alarm would be suppressed by a simultaneous "Bad"
alarm.
1 - "Bad" = bad value:

The bad value bit is the normal means of indicating that the
input value is bad. The system will, in general, proceed using
the last value it had for the variable but with this bit set.
The last good value accompanies the "Bad" indication. There are
nine primary ways by which a bad value can be generated:
- Set by the algorithm as part of original data base
initialization.
- Bad transducer detected: set by the physical circuit.
- Bad input circuitry: set by the physical device.
- Set optionally by an agent that failed to communicate.
- Remote value with a bad communication status fetched:
optionally set by the agent service.
- A value status written (using an indirect write) by a
remote device with the No-Com status bit accidentally
set: the No-Com bit will be reset and this bit set by
the receiving block.
- A value status written (using a cyclic or direct write)
by a remote device with the No-Com status bit set: the
No-Com bit will be reset and this bit optionally set by
the receiving block.
- A NaN was detected in the value item written to the
block or returned in response to a fetch: "Bad" set by
the Data Base Write Service or agent (along with Not-
from-Process, and Failed).
- Set on transition to O/S mode.
It is intended that a block would set an alarm when this bit is

set because even though the bad status can flow through several
blocks in a cascade structure, it is a major disruption to the
control scheme. It is not set by the block that transitions
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
into O/S mode. If appropriate, the priority of the bad alarm

can be set to 0.
The exact handling of the "Bad" status will be defined by the

--```,``-`-`,,`,,`,`,,`---

90
individual algorithm descriptions. However, in general, the

algorithms will specify the following rules:
- when a value that is marked "Bad" is read or written
during interblock communication, the receiving location
will replace its original value with the communicated
value and, of course, the value will continue to be
marked "Bad".
- when a block executes its algorithm and finds that it
is actually instructed to use a "Bad" value, the
calculation will proceed with the "Bad" value; the
result of the calculation will be placed in the Output
of the block but it will be marked "Bad". (Note that
this action will specifically NOT be done in the PID
and Selector blocks and in two of the Math block
equations.)
2 - "Override" or "Not-from-Process" = not affected by the process:

The Override bit is set in the status byte of all variables at
initial data base start-up and whenever a status byte is
generated for an input value read from a data base value by an
I/O agent or a value written without a status byte by a higher
level device.
Normal Case:
The set status indicates that the data value does not
contain any element of live process data. A correctly
functioning Input or Output block will reset the bit in the
status byte of its input/output values. The status will be
passed "down" through blocks when appropriate and as
defined by the block algorithm. This information is
primarily set up for the operator but it is also used by
the PID algorithm to stop control action and is available
for the Logic, and Program algorithms to detect "input
override" of discretes.
This bit is set in all status bytes in a block that

transitions into O/S mode. Thereafter, it is set in all
transfer locations (i.e., Cas, RCas, and ROut transfer
locations) as long as the block is in O/S mode (but not
continuously set in I/O Words nor the block's Setpoint nor
Output). It is set in the status byte of all values that
are No-Com or Bad. It is set in the calculated Outputs of
all algorithms that:
1) normally pass it from their inputs to their outputs
AND 2) are in a mode higher in priority than Auto.
Note especially that the output blocks will reset this bit
in their "feedback" values.
It is not intended that a control block would set an alarm

or an event notification when this bit is set because it
can flow through several blocks in a cascade structure and
can cycle based on control scheme constraints. The source
of the break in the path, if it was done automatically,
should set an alarm.
Control Cascade Structures:

A "cascade structure" consists of a path between the Output
of a control block and an Output function block. The path
can pass through the Setpoints of other control blocks and
through certain function blocks that "support a cascade
structure". These include the Math and Selector analog
blocks and the Logic and Program discrete blocks.
Bit 5 represents information that is passing up the cascade

and indicates if there is a path to the process. When the
indication that there is a path to the process arrives at

//^:^^#^~^^"~~:~"~$$"~$^"#:
--```,``-`-`,,`,,`,`,,`---

91
--```,``-`-`,,`,,`,`,,`---
the Output of a control block, the control block will reset

Bit 2 and pass that state back down the cascade if the
following conditions are all true in the control block:
PID:
Bit 5 is reset in the status of the Output.
The block is configured to be "independent".
The highest priority actual mode bit set is lower
in priority than Man.
Not both of status bits 6 and 7 are set in the
Setpoint after block execution.
Discrete Control:
Bit 5 is reset in the value of the Output.
The block is configured to be "independent".
The highest priority actual mode bit set is lower
in priority than Man.
Not both of the Setpoint value bits 6 and 7 are
set after block execution.
Special options will be provided in the Math and Selector

blocks to prevent non-cascade inputs from causing this bit
to be reset.
This bit will be used to support two special cases. One

involves a User configuration: when a type of control
configuration called a "valve position controller" is
formed by a User, this procedure will cause the "from
process" bit to be set in the Input #1 of the valve
position controller PID. This is necessary for operation
of the integral action in that PID.
The other case involves a system application of the bit:

the handling of the input of a Selector block. When this
bit is reset, the selector can do its normal bias
adjustment of the non-selected input. When this bit is
set, the selector can optionally be configured to ignore
the input or to simply not do the bias adjustment. This
provides necessary options for the user and prevents
undesirable operation of the selector itself.
3 - "Special" = Special Status Bit:
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
There are two cases where a status bit to serve a special
function is needed. These are totally unrelated and
non-overlapping functions. Initially, all values will have this
bit reset.
- Remote not Invited:
This bit is set in a RCas or ROut transfer
location in a block with an analog Setpoint to
signal the Remote control device that the block is
not ready to accept its input. This function only
applies to the status byte of the RCas and ROut
analog transfer values. The bit is reset by the
secondary algorithm when the RCas or ROut cascade
structure is made up by the secondary.
- LO Set:
This bit is used by blocks in a cascade structure
to exchange information relative to LO mode. I/O
Agents that write block output words to lower
level cascade structures will normally mask this
bit when they write. However, some blocks with a
path to the process will allow themselves to be
placed in LO mode and will set this bit in their
outputs and write it to the output word
destinations. If they do not have a path to the
process, they will reject the LO mode. When a
lower level block that supports LO mode finds the
bit set in its input location, it will set its
mode to LO(x) and:

92
a) freeze its physical output until the bit

is again found reset AND
b) pass the LO status further down the
cascade.
When a higher level block that supports LO modes
finds the bit set in its Output location, it will
set its mode to IMan(LO(x)) and pass the LO status
further up the cascade if so defined.
It is not intended that a block would set an alarm or a

notification when this bit is set because it can flow through
several blocks in a cascade structure. If the application of
the bit is to indicate the LO mode, the source of the LO mode
should set the alarm. If the application of the bit is to
indicate the invitation to the remote control scheme, that
change was caused by some other event that should be the source
of an alarm if one is appropriate.
--```,``-`-`,,`,,`,`,,`---
4 - "Fail" = failed:
This bit will initially be reset in all I/O words except for
cascade locations in output blocks.
For OUTPUTs of hardware input blocks:

This bit is set if the hardware connection has failed AND the
OUTPUT is not actively pushing its value to another location
on Field Bus. It is initialized reset and left unaltered on
transition to, or during, O/S mode.
For INPUTs of hardware output blocks:
This bit is set if the value is being pushed to the block by
another block AND the value will not have its normal effect
on the hardware because the path to the ultimate destination
is broken due to failed output channel hardware, failed loop
wiring, a failed actuator, or the block is in O/S mode. It
is not set by a lower block in a "blocking" mode other than
O/S. It is initialized set. It is set on transition to O/S
mode and each cycle in O/S thereafter.
When an active agent encounters a "No-Com" situation, it can

optionally set this bit in the status byte.
In measurement paths:
The bit can flow from input measurements to blocks that
actively fetch the value, optionally through that block,
and on to other blocks that also fetch the value.
By configuration, the user can select one of the data

consumers to issue an alarm upon failure. Ultimately, the
failure bit will cause an alarm or simply terminate.
In cascade structures:
The bit can flow from an output variable "up" a cascade to
a higher level block that is in a cascade structure with it
(and therefore is pushing its value to the output block).
It can optionally flow through that block, depending on
configuration and the type of block, and further up to
higher level blocks in the cascade structure.
This bit indicates that there has been a failure lower in

the cascade structure. As a minimum, it will cause IMan to
be indicated by the higher blocks. Optionally, the
information can be passed upward in a cascade structure to
a block that will set itself into Man mode as a result of
this bit being set. When the failure is cleared in the
lower portion of the cascade, the blocks up to the one in
Man will clear and resume control but the block in Man will
stay in that mode until changed by the operator.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
93
This bit is initialized set by the analog and discrete

output blocks but, during normal operation, it is reset.
The reset state passes upward in the control structure via
the read-back of the block outputs; it is then passed
upward to the set point and the input transfer values by
each of the block algorithms. This bit will not pass
upward through non-initializable structures. This bit will
be set when:
1) A block is in O/S mode.
2) Any block in a cascade detects a fatal failure in
itself but can still communicate.
3) a block supports fail-safe and is operating in a
logical node that has its fail-safe indicator set
(refer to p16 of Data Owner Structure - Logical Nodes)
4) An output block detects an output hardware failure
5) An indirect write has a "No-Com" bit set.
6) An active agent finds a "No-Com" situation (optional).
When a PID or a Discrete Control block finds this bit set

in its Output word, it will set Man mode and will not pass
the bit any further up the cascade. Other blocks will
provide several options for responding to this bit:
1) Ignore
2) Set Man mode and do not pass any further up the
cascade.
3) Do not change the mode but pass the bit further up the
cascade.
A higher level block in a cascade structure never writes

bit 4 into a transfer location status byte.
It is not intended that a block would automatically set a

"failure" alarm when it receives a value with this bit set
because it can flow through several blocks in a measurement or
cascade structure. The source of the failure should report the
"failure" alarm. However, a receiving cascade block may be
configured to set Man mode (an alarm condition); a block
fetching a value with this bit set may be specifically
configured by the user to report a failure alarm.
5 - "No-Path" = No output path:

Bits 3 and 4 Reset:
All PID algorithms must have a path to the process that
will allow initialization and anti-windup feedback. This
is the status bit that indicates if such a path is possible
within the defined structure of the control system blocks.
For example, if the block structure has violated one of the
rules of a Cascade structure, such as trying to pass an
initializable output through Input #1 of a PID algorithm,
this bit will be set. This bit will not be set by limiting
conditions or by modes that break the path (i.e., Auto or
Man) but it will be set by blocks that are in O/S mode.
It is not intended that a control block would set an alarm

or a notification when this bit is set because it can flow
through several blocks in a cascade structure. The source
of the break in the path, if it was done automatically,
should set an alarm. Note: it is assumed that O/S mode is
always set manually (and thus should not cause an alarm) or
is done as a part of the Start/Restart procedure which
issues a notification.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
This bit is always initialized to "set". It is actively

reset in the status of inputs to blocks that output to
hardware. The reset status is passed up only through
blocks that are not in O/S mode and only through
initializable Cascade structures. Thus it will be reset

--```,``-`-`,,`,,`,`,,`---

94
only if the path to the process is a valid Cascade. The

PID algorithm will go into IMan if this bit is found set in
its output. All other Standard Field Bus algorithms will
operate normally regardless of the value of this bit. In
this "normal" operation, an Output word agent never writes
bit 5 into the Output's destination.
The standard PID algorithm will consider the state of the

No-Path bit while setting the value of status bit 2
(override) in its Output word 0. Specifically, it will set
bit 2 in Output Word 0 unless all of the following
conditions are true:
1) the block is in Auto or a lower priority mode (can not
even be in IMan or LO mode)
2) bit 5 in its Output is already reset (there is a path to
the process)
3) at least one of bits 6 and 7 are reset in this block's
setpoint.
Note that the PID can have a "doubly wound up" state in
which both bits in the Setpoint are set but they are not
set in the Output. Bit 3 does not have to be checked
because the PID algorithm rejects it automatically. Bit
4 does not have to be checked because a failure will
always set the ATW bits.
The intent and result of this procedure is that a Setpoint

or an Output lower in the cascade can be used as the Input
1 of a "valve position" PID controller and it will have its
Bit 2 set (thus blocking the valve position controller PID)
if any of the above tests fail for the original controlling
PID.
The standard Device Control algorithm will also consider

the state of the No-Path bit while setting the value of
status bit 2 (override) in its Output parameter.
Specifically, it will set bit 2 in each of the status bytes
for the parameter "Output" unless all of the following
conditions are true:
1) the block is in Auto or a lower priority mode (can not
even be in IMan or LO mode)
2) bit 5 in the status byte for this particular bit is
already reset (there is a path to the process)
3) the ATW bits for this particular bit, combined with the
ATW bits for the other two bits in the Output, indicate
that the bit can be moved from its current state.
The intent and result of this procedure is that a Setpoint

or an Output lower in the cascade can be used as the Input
of a discrete control scheme that will, through the
process, cause a "correction" to the current state.
Notice that there are two concerns in a Cascade structure:

initialization and anti-windup. This bit is specific to
the initialization part of that concern. Even if this bit
is set to indicate that there is no initialization path, it
--```,``-`-`,,`,,`,`,,`---
is still possible for a Cascade structure to provide

complete anti-windup protection as provided by bits 6 and
7.
Bit 3 Set:
When Bit 3 is set due to LO mode, bit 5 drops its normal
meaning and becomes a direction indicator for the source of
the LO mode in the cascade structure. If bit 5 is set, the
LO mode is being passed up the cascade relative to the
point at which the bits are observed. If bit 5 is reset,
the LO mode is being passed down the cascade.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
95
Bit 4 Set:
When Bit 4 is set due to a failure (not due to O/S mode), a
secondary in a cascade will reset bit 5 in the status bytes
of values in a true cascade structure. In this special
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
case, bit 5 drops its normal meaning (or it drops its
--```,``-`-`,,`,,`,`,,`---
direction indication if LO is set) and becomes a handshake

confirmation for bit 4. Notice that this combination is
strange: failure would normally be assumed to be
accompanied by No-Path.
When the next higher block receives this combination of

information, it recognizes it as a handshake request. If
it is configured to acknowledge a failure, it will
implement its failure actions, then set bit 5 in its Output
word's status byte AND WRITE IT BACK DOWN THE CASCADE.
If the higher block is not a PID nor a Device Control block

and is configured to pass the failure further up the
cascade, it will pass the status of bits 4 and 5 further up
the cascade. It will not allow bit 4 to be reset until it
finds bit 5 set in its own input information. When it does
find bit 5 set, it will set bit 5 in its Output word's
status byte and write it down the cascade.
This procedure provides an end-to-end acknowledgement to

the originator of the failure status that some block that
will take action got the status.
The interaction of bits 3, 4, and 5 in the normal status bytes

is quite complex. Attachment 1 presents and describes a state
diagram of the 8 states of these 3 bits. Attachment 1 to the
paper "Function Block Structure" presents the low-level
functional description that all Standard blocks must use to
manipulate these bits
6 & 7 - "ATW-h (bit 6) and ATW-l (bit 7)" = Anti-windup hi and low:
Whenever automatic control is implemented, consideration must be
given to the range limits of the manipulated variables, both
internal and external to the control system. In addition to the
range limits of a valve, it is possible that an analog control
cascade can be constrained by a number of factors in the control
structure:
1) failure of one or more function blocks, interblock
communication, or output hardware
2) blocking modes in lower function blocks
3) setpoint limits
4) output limits
5) a disconnected cascade path within a block
Bits 6 and 7 in the status byte are designed to indicate that
further movement in a control structure is limited in the
increasing or decreasing direction or in both directions. When
both of the bits for an analog output are set, the block will
typically go into IMan mode. The situation in which both of
these bits are set is generally referred to as "doubly wound
up".
A similar situation can be encountered in the measured

variable's path from the process to a control block. The
measuring device may be at a limit or block output limits
may be active. This condition is particularly important for
display to an operator when the measurement is displayed as an
engineering value instead of a percent of range because it is
more difficult for the operator to remember the limits.
For discrete cascades, these bits can indicate that a Logic,

96
Program, or Timer block is blocking a set or reset command.
These bits are set when there is a limit. Bit 6 indicates a

limit in the upward direction. "Up" is defined as an
algebraically larger value for the analog variable for which the
status bit was calculated or the ability to set a discrete.
Note that a discrete with a current state of set can have its
bit 6 set. This combination means that, if the value is
commanded to reset, it can not then be commanded to set.
Both of these bits are set in all status bytes of values in

blocks that transition into O/S mode. These bits will continue
to be set in all transfer locations all of the time that the
block is in O/S mode.
The handling of these two bits in measured values is very

simple. They will only be used (set) in analog values and will
only be set in OUTPUT values if the OUTPUT value is NOT written
to other blocks. They may be set if the OUTPUT value is read by
other blocks. Within those limits:
+ They are both normally reset if the block is operating.
+ If the block has OUTPUT limits and one of the limits
becomes active, the corresponding bit is set.
+ Some analog algorithms will consider the states of these
bits in their input values for purposes of calculating
the values in their OUTPUTS.
The handling of these bits in output control paths is much more

complex. The blocks that pass the control outputs to the
physical hardware initially determine these bits in their
Setpoint (or Input of Discrete Output blocks or the Output of
Discrete Register blocks). They reflect the physical limits of
the system plus any limits or blocking modes in the output blocks
themselves. If the value can be moved in either direction (or
if the discrete can be set or reset freely), then both bits will
be reset.
The block above the final output reads the value back before
execution, adds its own limits (output and set point) and mode
considerations, and transfers the bits to its own set point and
transfer locations (or to the initialized input bits of a Timer
block).
Both of these bits are continuously set in cascade transfer

locations that are not in control. They are continuously set in
the cascade transfer locations and Setpoint (or initializable
discrete inputs) of blocks in any form of IMan, or Man mode.
They are set in all transfer locations for blocks in any form of
Auto mode.
Note that the analog control blocks must consider direct/reverse

action and negative coefficients in this calculation and
discrete blocks must consider bit state inversion. If the
control structure is built according to the Cascade rules, the
bits will indicate high and low limiting conditions to all
control levels. It is not necessary that the control structure
actually output to the process for this to occur. For example,
if a Math block outputs to a data base item, bit 5 in the status
byte of higher level blocks will be set because a control path
that ends in a data base item can not be initialized. However,
bits 6 and 7 in the inputs to the Math block will still be able
to indicate limiting information to all higher blocks if the
structure in and above the Math block follows the cascade
structure rules.
Many discrete blocks have a 3-bit Setpoint. This Setpoint has a

special restriction: one and only one of the bits can be set at

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
97
the same time. A direct result of this rule is that two of the
bits can limit the third. For example, if two of the bits are
reset and are wound up high, not only is the third bit known to
be set but it is also wound up low! On the other hand, it is
possible for a bit to be set and wound up hi. If one bit was in
this condition and a second in the set was reset and wound up
hi, the third bit is known to be reset but not necessarily wound
up. These "extra" states for bits 6 and 7 must be set by the
algorithm.
Bits 3, 6, and 7 of the status byte of analog RCas and ROut

transfer locations are also used in the handshake between a
secondary block that has an analog Setpoint and its remote
primaries through the RCas and ROut transfer locations. There
is an almost identical procedure that is defined for discrete
Setpoints using bits 5, 6, and 7 of their Setpoint octets. This
procedure is detailed in Attachment 2.
It is not intended that a control block would set an alarm or a

notification when either or both of these bits are set because
they can flow through several blocks in a cascade structure and
can cycle. If the condition is the "doubly wound up state", the
source of the condition, if it was caused automatically, should
set an alarm.
CALCULATION OF BITS:
--```,``-`-`,,`,,`,`,,`---
If the individual function blocks of the Field Bus User Layer are to work
together correctly, the exact meaning of the status bits must be maintained
across Field Bus devices. Therefore, it is required that the logic used to
calculate the status bits follow the logic specified in this Standard.
The values of the status bytes are updated every time a function block
executes. The updating procedure is completely defined in Attachment 1 to the
paper "Function Block Structure". The logic defined there also includes the
updating procedures for the block's mode because the two tasks are related.
There are three blocks that require logic in addition to that shown in the
referenced logic: the Selector, Splitter, and Timer algorithms. The additional
logic is specified as part of the algorithm definitions in a later section of
this Technical Report.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
98
Status Byte - Attach 1 Bit 3-5 State Diagram
Status Byte - Attach. 1 State Diagram - Bits 5,

4, and 3
STATUS BYTE - ATTACHMENT 1

STATE DIAGRAM - BITS 5, 4, AND 3
This Attachment contains the explanation of the state diagram for the eight
states of status bits 5, 4, and 3. The diagram is titled "Status State Diagram",
is labeled "Figure 1", and is attached to this paper.
The diagram shows all eight possible states of the three bits during block
operation. There are a total of 9 states shown on the diagram because the state
of the three bits during Out-of-Service mode duplicates one of the operating
states.

BASIS
OVERVIEW
BOX 0
BOX 1
BOX 2
BOXES 3, 4, 5, AND 6
BOX 7
BOX 8
ALTERNATE IMPLEMENTATIONS
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Figure 1 - Status State Diagram
BASIS:
The states described are those found in the status byte, bits 5, 4, and 3.
For analog blocks, it is the status of the function block's Setpoint. For
discrete control blocks, it is the status of ANY ONE of the three bits in the
Setpoint. For discrete physical output blocks, it is the status of any one of
the Output bits. In all cases in which the Setpoint is described, the exact same
state of the bits will be found in the Cas transfer location if it is being used.
In all cases in which the Setpoint is described in discrete blocks, the exact
same state of the bits will be found in the RCas transfer location if it is being
used. For analog blocks, the LO state is not passed to the Rcas location: bit 3
takes on its alternate definition as is described in Attachment 3.
In the following discussion, the status byte being described will be referred
to simply as "the Setpoint". It will be assumed that the block containing the
status byte being described is using the full power of the status byte. Namely,
it is an "intermediate" block that can pass LO mode from its secondary to its
primary or vice versa. It is assumed to be configured to request failure
acknowledgement from its primary.
The nine states are shown as boxes. In the upper left corner of each box is
an index number that will be used in this explanation. The states of the three
bits (bits 5, 4, and 3) are shown at the top of each box, bit 5 on the left.
Under each bit (usually only the bits that are set) is a one-word description of
the information conveyed by that bit. Under the dashed line in each box is a
description of the state. In those cases where there are two descriptions, the
system is not able to differentiate between the two conditions.
SP-50 User Layer Technical Report Status Bytes - Attach 2

--```,``-`-`,,`,,`,`,,`---

99
The boxes are connected by lines with descriptors and arrows. All of the
lines have a large arrow and some of the lines have a small arrow in the opposite
direction. The large arrow is the direction corresponding to the description.
If the transition is reversible, the small arrow is present and indicates that
the reverse transition path corresponds to the inverse of the description. If
the small arrow is not present, then no transition can take place in the
"reverse" direction.
OVERVIEW:
The status bits will be as shown in box 0 when the function block is first
configured - when it starts up in Out-of-Service mode.
Most control blocks will operate in the state shown in box 3 while blocks
that are not outputting to the process will be in the state shown in box 1.
--```,``-`-`,,`,,`,`,,`---
When operation in state 1 or 3 is interrupted by failures, it will transition

to state 2 or 4 respectively. However, state 4 will use bit 5 in a special
handshaking protocol that requests acknowledgement from a higher block that it
has recognized the failure condition. When that acknowledgement (which has
nothing to do with the human operator) is received, the state transitions to
state 2. When the failure is cleared, operation transitions from state #2 back
to the starting state: 1 or 3. Note that state 0 and 2 have the same bit
configuration.
Note that state 1 specifically does not have a path to the process.
Therefore, that state can never be interrupted by an LO mode.
When operation in state 3 is interrupted by an LO mode, the transition path

is dependent on the source of the LO mode: above or below this point in the
cascade structure. If the LO mode was set above this point, state 3 transitions
to state 5; if below, state 6. When the LO mode clears, either state transitions
back to state 3. It is not clear if bit 5 in state 5 is operating under its
normal definition (No-Path) or under its definition in the handshaking with bit 3
since the effect is the same. The LO mode could not be passed down from above
unless there was a path to the process.
The complexity arises when there is BOTH a failure and an LO mode. These
states, 7 and 8, will be described in detail below.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
BOX 0:
A function block always starts (on "day 1"), in Out-of-Service mode with a
"Null" data base. That data base does not have an algorithm defined so the data
types of the data base are not useful.
When an algorithm type is configured, the logical node will load the "Null"
data base for that algorithm into the function block. The status bytes for the
initial values for that data base will have the bit states shown in box 0.
In this state, the block's requested and actual mode will have their high
order bit (bit 7) set and all other bits reset.
The transitions out of this state are straight forward with two exceptions.
It is possible that a block can transition to an active mode at a time when
communications with the next lower block in the cascade have failed or the lower
block is Out-of-Service. In that case, the transitioning block will not know
that there is actually a configured path to the process; it will transition to
box 2. The effect of this is that the failure lower in the cascade can not be
guaranteed to pass up to a control block that will go into Man mode and cause an

100
alarm before the failure clears. However, since it is assumed that only a human
will cause a block to transition out of O/S mode, the human is already
interacting with the cascade structure.
Secondly, it should be noted that state 0 can never transition to state #8

because state #8 has already received failure acknowledgement. There can be no
acknowledgement already present when state 0 transitions.
BOX 1:
This is the normal state for a Setpoint that is not in a proper cascade
structure. It can rapidly transition in and out of a failure mode: state 1 to
state 2 and back to 1. It can also return to O/S mode (state 0).
BOX 2:
Box 2 is one of three boxes that describe two different possible situations.
First, it can be a failure in a proper cascade structure that has already been
acknowledged. Secondly, it can be a failure in a noncascade structure. There is
no difference between these two states as far as the operation of the function
block is concerned.
Notice that the transition from state 1 to state 2 when a failure occurs can
--```,``-`-`,,`,,`,`,,`---
immediately clear one cycle later and transition back to state 1. However, if
state 3 has a failure, it goes to state 4 and waits for an acknowledgement, then
transitions to state 2 and waits for the failure to clear before returning to
state 3.
State 2 can also transition to state 0 if the block mode is changed to O/S.
The double contingencies will be described below.
BOXES 3, 4, 5, AND 6:
State 3 is the normal state for a Setpoint that is in a proper cascade
structure. During its normal operation, it can be interrupted by a failure, an
LO mode, both of them, or a command to return to O/S mode. For a failure, it
will transition to state 4 and use bit 5 as a handshake indicator to request an
acknowledgement from the block above. The acknowledgement transitions it to
state 2 and the clearing of the failure can then cause a transition back to state
3.
If control is interrupted by an LO mode applied above this point in the

cascade, the state transitions to state 5 and can return directly. If it is
interrupted by an LO mode applied below this point, it transitions to state 6 and
can return directly. Notice that bit 5 is used in state 6 to show that the LO
mode is passing up from below.
The double contingencies will be described below.
The block can also return to O/S mode (state 0).
BOX 7:

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
101
State 7 is entered when there is BOTH a failure and an LO mode. Since LO

mode is set, there must be a configured path to the process. Bit 5 is used for
the failure acknowledgement handshake. There is no indication as to the
direction of the source of the LO mode.
In state 7, bit 5 is acting in its role of requesting an acknowledgement of

the failure from the block above it. That acknowledgement causes a transition to
state 8.
When there is a block between the pure LO mode block and the output block,
that intermediate block has no way of knowing if the LO mode is flowing up or
down the cascade. It will assume that the LO mode is passing down. It will pass
the LO state down during State 7. It will pass it up only on transition to state
#7. However, it will not clear the LO indication above itself. As a result, a
"LO cascade" with 3 or more blocks can not clear its LO status once it is in
state 7. The transition from state 7 to state 4 can only occur automatically if
there are less than 3 blocks in the LO cascade. This is of academic interest
because state #7 should receive its failed acknowledgement within a few cycles
and transition to state #8. The solution to this "lockup" will be described as
part of the description of box #8.
BOX 8:
In state 8, there is both an acknowledged failure and an LO mode. What is
not known is the source of the LO mode: is it coming from above or below this
point in the cascade?
An output block can determine the source quite simply: either its mode (or
OUTLO for a single discrete bit) is causing it (i.e., it is from "below" the
status byte), or it is flowing down from above. The top block in the structure
can also determine the source equally simply. The problem is a block in the
middle of the cascade. In state #8, a block in the middle of a cascade structure
will leave bit 3 set in its transfer locations and in the Setpoint AND it will
write bit 3 when it writes its Output. It will pass the LO status upward only on
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
transition into state #8 but it will not clear the LO state above itself while it
is in state #8.
The result of this is that a cascade will retain the LO mode status during a
failure and reassert it throughout the cascade structure upon recovery. If the
--```,``-`-`,,`,,`,`,,`---
failure clears, state 8 will transition to state #6 automatically. There are

specific traps that have been incorporated in the detailed code, presented in
Attachment 2, to allow the top and bottom members of such a cascade to cause the
cascade to clear. However, if the original source of the LO mode was at the
bottom of the cascade and it clears its LO mode bit while it has a failure, the
LO will be retained in the cascade until the failure clears if there are more
than 2 members of the cascade.
An operator can clear an LO mode even while the failure exists. If the LO
mode is flowing down, the pure LO mode at the top of the structure must be
cleared. That will clear the structure. If the LO mode is passing up the
structure, the pure LO mode or the keylock at the bottom of the structure must be
cleared. That action will not clear the structure.
Assuming there are no other blocks in the LO cascade that are in keylock or
in pure LO mode, there are two methods of now clearing the cascade structure of
the LO mode. First, the Output block or the first control block above the output
can be changed to O/S mode for one execution cycle of the next higher block.
Second, the top block, or the next to the top block, can be placed into pure LO
mode for a cycle time, then returned to the desired mode.

102
ALTERNATE IMPLEMENTATIONS:
At the beginning of this paper, the assumption was made that the block
containing the status byte being described supported the passing of LO mode to
both its primary and secondary. If the block can not pass LO to its primary, the
LO mode indication will never appear in the Setpoint status byte.
If it can not pass it to its secondary, the LO indication will never appear
in the status byte of the Output and bit 3 will never be unmasked while writing
the Output status. Thus, states 5 through 8 will never appear.
Also at the beginning of this paper, the assumption was made that the block
containing the status byte being described supported, and was configured for,
failure acknowledgement by the block's primary. If that is not the case, then
states #4 and #7 will not appear in the Setpoint status because the block will
auto-acknowledge a failure and the states will immediately pass to states #2 or
#8.
If both assumptions are reversed, then the Setpoint status can only assume
states 0 through 3. However, the unacknowledged failure and LO status may appear
in the read-back of the Output; they will be acknowledged (for failure) or
rejected (LO status), resulting in states 0 through 4 in the Output.
The PID block is an example of a block for which both assumptions are
reversed. The block will set LO(x) in itself, but it will not accept the LO
status from the block above or below itself. The PID block will not allow the
failure state to be passed to the block above itself. Therefore, states 0
through 3 may appear in the status of the Setpoint and transfer locations. States
0 through 4 may appear in the status of Output Word 0.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

--```,``-`-`,,`,,`,`,,`---

103
Figure 1 STATUS STATE DIAGRAM

Acknowledge
2 Unfail (With Path)

1, 1, 0
No Path, Failed Unfail (No Path) 1 1, 0 0
Failed No LO Fail No Path
- Path, No LO Normal, No Path
+ Path, Fail Ack. Active Mode Active Mode
+ No Path, No Ack Failed (No Path) (No Path)
Active Mode, LO below, Failed

0
Active Mode, LO Above, Failed 1, 1, 0
No Path, Failed
Active Mode, LO Above O/S Mode.
5 Active
0, 0 1 Mode
3
0, 0 0
LO LO Mode Above
- LO, Passing -Normal, With Path
Fail O/S Active Mode
Mode (LO Below) Fail
0, 1, 1 LO Mode Below
7
HS(Bit 4) Failed LO
Failed Valid Path 6 4
1, 0 1 0, 1 0
+LO Passing Up. Fail -Failed, Valid Path.
+LO Passing down. HS(Bit 3), LO
--LO Passing Up. -*** ACK. Now ***
*** Ack. Now *** *
--```,``-`-`,,`,,`,`,,`---
Unfail (LO **
PassingUp) LO Passing Down
LO Passing Up
Remove LO (Limited)
Note:
Acknowledge * HS changes from showing
8
1, 1 1 Direction of source of
HS(Bit 4), Failed, LO LO (passing up = set) to
-+ LO Passing Up. Showing acknowledgement
LO Mode Above + LO Passing Down. of failed state (unack.
= reset).
** Converse of above
Figure 16: Figure 1 Status State Diagram

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
104
Status Byte - Attach 2 - Remote Handshake

STATUS BYTE - ATTACHMENT 2
REMOTE HANDSHAKE
Bits 3, 6, and 7 of the status byte of analog RCas and ROut transfer
locations are used in the handshake between a secondary block that has an analog
Setpoint and its remote primaries through the RCas and ROut transfer locations.
This handshaking procedure is designed to operate without the remote primary
reading or setting the mode of the secondary. This attachment will describe the
operation of the handshake between a secondary with an analog Setpoint and its
primary. Then, the change that is made for blocks with discrete Setpoints will
be explained.
This discussion will be based on a state diagram for the seven states of
status bits 3, 6, and 7. The diagram is titled "State Transition Diagram
Transfer Location Status Byte", is labeled "Figure 2", and is attached to this
paper.
The diagram illustrates the 7 states of a transfer value status byte with
regard to bits 3 (Special) and bits 6 and 7 (ATW-h and ATW-l). There are only 7
states shown on the diagram because one state of the three bits has no assigned
meaning and should never exist.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
The diagram applies equally well to either the RCas or the ROut transfer
location. The two locations are totally separate: they can simultaneously
interface with two different remote masters, and they each have their own mode
bits (RCas is bit 1 of the mode byte, ROut is bit 0). The following description
will assume that the RCas transfer location is the one illustrated and that the
secondary block (the owner of the transfer location) is initially in Auto mode
while the remote primary is initially in IMan(Auto).
After the secondary block's start-up initialization, bit j In that same

status byte, the secondary will indicate that the transfer locations are doubly
wound up by setting bits 6 and 7. This is shown as State 1 in the diagram. In
this state, the remote primary will stay in IMan(Auto) mode and can only
initialize. The secondary in our example is in Auto.
At some time, the mode of the secondary is changed to Auto(RCas), presumably

by the operator. After the next execution of the secondary block, State 2 will
exist. Here, bit 3 is still set, indicating that the cascade is not yet made up.
However, the primary is invited to execute the handshake because bit 6 is reset.
When the primary finds bit 3 set but bit 6 reset and it is ready to go into
control, it will respond by writing to the RCas transfer location, resetting bit
7. This generates State 3. If it reads its transfer location again before the
secondary executes, it will find bit 3 set, indicating that the cascade is not
--```,``-`-`,,`,,`,`,,`---
made up but it will not have to write the output again because the pattern of
state 3 uniquely indicates it is waiting for the secondary to execute.
Whenever the secondary has a condition that would allow the remote
connection, it monitors the three bits in the transfer location. If it finds bit
3 set and bits 6 and 7 reset, it will know that the remote is ready for control.
At that point, the secondary will clear the mode bits that are higher priority
than RCas, leaving itself in RCas mode (this narrative assumes that ROut did not
get set in the meantime). It then uses the value in the transfer location,
resets bit 3, and adjusts bits 6 and 7 to reflect the current windup state. This
generates one of the States 4, 5, or 6. The remote control block will know that
it is in control because bit 3 is now reset.
State 7 shows the bit status for the condition in which the cascade is forced
into initialization. Here the secondary (the owner of this transfer location)
would be in IMan(RCas) mode while the primary would be in IMan(Auto). When the

105
secondary executes and initialization is not forced, the condition will revert to
state 4, 5, or 6.
If the mode of the secondary is changed, for example to Auto, the cascade is
broken by the secondary by setting bits 3, 6, and 7. This returns the State
Diagram to State 1.
The Cas transfer location does not need to execute the handshake because Cas
is the first priority below Auto. If a Cas structure is broken, the secondary
block can stay in Cas with a frozen set point just as well as reverting to Auto.
If a RCas or ROut structure is broken, it is necessary that the connection count
out and the mode revert to a higher priority mode. Because of this reverting, it
is necessary that the handshake exist to rebuild the structure automatically.
The above method of handshaking precludes the passage of the LO mode

information up the Remote cascade connection. For secondaries with analog
setpoints, that restriction is acceptable. For secondaries with discrete
setpoints, the same restriction is unacceptable and, in fact, unnecessary. For
blocks with discrete setpoints, there are usually three values in the setpoint
plus the three status bytes for the three discrete values. The other five bits
in the setpoint value are free. Therefore, the handshaking described above will
be done using bits 5-7 of the RCas and ROut transfer value itself. That will
leave bits 3 and 4 free in the value in case any extensions to the Standard
algorithms need to use those bits as part of the discrete setpoint. As a result,
bit 3 in the status byte of each discrete bit in the RCas and ROut transfer
locations will be left free to convey the LO mode information.
The handshake for discrete values will work exactly the same as described
above for analog values except that:
a) the "Remote" bit will be in bit 5 of the setpoint value.
b) the ATW-h bit will be in bit 6 of the setpoint value.
c) the ATW-l bit will be in bit 7 of the setpoint value.
d) bit 3 in the status byte of each bit of the setpoint is left
free to carry the LO mode information.
In summary, any remote master can determine the status of its cascade
connection by reading the transfer value and its status byte(s). It never has to
read the mode of the secondary.
SP-50 User Layer Technical Report Agent - Attach 1 105

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
106
Block Initialize "Remote"

Mode Bit Remote
Set Executes
1 2 3
Bit 3 = 1 Bit 3 = 1 Bit 3 = 1
Bit 6 = 1 Bit 6 = 0 Bit 6 = 0
Bit 7 = 1 Bit 7 = 1 Bit 7= 0
Secondary Remote
1 = No Cascade Executes Executes
2 =Cascade Invited
3 = Remote Accepts
4 = Cascade - Wound Up Hi Secondary
5 = Cascade - OK Executes
6 =Cascade -Wound Up Lo
7= Cascade- Initialize
Cascade Initialization Wound-Up Hi
Wound-Up Lo
OK
7 6 5 4
Bit 3 = 0 Bit 3 = 0 Bit 3 = 0 Bit 3 = 0
Bit 6 = 1 Bit 6 = 0 Bit 6 = 0 Bit 6 = 1
Bit 7 = 1 Bit 7 = 1 Bit 7 = 0 Bit 7 = 0
Figure 17: State Transition Diagram

--```,``-`-`,,`,,`,`,,`---
SP-50 User Layer Technical Report Agent - Attach 1 106

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
107
Agents
The standard algorithms that will operate in Field Bus blocks will have a
defined data base that is accessible on-node and over the Field Bus. When blocks
need to communicate with each other, however, they need the mechanism to
accomplish the communication. In addition, the Cascade structures that are
established between blocks on Field Bus will require a tight handshaking protocol
between them to assure the integrity of the structure.
A standard algorithm will usually be defined to have input and output

"connections" to the block. Most connections will have an "agent". An agent
can, at the option of the user if the device supports the function, be used to
accomplish the action of reading or writing to another block (an "active" agent)
or it can be used to provide the passive end of the data transfer (an "inactive"
agent). Such an agent is implied by each input and output arrow shown on an
algorithm description drawing. Of course, an agent type is provided for doing
simple data base accesses or to declare itself "null". The following is a
description of the general operation of these agents.
This paper has the following sections:

APPLICATIONS
AGENT CLASSES
OVERVIEW OF AGENT'S DATA BASE ELEMENTS
AGENT TYPE CODES
DESCRIPTION OF EACH AGENT TYPE
Null
Immediate
Writeable
Active
REQUIRED AGENT TYPES
INPUT #0 AGENT CONTROL OF TRANSFER LOCATIONS
ACTIVE AGENT POINTER FORMAT - ANALOG
ACTIVE AGENT POINTER FORMAT - DISCRETE
GENERATING A MISSING STATUS BYTE
ACTIVE AGENT LOGIC - DISCRETE (reference to Attachment)
AGENT TIMING AND DETAILS
Agent Service For Prefetch At Prefetch Time
Agent Service For Prefetch At Start Of Block Execution
Agent Service As Part Of Block Execution (Start Of Block)
Agent Service As Part of Block Execution (End Of Block)
Attachment 1 - Discrete Active Agent Logic
Figure 1 - Discrete Active Agent Logic
APPLICATIONS:
For each of the defined input and output connections to a Standard algorithm,
except Input 0, there will normally be a standard agent. Although the algorithm
may specify restrictions on the capabilities of the agent for a particular
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
connection, they will all have the same form. The Input 0 connection is special
because it is sometimes the one that is associated with, and controlled by, the
mode. This structure is defined separately. However, buried within that
structure is a standard agent!
Some of the standard discrete blocks need a large number of input bits, too
many to allow them to be fetched independently. For those blocks, bit strings up
to 16 bits long can be fetched with one agent per string and placed into
"transfer" registers. This can be done either in the block itself or by the
local logical node. Then the ultimate users select bits from the transfer
registers. The string connection is configured using a standard agent while the
selection of individual bits is referred to as being a "bit pointer". The bit
pointers are defined in the paper "Standard Block Functions". This is not to
imply that a standard block agent can not access a single bit; the format for
SP-50 User Layer Technical Report Agents

--```,``-`-`,,`,,`,`,,`---

108
defining the access of a single bit by a block agent will be defined explicitly
below.
AGENT CLASSES:
There are four classes of agent types:
- Null
- Immediate
- Writeable
- Active
The Null agent is simply a way for the user of the algorithm to indicate that
this particular defined connection is not to be used. For example, the third
input in the Math block may simply not be needed. The "Null" agent essentially
says: "I and my associated connection do not exist".
The Immediate agent is a way to provide a data base item but to block writes
to it. For example, the above Math block may need to have Input #2 supply it
with a value of 40%. Now and forever. The immediate agent allows the example
"40" to be located in the static data base. Alternately, the Output of a block
may be a value that is simply calculated and left in the data base. It is
perfectly valid for any other block or node to read the value but writing to that
location has no meaning and could cause confusion. The immediate agent allows
read access to the value but blocks direct changes to it from outside of the
owning block except for outputs in manual mode.
There are two kinds of "Writeable" agents; they both provide a connection
(passive) for a communication from another structure in the system. They expect
to receive a write. The simple writeable agent simply declares its presence.
The other form actually keeps a count of the number of cycles since the last
write and can "count out" the connection.
Finally, the powerful type of agent, the active agent. This agent type will
have a "pointer" to a data base element or a node's physical input or output and
will read or write from that location each time the block executes. An agent can
read from any tag parameter in the lower half of the parameter number range that
has a suitable data type. An agent can only write from an Output Word and can
not write to an Output Word.
If the pointer leads to an off-logical-node data item, the value read will be
acquired before the block executes. If the action is an off-logical-node write,
the value will be placed in the node's own communication buffers before the block
execution is finished. One tricky part of the definition of the agents is that a
write agent also causes a read-back of its value before the block executes. This
allows the block to receive the feedback status information and confirm the
handshake with its partner during the block execution.
On-logical-node communication by active agents is done during block execution

because that communication can be done quickly by direct memory access, not
through the Field bus.
OVERVIEW OF AGENT'S DATA BASE ELEMENTS:

--```,``-`-`,,`,,`,`,,`---
The data base for each agent consists of a portion in the static data base
and a portion in the dynamic data base. A change to the static data base portion
will require that the static data base revision number be incremented.
The static data base portion includes an entry that defines the type of
"Agent". The rest of the static data base portion depends on that configured
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
agent type code. The complete list of static data base items is:
+ AGENT_TYPE_code
+ STATIC_VALUE

109
+ Pointer:
@ POINT_TAG_Name
@ POINT_PARAMeter
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
The dynamic data base portion consists of:
+ Value
+ Revision Number (REV_NUM)
+ No-Communication_Counter (NO_COM)
The first entry in the data base of the "agent" defines the type of agent.
This data element will be an 8-bit unsigned integer value but it can be
considered an enumerated variable by human interfaces. It is located in the
static data base and any change to it will increment the data base revision
number. The low-order bit of many of the agent types will indicate how the agent
will respond to a No-Communication situation - should it just set the No-Com and
Not-from-process status bits or should it set all of No-Com, Bad, Not-from-
process, and Failed?
Two types of agents will need a single value stored in the static data base.
An immediate input agent will use this location to store the actual value
(without status information). The value will be transferred from the static data
base to the dynamic value every block execution. The data type will be the same
as the type of the parameter. The status byte for the value will be generated by
the agent (see "Generating A Missing Status Byte" below). Note that the value of
an immediate Output agent is not stored in the static data base.
The Off-Field Bus agent to be defined below will need a location to store the
identification of the Field Bus to which its communications will be directed.
An active agent needs to know where to access its data. The "pointer" is
simply a data structure that will identify the path name of the piece of data to
which the agent connects. These two data items are also static. The first data
element, the POINT_TAG_Name, will be an ASCII string. The actual value stored
will, in fact, be the original ASCII string entered by the user. The
communication services will build its communication links using the ASCII name.
If the name of the target location or the name in the agent is ever changed, the
communication links will be broken and have to be reestablished using the new
name.
The POINT_PARAMeter will be either:

1) one 16-bit unsigned integer (high bit reset) or
--```,``-`-`,,`,,`,`,,`---
2) a complex structure defined below.
Two particular types of agents will be defined below that support off-Field
Bus pointers. The following requirements on the STATIC_VALUE will apply only to
standard Field Bus devices that support those types of agents:
Editor's Note: the following three paragraphs assume that the

Field Bus identification is undefined by the Standard but can be described in 32
bits. This will have to be brought into conformance with the work of the other
layers of the Standard.
The STATIC_VALUE data location will be a minimum of 32 bits in

length. If the user configures any type of agent other than the
off-Field Bus agents, the STATIC_VALUE will be used as described above.
The location will always be initialized to all reset bits. Other than
initialization and the use of the location as described above, the Field
Device will not use or change the location but will provide full static
memory services.
If the agent is of the Off-Field Bus type, higher level devices

will be free to use the STATIC_VALUE data location as an indicator of
the particular Field Bus on which the remote tag is to be found. Only
the low order 32 bits of the location will be used and the data type is,
in this case, totally independent of the data type of the agent's
parameter.

110
A higher level device that has not been (can not be) configured to
correctly interpret the data type of this location in this situation
should display the value as BOTH a 4 character (8 bits/character) ASCII
string (right-most 32 bits, right-most character in the lowest order
bits) AND as an 8 character hexadecimal number (i.e., 12345678H) based
on an interpretation of the 32 bits as a 32-bit unsigned integer.
It is important to note that there are two reasons why an agent may be only
partially configured. First, as with all nodes and blocks, the configuration
data is written one parameter at a time and in any order. There is no such thing
as "configuration time" or "download time" from the point of view of the field
device. Second, the handling of the Isolation Timer specifically allows, and
looks for, the configuration of a block point (counted) agent type with a Null
point (see the paper on "Modes", page 15).
The first item in the dynamic data base of an agent is the current actual
data value. The "value" memory location is the actual data item appearing in the
algorithm definition - not a value dedicated to the agent function. The
algorithm definition must provide a data base element for "value"; it can not be
a temporary variable.
Each of the inputs and outputs of an algorithm will have status information.
When a data item is passed between blocks using agents, it's status byte will
usually be carried with it. In addition, an active agent can generate a status
byte for a value that is read without a status byte, for example, a value from
the general data base. There are two forms of this status byte defined: analog
and discrete. The two forms are defined with a common structure and are, in
fact, almost exactly the same.
The two low order bits in the status byte contain information about the
quality of the data. The third bit shows the origin of the data: does the data
element have "roots" in data that has a process connection? The 5 high order
bits describe information about the outputting of data such as antiwindup
information. The status bytes are critical to the correct operation of the
CASCADE structures defined in Field Bus, especially for the ID algorithm. The
status byte is fully defined separately. The exact form of the parameters that
make up the "value" are defined in the paper "Function Block Structure".
One form of agent used for Outputs will keep a revision number that is
incremented every time its value is updated. This revision number can be read
from Field Bus. It is an 8-bit unsigned integer. Four active agent types
support the acquisition of this revision number as part of their structure. Only
the Math and PID algorithms, among the standard algorithms, are users of this
feature. The Math algorithm passes the sum of the revision numbers fetched for
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
its inputs to its Output. In the PID algorithm, the revision number is compared
to the previous revision number and, if different, the PID control proceeds. If
it is not different, the PID algorithm does not proceed but it counts the number
of cycles of continuous "no change" so that corrections can be made to its tuning
--```,``-`-`,,`,,`,`,,`---
constants when a new value finally does appear. The latest value of the
revision number is stored in the agent's "Revision_Number".
There will be three rules associated with the operation of the revision
number. First, the value stored in that location will be initialized to zero
when any function block's algorithm number is changed. Second, the value stored
in that location will be reset to zero any time a function block is set to O/S.
Third, any algorithm that generates the revision number for its Output will use a
procedure for calculating the revision number that will skip the value zero
during the normal progression of the value.
Finally, the system design provides for the ability to survive through a
short term loss of communication. Although the Link Layer protocol provides for
retries in the case of unsuccessful communications, those retries would come over
a very short period of real time. Many types of interference in an industrial
environment may be a short burst in real time but still block communication for
multiple Link Layer attempts. The No-Com counter allows an active agent to
remain over three block cycle times before it's connection is considered lost.
Because of the existence of the No-Com counter mechanism, the time allocated for

111
the block prefetch does not allow time for Link Layer retries. The types of
agents that can count-out will increment their counter at every block execution
and reset the counter every time the communication is successful. If the counter
exceeds a defined limit, the status of the value will be marked "No-Com" in the
value's status byte. The counter is not accessible over Field Bus.
AGENT TYPE CODES:

The Standard defines a set of "type" codes for the agents. The code number
is constructed according to certain rules designed to simplify the automatic
interpretation of the codes. The 4 classes of agents are a major part of the
code structure along with the location of the target of the pointer for active
agents.
One additional piece of coded information pertains to the reaction of the

agent to No-Com conditions. All active agents (except physical I/O agents) can
encounter a "No-Com" status situation, either through an immediate communication
problem on Field Bus or by accessing a parameter that, in turn, had a failure.
There will be provision for two versions of most active agents - to set or not to
set "Bad" when there is a "No-Com" status. The even codes will not set "Bad".
This rule is implemented in a way that maintains consistency across the numbering
of the inactive agents.
Although most references to this option will, as above, express it as

"Bad on No-Com", there are three other status bits that are involved. First, Not-
from-Process is automatically set whenever No-Com is set. Second, Failed is set,
and No-Path is reset, along with the setting of Bad when "Bad on No-Com" is
activated. Note that the combination of Failed = set and No-Path = reset is the
activation of the handshake described in Attachment 1 to the paper "Status Byte".
When considering these rules in the context of non-active agents and transfer
locations, there is a difference between "generating" and "reacting to" a No-Com
situation. For example, a value with its No-Com set may be written into an
inactive agent. The agent will "react" to that situation. On the other hand, an
inactive agent may be able to detect that no value has been written to it for
some period of time - it sets its own No-Com status. In this case, it "generated"
the No-Com situation. The low order bit of the code pertains to reacting to, not
generating, the No-Com situation.
The agent type codes are:
Agent Code Number

Class Agent Type Binary Decimal
--------- ------------------------------ -------- ---------
Null Normal 00000000 0
Immediate Normal 00000010 2
With Revision Number 00000100 4
With Status Reset 00000110 6
Writeable Simple 00001001 9
Required 0000101x 10 & 11
Active On-Block * 0001000x 16 & 17
On-Block Counted 0001001x 18 & 19
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Physical Node I/O @ 00010100 20
On-Node * 0011000x 48 & 49
On-Node with Revision Number * 0011001x 50 & 51
Off Log. N, On Phy. Node 0101000x 80 & 81
Off Log. N, On Phy. Node
Revision Number 0101001x 82 & 83
Off-Node, on Field Bus 1001000x 144 & 145
Off-Node, on Field Bus with
Off-Node, off Field Bus 1001010x 148 & 149
Off-Node, off Field Bus, with

--```,``-`-`,,`,,`,`,,`---

112
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
center table
Note: x = either a 0 or a 1 depending on the desired action
relative to the setting of Bad on No-Com.
* = If the remote parameter has a status byte with bit 0
set, then the agent's No-Com option will be invoked.
If the agent can not access the parameter, the local
value will be marked "Bad" unconditionally.
@ = see above for special handling of this agent type
during access failure.
The above code numbers for the types of agents are based on the following
system:
bit 0 = 1 if "No Com." will set "Bad" and "Fail" (note the
handshake, using status bit 5, defined for CASCADE
structures in the paper on Status Bytes).
1 & 2 = subtype codes
3 = set if writeable
4 = set if an active agent
5 = set if the agent is pointed to an off-block but on
logical node parameter
6 = set if the agent is pointed to an Off-Logical Node
but On-Physical node parameter.
7 = set if the agent is pointed to an off physical
node parameter. Note that "off physical node"
includes both parameters on the same field bus and
parameters not addressable on the immediate Field
Bus as distinguished by the sub-code.
center list
DESCRIPTION OF EACH AGENT TYPE:

The following is a detailed description of each agent type and important
notes for some of the types:
- Null:
+ Only one instance: Normal
@ The connection to the block is inactive.
@ Frequently used as the default agent type.
@ Might be used for the third input to the Math block or some
of the discrete transfer words in discrete blocks.
- Immediate:
+ Normal for Inputs:
@ The agent Value is copied from the STATIC_VALUE at each
execution of the block.
@ The Value_Status byte is generated using the same rules as
are described later for generating a missing status byte.
@ The Value can not be written by any method other than the
agent.
+ Normal for an Output Word:
@ The block calculates the new value and stores it and its
status in the parameter's value.
@ The Value can not be written from outside of the owning
block unless the owning block is in Man mode.
@ Typically used for the Output of blocks that do not need to
write their Output values to other locations.
+ Normal with Revision Number for an Output Word:
@ The block calculates the new value and stores it and its
status in the parameter's value.
@ An associated "revision number" is incremented every time
a new Output is calculated.
@ The Value can not be written from outside of the owning
block unless the owning block is in Man mode.
@ Typically used for the Output of blocks that do not need to
write their Output values to other locations but have to
indicate that the Output value has been updated.
+ Immediate with Status Reset:

--```,``-`-`,,`,,`,`,,`---

113
@ For output words only.

@ This agent is the same as Immediate except that it
automatically resets status bits 2-7 in the output's status
byte.
@ This is provided to allow the configuration of demonstration
and simulation control cascades that do not have physical
outputs. By resetting the status bits, the cascade can
operate despite the fact that there is no "process input"
and no "path to the process".
- Writeable:
+ Can be used only on inputs.
+ Simple Writeable
@ One of the two forms of agents that can be used on Inputs #1
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
and #2 in the Selector algorithm to make a complete CASCADE
structure into those block connections
@ Is the general work-horse used to receive data for
non-initialized inputs.
+ Required Writeable
@ The same as Writeable but the agent indexes the No-Com
counter every cycle. Writes to the agent's value cause the
No-Com counter to be reset. The agent changes the
Value_Status to "No-Com" if the No-Com counter indexes past
a fixed limit; a subsequent write would cause the No-Com
counter to be reset and could deliver a "good" value. The
fixed limit is 32 cycles.
--```,``-`-`,,`,,`,`,,`---
@ One of the two forms of agents that can be used on Inputs #1

and #2 in the Selector algorithm to make a complete CASCADE
structure into those block connections
- Active:
+ Block Agent
@ The value can be found (or is to be stored) in the block's
own data base at the parameter (and the bit position) given.
@ If the value can not be accessed, the "Bad" status will be
set unconditionally in the local parameter, a configuration
alarm will be set, and the block will be set in O/S mode.
@ If the remote value has a status byte and bit 0 in that
status byte is set, the agent's No-Com option will be
obeyed.
@ Is the general work-horse used to fetch on-block data for
@ Is the agent normally used to connect the CAS input to Input
0 (Note: this structure does NOT count out the connection
if the CAS value is not updated.)
@ The Value can not be written from outside of the local block
unless the agent is serving an Output Word and the local
block is in Man mode.
+ Block Agent (Counted)
@ Can be used only on inputs.
@ This agent type can point to any block parameter that has
status information.
obeyed.
@ If the remote value has its options set to mark the value
Bad on No-Com, then the imported value will already have
the Bad and Failed status values set and they can not be
reset. Note that the transfer locations and the discrete
parameter "Output" ALWAYS set Bad on No-Com.
@ This agent is specifically designed to be used for Input 0
to make the CAS connection "count out" just like the ROut
and the RCas connections do. When it sheds, it will start
the Logical Node's Isolation timer. However, it DOES NOT
shed to Auto. It can be used by other Inputs to connect to
any of the CASCADE transfer locations but it will not pass

114
initialization nor antiwindup from any Input other than 0.

@ If configured as the agent type for Input #0 but given a
null pointer, it will serve as an indicator to the logic
to set the Isolation timer when RCas or ROut count out.
@ The Value can not be written from outside of the local
block.
+ Logical Node Agent
@ The value can be found (or is to be stored) in a different
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
block in the same logical node at the parameter (and the bit
position) given.
--```,``-`-`,,`,,`,`,,`---
obeyed.
@ Is the general work-horse used to fetch on-node data for
@ Is the general work-horse used to store on-node Outputs in a
CASCADE structure.
unless the agent is serving an Output Word and the local
+ Logical Node Agent with Revision Number
@ Operates the same as the Node Agent except that it is used
only for inputs.
obeyed.
@ Retrieves, and presents to the algorithm, the revision
number of the parameter as well as the parameter. If the
parameter has no revision number, the block will be put in
O/S mode and the configuration alarm will be set.
block.
+ Physical Node Agent I/O
@ Identifies a physical node hardware connection point.
@ An agent for a hardware connection will only use the
"Parameter" variable (simply an integer).
@ Two system design rules result in this agent being simple.
First, all standard input and output blocks are defined such
that they interface to 1 and only 1 type of physical
hardware. Thus, for example, the AI algorithm can only
interface to serial input hardware. Second, the instances
of a particular type of hardware must be identified by a
zero based index number. Thus, a hardware agent need only
identify the index.
See the separate discussion of "Data Owner Structure -

Hardware" for the definitions of hardware connection types.
@ If the physical node does not have a physical point
corresponding to the index (and implied type) of the agent,
then a configuration alarm will be set and the block will be
set to O/S mode.
+ Off-Logical-Node, On-Physical Node Agent
@ the value can be found (or is to be written) in another
logical node in this physical node at the tag and parameter
(and bit position) given.
@ Is the general work-horse used to fetch off-logical node but
on physical node data for non-initialized inputs.
@ Is the general work-horse used to store off-logical node but
on physical node Outputs in a CASCADE structure.
@ Will optionally set the "Bad" status bit if "No Com." status
bit is set.

115
unless:
1) the agent is serving an Output Word and the local
2) the agent is serving a node discrete register. Then,
on-logical node output agents and bit pointers can
write to it.
+ Off-Logical-Node Agent with Revision Number
@ Operates the same as the Off-Logical Node but On-Physical
node agent except that it is used only for inputs.
block.
+ Off-Physical-Node Agent
@ the value can be found (or is to be written) on the local
field bus at the tag and parameter (and bit position) given.
@ This form can only exist in a Logical node that "supports
off-physical node agents".
@ Is the general work-horse used to fetch off-physical node
data for non-initialized inputs.
@ Is the general work-horse used to store off-physical node
Outputs in a CASCADE structure.
@ It is assumed but not required that the agent will identify
a peer device on the field bus, not a "master" device.
bit is set.
unless:
on-node output agents and bit pointers can write to
it.
+ Off-Physical-Node Agent with Revision Number
@ Operates the same as the Off-Physical Node Agent except that
it is used only for inputs.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
block.
+ Off-Field Bus Agent
@ the value can be found (or is to be written) at the tag and
parameter (and bit position) given but the tag is unknown
to the local Field Bus.
@ This form must exist, and can only exist, in a
physical node that "is part of a complex device". See the
physical node options bit string in the paper "Data Owner
Structure - Hardware".
@ Is the general work-horse used to fetch off-Field Bus data
for voted inputs (two types of algorithms defined in later
papers).
@ It is assumed but not required that the point will identify
a peer device on another field bus, not a "master" device.
bit is set.
unless:
on-node output agents and bit pointers can write to
it.

--```,``-`-`,,`,,`,`,,`---

116
+ Off-Field Bus Agent with Revision Number

@ Operates the same as the Off-Field Bus Agent except that it
is used only for inputs.
@ This form can only exist in a physical node that "is part of
a complex device". See the physical node options bit
string in the paper "Data Owner Structure - Hardware". If a
physical node in a complex device has a Standard function
block that supports revision numbers, then it must support
this agent type.
block.
REQUIRED AGENT TYPES:

There are a number of different types of agents. A specific logical node
will frequently have no need for all of the types, either inherently or in the
judgment of the manufacturer. There are a number of explicit and implicit
methods for indicating which agents are not supported that will be defined here.
There are three bits in the logical node's non-time-critical bit string (see
the paper "Data Owner Structure - Logical Nodes", page 26) that specify which
agents are supported/not supported in a logical node:
- logical node supports active agents.
- logical node supports off-physical node agents.
- logical node supports off-Field Bus agents.
There are certain types of agents that can not be used on Output Words - they
will not be supported if the logical node does not support any function blocks
that have non-hardware Input Word agents AND does not support logical node
variables. They will, of course, not be used on Output Words even if they are
supported in the logical node. They are:
- Simple Writeable
- Required Writeable
- Active Block Agent (counted)
- Active Logical Node Agent with Revision Number
- Active Off-Logical-Node Agent with Revision Number
- Active Off-Physical-Node Agent with Revision Number
- Active Off-Field Bus Agent with Revision Number
The "Immediate with Status Reset" type of agent is restricted to use on

Output Words - it will not be supported if the logical node does not support any
function blocks that have non-hardware Output agents and will never be used on
Input Words nor Logical Node variables even if the logical node supports them.
The "Physical Node I/O" active agent is only used to connect to physical
hardware. If a logical node does not support any function blocks that can
connect to hardware, then this type of agent will not be supported. It will
never be used on a Logical Node variable nor on a block agent that is not
specifically identified as a physical connection point.
There are three bits in the logical node's time-critical options bit string
(see the paper "Data Owner Structure - Logical Nodes", page 25) that specify
which logical node variables are supported in a logical node. These variables
each will have an agent. These agents will never support, and therefore do not
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
require a Logical Node to support, "Immediate with Status Reset", Active "On-
Block", Active "On-Block Counted", nor "Physical Node
I/O" types of agents.
There are a number of agent types designed to handle revision numbers.

However, there are relatively few Standard function blocks that can handle them!

--```,``-`-`,,`,,`,`,,`---

117
Therefore, the following rule will be used to determine if a particular logical

node's agents will support revision numbers. It is based on the concept that
there are four types of Standard function blocks relative to revision numbers:
1) blocks that generate revision numbers - Analog Input, Composition,
Serial Communication, and Tank Gauge.
2) blocks that convey revision numbers from their inputs to their
Outputs - Math and Selector.
3) blocks that terminate revision number paths - PID and On/Off
4) blocks that do not handle revision numbers (all other Standard
blocks).
A logical node that does not have any function blocks in classes 1-3 will not
support revision numbers in any of its agents.
A logical node that does not have any function blocks in classes 2 or 3 will
not support active agents that have revision numbers but will support the
"Immediate with Revision Number" type. Likewise, a logical node that does not
have any function blocks in class 1 will not support the "Immediate with Revision
Number" type but will support the active agents with revision numbers if they
have not been eliminated by one of the above rules.
All agent types that have NOT BEEN ELIMINATED by one of the above rules WILL
BE SUPPORTED in a Standard logical node, for BOTH the logical node variables and
the function block I/O words.
INPUT #0 AGENT CONTROL OF TRANSFER LOCATIONS:

As defined in the previous section, the agent type will control the reaction
to a communications count out and will control the "Bad on No-Com" option. When
a cascade structure is included in a function block, there are similar options
--```,``-`-`,,`,,`,`,,`---
that are needed for the transfer locations. These options are controlled by the
agent type configured for Input #0. All three transfer locations will be
controlled by the configuration of the Input #0 agent.
Since Input #0 will be useful for the transfer locations as well as for Input
#0, there will be situations in which Input #0 has an agent type defined but,
since there is no need for the Cas input, there is no other information. This
must be allowed. In this situation, the Cas mode can simply be marked "not
permitted" to avoid any problems.
If the Input #0 agent is of the type "required writeable" or "block

(counted)", then the mode change logic will know that the Logical Node
Isolation_Timer is to be set when an active transfer location counts out.
If the Input #0 agent has its low order bit set, then the mode change logic
will know that, when a transfer location mode sheds due to a count out, the shed
mode should be made permanent by writing it to the requested mode.
ACTIVE AGENT POINTER FORMAT - ANALOG:

The "Pointer" structure in the data base will hold the source data that
corresponds to the form:
Tag.Parameter
where "Tag" is as defined in the paper "Data Owner Structure - Hardware", page
2. The variable "Parameter" will be an integer value; its value is <= 32,767.
An active agent for a parameter with an analog data type will convert the
value of the addressed parameter to the data type of the agent's own parameter
(and vice. versa for writes). The block algorithm will define which one of 2
analog data types will be supported for the agent's own value: 16 bit signed
integer or 32 bit floating point.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
118
The data type of the addressed parameter can be a 16 bit integer (signed or
unsigned), a 32 bit floating point, an enumeration, or a bit string. The active
agent will convert between 16 bit integer and 32 bit floating point as necessary.
It will interpret an enumeration or a bit string as a positive integer. The
following table indicates the error handling:
1) For any read operation (for both Input and Output Word local
parameters):
If the conversion can not be made because the remote value is too
large, the local parameter value will be left unaltered but its
status will still be copied. In addition, the local status byte
will be forced to "Bad" and "Not-from-process" (independent of the
No-Com option in the agent type). This action will cause a "Bad"
Input (Output) Word" alarm in the local block.
2) For a write operation:
If the conversion can not be made because the local value is too
large or because it is negative, the local and remote parameter
values will be left unaltered. The status byte of the local
parameter will be used as the basis for a masked write message to
the status byte of the remote variable. However, bits 1 ("Bad")
and 2 ("Not-from-process") will be set in the status byte in the
message (not in the local status byte) before the write message is
sent. If the agent is configured to mark the local value "Bad" for
"No-Com", then the local status byte will be set to "Bad" (NOT to
"No-Com"). In addition, the configuration alarm for the local
block will be set and will not be turned off even if the condition
recovers. The alarm will only be cleared when the block is set to
O/S mode.
ACTIVE AGENT POINTER FORMAT - DISCRETE:

Some of the standard algorithms will need to point to a single discrete value
and its status byte (if present). It is necessary that the agent be able to
access any one of many different parameters and types of parameters for that
information, including selecting a single bit in a bit string or even a single
bit in the status byte of a value.
On the other hand, most of the discrete algorithms have 16 bit "transfer
registers" defined for their block I/O. The agents for these words will need to
be able to point to 16 bit binary values that may have a status byte for each
bit. Note that within the discrete blocks, the "bit" pointers defined in the
paper "Standard Block Functions" can access the individual bits.
In order to support this range of services, an agent for a discrete parameter

will be structured using one of two forms.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Discrete Agent - Type 0:

The agents for the 16 bit transfer registers are the first type of discrete
agent. They will point to a bit string. If the remote data structure is longer
than the agent's parameter, the value data beyond the end of the local parameter
will be ignored but the status values will be aligned if present. If the remote
data structure is shorter than the agent's parameter, the rest of the local
parameter will be left unaltered (note that the total local parameter will be
reset and its status byte(s) set to "Bad", "Not-From-Process", and "No-path-to-
the-process" status bytes at block initialization).
A type 0 active agent will have the same form as an analog agent:
Tag.Parameter
where "Parameter" is an integer that defines the parameter's code number
(with a value <= 32,767 and the high order bit always reset).

--```,``-`-`,,`,,`,`,,`---

119
Discrete Agent - Type 1:

The second type of discrete agent is also of the form:
Tag.Parameter
However, in this form, the data base item "Parameter" is compounded. The
structure is:
Bits 0-9 = Parameter code number (integer <= 1023)
A-D = Bit index indicating one of the low 16 bits of
"Parameter"
E = Invert action of the Agent: Set = Invert all value
bits and exchange status bits 6 & 7.
F = Set.
This is the form that would be used to fetch a single discrete value from a
parameter that is a bit string. Note that the state of bit F differentiates the
two types of agents.
The option to i
nvert the value bits requires, as shown above, that the two wind-up bits be
exchanged in order to retain their meaning. If this type of agent is used for an
Output word, the agent will invert the value before it is written, again
exchanging status bits 6 and 7.
GENERATING A MISSING STATUS BYTE:

At times it will be necessary to structure a block to input or
output data directly to a data base element rather than through
agent-to-agent connections. For example, one might wish to calculate
the controller gain for a PID algorithm and store the value in the PID's
data base. In such an event, there is no status byte to go with the
value in the data base. The agents will be able to generate such a
status byte for a read operation. What will be the contents of the
"generated" status?
The bits in the status bytes are in three sets. Bits 0 and 1 are
carrying information about the validity of the immediate communication
and about the "goodness" of the data value. The bits are reset if the
data is "good". Clearly, these need to be generated as reset if the
--```,``-`-`,,`,,`,`,,`---
communication is valid and the data base value is not "NaN". If the
agent can not communicate with the remote parameter, then bit 0 in the
status byte will be set and bit 1 will also be set (the last action is
sometimes optional - see details above). If the data base item has a
value of NaN, then bit 1 in the status byte will be set.
Bit 2 (not from process) is describing the origin of the data. If

it is from the process, then it can be used as the feedback of a PID
algorithm: the bit is, in that case, reset. If not, the PID algorithm
will have to be inhibited. This bit will always be set in a generated
status byte.
Bits 3-7 are carrying information from hardware output blocks back
to control blocks. Bit 3 is a special bit for Remote cascades and LO
indication. It does not have meaning in other situations. This bit
should be reset. Bit 4 is set to indicate a hardware failure somewhere
in the structure. No - leave this reset. Bit 5 indicates that this is
not an initializable structure to the process. Since no data base
element without a status byte can be in an initializable structure, this
bit should be set. Finally, bits 6 and 7 are the windup bits: they are
set to indicate that the value can not be moved up (ATW-h) or down
(ATW-l). These should always be left reset or the block will not be
able to move the value.
Thus, a status byte of (00100100 binary) will be used for all

(successful) agent reads of values in the data base that are not NaN and

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
120
do not have status bytes. This will be true for simple reads and for
the read-back of outputs. This service will not be explicitly called
out in the following description: it is implied.
ACTIVE AGENT LOGIC - DISCRETE:

The discrete parameter identified by TAG.PARAMETER can actually have any one
of the following different forms:
Single Bit Value
Without a status byte
With a status byte
Bit String Value
Without any status bytes
With a condensed status byte
With a status byte for each bit
Device cascade signal
Status byte
For a single bit or an analog value
If "Parameter" consists of a single bit value without a status byte or a bit

string value without a status byte, the status byte(s) will be generated (see
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
"Generating A Missing Status Byte" above). If "Parameter" consists of a bit
string value with a condensed status byte, the condensed status byte will be used
for all of the bits reported.
An agent will never read nor write a value that is marked "Bad" or a floating
--```,``-`-`,,`,,`,`,,`---
point number that is NaN. In these cases, the previously existing value in the
receiving location will be left unaltered but the status byte will be written.
In addition, the receiving location's status byte will be forced to have bit 1
("Bad") and bit 2 ("Not-from-process") set. Note that the value of NaN should
have forced both of those bits to be set in its accompanying status byte already.
The Attachment to this paper and its Figure define the logic that is to be
executed by the discrete agent as it places the value(s) and status byte(s) of
the remote parameter into the value and status byte(s) of the local parameter.
The discrete agent will not allow a floating point number, a signed integer,
nor an ASCII string to be addressed as a parameter but it will allow any other
data type. Note that the status byte of any one of the restricted data types can
be addressed.
The discrete agent can not access the value of a single bit of the status
byte of a selected bit in a bit string with a length greater than one.
AGENT TIMING AND DETAILS:

The descriptions of the individual agent types given above detailed certain
actions that the agents are to perform when communication can not be established
(or are lost) with the remote parameter. That description did not define the
timing of the communication relative to the execution of the function block. The
following defines the agent timing and the more general reaction to loss of
communication. However, it does not include some of the detailed agent actions
given above in order to simplify the description.
Agent Service For Prefetch At Prefetch Time:

At a time slightly before the execution of the block, the
"prefetch" operation will be performed, in all devices that support
off-logical node agents, to acquire the off-logical node data. The

121
prefetch operation will be executed at a point in the node block cycle

such that the Field Bus communication service will have time, before the
requesting block executes, to complete one read attempt under the worst
case conditions of field bus length, bus loading, etc. but with no time
allocated for retries. No standard block has more than 5 off-node
prefetches.
Refer to the paper "Data Owner Structure - Logical Nodes" for a

description of the timing of the prefetch of Logical Node variables.
When the logical node is scheduled, all of the agents in a block

are inspected to find the "active" agents. Active agents will only be
supported in logical nodes that "support active agents" and Field Bus
reads can only be requested in logical nodes that "support off-physical
node agents" (see bits 8 and 9 in the logical node non-time critical
options bit string in the paper "Data Owner Structure - Logical Nodes").
If a field bus read is required (and supported), the communication
service will be set up to do the read. A field bus read is required for
all off-physical node agents but all off-logical node agents will be set
up the same way.
If an agent requests a read that is not supported, the device will

issue a configuration alarm and set the offending block to O/S mode.
Note that this refers to an unsupported agent type, not to an incorrect
Tag or Parameter in the agent's pointer. The latter problem will simply
lead to a count-out when the tag is made active.
Off-Field Bus reads will only be done in physical nodes that "are
part of a complex device" (see bit 0 in the physical node options bit
string described in the paper "Data Owner Structure - Hardware"). All
other devices will issue a configuration alarm and set the offending
block to O/S mode if a block has an agent of the Off-Field Bus type.
The following description is for the block I/O words. The logical
node variables will be handled in a manner that is exactly analogous to
the block Output words.
Active Input Agents:

the request for off-logical node parameter values will be
set up and passed to the interlogical node communication
interface, the Field Bus communication service interface
or, for Off-Field Bus agents, to the "complex device
interface" (see the paper "Data Owner Structure -
--```,``-`-`,,`,,`,`,,`---
Hardware"). The setup and scheduling of the read may
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
be done at any time but the read must be done just before
the block executes but the block WILL execute on
schedule.
Active Output Agents:

the information to be written to off-logical node
destinations must be passed to the communication services
by the end of the block execution time. The setup and
scheduling of those services is presumably handled the
same as is done for inputs.
Note: an output agent does both a read and a write each

cycle. It must guard against a continuing situation in
which one of those operations can be done successfully
but the other can not. Therefore, the success/failure of
the communications for an output agent in any cycle is a
combination of a successful read followed immediately by
a successful write.

122
Note that only one data base parameter need be fetched

for the output point of a block in a CASCADE structure -
the value and its status. The mode of the secondary does
not need to be fetched.
On-node fetching will not occur at the prefetch time so that the
output of one control block in a node can be chained to the next control
block in that same node using the most recent value.
Agent Service For Prefetch At Start Of Block Execution:
When block execution starts, the agent service will check, within
the first 10% of the block's time period, to see if the prefetches have
been successful. Refer to the paper "Function Block Structure" for
the details of the logic given in general terms here.
Inputs: The active agents will execute the functional equivalent of the
following general logic:
IF the read was successful, then
reset a counter.
Increment the counter every cycle.
IF the read was unsuccessful, then
do not alter the local parameter's value, status
byte, nor revision number.
IF the counter goes over 3, then
set the Not-From-Process status bit.
optionally,
set the Bad status bit.
set the Failed status bit.
reset the No-Path bit.
--```,``-`-`,,`,,`,`,,`---
Outputs: The active agents will execute the functional equivalent of the
following logic:
(read service)
set a flag.
IF the read was successful, then
reset the flag.
ELSE
do not alter the local parameter's value,
status byte, nor revision number.
ENDIF.
(write service)
index a successful write counter.
IF the write was successful, then
reset the counter.
(check service just before next read)
IF [the flag is set OR the counter is > 0, then
increment the No-Com counter.
ELSE
reset the No-Com counter.
IF the No-Com counter > 3, then
set the No-Com status bit (Bit 0).
set the Not-from-Process status bit (Bit 2).
IF the agent is configured for it, then
set the Bad status bit (Bit 1).
set the Failed status bit (Bit 4).
reset the No-Path bit (Bit 5).
If the communication is successful, there is still one complication

to take care of. A read may have been from a location that had, in
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
turn, had a problem reading yet a third location or is currently in O/S

mode. If so, then bit 0 (bad communication) is set but the implication
is wrong - the bad communication was not this communication. Rather, it
was the "remote" one. Therefore, if Bit 0 of the successfully read

123
status byte is set:

- reset it
- set the Not-From-Process status (it should already be set)
- if the agent is a type that sets "Bad on No-Com" (type = odd),
then set Bit 1 (Bad) and bit 4 (Failed) and reset bit 5
(No-Path).
This same logic must be performed for inactive agents that have received
a write from some other location. Refer to the paper "Function Block
Structure" for the detailed implementation of this logic.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Agent Service As Part Of Block Execution (Start Of Block):
At the beginning of the execution of any control block, the agent
for each value must be serviced:
- For Immediate and Writeable agents:
An immediate agent for an Input will move the STATIC_VALUE

into the parameter value.
A required writeable agent will do the following check on its

No-Com counter (refer to the paper "Function Block Structure" for
the detailed implementation of this logic):
--```,``-`-`,,`,,`,`,,`---
IF the No-Com counter is less than 32, then

Do nothing
ELSE
set Bit 0 (No-Com) in the local parameter's status byte.
set Bit 2 (Not-from-Process) in the local parameter's
status byte.
IF the agent's type is odd, then
set Bit 1 in the local parameter's status byte
(Bad).
(Failed).
reset Bit 5 in the local parameter's status byte
(No-Path).
- For Active agents on-logical node:
Fetch the value and its status. Operation will be the same as
for an off-logical node fetch except there is no counter and the
inability to communicate unconditionally sets status bits 0, 1, 2,
and 4, resets status bit 5, and sets a configuration alarm. If the
value can not be read, set the status byte immediately. See the
description for the off-node prefetch action above.
Many of the standard algorithms will define "transfer

locations" for use in their CASCADE structures. These transfer
locations do not have agents and, therefore, are not described in
this paper. However, they do support No-Com counters that function
the same as those described here. The Cas and RCas No-Com counters
will "count out" at 32 block cycles if there have been no writes to
the respective locations. The ROut transfer location (if it
exists) will count out at 8.
The block agent (counted) agents can take advantage of the No-Com
counters for the transfer locations and for any of the Input and
Output Word locations. Such an agent can be pointed to one of
these on-block locations. The block agent (counted) agent will
execute the following logic:
IF the transfer location No-Com counter has not counted out

THEN Access the required data.
ELSE
Do not access the data in the transfer location

124
set Bit 0 in the local parameter's status byte (No-Com).

set Bit 2 in the local parameter's status byte (Not-From
Process).
IF the agent type is odd,
THEN
(Bad).
(Failed).
reset Bit 5 in the local parameter's status
byte (No-Path).
- For Active Off-Node Agents:
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
All service is done in the prefetch logic.
Agent Service As Part Of Block Execution (End Of Block):
At the end of the execution of any control block, the agent for
each Output must be serviced again:
- For Immediate and Writeable agents and all Input Word agents:
No action needed.
- For Block or Node Active Output Word Agents:
Write the value and its status with status bits 3-7 (normally)
masked off.
There are two cases in which bits 3 or 5 may have to be

written. First, if an LO status was passed up by the read and this
block is in LO mode or was in LO mode during the last cycle, then
only mask bits 4-7.
Second, if the Output word is in the block's cascade structure

and the prefetch had bit 4 set (Failure) and bit 5 reset (normally
No-Path but now used as the failure handshake), then bit 5 was
set by the local algorithm and needs to be written back to the
lower block. See the paper "Status Byte" for an explanation of
this handshake.
Note that on-node storing will be done during the block

execution so that the output of one control block in a node can be
chained to the next control block in that node using the most
recent value. Operation will be the same as for off-node writing
except there is no counter. If the value can not be written,
unconditionally set bits 0, 1, 2, and 4 in the status byte
immediately and set a configuration alarm.
For Off-Node Agents:
Before the end of the execution of a block, the Value (and the
Value_Status byte if necessary) for each Output with an off-logical
node agent must be placed in the Field Bus Communication buffer or
passed to the "complex device interface" (see the paper "Data Owner
Structure - Hardware) but the communication(s) need not be
accomplished. The agent service will normally write the value and
its status with status bits 3-7 masked off.
As explained in the "Application Support Services Interface"

paper, there is a "completion value" associated with each write.
This value will need to be set to 1 when the write is loaded into
the write buffer.

--```,``-`-`,,`,,`,`,,`---

--```,``-`-`,,`,,`,`,,`---
125
Off node agents have the same two cases in which bits 3 or 5
may have to be written as are given above.
Off-physical node, on-Field Bus stores will only be done by

logical nodes that "support off-physical node access". Off-Field
Bus stores will only be done in devices that "are part of a complex
device".
The value status byte will normally only exist for control
input or output values, transfer locations, and for Setpoints.
However, there are a few additional data base items that are
defined with status bytes. (See the paper "Array of Standard Block
Parameters".) If the status byte does not exist for the value
pointed to:
- only the value is written.
- if an analog output value to be written is marked "Bad" but
the value itself is not "NaN", then the write will not take
place.
- a bit that is marked Bad will be masked off while writing
discrete Output words.
- if a write is not done because there is no modified but
not Bad data, the completion code will be reset.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
126
Agent- Attach. 1 Discrete Agent Logic

This Attachment contains the explanation of the detailed read logic,
illustrated in the attached Figure, and write logic that an active agent for a
function block or logical node discrete parameter will execute.
The basis for the read logic is that an active agent (other than a physical
node I/O type) has been configured by the user for an I/O word that has a
discrete data type. A value has been fetched and is to be placed into the local
parameter. This paper will refer to the data that is to be written into the
local parameter's value as the "data".
The agent must analyze the parameter definition and data type for both the
local and remote parameters in order to correctly handle the agent function.
The logic diagram has an "Error" exit. When a logic path leads to that exit,
the local block will be set to O/S mode and a configuration error notification
will be issued. Note that this path can only be encountered on the first
execution after being in O/S mode or if the algorithm number of the remote tag is
changed.
The last section of this attachment will discuss the logic used by an active
agent that must write a local parameter's value into a remote parameter. The
Figure does not include that logic.

PARAMETER NOTATION
DETAILED READ LOGIC
Data Type
Type 0 Agent
Type 1 Agent
--```,``-`-`,,`,,`,`,,`---
WRITING OF THE DISCRETE VALUE
Masking
Mode
Selected Bit Plus Status
Output Word 0 To Cas Transfer Location
Figure 1 - Discrete Active Agent Logic
PARAMETER NOTATION:
All accessible data base values with status information will have parameter
code numbers in a particular "well known" range. Each value will be assigned 4
consecutive numbers in that range, starting with a code number whose hex
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
representation has its two low order bits reset. That code number will be called
"x", exactly as is done in the "Application Support Services Interface" and
"Function Block Structure" papers except in those papers it is called "z".
The version of the value addressed by parameter x will not have any status
information. The version addressed by (x+1) will have 1 byte of status
information. In the case of discrete values, that 1 byte is the "condensed"
status for the full string.
The parameter code (x+2) will address only the single status byte itself, NOT
the value - the status BECOMES the value to the other partner in the
communication.
Discrete (but not scalar) values will be addressable using (x+3). This will
be the value of the bit string plus its full array of status bytes.
SP-50 User Layer Technical Report Agents Attach Discrete Agent Logic

127
In the attached Figure, the notations x, (x+1), (x+2), and (x+3) are used to
conserve space. The case shown for x also describes discrete values that do not
have status information at all.
DETAILED READ LOGIC:

It is assumed that this read logic is executed after it is determined that
the active agent being described is serving a discrete I/O value.
The following discussion of the logic will start in the upper left corner of
the attached Figure.
Data Type:
The first step of the logic is to confirm that the remote data is
of a data type that can be converted to discrete. In this context,
"discrete" can refer to an 8 or 16 bit unsigned integer, a bit string,
or an enumeration. If this is not the case, then the block should issue
a configuration error notification and set O/S mode.
The next section of the logic is representative of the action that

must be taken to assemble the data in preparation for the later steps.
It identifies the four data types and defines the data structure. The
data type can be determined from the parameter code of the parameter
pointed to by the local agent. Specifically, if a parameter's code
number is in the range of numbers allocated for variables with status,
and if the low two bits of the parameter's code are reset, then that
version of the parameter has no status byte. If the code is one, two,
or three integers larger, then it is of the type of (x+1), (x+2), or
(x+3). If the parameter's code number is outside of the range, then it
is of the type x. See the definitions of parameters in the "Array of
Basic Parameters" paper.
There are three configuration checks and two special handling

checks that apply only to agents of type 1. Therefore, the next step in
the logic isolates the type 1 agents.
Type 0 Agent:
If the agent is type 0, then data bit 0 (and its status byte) will
be placed in the low-order bit of the local parameter's value (and its
status byte). The succeeding data bits (and their status bytes) will be
placed in the succeeding bits (and status bytes) of the local
parameter's value until there are no more bits in either the local
parameter or in the data. Any remaining bits in the local parameter's
value (and their status bytes) will be left unaltered. Any remaining
bits (and status bytes) in the data will be ignored.
There is one special case for type 0 agents. If the remote

parameter is a CAS transfer location and the local parameter is Output
Word 0, then special handshaking information is being transmitted in
bits 5-7 of the value from the Cas transfer location. This handshaking
is explained in Attachment 3 to the paper "Status Bytes".
Note: the following description is based on the assumption that the

Cascade transfer location always contains 8 data bits and Output
Word 0 of a discrete block always contains 16 bits. This
assumption is valid for all Standard discrete blocks that can
--```,``-`-`,,`,,`,`,,`---
participate in a CASCADE.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
128
If this special case exists, the status bytes for value bits 5-7
will be set to the default value. Bits 8 - CH will be loaded with the
Failed bit from the status bytes of Bits 0 - 5. The status bytes of
Bits 8 - CH will be set to the default value. The values and status of
Bits DH - FH will be left unchanged.
Based on the handshaking information, the status of the IMan bit in

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
the dynamic mode of the local block will be manipulated. In addition,

the wind-up bits (bits 6 and 7) in the status bytes of value bits 0-4
will be set if both of bits 6 and 7 are set in the value. This act
should be redundant with the action of the lower level block; therefore,
this block will not be responsible for resetting these bits.
--```,``-`-`,,`,,`,`,,`---
This description of the logic now returns to the step in which the agent type
was tested; the logic for type 1 agents will be described.
Type 1 Agent:
The first step for type 1 agents is a check of the configuration
validity. A type 1 agent contains an indicator of the bit number in the
remote value that is to be loaded into bit 0 of the local parameter.
The bit number can not be larger than the length of the (remote) data.
If it is, the error exit is taken.
There are two special situations that must be identified and

blocked. Special handling in the write step will be described below for
a type 0 agent that serves an Output Word and points to the dynamic
mode. Equivalent service is not provided for a type 1 agent. Rather,
the type 1 case must be blocked. If it is found, the logic will report
a configuration error and set the block to O/S mode. Similarly, the
Type 0 agent logic provided for special handling of an Output Word 0
connected to a Cas transfer location. That case is also blocked for
Type 1 agents.
The next step is to invert the data bits if required by the agent's
configuration. If any data bit is inverted, then bits 6 and 7 in that
data bit's status value must be switched to retain their meaning.
The logic is split at this point between data types x and (x+2) on
the one hand and types (x+1) and (x+3) on the other. Note that the
first pair either did not, or effectively did not, have any status
information. In the case of x, it was just not there. In the case of
(x+2), the only information was the status byte but it has essentially
changed to being the data value itself and it, in turn, did not have
status information. These statements are in the past tense because
prior logic has assigned default status bytes to them.
The data values that had a status byte and are being processed by a
type 1 agent will be placed into the discrete value in such a way that a
selected bit is loaded into bit 0 of the local variable and the status
information for that selected bit is loaded into the value bits of the
local variable in bits 8 - FH. This can only be done if the local value
is at least 16 bits long. Therefore, a check is done and the processing
is diverted back to the other path if the local value is short.
Following this check, the data types with status values and a type
1 agent are loaded into the local value. The value of the selected bit
in the data is loaded into the value of bit 0 in the local variable and
its status byte is loaded into bit 0's status byte. Then the bits
following the selected bit, in order, are loaded, along with their
status information, into the succeeding bit positions. The process
stops when the data is exhausted or local bit 7 is loaded. Bits and
their status information contained in bit positions that were not
included will be left unchanged. Finally, the status byte for the

129
selected bit (now already loaded into bit 0 of the local variable) will
be written into the local variable's data bits in bit positions 8 - FH.
The status bytes for these bits will be loaded with the default status
byte.
In the case of data type x or (x+2) or a short local register, the

bit in the remote value identified by the bit number in the agent's
configuration will be loaded into bit 0 of the local parameter's value.
The succeeding bits of the remote value will be located in the
succeeding bits of the local parameter's value until there are no more
bits in either the local parameter or in the remote data. Any remaining
bits in the local parameter's value, and their status bytes, will be
left unaltered. Any remaining bits and status bytes in the remote data
will be ignored.
WRITING OF THE DISCRETE VALUE:

There is some additional logic associated with the writing of the values
after block execution that is not shown in the Figure. The write logic includes
the obvious reversal of the reading logic (using masked writes to protect
unaltered bits and any configured inverting of data bits and the accompanying
switching of their status bits 6 and 7) with three exceptions:
Masking:
Whenever a discrete output word is written by its agent, the write
will be done using a mask for the data bits if any bits in the value
were not addressed by the configuration of the block and a mask for the
status bytes (if present in the receiving parameter).
The status byte mask will always mask off status bits 0 and 3
through 7 (unless bit 3 must pass down LO mode or bit 5 must be set as
part of the LO mode/failure handshake). Bits 1 and 2 will always be
unmasked if the value is being written.
Mode:
The mode of a block exists as two separate bytes in each function
block: the static mode and the dynamic mode (see the paper "Block
Modes"). The dynamic mode word defines the complete current mode of the
block but it can not be written; the static mode can be read and written
but it only defines the single low-priority mode. Therefore, a special
service will be provided for discrete algorithm Output Words that point
to the dynamic mode. The agent will fetch the dynamic mode and write
the static mode!
The following description is written knowing that the agent is of

type 0. Type 1 agents serving an Output Word and pointed to a dynamic
mode parameter are not allowed. This is enforced by the special test in
the read logic described above.
The rules to be followed when a discrete block modifies any of the

bits in an Output word connected by an active agent to a block's dynamic
mode are:
- The agent and its rules will operate only on the low order 8 bits
of the register.
- After the algorithm finishes execution, the agent service will do
the following to the actual Output Word data:
--```,``-`-`,,`,,`,`,,`---
@ Reset bits 6&7 (IMan, O/S) in both the value and the mask.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
130
@ Reset the value and mask bit for all mode bits higher in
priority than the lowest priority set bit.
- IF the final discrete register has 1 and only 1 of the first 8
bits set
AND if there is at least one mask bit set.
THEN write all 8 low order bits (with no masking) to the
static mode parameter of the block identified in the agent.
Selected Bit Plus Status:

There is one particular read that placed the value of a selected
bit of the data into bit 0 of the local parameter's value, continued
with the value and status of the succeeding bits until bit 7 in the
local variable was loaded, then put the status byte of the selected bit
into bits 8 - FH of the local value with default status bytes. Note
that the status byte data actually was placed into two locations because
it was also written into the status byte of bit 0 of the local
parameter's value.
What does the corresponding write operation do with the information

in bits 8 - FH? Nothing! For this special case being described, bits 8
- FH will ALWAYS be masked off. The only status information that is
used for a write of Bit 0 is the status information associated with Bit
0 when the block execution is done. The values and their status
information left in bits 8 - FH when the block finishes execution are
left there.
Output Word 0 To Cas Transfer Location:

Figure 1 contained special read logic for an active agent that
connects Output Word 0 to a Cas transfer location value. The
corresponding logic must be provided for the write.
The agent, while writing in this special case, will never change
bits 5-7 nor their status bytes in the value of Output Word 0. The
agent will generate alternate data for these bits for the write message
--```,``-`-`,,`,,`,`,,`---
when and as needed. In addition, the agent, while writing, will ignore,
and leave unchanged, the data (and their status information) in bits 8 -
FH in the Output word.
The agent will always use a masked write and will always set the
mask bits so that value bits 5 and 6 (and their status bytes) are NOT
written.
The cascade handshaking procedure defines (see the paper "Status

Bytes", Attachment 2 - "Remote Handshake") that the Output Word 0 agent
will normally mask bit 7 but, when it accepts the cascade, it will reset
and write bit 7 with the default status byte (defined in the main section
of the "Agent" paper).

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
131
START DISCRETE ACTIVE AGENT LOGIC

Error
Yes
No Yes
Remote No Bit string = data Agent's
Data = Use default status Bit #># Prohibited
Discrete Byte for each bit. Bits in Connection
? No Data ?
Yes Type Yes ?
X+1 Bit string =data; No
Remote Use cond. Status
Type Data? Byte for each bit.
Invert Data
X+3 No Bits and
Remote No Switch Status Bits
Status byte =data;
Data? Use default status 6 & 7 if so
Type
--```,``-`-`,,`,,`,`,,`---
Byte for each bit. Configured
X+2
Yes Remote
Data? Bit string = data;
Yes Use full status TypeNo
Data No
Byte array. 0
Type =
Agent?
X or
Symbols: (x+2)
No Remote Load the Value and Yes
Parameter Types: ?
X= no status info. Parameter Status of Data bit 0 Yes
= Cas Into Local Bit 0, then
X+1 = cond. Status Transfer
X+2 = cond. Status Loc? The Same for the
Only Yes Succeeding Bits.
No Local
X+3 =value plus
Full status Parameter
No Local Load Set. Bit Of Data, Length >15
Array. w/Status, into Bit 0 of
Parameter Bits?
Value and continue With Yes
Agent Types: = Output succeeding Data to fill Rest
Type 0 = high order Word 0? of Value.
bit reset Load set bit of
Yes
Type 1 = high order Data,
bit set w/Status, into
Use Bits 5-7 Of The Cas Bit 0 of value,
Transfer Location in the continue till
Set Bits 6 & 7 Bit 7; Bit 0's
Handshake as per
In Status Bytes of Done Status in 8
"Status Byte" Paper. Set
value Bits 0-4 if FH+ default
their Status to Default.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
wound up. status

Figure 18: Agents Figure 1: Discrete Active Agent Logic
4

132
Function Block Structure

The architectural core of Field Bus is the function block, which performs
some aspect of the work of data acquisition, control, or output. Every function
block contains an algorithm - a formula or rule - and a data base that is used by
the algorithm. One or more function blocks collectively reside within a logical
node and are processed according to the scheduling procedure of the logical node.
HyperReader Note: click on the word "block" or "blocks" in the above

paragraph, just for kicks.
FUNCTION BLOCK
Mode
Input Output
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Agents Algorithm Agents
Data
Figure 19: Function Block

--```,``-`-`,,`,,`,`,,`---
This paper will describe the basic structure of function blocks. The
detailed definitions of each Standard function block, along with the definitions
of Generic and Open blocks, will be given in the "Function Blocks" portion of
this Technical Report. This paper will also describe how the function blocks
will operate together in a "cascade structure", passing information in both
directions over a single configured connection. The first Attachment to this
paper will detail the logic to be used for setting the block's mode and the
status information for the Input Words, Output Words, Setpoint, and the Output
variable (the last for discrete blocks only). The second Attachment will define
a "fast initialization" scheme that may optionally be included in a logical
node's processing cycle.

OVERVIEW
FUNCTION BLOCK STRUCTURE
Analog
Discrete
DATA TYPES
Extended Bits
Bit 3 Duality
Remote Handshake
Value Bits 7-5
HOLD_PATH
I/O WORD PARAMETER DEFINITIONS
32 Bit Floating Point Parameters
16 Bit String Parameters
HANDLING OF NaN, BAD, AND NO_COM
EXECUTION RULES - CASCADES (Outputs)
Cas Transfer Location
SP-50 User Layer Technical Report Application Support Services Interface

133
RCas Transfer Location

ROut Transfer Location
Owner Manipulation Of Transfer Locations
Setpoint
Fetched Values
Processing of Cascade Readback Stati
No-Com Failed
NaN No-Path
Bad Wound-Up High XOR Wound-Up Low
Not-From-Process Doubly Wound-Up
LO Value Changed
Transfer Location Selection
EXECUTION RULES - MEASUREMENTS
FAILURE HANDLING OPTIONS WORD
PARAMETER MANIPULATION AS PART OF BLOCK EXECUTION
ALGORITHM INITIALIZATION COUNTER
Table 1 - Logic for Parameter Manipulation
CASE (O/S Mode, Analog)
CASE (NOT O/S Mode, Analog)
CASE (O/S Mode, Discrete)
CASE (NOT O/S Mode, Discrete)
Figure 1 - Generalized Analog Block
Figure 2 - Data Structures
Figure 3 - Analog Status Parameter Detail
Figure 4 - Discrete Status Parameter Detail
Attachment 1 - Status Logic
Attachment 2 - Fast Initialization Procedure
OVERVIEW:
A function block is modeled as having the following structural elements:
1) one or more "Inputs"
2) a data base
3) an algorithm
4) one or more "Outputs"
The block is "processed" according to some schedule or as the result of some
event. At that time, the block will calculate a new version of its Output(s)
based on the latest values of its Input(s), using its algorithm. The algorithm
will obtain configuration information and static data from its data base and may
store both externally accessible and internal dynamic data in its data base.
One class of function blocks can connect to physical inputs or outputs that
are a part of the physical node - the "hardware" connections. For example, an
analog input block will be configured to connect to a particular "scalar input"
in the physical node - that physical hardware becomes the Input for that block.
The output of the analog input block will be the value of the analog input
signal, in engineering units. Other blocks are defined to handle other types of
input signals and to control output hardware.
Another class of function blocks is not capable of connecting to physical

hardware - they only accommodate input and output values that are obtained from,
or used by, other function blocks or the higher level control system.
When the Field Bus function blocks are used as part of a control system, they
must exchange data, in an organized way, with other function blocks and with
higher level control entities. Many times, the data is simply made available for
reading by the data consumer. For example, an analog input block simply makes
it's output available for reading.
Data can be written to, or read from, a function block using the services
described in the paper "Application Support Services Interface". Reads and
"indirect" writes of a block's inputs, outputs, and data base values may take
place independent of the function block and, in fact, without the knowledge of
the block.

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\
134
The referenced paper also describes "direct" and "subscriber" reads and
direct writes. These services can be used by function blocks to assess data in
other peer function blocks or they can be used by the higher level control
system. These services provide some information to the service requestor that
the operation has taken place - normally in the form of a "completion" counter.
Based on the change in the counter's value, the requestor can determine that the
information exchange took place successfully.
When a parameter is defined to be the "Input" or "Output" of a function

block, there are two special structural characteristics that are implied. First,
all Inputs and Outputs will have status information accompanying their values -
see the paper "Status Byte". Second, every Input and Output has an "agent" - see
the paper "Agents". Only a selected few data base parameters have status bytes
and no data base parameters have an agent.
All function blocks must support the "Mode" parameter - see the paper "Block
Modes". All function blocks must support the O/S mode and all but the "Null"
algorithm will support at least one other (operating) mode. Some Standard
function blocks support all 8 modes defined in the referenced paper.
For many of the function blocks, the above structures and communication
services are sufficient for operation. All further details are to be found in
the individual algorithm descriptions.
There are many times when a much tighter association of the data producer and
consumer must be accomplished, with a control value and its status moving to the
consumer and status information being passed back to the producer. In the Field
--```,``-`-`,,`,,`,`,,`---
Bus design, this tighter association is called a "cascade structure" or just
"cascade". See the Appendix paper "Block Structure for Cascading" for a
description of the difference between a cascade structure and Cas mode.
HyperReader Note: click on the words "cascade", "Cas", and "mode" in

the above sentence just for kicks.
The cascade structure is spoken of as having a "top" and a "bottom". The top
is the highest level primary control block in the structure. The bottom is the
function block that controls the physical output to the process. See the
Appendix paper "Fundamental Control Structure" for a description of this concept
and notation.
Several control function blocks are designed to regulate a manipulated

process variable in such a way as to force a dependent process variable to become
equal to a target value or "Setpoint". The Setpoint may have been calculated by
another block and passed to the control block. The path that conveys the
Setpoint to the control block will often be a cascade. The path that conveys the
Output of the control block to a function block that can drive the physical
output will almost always be a cascade.
Other control function blocks have been designed with the same general
structure, retaining the name "Setpoint" for one of the inputs even though that
parameter is not strictly a "target" according to the algorithm of the block.
Some of the Standard function blocks in Field Bus can accept up to three
different signals, one of which will be selected as the Setpoint depending on the
mode of the block. The Setpoint is passed to the block's algorithm, along with
other block inputs, and the algorithm produces one or more output signals. One
or two of those output signals may be the continuation of the cascade path toward
the ultimate output(s) to the controlled process. The algorithm may allow a
higher level signal to be selected in preference to one of the calculated outputs
under the control of the mode.
The Field Bus system is designed to pass certain information back "up" the
cascade. This is done using some of the bits in the status bytes associated with
the function block inputs and outputs. The information that is passed up the
cascade includes indication of:
- lower level failures.

135
- LO mode in a lower block.

- the absence of a legal cascade path.
- limits on increases or decreases to the Setpoint's value.
At the same time, similar information can be passed "down" the cascade. In
addition to the Setpoint's value, the information that is passed down the cascade
includes:
- indication that LO mode is set in a higher block
- acknowledgement of the receipt of the failure indication
- indication that the process can effect the Setpoint value
- indication that the lowest "independent" control block is
controlling
- indication that the communication path for the Setpoint is
functioning
In order to have these information exchanges function correctly across

blocks, devices, and manufacturers, the set of rules defined in the remainder of
this paper must be obeyed.
FUNCTION BLOCK STRUCTURE:

A generalized outline of function blocks that support a cascade structure is
presented in Figure 1.
A function block capable of being included in a cascade structure would

typically accept 1 or more "Inputs" and have a "Setpoint". The algorithm
calculates one or more outputs based on those inputs. The output(s) are passed
to the block's "Output Words" and become available to other blocks.
If the block is configured to be in a cascade structure, the Output Word(s)

that support the cascade must have active agents - they must be actively storing
their result into another block.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
If the block is configured to be part of a cascade structure but below the
primary, one or more of the following additional functions must be configured
into the control scheme:
- another function block must write to the "Cas transfer location".
- a higher level control entity must write to the "RCas transfer
location".
- a higher level control entity must write to the "ROut transfer
location".
- a few Standard function blocks specify special input cascade
structures: if they exist, a higher level control entity must write to
them.
It is required that the configuration be arranged such that only one entity
may write to any one of the inputs or transfer locations. There is no check that
can be done by the function block itself to ensure conformance with this rule.
Analog:
An analog function block will typically have an "Input #0" agent.
That agent will include a pointer to the source of the input. If the
Cas transfer location is to be used (and if Cas mode is to connect a
cascade), the pointer must point to the Cas transfer location. The
Input #0 location can not be used simultaneously.
The Input #0 pointer can be configured to point to sources of data

other than its own Cas transfer location; however, the block can not
then be embedded in a cascade structure.
As shown in Figure 1, the mode selects between the several sources

of control of the Setpoint. In Auto mode, the operator can change the

--```,``-`-`,,`,,`,`,,`---

136
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Setpoint. In Cas mode, the cascade is connected through the Cas
transfer location. In RCas mode, the cascade is connected through the
RCas transfer location. The selected value is moved into the Setpoint
--```,``-`-`,,`,,`,`,,`---
value. The values in the transfer locations must have been written by
the higher level entity - they can not be fetched by this block.
One of the Outputs of the algorithm will be directed to Output Word

#0. The cascade will typically continue from that Output Word on to
another block. If the block supports the ROut mode, it will be able to
connect the cascade through the ROut transfer location and on to Output
Word #0 if the mode is set to ROut.
The Splitter Function Block will support a cascade structure

through either or both of Output #0 and Output #1.
The agent for an Output Word in a cascade must be an active agent.
Discrete:
If the block is a discrete block, then the ROut location is never
supported. All of the rest of the generalized structure is the same.
DATA TYPES:
The data structures for the transfer locations and the setpoints are
illustrated in Figure 2.
In an analog block, the transfer locations, Cas, RCas, and ROut, will have
provision for:
1) the 32 bit floating point value.
2) the 8 bit status byte for the value.
3) a direct write update counter (see page 20 of the paper "Application
Support Services Interface").
4) a counter, called TRANSFER_VOID, to be used by the owning block as
described below.
The Setpoint in an analog block will have provision for the 32 bit floating
point value and its 8 bit status.
In a discrete block, the transfer locations, Cas and RCas, will have
provision for:
1) the 8 bit binary string value.
2) five status bytes associated with the low order 5 bits in the value.
3) a direct write update counter as above.
4) TRANSFER_VOID, as above.
The Setpoint in a discrete block will consist of the 8 bit binary string plus
the 5 status bytes for the low order 5 bits in the value.
In both an analog and a discrete block, there will be only one parameter name
for each of the Cas, RCas, and ROut transfer locations. The 32 (or 8) bit value
can not be addressed alone. The status byte (for analog, all 5 status bytes for
discrete) must always be included in any read or write communication. The direct
write counter and TRANSFER_VOID are not accessible from Field Bus.
The design of the discrete Setpoint is the result of a combination of a

number of separate considerations:
Extended Bits:

137
The basic definition of the discrete Setpoint value uses three bits
for the value bit string. This follows directly from the chosen
complexity of the Standard function blocks. There certainly are other,
more complex functions that might be included as Extended or Generic
function blocks. They would need more than three bits to describe their
Setpoint value.
Bit 3 Duality:
The basic definition of the status byte uses bit 3 to indicate that
LO mode is set in the cascade structure. This mechanism is used to
carry the LO information up or down a cascade structure so that the mode
can be correctly displayed in all of the blocks in the cascade.
--```,``-`-`,,`,,`,`,,`---
However, a bit is needed at the two remote transfer locations (RCas

and ROut) to indicate to a higher level entity that the RCas or ROut
mode has been requested. In analog cascades, the ability to carry the
LO mode information up through the remote connections was given up in
order to use Bit 3 for the alternate meaning. This was accepted because
it is anticipated that the need to carry the LO mode information in
analog cascades will be infrequent (see the Appendix paper "LO Mode
Explanation").
It is anticipated that the LO mode will be used much more in

discrete cascades than in analog cascades. Therefore, it was more
important to retain the capability to indicate the LO mode up through
the remote connections.
Remote Handshake:
The request for a remote connection requires a response handshake.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
This handshake was incorporated into the analog cascade using undefined
states of bits 3, 6, and 7.
The analog procedure could not be used directly for discrete values
because the discrete value has multiple status bytes. If any one of the
discrete status bytes was chosen to carry out the handshake, problems
would be encountered when that particular bit was not allowed to change
in the cascade. Therefore, two other bits were needed for the
handshake.
Value Bits 7-5:

The design of the discrete Setpoint value combines these
considerations. The basic value is carried by the three low-order bits
in the value and they each have a status byte. In anticipation of
future Standard blocks and potential Extended and Generic blocks, an
additional two bits are reserved for use as part of the value, for a
total of 5 value bits, each with a status byte.
Bit 5 of the value is used to convey the remote mode request,

exactly as it is handled with status bit 3 in analog values. Therefore,
bit 3 in the status bytes of discrete values can continue to carry the
LO mode information.
Finally, bits 6 and 7 are reserved for the remote handshake and
secondary block mode indication. They are to be used by the handshake
exactly as are bits 6 and 7 in the analog status byte. In addition,

138
they will both be set if the secondary block can not currently accept a
--```,``-`-`,,`,,`,`,,`---
Setpoint. However, they will not convey individual bit wound-up high or
low information.
HOLD_PATH:
The combination of the design of the status bytes and the analog Function
blocks results in a situation where the block must set the path status bit in the
ROut and/or RCas status bytes but there is no basis for the information. There
are two alternative solutions: default to set or set up a "memory" variable.
The latter will be done in Standard blocks.
The following description is a model intended to precisely convey the

required functionality. Since the variable to be defined in the model is not
accessible from Field Bus, this functionality can be provided using any mechanism
that has the same external behavior.
In each Standard analog function block that supports ROut and/or Rcas and a
cascade structure below itself, there will be a logical variable called
"HOLD_PATH". This variable will not be accessible from Field Bus but it will be
referenced by other papers in this Technical Report (for example, see page 10 of
Attachment 2 to this paper). This variable will be associated with Output Word
#0.
HOLD_PATH will be initialized to 1 when the block algorithm is loaded or when

the block does a start/restart in which it lost its "non-static" memory.
The value of HOLD_PATH will be updated any time that bits 5-3 of the status
byte of Output Word #0 has one of two values. At any other time, the value of
HOLD_PATH will simply be retained. One of the two values is expected to be
present the vast majority of the time. When bits 5-3 equal 000B, they are
indicating 1) a path exists, 2) not failed, and 3) not LO mode: reset HOLD_PATH.
When bits 5-3 equal 100B, they are indicating 1) no path, 2) not failed, and 3)
not LO mode: set HOLD_PATH = 1. Refer to Figure 1 of Attachment 1 of the paper
"Status Byte" for a description of these and the other states of these status
bits.
The following will give an example of how HOLD_PATH will be used. When an LO
mode is passed "up" in an analog cascade, the information is not set into the
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
ROut status byte. However, the path information normally carried up to the block
by bit 5 is not available because bit 5 is used as a handshake with bit 3 to show
the direction of the passage of the LO. Since bit 3 in the ROut status byte is
used for the remote handshake, bit 5 of the ROut status byte is left free to
carry the path information. What value is to be placed there? The value in
HOLD_PATH.
Notice that this approximation (or exact but out of date) information will
have an affect on the human interface display information but not on control of
the process. Any time that HOLD_PATH is used, there will be either an LO mode or
a failure downstream of the block and both wind-up bits will be set, blocking all
control action anyway.
I/O WORD PARAMETER DEFINITIONS:

Some of the most important variables in the Standard Field Bus function
blocks are the INPUTS and OUTPUTS. They always have status information

139
associated with their value. The separate paper "Status Bytes" explains the
information content of these status bytes. This paper is only concerned with the
reading and writing of them.
The parameters with status bytes that are defined in Standard Function blocks
can be grouped based on data type. Parameters with status bytes can have one of
two different data types: 32 bit floating point numbers and string variables
having up to 16 bits in the string. The former has a single 8 bit status byte.
The latter has an 8 bit status byte for each of the bits in the string. In
addition, the latter data type has a "condensed" status byte that is the
transverse Boolean "OR" of the individual status bytes. The condensed status
byte is included for applications that will find use for the condensed status
byte but can not justify the communication load of the full status byte array.
Function blocks may be designed to handle bit strings with a length of less
than 16 bits. However, in order to maintain interoperability, the parameter (and
buffer) locations that are involved in receiving direct writes and cyclic reads
must be able to handle the full 16 bit strings. Therefore, the following
descriptions not only quote the length of "16" but the locations being referenced
must support the full 16 bits. It also must follow the rules given below for
parameter manipulation so that it can be an intermediate handler of the full-
width parameters.
The actual operation of the function block may, depending on its definition,
use less than the full 16 bits. When it does, it MUST use the bits IN ORDER
starting with the low order bit.
32 Bit Floating Point Parameters:

In order to manage time coherent communication access to variables
with status bytes, they have been defined as illustrated in the attached
figures. Figure 3, "Analog Status Parameter Detail", gives the
arrangement of a single floating point number with status byte. The
drawing shows a "superset" of an Input Word, Output Word, or logical
node variable. There will be a base parameter defined for the floating
point value itself, called parameter "z" in this figure. The value of
"z" will always be in a "well known" range of parameter numbers and have
its two low-order bits reset in its hex representation.
By definition, the immediately next parameter, "(z+1)", will

consist of a second copy of the 32 bit floating point number plus the
status byte. Both parameters will have an 8 bit, unsigned integer
associated with it (to be defined below as an update counter).
Also by definition, parameter "(z+2)" will refer to the status byte

of (z+1). However, there can be no writes to parameter (z+2) from the
Field Bus, neither direct, nor indirect. This is because there is no
way to coordinate the timing of the writing of the value and the writing
of the status byte. This parameter CAN be read, either cyclic or
direct.
For purposes of this paper, it is assumed, but not required, that
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
there is a "local variable", not addressable over Field Bus, that is yet
another instance of the same floating point value, again with a status
byte, but without an update counter. The local variable is used to
define the required functionality; any implementation that achieves the
same functionality is acceptable. Of course, the bus addressable
parameters MUST be as defined as viewed from the bus.
If the function block supports active agents, then there will be a

40 bit buffer that will be available for cyclic reads of this parameter
(as shown at the bottom of Figure 3). In this case, there will also be
a memory location available for the cyclic read service consistency
parameter.

--```,``-`-`,,`,,`,`,,`---

140
It was pointed out above that Figure 3 is a "superset" of Input

Words, Output Words, and Logical Node variables; no one of them
contains all of the parts shown in the figure. The following comments
identify the subsets:
- Input Words:
The figure is reasonably accurate for Input Words except that
there can be no direct write of parameters z, (z+1), nor (z+3)
by the block from the local variable.
- Logical Node Variables:
The analog logical node variables will not store their value
at the end of the cycle. Therefore, they appear similar to
Input Words. With reference to Figure 3, after the input
logic is executed on parameters z, (z+1), and the cyclic read
buffer, the consolidated result is available to the function
blocks as parameters z, (z+1), and (z+2). The local variable
may be a temporary variable (it was not addressable anyway)
and there is no path from it to a direct write nor to block
execution.
- Output Words:
The biggest simplification of the Figure appears in this
case. There can be no direct writes to an Output word.
Because the potential conflict of multiple direct writes is
removed, the parameters z and (z+1) can refer to the same
memory location. Thus, there need be only one version of the
value, its status, and its counter. Parameter z would then
refer to its value portion, parameter (z+1) would refer to both
its value and its status, and (z+2) would refer to its status.
[Parameter (z+2) would still not be writeable.]
For an Output word, this drawing would actually be used twice.

At the beginning of the cycle, the cyclic read buffer would be
merged with the parameter values to calculate the local
variable. At the end of the cycle, the value in the local
variable would be placed into the parameters and would be the
source of any necessary direct writes.
The "block execution" comes between those two steps.
16 Bit String Parameters:

Figure 4, "Discrete Status Parameter Detail", gives the arrange-
ment of a single 16 bit string with status. This also is a superset of
an Input Word, Output Word, and a logical node variable. Again, there
will be a base parameter defined for the string itself, called parameter
"z" in this figure. Again, "z" will always be in a "well known" range of
parameter numbers and have its two low-order bits reset in its hex
representation.
The design of the Field Bus User Layer requires that the capability
--```,``-`-`,,`,,`,`,,`---
be provided to support a status byte for each bit in the string.

However, that leads to a relatively large array. Therefore the standard
is designed to accommodate BOTH the full and a condensed form of the
status information.
By definition, the immediately next parameter, "(z+1)", will

consist of a second copy of the 16 bit string plus the "condensed"
status byte. The condensed status byte is formed by the transverse
Boolean "OR"ing of the individual status bytes. As above, parameter
(z+2) will refer to the status byte of parameter (z+1); it also can not
be written but can be read.
The bit string variable is more complicated than the floating point
variable because of the expanded status byte version of the number that
must be maintained. Parameter (z+3) will be the string plus the
individual status bytes.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
141
Again, each of the parameters z, (z+1), and (z+3) will have an 8

bit, unsigned integer associated with it.
The local variable is exactly as defined for the floating point

value except that it includes the 16 bit value and the full status byte.
The cyclic read buffer and its associated consistency parameter are as
defined above except for the length of the buffer: it must be 10 bytes
long to accommodate the read of a variable with the full status array.
Note that the buffer, like the parameters, must accommodate the full 16
bit string and all of their status bytes even if the agent's own value
can only accommodate fewer bits.
The general operation of writing to the value of an agent (i.e.,

one of these parameter sets) is as follows:
- an indirect write (i.e., through the DBWS) can be done at any time.
The DBWS will update all "versions" of the parameter (i.e.,
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
parameter z, (z+1) and (z+3) if it exists) including the status values

(but not the cyclic read buffer) at each write. It will also reset
the write counter for all versions of the parameter
- a direct write can be done at any time. The written value
will be loaded into the addressed parameter (and status field if there
is one) and the individual write counter will be reset.
- a cyclic read will be placed in the cyclic read buffer and the
consistency value will be reset.
- at entity execution time:
+ the new version of the parameter is moved into the local
variable.
+ the counter and consistency variables are incremented.
+ there is a separate counter for each output word and logical
node variable agent, called "IO_COUNT" in Table 1, that is reset
every time that a successful cyclic read is immediately followed
by a successful direct write. If not successful, it is
incremented. If the counter reaches 3, ALL versions of the
status byte for the agent will have their No_Com status bit set
and, optionally, have their Bad status bit set.
+ If all of the communication counters on one set of parameters
(i.e., parameters z, (z+1), and (z+3) if it exists) exceed a
limit (32 for the Input Words and the Cas and RCas transfer
location and 8 for the ROut transfer location) the algorithm
--```,``-`-`,,`,,`,`,,`---
may dictate special action.
It was pointed out above that Figure 4 is a "superset" of Input

Words, Output Words, and Logical Node variables; no one of them
contains all of the parts shown in the figure. The following comments
identify the subsets:
- Input Words:
The figure is reasonably accurate for Input Words except that
there can be no direct write of parameters z, (z+1), nor (z+3)
by the block from the local variable.
- Output Words:
The biggest simplification of the Figure appears in this
case. There can be no direct writes to an Output word.
Because the potential conflict of multiple writes is removed,
the parameters z and (z+1) can refer to the same memory string.
[Parameter (z+2) would still not be writeable.]
From the perspective of logic, there need be only one version

of the value, its condensed status, its full status, and its
counter. However, that memory string can not be arranged such
that it can always be used directly by the Application Layer.
For an Output word, this drawing would actually be used twice.

At the beginning of the cycle, the cyclic read buffer would be
merged with the parameter values to calculate the local
variable. At the end of the cycle, the value in the local
variable would be placed into the parameters and would be the

142
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
source of any necessary direct writes.
The "block execution" comes between those two steps.

- Logical Node Variables:
The discrete logical node variables WILL be able to store
their values at the end of the cycle. In general, their agent
can either be active or writeable.
With reference to Figure 4, after the input logic is executed

on parameters z, (z+1), (z+3), and the cyclic read buffer, the
consolidated result can be read by any of the function blocks
in the logical node as any of the four parameters. The local
variable may be used to retain the input value for use at the
termination of the cycle. There is no path from the local
variable to a direct write nor to block execution.
Since all on-logical-node writes are handled by the logic of

the DBWS, the multiple versions of the value can be kept
consistent.
If the agent is active, there can be no direct writes to the

parameters; the consistent value mentioned above can be
written as necessary.
If the agent is not active, there can be direct writes. It is

up to the User to keep the configuration "useful".
Again there is no path from the local variable to block

execution.
--```,``-`-`,,`,,`,`,,`---
HANDLING OF NaN, BAD, AND NO_COM:

The logic given in Table 1 of this paper and Table 1 of the DBWS paper
include the reaction of the communication service to a NaN value or to Bad or No-
Com. status bits found in the incoming values (either being written in or read).
Note that the reaction to No-Com. described here is to a status of No-Com. found
in the value acquired by a successful read or write; this is significantly
different from the situation where a communication can not be performed. These
reactions are summarized here for I/O Words (not for transfer locations):
IF the value read in has a value of NaN, then

set Bad (Bit 1).
set Not-from-Process (Bit 2).
IF the status of the value read in has Bad (Bit 1) set, then
IF the status of the value read in has No-Com (Bit 0) set, then
IF a write to the local data base through the Data Base Write
Service, then
reset No-Com (Bit 0).
set Bad (Bit 1).
IF the receiving location is a transfer location, then
set Special (Bit 3).
set Failed (Bit 4).
reset No-Path (Bit 5) (since bit 4 is set, this is the
handshake request described in Attachment 1 to the paper
"Status Byte".
set ATW-h and ATW-l (Bits 6 and 7).
'Note: this is a violent reaction to the receipt of a
' No-Com because no entity on Field Bus should ever
' write (indirectly) a status byte with No-Com set.
ELSE
reset No-Com. (Bit 0).

143

IF the (local) agent for the receiving location is of a type
that has its low order bit set, then
set Bad (Bit 1).
IF NOT [(an Output Word) OR (a Logical Node variable)],
then
set Failed (Bit 4).
reset No-Path (Bit 5).
'Note: a cyclic read may legitimately receive a
' No-Com status.
'Note: since an output word or a logical node
' variable agent will always read from the
' location it writes to, the No-Com
' condition does not cause a failure alert
' at start. A loss of communications will
' be detected by the local counters.
'Note: bit 5 is reset to activate the Failure
' handshake procedure - see Attachment 1
' to the paper "Status Byte".
EXECUTION RULES - CASCADES (Outputs):

Every function block that is operating in a cascade structure must obey a set
of rules if the information flow is to be reliable. The following discussion
gives the general rules for a cascade. However, there may be certain
modifications of these rules by an individual function block definition if
necessary.
Attachment 1 to this paper gives a detailed definition of the logic that will
be used to update the status information for certain of the values in an
individual block at each of its executions. Again, individual function block
definitions may modify those rules or offer the user the option to do so. In
addition, there are two Standard blocks that have unique structures and are not
considered by Attachment 1 - the Selector and Splitter analog Standard blocks.
The logic for those two blocks will be defined by the individual block.
Cas Transfer Location:

There is no mechanism for a Standard function block to fetch its
cascaded Setpoint while in Cas mode. It is assumed, but not required,
that a peer function block on the same Field Bus will write into the Cas
transfer location. The use of the Cas transfer location for higher
level control is strongly discouraged because the Cas mode is intended
to indicate to the operator that the control source is a Bus peer
device.
The peer function block must be able to support the failure

handshake that was defined in Attachment #1 to the paper "Status Byte"
if the secondary is configured to pass the failure acknowledgement up
the cascade. If it does not support it, a failure condition will not
clear correctly because it will be unacknowledged.
The peer block will prefetch the value and status of the Cas
transfer location before it executes. After execution, it will use a
"direct write" (see the paper "Application Support Services Interface")
to write the (Cas) Setpoint value and status byte but it will normally
mask bits 3 through 7 of all status bytes. If the value being
transferred is discrete, then bits 5-7 in the value will normally be
masked as well.
If the peer block finds bits 6 and 7 of the status byte (if
analog, bits 6 and 7 of the value if discrete) both set, then it will
still write a value and status to the Cas transfer location but it will

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
144
mask off the value as well as status bits 3 through 7.
If the peer block finds status bits 5&4 in the Cas transfer
location = 01B, it will know to activate the failure handshake procedure
explained in Attachment 1 to the paper "Status Byte". In that
procedure, the peer block will have to actually write to status bit 5.
That is the only time that the peer block will unmask bit 5 and it will
only do it when the bit must be manipulated as indicated by the
prefetched readback of the transfer location.
Note that a secondary block that can pass failure up the cascade
will pass the failure indication to cascade connections that are not in
control at the time of the failure. However, it will set bits 5&4 =
11B. This indicates that the failure has already been acknowledged; the
primary does not have to execute the handshake procedure and should not
set a failure alert.
If the peer block must pass the notification of a LO mode condition

down the cascade, it will set bit 3 in the status byte = 1. When the
condition clears, it will set bit 3 in the status byte = 0. Those are
the only times that the peer block will unmask bit 3 and it will only do
it when the bit must be manipulated as indicated by the prefetched
readback of the transfer location.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
A discrete peer block will execute the failure handshake procedure

defined in Attachment #1 of the paper "Status Byte" through bits 5-7 in
the discrete "value". If the discrete peer block only supports the low
order three discrete bits in the value, it should always reset value
bits 3&4 and set bits 0-2 in the status bytes for bits 3 and 4 equal to
100B.
RCas Transfer Location:

There is no mechanism for a Standard function block to fetch its
Setpoint while in RCas mode. Only a higher level entity can write into
the RCas transfer location. A peer Standard function block can not use
the RCas transfer location because such a block can not execute the
remote cascade handshake that is needed to change the mode to RCas.
--```,``-`-`,,`,,`,`,,`---
The remote block will execute the remote handshake as specified in

Attachment 2 to the paper "Status Byte". It will use bits 3, 6, and 7
of the status byte of an analog value; it will use bits 5, 6, and 7 of
the value of a discrete Setpoint. Note that the primary will have to
unmask and reset bit 7 in order to accept the "remote offer". That is
the only time that the remote location will unmask bit 7 and it will
only do it in the one cycle when the bit must be reset as indicated by
the prefetched readback of the transfer location.
As discussed above, the RCas transfer location in analog blocks

can not pass the LO mode information because bit 3 in the status byte is
used for the remote cascade handshake.
Except for the remote handshake and the LO mode indication, the
remote block will interact with the RCas location exactly as defined
above for the peer block and the Cas location.
ROut Transfer Location:

Only a higher level entity can write into the ROut transfer
location. A peer Standard function block can not use the ROut transfer
location because such a block can not execute the remote cascade
handshake that is needed to change the mode to ROut.

145
As discussed above, the ROut transfer location in analog blocks

can not pass the LO mode information because bit 3 in the status byte is
used for the remote cascade handshake.
The remote block will interact with the ROut location exactly as
defined above for the remote block and the RCas location except, of
course, the value being transferred is the secondary's output, not its
Setpoint.
Owner Manipulation Of Transfer Locations:

The owner block will initialize the transfer location value to NaN
[for analog, all reset value bits, bit 5 (LO) reset, and bits 6 and 7
(wound-up) set for a discrete value] and the status bytes to their
default values when the algorithm number is changed. Then it will
change any bits necessary to convey the following specific information.
Also at initialization, the owner will set the counter TRANSFER_VOID =
--```,``-`-`,,`,,`,`,,`---
2.
The owner will never reset status bit 2 (Not-from-process)

but will set it when No-Com or Bad conditions are found and whenever the
value in the transfer location is NOT used as the Setpoint.
If the owner finds that the No-Com bit was written as set, it will
set Bad and Not-from-Process and reset the No-Com bit. However, if the
transfer location counts out (see the paper "Application Support
Services Interface"), the owner will set the No-Com and Not-from-Process
bits and adjust the mode of its own block as defined in Attachment 1 to
the paper "Function Block Structure".
When a higher level source of the Setpoint or Output is not

selected by the mode, then that transfer location will have bits 2
(Not-from-Process) and 6 and 7 (the wound-up high and low bits) set = 1
in all status bytes and, if discrete, in the value. This is the
indication to the primary block to set the IMan mode bit in its own
actual mode.
When the owner block is not accepting the value of the Setpoint or
Output that is being passed down to a transfer location, it must execute
certain operations to ensure that the higher block receives the correct
value for initialization. This is accomplished using the counter
introduced above, called "TRANSFER_VOID". In addition, the owner will
set bit 2 (Not-from-Process) in the status byte.
Any time that the owner block is in an actual mode of higher

priority than Auto or any time that a Setpoint is written by the Data
Base Write Service, the value of the Setpoint will also be written into
the Cas and RCas locations, bit 2 (Not-from-Process) in the status bytes
of the transfer locations will be set, and the TRANSFER_VOID for that
location will be set to a value of 2. Similarly, any time that the
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
owner analog block is in an actual mode of higher priority than Man or
any time that an Output Word #0 is written by the Data Base Write
Service to an analog block, the written value will also be written to
the ROut transfer location, bit 2 (Not-from-Process) in the status bytes
of the transfer locations will be set, and TRANSFER_VOID for the ROut
location will be set to a value of 2.
At each execution of the owner block, and before the owner block
changes the values of its Setpoint or Output remaining from the last
cycle, it will perform the following operations on each of these
locations:
IF the transfer location's direct write counter indicates that a
new value was written, then
IF TRANSFER_VOID > 0, then

146
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Decrement TRANSFER_VOID.
copy the value in the Setpoint (or Output) to the value
in the transfer location.
set bit 2 in the status byte of the transfer location.
Ensure that bits 6 and 7 in the status byte (analog,
status bytes and value for discretes) of the
transfer location are both set.
When a higher level source of the Setpoint or Output is selected by

the mode, then the following logic will be executed on the location
in control and after the logic in the last paragraph:
IF TRANSFER_VOID = 0, then
IF Analog, then
IF Cas or RCas transfer location, then
Set bits 6 and 7 in the status byte = to bits 6 and
7 in the Setpoint
IF a special Input Word location, then
Set bits 6 and 7 as specified by the algorithm.
IF ROut transfer location, then
Set bits 6 and 7 in the status byte = to bits 6 and
7 in Output Word #0.
IF Discrete, then
'Note: must be the Cas or RCas location
Set bits 6 and 7 in the value = 00B.
Set bits 6 and 7 in the status bytes of the bits = to
bits 6 and 7 in their status bytes in the Setpoint.
IF TRANSFER_VOID <> 0, then
Ensure that bits 6 and 7 in the status of an analog value or
in the status bytes and the value of a discrete are set.
The owner block will manipulate status bits 5-3 in the Cas transfer
location and in discrete status bytes in RCas as defined in Attachment 1
to the paper "Status Byte". An analog owner block will similarly
manipulate bits 5 and 4 in the status of RCas and ROut transfer
locations. These bits will be used to indicate LO mode passing up or a
failure in the lower part of the cascade. If there are no failure nor
LO conditions, then bit 5 will indicate the existence of a proper
cascade path to the process. The following comments are pertinent:
1) LO mode status will only be passed up if the owner block can, by

definition or by a set option, do so. The current mode of the
owner block will not, however, be a factor in deciding if it
is to be passed up.
2) a failure status will only be passed up if the owner block can,
by definition or by a set option, do so. The current mode of
the owner block will not be a factor in deciding if it is to be
passed up. However, it will be passed up as unacknowledged
(bits 5&4 = 01) if the transfer location is currently selected
for control. It will be passed up as already acknowledged (bits
5&4 = 11) if the transfer location is currently not selected for
control.
If the failure is passed up the cascade as unacknowledged, the

higher level block acknowledges the condition by unmasking bit 5 for one
write and setting it. When the lower block finds bit 5 set, it can, in
turn, set bit 5 in its own output to pass the handshake back down the
cascade.
In the Cas transfer location of a discrete block, the owner block

will set bit 5 = 0 and use bits 6 and 7 to indicate its own mode. In
the RCas transfer location, the owner will use bits 7-5 in the value to
execute the remote handshake defined in Attachment 2 to the paper
"Status Byte". Note that bits 7 and 6 are also used to indicate the
acceptance of the transfer value as defined above.

--```,``-`-`,,`,,`,`,,`---

--```,``-`-`,,`,,`,`,,`---
147
Setpoint:
A cascade structure is never connected directly through the
Setpoint value. Only an operator or a higher level program should
manipulate the Setpoint. When an analog Setpoint is written without a
status value, the Data Base Write Service will:
1) reset bit 0 (No-Com).
2) reset bit 1 (Bad).
3) Set bit 2 (Not-from-Process).
It will leave the rest of the existing status bits alone.
When a discrete Setpoint is written without any status values, the

Data Base Write Service will:
1) force bit 5 in the value = 0.
2) leave bits 6 and 7 in the existing value alone.
3) reset bit 0 in all status bytes (No-Com).
4) reset bit 1 in all status bytes (Bad).
5) Set bit 2 in all status bytes (Not-from-Process).
It will leave the rest of the existing status bits alone.
A write to a Setpoint will never be allowed to set bit 2

(Not-from-Process) in an analog status byte nor in any of the status
bytes in a discrete value.
Fetched Values:
Before a block starts its execution, the logical node will have
acquired any off-logical node variables that are needed. On-logical
node variables are acquired after the start of block execution.
Before the execution of the block's algorithm, one of the two

procedures will have acquired any necessary Input Words as well as the
value and status stored at the destination of all active Output Words.
A cascade structure requires that the cascaded output have an active
agent.
The readback of the value and status of the target of the cascaded
active output agent is the mechanism for passing information up the
cascade structure. The primary block inspects the value and status
information and executes necessary operations.
If any of the actively fetched Input values have a No-Com status,

the local block must change that status. The definition of the
algorithm, and possibly a configuration option, will determine the
action to take in addition to resetting the No-Com status. It will be
either to ignore the condition or to set the value Bad.
Processing of Cascade Readback Stati:
No-Com:
There are two different contexts for No-Com. One context
concerns a No-Com status found in the status byte(s) of the value
read back from the target destination. The second concerns a
No-Com status imposed by the local block because of the inability
to actually read the target location.
A No-Com status of the first type may be caused by one of two

different causes. The cascade may be just starting and the count
out of the target location has not yet cleared or there is a
continuing communication problem with the writes to the target but
the reads are successful. This second possibility is a serious

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
148
problem. The actions to be taken are:

- The No-Com bit will be reset.
- The Bad status bit set.
- Not-from-process will be set.
- Status bits 6 and 7 (if analog, value bits 6 and 7 if
discrete) will be set.
- The algorithm will proceed.
No alerts will be issued at this point because either 1)
the No-Com will clear or 2) the No-Com has already been detected
and alarmed by the target location.
A No-Com of the second type is the normal case for No-Com. It

also is serious. The actions to be taken are:
- The No-Com bit will be set.
--```,``-`-`,,`,,`,`,,`---

A No-Com alert will be issued.
NaN:
When an analog value is read back and found to have a value of
NaN, the following action will be taken:

The NaN value will cause any calculation in which it is used to
result in a NaN value. There will not be an alert.
Bad:
If a Bad value is read back from an Output destination, then
- The Bad status bit will remain set.
Whenever an algorithm attempts to initialize but finds the

read-back value to be Bad, it will use the value and proceed.
However, if the algorithm passes the result of the calculation
further up the cascade, it will mark it Bad.
Not-From-Process:
A Not-from-Process indication read back from an Output
destination will be ignored. This status is only passed down the
cascade, it is never passed up.
Certain algorithms will specifically include the optional

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
logic to "reflect" the upward indication of a "Path to the Process"

back as a reset "Not-from-Process".
LO:
Some algorithms will not accept an LO mode passed up the
cascade. They will ignore the LO status.

--```,``-`-`,,`,,`,`,,`---
149
Some algorithms will accept an LO mode passed up the cascade

but they will not pass it further up the cascade. In that case,
the LO mode bit in the actual mode of the local block will be set,
but the LO mode indication will not be passed to the block's
Setpoint. The LO mode indication can never be set in the ROut
transfer location nor in an analog RCas transfer location.
Some algorithms will accept an LO mode passed up the cascade

and pass it further up the cascade. In that case, the LO mode bit
in the actual mode of the local block will be set and the LO mode
indication will be passed to the block's Setpoint, to the Cas
transfer location, and to any special cascade input connections.
If the block is discrete, then the status can also be passed in the
status bytes of the RCas transfer location. The current mode of
the block will not be a consideration in passing the status further
up the cascade.
Failed:
When a failure is reported up the cascade, a block's algorithm
and configuration will determine if it will:
1) pass the notification further up the cascade
2) change its own mode to Man and send the corresponding alert
3) ignore it
If the failure is to be passed further up the cascade, then

the action will be different for a cascade path that is selected
and those that are not selected.
For the former, the handshake procedure defined in Attachment

1 to the paper "Status Byte" will be executed.
For the latter, status bits 5&4 will be set to 11B. This is
the indication that the failure has already been acknowledged.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Therefore, blocks further up the non-selected paths will not issue
alerts, will not set their modes to Man, and will not execute the
handshake procedure.
No-Path:
If the No-Path status is set while the LO mode and the failure
status bits are reset, there is simply an indication that there is
no legitimate path to the process. This situation is passed up
through all cascade connections. The PID algorithm will eliminate
integral action if this condition is passed up to it and certain
function blocks will reflect a "Path to the Process" passed upward
back as a reset "Not-from-Process" passing downward.
Wound-Up High XOR Wound-Up Low:

Every function block in a cascade structure will calculate the
state of the wound-up status bits in its Setpoint. This
calculation will consider:
1) the state of the wound-up bits in the readback of its
Output
2) IF an analog block: the Output limits
3) IF an analog block: the direct/reverse action of the
algorithm
IF a discrete block: bit inversions.
4) the operating conditions of its algorithm.
5) IF an analog block: the Setpoint limits.
The wound-up bits of the Setpoint (Output) will be copied into
a transfer location whose value is selected. Of course, both

150
bits are set anyway in unselected locations.
Doubly Wound-Up:
If bits 6 and 7 are both set in the value read back from the
Output destination, then the local block will immediately set
itself into IMan mode. Bits 6 and 7 will then be set in the
Setpoint and in all cascade input locations.
Value Changed:
If the value read back from the output value is not exactly
the same as was written to it, the local block will immediately
set itself into IMan mode. Bits 6 and 7 will be set in the
Setpoint and in all cascade input locations.
Transfer Location Selection:

The actual mode of the local block determines the transfer location
that will be used, if any. The actual mode is determined from the
current status of the block and the requested mode every cycle.
Attachment #1 to the paper "Function Block Structure" defines the method
of calculating the actual mode.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
The paper "Application Support Services Interface" defines the
method of "counting out" a transfer location. That procedure is used
with the mode definition to optionally change to a higher priority mode
when a transfer location counts out.
If one of the transfer locations is selected by the mode, the

TRANSFER_VOID of that location is inspected. If it has a value of 0,
the transfer location value can be used. If it has a value greater than
0, the mode will be left alone but the Setpoint (if Cas or RCas, Output
if ROut) left from the last cycle will be used.
EXECUTION RULES - MEASUREMENTS:

Editor's Note:
The reader is reminded that the rules given in the previous section
pertain to a "cascade structure". A cascade structure is the data flow
from the output of one block to an initializable input of another block,
continuing though to an output to the process. The data path from a
measuring device to the measured variable input of a control block IS
NOT a cascade. In Field Bus, the blocks "push" (or write) their values
"down" the cascade to the output; they normally "pull" (read) the values
from the measuring devices. The push is one necessary but not
sufficient method of distinguishing the existence of a cascade
structure.
When a block's output is not being written (its agent is not currently
active), bits 6 and 7 in the status byte will be used to indicate the status of
limits on the value if the output is an analog value. If the measurement can not
increase due to a limit in the measuring device or in the data flow path,
normally caused by output limits, bit 6 will be set. Likewise, if the
measurement can not decrease, bit 7 will be set. These bits will flow through
--```,``-`-`,,`,,`,`,,`---
function blocks based only on the algorithm rules. These bits will be reset in
the status bytes of discrete values.
To determine the correct states of bits 6 and 7, the function block will
normally consider the states of bits 6 and 7 in its input value(s), the status of
any applicable setpoint and output limits, the direction of operation of the
algorithm equation, and user options. Each function block will define any

151
exception to these rules. The PID function block will utilize the status bits to
turn off integral action in the direction that could cause wind-up.
For both analog and discrete structures of this type, the system will provide
for bit 4 to optionally carry an indication of failure of a process measurement.
The information will be used to optionally suppress alerts and to allow a control
block several blocks removed from the measurement device to indicate the failure.
FAILURE HANDLING OPTIONS WORD:

The response of a function block to a failure indication passed upward from a
lower block or to a failure indication passed to it with a measurement is
partially controlled by user options. Those options are selected by setting bits
in a block configuration word dedicated to "failures".
Each function block is required to have a 16 bit string parameter called

"FAIL_OPT0". This parameter will indicate the user's selections to partially
control the reaction of the block algorithm to the presence of a failure
indication in the INPUTs or OUTPUTs of the block. The bits will be dedicated in
pairs to the first four inputs and the first four outputs. Low order bits 0 and
1 will serve INPUT0, the next two bits INPUT1, bits 8 and 9 will serve OUTPUT0,
etc.
A second parameter number will be reserved for FAIL_OPT1. This parameter

will be required in any block that has a fifth input word or a fifth output word.
It will contain dedicated bit pairs for each of inputs 4 through 7 and outputs 4
through 7. The bits will be arranged analogous to the arrangement in FAIL_OPT0
The four states that can be selected in each bit pair will be defined as
follows:
Bit Pair Meaning
Value All I/O except Cascade Cascade Outputs
00 Failure passed to value users; Failure passed up cascade;
alerts suppressed. alerts suppressed.
01 Failure passed and alarmed. Failure alarmed and ack.
--```,``-`-`,,`,,`,`,,`---
10 Failure not passed and alerts Reserved for specific
suppressed. algorithms.
11 Failure not passed but alarmed. Reserved for specific
algorithms.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
The first column of meanings apply to all circumstances except cascade
outputs. Specifically, that will be all hardware I/O connections, all input
words that have active agents, and all output words that have inactive agents.
In certain discrete blocks, some of the output words can act as input words.
They will be treated as input words for purposes of this description.
When the low order of the two option bits is reset, all "Fail" and "Bad"
alerts that would have resulted from the "Fail" status of the input in this
cycle and in this function block will be suppressed. The suppression applies
independent of the assigned priorities of any of the individual alerts.
In those cases in which hardware is exercised as part of the execution of the

block, the configuration in the first column will affect BOTH the failure
notification by the physical node for the hardware and to the "Fail" and
resulting "Bad" notification for the I/O block. Specifically, the "Fail" will be
reported by one (if its alert priority is high enough), and only one, of the two
paths - either the physical node or the function block but not both. If the low
order of the two option bits is reset, the physical node will set the alarm state
and report the failure (if the appropriate alert's priority is high enough); if
the bit is set, the function block will set the alarm state and report the
failure (again, if the appropriate alert's priority is high enough). If the
alert priority for the selected path is too low, the event is not reported by
either path. The standard hardware connections that fall into this category are:
1) PO 3) SO

152
2) SI 4) TK
When the high order of the two option bits is reset, the failure bit is
passed to any output value that is affected by the failed input ELSE it is reset.
Note that the failure state is not set in the status bytes of outputs if the
agent for the output is active or a physical connection.
The second column of meanings defined above apply to the cascade situation.
When the state is 00, the failure is passed up the cascade structure as defined
earlier in this paper. When the state is 01, the failure causes an alert to be
issued and the acknowledgement handshake to be exercised as defined earlier. The
failure information is not then passed any further up the cascade. States 10 and
11 are reserved for the use of specific algorithms (PID and Device Control).
PARAMETER MANIPULATION AS PART OF BLOCK EXECUTION:

As part of the function block execution, the function block can analyze the
agent associated with an INPUT or OUTPUT word parameter. The configuration of
the agent will indicate if a cyclic read is being used and, if so, the data type
of the contents of the cyclic read buffer. Then, depending on that information
and the consistency information, the cyclic read buffer may overlay the parameter
values or the parameter values may be used to update the "local variable". Note
that there are other parameters with status bytes but they have no agents: they
can not have an associated cyclic read buffer.
Specifically, the transfer of the contents of the buffer and parameters to

the local variable will take place as modeled in Table 1, BEFORE the value in the
local variable is used by the function block, and in all block modes including
O/S.
ALGORITHM INITIALIZATION COUNTER:

Many alarms are avoided at block start-up if all alarm processing and the
storing action of most active output agents are inhibited the first cycle of a
block after a mode change from O/S. Then, on the second cycle, alarms are still
disabled and most blocks initialize. Finally, in the third cycle, control can
normally start.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
This paper will model the indicator for these special block cycles as an
integer counter. The "Data Base Write Service" (DBWS) - see Attachment 2 to the
paper of that name - will set this integer as appropriate. The counter is not a
readable data base item; it can be implemented in any way that yields the
described functionality. Note that, for a long cycle time block, data base
changes could be completed between block executions. They might never be seen by
the block if it were not for the DBWS and this integer.
The defined values for the algorithm's "FORCE_INIT" are:

3 = on the next pass, if the block is not in O/S mode, THEN:
- do not allow active output agents to store the outputs
unless the value was input from this block's hardware
connection and is "Good".
- reset the No-Com count out counters (as part of the
algorithm processing - after all of the inputs are
supposed to be done).
- execute the algorithm initialization calculations.
- do not execute the alarm processing for the "PV Pointer"
function, the Input values, nor for the Output values.
- decrement FORCE_INIT by 1.
2 = on the next pass, if the block is not in O/S mode, THEN:
- execute the algorithm initialization calculations unless
this block is the output block for the cascade.

--```,``-`-`,,`,,`,`,,`---

153
- do not execute the alarm processing for the "PV Pointer"

function, the Input values, nor for the Output values.
- decrement FORCE_INIT by 1 but ONLY if there are no No-Com
counters in the block that have accumulated counts but
have not yet fully counted out (this is to be done as part
of the algorithm processing - after all of the inputs are
supposed to be done).
1 = on the next pass:
IF the block has an option to change its Requested mode
upon a "Bad" value for one of its inputs or outputs,
AND that input or output is in fact "Bad", then
Initialize the block.
IF the agent with the "Bad" value can count out, then
IF that agent would have counted out at this
time in the absence of communication, then
Decrement FORCE_INIT.
Go ahead with the requested mode change.
ELSE
Do a normal forward calculation
Decrement FORCE_INIT by 1.
0 = the next pass is to be normal.
When the block transitions from O/S to any other mode, under any conditions,
it will observe the three steps of special actions described above. It will be
forced to do this because the DBWS will have set FORCE_INIT to a value of 3 any
time the mode is changed from O/S or the block must act as if it was. The block
must at least go to state 2 after a data base change to the portion of the data
base that requires that the block mode be Man or O/S for changing. Again, the
DBWS will set FORCE_INIT as necessary.
--```,``-`-`,,`,,`,`,,`---
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^

154
Table 1: Logic For Parameter Manipulation

The following is the logic for the manipulation, during block execution, of
the parameters that are in the range of parameters that have status bytes. This
logic covers the following types of agents:
- Simple Writeable
- Required Writeable
- Off Logical Node, on Physical Node
- Off Logical Node, Off Physical Node
- Off Field Bus
It does not include the logic nor variables to handle the Revision Number that
may be a part of certain agents.
The sections of the logic are:

CASE (O/S mode, Analog)
CASE (NOT O/S mode, Analog)
CASE (O/S mode, Discrete)
CASE (NOT O/S mode, Discrete
Notes: This logic is designed to be executed BEFORE the logic given in

Attachment 1.
A No-Com status condition imported with a direct read will "look"

just like a locally generated No-Com condition. Note that the
DBWS does not allow a No-Com to be written - it automatically
converts all No-Com status conditions to "Bad Value"'s.
This logic is designed to be followed by the block processing

where the "local value" will be inspected for a change into or
out of No-Com and Bad alarm states and where the alarm handling
will be done. The No-Com and Bad conditions will be the basis
for alarms but the Failed condition will not; the CAUSE of the
failure is the alarm, not the failure state itself.
Assume for illustration:

IO_COUNT = a counter, associated with each output agent, that is
incremented once for each cycle in which either the read
or subsequent write of an output word's agent is
unsuccessful. The value is reset by a successful
communications pair, that is, a successful read FOLLOWED
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
immediately by a successful write.
I_COUNT = a discrete, associated with each output agent, that is
reset when a read is successful, set when it is not.
This discrete is used as one data item in the control of
IO_COUNT.
--```,``-`-`,,`,,`,`,,`---
IF the parameter is in the range of parameters with status bytes, then
' ASSUME - DBWS not active concurrent with this logic.

' - entity sets completion value for direct write = 1 when the
' direct write is requested.
SELECT CASE (Block mode, Parameter Data Type)
CASE (O/S Mode, Parameter data type 32 bit floating point)

Inhibit direct writes.
IF the counter for parameter (z+1) = 0, then
. IF the value of (z+1) = NaN, then
. Set bit 1 in the status byte of parameter (z+1).
. IF bit 0 is set in the status byte of (z+1), then
. Reset bit 0 in the status byte of (z+1).
. Set bit 2 in the status byte of (z+1) (Not-From-

155
. Process).
. IF the agent's type has its low order bit set, then
. Set bit 1 in the status byte of (z+1) (Bad).
. Set bit 4 in the status byte of (z+1) (Failed).
. Reset bit 5 in the status byte of (z+1)
. (No-Path).
. Set bit 2 (Not-from-Process) in the status byte of
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
. (z+1).
. Copy the value of parameter (z+1) into the value of
. parameter z.
ELSE IF the counter for parameter z = 0, then
. Copy parameter z into the value of parameter (z+1).
. Write the default status byte into the status of
. parameter (z+1).
. IF the value of z = NaN, then
. Set bits 1 and 2 in the status byte of parameter
. (z+1).
END IF.
Set the counters for parameters z and (z+1) = 1.
Enable direct writes.
CASE (NOT O/S Mode, Parameter data type 32 bit floating point)
IF [this is the agent for an Output Word OR this is the agent
. for a logical node variable, then
. IF [I_COUNT is reset AND the completion value for the
. write buffer is reset], then
. Reset IO_COUNT.
Set I_COUNT
IF NEW_ALGO is set, then
. 'Note: refer to page 5 of the paper "Application
. ' Support Services Interface" for the
. ' definition of NEW_ALGO.
. Copy parameter (z+1) to the Local Variable.
. Copy the value of parameter (z+1) to parameter z.
. Set the counters of parameters z and (z+1) to 1.
. Set the cyclic read buffer's consistency flag = 1.
. Reset IO_COUNT.
. IF this is the last agent to be processed in an entity,
. then reset NEW_ALGO.
ELSE IF the agent's configuration indicates that the agent is
. active, then
. IF the consistency parameter indicates that there is a
. new value in the cyclic read buffer, then
. IF the parameter being read is of the type 32 bit
. floating point or has been converted to 32 bit
. float, then
. IF the parameter to be read has no status byte
. (therefore it corresponds to parameter z,
. i.e., it is in the "well known" range of
. parameters and has its two low bits reset
. or it is outside of the range), then
. Inhibit direct writes and cyclic reads.
. Put the default value of the status byte
. into the status byte of parameter
. (z+1).
. IF the value of the first 4 bytes of the
. buffer = NaN, then
. Set bit 1 in the status byte of
. (z+1).
. (z+1).
. Copy the first 4 bytes of the buffer into
. the value of parameter (z+1) and into
. parameter z.
. Copy parameter (z+1) into the "local

--```,``-`-`,,`,,`,`,,`---

156
. variable".
. Reset I_COUNT.
. IF the parameter to be read corresponds to
. parameter (z+1) (i.e., it is in the "well
. known" range of parameters and has its
. low order bit set and its next to low
. order bit reset), then
. IF the value of the first 4 bytes of the
. buffer = NaN, then
. Set bit 1 in the status byte of the
. buffer.
. IF bit 0 is set in the status byte of the
. buffer, then
. Reset bit 0 in the status byte of the
. buffer.
. buffer (Not-From-Process).
. IF the agent's type has its low order
. bit set, then
. Set bit 1 (Bad) in the status
. byte of the buffer.
. IF NOT [(an Output Word) OR (a
. Logical Node variable)],
. then
. Set bit 4 (Failed) in the
. status byte of the
. buffer.
. Reset bit 5 (No-Path) in
. the status byte of the
. buffer.
. IF status bit 1 of the buffer is set, then
. buffer.
. Copy all 40 bits of the buffer into the
. "local variable".
. Copy all 40 bits of the buffer into
. parameter (z+1).
. Copy the value of parameter (z+1) into
. parameter z.
. Reset I_COUNT
. ELSE
. Configuration error! - BREAK
. END IF.
. Set the consistency value for the read buffer =
. 1.
. ELSE
. END IF.
. ELSE 'no new value in the cyclic buffer
. Increment the consistency counter but limit to 32.
. IF this is an output word's agent or a logical node
. variable's agent, then
. Increment the IO_COUNT but limit to 32.
. END IF.
. Increment the counters for parameters z and (z+1) but
. limit to 32.
. IF IO_COUNT > 3, then
. Set the No-Com. bit (Bit 0) in the status byte of
. parameter (z+1) and the local variable.
. Set the Not-from-Process bit (Bit 2) in the status
. byte of parameter (z+1) and the local variable.
. IF the low order bit of the agent is set, then
. Set the Bad bit (Bit 1) in the status byte of
. parameter (z+1) and the local variable.
. Set the Failed bit (Bit 4) in the status byte

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
157
. of parameter (z+1) and the local variable.

. Reset the No-Path bit (Bit 5) in the status
. byte of parameter (z+1) and the local
. variable.
. Permit direct writes and cyclic reads.
ELSE 'writeable or required writeable agent or no agent.
.
. Inhibit direct writes.
. IF the counter for parameter (z+1) = 0, then
. IF the value of (z+1) = NaN, then
. Set bit 1 in the status byte of parameter
. (z+1).
. Set bit 2 in the status byte of (z+1)
. (Not-From-Process).
. IF the agent's type has its low order bit set,
. then
. (Bad).
. (Failed).
. (No-Path).
. Set bit 2 (Not-from-Process) in the status byte
. of (z+1).
. Copy parameter (z+1) into local variable.
. parameter z.
. Reset the timer in the logical node's Isolation
. Timer
. Set the counter for z = 0.
. ELSE IF the counter for parameter z = 0, then
. Copy parameter z into the value of parameter (z+1).
. parameter (z+1).
. IF the value of z = NaN, then
. Set bits 1 and 2 in the status byte of
. parameter (z+1).
. Copy the parameter (z+1) into the local variable.
. Timer
. Set the counter for (z+1) = 0.
. END IF.
. limit to 32.
. IF the counter for parameter z > 6, then
. IF this is the ROut transfer location, then
. Set bit 3 (Remote) in the status bytes of (z+1)
. and the local variable.
. Set bits 6 and 7 (ATW's) in the status bytes of
. (z+1) and the local variable.
. IF this is the RCas transfer location, then
. Set bit 3 (Remote) in the status bytes of (z+1)
. and the local variable.
. Set bits 6 and 7 (ATW's) in the status bytes of
. IF [the agent is of the type "required writeable" OR
. this is the Cas transfer location], then
. Set bit 0 (No-Com.) in the status bytes of
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
. Set bit 2 (Not-from-Process) in the status

. bytes of (z+1) and the local variable.
. then

--```,``-`-`,,`,,`,`,,`---

158
. Set bit 1 (Bad) in the status byte of

. Set bit 4 (Failed) in the status bytes of
. Reset bit 5 (No-Path) in the status byte
. of (z+1) and the local variable.
. Permit direct writes.
. Reset the buffer's consistency flag.
. Reset IO_COUNT.
END IF
CASE (O/S Mode, parameter data type 16 bit string)

Inhibit direct writes.
IF the counter of parameter (z+3) = 0, then
. FOR each of the 16 status bytes in the status byte array
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
. of (z+3):
. (Not-From-Process).
. then
. (Bad).
. (Failed).
. (No-Path).
. of (z+3).
. NEXT status byte
--```,``-`-`,,`,,`,`,,`---
. Form a temporary variable "STAT" by transverse Boolean

. "OR"ing the 16 status bytes of parameter (z+3).
. Write STAT into the status of parameter (z+1).
. Copy the value of parameter (z+3) into parameter z and
. into the value of parameter (z+1).
ELSE IF the counter of parameter (z+1) = 0, then
. parameters z and (z+3).
. Set bit 2 in the status byte of (z+1) (Not-From-
. Process).
. IF the agent's type has its low order bit set, then
. Set bit 1 in the status byte of (z+1) (Bad).
. Set bit 4 in the status byte of (z+1) (Failed).
. (No-Path).
. Set bit 2 (Not-from-Process) in the status byte of
. of (z+1).
. Copy the status byte of parameter (z+1) into every status
. byte position of parameter (z+3).
ELSE IF the counter of parameter z = 0, then
. Copy parameter z into the values of parameters (z+1) and
. (z+3).
. parameter (z+1) and into each of the status bytes of
. parameter (z+3).
END IF.
Set the counters for z, (z+1), and (z+3) = 1
Enable direct writes.

--```,``-`-`,,`,,`,`,,`---
159
CASE (NOT O/S Mode, Parameter data type 16 bit string)

IF this is the agent for an Output Word or a logical node
. variable, then
. IF [I_COUNT is reset AND the completion value for the
. write buffer is reset], then
. Reset IO_COUNT.
Set I_COUNT.
IF NEW_ALGO is set, then
. Copy parameter (z+3) to the Local Variable.
. Copy the value of parameter (z+3) to parameter z and the
. value of parameter (z+1).
. Calculate the condensed status byte from the full status
. byte array in parameter (z+3) and copy into the
. status byte of parameter (z+1).
. Set the counters of parameters z, (z+1), and (z+3) to 1.
. Set the cyclic read buffer's consistency flag = 1.
. Reset IO_COUNT.
. IF this is the last agent to be processed in an entity,
. then,
. Reset NEW_ALGO.
ELSE IF the agent's configuration indicates that the agent is
. active, then
. IF the consistency parameter indicates that there is a
. new value in the cyclic read buffer, then
. IF the parameter being read is of the type 16 bit
. string or has been converted to a 16 bit
. string, then
. IF [the parameter to be read meets the
. following conditions:
. - remote parameter = a value, not a
. status [i.e., it is not a parameter
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
. (z+2)]
. - remote parameter is a discrete
. - remote parameter has status
. information [i.e., it is a
. parameter (z+1) or (z+3)]
. - remote parameter has value and full
. status [i.e., it is a parameter
. (z+3)]
. - local agent is "type 0" [i.e.,
. there is no bit selection]
. - remote parameter is not Cas
. transfer location
' Note: these conditions are a specific
' path in the logic shown in the
' Attachment to the paper
' "Agents". See that paper for
' for the agent "type".

160
START DISCRETE ACTIVE AGENT LOGIC

Showing one path in red
Error
Yes
No Yes
Remote No Bit string = data Agent's
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Data = Use default status Bit #># Prohibited
Discrete Byte for each bit. Bits in Connection
? No Data ?
Yes Type Yes ?
X+1 Bit string =data; No
Remote Use cond. Status
Type Data? Byte for each bit.
Invert Data
X+3 No Bits and
Remote No Switch Status Bits
--```,``-`-`,,`,,`,`,,`---
Status byte =data;
Data? Use default status 6 & 7 if so
Type Byte for each bit. Configured
X+2
Yes Remote
Data? Bit string = data;
Yes Use full status TypeNo
Data No
Byte array. 0
Type =
Agent?
X or
Symbols: (x+2)
No Remote Load the Value and Yes
Parameter Types: ?
X= no status info. Parameter Status of Data bit 0 Yes
= Cas Into Local Bit 0, then
X+1 = cond. Status Transfer
X+2 = cond. Status Loc? The Same for the
Only Yes Succeeding Bits.
No Local
X+3 =value plus
Full status Parameter
No Local Load Set. Bit Of Data, Length >15
Array. w/Status, into Bit 0 of
Parameter Bits?
Value and continue With Yes
Agent Types: = Output succeeding Data to fill Rest
Type 0 = high order Word 0? of Value.
bit reset Load set bit of
Yes
Type 1 = high order Data,
bit set w/Status, into
Use Bits 5-7 Of The Cas Bit 0 of value,
Transfer Location in the continue till
Set Bits 6 & 7 Bit 7; Bit 0's
Handshake as per
In Status Bytes of Done Status in 8
"Status Byte" Paper. Set
value Bits 0-4 if FH+ default
their Status to Default.
wound up. status
Figure 20:Discrete Active Agent Logic (path marked in red)

161
. then
. FOR each of the 16 status bytes in the
. status byte array of the buffer:
. IF Bit 0 (No-Com.) is set, then
. Reset bit 0.
. Set bit 2 (Not-from-Process)
. IF the agent's type has its low
. order bit set, then
. Set bit 1 (Bad) in the
. status byte.
. IF NOT [(an Output Word) OR
. (a Logical Node
. variable)], then
. Set bit 4 (Failed) in
. the status byte
. of the buffer.
. Reset bit 5 (No-Path)
. in the status
. byte of the
. buffer.
. ENDIF.
. ENDIF.
. ENDIF.
. IF Bit 1 (Bad) is set, then
. Set bit 2 (Not-from-Process)
. NEXT status byte.
. Copy the buffer into the "local variable".
. Copy the buffer into parameter (z+3).
. Form a temporary variable "STAT" by
. transverse Boolean "OR"ing the 16
. full status bytes of the local
. variable together.
. Copy the value of the buffer into
. parameter z and the value of
. parameter (z+1).
. Copy "STAT" into the status byte of
. parameter (z+1).
. Reset I_COUNT
. ELSE
'[see the Attachment to the paper "Agents"
'for the details of servicing other types
'of discrete data.]
. END IF.
. Set the consistency value for the read buffer =
. 1.
. ELSE
. END IF.
. ELSE 'no new value in the cyclic buffer.
. Increment the consistency counter but limit to 32.
. IF this is an output word's agent or a logical node
. variable's agent, then
. Increment the IO_COUNT but limit to 32.
. END IF.
. limit to 32.
. IF IO_COUNT > 3, then
. Set the No-Com. bit (Bit 0) in all status bytes of
. (z+1), (z+3), and the local variable.
. Set the Not-from-Process bit (Bit 2) in all status
. bytes of (z+1), (z+3), and the local variable.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
. IF the low order bit of the agent is set, then

. Set the Bad bit (Bit 1) in all status bytes of
. (z+1), (z+3), and the local variable.
. Set the Failed bit (Bit 4) in all the status

--```,``-`-`,,`,,`,`,,`---

162
. bytes of (z+1), (z+3), and the local

. variable.
. Reset the No-Path bit (Bit 5) in all the status
. variable.
. Permit direct writes and cyclic reads.
ELSE 'writeable or required writeable agent or no agent
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
. Inhibit direct writes.

. IF the counter of parameter (z+3) = 0, then
. FOR each of the 16 status bytes in the status byte
. array of (z+3):
. IF bit 0 is set in the status byte of (z+3),
. then
. (Not-From- Process).
. IF the agent's type has its low order bit
. set, then
. (z+3) (Bad).
. (Failed).
. Reset bit 5 in the status byte of
. (z+3) (No-Path).
. IF bit 1 is set in the status byte of (z+3),
. then
. Set bit 2 (Not-from-Process) in the status
. byte of (z+3).
. NEXT status byte
. Form a temporary variable "STAT" by transverse
. Boolean "OR"ing the 16 status bytes of
. parameter (z+3).
. Write STAT into the status of parameter (z+1).
. Copy the value of parameter (z+3) into parameter z
. and into the value of parameter (z+1).
. Timer
. Set the counters for z and (z+1) = 0.
. ELSE IF the counter of parameter (z+1) = 0, then
. parameters z and (z+3).
. (Not-From- Process).
. then
. (Bad).
. (Failed).
. (No-Path).
. of of (z+1).
. Copy the status byte of parameter (z+1) into every
. status byte position of parameter (z+3).
. Timer
. Set the counters for z and (z+3) = 0.
. ELSE IF the counter of parameter z = 0, then
. Copy parameter z into the values of parameters (z+1)
. and (z+3).
. parameter (z+1) and into each of the status
. bytes of parameter (z+3).

--```,``-`-`,,`,,`,`,,`---

163

. Timer
. Set the counters for (z+1) and (z+3) = 0.
. END IF.
. Copy parameter (z+3) into the local variable.
. Increment the counters for parameters z, (z+1), and (z+3)
. but limit to 32.
. IF this is the RCas transfer location, then
. Set bit 5 (Remote) in the value of parameter
. Set bits 6 and 7 (ATW's) in all the status
. variable.
. IF [the agent is of the type "required writeable" OR
. this is the Cas transfer location OR this is
. the variable "Output"], then
. Set bit 0 (No-Com.) in all of the status bytes
. of (z+1), (z+3) and the local variable.
. Set bit 2 (Not-from-Process) in all of the
. status bytes of (z+1), (z+3), and the
. local variable.
. then
. Set bit 1 (Bad) in all of the status bytes
. of (z+1), (z+3), and the local
. variable.
--```,``-`-`,,`,,`,`,,`---
. Set bit 4 (Failed) in all of the status

. variable.
. Reset bit 5 (No-Path) in all of the status
. variable.
'Note: the ROut transfer location
' applies only to analog
' locations - it is not needed
' in this location in the logic.
. Permit direct writes.
. Reset the buffer's consistency flag.
. Reset IO_COUNT.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
END IF.

164
GENERALIZED ANALOG BLOCK
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Cas Trans. RCas Trans. Rout Trans.
Location Location Location
Pointer Mode Setpoint Mode

Select Select Select
Input Output
Word #0 Word #0
Input Output
Algorithm
Word #1 Word #1`
Input Output
Word #2 Word #2
Figure 21: Function Block Structure: Figure 1, Generalized Analog Block

--```,``-`-`,,`,,`,`,,`---

165
Figure 2
DATA STRUCTURES
Analog Transfer Locations:
32 bit value 8 bit status Direct Write Ctr. TRANSFER_VOI
Analog Setpoint
32 bit value 8 bit status
Discrete Transfer Locations
8 bit 5* 8 bit status Direct Write TRANSFER_VOID
Bits 2-0 = value

Bits 4 & 3 = Spare (reset)
Bit 5 ="Remote Status"
Bits 6 & 7 + Remote Handshake and Doubly Wound-Up
Discrete Setpoint:
8 bit value 5 * 8 bit status
Bits 2-0 =Value

Bits 4 &3 =Spare (reset)
Bits 7-5 = Unused (reset)
Figure 22: Function Block Structure: Figure 2, Data Structures

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
--```,``-`-`,,`,,`,`,,`---

166
DISCRETE STATUS PARAMETER DETAIL
Indirect DBWS Cyclic read or

Write Direct read of:
Parameter z
Parameter z
--```,``-`-`,,`,,`,`,,`---
VALUE Ctr Parameter (z+1)

16 Bits Parameter (z+2)
Parameter (z+3)
Parameter (z+1)
Direct write
(with mask) to
parameter z, VALUE Cond. Status Ctr
(z+1). Or (z+3) 16 Bits 8 bits
Parameter (z+3) Parameter (z+2)
VALUE Full Status Ctr

16 Bits 8 & 16 Bits
Direct write or parameter z, (z+1) VALUE Full Status

16 Bits 8 & 16 Bits
Block execution. or
( +3)
Local Variable
Cyclic Read Buffer
Cyclic
Read 16 Bits + 8 * 16 bits Consts.
Figure 23: Function Block Structure: Figure 3, Analog Status Parameter Detail

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
167
Attach. 1 Status Logic ( vacant)
Attach. 2 Fast Initialization Procedure

This Attachment describes the optional procedure that can be implemented in a
Timed Standard logical node to speed the upward flow of information in a cascade
structure.

BACKGROUND
PROCEDURE OVERVIEW
REQUIREMENTS
FUNCTION BLOCK INFORMATION
CASCADE CONNECTION INFORMATION
PROCEDURE
Analog
Discrete
BACKGROUND:
The description of the function blocks generally implies that the blocks will
be executed in order from the top of the cascade to the output. For blocks
within one logical node, there is one obvious technical reason to arrange the
blocks in the logical top-down order but there are two potential reasons for the
user to purposely arrange the blocks in the reverse order. One must remember that
blocks running in different logical nodes can not be synchronized, even if they
are in a cascade structure. When a cascade spans logical nodes, the execution
frequency will have to be arranged to reduce dead time to an acceptable level.
Why arrange the blocks in the top-down order? Because the best control loop
performance is achieved by executing a block using inputs that include the
minimum possible dead time. When one analyses the information flow in a cascade,
it is obvious that the minimum dead time is achieved by executing the topmost
block, passing its output to the next block and executing it, etc. until the
Setpoint for the output block is calculated and passed to the output block, which
will execute last.
One operating characteristic that can force the user to arrange the blocks in
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
the reverse order is the potential for operator input into the middle of a
cascade structure to be overwritten by a higher level block. For example, if an
operator sets an interior block into Auto mode, changes the Setpoint, and returns
the block to Cas mode, the system should not lose the new value nor bump the
process. If there is no protection for this action, a user may feel that it is
necessary to arrange the blocks in reverse order to minimize the possibility of
this problem.
In the SP-50 User Layer, there is complete protection against this. The
prefetch of the status of the secondary's transfer location value partially
solves this problem. The Data Base Write Service solves most of the rest of the
problem by writing a new value of the Setpoint or Output into both the addressed
location and the corresponding transfer location. The remaining window for a
problem is eliminated by having all secondaries discard the first cascade value
written after a mode change and restore the previous value (the internal value
TRANSFER_VOID - see the paper "Function Block Structure" and the Appendix paper
"Fundamental Control Structure" - page
14).

--```,``-`-`,,`,,`,`,,`---

168
The second reason to arrange the blocks in reverse order is to speed up the
flow of information going "up" the cascade. If the blocks are executed
relatively slowly, and there are several blocks in the cascade, an operator will
notice that a mode change at the bottom of the cascade will take some noticeable
time to reflect itself as IMan mode at the top of the cascade. During that time,
the operator and higher level control programs are given conflicting information.
A partial solution for this problem is the subject of this paper. By

minimizing the problem, the user may be free to arrange the function blocks in
the forward order which is preferred for control and easy maintenance.
It certainly would be possible and advantageous to provide a more complete

solution to this problem. Any Standard Field Device may indicate that the fast
initialization procedure is supported and, in fact, do a more complete job of
solving the problem than is specified for the procedure by this paper.
PROCEDURE OVERVIEW:
--```,``-`-`,,`,,`,`,,`---
The model of the fast initialization procedure involves:

1) the calculation of several pieces of data describing the current
state of the block during the normal execution of each block. This
data is left in a form that can be handled easily by the later
initialization procedure.
2) the generation of a list of "cascade paths" during the normal
execution of the blocks. Each entry in the list identifies the
primary and secondary for the path.
3) During the portion of the timed standard logical node's cycle that
has been set aside for overhead (the 20%), the logical node will
process each cascade path in the table, in reverse order - the last
path first. By combining the information available from each block
and the path information from the table, the information flowing
upward in the cascade can be passed from the bottom to the top of the
portion of the cascade located in one logical node in one cycle time.
This procedure will pass the following information up the cascade and set the
information into the status byte of the Output Word, the block actual mode, the
Setpoint status byte, and the Input Word and transfer location status bytes:
1) The setting and clearing of LO mode under certain conditions (see the
next paragraph for the exceptions).
2) A failure in the path to the process.
3) A recovery from a failure under certain conditions.
4) The "Path-to-the-Process" status.
5) Any wound-up condition (wound-up hi, wound-up lo, or doubly wound
up).
6) The reset of a wound-up high or of a wound-up low condition. In some
cases, the block itself may have to execute once to update the actual mode.
This solution is only a partial solution because it will NOT pass the
following information up the cascade:
1) LO mode that is set concurrently with a failure unless the LO mode
was set by a Field Bus command or by keylock in a block in the local
logical node.
2) the resetting of a failure if:
- LO mode is set but not known to be passing up
OR
- if the handshake using bit 5 of the status byte is not
complete.
3) the transition out of the IMan mode state.
4) In a block that has 1 Output cascade blocked by a failure and a
second blocked by LO mode, it will pass NEITHER condition up the
cascade.
The exception in case (1) and the first exception in case (2) exist because of
the use of bit 5 in the status bytes to show the direction for LO mode AND the
handshake for failures. The exceptions could be eliminated by extended logic in

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
169
the procedure but such an extension is not included in the capability required
for this option.
The second exception in case (2) and exception (3) exist because there must
be assurance in all cases that the higher blocks in the cascade have initialized
or received the failure information. This would require the addition of cycle
counters to the logic and would unduly increase the complexity of the logic.
Because doubly wound up and IMan are not cleared, the LO and Fail can be cleared
immediately since the blocks will still initialize as the clearing of doubly
wound up moves up the cascade. Note that the subsequent block operations will
pass all of this information correctly, just slower.
The very rare case (4) could have been handled by additional logic but was
not judged worthwhile.
When the procedure is applied to discrete blocks, it is assumed to update the

status information in the variable "Output", not in the Output Words. Note that
"Output" does not have a condensed status byte while an Output Word does.
REQUIREMENTS:
Bit DH in the logical node options non-time critical bit string
(N_TIME_CRIT0; see page 26 of the paper "Data Owner Structure - Logical Nodes)
indicates support for "fast initialization", the subject of this attachment. If
this procedure is implemented, the bit will be set. If it is not supported, the
bit will be reset. Any logical node that can not support at least 3 function
blocks, or can only support blocks with hardware I/O, must show the bit as reset.
A logical node that has the bit set but is only configured to execute one or two
function blocks (i.e., CB = 2 or CB = 1), may turn the procedure off (but leave
the options bit set).
If the procedure is supported, the logical node must appear to be executing

the procedure defined in this Attachment. It is not necessary that the procedure
given here be followed, only that it APPEAR to be followed. A device that does a
more complete procedure is allowed and encouraged as long as the extra
functionality passes correct information up the cascade and does not affect the
normal execution order of the blocks.
There are a number of variables that are named and defined here; none of them
are accessible from Field Bus and they are not required in an actual
implementation.
From the perspective of higher level devices, the only impact that exists
from this entire procedure is the presence of bit DH in the options bit string.
Of course, there may be a large impact on the timeliness of the information made
available to, and displayed by, such a higher level device.
FUNCTION BLOCK INFORMATION:

When a function block executes in a Timed Standard logical node that supports
this procedure, it is modeled as calculating and leaving behind certain
information. This information is not accessible from Field Bus. Each individual
function block definition will provide detailed information concerning the
calculation of the values of these variables.
The definitions of variables that follow refer to "outputs" #0, #1, and #2.
If the block outputs are analog, output #0 = Output Word #0, output #1 = Output
Word #1, and output #2 does not exist. If the block outputs are discrete, output
#0 refers to bit #0 in the value "Output". Output #1 refers to bit #1 of
"Output", and output #2 to bit #2.

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
170
The variables are:

PATH_0_TO_BLK - analog blocks only.
- this logical is set if output #0 alone is currently
supporting a legitimate cascade connection back to
the block. Note: if output #1 can simultaneously
support a legitimate cascade connection back to the
block, this logical is reset.
PATH_1_TO_BLK - analog blocks only.
- this logical is set if output #1 alone is currently
supporting a legitimate cascade connection back to
the block. Note: if output #0 can simultaneously
support a legitimate cascade connection back to the
block, this logical is reset. Note: the only
Standard function block that can support this is the
Splitter block.
PATH_0&1_TO_BLK - analog blocks only.
- this logical is set if both outputs #0 and #1 are
currently supporting a legitimate cascade connection
back to the block. Note: The only Standard
function block that can support this is the Splitter
block.
PATH_TO_BLK - discrete blocks only.
- this logical is set if the block can support
legitimate cascade connections back to the block
"Output" parameter.
LO_UP_TO_BLK - this logical is set if LO mode can be propagated up
to this block.
LO_BLK_UP - this logical is set if LO mode can be propagated
further up a cascade from this block.
FAIL_BLK_UP - this logical is set if a failure acknowledgement
request can be propagated further up the cascade
from this block. If an algorithm is configured with
"STOP_FAIL" = 1, then FAIL_BLK_UP = 0.
PATH_TO_CTL - this logical is set if the Cas Transfer Location
is supported and is pointed to by Input #0's agent.
This parameter is mode independent.
Note: in discrete blocks, this logical will only be
set if the three Setpoint bit pointers point to the
first three bits of the Cas Transfer Location (in
order) and Boolean operators are not used on any
Setpoint bits. Also, the block's "pass
initialization" option must be set if it is present.
PATH_TO_1 - analog blocks only.
- this logical is set if Input #1 is currently
supporting a legitimate cascade connection.
Note: the only Standard function block that can
support this is the Selector block; in that block,
this logical will be set only if the Input #1 agent
is some kind of writeable agent. Also, the block's
"pass initialization" option must be set.
PATH_TO_2 - analog blocks only.
--```,``-`-`,,`,,`,`,,`---
- this logical is set if Input #2 is currently

supporting a legitimate cascade connection.
Note: the only Standard function block that can
support this is the Selector block; in that block,
this logical will be set only if the Input #2 agent
is some kind of writeable agent. Also, the block's
"pass initialization" option must be set.
REV_0 - for analog blocks:
this logical is set if the algorithm has reverse
action between its Setpoint and Output #0.
- for discrete blocks:
this logical is set if the Output Word bit pointer
and the agent's inverting for Output bit #0 combine
to invert the bit between Output #0 and the

171
secondary.
REV_1 - for analog blocks:
this logical is set if the algorithm has reverse
action between its Setpoint and Output #1.
Note: the only Standard analog function block
that can support this is the Splitter
block.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
secondary.
REV_2 - not used for analog blocks.
secondary.
BLOCK_WUH - this logical is set if the block itself would
generate a wound-up-high indication on its own
Setpoint. This includes the effect of Output
limits, direct/reverse action, block logic, Setpoint
limits, and mode. Note: in discrete blocks, this
parameter is a simplification; it is set if any
bit's status would be set but only for bits
configured to their corresponding bit in Output and
on to cascade connections (see below). It will
block the fast resetting of wound-up-high for all
three bits if it is set.
BLOCK_WUL - this logical is set if the block itself would
generate a wound-up-low indication on its own
Setpoint. This includes the effect of Output
limits, direct/reverse action, block logic, Setpoint
limits, and mode. Note: in discrete blocks, this
parameter is a simplification; it is set if any
bit's status would be set but only for bits
configured to their corresponding bit in Output and
on to cascade connections (see below). It will
block the fast resetting of wound-up-low for all
three bits if it is set.
LO_UP - this logical will be reset at each block execution
except it will be set if LO_BLK_UP = 1 AND any of
the following conditions exist:
1) the block's actual mode is pure LO
--```,``-`-`,,`,,`,`,,`---
2) the block is keylocked into LO mode.

3) the block is forced to LO mode by a
configured input such as the PID's force
tracking or the discrete block's Human
Interface interlock.
This variable will be manipulated by both the block
and the procedure to be defined below. Note that
there are conditions in which LO mode may be passing
up the cascade but these tests do not set LO_UP.
LO_UP0 - these logicals will be used by the procedure. They
LO_UP1 will be reset every time the block executes except
LO_UP2 they will be set if the block is discrete and the
corresponding bit in the block's Setpoint is not
configured through the algorithm to its
corresponding bit in Output and on to a cascade
connection (see below).
Note: these logicals will be set by the procedure
if the procedure can determine unambiguously that
LO mode is being passed up the cascade. They will
be associated with connections as:
LO_UP0 = LO passing up to the block through
Output Word #0 or discrete Output
bit #0.

172

Output Word #1 or discrete Output
bit #1.
discrete Output bit #2.
CASCADE CONNECTION INFORMATION:

When a function block executes in a logical node that supports this
procedure, it is modeled as calculating and adding "cascade connection"
information to a table structure maintained by the logical node. Each entry in
this table will correspond to an active cascade connection. An active cascade
connection is an on-logical-node communication path that has, on one end, an
Output that can support a cascade and has an active agent. The active agent must
point to a Cas Transfer Location value, an Input #1 value and status (analog), an
Input #2 value and status (analog), or an Output Word #0 bit (discrete,
specifically in a Discrete Register block).
No entry will be placed in this table by a block in O/S mode.
If the primary of the "cascade connection" is a discrete block, there are

certain additional requirements. The internal configuration of the block must:
1) support discrete cascades.
2) the 3 Setpoint bits must be configured to the 3 low-order bits of
Output and in order (bit #0 to bit #0).
3) a separate "cascade connection" will be shown for each active bit
among the 3 low-order bits in "Output".
--```,``-`-`,,`,,`,`,,`---
The logical node will use the information, in reverse order, to calculate the
flow of information "up" the cascade during the logical node's overhead time.
This information is not accessible from Field Bus. Each entry will provide the
following detailed information for each path:
DATA_TYPE - a logical that indicates, if set, that the cascaded
information is a discrete bit.
PRIMARY - this integer will contain the block number that
is the primary for this path. The algorithm in the
primary block must be able to support a cascade
connection below itself.
PRI_CONNECT - analog:
this integer will contain the primary's Output
Word parameter number that is the source of this
path. This connection must be able to support a
cascade.
- discrete:
this integer will contain a dummy parameter number
that identifies the bit in the word "Output". The
value of this integer can have bits 0-9, EH, and FH
reset. The value in bits AH-DH can represent an
integer value of 0, 1, or 2. Such a configuration
follows the configuration rules of a Type 1 agent's
pointer parameter (see page 16 of the paper
"Agents") and will be uniquely different from any
possible normal parameter identification.
SECONDARY - this integer will contain the block number that
is the secondary for this path.
SEC_CONNECT - analog:
this integer will contain the secondary's parameter
number that is the target of this path. The
parameter number must be the number of one of the
following:
- the Cas Transfer Location value and its
status byte.
- the Input Word #1 value and its status byte.
- the Input Word #2 value and its status byte.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
173
- discrete:
this integer will not necessarily match the
parameter of the Output Word's agent's pointer
parameter. It can be the parameter of the
secondary's bit expressed as a Type 1 agent's
pointer parameter (see page 16 of the paper
"Agents"). The inverting indicator will be reset
since its information is carried by the parameter
REV_x defined above.
The secondary's parameter must be one of the

following:
- the Cas transfer location
- Input Word #1 or #2.
- Output Word #0, #1, or #2.
PROCEDURE:
The following logic will be executed during the 20% of the logical node cycle
that is allocated to the logical node's overhead. It will be executed for each
--```,``-`-`,,`,,`,`,,`---
path in the "cascade connection" table, starting with the last path entered
during the execution of the previous cycle of blocks.
This procedure is written to account for all of the Standard function blocks
except the Timer. It specifically recognizes the two cascaded outputs of the
Splitter block and the three cascaded inputs of the Selector block. The
constraints imposed on discrete cascades are those of the normal block
functioning. However, as noted above, the procedure is incomplete. Some
information flow will not occur until the next normal execution of the function
block and some information is not passed up the cascade by this procedure.
However, no incorrect information is inserted in the normal process by this
procedure.
An analog cascade connection that has the Cas transfer location or the RCas
transfer location of the Timer block as its secondary will be handled exactly as
any other analog cascade connection. There can be no analog cascade connection
that has the Timer block as its primary. A discrete cascade connection that has
the Timer block as its secondary is accounted for in the following logic.
A discrete cascade connection that has the Timer block as its primary is not
covered in the logic. The logic for this case is explained in the block
algorithm. It is actually much simpler than other discrete blocks but quite
different.
Throughout this logic, reference will be made to the states shown in Figure 1
of Attachment 1 to the paper "Status Byte".
This procedure is written as if data base values are changed directly. That
will not be done in an actual implementation. Rather, the changed values will be
collected as working variables and written to the Field Bus accessible data base
with function block reads inhibited as indicated by the instruction step near the
end of the procedure.
START
Set temporary logical ALERT = 0
' This local variable is used in the logic for discrete cascades.
' This step is NOT included in the GOTO that is called for near the
' end of the logic.
'

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
174
' **************************************************************
' **************************************************************
' ** **
' ** ANALOG CASCADE LOGIC **
' ** **
' **************************************************************
' **************************************************************
'
IF DATA_TYPE = 0, then
'
' The entry in the table will identify the primary block, its
' connection, the secondary block, and its connection. In this logic,
' the connection to the secondary could be to the Cas transfer location,
' Input #1, or Input #2; the letter "x" will be used in variable names
' to designate the connection. The connection to the primary could be
--```,``-`-`,,`,,`,`,,`---
' to Output Word #0 or #1; the letter "y" will be used in variable names
' to designate the connection. In some cases, reference must be made to
' the "other" Output Word - the letter "z" will be used for that
' connection (i.e., if y = Output Word #0, then z = Output Word #1 and
' vice versa).
'
' Note that Output Word #1 as a cascaded output and ROut can not
' coexist. Therefore, changes to the ROut location do not include a
' test of which output word is being processed: it must be #0 if ROut
' exists.
'
IF secondary's algorithm <> analog, then
BREAK.
IF secondary's PATH_TO_x = 0, then
BREAK.
' No need to process this connection if the secondary can not
' support the cascade connection.
IF [(secondary's LO_UP = 1) AND (secondary's algorithm <> Timer)], then
' Note that LO is not indicated in the RCas nor ROut transfer
' locations.
Set bit 3 in the status byte of primary's connection = 1.
' Note: this step generates one of states 5-8 in Figure 1 of
' Attachment 1 to the paper "Status Byte".
IF bit 4 in the status byte of primary's connection = 0, then
Set bit 5 in the status byte of primary's connection = 1.
' Note: this step converts state 5 to state 6.
' Unfortunately, states 7 and 8 are ambiguous.
Set bits 7&6 in the status byte of primary's connection = 11B.
IF bit 4 in the status byte of primary's ROut location = 0, then
Set bit 5 in the status byte of primary's ROut location =
HOLD_PATH
' See page 7 of paper "Function Block Structure"
' for a description of HOLD_PATH.
IF bit 3 in the ROut status byte = 0, then
Set bits 7&6 in the Status byte of the primary's ROut transfer
location = 11B.
' If the above test were not included, this could
' override the Remote handshake - see Figure 2 in
' Attachment 2 to the "Status Byte" paper.
IF primary's LO_UP_TO_BLK = 1, then
Set primary's LO_UPy = 1.
IF [(primary's PATH_y_TO_BLK = 1) OR (primary's
PATH_0&1_TO_BLK = 1 AND LO_UPz = 1)], then
Set the IMan and LO bits in primary's actual mode byte
= 1.
IF primary's LO_BLK_UP = 1, then
Set primary's LO_UP = 1.
Set bit 3 in the status byte of primary's Setpoint
= 1.
IF bit 4 in the status byte of primary's Setpoint =
0, then
Set bit 5 in the status byte of primary's

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
175
Setpoint = 1.
Set bits 7&6 in the status byte of the primary's
Setpoint = 11B.
IF bit 4 in the status byte of primary's RCas
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
transfer location = 0, then

Set bit 5 in the status byte of primary's RCas
transfer location = HOLD_PATH.
IF bit 3 in the RCas status byte = 0, then
Set bits 7&6 in the status byte of the
primary's RCas transfer location = 11B.
' If the above test were not
' included this could override the
' Remote handshake - see Figure 2 in
' Attachment 2 to the "Status Byte"
' paper.
IF PATH_TO_CTL = 1, then
Set bit 3 in the status byte of primary's Cas
transfer location = 1.
IF bit 4 in the status byte of primary's Cas
transfer location = 0, then
Set bit 5 in the status byte of the
primary's Cas transfer location = 1.
primary's Cas transfer location = 11B.
IF PATH_TO_1 = 1, then
Set bit 3 in the status byte of primary's Input
--```,``-`-`,,`,,`,`,,`---
Word #1 = 1.
IF bit 4 in the status byte of primary's Input
Word #1 = 0, then
primary's Input Word #1 = 1.
primary's Input Word #1 = 11B.
Set bit 3 in the status byte of primary's Input
Word #2 = 1.
IF bit 4 in the status byte of primary's Input
Word #2 = 0, then
primary's Input Word #2 = 11B.
'
' ************************************************************
' * A2 Move a no-failure status up the cascade *
' * and adjust the path-to-the-process *
' * if LO mode is not set. *
' ************************************************************
'
IF bits 4&3 in the status byte of the secondary's connection = 00B,
then
' Note that this step resets LO if it was passing up but
' has now cleared providing there is only 1 active cascade.
Set bit 3 in the status byte of the primary's connection = 0
Set the temporary string TEMP_STR = bits 5&4 in the status byte
of the secondary's connection.
Set bits 5&4 in the status byte of the primary's connection =
TEMP_STR.
' Note: this transitions state 2 to state 1 or state 3 if
' it was set.
Set bits 5&4 in the status byte of the primary's ROut transfer
location = TEMP_STR.
Set temporary logical FLAG = 0.
IF primary's PATH_y_TO_BLK = 1, then
FLAG = 1.
Set HOLD_PATH = bit 1 of TEMP_STR
IF primary's PATH_0&1_TO_BLK = 1, then

176
FLAG = 1.
' Note: the following logic moves the no-failure status
' up the cascade even if there is a second cascade
' structure with a failure or LO status.
IF bits 5-3 of the status byte of the primary's Output Word z
= 000B, then
TEMP_STR = 00B.
HOLD_PATH = 0.
' When the IF is true, the path status is known to
' be good.
ELSE IF bits 5-3 of the status byte of the primary's Output
Word z = 100B, then
HOLD_PATH = bit 1 in TEMP_STR
ELSE IF TEMP_STR = 00B, then
HOLD_PATH = 0
ELSE IF HOLD_PATH = 0, then
TEMP_STR = 00B.
ENDIF
IF FLAG = 1, then
IF primary's LO_UP = 0, then
IF (bits 5-3 in the status byte of the primary's Setpoint
= 001B), then
' *********************************
' * LO passing down! *
' *********************************
Set bit 4 in the status byte of the primary's RCas
transfer location = HOLD_PATH.
IF [(bit 3 in the status byte of the primary's
Cas transfer location = 0) OR (bits 5-3 in
the status byte of the primary's Cas
transfer location = 101B)], then
Set bits 5-3 in the status byte of the
primary's Cas transfer location =
000B.
Output Word #1 = 0) OR (bits 5-3 in the
status byte of the primary's Output Word
#1 = 101B)], then
--```,``-`-`,,`,,`,`,,`---
primary's Output Word #1 = 000B.
#1 = 101B)], then
primary's Output Word #2 = 000B.
IF [(bit 3 in the status byte of the primary's Setpoint
= 0) OR (bits 5-3 in the status byte of the
primary's Setpoint are 101B)], then
' *********************************
' * No LO mode or the old one *
' * that needs to be cleared. *
' *********************************
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

IF >1 mode bits are set in the actual mode,
then
set the LO mode bit in the actual mode =
0.
Set bit 3 in the status byte of the primary's
Setpoint = 0.
Setpoint = TEMP_STR.

177

RCas transfer location = TEMP_STR.
Cas transfer location = 0) OR (bits 5-3
in the status byte of the primary's Cas
transfer location = 101B)], then
primary's Cas transfer location =
TEMP_STR.
#1 = 101B)], then
primary's Output Word #1 = 0.
primary's Output Word #1 = TEMP_STR.
#1 = 101B)], then
primary's Output Word #1 = 0.
primary's Output Word #1 = TEMP_STR.
'
' ************************************************************
' * A3 *
' * Move a no-failure status up the cascade if *
' * LO mode is known to be passing up the cascade. *
' ************************************************************
'
IF bits 4&3 in the status byte of the secondary's connection = 01B, then
IF [(LO_UP in the secondary = 1) AND (secondary's algorithm <>
Timer)], then
' Note: this is specifically selecting states 5 or 6 but
' since it is known that LO mode is being passed
' up, state 5 is eliminated.
connection = 10B.
Set bit 4 in the status byte of the ROut location = 0.
Set bit 5 in the status byte of the ROut location = HOLD_PATH.
IF primary's LO_UP = 1, then
Set bits 5&4 in the status byte of primary's Setpoint
= 10B.
Set bit 4 in the status byte of the RCas transfer
location = 0.
Set bit 5 in the status byte of the RCas transfer
location = HOLD_PATH.
--```,``-`-`,,`,,`,`,,`---

Cas transfer location = 10B.
Input Word #1 = 10B.
'

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
178
' ************************************************************
' * A4 *
' * Move failure with request for *
' * acknowledgement up the cascade. *
' ************************************************************
'
IF bits 5&4 in the status byte of the secondary's connection = 01B, then
IF bit 4 in the status byte of the primary's connection = 0, then
' Because of this step, the following logic only operates
' on the first cycle after a failure - it allows
' acknowledgement after that.
connection = 01B.
' Note: this step transitions 1 of states 3, 5, or
' 6 to either state 4 or 7.
connection = 11B.
location = 11B.
Set bits 7&6 in the status byte of the primary's ROut
transfer location = 11B.
' If the above test were not included, this
' could override the Remote handshake - see
' Figure 2 in Attachment 2 to the paper
' "Status Byte".
IF the ROut actual mode bit = 1, then
ROut transfer location = 0.
' This logic will request acknowledgement from
' anyone with an active mode bit!
FLAG = 1.
IF bit 4 in the status byte of the primary's z
connection = 1, then
FLAG = 1.
IF FLAG = 1, then
IF FAIL_BLK_UP = 0, then
FLAG = 0
IF the requested mode bit = higher priority than Auto,
then
FLAG = 0
IF PATH_TO_1 = 0 AND PATH_TO_2 = 0, then
IF the requested mode bit = higher priority than
Cas, then
FLAG = 0
' The net of the above four IF's is that
' there is no one above the primary from
' whom to request acknowledgement if FLAG
' ends up = 0.
IF FLAG = 0, then
IF block mode is to be changed to Man on failure,
then
Set actual mode byte to 00H.
Set the Man mode bit in the actual mode byte.
IF the requested mode bit <> Man, then
Set requested mode byte to 00H.
Set Man mode bit in the requested mode
byte.
Increment the static data base revision
number by 1.
Set notification of an unrequested mode
change or leave flag for the block to
do it at its next execution.
Set the IMan mode bit in the actual mode byte.

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
179
Set bits 7-4 in the status byte of the primary's

Setpoint = 1111B.
Set bits 5&4 in the status byte of the primary's RCas
transfer locations = 11B.
RCas transfer location = 11B.
Set bits 7-4 in the status byte of the primary's Cas
IF FLAG = 1, then
Setpoint = 0.
IF the RCas actual mode bit = set, then
RCas transfer location = 0.
IF the Cas actual mode bit = set, then
IF the requested mode bit set is lower in priority
than Man, then
'
' ************************************************************
' * A5 *
' * Move failure without request for *
' ************************************************************
'
IF bits 5&4 in the status byte of the secondary's connection = 11B,
then
Set bits 5&4 in the status byte of the primary's connection = 11B.
Set bits 7&6 in the status byte of the primary's connection = 11B.
location = 11B.
location = 11B.
' If the above test were not included, this could
--```,``-`-`,,`,,`,`,,`---
' override the Remote handshake - see Figure 2 in

FLAG = 1.
IF bits 5&4 in the status byte of the primary's z connection
= 11B, then
FLAG = 1.
IF FLAG = 1, then
Set bits 7-4 in the status byte of the primary's Setpoint =
1111B.
Set bits 5&4 in the status byte of the primary's RCas transfer
locations = 11B.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
180
Set bits 7&6 in the status byte of the primary's RCas

Set bits 7-4 in the status byte of the primary's Cas
Set bits 7-4 in the status byte of the primary's Input
Word #1 = 1111B.
Set bits 7-4 in the status byte of the primary's Input
Word #2 = 1111B.
'
' ************************************************************
' * A6 *
' * Move a not-wound-up-high status up the cascade. *
' * *
' ************************************************************
'
IF bit 6 in the status byte of the secondary's connection = 0, then

IF bits 7&6 in the status byte of the primary's connection <> 11B,
then
Set bit 6 in the status byte of the primary's connection = 0.
IF bits 7&6 in the status byte of the primary's ROut transfer
location <> 11B, then
Set bit 6 in the status byte of the primary's ROut
IF [(primary's PATH_y_TO_BLK = 1), then
IF REV_x = 0, then
IF BLOCK_WUH = 0, then
IF bits 7&6 in the status byte of the primary's
Setpoint <> 11B, then
primary's Setpoint = 0.
RCas transfer location <> 11B, then
primary's RCas transfer location
= 0.
Cas transfer location <> 11B, then
primary's Cas transfer
location = 0.
Input Word #1 <> 11B, then
IF REV_x = 1, then
IF BLOCK_WUL = 0, then
Setpoint <> 11B, then
primary's Setpoint = 0.
RCas transfer location <> 11B, then

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
181

primary's RCas transfer location
= 0.
Cas transfer location <> 11B, then
primary's Cas transfer
location = 0.
'
' ************************************************************
' * A7 *
' * Move a not-wound-up-low status up the cascade. *
' * *
' ************************************************************
'
' This logic is exactly the same as given for bit 6 above except
' that bits 6 and 7 are reversed.
'
'
' ************************************************************
' * A8 *
' * Move a wound-up-high status up the cascade. *
' * *
' ************************************************************
'
Set bit 6 in the status byte of the primary's connection = 1.
Set bit 6 in the status byte of the primary's ROut transfer
location = 1.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
IF [(primary's PATH_y_TO_BLK = 1), then FLAG = 1.
IF [(primary's PATH_0&1_TO_BLK = 1) AND (REV_z = 0)], then
IF bit 6 in the status byte of the primary's z connection = 1,
then
FLAG = 1.
IF [(primary's PATH_0&1_TO_BLK = 1) AND (REV_z = 1)], then
IF bit 7 in the status byte of the primary's z connection = 1,
then
FLAG = 1.
--```,``-`-`,,`,,`,`,,`---
IF FLAG = 1, then
IF REV_x = 0, then
Set bit 6 in the status byte of the primary's Setpoint
= 1.
Set bit 6 in the status byte of the primary's Cas
Set bit 6 in the status byte of the primary's Input
Word #1 = 1.

182
Word #2 = 1.
IF REV_x = 1, then
Set bit 7 in the status byte of the primary's Setpoint
= 1.
Set bit 7 in the status byte of the primary's Cas
Word #1 = 1.
Word #2 = 1.
'
' ************************************************************
' * A9 *
' * Move a wound-up-low status up the cascade. *
--```,``-`-`,,`,,`,`,,`---
' * *
' ************************************************************
'
' This logic is exactly the same as given for bit 6 immediately
' above except that references to bits 6 and 7 are reversed.
'
'
' ************************************************************
' * A10 *
' * Conclusion of the analog logic. *
' * *
' ************************************************************
'
IF the next entry in the cascade connection table has the same primary,
then
GOTO the beginning of the above logic and do that cascade.
IF bits 6 and 7 in the status byte of the Setpoint are both set, then
set the IMan bit in the actual mode of the primary.
Make the changes to the Field Bus accessible data base with Field Bus
read access inhibited.
Clear the entries in the "cascade connection" table that have just been
worked.
'
' **************************************************************
' **************************************************************
' ** **
' ** DISCRETE CASCADE LOGIC **
' ** **
' **************************************************************
' **************************************************************
'
IF DATA_TYPE = 1, then
'
' The entry in the table will identify the primary block, the bit
' index in the value of Output, the secondary block, and the bit index
' in the secondary's bit string. The connection to the secondary can
' be to the Cas transfer location or to the block's Input or Output
' Words #0.
'
' In some cases, reference must be made to any of the three Output
' bits in the primary; the letter "z" will be used in that case (for
' example, LO_UPz = any of the three values LO_UP1, LO_UP2, or LO_UP3.
'
' Note that an Output bit that is not configured to a destination
' has a status byte with bits 2-7 all set.
'

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
183
' Note that discrete blocks do not support an ROut transfer

' location. In their RCas status bytes, bit 3 is available to carry LO
' mode and bits 7&6 are not involved in the remote handshake.
'
IF [(secondary's algorithm <> discrete) AND (secondary's algorithm <>
Timer)], then
BREAK
IF secondary's algorithm = Discrete Register, then
IF secondary's parameter <> Output Word #0, then
BREAK
IF secondary's algorithm = Timer, then
IF secondary's parameter NOT in LIST (Input Word #1, Input Word #2,
Output Word #0, Output Word #1), then
BREAK
IF [(secondary's parameter <> Cas transfer location) AND (secondary's
algorithm <> Discrete Register) AND (secondary's algorithm <>
Timer)], then
BREAK.
' No need to process this connection if the secondary can not
' support the cascade connection.
IF primary's algorithm = Timer, then
Execute the special procedure given in the Timer algorithm
description.
'
' ************************************************************
' * D1 *
' * Move LO mode up the cascade. *
' * *
' ************************************************************
'
Set temporary logical FLAGLO = 0.
IF secondary's LO_UP = 1, then
FLAGLO = 1.
IF (secondary's algorithm = Discrete Register) AND (secondary bit's
OUTLO = 1, then
FLAGLO = 1.
' Note: this flag is used in the next step and again 2 pages
' later.
IF FLAGLO = 1, then
Set bit 3 in the status byte of the primary's Output bit = 1.
' Note: this step generates one of states 5-8 in Figure 1 of
IF bit 4 in the status byte of the primary's Output bit = 0, then
Set bit 5 in the status byte of primary's Output bit = 1.
' Note: this step converts state 5 to state 6.
' Unfortunately, states 7 and 8 are ambiguous.
Set bits 7&6 in the status byte of the primary's Output bit = 11B.
IF primary's LO_UP_TO_BLK = 1, then
Set primary's LO_UPy = 1.
IF [(primary's PATH_TO_BLK = 1), then
IF any 2 of primary's LO_UPz's are = 1, then
Set the IMan and LO bits in primary's actual mode
byte = 1.
Set primary's LO_UP = 1.
FOR each of the status bytes in the primary's
Setpoint:
Set bit 3 = 1
IF bit 4 in the status byte = 0, then
Set bit 5.
Set bits 7&6 = 11B.
FOR each of the status bytes in the primary's
RCas transfer location:
Set bit 3 = 1
Set bit 5.
--```,``-`-`,,`,,`,`,,`---
Set bits 7&6 = 11B.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
184
FOR each of the status bytes in the
primary's Cas transfer location:
Set bit 3 = 1
Set bit 5 = 1.
Set bits 7&6 = 11B.
ELSE IF primary's LO_BLK_UP = 1, then
FOR the status byte of the bit in the primary's
Setpoint corresponding to the cascade:
Set bit 3 = 1
Set bit 5.
Set bits 7&6 = 11B.
FOR the status byte of the bit in the primary's
RCas transfer location corresponding to
the cascade:
Set bit 3 = 1
Set bit 5.
Set bits 7&6 = 11B.
FOR the status byte of the bit in the
primary's Cas transfer location
corresponding to the cascade:
Set bit 3 = 1
Set bit 5 = 1.
Set bits 7&6 = 11B.
ENDIF
'
' ************************************************************
' * D2 Move a no-failure status up the cascade *
' * and adjust the path-to-the-process *
' * if LO mode is not set. *
' ************************************************************
'
IF bits 4&3 in the status byte of the bit in the secondary = 00B, then
' Note that this step resets LO status if it was passing up
' but has now cleared.
Set bit 3 in the status of the primary's Output bit = 0
Set the temporary string TEMP_STR = bits 5&4 in the status byte
of the secondary's bit.
Set bits 5&4 in the status byte of the primary's Output bit =
TEMP_STR.
' Note: this transitions state 2 to state 1 or state 3 if
' it was set.
Set temporary logical FLAG = 0
IF primary's PATH_TO_BLK = 1, then
IF the primary's LO_UP = 0, then
IF primary's LO_UPy = 0, then
IF bit 3 in the status byte of the bit in the
primary's Setpoint corresponding to the
cascade = 0, then
FLAG = 1
Set bits 5&4 = TEMP_STR.
' *********************************
' * No LO mode. *
' *********************************
IF (bits 5-3 in the status byte of the bit in
the primary's Setpoint corresponding to
the cascade = 001B), then
FLAG = 1
' *********************************
' * LO passing down! *
' *********************************
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
185
IF (bits 5-3 in the status byte of the bit in

the primary's Setpoint corresponding to
the cascade are = 101B), then
FLAG = 1
Set bit 3 = 0.
' *********************************
' * The old LO mode bit that *
' * needs to be cleared. *
' *********************************
IF FLAG = 1, then
FOR the status byte of the bit in the primary's RCas
transfer location that corresponds to the cascade:
IF (bit 3 in the status byte = 0 OR bits 5-3 in the
status byte = 101B), then
Set bit 3 = 0.
FOR the status byte of the bit in the primary's Cas
transfer location that corresponds to the
cascade:
IF (bit 3 in the status byte = 0 OR bits 5-3 in
the status byte = 101B), then
Set bit 3 = 0.
'
'
' ************************************************************
' * D3 *
' * Move a no-failure status up the cascade if *
' * LO mode is known to be passing up the cascade. *
' ************************************************************
'
IF bits 4&3 in the status byte of the secondary's bit = 01B, then
' Note: this is specifically selecting states 5 or 6.
IF FLAGLO = 1, then
' Note: it is known that LO mode is being passed up, thus
' state 5 is eliminated.
Set bits 5&4 in the status byte of the primary's Output bit
= 10B.
IF primary's LO_UPy = 1, then
FOR the bit in the primary's Setpoint that
corresponds to the cascade:
Set bits 5&4 in the status byte of the bit =
10B.
FOR the bit in the primary's RCas transfer location
that corresponds to the cascade:
Set bits 5&4 in the status byte of the bit =
10B.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
FOR the bit in the primary's Cas transfer

location that corresponds to the cascade:
Set bits 5&4 in the status byte of the bit
= 10B.
'
' ************************************************************
' * D4 *
' * Move failure with request for *
' ************************************************************
'
IF bit 4 in the status byte of the primary's Output bit = 0, then
' Because of this step, the following logic only operates
' on the first cycle after a failure - it allows

--```,``-`-`,,`,,`,`,,`---

186
' acknowledgement after that.

= 01B.
' Note: this step transitions 1 of states 3, 5, or
' 6 to either state 4 or 7.
= 11B.
Set temporary logical FLAG = 0
FLAG = 1
Set temporary logical ALL = 0.
IF 2 of the status bytes for the low order three bits of
Output have bit 4 = 1 AND the third bit has a value of
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
1, then
ALL = 1.
IF all 3 of the status bytes for the low order three bits of
Output have bit 4 = 1, then
ALL = 1.
IF FLAG = 1, then
IF [(FAIL_BLK_UP = 0) OR (requested mode bit = higher
priority than Cas)], then
IF ALL = 0, then
IF block mode is to be changed to Man on
failure, then
Set the temporary logical ALERT = 1.
' This signals that an alert is to be
' issued at the end indicating a "bit
' failure". However, an instruction
' in the next section may cancel this
' because it has a failure across all
' three bits.
IF ALL = 1, then
IF block mode is to be changed to Man on
failure, then
Set actual mode byte to 00H.
Set the IMan and Man mode bits in the
actual mode byte.
IF the requested mode bit <> Man, then
Set requested mode byte to 00H.
Set Man mode bit in the requested
mode byte.
Increment the static data base
revision number by 1.
Set notification of mode change or
leave flag for the block to do
it at its next execution.
Set the temporary logical ALERT = 0.
FLAG = 0
Set bits 7-4 in the status byte of the corresponding bit
in the primary's Setpoint = 1111B.
in the primary's RCas transfer location = 1111B.
Set bits 7-4 in the status byte of the corresponding
bit in the primary's Cas transfer location =
1111B.
IF FLAG = 1, then
IF ALL = 1, then
FOR each status byte of the primary's Setpoint:
Set bits 7-4 = 1101B.
IF the RCas bit is set in the actual mode byte, then
FOR each status byte of the primary's RCas
transfer location:
Set bits 7-4 = 1101B.
IF the Cas bit is set in the actual mode byte, then

--```,``-`-`,,`,,`,`,,`---

187
FOR each status byte of the primary's

Cas transfer location:
Set bits 7-4 = 1101B.
'
' ************************************************************
' * D5 *
' * Move failure without request for *
' ************************************************************
'
IF bits 5-3 in the status byte of the primary's Output bit = 100B,
then
' This IF limits this whole set of logic to the specific
' case of "No-Path, No-LO" before the failure and also
--```,``-`-`,,`,,`,`,,`---
' limits it to one pass of action when the failure

' occurs.
= 11B.
' Note: this step transitions status state 1 to
' state 2.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
= 11B.
Set temporary logical ALL = 0.
IF 2 of the status bytes for the low order three bits of
Output have bit 4 = 1 AND the third bit has a value of
1, then
ALL = 1.
IF all 3 of the status bytes for the low order three bits of
Output have bit 4 = 1, then
ALL = 1.
in the primary's Setpoint = 1111B.
in the primary's RCas transfer location = 1111B.
Set bits 7-4 in the status byte of the corresponding
bit in the primary's Cas transfer location =
1111B.
IF ALL = 1, then
FOR each status byte of the primary's Setpoint:
Set bits 7-4 = 1111B.
FOR each status byte of the primary's RCas transfer
location:
Set bits 7-4 = 1111B.
FOR each status byte of the primary's Cas
transfer location:
Set bits 7-4 = 1111B.
'
' ************************************************************
' * D6 *
' * Move a not-wound-up-high status up the cascade. *
' * *
' ************************************************************
'
IF {[(bit 6 in the status byte of the bit in the secondary = 0) AND
(REV_y = 0)] OR [(bit 7 in the status byte of the bit in the
secondary = 0) AND (REV_y = 1)]}, then
' Note: recognize that discretes may have some wound up states
' set because of no degrees of freedom in the three-bit
' Setpoint. Because of that, the primary may have
' wound-up states properly set even while the individual
' bits in the secondary's do not.
'
' If the secondary is the Cas transfer location, it will

188
' be a set itself and will already have included the

' degree of freedom restriction. If the secondary is a
' bit in the Output Word #0 of a Discrete Register, then
' the final steps in this logic will restore the degrees
' of freedom restriction.
IF bits 7&6 in the status byte of the bit in the primary's
Output <> 11B, then
Set bit 6 in the status byte of the bit in the primary's
Output = 0.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
' Can't reset one of these bits if they are both
' set because that might allow values to flow.
IF bits 7&6 in the status byte of the bit in the primary's
Setpoint corresponding to the cascade <> 11B, then
IF BLOCK_WUH = 0, then
Setpoint bit corresponding to the cascade = 0.
IF bits 7&6 in the status byte of the bit in the
primary's RCas transfer location corresponding
to the cascade <> 11B, then
RCas transfer location bit corresponding
to the cascade = 0.
IF bits 7&6 in the status byte of the bit in
the primary's Cas transfer location
corresponding to the cascade <> 11B, then
Cas transfer location bit corresponding to
the cascade = 0.
'
' ************************************************************
' * D7 *
' * Move a not-wound-up-low status up the cascade. *
' * *
' ************************************************************
'
' This logic is exactly the same as given for bit 6
' immediately above except that bits 6 and 7 are reversed.
'
' ************************************************************
' * D8 *
' * Move a wound-up-high status up the cascade. *
' * *
--```,``-`-`,,`,,`,`,,`---
' ************************************************************
'
Set bit 6 in the status bytes of the bit in the primary's
Output = 1.
Setpoint corresponding to the cascade = 1.
RCas transfer location corresponding to the cascade = 1.
Cas transfer location corresponding to the cascade = 1.
'

189
' ************************************************************
' * D9 *
' * Move a wound-up-low status up the cascade. *
' * *
' ************************************************************
'
' This logic is exactly the same as given for bit 6 immediately
' above except that bits 6 and 7 are reversed.
'
' ************************************************************
' * D10 *
' * Conclusion of the discrete logic. *
' * *
' ************************************************************
'
IF the next entry in the cascade connection table has the same primary,
then
GOTO the beginning of the above logic for that cascade starting
with the statement "IF DATA_TYPE = 1, then".
FOR each of the sets of status bytes in the primary's Output, Setpoint,
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
RCas transfer location, and, IF PATH_TO_CTL = 1, the Cas transfer

location:
' Check degrees of freedom in the Output, Setpoint, and Cas
' and RCas transfer location.
Select the value bit that is set:
IF bit 6 in each of the other two status bytes is set, then
Set bit 7 in the status byte of the selected bit.
IF bit 7 in the status byte of the selected bit is set, then
Set bit 6 in the status bytes of both of the other bits.
IF bits 6 and 7 in the status byte of each of the three bits in the
Setpoint = 11B, then
Set IMan bit in the actual mode byte of the primary.
Set bits 7&6 in each of the status bytes of the Setpoint and RCas
Set bits 7&6 in the value of the Setpoint and RCas transfer
locations = 11B.
Set bits 7&6 in each of the status bytes of the Cas transfer
location = 11B.
Set bits 7&6 in the value of the Cas transfer location = 11B.
IF the temporary logical ALERT = 1, then
IF block mode is to be changed to Man on failure, then
Set notification of "1 bit failed" or leave a flag for the
block to do it at its next execution.
Make the changes to the Field Bus accessible data base with Field Bus
read access inhibited.
Clear the entries in the "cascade connection" table that have just been
worked.
END
--```,``-`-`,,`,,`,`,,`---

190
Application Support Services Interface

APPLICATION SUPPORT SERVICES INTERFACE
The sections of the Technical Report that describe the function block
parameters do not completely define the communication services to be used for
data exchange nor the detailed structure of the parameters that have status
bytes. The communication services that will be available from the lower layers
have been defined in a separate document that is quite independent of the rest of
the Technical Report. It does not describe the conditions under which, nor order
in which, the User Layer will use the services.
This paper will integrate these aspects of the User Layer. It will describe
how the "User Layer Support Services" are to be used by the interoperable
function blocks and the logical and physical nodes that support them.

BACKGROUND
DEFINITIONS
SUMMARY
CHANGE OF A TAG NAME
CHANGE OF A TO TYPE OR SUBTYPE
CLOCK SYNCHRONIZATION
DATA DICTIONARY SUPPORT
Physical Nodes
Logical Nodes
Function Blocks
Extended Parameters
General
ALERT FUNCTION SUPPORT
PARAMETER INDICES
PARAMETER NUMBER STRUCTURE
DATA MESSAGE DEFINITIONS
READ HANDLER
DUAL MAPPED PARAMETERS
INDIRECT WRITES
DIRECT WRITES
SUBSCRIBER SERVICE
PREFETCH TIME AND ALARM
ON-PHYSICAL- AND ON-LOGICAL-NODE READS AND WRITES
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
NO_COM. STATUS
DBWS COMPLEX WRITES
CYCLE SYNCHRONIZATION
Attachment 1 - User Layer Support Services
Attachment 2 - Extended Parameter Data Dictionary Encoding
BACKGROUND:
The design of the User Layer is based on a specific set of Application Layer
services. It is possible that those services may be modified in the future.
Therefore, two papers that have led to the current design of the User Layer are
attached to this paper.
The Appendix paper titled "Application Layer Services" is a general

description of the communication support needs of the User Layer without regard
to the actual design of the lower layers. This paper may be useful if there is a
future need to review the "original" service needs of the User Layer.

--```,``-`-`,,`,,`,`,,`---

191
The User Layer design has been integrated with the specific set of User Layer
Support Services defined in Attachment 1. That paper defines each of the
services that will be required to be available from the lower communication
--```,``-`-`,,`,,`,`,,`---
layers.
DEFINITIONS:
For purposes of this paper, "interoperable function blocks" will include the
standard, alternate, and interoperable generic function blocks, and extensions of
them but not the interworkable generic function blocks nor the open blocks. The
term "interoperable agents" will refer to agents of such blocks.
Several references are made to "logical node variables". The reader is

reminded that there can be up to 5 discrete variables or 3 discrete and 2 real
variables in the data base of the logical node itself (see "Data Owner Structure
- Logical Nodes" paper). These variables are fetched and stored by the logical
node using techniques similar to those used by the function block agents. There
is no provision in this standard for "logical node variables" and their agents
that are not "interoperable".
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
This paper will use the notation "TO", an acronym for "tagged object", to
represent any or all of function blocks, logical nodes, and physical nodes. Note
that each of these different types of entities has a "tag
name".
A separate paper in the Technical Report describes the operation of the "Data
Base Write Service". That function is referenced as "DBWS". Note that the DBWS
of the User Layer is a complex instance of the "write handler" of the support
services paper.
This paper will differentiate between "agents" and "non-agents". The former
term refers not only to the agents that are defined for the input and output
words in the function blocks but also to the agents for the logical node
variables and configured portions of higher level control systems. The term non-
agent refers to communication entities associated with any human interface
devices, history gathering devices, and "programmable" devices such as batch
control programs.
This paper will refer to the following classes of communication services:

1) on-block
2) on-logical-node
3) off-logical-node
4) off-physical-node
These terms only refer to the servicing of (configured) agents. They do not
refer to communications between the physical or logical node executives and the
data records nor between the algorithm processor and the algorithm's own data
base. Three of the terms have the following additional special definitions:
2) the second term specifically excludes on-block communications.
3) the third term is used in situations in which there is no need to
differentiate between
(a) communications with data records in other logical nodes on
the same physical node and
(b) communications with data records in other logical nodes in
different physical nodes.
4) the fourth term is used when the distinction between off-logical-node
and off-physical-node is important.
The "User Layer Support Services" paper defines a number of communication

support services that will be available to the User Layer, both for receiving and
sending communication messages and for supporting those actions. In order to
ensure interoperability without extensive negotiation, the interoperable function
blocks and the logical and physical nodes in which they are implemented will be
required to support almost all of those services. There are only four

192
exceptions, three that are indicated by option bits in each logical node's option
bit string, and one that is "logical".
The "User Layer Support Services" paper defines a publisher - subscriber

paradigm and supplies a number of services to support it. The Standard User
Layer will require support for a portion of that paradigm and will never use the
rest. Specifically, the paradigm essentially consists of two parts - a scenario
in which the entity wishing to subscribe can initiate action by the publisher.
The alternative is the scenario in which the publisher is self motivated by its
own configuration or design. The former portion, the "active subscriber" is
ALWAYS supported in the Standard User Layer. The latter portion of the paradigm,
the self-motivated publisher, is NEVER used in the Standard User Layer.
This paper, and all of the papers that follow it in the Technical Report,
will refer to the "active subscriber" portion of the Publisher - Subscriber
paradigm as "cyclic reads".
SUMMARY:
A field device only needs to support those address management functions that
are "logical". A field device (a data owner, not a data user or a human
interface device) must, of course, be able to respond to the address assignment
services (i.e., "Get Untagged Device ID Request", "Write Physical Device Tag Name
Request", and "Assign Fieldbus Address") but not initiate them. The "device id"
that will be used will be the concatenation of the manufacturer's name (reported
first), the model number (reported second), and the serial number (reported last)
with all but 1 trailing space in each parameter eliminated.
A physical node that includes a logical node that can support active agents
must be able to invoke address recovery services. To do that, it must be able to
automatically initiate and support the "Distribute Addresses" and the "Restore
Physical Device Tag Names" services.
The DBWS will appear to automatically invoke the "Register Tag" and "Remove
Tag" services when a tag name is written to a device.
A logical node with Standard function blocks will probably have to support
"Inhibit Direct Access" and "Permit Direct Access" in order to meet the
requirement of this Standard.
All Standard Field devices will support the "Subscribe Indication" and
"Subscribe Response" services and be able to publish any data base parameter that
does not require a "read handler", and will cancel the publishing when sent a
"Cancel Buffer Service Request".
The non-time-critical options bit string of every logical node will indicate
if the node supports active agents. If not, then that logical node and its
function blocks do not need the "Parameter Access Services" that are used only by
active agents. However, its physical node will still have to support all
responder services. Thus, it WILL supply an "Open Indication" handler, will
support "Open Response", and will support "Close Request". It will supply a
"Write" handler and will support "Write Response" and "Masked Write Response".
It will support the utility services "Disable Request" and "Enable Request".
If it does support active agents, then it must be able to "Schedule

Communications" and invoke direct writes, masked writes, and cyclic reads. In
addition, it will disable (or cancel) those when a function block with a new
agent pointer transitions from O/S mode or when a tag name is written to the
pointer of a logical node variable's agent. Both a logical node and function
blocks will be able to utilize the "Locate Tagged Object" service.
The time-critical options bit string of every logical node will indicate if
the node allows function blocks that support a read handler. If it does, then
the parameters of TO's in that logical node that are identified as potentially

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
193
accessed through a read handler MUST be so accessed. The only defined instances
of such parameters are in the "Interface" type function blocks. If the logical
node supports a read handler, it's physical node must have a "Read Indication"
handler and must support the "Read Response" service.
The time-critical options bit string of every logical node will indicate if
the node supports the alert reporting service. If not, then that logical node
does not require that its physical node support the "Event Reporting" services.
If it does, then the field device must support those services that are necessary
to report the events using the event reporting service, including the "Multicast"
services.
The User Layer of most field devices will not have a need to access the
information in the "Data Dictionary". All User Layers will need the ability to
"Add", "Delete", and "Set" parameters in the data dictionary. The lower layers
in the Field Device WILL support all bus responses to Data Dictionary services.
There is no User Layer requirement to support "Generic Management", nor "Time

Management" services. However, Field devices must respond to the Get and Set
(both layer parameters and time) Management services executed in peer devices.
CHANGE OF A TAG NAME:

The changing of the TAG name of a physical node must be done using the
explicit support service provided. The parameter that contains the physical
node's TAG is read-only.
All writes to the parameters that contain the tag names of logical nodes and
function blocks must be made through the DBWS. If the TO is a function block,
the block must already be in O/S requested and actual mode for such a write
request to be valid. When the DBWS handles a valid write to a tag name that will
result in an actual change to the tag name, then it (the DBWS) will execute a
"Disable Request" for the old tag name. It will "remove" the old name from the
directory and "register" the new name. It will also make the necessary changes
to the Data Dictionary.
CHANGE OF A TO TYPE OR SUBTYPE:

All writes to the parameters that contain the "TO_Type" and the "TO_TYPE1"
must be made through the DBWS. If the TO is a function block, the block must
already be in O/S requested and actual mode for such a write request to be valid.
When the DBWS handles a valid write to either of those parameters (but NOT the
"TO_USER_SUBTYPE") that results in an actual change to the type or subtype, then
it (the DBWS) will execute a "Disable Request" for the tag name. It will make
the necessary changes to the Data Dictionary and execute an "Enable Request".
The DBWS will then take an action that will be modeled here as setting an
internal flag called "NEW_ALGO". It is not required that any such flag exist or
that the action be carried out in the fashion to be described. It IS required
that the action ACT AS IF it were carried out in the described fashion.
The NEW_ALGO flag will override the requested mode, forcing the actual mode
to O/S during the time necessary for the following action.
At the convenience of the logical node time schedule, the new algorithm will
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
be activated and its default data base will be loaded into the public parameters.
After that is complete, the appropriate flag to cause block initialization will
be set.
When the block's requested mode transitions from O/S and the block executes,
it will find NEW_ALGO set. Therefore, it will

--```,``-`-`,,`,,`,`,,`---

194
- initialize the flag IO_COUNT for each agent (see Table 1 in the paper
"Function Block Structure" for a description of this illustrative
flag).
- initialize the communication update counters for each parameter
(defined below)
- initialize the consistency variable for each cyclic read buffer and
the completion status of each direct write buffer (again see below).
- issue a "Tagged Object Enable" service request
- establish all associations and schedules
- establish any cyclic reads needed by its agents
- reset the NEW_ALGO flag.
Only then will the block begin actual execution.
The "Tagged Object Enable" service request is not needed if the tag name of
the function block was also changed during this operation.
It is not necessary that all of the above operations be done in one cycle and
it is not important whether the function block, the logical node, or the physical
node actually does the work.
--```,``-`-`,,`,,`,`,,`---
It is important that the communication counters not be incremented by block

execution until after the associations have been made, the schedule time
obtained, and the cyclic reads set up. The transition from O/S will not wait for
the actual cyclic reads to occur and it will not wait for a service, even the
communication services mentioned, if error returns indicate that they can not be
accomplished.
CLOCK SYNCHRONIZATION:
The "System Clock" section of the paper "Data Owner Structure - Hardware"
defines the details of the operation of the Field Device's clock. In summary, the
User Layer of all Field Devices will be concerned with three time parameters:
NODE_TIME - the time in 1/32 of milliseconds since the device's
microprocessor last started.
SOCIAL_TIME - the time since 1 January, 1970 in terms of
Coordinated Universal Time (UTC) (Note: daylight
savings and "local" time will specifically not be
fundamental to Field Device time).
NODE_TIME_OFFSET = (SOCIAL_TIME - NODE_TIME)
All three parameters will be carried as 48 bit integers with 1/32 of a
millisecond resolution. All Standard field devices must support NODE_TIME in
their physical node data bases.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
A Field Device may be designed to directly support a clock for use by the
function blocks. For Standard blocks, this service is defined based on an "alarm
clock" approach. To provide that service, the device needs access to a reference
clock, at least to initialize its setting.
Each of the alert events will be reported must be synchronous across the
Field Bus. Thus, if the Field Device supports alert reporting, it needs a
synchronized social clock.
All logical nodes must be operating from the Field Bus clock and utilize and
support the "Node Time Synchronization" service. All devices must support the
response to the "read node time offset request". If the User Layer supports
either the alarm clock or the alert system, then it must support the "Get Node
Time" and "Get Node Time Offset" services.
Each physical node will have a bit in its options bit string that indicates
if the physical node can execute independently of its communication engine. If
so, and if any of the logical nodes in the physical node supports alert reporting
(see above), the physical node will, upon start-up, start and "tick" NODE_TIME
until the communication layers start. At that point in time, the physical node
will issue an event report that ties "NODE_TIME" to "NODE_TIME_OFFSET".

195
More specifically to the last item (i.e., specifically for those cases in
which the User Layer can operate separately from the communication engine):
- any time that the User Layer accesses the clock service, it may
receive a failure response.
- if the failure indicates that "NODE_TIME" is not available, the User
Layer will attempt to obtain NODE_TIME from any other Field Bus
interfaces.
- If none are available, it will use any off-Field Bus clock that shows
the time since the device start-up.
- If none are available, it will keep its own version of node time.
- the User Layer will "tick" its own NODE_TIME until it receives a
request from the lower layer for node time. At that point, it will
deliver its version of NODE_TIME and, from that point on, it will
revert to using the time service.
- the resolution and accuracy of the "ticking" that the User Layer can
accomplish is outside of the scope of Field Bus.
- if there are multiple communication services, the User Layer will
search for an operating communication service before it starts its own
version of NODE_TIME.
- if there are multiple communication services, the User Layer will
revert to the use of whichever communication layer comes up first.
- when the control of the clock is passed back to the communication
layer, the physical node will issue an alert that reports the event
and includes BOTH the NODE_TIME and the NODE_TIME_OFFSET.
DATA DICTIONARY SUPPORT:

The User Layer has been designed to negate the need for higher level devices
to maintain a full copy or "image" of the dynamic data of the field devices. The
primary driving force for such a mechanism would normally be the required maximum
call-up time of a display on a human interface. The primary reason to avoid it
is the continuing large communication link traffic required to update the image.
There are a number of design features that have been included to address this
problem; for example, the PV and Tag display build and refresh parameter groups
defined in the paper "Array of Standard Block Parameters". However, there is
--```,``-`-`,,`,,`,`,,`---
also a problem with what might be called "serial data". This term refers to data
that the human interface needs to determine what data it needs! This serial
chain can very easily get to be three layers deep. If a serial chain exists, the
human interface would have to formulate a field bus message, wait for an answer,
formulate another message, wait for that answer, etc. The User Layer Support
Services provides mechanisms for eliminating the first two as follows.
When a human interface must display information for tag "F101", it must first
find that tag and determine its field bus address. The Directory includes that
information and is available to the human interface display builder on the "near"
side of the field bus. The Directory contains the tag name and address of all
tags on the bus.
The second step for the human interface is to determine what type of TO F101
is and what parameters it supports. If this second set of information is
sufficiently complete, the human interface can formulate ALL of its reads to the
parameters in the actual data base of F101 that are necessary to complete the
display. The design objective of the User Layer is to include all of that
"second set" of data in the Data Dictionary. It also will then be available on
the "near" side of the field bus.
It is important to recognize that all data in the Data Dictionary must be set
by the data owner. This means that the field device must know its data by some
means other than the Data Dictionary. Thus, any user-set data in the Data
Dictionary must ALSO be parameter data of the field device. Also, it is intended
that all Data Dictionary data must be stored and kept current by all higher level

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
196
devices on field bus, a non-trivial task if the amount of data is large and/or
subject to frequent change.
The amount of data in the Data Dictionary is kept to a minimum but is

intended to cover all of the "second set" needs.
The following defines a data record that must be entered into the Data
Dictionary of all interoperable TO's; made available in Data Dictionary responses
to requests by other bus devices, and kept up to data by the field device. All
of the data in the records defined below is:
- explicitly known by the field device by design, OR
- defined by parameters that are "under" the data owner's static data
base revision number.
Any TO other than a standard function block can include additional records but
the defined records must be included for interoperable TO's. In the following
--```,``-`-`,,`,,`,`,,`---
table, a "*" follows the item number for items in the physical and logical node
list when the data can be fixed by the manufacturer ASSUMING that the
manufacturer will fix the type of physical node (there is only one defined in the
standard) and the logical node type (there are seven defined in the standard).
Physical Nodes:
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
A single data record, with the name "PN" and containing the
following data, will be included in the Data Dictionary for every
physical node's tag name (data can be appended to the record but the
first 12 items must be included and their order and definition are
fixed):
1) 8 bit unsigned integer to define the length of the record in
bytes (including this byte in the count).
2)*8 bit integer that will contain the TO type of the physical
node (see the paper Data Owner Structure - Logical Nodes" for a
definition of the possible TO Types.)
3)*8 bit integer that will contain the Mfg. Subtype (defaults to
the same value as item (2) for standard physical nodes)(see the
paper "Data Owner Structure - Logical Nodes" for a complete
definition)(MUST have a value that is defined in Table 1 of
the paper "Data Owner Structure - Logical Nodes").
4) 16 bit integer that will contain the User Subtype (as set in the
physical node parameter of the same name) (defaults to the same
value as item (2) for standard physical nodes) (see the paper
"Data Owner Structure - Logical Nodes" for the use of this
parameter).
5) 8 bit integer that will contain the ASK of the physical node
(as set in the physical node parameter of the same name)
(see the paper "Alert Function" for a definition of an ASK).
6) 16 bit integer that will contain the BASK of the physical node
(as set in the physical node parameter of the same name).
(see the paper "Alert Function" for a definition of a BASK).
7)*24 bit unsigned integer:
The low 18 bits will define three six bit numbers, each with a
range of 0-63. They define the number of "Auto-Formatting"
variables in this physical node's data base that are unrelated
to I/O hardware. The variables are referred to as "PN_AF_x (i)"
in the paper "Array of Basic Parameters" where x defines the
access class:
x = F = mode case 00B on page 7 of the Basic Param.
paper.
x = M = mode case 10B on page 7 of the Basic Param.
paper.
x = O = mode case 11B on page 7 of the Basic Param.
paper.
The low order 6 bits define the number of variables in class F,
the next 6 bits define class M, etc.

197
(See the paper "Human I/F Considerations" for a description of

the Auto-Formatting variable).
Bits 12H & 13H define the number of alert descriptors supported
in the 0-1FH range of alert codes. Bits 14H-17H define the
number of alert descriptors supported in the 20H-3FH range of
alert codes (see the paper "Alert Function", page 8).
Note that bits 12H-17H must all be reset if the time critical
bit string for the node indicates that the node does not support
alerts. Also, bits 14H-17H must all be reset if the time
critical bit string indicates that the node does not support the
extended range of alerts.
8)*8 bit string.
Bits 3-0 - interpreted as a 4 bit unsigned integer to define the
number of bytes of "time critical" options string data
(i.e., how long is the next data item not including
this byte in the count?).
Bit 4 - set if this physical node supports the alert service.
Note: this bit identifies whether alerts are REPORTED
using the Application Layer event reporting
capability.
Bit 5 - set if this physical node supports the basic alerts.
Note: the data base parameters that support the basic
alerts are required. This bit indicates if they
do anything!
Bit 6 - set if this physical node supports the extended alerts.
Note: the data base parameters that support the extended
alerts are only present if this bit is set.
Bit 7 - set if this physical node supports extended parameters
(see the "Extended Parameters" section of this paper).
(See the paper "Alert Function"for a description of these
terms.)
9)*Time critical options bit string data [there must be exactly
as many bytes of data as is given in item (8) above] (see the
paper "Data Owner Structure - Hardware" for the definition of
this parameter).
10)*16 bit integer containing the Field Bus revision number (see the
paper "Data Owner Structure - Hardware", page 22).
11)*8 bit integer containing the total number of logical nodes in
the physical node.
12)*8 bit unsigned integer to define the number of types of hardware
attached to this physical node.
13)*a 24 bit word for each type of hardware, not included if not
present [there must be exactly as many 24 bit words as is given
in the number in item (11)]:
Bits 0 - 5: the hardware type:
These 6 bits will indicate the type of hardware described
by this 24 bit word -
0 Counter Input 7 Serial Comm. Ports
1 Discrete Registers 8 Tank Gauging
2 Foreign Memory 9 Voted Discrete Out
3 Human Interface A Voted Scalar Out
4 Pulse Outputs B Component Analyzer
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
5 Scalar Inputs C Property Scanner
6 Scalar Outputs
The values 0DH through 2FH are reserved, 30H to 3EH are
available for manufacturer use. Note: it is extremely
important that no manufacturer use 3FH: it will be given
a special meaning - see page 13 of the paper "Array of
Basic Parameters".
Bits 6 - 8: number of auto-formated variables per hardware

type:
These three bits will be used to indicate if there are zero
to seven auto-formatted variables [I/O_TYPE_AF(i)]
associated with the full set of this type of hardware. The

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
198
three bits will be interpreted as a number in the range of

0-7 and that number will be the maximum value of (i). All
instances of I/O_TYPE_AF(i) for this hardware type equal to
that number and less must exist.
Note: the data in the array of auto-formatting variables

for each data type are arranged in a fixed structure
- a parameter number is reserved for each of the 63
potential I/O types. The parameter's index will
select one of the existing variables for the defined
hardware type. (See the paper "Array of Basic
--```,``-`-`,,`,,`,`,,`---
Parameters" for the parameter names and numbers; see
Attachment 1 to the paper "Human I/F Considerations"
for a description of the auto-formatting variables.
Bits 9 - 11: number of auto-formatted variables per hardware

instance:
These three bits will be used to indicate the number of
auto-formatted variables associated with each instance of
this type of hardware. The three bits will be interpreted
as a number in the range of 0-7.
Note: this data will define the arrangement of the data in

the parameter array "I/O_AF (i)" (see the paper
"Array of Basic Parameters"). Each parameter number
will refer to the Auto-Format variables for one of
the hardware types. The index of the parameter will
identify the particular variable in the array of
auto-formatted variable (see Attachment 1 to the
paper "Human I/F Considerations" for a description of
Auto-formatted variables) for this hardware type.
There can be 0 to 7 variables per I/O instance; that

number is defined for all instances of I/O for this
hardware type, not for each instance. If the number
is 0, there are no values for I/O_AF (i) for any
instances of this hardware type. If the number is
>0, the auto-format variables are arranged in order,
with the 1 - 7 variables for hardware instance 0
first, then the 1-7 variables for hardware instance
1, etc. through increasing index numbers.
Bits 12 - 23: number of instances of hardware:

The high order 12 bits of the word will be interpreted as
the number of instances of this hardware type
Note: this value will define the maximum value for the
hardware pointer in any agent referring to this type
of hardware. It will also define the maximum value
for the index "i" in the array "I/O Value (i)" (see
the paper "Data Owner Structure- Hardware, page 12).
Each value in that array will refer to an individual
physical I/O connection. The description of the value
for each I/O type will be defined in the appropriate
function blocks. They will be arranged in order, the
value for hardware instance 0 at I/O_VALUE(0).
For example, if there are:

- three counters with no auto-formatting.
- four scalar inputs with common calibration information in
three auto-formatting variables and individual point
calibration in one variable per point.
- two scalar outputs, each with individual calibration
data in their own auto-formatting variable.
then item (11) = 3 and the FULL set of 24 bit words at the item
(12) position in the "PN" string would be:
000000000011 000 000 000000B - word for counters

199
000000000100 001 011 000101B - word for scalar inputs

000000000010 001 000 000110B - word for scalar outputs
(the blanks, dashes, and alpha characters are not to be
included; they are added here for human readability).
Note: the I/O hardware value and the auto-formatting variables

for a hardware instance will be addressable using the
tag name of the physical node plus a parameter OR by
using the tag name of the TO that includes a
hardware pointer plus a parameter.
Logical Nodes:
A single data record, with the record name "LN" and containing the
logical node's tag name (data can be appended to the record but the
fixed):
1) - 9) - exactly the same as the first 9 items for PN except that
"Logical" is substituted for "Physical" at every
occurrence in the definitions (for item 9, refer to the
paper "Data Owner Structure - Logical Nodes").
Note: for item 7 (auto-formatting), (do not count the
Auto-Formatting variables declared in the physical
node for the hardware associated with the logical
--```,``-`-`,,`,,`,`,,`---
node)
10) 16 bit integer containing the value of the logical node
descriptor "CB". (See the paper "Data Owner Structure - Logical
Nodes".)
11)*16 bit integer containing the value of the logical node
descriptor "MB". (See the paper "Data Owner Structure - Logical
Nodes".)
If there is only one logical node in the physical node, then the
one resulting TO will have both a "PN" and a "LN" data record in its
Data Dictionary.
Function Blocks:
A single data record, with the record name "FB" and containing the
function block's tag name (data may be appended to the record but the
fixed):
1) - 9) - exactly the same as the first 9 items for PN except that
"Function Block" is substituted for "Physical" at every
occurrence in the definitions.
Note: for item 7 (auto-formatting), (do not count the
Auto-Formatting variables declared in the physical
node for the hardware associated with the
function block)
For item 8, the information for the logical node
containing this function block is reported.
For item 9, refer to the individual function block
definitions for the option bit string definition.
10) 8 bit binary string to define the number of parameters
under the User access [maximum of 5; if = 0, then no entry
for item (11)] and to define whether their access level is
forced high or low (see ASSIGN_USER in the paper "Block Modes",
p6).
11) String of 16 bit words, each one a parameter number of a
parameter that is defined to be under the User access bit.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
200
Note: the Field Device must supply enough room for a total of
5 parameters in item (11).
If there is only one function block in the logical node, then the
one resulting TO will have both a "LN" and a "FB" data record in its
Data Dictionary. If that logical node is the only logical node in the
physical node, then the PN will also be in the Data Dictionary of the
same TO.
Extended Parameters:
The User Layer Standard has defined many data base parameters to
support the nodes and their function blocks. In addition, there are
three methods provided for adding parameters in such a way that
independent Field Bus devices can access the variables. The first is
the Auto-format variables. The second is the extension variables that
are defined in the generic function blocks. The third is the one for
which the term "extension parameters" is reserved. It utilizes special
data dictionary parameters to expedite access to the extension
parameters.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
An individual data record for each "primary" extended parameter
will be included in the Data Dictionary of the TO that contains the
parameters. If the TO is a physical node, the name will be "EXPx", a
contraction of "EXtended variable, Physical node, instance x". The
names for logical nodes and function blocks will be EXLx and EXFx,
respectively. The value of "x" will be assigned in serial order,
starting with 0, for each TO.
These dictionary parameters indicate the existence of support

data base parameters such as entry limits, descriptor strings, etc.; they
give the data types of both the primary and support parameters; and they
give the information necessary to locate the primary parameters and the
support variables in the data base of the Field device. Since they will
be stored in the data dictionary, they are designed to be as compact
as possible. Attachment 2 gives the details of the structure of the data
dictionary parameters.
If bit 7 in item 8 of a TO's PN/LN/FB is set, the data dictionary

for that TO MUST contain "EXc0" where c is one of "P", "L", or "F".
The paper "Array of Basic Parameters" defines the parameter

number ranges in which the extended parameters and their support
variables can be assigned.
There is no limit defined, in the User Layer Standard, for the

number of extension parameters that can be generated by any one TO and
no limit to the total number that can be generated on one Field Bus.
General:
--```,``-`-`,,`,,`,`,,`---
To achieve the above, the field device's User Layer will need the
"Add -", "Delete -", and "Set Named Object Attribute" services. The
lower communication layers must support "Get List" and "Read Named
Object Attributes" requests from other field bus devices.
A field device that supports only standard function blocks can

determine the maximum number of bytes of data storage that are required
for the above. It need not support more that that amount of data in its
Data Dictionary.
For example, consider a physical node that supports one scalar

input, one logical node, and two standard function blocks (i.e., a

201
transmitter that can support an AI block and a Math block). It would

need the following (minimum) amount of room in its Data Dictionary:
PN = items 1-6 = 8 bytes

item 7-9 = 6 byte
items 10-13 = 7 bytes
LN = items 1-6 = 8 bytes
item 7-9 = 6 bytes
items 10&11 = 4 bytes
FB(0) = items 1-6 = 8 bytes
item 7-9 = 6 bytes (max of AI/Math requirement)
item 10&11 = 11 byte
FB(1) = same as FB(0) = 25
Grand Total = 87 bytes of data in the Data Dictionary required.
ALERT FUNCTION SUPPORT:
--```,``-`-`,,`,,`,`,,`---
Each logical node will include a bit in its options bit string that indicates
if it supports the alert function. If it does, then the physical node that
includes that logical node must support the entire alert function. The details of
the alert function support in the User Layer can be found in the separate paper -
"Alert System".
Since it is not expected that Field Devices will receive alert data, they are
assumed to not support the "event enrollment" services even if they support event
reporting. They must initiate and support the "Post Event" service and the other
portions of the field device's communication logic must support responses to
Field Bus requests for the other services. Both the Management and the lower
layers must support the "Get -" and "Set Event Control Parameters" service.
PARAMETER INDICES:
The design of the User Layer is based on the assumption that the User Layer
Support Services allow the use of an "index" associated with parameter numbers.
In general, the index is used infrequently. The index is not supported by
agents; therefore, an index is never used on a parameter that might be needed by
a block agent. Consult the papers "Array of Basic Parameters" and "Array of
Standard Block Parameters".
PARAMETER NUMBER STRUCTURE:

The fundamental (detailed) design of the User Layer has placed several
restrictions on the structure of the parameter numbers. Likewise, and
independently, the design of the lower layers of the Field Bus protocol has
placed several other restrictions on their structure. These restrictions will be
defined and resolved here but the detailed design and assignments of the
parameter numbers will be given in the papers "Array of Basic Parameters" and
"Array of Standard Block Parameters".
The User Layer restrictions are:

1) the parameter number is assumed to be no longer than 16 bits.
2) the pointer in an agent accessing a parameter uses the high
order bit of the parameter number for other purposes - the high
order bit of the actual parameter number is assumed to be reset.
3) the pointer in an agent accessing a single bit in a discrete
value, or a single status byte in an array of status bytes, uses
the high six bits for other purposes - the high order 6 bits of
the actual parameter number are assumed to be reset.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
202
The lower layers restrict the parameter number as follows:

4) the parameter number plus three attribute bits are assumed to
require a 16 bit field.
5) the three attribute bits (assigned to the high order positions in
the 16 bit field) have the following meanings:
a) IF bit 15 is set, then
the parameter can not be directly/cyclically read.
b) IF bit 14 is set, then
the parameter can not be directly written.
c) IF bit 13 is set, then
--```,``-`-`,,`,,`,`,,`---
the parameter is read-only.
6) a value of -1 (all bits set) in the field has special meaning to
the lower layer code.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
The classes of parameters represented by the restrictions in rules 5b and 5c

(i.e., those parameters that would have bits 13 and/or 14 set) are widespread and
important. Many of them must be accessible for bitwise reading by agents. It is
not possible to simply assign a 13 bit parameter number to all block parameters
and assign states to bits 14 and 13 according to rules 5b and 5c.
This conflict is resolved by the specific assignment and interpretation of

the parameter numbers. The high order 3 bits are used as dedicated attributes -
see page 5 of the paper "Array of Basic Parameters"; they are not carried (or are
not meaningful) in the transmitted parameter number since they are not used to
resolve parameter identification. The rules followed by the User Layer Standard
will be:
1) the full parameter field will be 16 bits long but only 13 bits will
be carried (or significant) on Field Bus.
2) any parameter value used in User Layer configuration will be 13
bits long and occupy the low order bit positions in the 16 bit field.
3) the values for bits 15-13 (the attribute field) will be defined for
every Standard parameter.
4) any parameter that has either of bits 12 or 11 set can not be bitwise
accessed by an agent in a Standard Function Block.
5) the specific parameter value that has all 16 bits set will not be
assigned.
Note that any parameter that would have bit 15 set can not be accessed by any
Standard function block agent because the time of the response to the read
request would not be deterministic. Also, any parameter that would have bits 14
and/or 13 set can not be configured into an Output agent because all active
output agents must write.
The "Array of Basic Parameters" paper will use these rules as a starting
point for the design of the User Layer parameter arrays.
DATA MESSAGE DEFINITIONS:

A read message from a parameter that has status information may include both
a value and its status byte. A write message to one of these parameters may
include not only the value and its status byte but also a mask (for masked
writes). The order of these pieces of data in the message is defined here.
For all reads, the value, if it is included, will be transmitted in its full
format - either 32 bits for an analog value or 8, 16, or 32 bits for a discrete.
If the status byte is included, it will follow the value and precede the mask.
Masked writes can be used for both the analog and discrete parameters being
discussed here. For the analog values, the only time a mask has meaning is when
the status byte is included. Therefore, there are four forms of data messages
for analog values (where the bits are transmitted in the value order given here,
low order bits of each value first:

203
1) 32 bit floating point value (read or unmasked write of parameter z).

2) 32 bit floating point plus an 8 bit status byte [read or unmasked
write of parameter (z+1)].
3) 32 bit floating point plus an 8 bit status byte plus an 8 bit mask
for the status byte [masked write of parameter (z+1)].
4) 8 bit status byte [read of parameter (z+2)].
For a bit string, two limiting but simplifying assumptions are made: the full
bit string of the value is always transmitted and the mask will apply to the none
or all of the value string. Therefore, there are seven forms of data messages
for discrete value writes of a "x" bit value:
1) x bit string (read or unmasked write of parameter z)

2) x bit string + x bit mask for the string (masked write to parameter z)
3) x bit string + 8 bit condensed status [read or unmasked write of
parameter (z+1)]
4) x bit string + 8 bit condensed status plus (x+8) bit mask [masked
write to parameter (z+1)]
5) 8 bit condensed status byte [read of parameter (z+2)]
6) x bit string + (8*x) bit status array [read or unmasked write of
parameter (z+3)]
7) x bit string + (8*x) bit status array + (9*x) bit mask [masked write
to parameter (z+3)]
READ HANDLER:
It is anticipated that very few interoperable field devices will use a "read
handler". Where one is required (see the "remote data option" in the "Interface"
blocks), it will of course be provided. There is an option bit in the logical
nodes option string to indicate whether this service is provided in the logical
node. If it is, it will so respond in the "association" response. If the
service is provided, then it must be available for every "Interface" block
implemented in that logical node.
If the logical node supports a read handler and has a function block with an
algorithm that supports "remote data access" for certain parameters, then the
read handler MUST be used for those parameters in all such blocks in the logical
node.
The remote device seeking association can determine the TO type from its data
dictionary. Given the association response and the TO type, it can determine,
for all standard function blocks, exactly which parameters are to be accessed
through the read handler.
DUAL MAPPED PARAMETERS:

The "Open Response" service of the User Layer Support Services defined in
Attachment 1 provides the ability to indicate the parameter list that is
associated with a TAG. That facility will be used to define not only the
parameters of the tag but, in addition, to define certain additional parameters.
Specifically, all function blocks will include in their list the following
parameters that actually are associated with the data base of the physical and
logical nodes in which the function block resides (these parameters are defined
in Table 1 of the paper "Array of Basic Parameters"):
LN_NUM - the logical node's index in the array of logical node tag
names in this physical node (read only).
LN_TAG Names - the array of logical node tag names in the physical node
(can be written).
TAG - the physical node's tag name (can only be written using
User Layer Support Services).
TIME_CRIT0 - the time critical bit string from the logical node (read

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
204
only).
FAIL_SAFE - the 8 bit string that defines the basic FAILSAFE function
in the logical node (can be written with a mask).
NOWRITE - the 8 bit string that defines the basic NO_WRITE service
in the logical node (can be written with a mask).
LN_VAR0 through LN_VAR4
- the five logical node variables (read only).
In a similar fashion, all logical nodes will include the following parameters
that are actually associated with the data base of the physical node in which the
logical node resides (these parameters are also defined in Table 1 of the paper
"Array of Basic Parameters"):
LN_TAG Names - the array of logical node tag names in the physical node
(can be written).
TAG - the physical node's tag name (can only be written using
User Layer Support Services).
TIME_CRIT0 - the time critical bit string from the physical node (read
only).
INDIRECT WRITES:
An indirect write (called the "write service with a write handler" in the
support services document) can be used for any of the writeable parameters. All
such writes will be placed in the buffer of the "Data Base Write Service" (DBWS)
and completed by the physical node containing the function block. See the paper
by that name for details on the DBWS.
The DBWS provides a number of data base change services for the function
blocks. Three of those services are particularly important here:
- The DBWS will set an internal flag, here called "NEW_ALGO", any time
the algorithm number is changed (not just written) AND will
immediately invoke the "Disable Request" communication service, will
update the Data Dictionary, and invoke the "Enable Request".
- The DBWS will invoke the "Disable Request" communication service any
time a tag name is changed, it will invoke the "Remove Tag Name" and
"Register Tag Name" directory services, and it will update the data
dictionary for the removal of the old tag name and the entries for the
new tag name. Finally, it will invoke the "Enable Request".
- The DBWS will update the Data Dictionary any time it changes a
parameter that is included in the dictionary.
--```,``-`-`,,`,,`,`,,`---
DIRECT WRITES:
A field device may be required to enforce the NOWRITE option. The device
will only be able to stop indirect writes, not direct writes. Therefore, all
Standard devices will use direct writes ONLY for configured operations, not human
interface operations nor "user programmed" operations such as batch control.
The parameter number for all Input Words and logical node variable values
will indicate that the location can be directly written. Nevertheless, these
values can only be directly written if their agent is of type "writeable" or
"required writeable". In addition, the parameter called (z+2) in Drawing 3 in
the paper "Function Block Structure" can NEVER be written, under any conditions.
When the data owner is actually requested to set up a direct write to

parameters z, (z+1), or (z+3) of an agent's value, the agent for the value being
written to will determine if the location can be written based on its (the
agent's) type. (Note that z+3 does not even exist in analog values.)
Specifically, only when the agent's type is "Writeable" or "Required Writeable"
will the agent allow direct writes to z, (z+1), or (z+3).

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
205
SUBSCRIBER SERVICE:
If the logical node supports active agents, then a value can be cyclically
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
read into a special "cyclic read buffer". All off-logical-node configured reads
by interoperable TO's will be done using cyclic reads.
The cyclic read will take place before the start of the block execution
(i.e., at "prefetch time").
PREFETCH TIME AND ALARM:

Any Logical node that supports cyclic reads must support the parameter pair
"PREFETCH" and "MAX_PREFETCH". PREFETCH will contain the length of time between
the "earliest permitted start time" and the beginning of block execution for any
cyclic read. MAX_PREFETCH will give the high alarm limit for PREFETCH. There
will be a pair of these parameters in the logical node's data base if it supports
logical node variables. There will be a pair of these parameters in any function
block in the logical node that supports active agents.
Both values will be 16 bit unsigned integers where the 16 bits will
correspond to the low 16 bits in the 48 bit clock variables defined in the paper
"Data Owner Structure - Hardware". They will be able to indicate time
differences up to 2 seconds long.
The node or block will enter in PREFETCH the length of the "prefetch time"
for the associated set of prefetches that are needed for that node or block.
This is the time, in 1/32 of milliseconds, between the beginning of the "window"
in which the cyclic read can be started and the beginning of the block execution.
If the prefetch time is larger than the full range of PREFETCH, the node or block
will set it to FFFFH. If no active, off-physical node prefetches are configured,
PREFETCH will be set to zero. See the paper "Array of Basic Parameters" for a
description of PREFETCH.
The parameter MAX_PREFETCH gives the maximum permitted value of PREFETCH. If

this limit is violated, the node or block will set an alarm. MAX_PREFETCH will
default to a value of FFFH. If MAX_PREFETCH is set to zero, the alarm will not
be issued.
ON-PHYSICAL- AND ON-LOGICAL-NODE READS AND WRITES:

The User Layer Support Services document does not define the services to be
used for on-physical-node nor on-logical-node reads and writes. Such services
must exist if a physical node can support more than one function block or logical
node agents. Naturally, such services do not necessarily affect the formal
communication layer definitions. Never-the-less, such services will be defined
here because they are purposely defined similar to the formal communication layer
definitions.
If a field bus device supports more than one logical node, then each logical
node that supports interoperable agents must support "standard on-physical-node
communication services". Such support is defined simply: it must appear to other
devices on the field bus and to the function blocks in the devices EXACTLY the
same as the communication services provided to off-physical-node communications
with the exception that there may be no communication latency. Specifically, the
indirect writes will appear to be handled through the buffer of the DBWS,
including the asynchronous latency and the ordering provided by the DBWS's FIFO
buffer. (This requirement is included for emphasis, not to the exclusion of any
of the other services.)

--```,``-`-`,,`,,`,`,,`---

206
If a field bus device's logical node supports more than one interoperable
function block, or if it supports an interoperable function block and logical
node variables, then it must support "standard on-logical-node communication
services". Such support is the same as standard on-physical-node communication
support with the exception of the parameter read and write services themselves,
as defined here:
1) there will be no "scheduling" service.
2) "direct" writes as defined above will not exist.
3) "indirect writes" as defined above will be the only mechanism for
on-logical-node writes but they will be:
a) initiated within the function block's, or logical node's,
allocated time (i.e., they will be "in-line" writes), AND
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
b) processed immediately, NOT through a buffer, AND
c) processed with the same logic as is used by the DBWS.
Note: the standard function block and logical node agents
are defined in such a way that the parameters they
can access are limited to one-half of the parameter
range. It will be found, therefore, that most of the
logic of the DBWS will not be needed by the on-
logical-node write handler.
Note: indirect writes to all parameters ABSOLUTELY MUST BE
INITIATED AND COMPLETED WITHIN THE TIME ALLOCATION OF THE
REQUESTING FUNCTION BLOCK OR WITHIN THE REQUESTING LOGICAL
NODE'S PROCESSING TIME (i.e., within the logical node's 20%
of the time cycle).
4) cyclic reads as defined above will not exist.
5) "direct" reads as defined above will be the normal mechanism for on-
logical-node reads [the only exception being item (6)] and they will
be:
a) initiated within the function block's, or logical node's,
allocated time (i.e., they will be "in-line" reads), AND
b) processed immediately.
6) certain conditions are defined above for the utilization of a "read
handler". If there is an on-logical-node read of one of those
parameters under those conditions, then the field device will provide
the same service to the on-logical-node read. However, IT IS
ABSOLUTELY REQUIRED THAT SUCH READS BE DONE WITHIN THE TIME
ALLOCATION OF THE REQUESTING FUNCTION BLOCK OR WITHIN THE LOGICAL
NODE'S PROCESSING TIME (i.e., within the logical node's 20% of the
time cycle). It is not permissible to access the read-handler
parameter "ahead of time" as is done for the cyclic read of
off-logical-node parameters.
Note: one result of this requirement is that a standard function

block (for example, a MATH block) operating in a logical node
that also supports function blocks with "remote" reads (i.e.,
an INTERFACE block), might need a relatively large "MX"
(manufacturer's minimum logical node cycle time). This problem
can be avoided by using two logical nodes - one for the
INTERFACE blocks and one for all other blocks. Then the
communications with the remote variables become
off-logical-node accesses and can be scheduled ahead of, or
completed after, the control block's allocated time.
NO_COM. STATUS:
An agent that requests a cyclic read can, and normally will, set up a memory
location to receive a "consistency" value. This paper assumes that the agent
will initialize this location to a value of 1 and increment it every cycle, with
a limit of 32. If the value changes to zero, the agent knows that the cyclic
read took place. When it is exactly equal to 31, the agent will issue a count-
out alarm. The next cycle, when it is equal to 32, it will know that the alarm

--```,``-`-`,,`,,`,`,,`---

207
has been set; from then on, it will stop incrementing the value. If it changes
to any value above 32, the agent knows that the value is an error code.
An agent that requests a direct write can, and normally will, set up a memory
location to receive a "completion" status. This paper assumes that the agent
will set this location to a value of 1. If the value changes to zero, the agent
knows that the direct write took place. If it changes to any other value, the
agent knows that the value is an error code.
In addition, the parameters that are in the range of parameter numbers that
are defined as having status bytes will have a "counter" byte associated with
them. The contents of that byte will be reset by the direct "write delivery"
service every time there is a write to the corresponding parameter. The DBWS
will reset the same value any time there is an indirect write. The owner will
--```,``-`-`,,`,,`,`,,`---
initialize the value to 1 and increment the same value every cycle. If the value
grows to exceed some limit, the owner will know that "no one is writing to it".
In the description to follow, two "short-hand" terms are used:

- set "No-Com" will mean not only the setting of the "No-Com." status
bit in the status byte but it will also imply the setting of the
corresponding "Not-from-Process" status bit (bit 2).
- set "Bad" will mean not only the setting of the "Bad" status bit
in the status byte but it will also imply the setting of the
corresponding "Failed" status bit (bit 4) and the resetting of the
"No-Path" status bit (bit 5). Note that this pair will activate
the "failure handshake" described in Attachment 1 of the paper
"Status Byte".
There are five variations on the use of this communication completion

information:
1) all active input agents (only receive cyclic reads) will monitor
the consistency value. If it grows to equal 31, the active agent
will set "No-Com" in the status byte of the input word and will
optionally set "Bad".
2) all active output and logical node variable agents have two actions:
they set up a cyclic read and a direct write. They will operate as
if they also set up an independent integer for their private use as a
communication counter. The integer will be initialized to 0. Any
time that the active agent detects a successful cyclic read followed
immediately by a successful write, it will reset the integer.
Otherwise, it will increment the integer. If the integer indicates
that there have been three cycles without a successful read/write
pair, "No-Com" will be set in the status byte of the output word.
The "Bad" status may optionally be set at the same time.
3) writeable agents have the capability of "counting out" based on the
"counter" set up as part of the words with status bytes. If the
counter value exceeds 30 (a fixed limit), the agent will optionally
mark the I/O word "No-Com" and optionally, "Bad".
4) the Cas and RCas transfer locations use their counters even though
they are not I/O words. If their counter exceeds 30 (a fixed value),
"No-Com" will be set in the status byte of the value. If, at that
time, the mode indicates that their values are being used as the
setpoint, the mode will be transferred to a higher-priority mode
depending on the block algorithm and certain other conditions.
5) the ROut transfer locations operates the same as given in item (4)
except that the limit is 7, not 31.
When the monitored values are subsequently reset by a successful
communication or pair of communications, the status bits that were set as a
result of the loss of communication will be controlled by the status byte
that is successfully read.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
208
DBWS COMPLEX WRITES:

The User Layer design has the need for several relatively unique and/or
complex write services. These services are all "writes". As an example, some
applications need the following general service or a variation of it:
IF the value of parameter "r" is equal to the value "n", then
write the value "v" through the mask "m" into parameter "p".
increment the value in "r".
IF the new value of "r" is zero, set "r" = 1.
ELSE
respond with an appropriate error message.
Variations of this service are also needed that are supersets and subsets of the
above form or have an alternative structure in which the value of parameter "r"
is initially checked for any negative number instead of a specific value and/or
the value of it is set to a given value instead of incremented.
A specific application of this service might need to check the data base
revision number "r" to see if the data base has been changed by some other device
(the application knows the revision number from a previous access) and, if not,
write the value "v" to the parameter "p", then index the revision number. These
operations must be done in one atomic operation in order to maintain time
coherency of the action and the revision number can not be allowed to roll over
to zero.
The User Layer Support Services are not designed to provide such services.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
In the User Layer design, the need for this service always involves
parameters that can not be addressed by agents, i.e., a direct write can not
address the parameters that need these special services. Therefore, the special
services can and will be provided by the DBWS.
A special series of parameter numbers are defined that will be recognized by

the DBWS as "dummy" parameters. The parameter numbers will be in the range that
can not be addressed by agents. The data that will be written to these dummy
parameters will be in a complex form and will be interpreted by the DBWS. See
the paper "Data Base Write Service" for a detailed definition of this service.
CYCLE SYNCHRONIZATION:
Cycle synchronization is described in the paper "Data Owner Structure -
Logical Nodes", page 27. That scheme only operates with inactive agents. It is
based on a measure of the difference between the time that a scheduled direct
write of a parameter (or a cyclic read of a parameter) takes place and the time
that the parameter value was used (or stored) by the function block execution.
The beginning of the next logical node cycle is then delayed as appropriate to
minimize that time.
The Applications Support Services I/F is based on a model which executes all
of the read and write functions within the lower layer. However, detailed
examination indicates that there will be some code in the User Layer in real
applications to support the read and write functions. Therefore, the exact method
of determining the time of the direct write is left to the implementers. It is
only required that the overall synchronization scheme be able to determine
exactly when the Application Layer executed the direct write into the data base
parameter.
The time at which a cyclic read of a parameter takes place is provided for in
the optional User Layer routine identified in the "Subscribe Response" service
and called every time the parameter is published.

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^
209
The synchronization scheme will capture the time at which the values are read
(or stored) by the User Layer. The difference in time can be calculated,
compared to the tolerance, and the start of the next logical node cycle delayed
to minimize the time difference.
--```,``-`-`,,`,,`,`,,`---

210
Attach. 1 Support Services

The user layer (UL) is a set of programs for the operation and communication
of tagged objects (TO). The TO include function blocks, logical nodes, and
physical nodes. The communication programs interface to the user layer support
services (US). These services need to be defined independently of UL
implementations, as the UL and US may be done by separate manufacturers.
HyperReader Note: click on the word "layer" in the above

paragraph, just for kicks.
This paper will define each of the services provided by the US.

1 USER APPLICATION SUPPORT SERVICES
1.1 Parameter Access Services - Associations
1.2 Parameter Access Services - Periodic
1.3 Multicast Services
1.4 Event Reporting Services
1.5 Time Services
1.6 Utility Services
2 DIRECTORY SERVICES
3 DATA DICTIONARY SERVICES
4 MANAGEMENT SERVICES
4.1 Generic Management Services
4.2 Address Management
4.3 Time Management
5 NOTES ON TIME
5.1 Node Clock
5.2 Private Clock
1. USER APPLICATION SUPPORT SERVICES:

These services handle the communication needs of the TO. Other services, to
be described in sections 2-4, are required for the system operation.
1.1 Parameter Access Services - Associations:

These services provide the functionality of point-to-point
connections between a UL and a TO, for one or many transactions.
1.1.1 Schedule Communications:

The UL asks the US in its own device to schedule capacity in a
range of times. The US replies with the actual start time and an
ID for the schedule, if possible. The capacity may be used once or
periodically.
1.1.2 Cancel Scheduled Communications:

The UL tells its US to release scheduled communication
capacity by canceling the schedule with a specified ID.
1.1.3 Open Association Services:

The UL uses these services to establish a path to a TO. Once
established, the UL may read and write TO parameters. The TO is
not able to initiate communication to the UL that established the
path. An association will be broken by the UL containing the TO if
its tag or function is changed, or it otherwise becomes
inconsistent with the original association.
Open Request:
The UL sends a request to another UL to open an
association with a TO. The request contains a shorthand
SP-50 User Layer Technical Report Application Support Services - Attach 2 210
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
211
reference to the 16 character tag of the TO which will be

resolved into a communication address by the initiating US.
It also contains the name of the application in the UL that is
making the request, so that the UL containing the TO will know
who is trying to establish a connection. It may contain other
data related to security. The UL also allocates some space
for data about the association to be returned if the
connection is established.
A status reply is sent by the responding UL indicating

that the request message either succeeded or failed, but the
association is not complete until the open response is
received.
Open Indication:
The UL containing the TO must have a program to handle an
open request from another UL. That program is notified that
it has work to do by the open indication, which passes the
data sent by the initiating UL (IUL).
Open Response:
The responding UL (RUL) sends data to its own US
describing the TO, and the location in the RUL of any read or
write handlers required by the TO. It also sends a message to
the IUL that identifies the association. This ID will be used
by all read and write requests from the IUL to the TO. The
message may also contain additional data about the association
or communication security.
1.1.4 Close Association Services:

An association may be closed by the IUL, the RUL, or either US
in case of failure.
Close Request:
Either UL can ask its US to close an association with a
specified ID. If the IUL makes the request, it will receive a
status reply.
Close Indication:
A UL may have a program to handle unexpected closure of
associations. If it does, this service passes the association
ID and the reason that it was closed to that handler.
1.1.5 Define Parameter Group:

The IUL may request that a specified parameter be used to
reference a collection of parameters, possibly as a display list.
The group may only be defined for a specific association. That is,
the parameter has no special meaning to any other association. The
list contains items in the form "tag dot parameter" but all tags
must be in the physical node addressed by the association. For
example, an association may be made to a Logical Node (since it is
a TO) containing several function block TO. Parameters from
different blocks may be put in the list. An association for this
purpose may be made to a Physical Node, but the TO in the group
must all be serviced by the same Field Bus interface.
The list may be changed at any time by the IUL, as it controls

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
traffic over the association.
A status reply is sent by the RUL.
1.1.6 Read Services:

The IUL may use an association to read data from a TO
parameter. The IUL must specify whether the RUL is to handle the
read request, or to have the RUL US reply directly. Under normal
circumstances, all reads will be direct except for a few
parameters in the "Interface" function blocks.
--```,``-`-`,,`,,`,`,,`---

212
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Read Request:
The IUL asks its US to read a specified parameter of a
specified association, and provides a buffer to contain the
reply. The RUL US sends a status reply, which contains the
data if the read was successful or an error code if the read
failed. This is the only response from the RUL. In the
meantime, the status is "wait for completion".
Read Indication:
If the read is not direct, this service notifies the RUL
read handler and passes it the parameter to read. When done,
the read handler issues the read response.
Read Response:
The RUL read handler asks its US to send the requested
data to the IUL.
1.1.7 Write Services:

The IUL may use an association to write data to a TO
parameter. The write may be direct, or it may be queued up for
the RUL Data Base Write Service (DBWS), as determined by the IUL.
Under normal circumstances, most writes will be queued for the
DBWS. Direct writes should only be used for writes supporting
configured operation of TO and higher level entities that resemble
TO or when the DBWS is not available. See the section "Read/Write
During Failure" in the Technical Report paper "Field Device Start
and Restart."
Write Request:
The IUL asks its US to write a specified parameter of a
specified association, and passes it the data to be written.
It may also include data to satisfy the security needs of the
association.
The RUL US sends a status reply if the read was direct

and/or failed, which ends the transaction. Otherwise, the
request is put in the DBWS queue, along with the IUL
association ID, and the reply sent is either the data or the
failure code. There is only one response from the RUL.
There is no write indication because all UL contain a DBWS,

which uses the Dequeue Service (to be described later) to discover
write requests.
Write Response:
--```,``-`-`,,`,,`,`,,`---
The RUL DBWS will send a status message to the IUL with
an ID linking it to the original request.
1.1.8 Masked Write Services:

These services are identical to the above write services,
except that the data includes a mask that controls the writing of
each bit in the destination. The write may be direct or through
the DBWS.
Masked Write Request:

The IUL asks its US to write a specified parameter of a
specified association, and passes it the data to be written
and the mask to determine which bits to write.
Masked Write Response:

Identical to the plain write response.

213
1.2 Parameter Access Services - Buffers:

These services provide the functionality of links between (or
among) TO parameters. They provide the prefetch communication described
elsewhere in the Technical Report. They are set up once when a device
starts up, and left running until the control configuration is changed
in a way that affects the link. Once set up, the UL has nothing to do
with them. The US move the data.
An association is not required for these services. It is the

user's responsibility to control the number of things that write to a TO
parameter.
1.2.1 Publish Service:

The UL containing a TO that needs to send data to another TO
in another logical node asks its US to set up a cyclic write of a
specified "tag dot parameter" at specified start and cycle times,
and to take the data from a buffer (normally the agent of the TO
that caused this write to be set up), with optional consistency
data as determined by the agent.
The US will negotiate a schedule with the network. It will

return a status to the UL, either success when the first data is
sent, or failure, if that happens prior to sending the first data.
It also returns an ID to be used in cancelling the service.
Publish Request:
The IUL asks its US to publish a specified tag.parameter
along with a consistency number on a cyclic schedule. The
IUL specifies the required time window for the start and the
required period of the schedule. The IUL can optionally
specify a procedure to be called whenever the parameter is
published (the call is made immediately after the value is
published and is intended for error detection).
Publish Confirm:
If the Publish Request specified a procedure to be
called whenever a parameter is published, then the Publish
Confirm is the mechanism for calling that procedure.
1.2.2 Subscribe Service:

The UL containing a TO that needs data from another TO in
another logical node asks its US to set up a cyclic read of a
specified "tag dot parameter" at specified start and cycle times,
and to put the data in a buffer (normally the agent of the TO that
caused this read to be set up), with optional consistency data as
required by the agent.
The US will negotiate a schedule with the network, or arrange

to receive data that is already being sent by the desired TO on its
own schedule. If the specified start and cycle times are null,
only the pre-existing schedule will be used. It will return a
status to the UL, either success when the first data is received
into the buffer, or failure, if that happens prior to receipt of
the first data. It also returns an ID to be used in canceling the
service.
[Note that this service could cause multiple transmissions of

the desired TO data to satisfy multiple schedules. Caveat
--```,``-`-`,,`,,`,`,,`---
Configurer.]
Subscribe Request:
The IUL asks its US to subscribe to a publisher of a
specified tag.parameter. Consistency information can

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
214
accompany the parameter value. The IUL can optionally

specify the required time window for the start and the
required period of the schedule. The IUL can optionally
specify a procedure to be called whenever the parameter is
read.
Subscribe Indication:
The UL containing the TO must have a program to handle a
subscribe request from another UL. That program is notified
that it has work to do by the open indication, which passes
the data sent by the initiating UL (IUL).
Subscribe Response:
The responding UL (RUL) sends data to its own US
describing the location in the RUL of the requested parameter
and the location of the consistency information. The data can
optionally include the identification of a routine to be called
whenever the requested parameter is published.
Subscribe Confirm:
If the Subscribe Request specified a procedure to be
called whenever a parameter is published, then the Subscribe
Confirm is the mechanism for calling that procedure.
1.2.3 Cancel Buffer Service:

The UL that started a periodic service may cancel it by asking
its US to cancel the service with a specified ID. In the case of a
write, this may cause trouble for reads that use the schedule of
the write. In the case of a cancelled subscription, the request
may or may not cancel the publishing, depending on whether there
are any other subscribers.
The US will return a status. This may be delayed by

communication on the network to re-adjust schedules.
Cancel Buffer Service Request:

The UL tells its US to cancel a particular buffered
service.
Cancel Indication:
The UL containing the TO must have a program to handle a
buffered service cancel request from another UL. That
program is notified that it has work to do by the cancel
indication, which passes the identification of the service to
be canceled and the reason code that explains why the
association was closed.
1.3 Multicast Services:

The network supports a set of multicast addresses. An address does
not correspond to any physical device, but if a message is sent to one,
it can be heard by those devices that have requested to receive
transmissions to that address. These services do not support duplicate
message detection or error recovery. These services are required for
event reporting.
1.3.1 Multicast Send Request:

The UL asks its US to send a specified data buffer to a
specified multicast address. The US returns a status for the
transmission. The UL can not determine that anyone heard it.
1.3.2 Accept Multicast Request:

The UL asks its US to receive data for a specified multicast
address. It must also specify either (or both) a multicast handler
program in the UL, and a pointer to a location that can be used to
SP-50 User Layer Technical Report Application Support Services - Attach 2

--```,``-`-`,,`,,`,`,,`---
214

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
215
identify a data queue in the US. The US will return the status of
the request, and an ID for future reference to the request.
1.3.3 Accept Multicast Indication:

The US indicates to the UL multicast handler that data has
been received for a specified multicast request ID. It must also
include the data if there was no queue specified in the request.
1.3.4 Cancel Multicast Acceptance Request:

The UL asks its US to cancel a specified multicast request ID.
1.4 Event Reporting Services:

The event service has the following characteristics:
1. There is only one such service in a physical node. All events

generated by all TO in the physical node are reported to this
service.
2. Reported events are gathered in a buffer in the US. The

contents of the buffer are sent to a multicast address when a
specified number of events have been reported, or a specified
time has elapsed since the first report entered the queue. The
multicast is unconfirmed.
3. The multicast message sent is called the event message (EM).

Each EM has a sequential serial number. Receiving devices can
tell if a message is missing, or is a duplicate. Services are
provided to recover missing messages.
4. A dummy EM will be sent if a specified time between messages

elapses. This message will have a sequence number, but it will
not be incremented. Receiving devices can tell if a device that
should be sending messages has stopped doing so.
5. A specified number of EM will be saved at the originating

physical node. Storage is cleared by specifying an expiration
time, allowing old EM to be removed. If storage fills up, no
new EM can be assembled and sent.
6. An EM will never contain a partial event report.
1.4.1 Post Event Request:

When the UL discovers an event while processing TO, it asks
the US to add it to the buffer. The US determines when to send an
EM, using data provided by the Set Parameters service, to be
described later.
1.4.2 Event Enrollment Services:

When a UL enrolls in an event, it will be notified either when
EM arrive from a specific source, or the source has stopped
sending, after a time of silence.
--```,``-`-`,,`,,`,`,,`---
Event Enrollment Request:

The UL asks its US to receive multicast EM from a
specified TO (which must be a physical node). It must also
specify either (or both) an EM handler program in the UL, and
a location in which to store a pointer to a data queue in the
US. The US gets the maximum time between EM and the current
EM sequence number from the TO and then returns the status of
the request, and an ID for future reference to the request.
If all went well, the status is "wait for completion". If an
EM is received before the maximum time, the status becomes
"success", otherwise it failed.

//^:^^#^~^^"~~:~

216
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Event Indication:
If the event enrollment request included an EM handler
identification, the US indicates to the UL EM handler that
data has been received for a specified enrollment ID. It
must also include the data if there was no queue specified in
the request. It may also indicate that a failure has
occurred.
1.4.3 Cancel Event Enrollment Request:

The UL asks its US to cancel a specified enrollment ID.
1.4.4 Get Event Sequence Number Request:

The UL asks the US to return the Event Sequence Number (ESN)
of a specific tagged object. The UL does not have to be enrolled
in the TO to do this. The US gets the ESN with a secure
point-to-point message, and returns it and the status to the UL.
1.4.5 Read Event Request:

The UL asks the US to return an EM with a specified ESN from a
--```,``-`-`,,`,,`,`,,`---
specified TO. The UL does not have to be enrolled in the TO to do

this. The US gets the EM with a secure point-to-point message, and
returns it and the status to the UL.
1.4.6 Get Event Control Parameters Request:

The UL asks its US for a copy of the parameters that the US
is using to control the generation of EM. The US returns the
parameters (described below) and a status.
1.4.7 Set Event Control Parameters Request:

The UL tells its US what parameters to use for event
generation. If this causes a change to the maximum time between
EM, the US will send an EM containing the new time so that those US
enrolled in reading events can update the failure time. The US
will return a status.
Some of the parameters may be subject to limits. Some of them

may be fixed, depending on the implementation. The following is
the required list of parameters:
o Maximum time to delay reporting an event.
o Maximum size of an EM.
o Maximum time between EM.
o Maximum number of transmitted EM to save.
o Minimum time to save a transmitted EM.
1.5 Time Services:

Each physical node has a clock called the node clock. It starts
from zero whenever power is applied, and before social time can be
determined. A node to social offset (NSO) register is provided to
contain the difference between social time and node time.
1.5.1 Get Node Time Request:

The UL asks the US for the current node time. The US
quickly replies with the value.
1.5.2 Get Node Time Offset Request:

The UL asks the US for the NSO in this node. The US returns
the offset; if the value is zero, the node has no sense of network
coordinated time.
1.5.3 Read Node Time Offset Request:

The UL asks the US for the NSO in another node. The US
returns the offset and a status code.

217
1.6 Utility Services:

These services do not fit in the above categories.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
1.6.1 Dequeue Request:

The US may queue messages for writes and events. This service
is used by the UL to retrieve the data from a specified queue.
1.6.2 Disable Request:

If the UL makes a change to a TO that affects consistency,
like the tag or function, then it must ask the US to use this
service to break all associations and cyclic operations for a
specified TO, and to block the formation of any new ones.
1.6.3 Enable Request:

When the UL is done changing the TO, a consistency variable
is incremented so that other services will know that it has been
changed. The UL must then use this service to ask the US to
unblock attempts to form associations or establish cyclic
operations. This service will not re-establish the associations
and cyclic operations that were closed when the disable request
was issued.
1.6.4 Inhibit Direct Access:

When the UL is interacting with its own data base, it may
have to temporarily inhibit direct reads and writes in order to
maintain time coherency of the data. During the inhibit, direct
reads and writes are queued; they are processed after access is
again permitted. Note that the indirect writes are processed by a
procedure that is within the UL, hence they do not need a US
inhibit service.
Inhibit Request:
The IUL asks its US to inhibit direct read and write
access to a specified TO.
Permit Request:
The IUL asks its US to again permit direct read and
write access to a specified TO.
1.6.5 Wakeup Service:

The UL can ask its US to notify a specified program when a
specified time is met or exceeded. The time may be absolute node
or social time, or relative to when the request is received. The
type of request may be single or cyclic. Cyclic requires a time
interval specification. The US returns an ID for the service. The
specified program will be given the ID each time it is notified.
Request Wakeup Request:

The IUL asks its US to wake it up at a user specified
time. The request indicates whether the wakeup is cyclic or
one time, the wakeup time and the time basis (social, node,
or relative). If the request is for cyclic wakeups, the
request must specify the interval between wakeups. It also
specifies the UL function to be called at the wakeup time.
Request Wakeup Response:

When the time arrives for a wakeup, this command is sent
to the UL function specified in the wakeup request. It
includes an identifier of the particular wakeup service.
1.6.6 Cancel Wakeup Request:

The UL tells its US to cancel the wakeup request specified by
the service whose identifier is included in the request.
--```,``-`-`,,`,,`,`,,`---

218
2. DIRECTORY SERVICES:
The directory contains information about each TO that is useful to US for
communicating with a specified TO. The node containing a TO is considered to be
the final authority on data for that TO.
2.1 Register Tag Request:

The UL asks its US to place a specified tag name, its network
address, and its related tag names in the directory. No network
communication occurs. The US returns a shorthand reference to the tag.
For each "base" shorthand reference, the directory will keep two
associated shorthand references: one to the "physical node" and one to
the "logical node". If the base reference is a function block, the
other two references will be as implied. They may be the same as the
base reference because of tag name condensation (i.e., if there is only
one function block (logical node) in a logical node (physical node), the
two data bases "condense" under one name). If the physical (logical)
node tag name is blank, then the base reference was to the physical
(logical) node.
For each physical node tag name, the directory will also contain
its manufacturer name, model number, and serial number. This data will
exist as the visible strings taken from the data base of the physical
node and concatenated. All sets of spaces greater than one space long
will be reduced to a single space. This information will not be
accessible from the directory but will be used by the Address Recovery
Service "Distribute Addresses".
2.2 Remove Tag Request:

The UL asks its US to remove a specified tag name and its address
from the directory. No network communication occurs.
2.3 Locate Tagged Object Request:

The UL asks its US to find a specified tag on the network. If the
tag is found, the US registers both tag and network address in the
directory, and returns:
- a shorthand reference to the tag.
- a shorthand reference to the logical node housing the tag
(blank if the specified tag was a logical node)
- a shorthand reference to the physical node housing the tag
(blank if the specified tag was a physical node)
3. DATA DICTIONARY SERVICES:

The data dictionary is a set of data that is used by the US to control
communication with TO and their parameters without requiring UL handlers. It
resides in, and is maintained by, the US.
The data dictionary contains information about named objects. All named
objects are associated with a TO. A named object may be a TO, or a parameter of
a TO, or an independently named object. The information about an object is
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
219
called its attribute. The data that describes the attribute of a named object
may not exceed 200 octets. The data dictionary of a physical node must contain
its manufacturer name, model number, and serial number.
--```,``-`-`,,`,,`,`,,`---

220
3.1 Get Named Object List Request:

The UL uses this service to discover what named objects are
contained in a physical or logical node. It may also be used to get a
list of named objects in any single TO. The UL specifies the tag of a
device containing a data dictionary. It further specifies a TO name
string and a named object string.
The returned data will be stored in a specified UL buffer.
3.2 Read Named Object Attribute Request:

Once the list of named objects is known, the UL may use this
service to discover the attributes of a named object. The UL must
specify the tag of the device containing the data dictionary, the name
of the TO, and the name of the named object (parameter) to be read.
The returned data will be stored in a specified UL buffer.
3.3 Add Named Object Request:

This service allows a UL to add a named object and its attributes
to a specified TO within its own node. No network communication is
required.
3.4 Delete Named Object Request:

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
This service allows a UL to delete a named object and its

attributes from a specified TO within its own node. No network
communication is required.
3.5 Set Named Object Attributes Request:

This service allows a UL to create or modify an attribute of a
named object of a TO within its own node.
3.6 Remove Named Object Attributes Request:

This service allows a UL to delete an attribute of a named object
of a TO within its own node.
4. MANAGEMENT SERVICES:
These services comprise generic services, which operate on the layers,
address management services, which establish or recover addresses, device
download services, and social time setting services.
4.1 Generic Management Services:

These services include read, write, initiate, and report operations
for a specified layer in a specified device.
--```,``-`-`,,`,,`,`,,`---
4.1.1 Get Request:

The UL asks the US to get a layer parameter, specifying the
tag of the device containing the layer, the layer entity ID, and
the parameter.

221
4.1.2 Set Request:

The UL asks the US to set a layer parameter, specifying the
tag of the device containing the layer, the layer entity ID, and
the parameter.
4.1.3 Action Request:

The UL asks the US to initiate a layer activity, specifying
the tag of the device containing the layer, the layer entity ID,
and the action number to be performed.
4.1.4 Notification Services:

Layer management uses the event reporting service of the
physical node to report events, without involving the UL of the
field device.
4.2 Address Management:

The following services are used to create new devices on the
network, or to recover from some event that has caused tags or addresses
to be lost.
4.2.1 Tag/Address Assignment:

The network has one or more addresses intended for
communication with devices that do not have an assigned address. A
new device must first have a tag name given to its physical node.
Then a unique bus address may be assigned. Before it is tagged, a
physical node is known by its (presumed unique) manufacturer name,
model number, and serial number. A new device can be tagged when
it is not on the network, and it can be given a bus address, but
neither can be guaranteed to be unique. The device may have to be
tagged by itself, but the address assignment should occur while the
device is on the network. The following services are useful:
Get Untagged Device ID Request:

The UL of a device capable of assigning tags asks its US
to send a request to the network address used for this
purpose, for any untagged physical node to return its device
ID (name, model, and S/N). The US returns the device ID data
and a status. The request may fail because no device replied,
or more than one device replied, which would produce a garbled
message.
Write Physical Device Tag Name Request:

purpose, to write a specified tag to any device with a
specified device ID. A device will not write the tag if its
device ID does not match the one in the message. The US
returns a status from the previously untagged device.
Assign Fieldbus Address Request:

purpose, to have a device with a specified tag name set its
bus address to a specified value. If the specified address is
zero, the network will determine an address and return it to
the US. The US returns a status based on the remote address
assignment.
4.2.2 Address Recovery Services:

These services are used to recover from the situation where
one or more devices have lost the physical node tag and/or the bus
address. The bus address is easily restored if the device tag is
retained. The tag can only be restored automatically if a list of
tag - device ID pairs has been kept up to date.
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
222
Distribute Addresses:
The UL asks the US to send a list of tag - address pairs
to a specified distribution address. The list could come from
the directory. Any device with a matching tag will set the
bus address specified in the message. The US returns a status
when the list has been transmitted, but there is no knowledge
of what happened in the other devices.
Restore Physical Node Tag Names:

There is no separate service for this purpose. Use the
Write Physical Device Tag Name Request service described
earlier.
4.3 Time Management Services:

There will be a designated node in the network that is responsible
for publishing the social time offset. That node will be called the
"network time server".
Become NTS Request:

The UL of a device capable of calculating and publishing the
social time offset asks its US to attempt to become the network
time server. The service returns an indication of success or a
reason for a failure.
Relinquish NTS Request:

The UL of a device that is currently the network time server
instructs its US to cease to be the network time server. The
service returns an indication of success or a reason for a failure.
Set Social Time Offset Request:

The UL of a device that is currently the network time server
instructs its US to set the social time for the network. The UL
passes the social time to the US. The service returns an
indication of success or a reason for a failure.
5. NOTES ON TIME:
5.1 Node Clock:

A physical node has three values of time, defined as follows:
1. Node time - a 48 bit register incremented 32,000 times per

second, cleared at start-up of the physical node.
[48 bits at 32000 ticks/second is about 278 years.]
2. Link time - the 48 bit sum of node time and the link time
offset (LTO) (not seen by the user layer).
3. Social time - the 48 bit sum of node time and the node to social
time offset (NSO). The origin of social time is
midnight of 1 January, 1970.
Node time increases monotonically into the far future, until the next start-
up of the node. The rate of increase is controlled by the link layer, so that
all nodes will have the same value for link time.
Link time is determined by a link time master. Link time slaves adjust their
LTO to match. Link time is only required to be stable enough to permit
scheduling bus traffic over relatively short intervals. It has no relationship
to sunrise.
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
223
Social time is determined by something external to the network. It could be

someone using a human interface to set the social time to match wall clock time.
This bumps the STO in all network devices. Any device must post an event when
its STO is changed, done by the US, because events are posted with node time, not
social time. If the node clocks were not synchronized by the link layer, the STO
would have to be updated frequently, generating many events to be stored.
If an external time standard is available, such as WWV (primary) or the power

line frequency (secondary), then the link time master node clock rate can be
adjusted to keep it close to true time over long periods. If the rate is
adjusted, the NSO only needs to be set once when a node starts upand gets on the
network. Since social time is kept as Universal Coordinated Time (UTC), the
daylight savings time issue is handled by the display devices, by telling them
the rules for translating UTC to local time. Unix, for example, has extensive
support for this conversion.
5.2 Private Time:

It is possible that a Field Bus device will be connected to a gateway to a
foreign device that has its own clock, but does not support any form of
synchronization. If it is possible for the gateway to read the foreign time, it
can calculate the offset with respect to Field Bus social time. This offset may
be used to convert the time in events received from the foreign device to local
node time. The precision of the conversion will vary with the application.
The offset will be made available as a parameter called PRIVATE_OFFSET. This

parameter will be stored in the logical node's data base, thus allowing each
logical node to support a private time.
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
224
Attach. 2 Extended Parameters
EXTENDED PARAMETER ENCODING

Bit 15 in each of the TIME_CRIT0 options bit strings in tagged objects will
indicate the existence of "extension variables" that have been added to the
standard Field Bus function block by the field device manufacturer. This paper
will define the system that is provided to define such extension variables.

BACKGROUND
OVERALL STRUCTURE
DETAILED LAYOUT OF EXyz
Table 1 - EXyz codes
BACKGROUND:
When bit 15 is set in the TIME_CRIT0 options bit string of a tagged object
(TO), then that TO must contain one or more extension variables. When bit 15 is
set, there must be a parameter called EXy0 in the data dictionary of the TO. If
the TO is a physical node, y = P; if a logical node, y = L; if a function block,
y = B.
Any Field Bus device can access EXy0 to find the following information:
- the extension variable's parameter number, its data type, its
descriptor strings, etc.
- all extension parameters associated with that variable that must
be included in a static data base image.
- the existence of another extension variable - leading to EXy1,
etc.
The reader should note that certain information can be obtained about a
parameter simply by inspection of its parameter number. The paper "Array of
Basic Parameters" gives the complete definition of the parameter system and a
summary is given on page 19 of that paper. Some of the more important pieces of
information are:
- can be read (if bit 15 is reset).
- can be directly written (if bit 14 is reset).
- can be indirectly written (if bit 13 is reset).
- when bit 12 is set,
+ the parameter is under the data base revision number if bit 11
is set.
- when bit 12 is reset and the parameter is in a function block:
+ if bits 10 & 9 = 00B, then there is no mode restriction on
writing the parameter
+ if bits 10 & 9 = 10B, then, in simple terms, the parameter can
only be written when the mode is in Man or O/S
+ if bits 10 & 9 = 11B, then, in simple terms, the parameter can
only be written when the mode is in O/S.
The coding system defined for extension variables in this paper will take
advantage of those parameter attributes that can be easily deduced from the
parameter's assigned identification number.
OVERALL STRUCTURE:
The coding system is arranged to define two "levels" of extension parameters
- "value" variables and "support" variables. For example, there may be need for
SP-50 User Layer Technical Report Applications Suppt Serv - Attach. 2 Extended Parameters
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
225
an extra block output word. It would be a "value" variable. In order to fully

support the extra output word, there must be other extension variables that
define its engineering units, its display range, its display attributes, a
descriptor, etc. These are "support" variables.
In general, there will be one data dictionary parameter called "EXyz" for
each "value" variable. That EXyz will indicate the existence of the associated
"support" variables.
The data contained in "EXyz" will always be arranged in 3-byte groups. The
codes that are defined in this paper will always be in the first byte of the
group. Therefore, any Field Bus device can easily scan the data string, looking
at every third byte until it finds the information that it needs.
The "value" variable is not necessarily in the static data base. Its
assigned parameter number will indicate whether it is under a revision number.
However, in order to simplify the coding of the static data base backup routine,
the coding system will explicitely identify those value variables that are in the
static data base.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
The "support" variables can be shared by two or more value variables or may
even be variables that are already defined in the standard block. This
flexibility could lead to inefficiency when a higher level device attempts to
backup the static data base - a single, minimized list of static data variables
is needed. Therefore, the 3-byte groups in each Exyz parameter will be arranged
in the following order:
1) the group identifying the "value" variable
2) the group identifying any "support" variables that are newly
introduced AND are under a revision number.
3) the groups identifying "support" variables that have already been
introduced (in earlier EXyz parameters or as standard
parameters), and support variables that are not under a data base
revision number.
The data in the data dictionary parameter (EXyz) is assembled by the

manufacturer and entered into the data dictionary by the field device. It is
completely coded so that it is not specific to any particular language or
character set. It can not be changed by the user. The information allows a
higher level device or a human interface to access parameters in the data base of
the field device for the actual values or visible strings.
DETAILED LAYOUT OF EXyz

The EXyz data dictionary parameter will be composed of three-byte groups of
data. The groups within EXyz will be arranged as follows:
1) a code indicating the existence of a "value" extension variable
followed by the parameter number of that variable (required).
2) codes indicating the existence of newly introduced "support"
extension variables that are part of the static data base, each
followed by the parameter number of the variable (optional).
3) one of two codes indicating the end of the "new" static data
base variables - one code for cases in which the value variable
is under a revision number, one for otherwise. The 2-byte
field will be used to indicate whether there is more data in
this parameter and whether there are any more EXyz parameters
for this TO (required).
4) codes indicating the existence of "support" extension
variables that were introduced elsewhere, each followed by the
parameter number of the variable (optional).
--```,``-`-`,,`,,`,`,,`---
The codes themselves are defined in Table 1. All codes are 1 byte and are
followed by a 2-byte argument. Usually, but not always, the argument is the
parameter number of a parameter in the TO's own Field Bus accessible data base.
All parameter references must be to the TO that contains EXyz.

226
TABLE 1, EXTENSION VARIABLE CODES IN EXyz

EXTENSION VARIABLE CODES IN EXyz
The three types of codes that can be used are:

Value Variable Codes
Static Data Flag
Support Variable Codes
Value Variable Codes:

- One of these codes must be the first byte in EXyz
- all of these codes are to be followed by a 2 byte parameter number.
- These codes can not be used at any other location in EXyz.
0 = 4 byte floating point without a status byte.

1 = 4 byte floating point with a status byte.
2 = 8 byte floating point without a status byte.
3 = 8 byte floating point with a status byte.
4 = 8 bit unsigned integer
5 = 8 bit signed integer
AH = 64 bit unsigned integer
BH = 64 bit signed integer
CH = 8 bit bitstring (single bit definitions)(no status byte)
DH = 8 bit bitstring (complex bit definitions)(no status byte)
EH = 8 bit bitstring (single bit definitions)(1 status byte)
FH = 8 bit bitstring (complex bit definitions)(1 status byte)
10H = 8 bit bitstring (standard discrete SP format with 3 status bytes)
11H = 8 bit bitstring (standard discrete SP format with 5 status bytes)
12H = 8 bit bitstring (single bit definitions)(9 status bytes)
13H = 8 bit bitstring (complex bit definitions)(9 status bytes)
14H = 16 bit bitstring (single bit definitions)(no status byte)
15H = 16 bit bitstring (complex bit definitions)(no status byte)
--```,``-`-`,,`,,`,`,,`---
16H = 16 bit bitstring (single bit definitions)(1 status byte)

17H = 16 bit bitstring (complex bit definitions)(1 status byte)
18H = 16 bit bitstring (single bit definitions)(17 status bytes)
19H = 16 bit bitstring (complex bit definitions)(17 status bytes)
1AH = 32 bit bitstring (single bit definitions)(no status byte)
1BH = 32 bit bitstring (complex bit definitions)(no status byte)
1CH = 32 bit bitstring (single bit definitions)(1 status byte)
1DH = 32 bit bitstring (complex bit definitions)(1 status byte)
1EH = 32 bit bitstring (single bit definitions)(33 status bytes)
1FH = 32 bit bitstring (complex bit definitions)(33 status bytes)
20H = 64 bit bitstring (single bit definitions)
21H = 64 bit bitstring (complex bit definitions)
22H = 116 bit bitstring (single bit definitions)
23H = 116 bit bitstring (complex bit definitions)
24H = 48 bit time - expressed in 1/32 of milliseconds
25H = 8 bit enumerated variable
26H = 16 bit enumerated variable
27H = 8 byte (4 characters in UNICODE) visible string
2AH = 64 byte (32 characters in UNICODE) visible string
2BH = 64 character (default to 1-byte code) visible string
2CH = 116 character (default to 1-byte code) visible string
FFH = Coding system escape - the contents of the parameter that
follows this code will be defined by the alternate coding
system.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
227
Static Data Flag:

- This code must be used after any Support variable definition codes
that introduce new variables and before any Support variable codes
that refer to variables already introduced.
FDH = end of new static data list - the value variable is NOT in the
static data base.
FEH = end of new static data list - the value variable IS in the static
data base.
For each of the above two codes:

The low byte of the following 2-byte field will indicate the
number of EXyz parameters for this TO that follow the current
EXyz. The high byte of the following 2-byte field will indicate
the number of 3-byte groups in this EXyz that follow this group.
Support Variable Codes:

- These codes can be used both before and after the Static Data Flag
--```,``-`-`,,`,,`,`,,`---
40H - Engineering units description - 16 byte (8 characters in UNICODE)

visible string
visible string
visible string
43H - Variable Description - 32 byte (16 characters in UNICODE) visible
string.
44H - Variable Description - 64 byte (32 characters in UNICODE) visible
string.
45H - Variable Description - 64 byte (default to 1-byte code) visible
string.
46H - Variable Description - 116 byte (default to 1-byte code) visible
string.
47H - Text - 116 byte (default to 1-byte code) visible
string.
Note: this code can be repeated for
multiple parameters. All of the
text will be concatenated with the
first text parameter supplying the
first line of the text display.
48H - Display Attribute - 8 bit bitstring (see the paper "Human
Interface considerations, page 8 for a
definition of this parameter).
49H - First SI Units Word - 16 bit bitstring (see the paper "Human
Interface Considerations, page 7 for a
4AH - Second SI Units Word - 16 bit bitstring (see the paper "Human
Interface Considerations, page 7 for a
4BH - Write Mask - same data type as value variable but
restricted to bit strings.
Note: a set bit in this string indicates
indicates a bit in the value string
that can be written. If any bits
are reset in this string, then a
masked write must be used to write
the value variable.
4CH - Display High Range - same data type as value variable
4DH - Display Low Range - same data type as value variable
4EH - Existence Limit Lo - same data type as value variable
4FH - Existence Limit Hi - same data type as value variable
50H - Value Bit Pointers Bit pointers for each bit in the
6FH value variable. 50H is the
pointer to the source of bit

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
228
1. Format the same as for

standard bit pointers.
70H - Entry High Limit - same data type as value variable
71H - Entry Low Limit - same data type as value variable
72H - Typical Value - same data type as value variable
73H - Target Value - same data type as value variable
74H - Target Pointer - same format as TARGET_PARAM in PV Function
75H - Target Pointer 0 - same format as TARGET_PARAM0 in PV Funct.
78H - Target Filter - same format as TARG_FILTER in PV Function.
79H - Deviation Comp. Ctl. same format as DEV_LOGICAL in PV Function.
Note: for the next 8 codes, refer to the
definition of the PV Function alarm
operation.
7AH - Alarm HiHi Limit - same data type as value variable
7BH - Alarm Hi Repeat - same data type as value variable
7CH - Alarm Hi Limit - same data type as value variable
7DH - Alarm Lo Limit - same data type as value variable
7EH - Alarm Lo Repeat - same data type as value variable
7FH - Alarm LoLo Limit - same data type as value variable
--```,``-`-`,,`,,`,`,,`---
80H - Deviation Alarm Limit - same data type as value variable

81H - Alarm Deadband - same data type as value variable
82H - Discrete Alarm Log. - 8 bit bitstring - same format as
ALARM_LOGICAL in PV Function.
ALARM_LOGICAL in PV Function but
describes up to 7 bits.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
86H - Discrete Alarm DOT - Discrete alarm delay off timer -

same format as ALARM_DOT in PV
Function.
87H - Access Authority - 1 byte, unsigned integer
Special codes to define fields in a bitstring:
8FH - Bit Field Definition - same data type as value variable

90H to CFH - Bit Field Identification
A manufacturer may wish to define a bit string with definitions

for sets of bits within the string. This will be done in a two
step process. First, the fields must be identified in the bit
string, then the definitions for each field must be identified.
The bit fields will be identified using a bitstring that is the

same length as the value variable. The low order bit of each bit
field will be set. This will be called the "Bit Field
Definition".
The definitions for each field will be identified using code

numbers that are calculated from the following indices:
i = 0 = 32 byte (16 characters in UNICODE) visible string

1 = 64 byte (32 characters in UNICODE) visible string
2 = 64 character (default to 1-byte code) visible string
3 = 116 character (default to 1-byte code) visible string
j = field number, zero based count, counted from low order bit.
maximum value = FH
code = 60H + 4 * j + i

229
Special codes to define an array:
A manufacturer may wish to define a value variable as an array.
The array will be identified as A(x,y,z)

where: the subscripts are zero based.
the dimension of x defaults to 1
the dimensions of y and z default to 0
A(0,0,0) will be located at the parameter defined
for the value variable.
A(1,0,0) will be located at the next higher parameter
number.
etc.
D0H - the dimension of x

D1H - the dimension of y
D2H - the dimension of z
D3H - Description of x - 32 byte (16 characters in UNICODE) visible
string.
D4H - Description of x - 64 byte (32 characters in UNICODE) visible
string.
D5H - Description of x - 64 byte (default to 1-byte code) visible
string.
D6H - Description of x - 116 byte (default to 1-byte code) visible
string.
D7H - Description of y - 32 byte (16 characters in UNICODE) visible
string.
D8H - Description of y - 64 byte (32 characters in UNICODE) visible
string.
D9H - Description of y - 64 byte (default to 1-byte code) visible
string.
DAH - Description of y - 116 byte (default to 1-byte code) visible
string.
DBH - Description of z - 32 byte (16 characters in UNICODE) visible
string.
DCH - Description of z - 64 byte (32 characters in UNICODE) visible
string.
DDH - Description of z - 64 byte (default to 1-byte code) visible
string.
DEH - Description of z - 116 byte (default to 1-byte code) visible
string.
DFH - Correct parameter - 16 bit bitstring
Note: due to the size of the array,
it may not be possible to
assign the array the parameter
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
value that correctly describes

the parameter access
attributes. This parameter
indicates the correct
attributes.
--```,``-`-`,,`,,`,`,,`---

230
Data Base Write Service

A Field Bus data owner will have a relatively large data base. There will be
a number of other devices on the field bus that will need to interact with that
data base. The bus interface will need a communication service that controls
those interactions to ensure that complete data integrity and consistency is
maintained. The following discussion will refer to such a service as the "Data
Base Write Service" (DBWS).
Many of the controls in the DBWS are also needed for communication from on-
logical-node blocks, including the configurable part of the owning block itself.
Therefore, the DBWS is modeled as handling all of the write commands except those
from the algorithm of the owner block or node.

REQUIREMENT
INTRODUCTION
WRITE PROCESS SUMMARY
WATCH-DOG TIMER
Physical Node Failure
Status Byte Modification
I/O Hardware Directly Writeable
REVISION NUMBER SERVICE
Static And Auto-Format Revision Numbers
Clipboard Revision Numbers
STATUS BYTE SERVICE
PHYSICAL AND LOGICAL NODE SERVICE
FUNCTION BLOCK SERVICE - HIGHLIGHTS
FUNCTION BLOCK DYNAMIC DATA BASE
DETAILS OF LOGIC FOR WRITING
Table 1 - Logic for Indirect Writes
CASE Analog
CASE Discrete
Figure 1 - Application Layer - Writing to Buffer
Figure 2 - Clipboard Revision Number Logic
Attachment 1 - Complex Write Services
Figure 1 - Generic Conditional Writes
Figure 2 - Generic Conditional Writes (cont.)
Attachment 2 - DBWS Logic
Figure 1 - Buffer Service Logic
Figure 2 - Static & Auto-Format Data Base Revision Number
Figure 3 - Logical/Physical Node Values
Figure 4 - Mode
Figure 5 - Data Base Values
Figure 6 - Data Base Values (cont.)
REQUIREMENT:
This entire paper is presented based on an implementation model in order to
simplify the description. There is no requirement that the logic be executed in
the exact order specified nor that it even be implemented in the same fashion.
Rather, any implementation that produces results that can not be distinguished
from the results of the model, with regard to timing or logic, when viewed
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
externally from the Field Bus, will be completely acceptable, even in Standard
Field Devices.
SP-50 User Layer Technical Report Database Write Service

--```,``-`-`,,`,,`,`,,`---

231
INTRODUCTION:
The Field Bus mechanism for writing to the data bases of the field devices
will appear as if it involves a "write buffer". Most write commands will be
stored in the buffer by the communication logic processor. The DBWS will remove
messages from the write buffer and service the messages.
Certain "direct" write commands will be allowed to bypass the write buffer.
However, those commands will, in all but two cases, be writing to data base
parameters that do not require any restrictions. The handling of the exception
cases will be defined below. It is necessary that a data owner be able to
inhibit direct writes for short periods of time while it access its own data
base.
All Field Bus write operations will receive ONE response from the target
entity. That response may be an immediate indication of success from a direct
write, an immediate indication of a failure of a direct or indirect write, a
delayed indication of a failure of an indirect write, or a delayed indication of
success from an indirect write. The communication logic will generate an
immediate write rejection response when the buffer is full.
It is assumed that a data owner's operation will be scheduled such that data
base reads or writes by the owner will not collide with writes by the buffer
service logic.
Writes from on-logical-node peer blocks and even from the configured portions
of the owner block will be subject to the same rules as other indirect writes.
All of these writes will be processed by the indirect write logic and, at the
same time, NONE of these write messages will go through the buffer.
The field bus devices will function as if they use an internal data buffering
scheme to hold certain data during the actual execution of the block. At the end
of the block execution, the block will inhibit data record reads and writes (both
direct and by the DBWS) and copy the buffer to the real data record. Then it
will enable both the reads and the writes.
A portion of the data record of each node and block will be identified as the
static area. This area will have a revision number service for purposes of
assisting higher level devices in keeping back-up copies, and temporary mirror
copies, of the data retained in it. It is assumed that many field devices will
have physical provision for holding the static data base during short power
interruptions. It is further assumed that many higher level control systems will
have services to store a back-up copy of the static data base, to update the
back-up based on the revision number of the static data areas in the field
devices, and to "download" the static data when necessary. There are, in
general, two revision numbers per tagged object - a revision number for the
static data NOT including the Auto-format data, and a second one specifically for
the Auto-format data. Finally, two parameters are considered to be part of the
static data but are not under either revision number. They are the function
block's requested mode and the logical node parameter FAIL-SAFE. These two very
important parameters will be tracked directly by a higher level device that can
restore a field device's data base.
Many statements in this paper refer to "actual" and "requested" mode. The
reader is reminded that there are two versions of mode in the function blocks.
One, the requested, is in the static data area and can never have more than 1 bit
set and never bit 6 (IMan). The other, the actual mode, is generated by the
function block itself, is in dynamic memory, and is read-only.

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
--```,``-`-`,,`,,`,`,,`---
232
WRITE PROCESS SUMMARY:

Each data base item that can be read from, or written to, the data base of
the User Layer will have a 16 bit parameter number. The parameter number
assignments are arranged such that the high order three bits of the parameter
number indicate read and write restrictions that are enforced by the Application
Layer. Those three bits are never transmitted over Field Bus as part of a read
or write parameter name. The lower order 13 bits are transmitted and are the
bits that uniquely define a particular parameter within a TAG.
Figure 1, "Application Layer - Writing to Buffer", illustrates the logic

model for the passing of write messages to the User Layer by the Application
Layer write service.
The high three bits of the 16 bit range may indicate that a parameter is
"writeable" and "can be directly written". In that case, the Application Layer
can accept a direct write message and place the data from the message directly
into the User Layer's data area. The Application Layer will have confirmed that
the parameter is in fact supported by this TAG based on the list of supported
parameters that the User Layer supplied to the Application Layer when the
"Association" was made (see Attachment 1 to the paper "Application Layer Services
Interface").
The User Layer of the sender of the direct write command will receive an
immediate acknowledgement that the write command was executed or a notification
of the failure and its cause (if possible).
The Application Layer of a Field Device will normally place "indirect" write
commands into a write buffer after determining that the addressed parameter is
writeable and supported. The User Layer of the sender of the write command will
NOT receive an immediate acknowledgement that the write command was received if
it was delivered correctly. Later, when the command is taken out of the buffer
and executed, the original sender WILL receive a response that confirms that the
write command has been processed and indicates its disposition. Any time there
is a failure in the process, a failure response will be returned immediately (if
possible).
If the buffer is full and can not receive the indirect write command, the
write message will be rejected with an appropriate error message.
There are two important "twist's" in the above system. First, the parameter
numbers of the data values of Input Words and logical node variables (but not
Output Words) that are contained in this Standard, and may be used by higher
level devices to check configuration, always show the parameter as directly
writeable. However, that ability is dependent on the TYPE OF AGENT configured
for the Input Word or variable.
In fact, the default data base for the owner block will have the bits set to
show "not directly writeable". When the DBWS of the Field Device changes a
TO_TYPE, TO_TYPE1, or an agent's type, it will check the bits in the parameter
numbers of these parameters. If, at that time, the agent is of the type
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
"writeable" or "required writeable", the data owner block will allow the
parameter to be directly written. Otherwise, it will restrict it to being only
indirectly written. All communications with other blocks after that point in
time will have the correct parameter restrictions.
Note that no one can directly read the actual restriction. However, the
restriction is based on a simple logical combination of the above rule and
accessible configuration data.
Also note that, if the target block is subsequently placed in O/S mode,
associations with it will remain INTACT but its associations with other tagged
objects will be broken. It is only when its algorithm number is changed, its tag

233
name is changed, or an agent type is changed, that associations to it are broken.

When that happens, they can be remade immediately.
The second "twist" is only present in Field Devices that are designed in such
a way that it is possible for the Application Layer to operate and have access to
the User Layer's memory while the User Layer logic engine is inoperable, due to
either a hardware or software failure. If such independent operation is even
remotely possible, it is required that the Application Layer engine support a
service that is defined in a later section of this paper - not in the Standard
Application Layer. This service is modeled as being a "watch-dog timer".
All of the above, except the DBWS manipulation of agent value attributes, is
assumed to be provided by the "communication processor". All of the following is
assumed to be provided by the "User Layer logic engine". A detailed explanation
of this logic, along with logic diagrams, will be given in Attachment 2.
When a message is taken from the buffer to be processed, it is possible that

the algorithm in a node or function block has blocked writes to its data record -
the one being addressed by the message. In this case, the write message will be
restored in a User Layer queue and temporarily bypassed. Later write messages to
other nodes and blocks can be processed but no later write message to the TAG
with the blocked data record can be processed. When the algorithm unblocks the
data record, the DBWS will process the messages that were bypassed earlier; they
will be processed in the order in which they were originally received.
The sender of the write message may choose to indirectly write a parameter
that is directly writeable. When this is done, the message will be handled by
the buffer processor except no writes will be allowed to the "I/O Ports".
For the parameters that must be written indirectly, the high order bits of
the 13 bit field have, in turn, been used to define certain write restrictions
for use by the User Layer. The "system" is defined and explained in the paper
"Array of Basic Parameters". The DBWS will rely very heavily on the information
in those bits.
Several of the ranges provided in the system are defined as "parameter

specific rules apply". These are the only parameters that must be recognized
specifically by the DBWS.
For the remainder, the DBWS only requires the state of certain bits in the
parameter's number (along with block or node state data, of course) to determine
the write restrictions.
Some of the parameters need write services that are not provided by the
Application Layer and simple write restrictions provided in the parameter number
range definitions. A set of generic "complex write" services will be provided by
a particular range of parameter numbers and the Standard DBWS. Each individual
parameter number in the range provides a different complex write service. By
writing a data string to a selected "actor" parameter number, the writing entity
can request one of the services. The DBWS knows that the service is requested
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
because of the actor parameter number. The data string must, of course, be in
the format defined for that service. The DBWS will execute the complex service
using the data in the data string. If the service can be provided, the "write"
is considered successful. The services are detailed in Attachment 1.
WATCH-DOG TIMER:
If a Field device is designed in such a way that the Application Layer can
operate and respond to reads and/or direct writes while the User Layer logic
engine is stopped, due to either a hardware or software failure, then a service
must be provided that appears to be a watch-dog timer operated by the Application
Layer engine (i.e., continues to run while the User Layer is stopped). Again,
this is a requirement for Standard Field devices that have the above
characteristic in their design.

--```,``-`-`,,`,,`,`,,`---

234
The model of this service is based on a watch-dog timer that will "bark" when
the User Layer logic engine stops. The maximum allowable delay in the bark after
the User Layer stops will be two times the physical node variable "AX" (see Data
Owner Structure - Hardware", page 14).
When the watch-dog barks, it will provide two services that are required if
the watch-dog exists, and a third service that is a required part of an optional
service (i.e., if the option is supported, the watch-dog service becomes
required).
When the watch-dog barks, the watch-dog will:

- send the appropriate alert concerning the failure.
- modify certain bits in all status bytes in the User Layer's
memory.
- modify the "indirectly writeable" parameter bits for certain
optional memory locations.
Note that a higher level device must have made an association with the tagged
object before the logic engine died in order to be able to write after "death".
Physical Node Failure:

--```,``-`-`,,`,,`,`,,`---
There are a set of physical node diagnostic messages defined in the

"Alert" paper. The watch-dog will issue the appropriate alert to
notify the higher level systems of the failure.
Status Byte Modification:

The status byte modifications are needed to correctly interrupt
control applications when the User Layer stops. Specifically, bits 0
(No-Com), 2 (Not-from-Process), and 4 (failure) will be set, and bit 5
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
(failure handshake) will be reset, in every status byte in the memory.
If there are any control schemes that are using the values whose
bits are set, control will stop correctly because they will respond to
these status bit states.
When the User Layer logic engine restarts, these bits will clear
"naturally".
I/O Hardware Directly Writeable:

The third function of the watch-dog involves certain memory
locations called "I/O Ports". These locations are modeled as
representing actual "hardware" values and being independent of the logic
engine of the User Layer. Therefore, if the User Layer logic engine
fails, these locations will still represent the hardware values and may,
in fact, be writeable. The data is defined to be very low level data.
If the Field Device supports these memory locations, then it must

supply the functionality described here.
These memory variables are shown in this Standard as being readable

and writeable at any time. Higher level human interface devices should
assume the same. Their 13 low order bits have been assigned such that
they are all in one isolated range of parameter numbers. By their
nature, the variables should never be the target of any configured write
and would not normally be used by an operator.

235
The model of the operation of the field device assumes that these
variables are shown in the actual table passed to the Application Layer
as being read-only. When the watch-dog barks, it will reset the
read-only bits in the table for these parameters. When the logic engine
subsequently restarts, the bits must be returned to set by either the
watch-dog or the User Layer. Thus, while the logic engine is stopped,
the variables become writeable.
A direct write to one of these variables will thus be rejected if

the User Layer logic engine is running; if it is not, the command will
be executed by the Application Layer and a confirming response sent
immediately.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
REVISION NUMBER SERVICE:

The need for data base revision numbers was explained above. In general,
these numbers are assigned to three different types of data:
1) tagged object static data ex. Auto-format variables.
2) tagged object Auto-format variables ex. those related to hardware.
3) clipboard data.
The data in sets 1 and 2 tend to be independently adjustable and it is
anticipated that it will be "backed up" by a higher level device and will be
"downloaded" when needed. In those cases where the data can not be independently
adjusted, a plant's operating procedures will have to regulate access to them in
any event. For example, if one operator is adjusting the gain of a controller
and another is adjusting the reset time of the same controller, there is a bigger
problem than data base access can handle!
These characteristics are not true of the data in set 3 - it consists of full
pages of the clipboard and there may well be collisions between multiple devices
compressing and rewriting several pages. In addition, the data in the clipboard
will normally not be "backed up" by higher level devices. Therefore, the
revision number for the clipboards will be handled slightly different from the
others.
The design of the DBWS model does not allow any revision number service on
direct writes.
For the remainder of this paper and its attachments, the three classes will
be called "static", "auto-format", and "clipboard". For the remainder of this
particular section, the static data base and/or the Auto-format data base will be
referred to simply as "data base". There is no reference in this section to the
dynamic data base.
Static And Auto-Format Revision Numbers:

It is important that these revision numbers not be incremented for
every data base write but still be incremented at least once after a set
of changes because there could be an excessive amount of traffic on the
field bus during numerous increments of the revision number. However,
the field device can not rely on the device doing the data base changes
to always increment the data base revision number because the device
doing the writing may fail in the middle of the procedure.
To satisfy those needs, the "Data Base Write Service" will monitor
writes to the data base of each tagged object and implement specified
logic. In this logic, the term "index" will be used to denote the
following procedure:
Reset the low order bit of the revision number.
IF the change counter <> 0, then
Add 2 times the change counter to the revision number.
Issue an alert to report the revision number change.

--```,``-`-`,,`,,`,`,,`---

236
Reset the change counter.

Drop the associated data base change monitor
IF this is a function block, then
IF the "other" data base change counter = 0, then
Reset CHANGE_PENDING.
The logic for write monitoring is:

- An attempt to write to function block data base items that have
mode restrictions while the block does not have a proper mode
will be rejected.
- Most writes to a physical node's data base from outside of the

physical node, or to a logical node or function block data base
from outside of the logical node, will set up a monitor within
the DBWS on all writes to the tagged object's data base revision
number and, for a function block, all writes to the block's
--```,``-`-`,,`,,`,`,,`---
requested mode. The monitor will not be set up if the revision
number = 0. When it does transition to "on", the monitor will
set the least significant bit in its associated revision number.
- The monitor will count the number of parameters that are changed
in its associated data base by off-node writes (but not requested
mode nor FAIL-SAFE). (A write of a data set or multiple actions
in a complex write will be counted as multiple changes, not as
one. However, a value and its status byte(s) will be considered
one entity.).
- The Monitor will maintain an elapsed time clock with a fixed time
limit of 2**6 seconds.
- Any write to the data base from off the logical node (or off
the physical node for physical node data bases) will reset the
clock (but not the counter). The monitor will not be concerned
with writes from its own node.
- When the clock times out, the monitor will automatically

index the revision number and drop off. (Note *)
- Any write that indexes the block's data base revision number
will cause the monitor to drop off. (Note *)
- Any write that would change the mode to a priority lower than Man
(for analog blocks; Auto for discrete blocks) will cause the
revision number to be indexed and the monitor to drop off.
(Note *)
Note *: an "index" of the revision number at this point is the

same as "the old revision number + 2 times the counter" because
the definition of "index" negates the setting of the low order
bit required above.
In order to minimize the number of times that the monitor is

invoked and the revision number changed, the DBWS will inspect the value
being written to any parameter value and the source of the write. If
the value being written is identically the same as the old value, the
DBWS will NOT invoke the monitor. If the value being written is
identically the same as the old value AND from off logical node (off
physical node if a physical node data base), the logic WILL reset the
monitor's time to the full 2**6 seconds if it is already running.
Writes from function blocks internal to the logical node will not
affect the monitor nor its timer and will not increment the data base
revision number. This guards against excessive Field Bus traffic as
higher level devices attempt to keep their copies of the data bases up
to date. However, the user who decides to configure a function block to
change an item of data must consider the ramifications of his action on
restarts and data base downloads.

//^:^^#^~^^"~~:~"~$$"~$^

237
There is one situation that adds some complexity to the above.

When a device initializes its data base and sets its data base revision
counter to zero, it is important that a full and complete data base be
loaded before that device attempts any control. Therefore, in the above
discussion, the DBWS change monitor will not be started if the revision
number equals zero. Specifically in this case, some bus device would
have to explicitly write the revision number; all mode changes will be
rejected if any of the following are true:
1) the static revision number = 0
2) the function block has one or more Auto-Format variables under
the Auto-Format revision number and the number = 0.
3) the logical node containing the function block has a static
revision number of 0.
4) the logical node has one or more Auto-Format variables under
the Auto-Format revision number and the number = 0.
Any higher level device that writes an absolute revision number

will generate it according to the following rules:
- select bits BH through 1BH from the 48 bit value of the writer's
SOCIAL_TIME
- reset the low bit.
This value is specifically chosen to avoid a repeat of a revision number
within a short time period when there are several restarts and reloads
of a field device. If the bus device that writes the revision number
tries to write an odd number, it will be rejected.
One constraint in the DBWS logic is concerned with the source of

the write message. It is not possible, in general, to know the source
of the message on Field Bus but it is possible to know if the message
originated in the SAME logical node of the same field device. If it
did, then it is known that the message came from a control block, not
from a human interface. The DBWS will not allow mode writes from an on
logical node control block to change the mode of a block that has had a
protected parameter in its data record changed but has not yet had its
revision number incremented ("protected" means a data base parameter
that requires O/S or Man mode to change). This restriction will be
referred to in the attachment to this paper as "CHANGE_PENDING". This
test prevents a block that has an inconsistent data base from being put
on control. This violation will NOT generate an indication of a
--```,``-`-`,,`,,`,`,,`---
problem: the source block will be informed that the write was
SUCCESSFUL. When the revision number is indexed, the control action
will be allowed if it is still trying.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
This design is specifically set up to allow higher level devices to
recognize that they should not "upload" data for backup if the revision
number is 0 or odd. They can also recognize a block that is in the
process of having its data revised by the existence of an odd revision
number. The alert that is designed to inform higher level devices that
a revision number has changed will NOT be sent when the low order bit is
set: it WILL be sent when the revision number is "indexed".
Attachment 2 to this paper gives the detailed logic for the DBWS.
The details of the above general logic are included in that Attachment.
Clipboard Revision Numbers:

Each clipboard revision number will have an even parameter number
assigned to it; that parameter number will be used to read the value of
the revision number. The next higher odd value will be used by the
clipboard revision number system as a semaphore.
All writes to the clipboard data will have to use a particular

form of the "complex write services" defined below. Therefore, the
restrictions on writing to the two versions of the clipboard revision

238
numbers being defined here are quite simple: the even number parameter
(the revision number) is read-only. The odd parameter number (the
semaphore) can, but almost never should, be indirectly written.
Figure 2, "Clipboard Revision Number Logic", shows the details of

the logic for the three different complex writes that will be used to
interact with the revision number, the semaphore, and the clipboard
parameters.
Under normal conditions, the data base revision number will have
some particular value and the semaphore will be equal to zero. The
revision number is one entity: the low order bit is not a flag as it is
for the other types of revision numbers.
When a Field Bus Standard higher level device is ready to write to

the clipboard, it will use the following "voluntary" protocol.
1) it will confirm that the page to be written is in the supported

range of page numbers, it is not in the ROM portion, and the
semaphore = 0
2) it will use the complex write called "Obtain Clipboard
Semaphore". The argument for this service is simply the time
duration over which the claiming device wants exclusive access
to the clipboard.
If the semaphore is equal to zero, the complex write service

will write the value into the semaphore and return an indication
of a successful write. If the semaphore is not equal to zero,
or if a clipboard is not supported, the service will return a
"fail" message.
3) the data owner will, if the semaphore is greater than zero,
--```,``-`-`,,`,,`,`,,`---
reduce the value in the semaphore at the rate of 1 unit every

second. The value will not be reduced below zero.
4) if the higher level device finds a non-zero semaphore, it may be
because a higher level device claimed a semaphore, then died.
This situation can be corrected by simply waiting for the timer
to time out. This should be the course taken by higher level
programs if possible. Alternately, it can be corrected by
allowing the operator to exercise an option to use the normal
indirect write service to write the semaphore equal to zero.
However, this option should not normally be used and its use
should not be encouraged by the design of the human interface.
5) the higher level device that has the semaphore [it had a
successful write in step (2)] can use the special complex write
service specifically designed to write clipboard pages, the
"Write Clipboard Data and Increment Revision Number" service.
This service confirms that the semaphore is > 0, then writes the
data. This service takes the page number of the clipboard and
the data to be written as arguments.
6) when the higher level device is ready to cancel the semaphore,
it will send the "Release Clipboard Semaphore" complex write
command. This service will set the semaphore to 0. If the
semaphore was already 0, the write will fail.
The rest of this paper will refer only to the static and Auto-
format data bases and their revision numbers.
STATUS BYTE SERVICE:

The DBWS will determine if the write is to a variable that has a status byte
(any parameter in the "well known" range). If so, it will write the value (and
status) into ALL OF THE PARAMETER LOCATIONS using the following rules:
IF the parameter is in the range of parameters with status bytes, then

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
239
IF the parameter data type is 32 bit floating point, DO CASE

Analog (Table 1).
IF the parameter data type is 16 bit string, DO CASE Discrete
(Table 1).
ELSE error!
END IF
PHYSICAL AND LOGICAL NODE SERVICE:

Most of the parameters in the physical and logical node data bases are
restricted to indirect writes but do not have parameter specific restrictions.
The DBWS will enforce the objective of the NOWRITE parameter. It will
prevent most indirect writes to the entire logical node, including the logical
node's data record and the records of all function blocks in the logical node,
when bit 0 of the logical node's NOWRITE parameter is set.
The only parameters that can be written are:
1) NOWRITE itself (obeying its "parameter specific" rules)
2) the "value" and "value status byte" of a writeable agent
3) the value and status byte of any Cas, RCas, or ROut transfer location
4) any alarm acknowledgement word
5) any data base revision number
There will be a specific error response for a violation of a NOWRITE state. Since
the DBWS can not stop direct writes, this is the reason for requiring that no
Standard Field Bus devices use direct writes for writes originating from human
interface devices and user programmable (as opposed to user configurable)
domains.
All of the restrictions that follow from the parameter's number range must be
--```,``-`-`,,`,,`,`,,`---
implemented by the DBWS logic. In addition, the special requirements of the
"parameter specific" parameters must be built into the DBWS logic. This section
of this paper will highlight those parameters that require extensive or unusual
support. The"Array of Basic Parameters" paper contains the specific references
for the definitions of these restrictions. Attachment 1 to the paper "Human I/F
Considerations" details the service that must be provided to all Auto-format
variables.
The physical node's TAG name is a read only parameter. It can only be
changed by using the specific services of the Application Layer. The change will
be made with no User Layer restrictions; the Application Layer will break all
associations with, and cyclic reads of, the old tag name. The association to the
physical (and logical if the tag is collapsed) node's parameters can be remade
immediately.
The User Layer Standard only defines 0 one Physical Node TO_TYPE. Therefore,
there are currently no defined restrictions for a change to this parameter even
though it is in the class of parameters that have parameter-specific but not mode
related restrictions.
The logical node's TAG name can be changed by an indirect write with no
restrictions; it is under the revision number. A function block's TAG name can
be changed by an indirect write only if the block is in O/S mode; the TAG name is
under the logical node's revision number. The DBWS will be responsible for
notifying the Application Layer that all associations with, and cyclic services
involving, the old tag name should be stopped. Cyclic reads of the block can be
reestablished using the new tag name at any time. Note that an alert, code 3EH,
must be issued BEFORE the tag name is changed - see Tables 2 and 3 in the "Alert"
paper. This latter process is modeled using the REPORT_CHG integer described on
page 8 of the "Alert" paper.
The DBWS handling of the logical node parameters used to schedule the node is
complex. The parameters in question are:
1) TO_TYPE
2) User set value for the cycle time exponent (CX) - applicable to

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
240
the cycle-phase/cycle-phase standard and the timed

standard/cyclic standard/cyclic node types.
3) User set number of blocks to execute (CB) - applicable to the
timed standard/cyclic standard/cyclic node type.
The User Layer Standard defines several Logical Node TO_TYPE's. The
parameter is indirectly but not directly writeable and is under a data base
revision number. The data owner must be aware of the types of logical nodes
supported. The TO_TYPE can be freely changed to a supported type of logical node
if one of the following is true:
1) all function blocks in the logical node are in O/S mode.
2) CX is not supported in the logical node.
3) CX is supported and LN_OOS is TRUE
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
4) CB is supported and is equal to 0.

When the TO_TYPE is changed, the DBWS will be responsible for notifying the
Application Layer that all associations with the node, and all cyclic reads by
and of the node, should be stopped. The associations can be immediately remade.
--```,``-`-`,,`,,`,`,,`---
The following statements define the required handling for the parameters CX and
CB:
1) a write to one of these parameters when the node type is one that
does not support the parameter will be rejected.
2) a write to CB when the node type is cycle/phase will be rejected - it
is read only in that case.
3) a write that results in an actual change to either of CX or CB in the
logical node static data base will cause the field device to
reschedule itself.
4) the DBWS will serve as the monitor of such changes and signal the
logical node to complete its current cycle (with the old value of CX
or CB in its data base), then execute the rescheduling procedure.
The logical node may have up to 5 "logical node variables". When either the
agent type or the pointer of an active agent is changed, the DBWS will be
responsible for notifying the Application Layer that all associations made by the
node, and all cyclic reads by the logical node variable that was changed, should
be stopped and the value marked "Bad", "Not-from-Process", and "No-path-to-
process". The associations can be immediately remade. The only exception to
this rule occurs when the agent type is changed between "writeable" and "required
writeable" and/or just the action upon No-Com is changed. In that case,
associations do not have to be broken and the value should not be set "Bad", etc.
If any of the parameters ASK, BASK, or the alert priority string (all free
access static data parameters) are modified, alert code 3EH must be issued. The
process to support this action is modeled using the REPORT_CHG integer described
on page 8 of the "Alert" paper.
FUNCTION BLOCK SERVICE - HIGHLIGHTS:

Most of the parameters in the function block data bases are restricted to
indirect writes but do not have parameter specific restrictions.
The design of the Alert system (see the paper by that name) provides for
several alerts under the code number 3EH that report changes to the data base.
The DBWS must monitor those changes and generate the alert report.
As a service for all of the data record in a function block, the DBWS
will severely restrict write access to a block while either of the following
conditions exist:
1) the block's requested mode is LO.
2) the block's actual mode is in any form of LO mode.
The only block information that will be writeable during that time is:
1) the block's requested mode.
2) the block's data base revision numbers.
3) the values of writeable input agents.

241
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
4) the status bits of the cascade transfer locations (full writes of
value and status will only change the status but the count-out
counters will be reset by the write and the writer will get a normal
response).
5) any alarm acknowledge word.
Likewise, the DBWS will severely restrict writes to the data record of an
output bit in a Discrete Register block or a Discrete Output block when:
1) the bit has OUTLO set.
2) the bit has a keylock set.
The only bit information that will be writeable during that time is:
1) the bit's OUTLO value.
2) the alarm acknowledge word.
All of the restrictions that follow from the parameter's number range must be
implemented by the DBWS logic. In addition, the special requirements of the
"parameter specific" parameters must be built into the DBWS logic. This section
of this paper will highlight those parameters that require extensive or unusual
support. The two papers that give the arrays of parameters contain the specific
references for the definitions of these restrictions.
The User Layer Standard defines a number of function block TO_TYPE's and
provides for TO_TYPE1. Both parameters are indirectly but not directly writeable
and are under a data base revision number. These parameters can only be changed
if the function block is in O/S mode. The DBWS must be aware of the types of
function blocks supported by the logical node and reject any writes of an
unsupported type.
When TO_TYPE or TO_TYPE1 is actually changed, the DBWS will be responsible

for notifying the Application Layer that all associations with the block, and all
cyclic services involving the block, should be stopped. The DBWS will also be
responsible for loading the default data base for the new TO_TYPE into the data
record and for any other actions necessary to allow communications with the new
data base. Associations with, and cyclic reads of, the block can be
reestablished at any time.
When the function block scheduling parameters BX or PN are changed (present

only in a cycle/phase or cycle/phase standard logical node), the DBWS will set up
the rescheduling of the block.
The function block may have up to 5 active I/O agents. The function block
must be in O/S mode in order to change either the agent type or the pointer of an
active agent. When that is done, the DBWS will be responsible for notifying the
--```,``-`-`,,`,,`,`,,`---
Application Layer that all associations with the block, and all cyclic services
involving the block should be stopped. The DBWS will also place any necessary
default data into the agent's parameters. Associations with, and cyclic reads of
the block can be reestablished at any time. The only exception to this rule
occurs when the agent type is changed between "writeable" and "required
writeable", between "on-block" and "on-block counted" and/or just the action upon
No-Com is changed. In that case, associations do not have to be broken and the
value should not be set "Bad", etc.
The DBWS will enforce some of the restrictions on writing the requested mode
(the item numbers will be referred to in Attachment 2, Figure 4):
S1) One and only 1 bit can be set at one time.
S2) Bit 6 (IMan) can never be set.
S3) Can not set a mode bit that corresponds to a reset bit in the mode
permitted byte.
S4) the following limit on setting O/S mode:
IF the block being written to is an Output block AND
IF the block is keylocked OR all output bits are keylocked, THEN
The requested mode can be O/S only if the actual mode is O/S
S5) mode writes from an on logical node control block can not change the
mode of a block that has had a protected parameter in its data
record changed but has not yet had its revision number incremented.

242
The first two constraints will have a common but dedicated error response code;
the third and fourth violations will have their own dedicated response error
codes.
The DBWS will block any write to the parameter ACQUIROR that attempts to set
a non-zero value when the current value is non-zero. This violation will have
its own dedicated error response code. In addition, whenever ACQUIROR is
changed, the DBWS will make the appropriate changes in the mode attribute byte of
the same block. If the high bit of the new value of ACQUIROR is set, the high
bit of the attribute byte will be set, ELSE it will be reset. If any of the low
15 bits of ACQUIROR are set, bit 6 of the attribute byte will be set, ELSE it
will be reset (see the paper "Modes", page 8) (these rules will be referred to as
"Rule S6" in Figure 6, Attachment 2).
One additional rule for static data base parameters is required:

S7) Any write to a "Setpoint Limit" of an analog block must be setting
a value within the "Control Range" if the control range function is
supported in the block. If both values are written in one write
message, this rule applies to the result of both writes, NOT to the
intermediate transient state between the two changes.
If any of the parameters ASK, BASK, or the alert priority string (all free
access static data parameters) are modified, alert code 3EH must be issued. The
process to support this action is modeled using the REPORT_CHG integer described
on page 8 of the "Alert" paper.
FUNCTION BLOCK DYNAMIC DATA BASE:

There are also a set of DBWS services that are required by the dynamic data
base (the item numbers will be referred to in Attachment 2, Figures 4 and 5 ):
D1) No writes to the block's "Output" unless:
a) the actual mode word has its O/S or Man mode bit set
AND
b) neither the actual mode's IMan nor LO bits are set (in any
combination of bits).
When such a write is executed, the DBWS will:
c) set the algorithm's "initialization counter" = 1 if it
--```,``-`-`,,`,,`,`,,`---
currently equals 0.
D2) No writes to the block's "Setpoint" unless:
a) the Auto mode bit is the lowest priority bit set in the actual
mode AND PV tracking is not active AND the algorithm is not
initializing the Setpoint.
OR
b) the Auto mode bit is set in the requested mode and there are no
mode bits of priority higher than Auto set in the actual mode.
D3) Any write to the "Setpoint" or "Target_SP" of an analog block must
be setting a value within the Setpoint Limits if the Setpoint Limit
function is supported in the block. If both values are written in
one write message, this rule applies to the result of both writes,
NOT to the intermediate transient state between the two changes.
D4) The Setpoint Ramp logical (RAMP_FLAG) can not be set while:
a) there are any mode bits other than Auto set in either the
actual or requested modes.
b) the Input #1 of the block can not be "bad".
D5) The value being written into the Setpoint or the cascade transfer
locations of a Standard discrete block that has a 3-bit Setpoint
must have 1, and only 1, of the low order 3 bits set.
D6) Enforce the read-only status of the agent data area except it will
allow writing to the value and value status parameters of an input
agent that is of the type "writeable" or any agent's value in O/S
mode.
D7) The service will perform a function that is critical to the success
of the cascade scheme. It will, as part of its monitoring of the
writing into the block Setpoint and Output, mirror any write into
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@

243
the Setpoint also into the Cas and RCas transfer values. Similarly,
it will mirror any external write to the Output into the ROut value.
In all cases, it will set TRANSFER_VOID. See page 11 of the paper
"Function Block Structure" for the details of this operation.
D8) Reset the count-out-gate on the Cas, RCas, and ROut transfer
locations. It will reset the gate every time it receives a write to
the location. The individual blocks can then increment the gate
counter at each execution and drop the mode if the maximum count is
exceeded.
D9) A write into the value of the Cas, RCas, and ROut transfer locations
will be blocked when the status bits of the location indicate that
the value is "doubly wound up". The write of the status byte will
proceed but only bits 2, 3, and 5 will be allowed to be altered.
However, the count-out-gate will be reset as normal and a normal
response will be returned to the writer.
D10) Reset the count-out-gate on any Required Writeable agent values. It
will reset the counter every time it receives a write to the
location. The individual blocks can then increment the gate counter
at each execution and set a No-Com status if the maximum count is
exceeded.
D11) Add the default status byte to any write (except the 3 cascade
transfer locations) that does not have a status byte but is directed
to a data base variable that has a status byte.
D12) Trap the write of any status byte that is marked No-Com and reset
the No-Com status bit and set the Bad status bit.
D13) Convert a floating point + or - infinity to NaN. Also, set a
floating point -0 to +0.
D14) Detect the write of a value of NaN to any data base variable that
has a status byte and force the status byte to "Bad",
"Not-from-Process", and "No-path-to-Process".
The first 6 rules will have individual response error codes.
DETAILS OF LOGIC FOR WRITING:

The detailed logic for the DBWS is given in Attachment 2 to this paper and in
its six logic drawings.
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
244
Attach. 1 Complex Write
COMPLEX WRITE SERVICE

This Attachment documents the complex write services that will be provided by
--```,``-`-`,,`,,`,`,,`---
the DBWS. These writes will appear to be indirect writes to parameters and be
placed in the DBWS buffer. The DBWS will recognize the write and execute the
service that is associated with the parameter number, using the write message as
the arguments.
INTRODUCTION
DEFINITIONS AND BASIS
WRITE STATIC DATA
0) Write Data With Temporary O/S
Mode. 1) Write Data With
Temporary Man Mode. 2) Write Data
and Index Revision Number.
3) Mask Write Data With Temporary O/S Mode.
4) Mask Write Data With Temporary Man Mode.
5) Mask Write Data and Index Revision Number.
6) Index Revision Number.
7) Write Bit.
WRITE CLIPBOARD DATA
8) Obtain Clipboard Semaphore.
9) Write Clipboard Data and Increment
Revision Number. AH) Release Clipboard
Semaphore.
INITIALIZE COUNT_TIME
BH) Initialize COUNT_TIME.
GENERIC CONDITIONAL WRITES
CH) Conditional Write.
DH) Complex Conditional Write.
RESERVED AND AVAILABLE FOR MANUFACTURERS
Figure 1 -Generic Conditional Writes
Figure 2 - Generic Conditional Writes (cont.)
INTRODUCTION:
Each of these services is assigned an "actor" data base parameter number.
The numbers are in a special range of parameter numbers easily recognized by the
DBWS.
When an indirect write message is sent to one of these actor parameters, the
write is placed in the DBWS buffer just as for an ordinary indirect write. The
removal of the message from the buffer will be handled exactly as any other
indirect write: the addressed TO must not have writes to its data base inhibited.
After removing the message from the buffer, the DBWS will recognize the
parameter as being an actor and execute the service that is associated with the
parameter number, using as arguments the data that was passed as the "data to be
written" to the actor parameter.
All of the actor parameters will have their parameter number bits 15-6 =
1101000000B. The low order 64 values will be defined here.
SP-50 User Layer Technical Report Database Write Service At. 1 Complex Write Service

245
DEFINITIONS AND BASIS:

There are two terms that are used in this document that require careful
definition. One is the term "index the revision number". This term is defined
in the main paper. It is a series of operations that are much more than the term
might imply.
The term "mask" is used extensively in this document. It is a string of bits

that are to be matched up with the corresponding bits in the data to be written.
If the mask bit is set, the corresponding data bit is written. If the mask bit
is reset, the corresponding data bit in the old value being written over is left
unaltered.
All of these write operations are intended to be "atomic" operations -

meaning all at the same time and all or nothing is done. Therefore, the complex
write service must complete the checking of the entire message before executing
any of it. It is not permissible to execute part of the message, then fail on a
step and give an error message.
WRITE STATIC DATA:

Most of the data in the static data base of a TO is under one of two revision
numbers. Those numbers must be incremented to show the change in their static
data base. In addition, writes to many of the parameters in the static data base
are under one of two mode restrictions: the function block may have to be in O/S
mode or it may have to be in a mode whose priority is greater than Auto but not
LO. The theoretical sequence of doing a write to one of the parameters under
a mode restriction would be:
- set the required requested mode.
- write the value.
- increment the associated Data Base Revision Number.
- restore the mode.
Seven of the complex write actors are designed to make these steps more
efficient. The first two allow the entire operation to be done with one write
while the third would be used if multiple parameters were to be written to a mode
controlled parameter or it can be used for the entire write operation on a non-
mode controlled static data base parameter. The next 3 repeat the first 3 but
provide for a write mask. The seventh actor provides a simple method of indexing
the Data Base Revision number.
The last actor in this set provides a simple bit manipulation service.
0) Write Data With Temporary O/S Mode:

This service will write the value of the parameter to the
data base and set an indicator that will force the function
block to act as if it transitioned from O/S to the restored
mode at its next execution (i.e., FORCE_INIT = 3). Then it
will index the appropriate static data base revision number.
(See the main paper for the definition of "index" and the
paper "Function Block Structure", page 23 for FORCE_INIT).
Note that the sequence of the logic for a single complete

execution of a function block must be designed to operate
correctly, either as if no change was made or as if the
block was in O/S mode, no matter when this command is
executed during the time that the block allows indirect
writes to its data base.
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
246
The calling attributes are:

bytes 1 and 0 - the number of the parameter to write.
bytes 2+ - the data in the same format as used in a
normal indirect write command.
The write message will fail if:

1) the specified parameter is not supported in this
TO. Note that the DBWS will have to perform
this check since the Application Layer checked
for support of the actor parameter number, not
the parameter identified within the message.
2) the parameter is not indirectly writeable.
3) the write is to a requested mode or data base
revision number. 4) any of the write restrictions
specified in the normal indirect
write service are not met except, of course, the
O/S mode restriction.
5) the targeted block, or any discrete output bit in the targeted
block, is in LO mode.
6) the associated static data base revision number is zero.
7) the message's arguments are unacceptable.
1) Write Data With Temporary Man Mode:

This service is exactly the same as service (1) except that
that indicator will show that the block transitioned from
Man mode instead of O/S mode (i.e., FORCE_INIT = 2). This
service will fail if O/S mode
was required to change the parameter.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
2) Write Data and Index Revision Number:

This service will appear to be the same as a simple indirect write
except it will also index the revision number.
It is anticipated that this actor will frequently be used

to write to the requested mode.

bytes 1 and 0 - the number of the parameter to write.
bytes 2+ - the data in the same format as used
in a normal indirect write command.
The write message will fail if:

1) the specified parameter is not supported in this
TO. Note that the DBWS will have to perform this
check since the Application Layer checked for
support of the actor parameter number, not the
parameter identified within the message.
2) the parameter is not indirectly writeable.
3) the write is targeted to a data base revision number.
4) any of the write restrictions specified in the
normal indirect write service are not met.
5) the associated static data base revision number is zero.
6) the message's arguments are unacceptable.
3) Mask Write Data With Temporary O/S Mode.

--```,``-`-`,,`,,`,`,,`---

247
4) Mask Write Data With Temporary Man Mode.
5) Mask Write Data and Index Revision Number.

These three actors repeat actors 0-2 except they provide
for a masking service during the writing of the value. In
each case, the data in bytes 2+ is in the same format as
used in a normal masked indirect write command. NONE of
these three actors can be used to write to a requested mode
or to a data base revision number.
6) Index Revision Number:

A Human Interface may have no way of knowing, when it writes
a parameter to the static data base, if its operator will
enter another piece of data or if the changes are done. At
some subsequent time, it needs a service to index the
revision number.
This service will simply index the revision number (causing the
data
base change monitor to drop off if it was running).
The calling attribute is:

byte 0 = 00000000B = static data base revision number
byte 0 = 00000001B = auto-format data base revision number
This write will fail if the calling attribute is missing,

the change counter = 0 or if the revision number selected is
equal to zero.
7) Write Bit:
This service will allow the value of a selected bit in a bit string,
integer, or status byte to be manipulated.
If the service is used on a parameter with no status, bits 2 and 3 in
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
byte 2 defined below must be present and reset.
If the service is used on a bit in a bit string with individual status

bytes, the status byte and its mask are optional. If
included, the status of the targeted bit will be [mask]
written, then the condensed status byte for the whole string
will be updated. If it is not included, the default status
will be written for the targeted bit, then the condensed
status byte for the whole string will be updated.
If the service is used to operate directly on the status

byte (i.e., bit 3 in byte 2 defined below is set), then
IF the parameter has only one status byte, then
the bit selector is relative to the low order bit
of the status byte
IF the parameter has multiple status bytes, then
the bit selector is relative to the low order bit
of the status byte for the low order value
bit. A bit selector of 1 would be the second
bit in the status byte for the low order bit;
a bit selector of 8 would be the low order
bit in the status byte for the second value
bit, etc.
The actor will recalculate the condensed
status byte when finished.
--```,``-`-`,,`,,`,`,,`---

248

bytes 1 and 0 - the number of the parameter to
manipulate. byte 2 -
bits 1&0
00B = reset bit. 10B = invert existing bit value.
01B = set bit. 11B = do not alter existing bit.
bit 2 = set if status byte and its mask included.
bit 3 = set if bit manipulation to
operate directly on a status bit
(bit 2 must be reset).
bits 4&5 = reserved
bits FH-6 = bit select: 0 = low order bit
(can not be larger
than 960).
byte 3 - status byte data (required if bit 2 in byte 2 = set,
else must not be present).
byte 4 - mask for status byte. (required if bit 2
in byte 2 = set, else must not be
present).
This write will fail if:

1) the specified parameter is not supported by this TAG
--```,``-`-`,,`,,`,`,,`---
2) it is targeted to a requested mode or to a data base

revision number.
3) bit 2 and bit 3 in byte 2 both set.
4) bit 3 is reset and:
the parameter is of data type float, signed integer,
or visible string.
5) bit 3 is set and:
the parameter does not have a status byte or the bit
selector is larger than the number of status bits.
6) status information is included but the specified
parameter does not have a status byte.
7) the message is too short - it does not include the
indicated status and mask bytes.
8) if the bit selector is larger than the total length of the
targeted parameter (bit 3 reset) or larger than the
total number of status bits (bit 3 set).
simple indirect write service are not met.
WRITE CLIPBOARD DATA:0

The procedure for writing to the clipboard in a physical
node is different from the procedure for the static and auto-
format data. A
semaphore must be obtained, the write MUST be done using a
complex write service, and the revision number will be
incremented for every write. The following three services
are specifically designed to interact with a clipboard. Any
Field Device that does not support a clipboard need not
implement these three services.
8) Obtain Clipboard Semaphore:

This service will test the clipboard semaphore for a non-
zero value. If it is zero, it will write the time attribute
into the value of the semaphore. It will not affect the
revision number.
byte 0 = the length of time, in seconds, for which the source
entity will own the semaphore (unsigned 8 bit integer).
The DBWS will have to check to be sure that the clipboard is

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
249
supported by the addressed TAG and the semaphore is zero.

If either test fails, or if byte 0 is missing or zero, the
write will fail.
9) Write Clipboard Data and Increment Revision Number:

This actor will IGNORE the fact that all clipboard pages are marked as
"read-only".

zero value, write one page of the clipboard and index the
clipboard revision number. If the message is less than the
total length of the clipboard page, it will fill the
remainder of the page with spaces [character 32 (base10)].

byte 0 = clipboard page index as an unsigned 8 bit integer.
bytes 1+ = the data in the same format as used in a
--```,``-`-`,,`,,`,`,,`---
normal write command.
Since the Application Layer will include the length of

the message in the buffer, there is no need for a calling
attribute giving the data length.
The actor will provide two extra services for the clipboard:
- if the clipboard page index > CUR_CLIP_P, then
CUR_CLIP_P = index
- if the data is all spaces [character 32 (base 10)]
AND the clipboard index = CUR_CLIP_P AND
CUR_CLIP_P > 0, then decrement CUR_CLIP_P by 1.
(Refer to page 14 of the "Human Interface Considerations" paper
for
details on CUR_CLIP_P.)
The DBWS will have to check to be sure that the clipboard is supported
by the addressed TAG and that the index is:
+ not in the ROM based section of the clipboard.
+ equal to, or less than, the number of pages in the clipboard.
If either test fails, or if the semaphore = 0, the write will
fail.
AH) Release Clipboard Semaphore:

zero value. If it is non-zero, it will reset it to zero.
It will not affect the revision number.
There are no calling attributes.
The DBWS will have to check to be sure that the clipboard is

supported by the addressed TAG and the semaphore is non-
zero. If either test fails, the write will fail.
INITIALIZE COUNT_TIME:
There is one service that is needed for the COUNT_TIME variables in the
physical node: they have to be initialized with NODE_TIME and all of their
associated counters have to be reset.
BH) Initialize COUNT_TIME:

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
250
This service will write the current NODE_TIME into either

COUNT_TIME0 or COUNT_TIME1 and reset the communication
counters that are associated with it (but NOT the error
rate).
byte 0 = 00000000B = initialize COUNT_TIME0
00000001B = initialize COUNT_TIME1
The DBWS will have to check to be sure that COUNT_TIME1 is supported
if it is selected and report a failed write if it is not.
GENERIC CONDITIONAL WRITES:

There are many situations in which a higher level device
must execute an "atomic conditional write". This refers to
a situation in which an operation more complex than a simple
write must be done in such a way that there is no time
window between the steps of the operation. For example, a
higher level device may need to command an operation such as
"if the revision number = 0, then write 100 into the value
of TAG.PARAMETER". It is not possible to check the
parameter number in one operation, then write the value in
another operation because some other device might change the
revision number in the mean time.
The atomic conditional writes will take a number of different forms,

with a variety of complexities. The service has been
designed generically, then divided into two services -
normal and complex. The normal service will be defined here
and the complex form will be described separately and next.
CH) Conditional Write:

The normal conditional write service will allow the source
of the write to use a relatively simple coding system to
transmit to the DBWS some simple instructions to be
followed. There will be many restrictions in this service:
most of those restrictions are removed in the later service
that is much less efficient. The general structures of the
function are:
Meaning (Op. Code ) Meaning - cont.

Write value [through mask] to(Param. Value).
Boolean OR value [through mask] to(Param. Value).
Boolean XOR value [through mask] to(Param. Value).
Boolean AND value [through mask] to(Param. Value).
IF (Param.Value) <x then write value [through mask] to it.
IF (Param.Value) =x then write value [through mask] to it.
IF (Param.Value) <>x then write value [through mask] to it.
IF (Param.Value) >x then write value [through mask] to it.
IF (Param.Value) low bit = x then write value [through mask] to it.
Add value to (Param. Value).
Subtract value from(Param. Value).
Sub.&clamp @0 value from(Param. Value).
Increment (Param.Value).
Inc.&skip 0 (Param. Value).
Decrement (Param. Value).
Dec.&skip 0 (Param. Value).
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
251
An inspection of these commands shows that:

- they all refer to one and only one (Parameter Value).
- most refer to a "value"
- they all have one and only one operation code.
- many of them have an optional masking capability
- many of them refer to a variable "x"
The design of this service limits "x" to a value of 0 or 1.
This service assumes that the "value" has already been converted to the correct
data type as implied by the operation code. For example, if the operation code
is the simple write command and the parameter happens to be a floating point
number, the service will ASSUME that "value" is a floating point number; it will
not be able to float an integer "value".
This service will not assume that the "value" is the same length as the
parameter. That is supplied separately so that:
- selected portions of bit strings can be written
- the service logic does not have to determine the data type of
the parameter value in order to parse the command.
This service will not assume that the mask is the same length as "value". That is
supplied separately so that selected portions of "value" can be masked. The
format of the "data" directed to this actor will be:
Bytes 1&0 = CONTROL WORD (format defined below)
Required.
Bytes 3&2 = PARAMETER number of the parameter that is to be
altered (standard parameter number and format).
Required.
Note that the total write message was addressed to a

actor parameter, NOT to the parameter that was to be
--```,``-`-`,,`,,`,`,,`---
altered. The service must check to ensure that the

specified parameter is a supported and indirectly
writeable parameter.
All restrictions imposed by the normal indirect

writing rules must be met.
Bytes x-4 = VALUE (presence, length and type as defined by
CONTROL WORD).
Bytes y-(x+1) = MASK (presence, length and type as defined by
CONTROL WORD).
Byte (y+1)+ = another CONTROL WORD
OR
end of message data.
Format of CONTROL WORD:

The "CONTROL WORD" for the normal conditional write actor is
illustrated in the top half of Figure 1.
Bits 3-0 = operation

0 = Write
service will check to be sure that the mask, if
present, either completely passes or completely
blocks the floating point or signed integer value if
present.
If the addressed parameter has status information,

and the data to be written is only as long as the
value portion of the parameter, the default status
byte will be entered in the status.
The condensed status byte, if present, will be

recalculated.
1 = Boolean OR
2 = Boolean XOR
3 = Boolean AND

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
252
service will check to be sure that these

three operations do not operate on a visible
string, signed integer, nor a floating point
parameter value.
If the addressed parameter has status information,

and the data to be written is only as long as the
value portion of the parameter, the existing status
byte will be unchanged. If the status byte is
changed, the condensed status byte, if present, will
be recalculated.
4 = low bit = x
"x" will be defined as either 0 or 1.
The service will not allow this operator if
PARAMETER's value is a visible string, floating
point, signed integer, nor discrete value.
If PARAMETER's value is a bit string or unsigned

integer, the service will perform as written.
If the addressed parameter has status information

but no status information is provided in the command,
the default status byte will be used and the
condensed status byte, if present, will be
recalculated.
5 = Add
6 = Subtract
7 = Subtract & Clamp @0
8 = Increment
9 = Increment & Skip 0
AH = Decrement
BH = Decrement & Skip 0
The service will check to be sure that these seven
operators are not invoked on a visible string or
discrete. Only operators 5-7 can be invoked on a
floating point parameter value.
The "Subtract & Clamp @0" service will perform the

following logic:
IF "value" >= PARAMETER's value, than
set PARAMETER's value = 0.
ELSE
PARAMETER's value = PARAMETER's value "value"
The "Increment & Skip 0" ("Decrement & Skip 0")

services will perform the following logic:
--```,``-`-`,,`,,`,`,,`---
Increment (decrement) PARAMETER's value by 1. IF
PARAMETER's value = 0, then
Increment (decrement) PARAMETER's
value by 1.
If these services are used on a bit string that has

status information, the status information will not be
altered.
CH = <x
DH = =x
EH = <>x
FH = >x
"x" will be defined as either 0 or 1.
If PARAMETER's value is a signed or unsigned integer

or a floating point value, the four operators will
perform as written.
These two values of x are defined to be without an
implied data type. For example, if the parameter is

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
253
a floating point variable, then the service will use

x as a floating point number with a value of 0 or 1
as indicated. (Note that a floating point -0 is
defined by this Standard to be identically equal to
+0 but the floating point representations are
different. For purposes of this comparison, they
ARE identically equal; the actor must test for both
representations.)
If PARAMETER's value is a bit string, the four

operators will compare it to an equivalent bit string
with "x" in ALL bit positions.
If PARAMETER's value is a visible string, x=1 will

not be allowed. If x=0, the service will only allow
the equal and not equal operators and will compare
the value to an equivalent visible string with
"space" (char. 3210 ) in ALL character positions.
If PARAMETER's value is a discrete, the service

will only allow the equal and not equal
operators and will perform them as
written.
Bit 4 = x
Bit 5 = 0 if low order bit of mask = low order bit of value
= 1 if high order bit of mask = high order
bit of value Bits 6-8 = mask length in bytes.
= 0 = no mask
1 = length = 1 byte
2 = length = 2 bytes
7 = same as value
Bits FH-9 = value length in bytes [(value can not be larger
than (116 - length of mask)].
1) the specified parameter is not supported by this TAG
2) the write is targeted to a revision number or a
requested mode.
3) the parameter is a data type that
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
is not supported by the selected operation.
4) the message is too short - it does not include the
indicated status and mask bytes.
simple indirect write service are not met.
DH) Complex Conditional Write:

This service will allow the source of the write to
completely control the write process that occurs in the
target's DBWS but at the cost of efficiency and complexity.
This service provides a set of commands for a write operation that is a

series of steps. The steps are either "test" or "action" steps. The two kinds
of steps can be mixed, in any order, in one write message. The full set of steps
is to be executed as an atomic operation. Either the entire set is successful or
none of it is executed - a sequence CAN NOT partially fail. A "CONTROL BYTE" is
used to structure each step. The order of the bytes in the write message will be
(low order bytes first):
--```,``-`-`,,`,,`,`,,`---

254
Step 1: CONTROL BYTE

data for step 0
Step 2: CONTROL BYTE
data for step 1
etc.
(end of message)
The CONTROL BYTE is outlined in the bottom half of Figure 1. It always has the
"operation type" indicator in its low order bit - "test" if reset, "action" if
set. Each step can define the TAG.PARAMETER that it is to operate on AND TO
LEAVE AS THE DEFAULT FOR THE NEXT STEP. Bit 6 is set if a new parameter number
--```,``-`-`,,`,,`,`,,`---
is to be used; bit 7 is set if a new TAG is to be used. The CONTROL BYTE for
step 0 must have bit 6 set but it may default to the same TAG as used to address
the actor. It is required that all TAG's be in the addressed physical node.
It should be noted that the write message is removed from the DBWS buffer and
executed according to the ability to write to the data base of the TAG to which
the message was originally addressed (based on both indirect write inhibit and
NO_WRITE. Frequently, the first few steps of the message will be tests, not
writes. Therefore, if a message is interacting with several TAG's, the message
SHOULD NOT necessarily be addressed to the TAG that is addressed by the first
step. Rather, it should be addressed to the TAG that is addressed by the first
ACTION step. In that case, step 0 will have to identify its own TAG.
A "test" step will imply the following logic:

IF (NOT TEST), then
Fail write message
Send response message indicating cause of failure.
Break
ELSE
Continue
The details of the CONTROL BYTE for a "test" step are given in the top of Figure
2. Notice that bit 0 is always 0. "Test" can be any one of the following types:
0 = no test (the whole step is null but it may have value and
mask data bytes).
1 = the parameter is < x.
2 = the parameter is = x.
3 = the parameter is <> x.
4 = the parameter is > x.
5 = the low bit of the parameter is = x.
The value of x can be defined right in the CONTROL BYTE if it is equal to 0 or 1.
These two indicators are defined to be without an implied data type. For
example, if the parameter is a floating point variable, then the service will use
x as a floating point number with a value of 0 or 1 as indicated. (Note that a
floating point -0 is defined by this Standard to be identically equal to +0 but
the floating point representations are different. For purposes of this
comparison, they ARE identically equal; the actor must test for both
representations.)
Alternately, x can be defined by two or more bytes of "step data": the first
byte gives the length of the value of x (in bytes), and the second and succeeding
bytes gives the value itself, always in the correct data type. An additional 2
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
or more bytes can give a mask length and data. Bits 4 and 5 in the CONTROL BYTE
select between these alternatives as is shown in Figure 2. The general structure
of the bytes that constitute a "test" step are:
Byte 0 = CONTROL BYTE
Bytes 2&1 = parameter number of addressed parameter (if bit 6 in
CONTROL BYTE = 1)
Next 2 Bytes = internal ID of the addressed TAG (if bit 7 in
CONTROL BYTE = 1)
Next Byte = length of value (in bytes) (present if, and only if,
bit 5 in CONTROL BYTE is set)
Next l bytes = value (present if, and only if, bit 5 in CONTROL
BYTE is set AND if the length byte <> 0). If present,
must be exactly as long as specified in the length

255
byte.
Next Byte = length of mask (in bytes) (present if, and only if,
bits 6&5 in CONTROL BYTE = 11B).
Next l bytes = mask (present if, and only if, bits 6&5 in CONTROL
BYTE = 11B AND if the mask length byte <> 0). If
present, must be exactly as long as specified in the
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
length byte.
Next Byte = another CONTROL BYTE
OR
An "action" step will imply the following logic:

ACTION
IF (ACTION failed), then
Fail write message
Send response message indicating cause of failure.
Break
ELSE
Continue
The details of the CONTROL BYTE for an "action" step are given in the bottom of
Figure 2. Notice that bit 0 is always 1. "Action" can be any one of twelve
subtypes. They are defined exactly the same as the first twelve types in the
normal conditional write defined above.
The argument for the action is defined by two or more bytes of "step data": the
first byte gives the length of the value (in bytes), and the second and
succeeding bytes gives the value itself, always in the correct data type. In an
action step, the length byte must always be present. If the length = 0, the
action is null. If the length <> 0, the exact number of bytes as defined by the
length must be present in the message.
An additional 2 or more bytes can give a mask length and data. Bit 5 in the
CONTROL BYTE indicates if a mask is provided as is shown in Figure 2. The mask
length byte must be present if bit 5 is set, and must not be present if it is
reset. If the length is present and <> 0, then the exact number of bytes as
defined by the length must be present in the message.
The general structure of the bytes that constitute an "action" step are:
Byte 0 = CONTROL BYTE
Bytes 2&1 = parameter number of addressed parameter (if bit 6 in
CONTROL BYTE = 1)
Next 2 Bytes = internal ID of the addressed TAG (if bit 7 in
CONTROL BYTE = 1)
Next Byte = length of value (in bytes) (required, 0 for Action
CH).
Next l bytes = value (present if, and only if, the length byte <>
0). If present, must be exactly as long as specified
in the length byte.
Next Byte = length of mask (in bytes) (present if, and only if,
bit 5 in CONTROL BYTE = 1).
Next l bytes = mask (present if, and only if, bit 5 in CONTROL BYTE
= 1 AND if the mask length byte <> 0). If
present, must be exactly as long as specified in the
length byte.
Next Byte = another CONTROL BYTE
OR
This actor will progress through each step in order. If any step fails,
NONE of the alterations of the Data Base will be consummated and the
write will be "failed".
There is no provision for placing two or more independent sets of steps

in one message. However, the "write" action (only) can refer to another
agent.
--```,``-`-`,,`,,`,`,,`---

256
The ultimate limit on this actor is imposed by the requirement that the
total message to the actor must be less than 121 bytes long.

1) any specified parameter is not supported by the TAG specified
or implied by default for the step.
2) any action is targeted to a data base revision number other than
action CH.
3) any action other than an unmasked write is targeted to a
requested mode.
4) the parameter is a data type that is not supported by the
selected operation.
5) the message is too short - it does not include the indicated
status and mask bytes.
6) any of the write restrictions specified in the simple indirect
write service are not met.
7) any parameter targeted by an action is currently protected by its
logical node's NO_WRITE.
8) the execution of the command takes more than one physical node
"AX" cycle (see the paper "Data Owner Structure - Hardware", page
13 for a definition of AX).
RESERVED AND AVAILABLE FOR MANUFACTURERS:
Parameter numbers in the range of 0EH to 3FH will be reserved for future
standards. The range 40H to 4FH will be available for manufacturer-specific
definitions of actors.
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
257
--```,``-`-`,,`,,`,`,,`---
Figure 1 GENERIC CONDITIONAL WRITES
Cond. Write-Ctl. Word:

F E D C B A 9 8 7 6 5 4 3 2 1 0 Conditional Write
Operation type
Value Description
0 Write
1-3 Boolean OR, XOR, AND
4 Low Bit = x
4 Bits: Operation 5&6 Ad, Subtract
1 Bit: "x" 7 Subtract & Clamp @0
1 Bit: Mask justification 8 Increment
(0=Low bit align. 1=hi bit 9 Increment & Skip 0
align) AH Decrement
3 Bits: Mask length (bytes) BH Decrement & Skip 0
CH-FH <x, -x, <>x, >x
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Complex Cond. Write-

Ctl. Word Outline:
Complex Conditional Write
7 6 5 4 3 2 1 0 Operation type
Value Description
0 Test
Operation type 1 Action
1 if new parameter
1 if new tag
Figure 24: Generic Conditional Writes

258
Figure 2
GENERIC CONDITIONAL WRITES

(CONT.)
7 6 5 4 3 2 1 0 Complex Conditional
Write -Test Subtypes
0 Value Description
0 No Test
1-4 <x, =x, <>x, >x
5 Low Bit = x
3 Bits: subtype
6&7 Reserved
2 Bits: attribute description
00 = 0
Complex Conditional
01 = 1
Write -Action Subtypes
10 =value appended
11 = masked value appended
Value Description
0 Write
Complex Cond. Write - 1-3 Boolean OR, XOR,
Action Type: 4 AND
5&6 Low Bit = x
7 6 5 4 3 2 1 0 7 Add, Subtract
8 Subtract & Clamp @0
1 9 Increment
AH Increment &Skip 0
4 Bits: Subtype BH Decrement
1 Bit: set if mask provided CH Decrement & Skip 0
DH-FH Index Revision Number
Figure 25: Generic Conditional Writes (cont.)
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
259
Attach. 2 Logic
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
DBWS LOGIC
The logic that is to be executed by the Data Base Write Service (DBWS) is
detailed in six drawings. This Attachment explains the detailed logic shown in
those drawings. The explanation will be given in the same order as the logic
drawings - starting with Figure 1, "Buffer Service Logic".
Most of the incoming write messages processed by the Application Layer will
be placed in the "Write Buffer" shown at the top of the drawing. This Attachment
will concentrate on the logic that removes the messages from the write buffer; it
is modeled as being processed by the function block logic processor in the Field
Device, not by the communication processor (if they
are separate processors).

BUFFER SERVICE LOGIC
LOGIC FOR STATIC & AUTO-FORMAT DATA BASE REV. NUMBER LOGIC (A)
LOGIC FOR WRITING LOGICAL/PHYSICAL NODE VALUES (B)
LOGIC FOR WRITING MODE (C)
LOGIC FOR WRITING DATA BASE VALUES (D)
LO Mode Check
Write to "O/S Required" or "Man Required" Parameters
Write to Cascade Transfer Locations
Write "Other" Data Base Items
Figure 1 - Buffer Service Logic
Figure 2 - Static & Auto-Format Data Base Revision Number
Figure 3 - Logical/Physical Node Value
Figure 4 - Mode
Figure 5 - Data Base Values
Figure 6 - Data Base Values (cont.)
BUFFER SERVICE LOGIC:

The logic processor will provide a procedure to remove messages from the
write buffer and process the requested write. The logic of this procedure is
described starting with Figure 1, "Buffer Service Logic".
If the block or node that is addressed happens to have requested that all of
its writes be temporarily blocked, the message will be retained in a User Layer
queue. Messages received later but addressed to other blocks or nodes will be
processed ahead of a message to the blocked destination but other messages to the
same blocked destination will be retained in their proper order, first received -
first written.
If the write is from off of this physical node, the Isolation_Timer in all
logical nodes in this physical node will be reset if they are running (see Data
Owner Structure - Logical Nodes, p21)
A write message to an actor will be found in the buffer just like any other
indirect write message. At a point later in the logic, the messages to actors
will be identified and directed to the complex write service. That service will
then have to write or modify data base parameters. Before doing so, the complex
write service will normally reenter this logic and confirm that the altering or
writing of the targeted parameter is permissible. This is not necessary for
actors 8-BH; they can always be written. The entry to this logic in the upper
left corner of Figure 1 is that reentry point for the complex write service.
The logic will check that the TAG and parameter being written to are
supported and the parameter is an indirectly writeable parameter. This heck was
performed by the Application Layer prior to loading the message into the buffer.
SP-50 User Layer Technical Report Database Write Service Attach 2

--```,``-`-`,,`,,`,`,,`---

260
However, the tag's data base may have been changed in the meantime. In addition,
it is needed for the actor logic. If this test fails, one of the following error
messages giving the reason for the rejection of a write at this point will be
reported:
1) TAG not supported in this physical node.
2) PARAMETER not supported in this TAG.
3) PARAMETER not indirectly writeable.
The logic will determine if the write targets a static or Auto-format data
base revision number. If it does, the node labeled "A" indicates that the sub
logic in Figure 2, explained below, is to be executed.
At this point, any write to an actor (as defined in Attachment 1) will be

intercepted and passed to the complex write actors. They, in turn, will execute
this same logic but in the context of the requested complex write. Note that,
when the complex write service returns to this logic via. The entry in the top
left corner of this Figure, it will NOT be an "actor" for purposes of this test,
it will be a resolved indirect write.
The logic checks to see if the logical node's NOWRITE bit is set and, if so,
--```,``-`-`,,`,,`,`,,`---
whether the parameter being addressed can be written during NOWRITE (see the list
on page 12 of the paper "Data Base Write Service"). Note that the NOWRITE
restriction does NOT affect physical node parameters: hence messages to the
clipboard and COUNT_TIME data will NOT be blocked by NOWRITE. The logical node's
NOWRITE DOES affect the data in ALL function blocks in that logical node.
The logic will next check the parameter being written to see if it is a
parameter that has special write restrictions such as requiring a masked write or
can not be set negative. These requirements are defined as part of the
definition of the standard parameters (see the papers "Array of Basic Parameters"
and "Array of Standard Block Parameters"). It is required that the reason for
the rejection of a write due to a restriction be reported with one of the
following error identifiers:
1) discrete that can only be set, not reset.
2) scalar value that can not be set negative.
3) scalar value that can be written as non-zero only if currently zero.
4) a write to this variable must be a masked write.
5) a write to this variable must be a conditional write.
6) a write to this variable must be a masked conditional write.
7) a write to this variable must be a masked conditional write with the
compare done against the mode attribute byte.
The last three checks were not done ahead of the servicing of the data base
revision number because the logic in "A" is the special logic for revision
numbers and writes of revision numbers are not blocked by NOWRITE. In the same
vein, a write to an actor will not be blocked by NOWRITE BUT thecomplex write
service will return to this same logic to check the low level write command: it
will then be subject to NOWRITE restrictions.
The logic next determines if the write is to a physical or logical node. If

it is, then the node labeled "B" indicates that the "sub" logic given in Figure 3
will be used for this write message.
If the write is to a requested mode, the node labeled "C" indicates that the
"sub" logic in Figure 4, explained below, is to be executed.
If the write is not to any of the specific parameters checked by the logic to
this point, it must be to a function block's data record. The node labeled "D"
indicates that the sub logic in Figure 5 is to be executed. Again, that logic
will be explained below.
SP-50 User Layer Technical Report Database Write Service Attach 2 Logic
//^:^^#^~^^"~~:~"~$

261
LOGIC FOR STATIC & AUTO-FORMAT DATA BASE REVISION

NUMBER LOGIC (A):
The entry point "A" is at the top left of Figure 2.
If this logic is being exercised by the complex write service, it must check
that the actor type and action type are acceptable. The only actors that can
manipulate the static or Auto-format revision numbers are numbers 0-6 and DH.
Any other actor will cause a rejection of the write.
A write to the revision number can be one of two forms: either the writing of
a specific revision number or a complex write that requests an index of the
number. Two important restrictions will be imposed by the logic. First, only an
absolute revision number can be written if the existing revision number is the
special value zero. Any other time, an absolute revision number can not be
written and only the command to index is available. When the absolute value can
--```,``-`-`,,`,,`,`,,`---
be written, the new value can not be zero nor an odd number.
The second restriction involves the complex message that indexes the existing
revision number: there is no mechanism for the writing device to define the size
of the increment. The following logic will always increase the value by twice
the number of changes that were made in its associated data base.
An absolute write of an even, non-zero number is only allowed when the

current revision number is zero. If those conditions are met, the logic will
write the revision number and send a confirming response to the sender.
A complex write request that the revision number be indexed can only be
executed if the revision number is currently non-zero, the "monitor" is on, and
there is some non-zero value in a counter that has been counting the number of
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
changes to this data base. The counter is not checked in the logic because the
counter is incremented off of zero when the monitor is started by this logic.
If these tests are passed, a write command to index the revision number is
allowed. The DBWS will have been monitoring the data base revisions; the "change
counter" will contain the number of data base changes (not counting the requested
mode nor FAIL-SAFE) that have been made. All of the steps of "indexing" as
defined on page 8 of the main paper will be executed and a response message will
be sent to the writer indicating success.
If the monitor is currently "off", then no data base changes have been made
requiring a change in the revision number. The logic will not allow a writer to
index the number unnecessarily: it rejects the write and sends
the shown message to the source of the write.
LOGIC FOR WRITING LOGICAL/PHYSICAL NODE VALUES (B):

The drawing of the logic for writing to the data bases of the physical and
logical nodes is given in Figure 3.
A change to a logical node's TAG name is trapped and handled according to the
rules given on page 13 of the main paper.
The logic next checks for three variables that only concern logical nodes,
not physical nodes: TO_TYPE, CX, and CB. When their values are changed, the
logical node must implement a new time schedule. The model of the system assumes

262
that the generation of the new time schedule will take some finite time, after
which the logical node will restart with the new time cycle. It is assumed that
it is the DBWS that monitors these values and forces the rescheduling action by
setting an internal flag (not accessible from Field Bus). The monitor is started
or reset on this logic path. See page 13 in the main paper for additional
details.
The next logic check involves the agents for the 5 logical node variables.
If the agent type or the pointer of the agent is changed, there are specific
rules given on page 14 of the main paper for the required handling. The
operation of setting the agent's value "Bad" (and also "Not-from-Process" and
"No-path-to-Process") is shown separately so that the following step can share
the larger box on the diagram.
Function block tag names are actually logical node variables. The next step
in the logic checks for a change in one of these names. If so, then the special
rules, also given on page 13, have to be followed.
If the write is to the Auto-format variables associated with the physical I/O
hardware, either instances or I/O type, the DBWS will check for an LO key and for
the existence and mode of the associated function block(s). If LO is set by a
physical key, the write will be rejected. If there is no LO key AND if there is
no associated function block (i.e., no function block has a hardware agent
pointing to this particular I/O instance or set), the write can proceed. If
there is an associated function block, then that block must be in either O/S or
Man requested mode for the write to proceed. Note that if LO has been set by
Field Bus, it will be reflected in the mode of the associated block. There are
two different write rejection messages to cover the two different cases: 1) LO
key set but no associated function block, and 2) improper mode in the associated
function block.
Next, the logic separates the writes to the static data bases from the writes
to the dynamic data bases. Writes to the dynamic data base are simply written
and the response to the writer is sent. The others are checked for a write to
Fail-safe; if the write is to Fail-safe, the logic will apply the checks given on
page 3 of the main paper. If the rules are violated, a specific error message
will be returned to the sender.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
For all other static data base items, the logic will confirm that all writes
to parameters with "parameter specific rules" obey the rules. If the rules are
violated, a specific error message will be returned to the sender.
--```,``-`-`,,`,,`,`,,`---
For most of the remaining writes, the logic will reset the monitor if it is
on. If it is currently off, the logic will check to be sure that the value is
really being changed, and, if it is, turn the monitor on and set the least
significant bit in the associated data base revision number. The value is
written and the sender is told that the write was successful. In the special
case of a on logical node write, the value is written to the data record but the
monitor is not started nor reset.
That concludes the logic for writing physical and logical node parameters.
LOGIC FOR WRITING MODE (C)

The entry point "C" is at the top left of Figure 4.
If the write is to the requested mode of a function block, the restrictions

on writing the mode, S1 to S4 on page 15 of the main paper, are checked. If any
one of these restrictions is violated, a message is returned to the source of the
write. The response message will indicate the cause of the rejection detailed to
the specific "S" number.
When logic is being exercised by the complex write service, it must again
check that the actor type and action type is acceptable. The only actors that

263
can manipulate mode are number 2 and action CH in actor DH. Any other actor will
cause a rejection of the write.
A write to the block's requested mode can be one of two forms: either a
simple indirect write to the requested mode or a complex write that requests that
the data base revision number be indexed along with the write to the requested
mode word.
A function block is not to be put into service if either of its related

revision numbers are still equal to zero. See the main paper, page 10 for the
details of this check. If this check fails, the requested change in the revision
number is not acceptable. The mode simply can not be changed (it must remain in
O/S mode) until the data base revision number has been initialized with a write
of an absolute, non-zero even number into the revision number.
A function block is not to be put into service if LN_OOS is TRUE in its

logical node (see the paper Data Owner Structure - Logical Nodes, page 2).
Any write that changes the requested mode FROM O/S to any lower priority mode
will set FORCE_INIT = 3. This insures that the block fully initializes any time
it starts up from O/S (see page 23 of the paper "Function Block Structure").
The rest of the logic for writing modes depends on the block's data base
monitors. If both of them are currently "Off", then no data base changes have
been made requiring a change in the revision number. Therefore, the write of the
new requested mode is simple but requires an alert if there was actually a
change. Note the special check for actor 2 while the monitor is off: unnecessary
indexing is not allowed.
Figure 4
This check of the monitors is quite complicated for actor DH. It is required
that the write to the actor fail if the sender is unnecessarily requesting an
"index" of the revision number. However, it is entirely possible that "actions"
in the complex conditional write request to actor DH set up the need to index the
revision number. It is up to the complex write service logic to ensure that this
testing is done correctly.
The logic to handle the "monitor on" cases is concerned with the source of
the write message. The logic will not allow mode writes from an on logical node
control block to interfere with the handling of the data base revision number.
The logic step labeled "Write from on logical node?" prevents the downstream
logic from indexing the revision number or resetting either monitor due to an on
logical node write.
The logic step labeled "CHANGE_PENDING set?" directly refers to the

requirement given on page 9 of the main paper: an on logical node write can not
change the mode of a block that has had a protected parameter in its data record
changed but has not yet had its revision number incremented. The condition in
this check is modeled as being indicated by the internal, non-accessible logical
called "CHANGE_PENDING". It is shown as being set at the appropriate place in
this logic specifically so that the information for this check is available. It
is reset by the "index" command.
Figure 4
Note that, when this check is violated, the sender is notified that the write
was successful! This method of handling mode writes from the same logical node
results in the following:
1) the on logical node control block writing the mode will not count
out nor issue an alarm.
2) the on logical node control block writing the mode can not cause a
block to be put into control while it has a "mixed" static
configuration.
If a monitor is on and the write command is from an off logical node source,
the logic next inspects the mode being written. If the mode is lower in priority
than Man (for a block that supports Man, lower than Auto otherwise), the mode is
written, an alert warning of the new requested mode is sent if the write actually
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
264
changed the value, both function block revision numbers are indexed, and a
response message to the writer indicating success is sent.
Any mode manipulation by an actor is sent on the same path. This follows
from the very limited nature of the actors that were originally allowed to write
to the requested mode - actor 2 or DH (action CH). They specifically requested
the index of the revision number and the previous special testing confirmed that
actor DH was not unnecessarily requesting an "index".
If the write command is from an off logical node source but the new mode is
O/S, LO, or Man, the logic leaves the monitor running, the timer on the monitor
will be reset, the mode will be written, and a response message to the writer
indicating success is sent. Note that the monitor "reset" means that the timer
will be reset to zero but the monitor will continue in operation and the change
--```,``-`-`,,`,,`,`,,`---
counter is left alone.
That concludes the logic for writing the requested mode.
LOGIC FOR WRITING DATA BASE VALUES (D):

The entry point "D" is at the top left of Figure 5.
The top portion of this Figure is concerned with the logic for writing to a
block that is in LO mode. The lower portion is concerned with the logic for
writing to static data base values that require that the block's mode be in O/S
or Man. A small logic step at the bottom of Figure 5 asserts a few rules that
apply to both cascade transfer location writes and other writes to the dynamic
data base.
The logic shown on Figure 6, actually a continuation of Figure 5, is

concerned with the cascade transfer locations (top half of the figure), and the
general static and dynamic data areas (bottom half).
The following description is organized using these divisions.
LO Mode Check:
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
The logic checks the "class" of the parameter vs. the status of the
block's mode. This check implements the restrictions listed on page 14
of the main paper:
1) If the parameter can be written while LO mode is set, the checks
are bypassed.
2) For parameters that can be limited by the LO mode status:
a) if the requested mode is set to LO, the block will not go
into LO mode until the next execution of the block but this
situation will inhibit writes immediately.
b) if the actual mode is either LO or IMan(LO) (not any other
combinations of mode bits), then the pure LO mode has been
set in this block and writes are blocked.
c) if the write being processed is to a Discrete Output block
or an Output bit in a Discrete Register, the logic must
also check for the existence of the OUTLO flag and/or the
presence of a keylock for the particular bit whose data is
being changed by the write message.
Any of these cases will block most writes to either the block or the
bit. Even if only 1 bit among several are blocked, the message is
rejected. A response message indicating the exact cause of the
rejection will be returned to the sender. Note that this check must
recognize any mask in the write message so that the sender can
manipulate unrestricted bits in a word that has locked bits by using the
suitable mask.

265
At this point in the logic, the write is known to be a write to a

block data item other than mode, revision number, or one of the special
parameters and not in violation of LO mode restrictions on the block or
bit.
Write to "O/S Required" or "Man Required"

Parameters:
The logic begins by isolating those parameters that can only be
written while the block is in O/S mode. If the parameter is one of the
set, the value is checked to see if it is exactly the same as is
currently in the static data base. If it is, the block initialization
and revision number change are not needed but
- the sender will be notified that the write command was
successfully executed
- the monitor will be reset IF
+ it is currently on AND
+ the write was from off logical node
If the value is different, the requested mode is checked. If it is

not in O/S, the logic sends a message to the source of the write
indicating the exact cause of the rejection.
If the block is in O/S mode, then the logic will check for a change
to the TO_TYPE, TO_TYPE1, BX, or PN values. If the write is to any of
these parameters, refer to page 14 of the main paper for the rules.
Otherwise, the value is written and the special values such as
CHANGE_PENDING and the monitor are appropriately adjusted as shown.
Note that the integer that will force the block to execute the special
three-cycle operation (FORCE_INIT) does not need to be set because that
will be done when the mode transitions out of O/S.
This step was allowed based on the requested, not actual mode.
This rather lax test is possible since the DBWS sets the initialization
counter based on the requested mode. The block will be forced to
correctly initialize even if there are a series of mode changes that are
fast compared to the cycle time of the block. The block will always go
through the three special cycles.
The logic for a parameter that is read-only unless the block's mode
is Man or a higher priority mode is similar to the logic just covered.
The requested modes that are acceptable are O/S or Man for analog
blocks, O/S and Auto for discrete blocks. In this case, FORCE_INIT must
be set as well as CHANGE_PENDING. This is because a requested mode
change out of Man DOES NOT automatically generate an initialization
pass. If the block executes before the mode is changed out of Man, it
will process the initialization and reset FORCE_INIT even while it is in
Man mode.
The next major step in the logic will be concerned with writes to
the cascade transfer locations. However, there are several rules that
apply to both those locations and other dynamic data base items. Those
rules are applied at this point.
Rules D5 on page 16 and D11 through D14 on page 17 of the main

paper concern the following areas:
D5) 3-bit setpoints require 1, and only 1, bit set.
D11) add default status byte if status byte missing on a write.
D12) trap a No-Com status and convert to Bad, resetting the No-Com
bit.
D13) trap a + or - infinity data value and change it to NaN, "Bad",
"Not-from-Process", and "No-path-to-Process".
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
D14) trap a NaN data value and set its "Bad", "Not-from-Process",
and "No-path-to-Process" status bits, leaving the NaN value.
Only the first rule blocks the write and generates a rejection code.
--```,``-`-`,,`,,`,`,,`---

266
The other three rules simply modify the write and continue, generally
producing only a "successful" response to the sender.
Figure 6 is actually a continuation of Figure 5; node "E" simply

connects them.
Write to Cascade Transfer Locations:

Services D8 and D9 on page 17 (reset transfer location count out
gates and block the writes if doubly wound up) are provided for all
three of the cascade transfer locations if they exist. This section of
the logic implements those services.
In each case, the logic checks the current status of the receiving
location. If the mode is blocking the higher level device or if the
transfer location is "doubly-wound-up", the write will not take place
BUT THE SENDER WILL BE NOTIFIED THAT THE WRITE WAS SUCCESSFUL. In the
--```,``-`-`,,`,,`,`,,`---
overall design of the handshake between a control block and its

secondary, the knowledge of the condition of the secondary is passed up
to the primary via. the READ of the transfer location, not by the
failure of a write.
In each case, the logic resets the counter on the count out gate of
the transfer location if the requested mode is correct. This is done so
that the remote handshake is not broken by a doubly wound up condition.
Also, in each case, the logic will complete the writing of bits 3, 5,
and 7 in the status byte of the transfer location if the required mode
is current (for analog blocks; bits 3 and 5 of the status bytes of each
discrete bit and bits 5 and 7 of the Setpoint value of a 3-bit Setpoint
value). This allows LO mode and failure acknowledgement to pass through
a cascade that is doubly wound up.
If the state of the transfer location and the mode of the block is
appropriate, the value is written and the sender is notified of the
success.
Write "Other" Data Base Items:

The rules that were specified in the main paper were divided
between rules for the static data area and rules for the dynamic data
area. The logic makes that same split at this point.
If the write is to a dynamic data area, the following rules must

be checked and an appropriate error message will be generated if the
check fails. The error message should be at least as detailed as the "D"
rules themselves:
D1 a/b) restrictions on writes to "Output".
D2) restrictions on writes to "Setpoint".
D3) force writes to "Setpoint" or "Target_SP" to respect SP limits.
D4) restriction on writes that set the SP Ramp_Flag.
D6) agent's data is read-only except for value and value status of
writeable agents.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
If the above 5 checks are passed, the dynamic data write is forced
to follow the following rules. Note that these rules are simply
imposed: they do not cause the write to be rejected nor do they cause
any response error message. They simply add steps to the write
procedure:
D1c) set initialization counter to 1 for a write to "Output"
D7) mirror Setpoint and Output writes to the cascade transfer
locations.

267
D10) reset the count out gate on required writeable agent values
After these checks are completed, the value is written and the
procedure returns to Figure 2.
If the write is to a static data value, a different set of checks

must be performed. Again, any write rejections based on these rules
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
will carry error codes that are at least as detailed as the "S" rules
themselves:
S6) limit on writes to ACQUIROR.
S7) limits on writes to the Setpoint Limits.
In addition, the DBWS is responsible for manipulating two bits in

the mode attribute byte based on the value of ACQUIROR. These rules
are represented at the bottom of Figure 6. Again, note that this rule
does not cause the rejection of the write command nor any error message.
If all of the checks are passed, and after the auxiliary operations
are done, the write is executed if the value changed. If the write was
on logical node, the monitor is not affected. If the write was from a
different logical node and changed the value, the monitor is turned on
or reset. If the write was from a different logical node but did not
change the value, the monitor is reset if it is on but not turned on if
it is currently off. The procedure then returns to Figure 2.
The sender is notified of the success or failure of the write. The

sender is not notified when the write was skipped because the value
would not be changed nor when additional operations are done as a result
of the above rules.
--```,``-`-`,,`,,`,`,,`---

268
Figure 1 BUFFER SERVICE LOGIC

Actor
Logic Write Buffer
Zero Write Service

No
Isolation Blocked Buffer
Timer ? Place write in UL queue
Yes Keep order
TAG No
Valid Reject Write:
? No Invalid Target Respond
No To Sender
Yes Param. Yes Param. Yes Write Yes
Valid Indirect
Write
Rev.#
?
A
?
No
?
Violate
Log. Node Actor Process write according to
NOWRITE No ? The actors' service definition
? Yes
No Reject write: violates
Yes
Special NOWRITE limits.
Restrict- No
ions Reject write - special write
OK? restrictions
Write Yes
To P/L
Yes
Node?
B
Write
Yes
To
Mode?
C
No No
D
Figure 26: DBWS Figure 1, Buffer Service Logic
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
269
Figure 2
STATIC & AUTO-FORMAT
A DATABASE REVISION NUMBER
Write
mode
Yes 0-6 No Reject Write:
Actor or Invalid mode.
? DH?
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
No Yes
New Write Absolute

Current Yes Yes No
Write Rev # Revision #
Rev #
=0? Abs.? =0 or
odd? Reject Write:
Can't write 0 Or odd Rev #
No No Yes
Reject Write"
Must write inc.
Yes To Rev 0 or rev. #
Write Reject Write:
Abs.? Must write abs.
To a 0 rev. #
No
No Reject write:
Monitor Can't freely
On? Index rev. #
Ye Index Return
Revision #
Figure 27: DBWS Figure 2, Static & Auto-format Data Base Revision Number
--```,``-`-`,,`,,`,`,,`---

270
Figure 3
LOG./PHY. NODE VALUES
B
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Db
Write See comments,
No Change main paper, page 12 Set flag to shut down
Log Node Object at end of cycle
TAG Yes Change value and restart.
? Follow rules given in main
Paper, pages 12 and 13
Yes Yes Yes
See main If value
Change No Change No Change Paper, page Change
TO_TYPE CX CB 12, Break AND
? ? ? associations, Off-node
Change param. Write:
Yes start
Allow new
Or restart
Chg. associations Monitor,
FB LNNo
Ver.
No inc.
TAG Type or Set var.
No Change ctr.
Name Ptr. Yes Value bad
? ?
Write LO
To Yes Key Yes Reject write:
Hrdw. Set? LO Key Set.
A-F? No
Assoc. Block
No No Block O/S or Reject write:
? Ye Man Requires O/S
? Or Man. mode
Write Yes No
To Yes
Write Value
Dynamic
Yes Send alert if change
DB? Write Yes Fail-
To Fail- Safe
No Reject write:
Safe? Rules No Violates Fail-safe Rules
OK?
No
Violates Reject write:
Param. Yes Violates parameter If Monitor on - reset it.
Spec. Specific rules. If value changes and rev.
Rule >0 start monitor, inc. change
--```,``-`-`,,`,,`,`,,`---
On
? No ctr. And set LSB of rev. #
No Logical
Node
? Yes Write value. Return
Figure 28: DBWS Figure 3, Log./Phy. Node Values

271
C Figure 4 MODE
Write
mode
Valid Reject Write:
No
Mode? Invalid mode.
S1-S4,
p15
Yes No No No
DH, Reject Write:
Actor #2
Action Invalid target
? ?
CH?
Any No Yes Yes
Related
Rev.# Reject Write:
No =0? Yes Must change
0 rev. # first.
--```,``-`-`,,`,,`,`,,`---
Yes
No
Leaving CHANGE New + Write mode.
No Yes
O/S PENDING Mode + If change,
Mode Set? (Man) send alert
? ? +Index both
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Yes No Rev. #'s
Set Yes
Force Write
From on Yes
Init. = 3 Actor Write
Logical ?
Node? No Mode
Reset And, if
Either Yes Change,
Monitor
Monitor No Send
No Times.
On? No alert
Actor
#2?
Reject write: Can't freely Index rev. # Return

Yes
Figure 29: DBWS Figure 4, Mode

272
D
DB Figure 5 DATA BASE VALUES Reject write-
Write LO mode set - can't
Yes write now.
Write Req. Reject Write;

No No Actual Yes
Value LO mode Param. Write
LO mode
while Set? Requires O/S
Set?
LO?
Yes Disc. See rules, main
No
Bit & KL Paper, page 14
No Or
OUTLO7 Yes
Change to:
Req. Yes Req. No TO_TYPE,
O/S Value Yes TO_TYPE1, BX
Mode =
Item Change Or PN1
O/S
? ?
?
No Yes
No Reject Write:
Req. Param. Write
Man. No Req.>Auto
Item Yes No
? Yes
Value Yes Req. Set force Init. = 2 if now <2.
Change Mode >
Rule No ? Auto?
IF rev. # > 0
D5, p16 Set CHANGE_
OK? On
Pending
Logical
Yes Write
Yes No Node
Value If value change;
?
Assert rules Increment change
No
D11-D14, p17 Reset Counter; set
No Monitor Monitor if off; Set
Rev.# least Significant bit
If on.
=0 In revision #.
Yes
E
Reject Write: 3-bit Setpoints Must have 1, and only 1 bit set. Return
Figure 30: DBWS Figure 5, Data Base Values

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
273
Figure 6 DATA BASE VALUES (con't)

E
DB
Con't Don't write value
No Portion of msg.
Reset Yes Don't reject msg.
Cas
Cas Yes Req. CDG Cas. No
Transfer Mode = Write TL Write Value
Loc. Cas? Yes Stat. DWU?
?
No Reset Return Set
No
RCas Yes Req. Yes RCas RCas LSB of
Transfer Mode = CDG TL Rev. #
Loc.? RCas Write DWU? Start
? Stat. /Reset
Yes Monitor
No Reset
No No Inc.
Yes Monitor
Yes Reset If On Counter
ROut Yes Req. ROut
ROut
Transfer Mode = TL
CDG
Loc.? ROut DWU? No
Write No
? Stat. Yes On
No
Logical
No Yes Assert Rules D1/c & No Node
Static Rules D7, p16 and D10, p17. Ye On ?
D1a,D4,D6 No
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Data Logical
OK Reject Write: Out, Node
?
? SP, Limits, Ramp ?
Flag & agents ctl. Write
Yes
No Value
Rule Value
No Reject Write: Change
S6, p15 Yes
OK ACQUIROR ?
No
? Control
Yes
S7 Chg. No Yes
Yes To Rev.
P14 Fix bits 6&7 in
OK? ACQUIROR ATT_ACCESS. #=0
Yes ? No ?
Figure 31: DBWS Figure 6, Data Base Values (cont.)
--```,``-`-`,,`,,`,`,,`---

274
Data Base Write Service Table 1 Logic for Indirect

Writes
The following is the logic for DBWS handling of writes to parameters in the
range of parameter numbers that includes status byte handling.
The sections of this logic are:

CASE Analog
CASE Discrete
Note: The "default status byte" is a status byte that is completely

reset except for bits 2 and 5 (Not-from-Process and No-Path)
Reference is made to the "z" notation used in Figures 3 and 4

in the paper "Function Block Structure".
The counters on parameters z, (z+1), and (z+3) are handled in

such a way that an indirect write to any of them will take
precedence over a later direct write to parameter z [and a
later direct write to parameter (z+1) if (z+3) exists].
This logic does NOT reset the Logical Node's Isolation_Timer.

Only the "configured" writes using a scheduled direct write
will do that.
The Data Base Write Service will not issue any No-Com nor Bad
alarms nor reset any existing such alarms.
CASE Analog:
IF the parameter number selected is "z", then
inhibit direct writes.
write the value into parameter z
write the value into the value of parameter (z+1).
write the default status byte into the status of parameter (z+1).
IF the value of z = NaN, then
set the following bits in the status byte of parameter (z+1):
bit 1 (Bad)
bit 2 (Not-from-Process)
IF the value written to is Setpoint, then
copy the value in parameter (z+1) into (z+1) of the Cas
Transfer location.
copy the value in parameter z into z of the Cas Transfer
Location.
copy the value in parameter (z+1) into (z+1) of the RCas
Transfer location.
copy the value in parameter z into z of the RCas Transfer
Location.
IF the value written to is Output, then
copy the value in parameter (z+1) into (z+1) of the ROut
Transfer location.
copy the value in parameter z into z of the ROut Transfer
Location.
permit direct writes.
set the counter integer for parameter z = 1.
reset the counter integer for parameter (z+1).
IF the parameter number selected is "(z+1)", then
IF the value of the data = NaN, then
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
set bit 1 (Bad) in the status byte of the data.

IF bit 0 in the status byte of the data is set, then
reset bit 0 (No-Com.).
SP-50 User Layer Technical Report Database Write Service Attach Indirect Writes
--```,``-`-`,,`,,`,`,,`---

275
IF the receiving location is a transfer location or the

Setpoint, then
set bit 3 (Remote).
set bits 6 and 7 (ATW).
set bit 2 (Not-from-Process) in the same byte.
write the value and status into parameter (z+1), using the
status mask if provided.
copy the value part of (z+1) into z.
Transfer location.
Location.
Transfer location.
Location.
IF the value written to is Output, then
copy the value in parameter (z+1) into (z+1) of the ROut
Transfer location.
copy the value in parameter z into z of the ROut Transfer
Location.
ELSE error 'note that a DBWS write to "(z+2)" is not allowed because
'the timing of an off-logical-node write of the status
'can not be coordinated with the write of the value -
'time coherency can not be provided. A write to
'parameter (z+3) is not allowed because it is
'undefined.
CASE Discrete:
IF the parameter number selected is "z", then
write the value into parameter z, using the mask if provided.
copy the value of parameter z into the value of parameter (z+1).
write the default status byte into the status of (z+1).
copy the value of parameter z into the value of parameter (z+3).
write the default status byte into each of the 16 status bytes
of (z+3).
Transfer location.
Transfer location.
--```,``-`-`,,`,,`,`,,`---

Location.
Transfer location.
Transfer location.
Location.
set the counter integer for parameter (z+1) = 1.
reset bit 0 (No-Com.).
IF the receiving location is a transfer location or the

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
276
Setpoint, then
set bit 5 in the value of parameter (z+1) (Remote).
set bits 6 and 7 (ATW).
set bit 2 (Not-from-Process) in the same byte.
write the value into the value of parameter (z+1), using the
mask for the value and status byte if provided.
write the value of parameter (z+1) into the values of parameters
z and (z+3).
write the status byte of parameter (z+1) into EACH of the status
bytes of parameter (z+3).
Transfer location.
Transfer location.
Location.
--```,``-`-`,,`,,`,`,,`---
Transfer location.
Transfer location.
Location.
FOR each of the 16 bits in the value of parameter (z+3):
IF the bit in the value mask corresponding to this bit in
value is set, then
IF (the No-Com status bit is set AND the first bit in
the mask for the status byte corresponding to
this value bit is set), then
reset the No-Com status bit (Bit 0).
set the Bad Value status bit (Bit 1).
set the Not-from-Process status bit (Bit 2).
set the Failed status bit (Bit 4).
reset the No-Path status bit (Bit 5).
set the ATW status bits (Bits 6 and 7).
IF (the receiving location is a transfer location
OR the Setpoint), then
set bit 5 in the value of parameter (z+3).
NEXT value bit.
write the value into the value and status of parameter (z+3),
using the mask for the value and status bytes if provided.
write the value of parameter (z+3) into the value of parameter z.
write the value of parameter (z+3) into the value of parameter
(z+1).
calculate the transverse Boolean "OR" of the status bytes of
parameter (z+3) and set the result into the status byte of
parameter (z+1).
Transfer location.
Transfer location.

Location.
Transfer location.
Transfer location.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
277

Location.
ELSE error - BREAK 'note: can not write to parameter (z+2).
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
278
Figure 2
CLIPBOARD REVISION NUMBER LOGIC
Complex No
Semaphore Set
Write: Semaphore
Test:
Obtain = Value
Active
Semaphore
?
Yes
No
Complex Index
Semaphore Yes
Write: Do Revision
Clipboard Test: Write
Active Number
Page
?
No
Complex Semaphore
Write: Yes Write
Test: Semaphore
Release Active = 0 OK.
Semaphore ?
Write
Done
Fail
Figure 32: Application Layer - Clipboard Revision Number Logic
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
279
Figure 1
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
APPLICATION LAYER - WRITING TO BUFFER
Write
Msg. Watch Dog
* = Data Flow Timer on UL
Logic engine.
Agent type
Parameter * Check by
Table * DBWS
Direct
Write Yes * Reject write:
Command Parameter not
No
? Writeable.
No Direct
Yes
Writeable
Param. Write directly
? To memory.
Buffer
Full\ Yes
? Respond
Reject Write:
To sender.
Can't write -
Buffer full.
Store value
No In buffer.
Done
Write Buffer
* = Data Flow
Figure 33: Application Layer, Figure 2, Writing to Buffer
--```,``-`-`,,`,,`,`,,`---

280
Alert Function
Alerts will be recognized by the physical node, the logical nodes, and the
function blocks in Field Bus devices that are both interchangeable and data
owners. The "Alert Function" is concerned with the services that are provided by
the Field Bus devices to detect events and to allow higher level devices to be
aware of the occurrence of these events and to achieve that awareness with
optimum efficiency relative to communication on the Field Bus.

INTRODUCTION
ASK AND BASK
ALERT SERVICE OVERVIEW
PHYSICAL NODE ALERTS
LOGICAL NODE ALERTS
FUNCTION BLOCK ALERTS
DETAILS OF DATA BASE SUPPORT FOR ALERTS
Data Base Items For Each Node/Block Alert
Node/Block Alert Descriptors
Report Change Indicator
ALERT REPORT RECORD
PHYSICAL NODE FUNCTIONS
Minimum Alert Exposure Time
No-Alert Alert
Buffer Overload Indicator
ALERT SUPPRESSION
HARDWARE I/O FAILURE ALERTS
FIELD DEVICE ALERT SERVICE LOGIC
CASE Normal
CASE Cycle In Which The Alert Service Is Blocked
CASE Cycle(s) After A "Buffer Blocked" cycle
HIGHER LEVEL DEVICE ALERT SERVICING
Table 1 - PHYSICAL NODE ALERTS
Table 2 - BASE LOGICAL NODE ALERTS
Table 3 - BASE FUNCTION BLOCK ALERTS
Figure 1 - Multiple Hardware Failure Suppression
Attachment 1 - Logical Node Extensions
Attachment 2 - Function Block Extensions
--```,``-`-`,,`,,`,`,,`---
INTRODUCTION:
The alert service will be concerned with two types of events: "alarms" and
"notifications". An alarm is a report of a state change. A node or block can go
into an alarm state, stay in that state for a period of time, then exit, or
"return", from the alarm state. The alert service will report both the
transition into, and the transition out of, the alarm state. Between those two
events, a discrete will be maintained showing the existence of the alarm state.
A notification is a report of an event but there is no connotation of a "state"
or a "return". For example, the loss of the validity of the static data base
will cause the generate of a notification alert (the data base will immediately
be changed to the default data base).
"Alerts" in Field Bus devices will consist of many different types of

occurrences. They will include, but are not limited to:
1) Hardware failures in the physical node.
2) Field Bus communication failures.
3) System software failures.
4) Illegal logical node configuration.
5) Illegal block configuration.
6) Mathematical or logical failures in the block.
7) Algorithm driven setting/resetting of requested mode.
8) Process alarms.
SP-50 User Layer Technical Report Alert Function

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
281
9) New process measurements (in certain types of nodes).
Yet another type of alert is a "message", containing a (variable) visible

string, from a field bus entity to another entity or to the human operator.
There are no Standard function blocks that require a message capability but the
codes are set up in this paper for use by a nonstandard block. Note that a
message can fit into either the alarm or notification category: a simple message
would be combined with the notifications (there is no "state" concept) and a
message that requires acknowledgement would be combined with the alarms (the
source is in a "waiting for acknowledgement" state very similar to an alarm
state).
This paper will define the alert descriptions that will be available for use
by the Standard nodes and blocks. It will also describe the alarm identification
functionality that must be provided by all Standard nodes plus a reporting
mechanism that can optionally be provided in each logical node.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
The alert service is designed to be supported by an alert reporting service
at the Application Layer (see the paper "Application Support Services Interface"
and its attachment - User Layer Support Services). Because of the communication
traffic associated with a burst of alert reporting, the Field Device's alert
service is designed to minimize the size of the alert record.
--```,``-`-`,,`,,`,`,,`---
ASK AND BASK:
Two parameters, designed to be of assistance to higher level devices in alert
handling, are required for all Standard nodes and Standard, Alternate, and
Generic Function Blocks - the "alert sort key" (ASK) and the "batch alert sort
key" (BASK). These two parameters are of no direct use to the field devices that
house them.
The ASK is an 8 bit unsigned integer. Every tagged object on Field Bus has
one and only one ASK. It is intended to be used by a higher level device to sort
the alerts reported up from the field buses for purposes of distribution within
the higher level system. It is intended to be an essentially permanent
assignment that shows the relationship of the tagged object to one or more
operator domains for purposes of alert display and acknowledgement.
The BASK is a 16 bit unsigned integer. Every tagged object on Field Bus has
one and only one BASK. It is intended, just like the ASK, to be used by a higher
level device to sort the alerts reported up from the field buses. However, the
BASK is specifically designed to be used in applications such as batch control
where a second sort key, in addition to the ASK, is needed. Typically, a BASK
describes a much smaller tagged object set than an ASK and is more related to
batch report preparation than to alert acknowledgement.
The ASK and BASK will be contained in the PN/LN/FB parameters in the Data
Dictionary as well as being parameters on their own right in the tag's data base
(see the paper "Application Support Service Interface", p7 and the "Array of
Basic Parameters" paper). The intended methods of using the ASK and BASK are
explained in the appendix paper "Explanation of ASK, BASK, and ACQUIROR").
ALERT SERVICE OVERVIEW:

A logical node may optionally support "the alert service" (see the paper
"Data Owner Structure - Logical Nodes", p25.). If it does, the alerts will cause
the generation of an "alert record" that will be passed to the Application Layer
when the alert occurs. In addition, if ANY logical nodes in a physical node
support alert reporting, then the physical node will also report its alerts.
(The Application Layer support for the alert service is assumed to be actually

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
282
provided to the physical node but not all logical nodes in a physical device have
to use the service.)
The Standard "Alert Service" is designed on the basis of the use of code and
subcode numbers to represent the description of each alert. There can be a
maximum of 63 types of alerts, each with up to 32 subcodes. The Standard nodes
and blocks will have defined lists of codes and subcodes. Each manufacturer can
choose the appropriate codes and subcodes from those lists as needed. In
addition, the undefined codes can be used if needed. There is absolutely no
intention that any field device would need or support all of the codes.
The alert code is passed in the alert record. An alert code of 3FH will
indicate that the Standard alert coding system is not being used. Since there
are no alternate systems defined, this Standard does not define what follows the
3FH code.
Most of the Standard code numbers will be in the number range of 0 - 1FH. In
addition, alerts are defined in the range of code numbers 39H to 3EH. Later
sections of this paper will define a list of alerts for all physical nodes, a
base list for all logical nodes and a base list for all function blocks.
Attachment 1 will define a list of additions for each type of logical node and
Attachment 2 will define a list of additions for each type of Standard function
block. Each list of alerts will allow a few code and subcode numbers within the
range of 0-1FH for extensions to the standard nodes/blocks; all of the codes
between 20H and 2FH inclusive are available to non-standard entities.
The code numbers 1DH - 1FH are always undefined but have associated
descriptor string variables. The manufacturer can define one or more of these
three codes for alerts that are not included in the Standard list. The descriptor
can default to a manufacturer entered string. The user can, as part of the
--```,``-`-`,,`,,`,`,,`---
device configuration, load a revised description into the descriptor string
variables (in the style and language chosen by the user). In addition, several
other code numbers in the range 0 - 1CH are usually available for manufacturer
definition but there is no defined support for labeling more than the three
alerts.
There will be a maximum of 32 (1FH) subcodes for each code. There are two
subcodes that will have a consistent definition and are implied in all of the
code lists. Subcode 1EH will always mean "the subcode identification was lost
because the alert system was full at the time of the alert". Subcode 1FH will
always mean "there is no appropriate defined subcode for the alert that
occurred".
When an alert occurs in the same cycle as an alert with the same code but a
different subcode, records for each of the alerts will normally be passed to the
Application Layer alert reporting service if it can accept them. However, later
sections of this paper define a number of situations in which alert reports are
suppressed by other simultaneous or preceding
alerts.
The alert service will include certain data base items for each of the first
32 possible alerts in each node/block. The list of those items is presented in
detail in a later section; a summary is as follows:
Configuration data:
a) alert priority - 4 bits.
b) reset unacknowledged alert option - 1 bit.
Dynamic Data:
a) alert state - 1 bit.
b) unacknowledged alert - 1 bit.
c) unreported state - 1 bit.
The Application Layer alert service will accept a user-entered value that
will prevent an alert from being overwritten if it has been "exposed" for less
than the defined amount of time. When alerts can not be passed to the
Application Layer because of that limit, the User Layer must be prepared to
provide some degree of backup. Specifically, it will retain an indication that
the NEW alerts occurred but were not reported. A later section of this paper

283
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
will provide an illustration of detailed logic that must appear to be performed
at the succeeding executions of the node or block. This function will be called
"overflow flagging".
The objective of this paper is to completely define the data owner parameters
that are both accessible to Field Bus and a part of the alert service. In
addition, the paper will demonstrate that there is at least one reasonable
implementation of the system. In order to meet those objectives, it is necessary
to refer to two additional variables that are not accessible to Field Bus. These
variables are used in the example implementation; they are not required. Any
implementation that preserves the exact meaning of the parameters accessible over
Field Bus is acceptable within a fully interchangeable field device. One
additional variable is an integer, called the "OVER_CTR", associated with each
physical node. Its use will be detailed in the "Field Device Alert Service
Logic" section of this paper. The second is an integer, called REPORT_CHG, that
will be explained in the section of this paper called "Report Change Indicator".
PHYSICAL NODE ALERTS:

The standard alerts for physical nodes will have code numbers 0 - 17H and 3BH
- 3EH. They will be called "standard physical node alerts". Alerts 18H - 1AH
are reserved for future Field Bus Standard definition while 1BH and 1CH are
available for manufacturer's use. As normal, alerts 1DH - 1FH may be defined and
used by the manufacturer; for each of these three alerts that are used, the
associated variable that contains the visible string description will be
required. A manufacturer may optionally support the "extended" alert reports -
code numbers 20H - 2FH. (Refer to the definition of the Data Dictionary variable
PN in the paper "Application Support Services Interface", p8 plus the definition
of TIME_CRIT0 on page 20 of the paper "Data Owner Structure - Hardware" for the
indicators of which of these codes and descriptions are implemented.)
The defined physical node alerts are given in Table 1.
The Failsafe hardware alerts will be handled by the logical node to

which the Failsafe is connected.
LOGICAL NODE ALERTS:

The standard alerts for all three types of standard logical nodes will have
code numbers 0 - 3 plus 3CH - 3EH: they will be called "base logical node
alerts" and are defined in Table 2.
Node alerts 3 - 1CH will be defined for individual types of Standard logical
nodes in Attachment 1. As normal, alerts 1DH - 1FH may be defined and used by
the manufacturer; for each of these three alerts that are used, the associated
variable that contains the visible string description will be required.
--```,``-`-`,,`,,`,`,,`---
A manufacturer may optionally support the "extended" alert reports - code

numbers 20H - 2FH. (Refer to the definition of the Logical Node Options Bit
String, bits 7 and 8, in the paper "Data Owner Structure - Logical Nodes", p25
for the indicators that show if the standard and extended alert codes are
implemented.)
FUNCTION BLOCK ALERTS:

The standard alerts for all standard function blocks will have code numbers 0
- 2 plus 3CH - 3EH: they will be called "base function block alerts" and are
defined in Table 3.

284
Function block alerts 3-1CH will be defined for individual types of Standard
function blocks in Attachment 2. As normal, alerts 1DH - 1FH may be defined and
used by the manufacturer; for each of these three alerts that are used, the
associated variable that contains the visible string description will be
required. (Refer to the definition of the Data Dictionary variable FB in the
paper "Application Support Services Interface", p12 for the indicator of which of
these codes is implemented.)
DETAILS OF DATA BASE SUPPORT FOR ALERTS:

The following data base parameters were introduced above but this section
will provide much more detail on their design. Notice that all of these
parameters are defined for the first 32 alerts only. Similar parameters could be
--```,``-`-`,,`,,`,`,,`---
defined for alerts 20H to 3EH and, in fact, the parameter numbers have been
reserved in the paper "Array of Basic Parameters". In those cases where this
standard has defined alerts 3BH - 3EH, the alerts that have been assigned those
codes do not need any data base support.
Data Base Items for Each Node/Block Alert:
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
The following lists the data that will be provided in the static
data base for each of the first 32 alerts in a block or node:
1) a single bit showing the "unacknowledge" option (required).
The bits for each alert will be arranged in a 32 bit string,
called ALERT_UNACK_OPT, for each node or block in the order
defined in the alert lists. Alert 0 will be the low-order bit.
The definition of the option will be given below. These bits
will be initialized reset.
2) A 4 bit integer showing the priority of the alert (required).
The integers will be arranged into one 128 bit string, called
ALERT_PRIORITY, with the 4 bits for alert 0 at the low order
position. The meanings of the low order 3 bits (integer values
0-7) of each nibble are:
0 = no alert - do not set alert state - do not report - do
nothing.
1 = set alert status but do not report the alert (see page
9 for a definition of "report").
2 = default value for diagnostic alerts.
3-7 = alert priorities used by higher level device.
The fourth (high-order) bit of each nibble will be reset to
indicate that the alert is temporarily inhibited (alert is not
to be reported). Thus the 4-bit integer must have a value of >9
for the alert to be reported. However, the high order bit in
Alert 0 is used as a master switch for the reporting of all of
the block's alerts EXCEPT for Alert 0. The reporting of Alert 0
can not be inhibited.
The 4 bit priority will be initialized to 8 for all process

alerts and to AH for all system alerts. A "process" alert is an
alert that is caused, directly or indirectly, by a valid
measurement from the physical inputs of Field Devices. A
"system" alert is one that is reporting on an event that is
caused by the Field device itself. Messages will be considered
"process" alerts.
The following is the data that will be provided in the Field Bus
readable dynamic data base for each of the first 32 alerts supported by
a node or block:
1) a single bit showing the status of the alert at the last execution of
the node or block (required) (read-only).
The bits for each alert will be arranged in two 16 bit strings,

285
called ALERT_SET0 and ALERT_SET1, for each node or block in the

order defined above; Alert 0 will be the low order bit of the
first string and alert 10H will be the low order bit of the
second string. This data arrangement will allow a function
block agent to access all of the alert states. These bits will
be initialized reset.
This bit will be set for one cycle for alerts that are
notifications. These bits will always reflect the true current
state of any alert independent of any alert service flow
control states.
2) a single bit called the "unacknowledged" bit (required) (read/write
Field Bus access).
This bit will be set when an alert is detected AND reported. It
will be reset by the node or block when (there is no ALARM state
AND the alarm has been reported AND the option bit above is
set). It will be reset by the node or block 1 cycle later IF
(it is a notification AND it has been reported AND the
unacknowledged option bit is set). This bit is never reset by
the node or block if the option bit is reset.
This bit is intended to be used by higher level devices that

support a system-wide acknowledgement function. The bits for
each alert will be arranged in two 16 bit strings, called
ALERT_UNACK0 and ALERT_UNACK1, for each node or block in the
order defined above; Alert 0 will be the low order bit of the
first string and alert 10H will be the low order bit of the
second string. These bits will be initialized reset.
3) a single bit called the "unreported" bit [required if this logical
(or physical) node supports alert reporting] (read only Field Bus
access).
This bit will be set when an alert with a priority above 9 is
detected but can not be reported. It will be reset by the node
or block when the alarm is reported. It will NOT be cleared if
the alarm returns.
This bit is intended to be available to higher level systems

that need to reconcile the fact that an alarm bit may be set but
the system never got an alert. The bits for each alert will be
arranged in two 16 bit strings, called ALERT_UNRPT0 and
ALERT_UNRPT1, for each node or block in the order defined above;
Alert 0 will be the low order bit of the first string and alert
10H will be the low order bit of the second string. These bits
will be initialized reset.
In addition to the above data, other data may be defined by the

standard block functions and algorithms to support some of the alerts.
For example, the analog process alarms will have alarm settings and dead
bands.
Node/Block Alert Descriptors:

Three variables are defined in association with alerts 1DH-1FH in
each node or block. They must exist if the corresponding alert is
supported by the device. Each variable will contain a visible string up
to 32 characters long. They will be labeled "ALERT_DESC0",
"ALERT_DESC1", and "ALERT_DESC2", will be read/write accessible from
Field Bus, and will be stored in the static data base. These variables
offer the ability for the manufacturer to provide three labeled alerts
that are not otherwise supported in the Standard.
The number of these strings that are supported, 0 to 3, is given in

the PN/LN/FB variables in the Application Support Services Interface
paper, pages 9-12. If 1 label is supported, it will be for alert
number 1DH; two will imply alerts 1DH and 1EH.

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
286
In a totally analogous manor, the first 16 alerts in the range

20H-3FH can be labeled with "ALERT_DESC3" (alert 20H) - "ALERT_DESC18"
(alert 2FH). They also must exist if the corresponding extended alert
is supported by the device. The PN/LN/FB variables also indicate the
presence of these alerts. These alerts can only be supported if the
options bit string for the node or block indicate that "extended alert
--```,``-`-`,,`,,`,`,,`---
reporting" is supported.
When these alert codes are used, there is no mechanism to label the
subcodes. However, there is a method of identifying which are alarms
and which are notifications. If the subcode is between 0 and 0FH, it
will be an alarm; if it is above 0FH, it is a notification. Also,
subcodes 0EH and 0FH will have the same meaning for these alert codes as
the meanings of subcodes 1EH and 1FH given above. Thus, the two
standard subcodes are available for both alarms and notifications.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Report Change Indicator:

Each node and block is modeled as having an integer, not accessible
from Field Bus, called REPORT_CHG. It is modeled as being set by the
Data Base Write Service (DBWS) (see the paper by the same name). Any
time that the DBWS changes one or more of:
- a node or block's tag name
- a node or block's ASK
- a node or block's BASK
- a node or block's alert priority string
then the DBWS is modeled as setting REPORT_CHG = 3. In addition, the
DBWS will, under the same conditions and at the same time, issue an
alert for the node or block (using the OLD tag name if it was just
changed), alert code 3EH. The service will be designed such that the
alert is sent by the physical node before the Directory or Data
Dictionary data is changed to reflect the new data. This example of the
use of REPORT_CHG assumes that the value of REPORT_CHG is decremented to
2 when the alert is successfully released onto Field Bus.
When REPORT_CHG = 2, the physical node will update the Directory or

Data Dictionary data. When that change is completed and distributed on
Field Bus, the physical node will decrement REPORT_CHG to 1.
While REPORT_CHG is > 1, no alerts will be issued by the node or

block that was changed. See the description in the "Higher Level Device
Alert Servicing" section later in this paper for a description of how
REPORT_CHG is modeled as being used by the node/block alert servicing
logic and finally changed to 0.
ALERT REPORT RECORD:

Each alert will result in a report that will be passed to the Application
Layer for reporting to other Field Bus devices. The Application Layer will
require an "Alert Type" along with the report. The Standard User Layer has been
assigned the first 64 alert types. They all indicate a fixed record length of 7
bytes plus the one byte type code.
The "Alert Type" that will be passed to the Application Layer will be the
alert number (i.e., the code numbers in the listing of alerts given in Tables 1-3
and Attachments 1 and 2).
The report will have the following 7 byte format:

1) the internal tag identification (2 bytes)
These two bytes will carry the INTERNAL designation of the
tag in which the alert originated. The designation will be

287
converted to a visible string by the receiving nodes.

The format will be defined by the lower communication layers.
2) The alert code byte:
Bits 4-0: the alert subcode.
Bits 7-5: the low 3 bits of the alarm priority.
3) the time double word (32 bits):
Bits 0 - 1CH : bits 4-20H of NODE_TIME will be moved into bits
0-1CH of this double word (this will give time with
a precision of 1/2 millisecond and a total of 3.1
days till rollover).
Bit 1DH : Set = transition into the alarm state (or
notification).
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Reset = report of the transition out of the alarm

state (never used for notifications).
Bit 1EH : Set if OVER_CTR <> 0 (see below for definition).
Bit 1FH : Set if the alert could not be immediately reported
because of an overload of the alert system.
Note that it is assumed that the higher level device has direct access to the
following information:
1) translation of the internal to external tag name (from its own
Application Layer Directory, see paper "Application Support
Service Interface", Attachment 1 - "User Layer Support Services").
2) TO_TYPE and TO_SUB_TYPE (i.e., node type or block algorithm number)
(from its own Data Dictionary).
3) ASK and BASK for the reported tag (from its own Data Dictionary).
4) definition of the alert number (as a function of node/block type, and
block algorithm) (for all alerts defined in the Standard).
5) NODE_TIME_OFFSET for each physical node (reported upon change by the
clock service - see the paper "Data Owner Structure - Hardware").
The alert service will NOT generate an alert report in the following
situations:
1) If the alert is NOT Alert 0 and the alert priority is less than AH.
2) If the alert is NOT Alert 0 AND the node's/block's alerts are
temporarily inhibited (high bit of Alert 0's priority reset).
3) If the alert is Alert 0 and the low 3 bits of the alert priority has
a value less than 2.
4) If an alert is defined as a "notification" as opposed to an "alarm",
there is no such event as the "return" of the alert.
5) If an alert is the low priority of a dual alert (see next Section).
PHYSICAL NODE FUNCTIONS:

The physical node will provide three services to assist in alert service. It
will maintain a variable to define the minimum exposure time for each alert, it
--```,``-`-`,,`,,`,`,,`---
will issue an alert if there have been no alerts for 3 days, and it will maintain
a non-field bus accessible variable that indicates an alert reporting overload.
Minimum Alert Exposure Time:

The User Layer will deliver a record to the Application Layer for
each instance of an alert. The Application Layer will hold that record
in a buffer while it reports it. A higher level device has the ability
to request a particular alert report if it finds that it missed a
specific alert number.
To make this mechanism useful, the record must be held in the

buffer for some known minimum amount of time. However, if that time is
too long, the alert records will have a higher probability of backing up
into the "overflow" handling to be defined below. The minimum residence
time is thus a "tuning" parameter of the system. It will be User

288
entered as the integer "EXPOSE" (see the paper "Array of Basic

Parameters" paper for the definition of "EXPOSE").
The 32 bit value stored in EXPOSE will be shifted left 8 binary
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
places and used as the time in 1/32 of a milliseconds. This gives
EXPOSE a range of 8 milliseconds to 397 days.
No-Alert Alert:
The time stamp for alerts will roll over after 3.1 days.
Therefore, there will be a service in the physical node executive that
will keep the time since the last alert was reported. After exactly
3*24 hours, it will issue a code 3BH physical node alert.
Buffer Overload Indicator:

Each physical node that contains 1 or more logical nodes that
support alert reporting will support a buffer overload indicator. It
can be implemented in any way but its functionality must match the model
presented here.
It is modeled as having a simple counter associated with it, the

"overload counter" (OVER_CTR) (dynamic data base, not accessible from
Field Bus, for model definition only). The counter would be initialized
to zero. When the Application Layer alert reporting service is
overloaded (a new alert can not be passed to the Application Layer
service because the oldest record has not been exposed long enough) the
integer would be set to 2. Its use will be described immediately.
There would be a physical node service that would inspect the

integer on a specific time cycle. The time cycle is based on the
maximum value of "AX" found in the physical node and all of its logical
nodes that support alert reporting. The cycle time itself will be 2**AX
seconds. See the paper "Data Owner Structure - Hardware", page 11 for
a description of the variable AX.
At each "AX cycle", if the value of the integer is 1, it would be

decremented to 0. If it is 2, it would be decremented to 1. Bit 1EH in
the time word in all alerts will be set to 0 if the counter is zero,
ELSE it will be set to 1. Thus, bit 1EH is set as soon as an overload
condition is encountered and reset after a full cycle of no overload.
An analysis of the alert records obtained by higher level devices can
differentiate between 1) multiple bursts of alarms separated by a period
of time in which the unreported alerts all cleared and 2) a single
burst.
ALERT SUPPRESSION: --```,``-`-`,,`,,`,`,,`---
Three basic actions are necessary when an alert occurs. They are:
1) set status bit (for 1 cycle for notifications, till return for
alarms).
2) set unacknowledged bit.
3) generate the alert record and pass it to the Application Layer Alert
Service.
This paper will refer to action 3 as "reporting". There are certain situations
in which reporting will NOT occur. This is done to avoid unnecessary alerts to
the operator. These situations will be referred to as "dual" alerts - they are:
1) If a "Function Block Failure" (function block alert code 00) is set,

289
a "Function Block operation warning" (function block alert code 01)

will not be reported.
2) The block variables will frequently incur a "Bad" status at the same
time as a "No-Com" status. This will happen because of the pointer
option to set "Bad" automatically when a "No-Com" status is found.
Most alarms for No-Com/Bad cover both cases and use a detail code to
distinguish between them. For those cases where separate No-Com and
Bad alarms are provided, only the higher priority of the two (or the
"Bad" if they are equal) will be reported. If both alarms are
cleared at the same time, again only the higher priority one will be
reported. If they clear at different times, they will both be
reported. A higher-level device must be prepared for the clearing of
alarms "that never occurred".
3) When a PV "Bad" alarm occurs or exists, none of the other PV Function
alarms will be reported except "Target Bad". If the PV pointer
points to a block Input Word, Output Word, or the Setpoint, the value
pointed to will not be reported as Bad.
4) When a HIHI alarm occurs before or at the same time as a HI alarm for
a single PV, the HI alarm will not be reported IF its priority is
equal to or lower than that of the HIHI alarm.
5) When a LOLO alarm occurs before or at the same time as a LO alarm for
a single PV, the LO alarm will not be reported IF its priority is
equal to or lower than that of the LOLO alarm.
6) When the PV Target is "Bad", the Deviation alarm and the "PV <>
Target" alarm will not be reported.
7) If the PV Deviation alarm occurs at the same time or after a HIHI,
HI, LO, or LOLO alarm of the same or higher priority, the Deviation
alarm will not be reported.
8) When a Setpoint "Bad" alarm occurs or exists, a Setpoint HI or
Setpoint LO alarm will not be reported.
9) When an Output Word 0 "Bad" alarm occurs or exists, an Output HI
Limit or Output LO Limit alarm will not be reported.
10) If the discrete PV alarm for a particular bit set or reset occurs at
the same time or after a "PV - no bits set or more than 1 bit set"
alarm of the same or higher priority, the bit set or reset alarm will
not be reported.
11) If the discrete PV alarm "Change in the PV" occurs at the same time
or after a "PV - no bits set or more than 1 bit set" alarm of the
same or higher priority, the "Change in the PV" alarm will not be
reported.
12) If the discrete PV alarm "Change in the PV" occurs at the same time
or after an alarm for a particular bit set or reset of the same or
higher priority, the "Change in the PV" alarm will not be reported.
HARDWARE I/O FAILURE ALERTS:

Without adequate alert suppression, it is possible that the failure of just
one hardware connection could result in the following alerts:
- physical node alert of hardware failure
- function block alert of "Failure" of hardware connection word.
- function block alert of "Failure" of the block I/O word
calculated from the value of the hardware connection.
- function block alert for a "BAD" PV.
- function block alert for a "BAD" TARGET.
--```,``-`-`,,`,,`,`,,`---
- function block alerts of "BAD" value of each of the auxiliary

outputs whose values are obtained from the same hardware.
Without suppression, a physical device with multiple hardware points could
generate multiple sets of these alerts, flooding the alert system.
There will probably be failure modes in field devices in which multiple I/O
connections fail but the physical node itself can still communicate on Field Bus.
There are conflicting requirements on the alert reporting of such failures:
- It is undesirable for a failure report to be blocked by a prior
failure.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
290
- It is undesirable for the device to issue multiple alerts for a

single failure.
- There must be some mechanism that prevents a large number of alerts
from flooding the Field Bus, the higher level system, and/or the human
operator.
The alert system will inspect the priority of each "BAD" or "FAILURE" alert
that is generated in a single execution of a function block with a hardware I/O
connection. If a physical node alert is generated as part of the servicing of a
hardware connection, the physical node and function block alerts will be combined
for purposes of suppression. Only the highest priority alert (with a priority
>9) will be issued; the other alerts in the same execution cycle will be
suppressed (not stored and issued later). Their alarm bits will be set BUT NOT
--```,``-`-`,,`,,`,`,,`---
the unacknowledged bit. If there are two or more alerts with the same priority,
the following rules will be used to break the tie:
- a FAILURE is superior to "Bad".
- the alert for the connection to the hardware is superior
- the alert for the PV is the next lower prefered.
- the alert for the parameter that is the default value of
the PV is the third preference.
- the alert for the auxiliary outputs are the next lower
preference. Each I/O function block will define the subranking.
- the alert for any other parameter except the TARGET are next.
- the lowest preference will be the TARGET parameter.
All further references to "new alerts" in this section will refer to the highest
priority alert.
It is the intent, but not a requirement of the standard, that primary

detector diagnostics such as "open thermocouple" be distinguished from physical
node failures and be alarmed only through the function block.
The rest of this section will define a model of the operation of one aspect
of the alert system in a PHYSICAL NODE that has more than ONE hardware connection
of one type or more than THREE connections in total. It is not necessary that
the actual mechanism employed in the hardware be implemented according to the
model to be described. It is necessary that it APPEAR to implement the model -
that its Field Bus response be the same as the response that would be obtained
from the model.
The basic function of the following model is to:

- trigger into action when a hardware connection failure (or
return) is reported.
- monitor all subsequent alert reports for a certain period of
time.
- if there are additional alerts, block the individual alert and
substitute, for the first one, a "multiple points" alert.
- retire at the end of the time period.
- provide a method of reporting a hardware failure even though
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
there is an existing failure alarm state.
+ Calculation of the time period:

The time period will be based on the value of "AX" in each of the
logical nodes and the physical node. It will be determined using the
follow logic:
x = physical node "AX" (see page 13 of the paper "Data
Owner Structure - Hardware").
y(i) = the "AX" of logical node "i"
LN_OOS(i) = the LN_OOS logical for logical node "i" (see page 2
of the paper "Data Owner Structure - Logical Nodes").
y = Maximum [ y(i) for which LN_OOS(i) <> True ]
IF x < y, then
x = y

291
IF x > 8, then
x = 8
IF x < 2, then
x = 2
TIME = 2**z seconds.

where: (x-1) < z <= x
Careful inspection will reveal that there will always be a valid

time that is an even multiple of the "AX" of one of the operating
nodes.
+ Alert suppression logicals:

The model of the alert suppression procedure uses two sets of three
logicals each. (None of these variables is visible from Field Bus.) For
the failure alerts, there are FLAG1F, FLAG2F, and FLAG_MF; for the
return alerts, there are FLAG1R, FLAG2R, and FLAG_MR. They are all
initialized to reset. When there is a failure, FLAG1x is set. On a
cyclic basis, the set flag is moved to FLAG2x, then is discarded. If
either of them is set, a report of a subsequent alert will be suppressed
but a special alert indicating multiple failures will be sent
(conditionally), and FLAG_Mx is set. A third failure within the time
period will be totally suppressed. The same functionality can be
achieved with a timer and a single flag.
+ Recognition of events
The physical node must be capable of recognizing a new failure or
recovery of each of its physical connections. If it has more than one
hardware point of a type, it can not do this using the alarm state of
the appropriate alarm because the alarm serves more than one hardware
point.
--```,``-`-`,,`,,`,`,,`---
+ Alert suppression procedure for failures (x=F):

- FLAG1F and FLAG2F initialized to reset.
- once each time period (time as define above):
FLAG2F = FLAG1F
FLAG1F = reset
IF both FLAG1F and FLAG2F = reset, then
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
reset FLAG_MF
- When any physical node alert that concerns the failure of a
specific hardware I/O point (i.e., codes AH - 17H) is newly
generated, the logic of Figure 1 will be executed.
- When any function block alert that concerns the failure of a
specific hardware I/O point is newly generated, the logic of
Figure 1 will also be executed. The "base" alert of Figure 1
will be the survivor of the function block's suppression rules.
Note that the "alert 39H" is a physical node alert while the
"base" alert is a function block alert.
+ Alert suppression procedure for recoveries from failures

(x=R):
The triad of logicals for the return alerts will operate separately
but in the analogous way. The unacknowledged alert bits will be reset
for each point at the time it recovers depending on the state of the
user's option. The alarm bit(s) will always be reset for any recovered
point. The physical node alert code 3AH will be used for the "multiple

292
--```,``-`-`,,`,,`,`,,`---
returns" alert.
- When any physical node alert that concerns the return from
failure of a specific hardware I/O point (i.e., the "return" of
code AH - 17H) is generated, logic equivalent to Figure 1 will
be executed. The logic will, of course, be altered as necessary
for returns, and will use alert 3AH, not 39H.
- When any I/O function block alert that results from the return
from "Bad" or "FAILURE" of a specific hardware I/O connection is
generated, logic equivalent to Figure 1 will be executed. The
logic will, of course, be altered as necessary for returns instead
of initial alerts. Again, the "alert 3AH" is a physical node
alert while the "base" alert is a function block alert.
+ Method results:
When a hardware failure occurs after a period of normal operation,
the first failure is reported in the normal way. If there is a physical
hardware failure in a connection that has no function block, the
physical node will handle the alert. If a second failure occurs in the
time period, the second alert will not be reported but a special
"multiple failures" alert will replace it. The time period will depend
on the slowest node cycle time but will always be less than 8 minutes
and more than 4 seconds. Alerts for recovers will operate separately
but in the same fashion.
FIELD DEVICE ALERT SERVICE LOGIC:

This section of the paper will detail one possible implementation of the
alert service logic. The particular logic is for illustration only but the
resulting details of the handling of the Field Bus accessible parameters is
required if they are supported at all. This section will not include the case of
multiple hardware points detailed above.
All Cycles:
- IF processing the physical node, then
the OVER_CTR will be serviced as described above.
- IF processing a logical node, then
IF LN_OOS = TRUE, then
IF REPORT_CHG = 1, then
set REPORT_CHG = 0
set all alarm states = 0
set all unacknowledged bits = 0
DO NOT do any further processing of the alerts this cycle.
- IF processing a function block, then
IF the actual mode of the block = O/S, then
IF REPORT_CHG = 1, then
set REPORT_CHG = 0
set all alarm states = 0
set all unacknowledged bits = 0
DO NOT do any further processing of the alerts this cycle.
- IF REPORT_CHG > 0, then
set temp = 0
FOR x = 0 to 31
IF alert state bit for alert x = set, then
temp = 1
set unreported bit for alert x
NEXT x
IF OVER_CTR is set, then
IF REPORT_CHG > 1, then

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
293
IF temp = 1, then
OVER_CTR = 2
skip alert service for this node/block this cycle.
- IF (OVER_CTR is <> 0 OR REPORT_CHG = 1) then,
execute the logic given in the CASE "Cycle(s) After A 'Buffer
Blocked' Cycle".
ELSE
Do CASE "Normal".
CASE Normal:
If (a supported alert is a notification AND its state bit is set),
then
reset the state bit.
IF the unacknowledge option bit is set, then
reset its unacknowledge bit.
Any alert (alarm or notification) that is found active but whose state
bit is reset will be "worked". If more than one subcode of an alert
is active, they all can be worked at the same time.
For each new alert that is being worked, the state bit will be set if
the priority is not 0 or 8. The alert will be reported (once for each
subcode unless there is alert suppression) if the priority is greater
than 9 and reporting for this tag is not inhibited. Note that setting
the unacknowledged bit is included in the "reporting" action. Note
also that bits 1EH and 1FH in the time word of the alert record must
be reset in a "normal" report.
Any alarm that is found inactive but whose state bit is set will be
report as "returned". The subcode is never reported with a return.
If all of the alerts that need to be reported can be passed to the

Application Layer Alert Service, the alerts will have been reported in
the order in which the function blocks execute in the logical node(s)
with the physical node alerts reported as found. Once the Application
Layer is found unable to accept an alert report during the processing
of a function block, the User Layer will assume that it can not accept
any other reports FOR THAT ONE INDIVIDUAL FUNCTION BLOCK.
CASE Cycle In Which The Alert Service Is Blocked:

If there are alerts that can not be reported because the alert service
can not overwrite enough old reports, the servicing will be changed
for the blocked alerts. First, OVER_CTR is set to 2. The alert's
state bit will be set as above. However, the unacknowledge bit will
not be set but the "unreported" bit will be set for all alerts that
could not be reported. If an alert had multiple subcodes newly active
and not all of them could be reported, the ones that could be reported
--```,``-`-`,,`,,`,`,,`---
will be, then the unreported bit will be set on that node or block
alert.
For all subsequent alerts found in this physical or logical node (but
not in this function block), there will be an attempt to write the
alert reports to the Application Layer. They will all have bit 1EH in
the time word set because OVER_CTR is set.
At the beginning of the next cycle, OVER_CTR will be decremented to 1.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
294
CASE Cycle(s) After A "Buffer Blocked" cycle:

In the next cycle after an alert report was blocked, there will be one
or more unreported bits set and the overload counter will be set to 1.
When nodes or blocks with unreported bits are encountered, the
following logic will be executed before the regular logic:
1) If the Application Layer can still not accept an alert report,

the overload counter will be set to 2 and the "unreported" bits
will remain set. Note that:
- If the alert is a notification and there was a repeat of
it in the last cycle, THE FACT THAT THERE WERE 2
NOTIFICATIONS WILL BE LOST.
- If the alert is an alarm, the alarm may clear and return
several times while waiting for buffer room. Such a case
of MULTIPLE ALARM OCCURRENCES WOULD NOT BE REPORTED.
2) If the Application Layer can accept the alert record,
all alerts that have an unreported bit set will be reported.
All alarms that are still active will be reported with their
current subcodes; all other alerts will be reported with a
subcode of 1EH. The time reported will be as of the preparation
--```,``-`-`,,`,,`,`,,`---
of the report; bit 1FH of the time field in the report will be
set (of course, bit 1EH will also be set because OVER_CTR > 0).
Alarms will be reported as "new alarms" (i.e., bit 7 of the

alert description word will be set) if the alarm still exists, a
return (bit 7 reset) if it does not currently exist. The
unreported bit will be reset and the unacknowledged bit will be
set. Note that:
1) the subcode of all delayed notification reports and
some alarms will be lost (indicated by subcode 1EH).
2) an alarm may occur with one subcode, be unreportable,
change to a different subcode, then be reported with
that second subcode - the first one having been lost
(no indication).
3) the time stamp will be the time the report was passed
to the Application Layer, not the actual time of the
alert (indicated by bit 1FH).
4) any alert that is reported with the high bit of its
time field set may be out of time sequence in the alert
buffer but it will not be out of sequence in the alerts
reported for a function block (indicated by bit 1FH).
If all alerts that were initially unreported could be reported in this

cycle, OVER_CTR will be equal to 1 at the conclusion of the alert
processing for any one node/block. If it is equal to 1, then it will
be decremented to 0 and normal operation will resume. Otherwise,
OVER_CTR will have been set to 2 again. In that case, it will be
decremented to 1 at the beginning of the next cycle, and the "Cycle(s)
After A 'Buffer Blocked' Cycle" logic will repeat.
HIGHER LEVEL DEVICE ALERT SERVICING:

The alert service is set up in such a way that the User Layer of a higher-
level device only manipulates the configuration of the alerts in the nodes and
the blocks, and resets the unacknowledged bit for an alert.
The higher level device will interact with the Application Layer in its Field
Bus interface and receive the alerts when reported. The Field Bus interfaces of
the higher level devices will receive the sequence number assigned to each alert
by the Application Layer of the Field Device and will be able to request any

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
295
missed alerts from the Field Device as long as the missed alert is still in the
Alert Service buffer.
When there is a change in the static data that is critical to the reporting
of alerts, the Field Bus node serving a higher level device will receive an alert
--```,``-`-`,,`,,`,`,,`---
code 3EH with a priority of 0. It is assumed that that alert will be reported to
all higher level devices getting the ASK or BASK of that tag. If the alerts are
being sorted based on the use of priority 3 for system alarms, the priority of 0
will be a key indicator - the alert 3EH should go to both classes of consumers.
The higher level devices will know that the current alerts for that tag should be
canceled and that they will be repeated, if they still currently exist, using the
new static data.
It is anticipated that a higher level Operator Interface that is concerned

with alert monitoring will operate in the following fashion:
1) The Operator Interface may be configured to monitor a certain set of
"alert sort keys" (ASK's). One of these 4-character keys is
configured for each node and for each block in Standard Field Bus
devices. Other higher level devices may have an assigned set of
BASK's instead of ASK's but they would operate the same way.
2) The Operator Interface is assumed to have support from its own Field
Bus interface such that it can ask to receive all of the alert
records that involve the defined list of ASK's.
3) In addition, the Operator Interface may have the capability to
determine if any nodes or function blocks in the assigned list of
ASK's do not have an alert reporting service. This capability would
involve a laborious search of the Data Dictionary items available from
the Field Bus interface serving the Operator Interface. Note that
the presence of support for alert reporting and support for the base
and extended alert lists is indicated in the "PN", "LN" and "FB" Data
Dictionary parameters (see the paper "Application Support Services
Interface", page 9). Once the list of such tag names is determined,
the two bit strings, ALERT_SET0 and ALERT_SET1 from each such tag
will have to be scanned at an appropriate frequency if they are
supported.

//^:^^#^~^^"~
296
Table 1 Physical Node Alerts

The physical node alerts are:
0) Function block logic processor stopped (alarm).
Subcode: 00 - never started.
Note: when a Field Device that supports
alerts starts up, it will generate
a return of this alarm and subcode
unless the actual subcode is known.
01 - logic processor diagnostics failure.
02 - non-volatile system code parity violation.
03 - non-volatile system code failure (i.e., "check-sum"
or equivalent on system code).
04 - static data memory parity violation.
05 - static data memory "check-sum" or equivalent failure.
06 - static data memory diagnostic test failure (actual
diagnostic such as write and readback, not parity nor
"check-sum" nor equivalent).
07 - RAM memory parity violation.
08 - RAM memory "check-sum" or equivalent failure.
09 - RAM memory diagnostic test failure (actual diagnostic
such as write and readback, not parity nor "check-
sum" nor equivalent).
Note: if a memory failure (subcodes 2-9) is being
reported and the failure can be determined to be
localized to one logical node, then the failure
will be reported as a logical node failure, not a
physical node failure (even if there is only one
logical node in the physical node).
AH - internal watch-dog-timer expired.
BH - external watch-dog-timer expired.
CH - Physical node static data base revision number = 0
and SFailSafe set.
DH - 19H - reserved for future standardization.
1AH - 1DH - manufacturer specific.
1) Physical node data base validity notification.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Subcode: 00 - complete hot restart executed.
01 - all static data OK, timer 0 expired but not timer 1.
02 - all static data OK, timer 1 expired.
03 - complete loss of static data bases. (Suppresses
code 3EH).
04 - loss of physical node static data base but all
logical node and function block static data is OK.
(Suppresses code 3EH).
05 - loss of physical node and one or more logical node
static data bases but function blocks OK. (Suppresses
code 3EH).
06 - loss of physical node and one or more function block
static data bases but logical nodes OK. (Suppresses
code 3EH).
07 - configuration error fatal to the operation of the
physical node and all of its logical nodes.
08 - configuration error fatal to the operation of the
physical node but all logical nodes unaffected.
09 - 19H - reserved for future standardization.
2) Field Bus communication port failure (alarm).
Subcode: 00 - No response on the bus.
Note: when a physical node that supports a
clock first establishes a value for
NODE_SOCIAL_OFFSET, it will send a
RETURN of this alarm unless the
actual failure code is known.
01 - no response from Field Bus interface A.
02 - logic processor failure - Field Bus A.
03 - non-volatile system code parity violation - Field

--```,``-`-`,,`,,`,`,,`---

297
Bus A.
04 - non-volatile system code failure (i.e., "check-sum"
or equivalent failure) in Field Bus A.
05 - static data memory parity violation - Field bus A.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
06 - static data memory failure (i.e., "check-sum" or
equivalent failure) in Field Bus A.
07 - static data memory failure (actual diagnostic such as
write and readback, not parity nor "check-sum" nor
equivalent) in Field Bus A.
08 - RAM memory parity violation - Field bus A.
09 - RAM memory failure (i.e., "check-sum" or
equivalent failure) in Field Bus A.
AH - RAM memory failure (actual diagnostic such as write
and readback, not parity nor "check-sum" nor
equivalent) in Field Bus A.
BH - excessive message errors while on Field Bus A.
Note: for physical nodes with only one Field Bus
interface, use the codes for Field Bus interface A.
CH - no response from Field Bus interface B.
DH - logic processor failure - Field Bus B.
EH - non-volatile system code parity violation - Field
Bus B.
FH - non-volatile system code failure (i.e., "check-sum"
or equivalent failure) in Field Bus B.
10H - static data memory parity violation - Field bus B.
11H - static data memory failure (i.e., "check-sum" or
equivalent failure) in Field Bus B.
12H - static data memory failure (actual diagnostic such as
write and readback, not parity nor "check-sum" nor
equivalent) in Field Bus B.
13H - RAM memory parity violation - Field bus B.
14H - RAM memory failure (i.e., "check-sum" or
equivalent failure) in Field Bus B.
15H - RAM memory failure (actual diagnostic such as write
and readback, not parity nor "check-sum" nor
equivalent) in Field Bus B.
16H - excessive message errors while on Field Bus B.
17H - 1AH - reserved for future standardization.
1BH - 1DH - manufacturer specific.
3) Primary or "A" power supply lost (alarm).
Subcode: 00 - output power lost.
01 - 0FH = Reserved.
10H - low voltage (i.e., "gray out").
11H - high voltage.
12H - supply hot.
13H - supply cold.
14H - cooling fan lost.
15H - excessive electrical noise in output.
4) Primary or "A" power supply warning (alarm) (must be suppressed if
alert #3 is already set or if it is set at the same time).
Subcode: 00 - maintenance switch open.
01 - 0FH = Reserved.
(subcodes 10H+ the same as for code #3).
5) Back-up or "B" power supply lost (alarm).
Subcode: (subcodes the same as for code #3).
6) Back-up or "B" power supply warning (alarm) (must be suppressed if
--```,``-`-`,,`,,`,`,,`---
alert #5 is already set or if it is set at the same time).

Subcode: (subcodes the same as for code #4).
7) Battery back-up power supply alarm.
Subcode: 00 - on battery - battery voltage low.
01 - battery voltage reversed.
02 - 0F Reserved.
(subcodes 10H+ the same as for code #3).
8) Battery back-up power supply warning (alarm).
01 - reserved.
02 - charger power lost.

298
03 - low charge current.

04 - high charge current.
05 - not on battery - battery voltage low.
06 - battery voltage high.
07 - 0F Reserved.
(codes 10H+ the same as for code #3).
This alarm is intended to describe a situation in which the battery
back-up power is not currently being used but has a warning (not
yet fatal) condition.
9) Memory holding energy device failure (alarm).
01 - polarity reversed.
(subcodes 02+ the same as for code #8)
Note: this alarm is intended to be used for an energy source that
only serves as a back-up energy supply for device memory.
Since the device must have power to report this alarm, it
will only indicate the loss of back-up, not the immediate
loss of field device functionality.
AH) Node hardware failure - Communication Port (alarm).
Subcode = the number of the hardware identifier (1CH = "identifier
number 1CH or higher", 1DH = "all hardware of this type",
1EH and 1FH are reserved for their general meaning).
Note: it is assumed that this alert will normally be turned off
and the hardware failures reported through the associated
function blocks.
BH) Node hardware failure - Counter Input (alarm).
function blocks.
CH) Node hardware failure - Discrete Registers 0 - 1CH (alarm).
Subcode = the number of the hardware identifier (1DH = "all
Discrete Registers in this range", 1EH and 1FH are
reserved for their general meaning).
function blocks.
DH) Node hardware failure - Discrete Registers 1DH - 39H (alarm).
Subcode = the number of the hardware identifier - 1DH (1DH = "all
Discrete Registers in this range", 1EH and 1FH are
function blocks.
EH) Node hardware failure - Discrete Registers 3AH+ (alarm).
Subcode = the number of the hardware identifier - 3AH (1CH =
"identifier 56H or higher", 1DH = "all Discrete Registers
3AH and above", 1EH and 1FH are reserved for their
general meaning).
function blocks.
FH) Node hardware failure - Foreign Memory (alarm).
function blocks.
10H) Node hardware failure - Human Interface (alarm).

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
299
function blocks.
11H) Node hardware failure - Pulse Output (alarm).
function blocks.
12H) Node hardware failure - SI's 00 - 1CH (alarm).
Subcode = the number of the hardware identifier (1DH = "all Scalar
Inputs in this range", 1EH and 1FH are reserved for
their general meaning).
function blocks.
13H) Node hardware failure - SI's 1DH - 39H (alarm).
Subcode = the number of the hardware identifier - 1DH (1DH = "all
Scalar Inputs in this range", 1EH and 1FH are
function blocks.
14H) Node hardware failure - SI's 3AH+ (alarm).
Subcode = the number of the hardware identifier - 3AH (1CH =
"identifier 56H or higher", 1DH = "all Scalar Inputs 3AH
and above", 1EH and 1FH are reserved for their general
meaning).
function blocks.
15H) Node hardware failure - SO (alarm).
function blocks.
16H) Node hardware failure - VD (alarm).
function blocks.
17H) Node hardware failure - VS (alarm).
function blocks.
18H - 1AH) Reserved for future Standards definition.
1BH - 1CH) Available for manufacturer definition.
1DH - 1FH) Available for manufacturer definition and associated with
the three alert descriptor strings.
20H - 2FH) Available for manufacturer definition
30H - 38H) Reserved for future Standards definition.
39H) Multiple Hardware Failures (notification):
Subcode: 00 - physical node notification that more than one alert
has occurred in or related to physical hardware
failure during the time period.
3AH) Multiple Hardware Failure Returns (notification):
Subcode: 00 - physical node notification that more than one alert
has occurred in or related to return from physical
hardware failure during the time period.
3BH) No-Alert Alert (notification):
Subcode: 00 - physical node notification that 3 days have elapsed

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
300
since the last alert.

Note: this alert will have a priority of 3; it is assumed that
the higher level device would use the information but not
report it to the human interfaces. There is no need for
the acknowledgement bits nor the unreported bit. Thus
there is no data base needed for this alert.
Note: No other subcode can be used.
3CH) Clock Bias Change (notification):
Subcode: 00 - the physical node has recognized a change in the
NODE_SOCIAL_OFFSET value such that the current value
is different from the last reported value by more
than the change limit (OFFSET_DB - see the paper
"Data Owner Structure - Hardware", page 15).
Note: the "time" value that will be included in the record for this
alert will be based on the new value of NODE_SOCIAL_OFFSET.
--```,``-`-`,,`,,`,`,,`---
report it to the human interfaces (or even historize it?).
There is no need for the acknowledgement bits. The
unreported bit is not needed because the "LR_OFFSET"
(described in the paper "Data Owner Structure - Hardware",
page 15) can simply not be updated until the report is
accepted by the Application Layer. Thus there is no data
base needed for this alert.
3DH) Physical node static data base change (notification):
Subcode: 00 - physical node data base revision numbers changed -
both base data and Auto-Format variables.
01 - physical node static data base revision number
change - not Auto-Format variables.
02 - physical node auto-format variable data base change.
Note: this alert is NOT set when the auto-format
variables associated with a hardware instance
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
or a hardware type are changed. It is only

set for the hardware-independent auto-format
variables [PN_AF_x (i)].
There is no need for the acknowledgement bits. It is assumed
that the data base change is signaled by an internal flag
that can simply not be reset until the Application Layer will
accept the report. Thus there is no data base needed for
this alert.
3EH) Physical node alert report change (notification):
Subcode: 00 = Null
01 = (not used).
02 = ASK change.
04 = BASK change.
08 = Alert priority change.
all other codes 03 - FH) summation of codes 01 - 08 to
show multiple changes.
Note: this alert MUST be successfully transmitted before the change
takes place and before any more alerts are issued by this
node/block.
Note: this alert will be unique in that it will have a priority of
0; it is assumed that the higher level device would use the
information but not report it to the human interfaces. There
is no need for the acknowledgement bit. The REPORT_CHG
mechanism that is modeled in this paper substituted for the
unreported bit. Thus there is no data base needed for this
alert.
3FH) Reserved for coding system escape.

301
The discrete hardware will NOT set a hardware failure alert when less than
all bits in a multibit discrete register are detected as failed: all such
failures will be allowed to flow through to the control function using the data.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
--```,``-`-`,,`,,`,`,,`---

302
Table 2 Base Logical Node Alerts

The base logical node alerts are:
0) Logical node failure (Alarm):

Subcode: 00 - configuration error fatal to the operation of the
logical node and all of its function blocks (but NOT
logical node variable configuration).
01 - function blocks executed out of order (this alarm is
designed to support a simple sequence checking
procedure.)
02 - logical node's non-volatile system code parity
violation.
03 - logical node's non-volatile system code failure
(i.e., "check-sum" or equivalent on system code).
04 - logical node's static data memory parity violation.
05 - logical node's static data memory "check-sum" or
equivalent failure
06 - logical node's static data memory diagnostic test
failure (actual diagnostic such as write and
readback, not parity nor "check-sum" nor equivalent).
07 - logical node's RAM memory parity violation.
08 - logical node's RAM memory "check-sum" or equivalent
failure
09 - logical node's RAM memory diagnostic test failure
(actual diagnostic such as write and readback, not
parity nor "check-sum" nor equivalent).
Note: if a memory failure (subcodes 2-9) is detected in
two or more logical nodes at the same time, then
the failure will be reported as a physical node
failure, not as several logical node failures.
AH - violation of MBC due to the current values of PN.
(logical node LN_OOS set FALSE - alarm returns to
normal when LN_OOS <> FALSE AND this alarm set AND
MBC not violated).
BH - 19H - reserved for future standardization.
--```,``-`-`,,`,,`,`,,`---
1) Logical node static data base validity notification.
Subcode: 00 - not used.
01 - not used.
02 - not used.
03 - complete loss of static data bases for the logical
node and all of its function blocks. (Suppresses
code 3EH in the logical node and codes 2 and 3EH in
all function blocks in the logical node.
04 - not used.
05 - loss of logical node static data base but all function
block static data is OK. (Suppresses alert code 3EH).
06 - all logical node static data OK, all function block
static data lost. Suppresses alert codes 2 and 3EH
for all function blocks in the logical node.
2) Logical node configuration error (not fatal) (notification).
00 - entered CX < MX (MX used).
01 - entered CB > MBC (MBC used).
Note: this subcode will not be used when the set of
values for PN causes an excessive number of
blocks per cycle in one of the cycle/phase
type logical nodes.
03 - violation of MBC due to the current values of PN.
(node PH's adjusted to continue logical node
operation).
04 - Logical Node variable #0 configuration error - that

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
303
variable is not being serviced.

10H - Field Device has an operating schedule for
fetching one or more of its logical node variables
that violates the MAX_PREFETCH limit.
11H - 19H - reserved for future standardization.
3) Logical node Failsafe trigger (alarm).
Subcode: 00 - Failsafe driven from hardware inputs.
01 - Failsafe driven from an on logical node data base
write.
02 - Failsafe driven from a off logical node but on
physical node data base write.
03 - Failsafe driven from a off physical node data base
write.
04 - Failsafe hardware diagnostic fault.
05 - Failsafe hardware lost sense power.
--```,``-`-`,,`,,`,`,,`---
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
06 - Failsafe hardware bypass switch in effect.
4) - 1CH) See Attachment 1 - Logical Node Extensions
20H - 2FH) Available for manufacturer definition.
30H - 3BH) Reserved for future Standard definition.
3CH) Private Clock Bias Change (notification):
Subcode: 00 - the logical node has recognized a change in the
PRIVATE_OFFSET value such that the current value is
different from the last reported value by more than
than the change limit (P_OFFSET_DB - see the paper
"Data Owner Structure - Hardware", page 14).
Note: the "time" value that will be included in the record for this
alert will be based on the Field Bus system time.
There is no need for the acknowledgement bits. The
unreported bit is not needed because the "LR_BIAS" (described
in the paper "Data Owner Structure - Hardware", page 14) can
simply not be updated until the report is accepted by the
Application Layer. Thus there is no data base needed for
this alert.
Note: no other subcode can be used.
3DH) Logical node static data base change (notification).
Subcode: 00 - logical node static data base revision number change
- not Auto-Format variables.
01 - logical node auto-format variable data base change
Note: this alert is not sent when the auto-format
variables associated with hardware are changed.
It is only set for the LN_AF_x (i) variables.
02 - FAIL-SAFE bit 0 value change.
Note: this alert will have a priority of 3; it is assumed that the
higher level device would use the information but not report
it to the human interfaces (or even historize it?). There is
no need for the acknowledgement bits. It is assumed that the
data base change is signaled by an internal flag that can
simply not be reset until the Application Layer will accept
the report. Thus there is no data base needed for this alert.

304

3EH) Logical node alert report change (notification):
Subcode: 00 = Null
01 = Tag name change (Note: alert is under the old name)
02 = ASK change.
04 = BASK change.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
node/block.
alert.

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
305
Table 3 Base Function Block Node Alerts

The base function block alerts are:
0 1 2 x 1DH-1FH 20H-2FH 30H-3AH 3CH 3DH 3EH 3FH
0) Function Block Configuration Error - Forced to O/S (Alarm):

Subcode: 00 - loss of all function block static data. (Suppresses
alert code 3EH.)
01 - loss of the function block static data BUT NOT the
auto-format variables. (Suppresses alert code 3FH.)
02 - loss of the function block auto-formatted data only.
03- TO_TYPE/TO_TYPE1 not supported.
04 - Invalid pointer - Input 0 agent.
05 - Invalid pointer - Input 1 agent.
06 - Invalid pointer - Input 2 or 3 agent.
09 - Invalid pointer - Output 0 agent.
0AH - Invalid pointer - Output 1 agent.
0BH - Invalid pointer - Output 2 agent.
0CH - Invalid pointer - Output 3 agent.
0DH - Invalid pointer - Output 4 or 5 agent.
0EH - Invalid pointer - Output 6 or 7 agent.
0FH - Invalid pointer - Setpoint Bit #0.
10H - Invalid pointer - Setpoint Bit #1.
11H - Invalid pointer - Setpoint Bit #2.
12H - Invalid pointer - PV Bit #0 or analog value.
13H - Invalid pointer - PV Bit #1.
14H - Invalid pointer - PV Bit #2.
15H - Invalid pointer - Target Bit #0 or analog value.
16H - Invalid pointer - Target Bit #1.
17H - Invalid pointer - Target Bit #2.
18H - Invalid pointer - Boolean Operators 0 - 3
19H - Invalid pointer - Boolean Operators 4 - 7
1AH - Invalid pointer - Output bits 0 - 3
1BH - Invalid pointer - Output bits 4 - 7
1CH - Invalid pointer - algorithm parameters
1DH - Manufacturer specific
Note: this alert would typically be given a relatively high

priority.
--```,``-`-`,,`,,`,`,,`---
Note: a return from one of the above alarms will be generated

when the block mode transitions out of O/S AND this alarm
is set AND the configuration is valid.
1) Function Block operation warning (Notification):

Subcode: 00 - O/S forced due to lost hardware data.
01 - O/S forced by algorithm.
02 - O/S in effect when LO set by key.
03 - LO mode forced by algorithm.
04 - LO mode forced by CASCADE feedback.
05 - LO mode forced by local keylock.
06 - Man mode forced by a failure.
07 - Man mode forced by algorithm.
08 - Man mode forced by Bad INPUT0.
09 - Man mode forced by Bad INPUT1.
AH - Man mode forced by Bad INPUT2.
BH - Auto mode forced by Bad INPUT0.
CH - Auto mode forced by Bad INPUT1.
DH - Auto mode forced by Bad INPUT2.
EH - Auto mode forced by failure.
FH - Auto mode forced by algorithm.
10H - Cas mode forced by algorithm.
11H - Illegal requested mode discovered at algorithm
execution time - requested mode reset to actual.

306
12H - Failure in Output path.

13H - One of two analog cascade paths failed - no mode
change yet. Note - analog cascades only.
14H - One of cascade bits failed - no mode change
yet. Note - discrete cascades only.
15H - Field Device has an operating schedule for
fetching one or more of this function block's
variables that violates the MAX_PREFETCH limit.
16H - existing ACQUIROR killed by complex write.
17- 1AH - reserved for future standardization.
1BH - 1DH - manufacturer specific.
Note: this alert would typically be given a medium priority.
2) Function Block Message (Acknowledgement required) (alarm):
Subcode: 00 - 1DH available as a pointer to the 32 bit
visible string variables MESSAGE00 through MESSAGE29
link dest1 link dest2 link dest3 link dest4

20H - 2FH) Available for manufacturer definition.
30H - 3BH) Reserved for future Standard definition.
3CH) Function Block Message (no Acknowledgement required) (notification):
Subcode: 00 - 1DH available as a pointer to the 32 bit
visible string variables MESSAGE00 through MESSAGE29
Note: this alert will make special use of bit 7 in the alert
description: if set, the message is followed by another
message and the next message is to be concatenated with this
one for display purposes.
Note: the alert priority of this alert is assumed to be set by the
--```,``-`-`,,`,,`,`,,`---
function block that generated the message. There is no

acknowledgement support needed. The function block that
originated the message is assumed to be able to retry to send
the alert report if the Application Layer is unable to accept
the alert record - thus the unreported bit is not needed and
therefore no data base is needed to support this alert.
Note: no other subcodes are allowed.
3DH) Function Block notification:
Subcode: 00 - Function block Static data base revision number change
- not Auto-Format variables.
01 - Function block Auto-Format variable change.
Note: this alert is NOT sent when an auto-format
variable associated with hardware is changed.
It is only set for the FB_AF (i) variables.
02 - Requested mode change.
03 - all alarms cleared by O/S mode.
Note: this alert will have a priority of 3; it is assumed that the
higher level device would use the information but not report
it to the human interfaces (or even historize it?). There is
no need for the acknowledgement bits. It is assumed that the
data base change is signalled by an internal flag that can
simply not be reset until the Application Layer will accept
the report. Thus there is no data base needed for this alert.
3EH) Function Block alert report change (notification):
Subcode: 00 = Null
01 = Tag name change (Note: alert is under the old name)
02 = ASK change.
04 = BASK change.
node/block.

//^:
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
307

alert.
--```,``-`-`,,`,,`,`,,`---

308
Figure 1
MULTIPLE HARDWARE FAILURE SUPPRESSION

Physical Hardware "Failure
Or Start Source "Base"
L/O Function Block "Bad" Alert = Alert
Or "Failure"
Yes Yes Alert Yes Base No

FLAG1F
OR 39H Alert
FLAG2F Priority Priority
Set? >0? >0?
Set Base No No
Alert Base Set Base
No
Status Alert Alert Status.
Bit. Status
Set?
Yes Base No
No Yes Alert
Set 39H Alert
Priority
Alert 39H
FLAG_MF No >9?
Status Priority
Set?
>0? Yes
Report Base Alert:

Yes
Set its Inack. Bit
Yes
Alert Set FLAG1F
39H
Priority>9? Report alert 39H;
Set FLAG1F; Set
No FLAG MF
END
Figure 34: Alert Figure 1, Multiple Hardware Failure Suppression
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

--```,``-`-`,,`,,`,`,,`---

309
Attach. 1 Logical Node Alert Extensions
The following is the table of the alerts that are to be added to the logical
node alert list for each of the specific node types:
UNDEFINED LOGICAL NODES:

05-1CH) as defined by the manufacturer.
UNSCHEDULED, MULTISTREAM/MULTICOMPONENT, AND

PROPERTY SCANNER LOGICAL NODES:
--```,``-`-`,,`,,`,`,,`---
05) Configuration Violation (Notification).
Subcode:
for Unscheduled logical nodes -
0AH - 1CH - manufacturer specific.
for other types of unscheduled logical nodes -
see the detailed definition of the specific logical node.
06) Node disabled (Alarm).
Subcode:
for Unscheduled logical nodes -
0AH - 1CH - manufacturer specific.
for other types of unscheduled logical nodes -

00 - External Disable
01 - 1CH - see the detailed definition of the specific logical
node.
For Unscheduled Logical Nodes:
07 - 10H - reserved for future standardization
11 - 1CH - manufacturer specific
For other types of Unscheduled logical nodes:
07 - 1CH - see the detailed definition of the specific logical
node.
CYCLE/PHASE AND CYCLE/PHASE STANDARD LOGICAL NODES:

05 - 19H) Reserved for future Standard definition.
1AH - 1CH) Available for manufacturer definition.
TIMED STANDARD, CYCLE STANDARD, AND CYCLIC LOGICAL

NODES:
05 - 19H) Reserved for future Standard definition.
1AH - 1CH) Available for manufacturer definition.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
310
Attach. 2: Function Block Extensions For Specific

Block Types
The attached Table identifies the alerts that are defined for each of the
Standard Function Blocks. The following list expands the definitions of each of
the alerts; it is in the same order as the rows in the Table.
a) LO Mode set by the block's algorithm (Alarm).

This alarm is set any time the LO mode bit in the actual mode
is set by the algorithm itself, as opposed to being set by the
requested mode. This does NOT include the situations in which
the LO mode bit in the actual mode is set because the LO mode
is passed up a cascade to the block.
b) Man/Auto Mode set by the block's algorithm (Alarm).
This alarm is set any time the Man or Auto mode bit in the
actual mode is set by the algorithm itself, as opposed to being
set by the requested mode.
Detail code: 00 - no detail code.
01 - Man mode set.
02 - Auto mode set.
c) Bypass set by the block's algorithm (Alarm).
This alarm is set any time the Bypass option is automatically
set by the algorithm itself, as opposed to being set by a write
--```,``-`-`,,`,,`,`,,`---
from Field Bus.
d) Keylock set while block mode = O/S (Alarm).
This alarm can only be set by output blocks that support a
hardware keylock.
e) Block Calculation Error (Alarm).
Any time a block encounters an Overflow in its process value
calculations, it will set this alarm. The alarm will be reset
when the block calculations in any one cycle do not encounter
an overflow condition.
f) Block Initialization Tolerance Error (Notification).
This alarm is used, for example, by the Math block when
initialization causes division by a number that is smaller than
the tolerance set by the user.
g) PV "Bad" (Alarm).
In a discrete block that supports this alarm, it is only set
when all of the PV bits are "Bad".
h) PV HIHI (Alarm).
This alarm is only used by analog blocks.
i) PV HI (Alarm).
Note that this alarm and the next one will be repeated in the
Alert buffer according to the rules of the alarm repeat
function defined in the paper "Standard Block Functions". This
alarm is only used by analog blocks.
j) PV LO (Alarm).
k) PV LOLO (Alarm).
l) PV Deviation (Alarm).
01 - Lo Deviation.
02 - Hi Deviation.
m) PV Target "Bad" (Alarm).
01 - analog value bad or all bits bad.
02 - 1 bit bad (used in discrete blocks only).
03 - 2 bits bad (used in discrete blocks only).
04 - no bits set (used in discrete blocks only).

311
05 - more than 1 bit set (used in discrete blocks

only) .
n) PV "Bad" (Alarm).
01 - 1 or more bits bad.
02 - no bits set.
03 - more than 1 bit set.
This alarm is only used by discrete blocks.
o) PV bit 0 (Alarm).
01 - bad.
02 - bit set.
03 - bit reset.
p) PV bit #1 (Alarm).
01 - bad.
02 - bit set.
03 - bit reset.
q) PV bit #2 (Alarm).
01 - bad.
02 - bit set.
03 - bit reset.
r) Change in the PV (Notification).
s) PV <> Target (Alarm).
t) Bit pointer (but not a Boolean function input bit pointer nor an
Output bit pointer) bit "Bad" (Alarm).
u) Boolean Bit Pointer "Bad" (Alarm).
v) Output Bit Pointer "Bad" (Alarm).
w) I/O hardware failed (Alarm).
01 - Input detector failed.
02 - Input amplifier failed.
03 - General Input Failure.
04 - Output driver failed.
05 - Output servo failed.
06 - General output failure.
07 - Feedback failed - critical to operation.
This Alarm is intended to be used to indicate a hard failure of
the device that prevents operation. It is not to be used for
failures of "secondary" inputs that are not critical to the
operation of the primary objective of the block.
x) Output feedback check failed (Alarm).
This Alarm is intended to be used to indicate a failure of the
check feedback to match the desired output where there is now
uncertainty as to which is wrong - the output or the check -
operation is continuing.
y) Diagnostic Screen 0 Warning (Alarm).
This Alarm, together with the next three alarms, are intended
to be used in conjunction with the screen definition technique
presented in the Human Interface paper.
z) Diagnostic Screen #1 Warning (Alarm).
aa) Diagnostic Screen #2 Warning (Alarm).
ab) Diagnostic Screen #3 Warning (Alarm).
ac) Packing/Seal Warning (Alarm).
This Alarm is intended to be used for any measurement that is
provided as a direct or indirect measurement of excessive
leakage in a seal, a valve stem packing, a valve stem bellows,
or the like.
ad) Cavitation/Noise Warning (Alarm).
This Alarm is intended to be used for any measurement that is
provided as a direct or indirect measurement of cavitation in a

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
312
valve or pump.
ae) Low Driver Power Warning (Alarm).
This Alarm is intended to be used to indicate that the primary
motivating power of the output device is below its normal
level. For example, the instrument air pressure supplied to an
air-driven valve is below its normal pressure.
af) Driver Saturated (Alarm).
This Alarm is intended to be used to indicate that the output
driver is "full on" or "full off" but still can not drive the
output such that the feedback matches the desired output.
ag) Hardware Override (Alarm).
This Alarm is intended to be used to indicate that an external
signal has taken control of the hardware. For example, this
would be the Alarm used to indicate that an external signal
from a safety system has taken control of the output.
ah) I/O signal path failed (Alarm).
This Alarm is intended to be used to indicate a failure
external to the field bus device itself.
ai) One or more discrete signals grounded but still operable (Alarm).
aj) One or more discrete signals shorted (Alarm).
ak) One or more discrete signals open (Alarm).
al) One or more discrete signals have dirty contacts (Alarm).
am) One or more discrete signals integrity bad (Alarm).
Note: this alarm is not intended to be used in cases where one
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
of the previous 4 alarms is appropriate.
ia) Input 0 quality (Alarm).
01 - No-Com, but "Good".
02 - Bad.
ib) Input #1 quality (Alarm).
02 - Bad.
ic) Input #1 Not-From-Process (Alarm).
id) Input #2 quality (Alarm).
02 - Bad.
ie) Input #3 quality (Alarm).
02 - Bad.
if) Input #4 quality (Alarm).
02 - Bad.
ig) Input #5 quality (Alarm).
02 - Bad.
ih) Setpoint Limit (Alarm).
01 - LO Limit.
02 - HI Limit.
ii) Setpoint Ramp Turned Off (notification)
01 - Output Failed
02 - LO mode set
03 - No path to process
04 - IMan set
05 - Change to non-Auto mode (none of above)
05 - Input #1 Bad
06 - Input #1 not from process
07 - Target outside of Setpoint Limits
ij) Input #2 or higher "No-Com" (Alarm).
ik) Input #2 or higher "Bad" (Alarm).
il) Input #3 or higher "No-Com" (Alarm).

--```,``-`-`,,`,,`,`,,`---

313
im) Input #3 or higher "Bad" (Alarm).

in) Input #4 or higher "No-Com" (Alarm).
io) Input #4 or higher "Bad" (Alarm).
ip) Input #5 or higher "No-Com" (Alarm).
iq) Input #5 or higher "Bad" (Alarm).
oa) Output 0 quality (Alarm).
02 - Bad.
ob) Output #1 quality (Alarm).
02 - Bad.
oc) Output #2 quality (Alarm).
02 - Bad.
od) Output #3 quality (Alarm).
02 - Bad.
oe) Output #4 quality (Alarm).
02 - Bad.
of) Output #5 quality (Alarm).
02 - Bad.
og) Output 0 Limit (Alarm).
01 - LO Limit.
02 - HI Limit.
oh) Output #1 Limit (Alarm).
01 - LO Limit.
02 - HI Limit.
oi) Output #2 Limit (Alarm).
01 - LO Limit.
02 - HI Limit.
oj) Output #1 or higher "No-Com" (Alarm).
ok) Output #1 or higher "Bad" (Alarm).
ol) Output #2 or higher "No-Com" (Alarm).
om) Output #2 or higher "Bad" (Alarm).
on) Output #3 or higher "No-Com" (Alarm).
oo) Output #3 or higher "Bad" (Alarm).
op) Output #4 or higher "No-Com" (Alarm).
oq) Output #4 or higher "Bad" (Alarm).
--```,``-`-`,,`,,`,`,,`---
or) Output #5 or higher "No-Com" (Alarm).

os) Output #5 or higher "Bad" (Alarm).

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
314
Field Device Start and Restart

The field devices that are a part of the Field Bus system will be operating
in a hostile environment: a situation in which devices can lose and recover
power, suffer transient failures, and be added to, and removed from, the bus
dynamically. This paper will define the provisions in the User Layer to support
the starting, or restarting, of field devices.
--```,``-`-`,,`,,`,`,,`---
INTRODUCTION
THE VARIABLE SFail-Safe
FORMAL DEFINITION OF OPTION SUPPORT
CHANGES TO THE DATA BASE DURING SHUTDOWN
READ/WRITE DURING FAILURE
RESTART
Self Check Output Block Logic
Inhibit R/W at Power-up Outputs Held or Have Feedback
Check Clock TIMER1 OK or "Go" Set
Read Timers Initialize Inputs
Check Combined Data Base "Go" Set
Work Each Logical Node Set Failed
Check Static Data Base Check Logical Node Dyn. Data Base
Hardware Output Block Work Each Physical Hardware Point
Check Dynamic Data Base Physical Node Static Data Base
TIMER0 Expired FB_FAIL Set
Hardware Input Block Start-Up
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Set Initialization Counter Initialize Timers
COMMUNICATION INTERFACE RESTART
Figure 1 - Physical Node Power-Up
Figure 2 - Logical Node Power-Up
Figure 3 - Communication Interface Power-Up
INTRODUCTION:
The start/restart procedure provides for four types of restarting. The fastest
one might be called a "hot" restart. The block restarts without even
initializing itself: it simply resumes operation as if nothing ever happened.
The second is analogous to a "warm" restart: operation resumes after
initialization is accomplished. Following the same analogy, the third is a
"cold" restart; it is used only for output function blocks. The cold restart
will force a configured block in the cascade structure to go into Man mode (Auto
mode for output and discrete blocks) as a result of the restart. These first
three types are differentiated based on timer values, the validity of the dynamic
data base, and the block algorithm. The final type, restarting with a null data
base, is forced when the data base security testing determines that a required
static data base was corrupted.
This discussion is based on a general model of the structure of a field

device. The model has two independent logic processors in the device: one for
the communication logic and one for the block execution logic. The block
execution logic processor services all of the function blocks in all of the
logical nodes in the physical device. If the communication logic processor fails
while the block execution logic processor continues, the blocks will operate as
if there was a loss of communications. A simpler field device that uses only one
processor will automatically lose its communication and logic services
simultaneously; this is one of the possible failure cases in the more complex
model. One of the bits in the physical node's Options Bit string (see p20 of the
"Data Owner Structure - Hardware" paper) defines the presence of this design
option.
Two timers are included in the logic to be described. It is assumed that these
timers are implemented in such a way that they operate independently of the logic
processors and independently of the power to the device. When the block
execution logic processor restarts, the timers will indicate the length of time
SP-50 User Layer Technical Report Field Device Start and Restart

315
since the block execution logic processor stopped execution, even if the failure
was due to the total loss of power to the device. If either or both of the
timers are not implemented, they should be considered as "expired" in the logic
to be described below.
Both of these timers apply to the complete physical node and their requested
and actual settings are part of the physical node's static data base. They are
controlled by the block execution logic processor, not by the communication logic
processor. They are assumed to be "count down" timers so that the physical
node's data base is not needed to determine if they have "expired".
TIMER0, used to permit a fast (i.e., a hot) restart without initialization,

must allow any time setting up to 32.767 seconds expressed in milliseconds.
TIMER1 is used to indicate that a restart after initialization (i.e., a warm
restart) is possible; it must allow any time setting in seconds up to 32,767
seconds. The user will enter the requested value for each timer in two separate
parameters - REQ_TIME0 and REQ_TIME1. The number basis and range of these two
parameters will match their corresponding timers. Both parameters will be 16 bit
unsigned integers. The physical node will transfer the values to TIMER0 and
TIMER1, limiting the value as necessary to meet the limitations of the actual
timer implemented in the device.
The accuracy of the timers is not specified in this standard. It is not

--```,``-`-`,,`,,`,`,,`---
required that the timers be able to time the full time value defined above. It is
only required that the time parameters exist in the data base and that the field
device accept, retain, and support the reading of, the timer ranges specified
above. If the actual timers can not count to the full time of the requested
value, then the value shown in the timers will be less than the requested time.
There is no intent to require that a field bus device implement the assumed
model. The only requirements are:
1) the field devices must respond to a failure in a way that is a
functional duplicate of the model, noting the many options.
2) the device must support the data base parameters consistent with the
chosen (and indicated) options.
3) the two timers defined in the following discussion must operate as
defined if they are implemented.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
4) the communication logic must control writing into, and reading
from, the data base of blocks whose processor is stopped or whose
logical node's data base has a revision number of zero.
The purpose of the following discussion is to completely define the data base
items associated with "Restart" and to give an existence proof of at least one
reasonable restart procedure.
THE VARIABLE SFail-Safe:

This paper defines a logical variable called "System Fail-safe" that is part
of the physical node data base. By definition, this variable must have a high
probability of maintaining its value during upset conditions. The value of this
variable will be considered to be reliable even if the physical node logic
processor has failed its self- test and if the static data base in the physical
node has failed its security check. For purposes of describing the logic in this
paper, it is assumed that the value is defined by a hardware jumper and
implemented with "hard logic".
This variable defines the desired action for ALL of the output points in the
physical node in the event of a failure that precludes both normal operation and
the application of the FailSafe definitions that are provided for each individual
output point. The alternatives are:
1) reset = go to the no-power state
2) set = hold at the present state

316
The value is also used to control the action of the total physical node when the
physical node's data base is lost. If SFail-Safe is reset, the physical node
will shutdown when the physical node's data base is lost. There will be a
parameter in the physical node's data base that can only be written to when the
processor is stopped. That parameter, RESTART, will be a discrete variable.
When the set state is written to it, the physical node processor will again try
to start up. See the paper "Array of Basic Parameters" for a definition of that
parameter. For purposes of this paper and the Standard, the terms "physical
node's processor" or "logic processor" will refer to either a real processor (if
there is one real processor for communications and another for the physical node
functions) or to the physical node task as in a single processor, multitasking
system.
The parameter called SFAIL-SAFE will be an 8-bit binary string variable in the
physical node's data base. The logical state of the variable SFail-Safe
referenced in this logic will be the low order bit reported in that string. Bit
1 in the string will be the user selected value for SFail-Safe. The device will
transfer the state of bit 1 to Bit 0 IF the device can support that option and IF
the option is indeed "writeable". Bit 1 will be the only bit in the byte that can
ever be written over Field Bus. The Data Base Write Service of the field device
will require that it always be written as a masked write with only bit 1
writeable. The variable is defined as being in the static data base so that it
will be uploaded and downloaded in those situations in which bit 1 can be
written. The meaning of the other bits in the parameter SFAIL-SAFE will be
defined immediately below.
A manufacturer may choose to design a field device so that the value of bit 0 in
the parameter SFAIL-SAFE is not writeable over Field Bus. In that case, bit 2 of
the parameter SFAIL-SAFE will be set. If the value of bit 0 can be changed, for
example by a physical jumper, but it can not be written over the Field Bus, the
value of the current setting will be shown in bit 0 but it will, of course, not
be writeable. Nevertheless, Bit 1 MUST still be writeable, it just does nothing.
The manufacturer may choose to design the restart logic in a field device so
that it will always operate as if SFailSafe is fixed in value (set or reset) and
there is no procedure provided to the user to change it (even a physical
procedure). In that case, bits 2 and 3 of the parameter SFAIL-SAFE will be set.
If bit 3 is set, bit 2 can not be reset. Bit 0 will reflect the appropriate
value.
A manufacturer may choose to implement the individual FailSafe discretes for

each physical hardware output point in such a way that they are configurable by
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
the user, associated with the correct physical output, and assured of being
correct after an upset. In this case, they will be used in place of SFailSafe in
the following logic for each physical output but SFailSafe will still be
implemented for the determination of the reaction to a loss of the physical
node's data base. This case will be indicated by setting bit 4 in the SFAIL-SAFE
byte.
Alternately, a manufacturer may choose to implement SFailSafe and not the

configurable FailSafe information for each physical output. In this case, bit 5
in the SFAIL-SAFE byte will be set.
Finally, bit 6 is set if the restart procedure is not consistent with this
description. Bit 7 is not currently used but is retained for future standards
use.
The total definition of the SFAIL-SAFE byte is:

bit 0 - SFail-Safe itself
1 - User requested state for SFailSafe.
2 - Set if bit 0 is not writeable.
3 - Set if bit 0 is not adjustable at all.
4 - Set if individual point FailSafe bits used in Restart logic.
5 - Set if individual FailSafe bits not implemented.
6 - Set if the restart procedure is not standard.
7 - reserved.
--```,``-`-`,,`,,`,`,,`---

317
FORMAL DEFINITION OF OPTION SUPPORT:

The manufacturer has several options of supporting the services defined above.
The data base information associated with these services includes a complete
definition of the services that the manufacturer has chosen to support. The
arrangement is as follows:
The physical node MUST support the following parameters, must never change
their values, and must protect them to the same extent that it protects the
remainder of the static data base.
- REQ_TIMER0
- REQ_TIMER1
- SFAIL-SAFE (the Data Base Write Service will automatically
mask all writes to this value so that only bit 1
is written.)
IF bit 2 in the physical node option bit string is set, then
The physical node must support the following additional
parameters: - RESTART
- TIMER0
- TIMER1
Assume the following NOT supported:
- logical node support for the Fail-Safe parameters and
logic. - logical node support for an actual physical input
to the
Fail-Safe logical.
- logical node support for an isolation timer.
- TIMER0.
- TIMER1.
IF the logical node's time critical options bit string has bit
4 set, then
the logical node has the Fail-Safe parameters and logic.
IF the logical node's non-time critical options bit string
has bit CH set, then
the logical node supports a physical input to the
Fail-Safe logical.
IF the logical node's time critical options bit string has
bit 5 set, then
the logical node supports an isolation timer.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
IF the value of TIMER0 > 0, then the physical node supports a

TIMER0.
IF the value of TIMER1 > 0, then the physical node supports a
TIMER1.
CHANGES TO THE DATA BASE DURING SHUTDOWN:

The restart procedure is based on the assumption that the data base of a
field device is not altered intentionally during power-down even if FailSafe has
been asserted. Note that the assertion of FailSafe must not change the value of
the Inputs to an Output block. It is recognized that the transfer of the results
of a block's execution into the accessible data base must, if started at the time
of failure, be completed before device shutdown so as to leave an internally
consistent set of data in the data base. It is assumed that the field device
design assures this.
READ/WRITE DURING FAILURE:

Since the model of the field bus device assumes that the communication logic
and the block execution logic are independent, it is possible that the
--```,``-`-`,,`,,`,`,,`---

318
communication logic can continue to operate after the block execution logic
fails. When that happens in a field bus device, the data base of the device may
or may not be accessible for reading and writing. If it is not accessible, all
reads and writes will be reported as failed as defined by the Application Layer
of the Field Bus protocol (i.e., the User Layer of peer devices will recognize
the lack of communication as a "No-Com").
--```,``-`-`,,`,,`,`,,`---
If the data base is accessible for reading despite the failure or if

communication occurs with a logical node that has a static data base revision
number of zero, then the communication logic will set three bits in every status
byte read from the function block data bases. Specifically, it will set bit 0
(No-Com), bit 2 (value not from process), and bit 5 (No-Path). Otherwise, all
reads will be executed in the normal fashion. Note that the three bits should not
be set in the data base itself. These three bits will stop control action during
the time that the function block processing is stopped.
In addition to making the data base of the failed device accessible for reads,
the designer of the field device may choose to provide the ability to write into
the data base. If so, the writes that occur under those conditions may not be
able to go through the normal write buffer since the failed node logic processor
may be responsible for servicing the buffer. The Field Bus User Layer has defined
certain parameters that can be written even while the logic processor is stopped.
It is assumed that these special values are similar to hardware I/O ports that
have been mapped into memory. The paper "Array of Basic Parameters" will identify
these data base items. This set of parameters will be independent of the
algorithm type.
If the designer of the field device does not choose to provide the ability to
write into the data base while the logic processor is failed, then all write
messages received under those conditions will be rejected with the normal "No-
Com" response.
In a field device that has separate logic and communication processors, a

manufacturer may provide a method whereby the communication interface can detect
that portions of the data base memory have been corrupted. The communications
interface could then intelligently block reads from these portions of the data
base. Nothing in the following discussion precludes nor discourages this
capability.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
When communication can occur but a logical node, although running, has a
static data base with a revision number of zero, any write into the logical node
data base or that logical node's function blocks will be allowed but no function
blocks in the logical node will function because of two requirements of this
procedure:
1) the logical node will not process its function blocks if it has a zero data
base revision number
AND
2) the logical node will force the requested and actual modes of all of its
function blocks to O/S.
RESTART:
The following discussion of the restart procedures for the block execution
logic is presented in the order shown on the attached logic flow diagrams:
1) Physical Node Power-Up, which includes and surrounds -
2) Logical Node Power-Up
3) Communication Interface Power-Up
The static data base of each logical node must pass a consistency check
before its subordinate structures can be started. This is defined in the
following discussions. Note that there is no data at all in the Standard
physical node data base and no dynamic data in the Standard Logical node data
bases that is required for the function blocks to properly restart.

319
The logic description will start in the upper left corner of Figure 1, at the
circle labeled "Power Up".
Self Check:
The first operation of the physical node logic might be

a series of self-check operations that test the ability of
the block logic processor to operate correctly (but
specifically not a check of the physical circuits associated
with process input/output signals). The field bus standard
does not define what these tests are or even that they must
be done. The Power-Up model assumes that they are done
immediately on power-up and that the physical node execution
logic will stop operation if the tests fail. The self-check
is assumed to include a check of the validity of the
contents of all non-volatile memory necessary for the
general operation of the physical node including the non-
volatile memory used by logical nodes and function blocks
but not the static or dynamic data of any of the physical,
logical, or function blocks or of the physical I/O points.
If the self-check fails, the physical node will set all
of its outputs to the SFailSafe state. The FailSafe states
defined for each individual output point can not be
implemented because the logic can not be executed, or can
not be trusted to correctly execute, the reading and setting
of the individual FailSafe states. In addition, the static
data base (in which the FailSafe states are stored) has not
yet, and can not, be tested. Note that the device
manufacturer may include the ability to communicate with the
physical outputs after the self-check fails using the above
defined ability to communicate into the data base of a
failed logic processor.
The action taken by the failed logic processor after it

enters the state "Die" as a result of failing its physical node
self check is not defined. A manufacturer may design a device
to attempt one or more retries. The logic presented in this paper
is consistent with multiple retries. The model of a Standard
Field Bus device assumes that the device will attempt at least one
"power-up" restart before going to a "die" state.
It is assumed that a method of entering the physical

node's tag name is provided even in the "Die" state and that
the Application Layer of the communication logic can assign
a node address in this state.
If the above restart logic leads to a permanently

stopped condition, the recovery procedure will be the same
--```,``-`-`,,`,,`,`,,`---
as defined above for the SFailSafe logic. A write message

will be sent over Field Bus to the parameter RESTART in the
physical node's data base. When the set state is written to
it, the physical node processor will again try to start up.
See the paper "Array of Basic Parameters" for a definition
of that parameter.
Inhibit Read-Write at Power-up:
When the physical node logic starts operation, the condition of the
data base of the node is unknown. Therefore, the physical node logic
will temporarily inhibit all communication until it can determine the
current state of the data base.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
320
A manufacturer who chooses to allow the communication logic

processor to operate independently of the block logic
processor may implement a less restricted method. If the
communication processor never stopped, then, and only then,
the communication interface may be left active at this point
in the logic but that option requires a change later.
Specifically, whenever a function block's dynamic data base
is set to the default values or the static data base of a
physical or logical node or of the function block is set to
Null, the interface to the block must be inhibited while the
changes are being made.
Check Clock:
The manufacturer may provide a method of determining if

the system clock time has been lost by the failure. If the
clock time is known to be good, the clock variables can be
left alone. However, if the clock was lost, or if there is
no way of knowing if it was lost, the variables NODE_TIME
AND NODE_TIME_OFFSET will be set to zero and the low two
bits in "ALARM" will be set = 10B. See the paper "Data Owner
Structure - Hardware", p14 for a description of the
operation of the clock and page 17 for a description of the
alarm clock.
Read Timers:
The two timers are assumed to have been running during the time
that the node was in the powered-down state. If the self-check passes,
the current state of the two timers (expired or not) will be
read once and then used for all blocks in the physical node.
The physical node will reset the single logical

variable "FB_FAIL" and a table of discrete variables called
the "Output Addressed" table. None of these variables are
available over Field Bus - they are defined here for use in
describing the restart logic processing. FB_Fail will be a
flag that will be initialized to reset, then set if any
logical node or function block lost its data base. The
Output Addressed table will have a logical value for each of
the scalar output points and each discrete output point
within the physical node (simple or voted, hardware or
foreign memory). If a discrete can optionally be an input
or an output point, it will have a value in the table.
There will be no value for Pulse Outputs, Human Interface
hardware, nor for Serial Communication ports.
Check Combined Data Base:

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
It is assumed that the manufacturer has provided some

mechanism for checking the validity of the static data bases
(the data that is covered by the data base revision
numbers). For purposes of this model, it is assumed that
some approach like checksums is used. It is also assumed
that there is a separate checksum for each portion of the
static data base that has a separate revision number.
This assumed design is not required by the Standard. If a device
has a validity checking method that covers larger portions of the data
base, then the following logic should be modified to account for the
design. For example, if the device has several logical
--```,``-`-`,,`,,`,`,,`---

321
nodes, each with several function blocks, but only one

"partition" of checked static data base, then that check
should be done at this point in the logic and the results
made available for use each time the following logic calls
for the checking of a portion of the data base.
Work Each Logical Node:
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Once the physical node processor is known to be
operable, the logical nodes and their function blocks will
be prepared for operation. Note that there is no data in the
physical node data base that is needed to operate the
logical nodes and function blocks. The logic description is
now to be found in Figure 2, the "Logical Node Power-Up"
drawing.
Since there may be multiple logical nodes in a single

physical node, this logic includes a "recycle" loop to
process each of the "n" logical nodes in turn.
Certain logical node data is assumed to be "built into"

the device. This data would be secure and/or checked as part
of the physical node self check. It will include the
following parameters:
1) the number of logical nodes
2) the permitted node type(s) of each logical node
3) MB (maximum number of blocks for the logical node)
for each logical node
4) MX (manufacturers minimum cycle time exponent) for
each logical node
There are two user-set data items in the writeable

static data base of logical nodes that are needed for
further processing - the values for CX (the current cycle
time exponent) and CB (the current blocks per cycle).
Therefore, the static data base of the logical node is
checked first.
If the integrity of the logical node's static data base

is found to be bad, or if the revision number of its data
base is zero, the individual function blocks in that logical
node can not be processed because it is not known how many
are to be processed nor at what cycle time. Therefore, the
logical node's data base is set to "Null" and the variable
FB_FAIL (to be used later in this logic) is set. Next, ALL
of the function blocks in the logical node [i.e., all MB
blocks (the manufacturer set maximum number of blocks) since
CB is not known] are processed through special logic.
The logic for responding to a bad logical node data base has
two features that allow the total restart logic to be repeated
endlessly. First, the null logical node data base (defined in the
paper "Array of Basic Parameters") has a data base revision number
of zero. Thus, if the logic is repeated, it will again go down the
same logic path as was executed the first time with the bad
data base. Second, the null function block data base
(Algorithm 20H) that is used if a block has a bad data base
will also have a revision number of zero and will also cause
the logic to go down the same path as the original failed
data base. Because of this, the restart logic is
repeatable.
Each function block in the logical node is processed in

turn. If the static data base is secure and has a revision
number greater than zero, then the dynamic data is set to
--```,``-`-`,,`,,`,`,,`---

322
its default values for the defined algorithm and the block
mode is set to the "requested" mode (the static data base
copy of mode). If the static data base is not secure or has
a revision number of zero, then the only alternative is to
set the whole block's data base to Null. In either case,
the block will not operate when the physical node is started
because the logical node's data base is null.
If the static data base of the logical node is secure

and has a revision number greater than zero, then each
function block in the logical node will be inspected in turn
with the intent of resuming operation. The logic drawing
uses the variable "FB" to represent the function block
number. The analysis will be done on all MB blocks but the
logic will distinguish between those blocks being executed
and those blocks "above CB".
Check Static Data Base:
If the static data base for a function block is not valid

or if the revision number is zero, there is no way of knowing how
to recover as part of the power-up operation. The only recourse
is to set the Null data base in that block. At this point, the
data base revision number will be zero: a higher level device can
respond to that special condition.
If the function block is above the CB limit, then the

only action that is needed in the restart logic is the
setting of the Null data base if the static data base is bad
or has a revision number of zero.
If the function block is at or below the CB limit and

has an invalid static data base or a revision number of
zero, then the Null data base will be entered and FB_FAIL
will be set. As noted above, the
zero revision number in the Null data base allows the
restart logic to be repeated endlessly and the variable
FB_FAIL will be set each time.
There is one detail to be cleared at this point. If

the physical node had NOWRITE set and one of the working
blocks lost its static data base, the NOWRITE will have to
be cleared. The operator may be locked away from writing
but can't wait for permission to overwrite it. The NOWRITE
discrete (abbreviated as LNNW in the figure) and the
corresponding tattle bit (abbreviated as LNNWTB) will be
automatically set at this point.
Hardware Output Block:
A block that is a hardware output block and has a valid static data
base will be analyzed for purposes of setting the "Output Addressed"
--```,``-`-`,,`,,`,`,,`---
table. The hardware agent of the output block will indicate the
particular hardware point that that block drives. The
Discrete Register block will be considered a "hardware
output block" for purposes of this test if the field device
includes any discrete outputting capability. Note that the
analysis of the Discrete Register block must include the
hardware agent mask so that the correct discrete points are
marked in the table.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
323
Check Dynamic Data Base:
The portion of a function block's data base that is NOT

covered by the data base revision number can be considered
to be further broken down into two sections: the data that
is regenerated by initialization and the portion that is
not. For example, the PID algorithm stores data such as the
previous error, the previous derivative term, and the output
before limiting. All of these values are set as part of a
block initialization. On the other hand, the set point of a
PID block that has Input 1 tracking turned off can not be
regenerated.
A manufacturer may design a field device in such a way

that the dynamic data base:
1) can not be lost
2) can be validity checked, or
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
3) can not be validated on restart.
The attached logic diagram shows two results possible from the
check of the dynamic data base. If all of the dynamic data is known to
be valid, the logic can proceed to the inspection of TIMER0.
Otherwise, the logic can proceed down the "bad/not tested"
path to, in the case of control blocks, the logic that sets
a default set of dynamic data and the requested mode that is
found in the static data base. Note that a more
sophisticated analysis is possible at this point. It is
possible that a device manufacturer may select the portion
of the dynamic data base to protect that can not be
initialized so that only the initializable part of the
default data base can be lost. Such a procedure could
improve the probability that the default data base could
clear its NaN/Bad values and start to control. If such an
analysis is provided, then the logic should proceed down the
"bad/not tested" path but the appropriate changes to the
null dynamic data base can be made.
For purposes of this procedure, it is not necessary

that the dynamic data be the actual working data base; it
may be a back-up copy that is captured frequently enough to
allow its use in a restart. Such a design might enable the
logic to proceed down the "good" path.
If the dynamic data can not be verified as good, all

parameters in the block that have status bytes must be
marked "Bad".
--```,``-`-`,,`,,`,`,,`---
Given that the logic is processing through the block
data bases, this is a convenient time to do one automatic
part of block restart: reset all of the communication No-Com
counters and reset all of the
count-out-gates on the cascade transfer locations.
TIMER0 Expired:
The first timer in the logic flow is provided for a "Hot" recovery
from a momentary loss of power. It is assumed that the time is set (by
the user through REQ_TIME0) for a time in the order of 100 ms. To 4
seconds. Given that the block logic processor is
operational, the data base is completely good, and the device
has only been shut down for a short period of time, it is
reasonable to start operations as if there had been no
interruption: a "Hot" restart. Note that this logic path
ignores the possibility that the FailSafe outputs were set.

324
TIMER0 is assumed to be set with a time that is short enough

that the "hot" restart can simply drive the outputs back to
their previous position and the process "will not notice".
Hardware Input Block:

A block that is a pure hardware input block does not need its
dynamic data base to restart although it is advantageous to retain
the input filter if possible. The logic includes an explicit check for
these types of blocks so that they can be started quickly. Note that
the set of Standard Algorithms includes a Discrete Register block that
can serve mixed discrete inputs and outputs; that block is NOT a
"hardware input block" for purposes of this test if the field device
includes any discrete outputting capability. The serial communication
function blocks are not to be considered as input blocks.
The human interface function block is to be handled at this point

in the logic based on the functionality of the human interface
input/output hardware to which it points. If the human interface block
points to hardware that only supports input mechanisms that
hold their value through a reset and its only output is
function block status information (not process information),
then that function block can be considered an input block.
For example, the hardware might consist of a three position
switch with indicating lights as defined in the device
control block. On the other hand, if the human interface
function block points to human interface hardware that can
display a process measurement, then that human interface
function block can not be considered an input block.
If the dynamic data was lost, the block will be forced

to initialize the input filter by setting FORCE_INIT = 2.
Thus, there can be either a "hot" or "warm" restart for an
input block. FORCE_INIT is defined on page 17 of the
"Function Block Structure" paper.
Set Initialization Counter:

If the function block was not an input type and the
device was shut down for longer than TIMER0, or if the
dynamic data base was bad/not tested, then initialization is
required. The block is forced to initialize by setting the
block's FORCE_INIT to 2. If the value in the cascade
transfer locations is changed as a result of the
initialization, higher blocks in the cascade structure will
be forced into an initialization cycle.
--```,``-`-`,,`,,`,`,,`---
The logic will also set the NOWRITE tattle bit in the
logical node's data base at this point since the validity of
the process data can not be guaranteed.
Output Block Logic:
The logic for the restart of a block after a relatively long outage
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
is different for Output blocks from all other blocks. Therefore, the
two logic paths are split. The Discrete Register block
mentioned above is to be considered an "Output Block" for
purposes of this logic if any
discrete I/O capability is provided in the physical device.
The human interface and serial communication function blocks
are not to be considered output blocks.

325
For all blocks other than Output blocks, the blocks

will initialize and run. If the block's dynamic data was
good or if the null dynamic data can be cleared by
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
initialization, the block will commence control action - a

"warm" restart. If the null dynamic data can not clear,
then this path will yield a "cold" restart.
Note that a block may execute a "hot" or "warm" restart

but a failure state may not have existed long enough to have
been seen by blocks higher in a cascade structure. If
initialization does not result in a change of the block's
Setpoint, then the higher blocks may not even initialize.
Outputs Held or Have Feedback:
If an Output block provides a feedback signal from the final driven

device (such as a stem position measurement on a modulated value) then
the logic will proceed to the test of TIMER1.
For Output blocks without feedback, it is assumed that the

manufacturer has provided a method of determining if the physical
outputs were maintained during the outage as opposed to
being dropped to the no-power state. For this logic, it is
not important whether the transition to the no-power state
was caused by the loss of power or by the assertion of the
FailSafe command with the FailSafe state set to be no-power.
The external devices driven by discrete outputs with the
pulse option turned on and the Pulse Output type output
hardware will always be assumed to have "held" for purposes
of this logic unless the block is known to have set the
output to the no-power state.
This logic test is NOT a measure/compare/tolerance test

- this is a yes/no test. For example, if a scalar output
stayed close to its former position but was subject to
drift, it would be considered to have held.
If the outputs held, then the logic for the block

should proceed to the test of TIMER1 to determine if the
block might still be able to restart with simple
initialization, depending on the length of the outage. If
the output did not hold, the logic path labeled "No" will be
used.
TIMER1 OK or "Go" Set:
If the outputs were held at their previous state during the outage
and the outage was shorter than the setting of TIMER1, the block can
restart after initialization - a "warm" restart. Alternately, the
individual output block may have an explicit option to "Go"
on restart do a warm restart no matter how long it was down.
Otherwise, the Inputs of the block will be marked "Failed"
as described below.
The value for TIMER1 is to be set by the user through REQ_TIME1.

--```,``-`-`,,`,,`,`,,`---
It is assumed that the value set will be determined by the

nature of the process being controlled. Up to the time
limit, a failed field device can return and go directly to a
"warm" restart - one cycle of initialization, then the
Output block resumes its previous mode with the cascade
enabled. That action is useful for efficient restarting
but, after some time limit, one does not usually want the

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
326
device to come back into service and automatically start to

manipulate the output. That limit is the value set in
TIMER1.
Initialize Inputs:
If the field device driven by a hardware output block

did not hold at its previous state during the outage and
there is no feedback
measurement available, it is necessary to initialize the
Input word of the Output block to the no-power state of the
Output. This must be done using the data base information
concerning analog ranges, direct/reverse action, etc.
"Go" Set:
If the output block is processed on this logic path, its explicit
option to "Go" on restart is still honored. The logic branches to a
"warm" restart with the initialized output if that option is set.
Set Failed:
--```,``-`-`,,`,,`,`,,`---
The function block will obey its defined option for

handling the failure state. The base action is to put itself
into Manual mode (Auto for discrete blocks) and issue a "mode
change due to a failure" alert. The status bytes of the
inputs would indicate a failure state due to the restart.
The alternative action is to pass the failure information up
the cascade as explained below but to otherwise resume normal
operation in its previous mode with no alerts issued. Given
correct configuration, this will cause a block above the
output block to go into Man mode and issue an alarm. Note
that an individual function block should not issue a
"restart" notification if it does not change its own mode in
order to reduce the number of notifications - the physical
node will issue the
"official" restart notification.
A handshake procedure is used to pass the failure information

up the cascade. For all Output blocks in a mode lower in
priority than Auto, the power-up logic will optionally set
bit 4 (Failed) and reset bit 5 (No-Output-Path) in the status
byte of the Cas and Rcas transfer locations - analog or discrete.
This action will initiate a complex handshake through the blocks
above the Output block. In general terms, the "Failed" state will
pass up the cascade with an indication of a path-to-process.
The higher block will either go into Man mode or it will pass the
Failed state further up the cascade. All PID function blocks will go to
Man and all Device Control blocks will go into Auto. All
other blocks that can be in a cascade will include an option
to choose which action they will take. All correctly
configured cascades will have a block that will go into Man
or Auto mode, set an alarm, set bit 5 in its output and write
bit 5 back down the cascade. The lower blocks will pass the
set bit 5 further down the cascade. When the Output block
receives the acknowledgement AND is no longer failed, it will
clear the Failed indication and pass that up the cascade.
The block that went into Man mode WILL NOT revert to its
previous mode.

327
A much more detailed statement of this action is:

1) The Output block that is in Power-Up and a mode of lower
priority than Auto will optionally:
a) set bits 4 and 5 in both transfer locations
b) if the requested mode is lower in priority than Auto,
set the requested mode to Auto and issue a "mode change
due to failure" alert.
OR:
a) set bit 4 (Failed) of its Cas and RCas transfer location
status bytes.
b) reset bit 5 (No-Output-Path but now a failure handshake
bit) of its transfer location status bytes.
c) initially issue no alerts.
d) revert to the base logic, setting bits 4 and 5 in both
transfer locations, if:
- the highest allowable transfer location counts out
AND
- bit 5 is not yet set
e) set bit 5 in both transfer locations if the requested mode
becomes higher in priority than Cas.
f) reset bits 4 (Failed) and 5 (Handshake) in both transfer
location status bytes ONLY if there is no
continuing failure
AND:
i) the block's mode is higher in priority than Cas.
OR
ii) bit 5 (Handshake) of the status byte of
one of the transfer locations is set.
2) When the PID, On/Off, and Device Control blocks that
have an active output agent find bit 4 (failed) set
in the Cascaded Output Word but bit 5 is reset, they
will:
a) set their actual and requested mode to Man
(Auto for discrete blocks).
b) report a "mode change due to a failure" alert.
c) set bit 5 (Handshake) in their Output Word's
status byte and write it back to the next lower
block in the cascade.
3) certain other control blocks that have an active
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
output agent will have the option to operate the

same as the blocks in (2) or, when bit 4 (Failed) is
set in their Output Word's status byte but bit 5 is
reset:
a) if they are in a mode of lower priority than Auto:
i) set bit 4 (Failed) in the transfer
location status bytes.
ii) reset bit 5 (Handshake) in their transfer locations.
iii) do not initially report any associated alert.
iv) revert to the base logic, setting bits 4
and 5 in both transfer locations, if:
- the highest allowable transfer location counts out.
AND
- bit 5 is not yet set.
v) set bit 5 in both transfer locations if the
requested mode becomes higher in priority
than Cas.
vi) set bit 5 (Handshake) in the Output word's
status byte and write it back to the next
lower block in the cascade whenever bit 5
is set in its own Setpoint.
b) if they are in a mode of higher priority than Cas:
i) report a failure alert.
ii) set bit 5 (Handshake) in the Output word's
status byte and write it back to the next
lower block in the cascade.
c) if they are in a mode lower in priority than
--```,``-`-`,,`,,`,`,,`---

328
Auto and bits 4 (Failed) and 5 (Handshake) in a

transfer location's status byte are set and bit
4 (Failed) in the Output word's status byte is
reset, reset bit 4 (Failed) in all of the
transfer location status bytes. Then, bit 5
(No-Output-Path) is set or reset in the
Setpoint and transfer location status bytes to
match its state in the Output word's status
byte.
The logic next checks to see if it has processed all of the

function blocks in the logical node. If so, the loop is
done.
Check Logical Node Dynamic Data Base:
The manufacturer may have provided a method of holding/checking the

dynamic data base during a shutdown. If so, and if the dynamic data
base is known to be good, it can be used. If the data base
is not known to be good, then the following operations will
be performed:
1) reset bit 0 of Fail-safe (the Fail-safe logical
itself) (see the paper "Data Owner Structure -
Logical Nodes", page 22).
2) if the Fail-safe function supports a hardware input
and that input is currently in the open state, then
set bit 0 (see the paper "Data Owner Structure -
Hardware", page 13).
3) reset bit 1 of Fail-safe (the bit that requests the
Fail-safe logical be reset).
4) zero the 5 logical node variables (if discrete, set
to NaN if scalar) and mark them "Bad" and zero the
masks for the discrete
variables.
At this point, the logic checks to see if it has
--```,``-`-`,,`,,`,`,,`---
processed all logical nodes. If so, it returns to Figure 1
at the point where it left. If not, it processes the next logical node.
Work Each Physical Hardware Point:
The physical hardware points can contain calibration

constants that can be written by Field Bus. It is possible
that these constants could be lost during an upset. It is
assumed that the field device manufacturer has provided some
method of checking these data.
Any physical hardware point that has lost its
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
calibration data must, of course, be prevented from starting
and an alarm must be set for that point. The hardware data
will be set to completely zero. The algorithms that service
the hardware will be designed to set themselves into O/S
mode as long as the data is completely zero. Any time they
change their mode, they must, of course, issue a "mode
change due to failure" alert.
Physical Node Static Data Base:
The physical node static data base is checked and set to its Null
value set if it is not secure or has a revision number of zero. Note
that the physical node can safely operate without any of the data in

329
this data base. In order to make that true, it is necessary

that the number of logical nodes in the physical node be
fixed by the manufacturer and not controlled by the user.
This can be arranged since the user can simply set LN_OOS =
TRUE to stop a Cycle/Phase or a Timed Standard logical node.
An Unscheduled Standard logical node is assumed to be under
the control of the independent scheduling agent.
Note: the above logic makes the assumption that the clock variable
ALARM_TIME is not critical (see the paper "Data Owner
Structure Hardware", page 18).
Once the null data set is entered in the physical

node's data base, it is still possible to start and operate
the logical nodes. However, the discrete SFailSafe is
checked so that the user has the option of aborting the
restart if the physical node's data base is lost. If the
logic finds the physical node's static data bad and
SFailSafe reset, it will go to the "Die" state and stay
there without automatically attempting another restart. The
above defined method of using the variable "RESTART" will be
necessary to resume operation of the whole physical node.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Note that the above discussion did not even mention the physical
node's tag name and address, which are stored in the physical node's
data base! If the physical node's data base is intact, it is assumed
that the node's name and address, being part of that data
base, are valid. If the physical node's data base is lost
and SFailSafe is reset, then the whole physical node will
set all of its outputs to their SFailSafe state and "Die".
However, if the SFailSafe bit is set when the physical
node's data base is lost, THE RESTART WILL PROCEED EVEN
THOUGH THE PHYSICAL NODE'S TAG NAME AND ADDRESS MAY HAVE
BEEN LOST.
THAT IS THE INTENT OF THE DESIGN AND PART OF THE
CONSEQUENCE OF SETTING SFailSafe! If the manufacturer has
provided some method of retaining the physical node's name
and address, then the physical node will be able to respond
correctly and resume communications much easier, but that
does not affect this logic.
FB_FAIL Set:
Once all of the function blocks in all of the logical

nodes have been processed, the single discrete variable
"FB_FAIL" will be tested.
If it was never set during the processing of the function blocks,
then all of the logical nodes and function blocks in the physical
node have secure static data bases. If FB_FAIL is set or if the
physical node's static data base was found to be bad in the previous
--```,``-`-`,,`,,`,`,,`---
step (abbreviated PNDB in the Figure), then a physical node alert

will be issued to indicate that the node's data base must be downloaded.
If FB_FAIL is reset, any process output in the physical node that

is not addressed by an output agent can safely be set to its no-power
state. Note that this applies to individual discretes for discrete
registers. The "Output Addressed" table defined above and
filled out by the function block inspections in the above
logic has resulted in a complete list of the physical hardware that is
addressed by the hardware agents in the function blocks. The unaddressed
hardware outputs can be set to their no-power state.

330
If the static data base was lost for any of the function
blocks except for blocks known to be above CB, there is no
known safe alternative to the SFailSafe value.
Note that the above procedure involving the "Output Addressed"

table is available upon command from Field Bus as a service.
The physical node variable "CLEAR_OUT", supported by all
physical nodes, can be set by a Field Bus write. When the
physical node finds that variable set, it can interrupt the
logical nodes and do the data base search. If there is only
one Timed Standard logical node, the interruption should be
at the end of that node's cycle. It is assumed that the time
to do the scan will result in a one-time delay in the start
of the next function block cycle.
After the commanded data base scan, the unaddressed

outputs can be set to the no-power state similar to the above
procedure. It is expected that the FB_FAIL logical will be
found reset when a commanded search is done. At the conclusion
of the search, the CLEAR_OUT discrete will be reset by the
physical node itself. The CLEAR_OUT discrete can not be
reset from the Field Bus.
Start-Up:
The next to last step in the restart procedure includes
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
initializing counters and starting the actual processing of the
functional blocks.
If the logical node's dynamic data base was lost, then:

1) ISOLATE_TIME, found in the logical nodes's
static DATA base, will be moved into the
Isolation Timer value.
2) All No-Com counters will be reset.
3) IF there is a hardware input to a logical node Failsafe
value
AND it is currently set
AND the Failsafe value is currently reset, THEN
Set Failsafe.
Note: if the logical node dynamic data base was lost,
then the Failsafe value will be found, by the
above logic, to be reset.
The communications will be turned back on.
A restart notification will be set.
The logical node processing cycles can be started for all

logical nodes that have a non-zero static data base revision number
and a value of LN_OOS = FALSE. A Timed Standard logical node will
also require that CB (current blocks per cycle) be larger than zero.
(The two variables referenced are defined in the paper "Data Owner
Structure - Logical Nodes.) These two requirements are normal
requirements of the logical
nodes, not rules unique to the restart procedure.
Initialize Timers:
It is necessary to initialize the two timers but it is

important that the slowest logical node executes at least once in
case the execution of the block processing causes another failure
immediately. Therefore, the initialization of the timers is delayed
--```,``-`-`,,`,,`,`,,`---

331
until the logical node with the LARGEST CX (i.e., the slowest cycle
time) has executed 1 cycle. Unscheduled logical nodes or logical
nodes that are not processing are ignored for purposes of
determining the delay time; if there are only unscheduled logical
nodes and/or logical nodes that are not processing in the physical
node, the timers may be initialized immediately.
COMMUNICATION INTERFACE RESTART:

It is assumed that the communication interface functions are provided by a
logic processor that is separate from the function block processor. Therefore, it
is possible that the communication function may be available while the function
block processor has failed. Alternately, the communication processor may be tied
to the function block processor in such a way that it restarts at the same time.
If the communication function is available while a physical node is not

processing or while a logical node has a static data base with a zero revision
--```,``-`-`,,`,,`,`,,`---
number, the communication interface will allow communication as defined above
(see "Read/Write During Failure"). However, the physical node will inhibit
communication during part of its restart procedure (see "Inhibit Read/Write at
Power-Up").
Figure 3, "Communication Interface Power-Up", illustrates the logic for the

restart of the communication function. It assumes that there is some kind of
self checking done by the communications logic processor.
When the communication function restarts, it will include a predetermined

delay. This delay will be included to protect for the situation in which the
communication processor and the function block processor both start at the same
time. The delay will be determined by the manufacturer and will be sufficiently
long to ensure that the communication processor will not start communications
before the physical node restart logic progresses to the "Inhibit R/W At Power-up
step. If the physical node self check fails, the communication processor can
proceed, allowing communication into the data base of the failed physical node
subject to the restrictions defined in the section "Read/Write During Failure".
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

332
Figure 1 PHYSICAL NODE POWER-UP

Yes Yes Yes
Power Physical Inhibit Clock FB_Fail Set
Up Node Self Commun Time On PNDB Alert
Check -ications OK? Set?
OK?
No No
No
Zero Su_Time,
Run_Time,Time_Event Set Unaddressed No FB_Fail
Physical Outputs Set?
Read Timers and Reset FB_Fail To No-Power.
Flag and "Output Addressed"
Set All
Tables.
Yes
Die OutputsTo
Set Unaddressed
SfailSafe
Physical Outputs
State Check Integrity of
To SFailSafe
Combined Data Base.
Work Each Logical Node -

Start Up
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
See separate Diagram.
Communications
Work Each Physical Hardware Point. And all Logical
If Manufacturer Data was lost, Nodes.
Mark hardware Point Failed
No
Initialize Timers
Is Set Null Physical After 1 Cycle Done
SfailSafe No In Logical Node
Physical Node
Set? Node DB. Static With Largest CX.
OK?
Yes Yes
Figure 35: Field Device Start and Restart, Figure 1, Physical Node Power-Up
--```,``-`-`,,`,,`,`,,`---

333
LOGICAL NODE POWER-UP

Figure 2
Done Zero Alert

All Times, Fix
Set Logical N= Bits 0 and
Start 1 in Fail-safe.
N=0 Nodes N+1
Done? Clear LN Var.
No LN
Work No
Static DB Yes
LN-n
OK? Yes
Dyn.
No DB of LN
No OK?
Yes Hardwar Static No Function
Set matching Bits Yes
In the "Output e Data Base Block FB
Addressed" table. Output OK? >DB1? =0
Bl k? Yes
Fb=
Dynamic Good Timer 0 No Fb+1
Data Base Null Block's DB Yes
Expired? Set FB_Fail,
Check All
Set LNNWTB. No Blocks
Hardware Reset LNNW On LN
Static
Input Done?
--```,``-`-`,,`,,`,`,,`---
Data Base
Bad/Not Block?
Yes OK?
Tested No
Hardware
Output FORCE_
Yes Null
Block? INIT=2
Blocks
Dynamic Data= DB
Defaults No
Set FORCE_ Yes Outputs Init.

Output No
INIT = 2 Held or Inputs
Block?
If now <2. F'back? Set
Leave Mode No Yes Failed
Alone Timer1 Yes No Status
Set LNNWTB OK or "Go" On all
Yes
"Go" Set? Block
Set FB_Fail And ? No Inputs
Null Logical
Nodes = DB
All Yes Yes `Dynamic data =
Do all "MB" Static
Blocks No defaults,
Blocks in Data Base
In LN Mode=Static
Following Logic OK?
Done? Mode
Null Blocks DB No
Figure 36: Field Device Start and Restart, Figure 2, Logical Node Power-Up

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^
334
Figure 3
COMMUNICATIONS INTERFACE POWER-UP
Wait Sufficient
Comm. Yes Time for the
Power Function Physical Node
Start
Up Self check To Inhibit Comm.
OK? Communications.
No
Die
Figure 37: Field Device Start and Restart, Figure 3, Communications Interface Power-Up
--```,``-`-`,,`,,`,`,,`---

335
Human Interface Considerations -HIF

One of the principle driving forces behind the standardization of the
function blocks is the resulting ability to implement, across manufacturers, a
full-function Human Interface (HI/F) to the field devices and blocks. This paper
will consolidate and highlight many of the HI/F considerations from the design of
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
the physical nodes, logical nodes, and function blocks. It will also document the
rules and suggested enumerations for HI/F displays.
It is the intent of the design of the standard blocks that the display
attributes of every piece of data in their data base be defined. However, there
are many different methods used for defining those attributes. They are:
1) implicit in the parameter data type.
example: a visible string.
2) implicit by definition for selected parameters.
3) implicit in the parameter definition but decimal point not located
and/or precision not defined.
example: the PID gain (dimensionless).
4) defined to be in "Extended SI" units with a "SI Units" descriptor.
example: Input #0 in an AI block.
5) user-specified units, display ranges, and decimal point locator
provided for analog values.
example: the Setpoint of an analog block.
6) user-specified enumeration set code number and discrete display code
provided for discrete values.
example: the Setpoint of a discrete block.
7) auto-formatting data supplied for manufacturer public data.
8) "clipboard" in physical node.
The next section describes the basis for the descriptions in this paper and
the first step in the display of any data item. The bulk of the paper will
detail the display procedures for each of the above cases. Finally, the Human
Interface requirements of the "triggered calibration" procedure will be
described. The details of the auto-formatting procedure and the material
description procedure will be given in the two attachments.

DISPLAYING A DATA ITEM
VISIBLE STRINGS
IMPLICIT DISPLAY PARAMETERS
DEFINED DISPLAY RULES FOR SELECTED PARAMETERS
REAL VALUES DEFINED TO BE IN "EXTENDED SI" UNITS
ANALOG VALUES WITH UNITS AND ATTRIBUTES
DISCRETE VALUE WITH ENUMERATION SET CODE NUMBER
DATA SETS
MANUFACTURER PUBLIC DATA (Auto-Format Variables)
EXTENDED PARAMETERS
PHYSICAL NODE CLIPBOARD
TRIGGERED CALIBRATION
Table 1 - Extended SI Units
Table 2 - Enumeration Set Code Numbers
Table 3 - Enumeration Set Detail - Codes 2, 10, and 16 (Numbers)
Table 4 - Enumeration Set Detail - Two State - "State" Feedback
Table 5 - Enumeration Set Detail - Three State - "State" Feedback
Table 6 - Enumeration Set Detail - Two State - "Limit" Feedback
Table 7 - Enumeration Set Detail - Three State - "Limit" Feedback
Table 8 - Glossary of Enumeration States
Table 9 - Recognized General Single Character Non-Print Commands
Table 10 - Field Bus Defined Single Character Non-Print Commands
Table 11 - Recognized General Single Byte Font Codes
Table 12 - Recognized General Two Byte Font Codes
Table 13 - Recognized "Escape" and "Field Bus Escape" Commands
Table 14 - Materials Specification List By Device
Table 15 - Materials Specification List By Code Number
--```,``-`-`,,`,,`,`,,`---

336
Table 16 - Suggested Maintenance Codes

Attachment 1 - Auto-Formatting
Figure 1 - Auto-Formatting Parameter Layout
Figure 2 - Auto-Formatting Parameter Header
Figure 3 - Auto-Formatting Detail Words
Attachment 2 - Material Description
Table 1 - Industrial Ceramics, Cermets, and Powder Metallurgy
Table 2 - Miscellaneous Material Descriptions
Table 3 - Surface Treating and Hardening, Material Color,
and Paint Systems
DISPLAYING A DATA ITEM:

This paper will assume that a human at a Human Interface device has requested
the display of a named parameter for a tagged object (TO) whose tag name is
specified. How is that data item displayed?
In almost all cases, it is appropriate to first determine the "TO_TYPE" of

the named object. The only exception would be a data item that is in all
objects, such as the tag descriptor. The TO_TYPE is defined in the Application
Layer Data Dictionary for all objects and is thus available without communication
on Field Bus itself. It will be assumed here that the TO_TYPE is that of a
Standard Physical Node, a Standard Logical Node, or a standard function block,
and that the parameter name is defined as a standard name.
Given the TO_TYPE, the HI/F device can determine from its own data tables for
the tagged objects defined in the standard:
--```,``-`-`,,`,,`,`,,`---
1) the validity of the requested data item for this TO

2) the data type.
3) which of the following categories applies to this data item.
The intent is to avoid the necessity for a series of Field Bus communications
before a parameter can be displayed.
VISIBLE STRINGS:
There are many different methods of encoding character fonts. This standard
recognizes two methods as fundamental and also provides "escape codes" to shift
into many other methods. One of the fundamental methods uses one byte per
character font and the other uses two bytes per font.
The one byte method is defined in Table 11 (Recognized General Single Byte
Font Codes). It is based on ISO-646 with many of the control codes specially
defined.
The two byte method is based on the "Unicode Standard"; details are available
from:
Kenneth W. Whistler, Secretary
Unicode, Inc.
1965 Charleston Road
Mountain View, CA 94043 USA
Table 12 (Recognized General Two Byte Font Codes) gives the Unicode
representation for the same character fonts that were defined in Table 11. The
control codes in the Unicode range of 0000H to 0020H are exactly the same as
defined for the single byte codes in the range 00H to 20H. In addition to the
fonts defined in Table 12, the Unicode system defines many other fonts. All
references to specific details of the Unicode system are based on the draft
available in June, 1991 and labeled "pre-copy-edit draft".
This paper will discuss four different classifications of visible strings:

1) the tag name (TAG), the manufacturer's name (MFG_NAME), and the
model number (MODEL_NUMBER).
2) "clipboard" visible strings (to be defined below).

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
337
3) all other visible strings of 32 characters or less.

4) all other visible strings of 33 characters or more.
The tag name, manufacturer's name, and model number will ALWAYS be entered
into the field device's data base using the one byte identification of the fonts
given in Table 11.
Visible strings in the clipboard will DEFAULT to the one byte identification
of the fonts given in Table 11. A complete set of "escape" codes is defined
below to indicate a change to and from other representations.
All other visible strings of 32 characters or less (and not in a clipboard)

will ALWAYS be entered into the field device's data base using the two byte
"UNICODE" representation of fonts. Table 12 gives the Unicode representation for
each of the fonts given in Table 11.
All visible strings of 33 characters or more (and not in a clipboard) will

DEFAULT to the one byte identification of the fonts given in Table 11. An
"escape" code is defined below to indicate a change to the two byte Unicode
representation and another code to transition back to the one byte
representation. No other representations will be allowed in these visible
strings.
Any data base item that is defined as being a "visible string" may contain
certain display formatting commands. The commands are given here as single byte
commands. However, when the above definitions or escape commands have indicated
a two-byte representation of each font, the following representations will be
expanded to two bytes by adding a zero byte in front of the value given. If the
visible string representation has been changed (by using an escape sequence) to a
system that has one of the following representations defined as a visible font,
then that font will prevail.
1) the only commands allowed in a string whose maximum length is 32
characters or less are:
"Record Separator" <RS> [Char. 30(base 10)] (See Table 10).
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
"Unit Separator" <US> [Char. 31(base 10)] (See Table 10).

"Space" <SP> [Char. 32(base 10)].
One of the two separator characters can appear at the end of the
string. The <US> command will simply indicate the end of the visible
string - any trailing characters will be ignored. The <RS> command
will indicate the end of the visible string and, in addition, cause
the last line of the string to be right justified. If the string
does not end in either command, the <US> command will be implied.
2) for strings whose maximum length is greater than 32 characters, the

following commands will also be supported - see Table 10 for the
definitions of these commands:
Char. 9 <HT> Horizontal Tab
Char. 10 (base 10) <LF> Line Feed
Char. 11 (base 10) <VT> Vertical Tab
Char. 14 (base 10) <SD> Select Double-Width Mode
Char. 15 (base 10) <SC> Select Condensed Mode
Char. 18 (base 10) <CC> Cancel Condensed Mode
Char. 20 (base 10) <CD> Cancel Double-Width Mode
Char. 24 (base 10) <HB> High Bit
Char. 32 (base 10) <SP> Space (can be word-wrapped)
Char. 127 (base 10) <SPH> Space (ignored by word-wrap)
Char. 255 (base 10) <SPH> Space (ignored by word-wrap)
3) Some strings, such as the tag descriptor, are "language", in addition

to font, specific. All strings that will be language specific in the
Standard blocks and nodes are user-entered strings. It is assumed
that the higher-level devices support the language of the user and
that the character strings were entered in that language. There is
no provision for identifying nor supporting a mix of languages for
the user. Note that this is referring to language, not fonts.
--```,``-`-`,,`,,`,`,,`---

338
The clipboard structure will be defined below.
The above requirements for the single byte representations of characters 33

(base 10) through 126 (base 10) are completely in conformance with the
International Reference Version of the G0 graphic character set of ISO/IEC
646:1991. The word-wrap clause has been added to character 32 (base 10).
Character 127 (base 10) is defined to be a space with a word wrap clause instead
of a media-fill or time-fill character. The C0 set defined above is
significantly different from the C0 requirements of 646.
The Unicode representations of the fonts shown in Table 12 is completely in

conformance with the 1991 pre-copy-edit draft of the Unicode system with the
following exceptions:
1) The command set defined for the representations less than 32 (base 10)
is significantly different.
2) There is no Unicode font that corresponds to the font given for the
one byte representation B0H. There is no font defined in Unicode for
the representation 2591H. There is a direct correspondence between
2592H and B1H, and between 2593H and B2H. Therefore, the assignment
was made as shown.
3) Unicode defines 007F as representing "delete". This is redefined by
this standard to the word-wrap clause given above.
IMPLICIT DISPLAY PARAMETERS:

Most defined algorithms include a number of parameters whose data type is
defined but whose display attributes, i.e., multiplier and decimal point locator,
are not defined. The following are the suggested methods of displaying these
data:
1) integer values: base 10, no decimal point, right justified.
2) hexadecimal values (used only in the Program block): base 16,
no hex point, capital H appended on the right, right justified.
3) the Input #0 and Setpoint of an AO or Pulse Width Modulated block
are always defined on a 0 to 100% scale but can overrange to a
limited extent. These values are always displayed with three
positions to the left of the decimal point. The left-most
display position can be used for a negative sign. If the actual
number is not within the range of -99.999 to +999.99, then the
Human Interface should display an error.
4) Real Numbers: if the value is inconvenient for the available
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
display field, say less than 0.1 or greater than 999, then
display the value in engineering notation (i.e., displayed with
an exponent of 10 where the exponent is a multiple of 3.
Finally, left justify the display of the value. This display
alternative will be seldom used and is restricted to parameters
of limited use to Operators.
These types of values can be displayed with descriptors implied in the
--```,``-`-`,,`,,`,`,,`---
algorithms, in the proper alphabet and language but with meanings faithful to the
parameter definitions in the algorithms.
Many of the algorithms also include discrete values whose state enumerations
are implicit. It is assumed that a Human I/F will provide a customized set of
enumerations, again in the proper alphabet and language but with meanings
faithful to the parameter definitions in the algorithms.

339
DEFINED DISPLAY RULES FOR SELECTED PARAMETERS

Certain parameters are to be displayed according to specific display rules.
Those rules are:
1) the physical device's SERIAL_NUMBER will be an unsigned integer. It
will be displayed in decimal notation with no decimal point.
2) the physical device's revision number, DEVICE_REV, and the Field Bus
revision number, FIELD_BUS_REV, will be unsigned integers. Once the
Human Interface has acquired the value, it will be converted to
decimal notation and displayed with a decimal point with the two least
significant digits to the right of the decimal point.
3) data base revision numbers will be unsigned integers and displayed
as a decimal number with no decimal point.
4) the ASK, BASK, and ACQUIROR are intended for the use of a higher
--```,``-`-`,,`,,`,`,,`---
level system. Therefore, there is no provision for translating the

integers to labels in a hand held communicator. It is assumed that
the higher level system will have some way of doing such a
translation.
A hand held communicator may, of course, include provision for

translating the integers to labels. Otherwise, the integer value
will be converted to decimal notation and displayed with no decimal
point.
REAL VALUES DEFINED TO BE IN "EXTENDED SI" UNITS:

Some of the algorithms, particularly the analog I/O algorithms, define
certain parameters as being in "extended SI" units, which are listed in Table 1.
The extended SI units list includes:
1) SI base units [meters (m), kilogram (kg), seconds (s), etc.]
2) SI supplementary units [Radian (rad) and Steradian (sr)]
3) Frequently used units derived from base units (m^2,m^3,kg/m^3,
etc.]
4) Derived units with special names [for example, Hz, W, Pa, etc.]
5) Combinations of units that appear in the denominators of derived
units.
All forms of the SI unit description can be reduced to a standard generic

form:
SI units = [ a * b * 10^(f-16)] / c
where: a, b, and c are instances from the list of extended SI
units.
f = a factor that defines the exponent of 10 multiplier
There are 6 items of information that are necessary to display a Field Bus
variable in extended SI units based on this generic form. They are:
1) The magnitude of the variable
2) The first numerator term of the engineering units description
3) The second numerator term of the engineering units description
4) The denominator of the engineering units description
5) The multiplier to use for display
6) The number of decimal places to display
The magnitude of a Field Bus variable will be under its own parameter. All of
the rest of the information will be packed into two words using a generic form.
Each of the SI units in the numerator and the denominator of the engineering
units description will be one of the items from the "Extended SI Units" list
shown in Table 1. This list includes defined units, provision for future defined
items, manufacturer specific items, and user specific items. The number next to
the item will be denoted as "a", "b", or "c" where each symbol can have a value
of 0 to 255.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
340
When the human interface or the server for a higher level device knows the
numerator and denominator units that are appropriate, it can, if desirable,
convert the number into any set of units that is appropriate for the user.
However, the Field Bus Standard does not provide for display scaling or decimal
point location for the converted value.
It will usually be appropriate to change the floating point multiplier of the

parameter value to some multiplier appropriate for display. This will be denoted
by the variable "f". The exponent used will be the value of (f-16).
Finally, the number of decimal places that should be shown in the display
must be defined. The number will be in the range 0-7 and will be denoted as "d".
Collecting the five variables together, we have:

1) Engineering Units first numerator value = a = 8 bits
2) Engineering Units second numerator value = b = 8 bits
3) Engineering Units denominator = c = 8 bits
4) Multiplier for display = f = low 5 bits of an octet
5) Number of decimal places to display = d = high 3 bits of an
octet.
The total of 4 octets will be packed into two words as:
First SI Units Word = a in the low byte
b in the high byte
Second SI Units Word = f in the low 5 bits
d in bits 5-7
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
c in the high byte
It is suggested that the following procedures be applied to display these

values (with units descriptor):
1) determine from the block type data in the HI/F device if the
data item has an associated SI Units parameter. If yes, read
the value. If not, determine the implicit value from the HI/F's
data about this algorithm.
2) convert the SI Units value to a units descriptor and display
format.
3) display the value in the defined format and right justified with
the given units descriptor. If the actual significant figures
to the left of the decimal point plus the sign, the decimal
point itself, and the requested places to the right of the
decimal point exceed the display capacity of the HI/F, first
round off up to the decimal point, then indicate an error.
--```,``-`-`,,`,,`,`,,`---
ANALOG VALUES WITH UNITS AND ATTRIBUTES:
Most analog I/O parameters and any analog Setpoints in defined function
blocks are provided with their own user-specified units, ranges, and decimal
point locator. In many algorithms, one display attribute will serve for several
block parameters. For example, the Setpoint, Input #0, and Input #1 in a PID
block all have the same display attributes. It is suggested that the following
procedures be applied to display these values with their units descriptor:
1) determine from the block type data in the HI/F device which data
item contains the display attributes.
2) Read the visible string containing the Units Descriptor. Also
read the display attribute. It is an 8 bit string that defines
the multiplier and the decimal point locator for display in the
following format:
bits 0&1: decimal positions to the right of the decimal
point, value = 0 - 3
bits 2-4: Multiplier for exponent of ten for display
bits 5-7: decimal positions to the left of the decimal
point including room for the sign, value = 0 -
8.
Definition for display exponent:
let the value in bits 2-4 = "a"

341
If a = 0, then the multiplier is to be 10^-2 (i.e.,

the value is to be shown as percent).
a<>0, then the multiplier is to be 10^3(a-4)
Thus, the multiplier can assume any of the set:
10^-9, 10^-6, 10^-3,
10^-2, 0, 10^3, 10^6, or 10^9
3) Display the value in the defined format with the given units
descriptor. If the actual significant figures to the left of
the decimal point exceed the positions requested, increase the
request for this display only. If the requested positions to
the left and right of the decimal point exceed the display
capacity of the HI/F, first delete leading zeros, then round off
up to the decimal point, then indicate an error.
4) If a graphical depiction is also to be displayed, step (1)
would also yield the data items that contain the upper and lower
display range to use.
There is one situation that requires special consideration for this display
type. What is the default value of the visible string for the Units Descriptor?
In the general case, the manufacturer does not even know the language that will
be used with the device! Therefore, a special notation will be defined and
available for use in the null data set.
If the manufacturer wishes to put a true visible string in the device as the
default value, that can easily be done.
An alternative for the manufacturer is to pack the entire string with spaces.
There may be times when it would be convenient to have Extended SI units

displayed until the user enters his visible string. Therefore, by definition,
the left-most (first) character of the visible string will be inspected to find a
special handling for the null data set. If the visible character is equal to the
"Field Bus Escape" command <FBE> [Char. 25 (base 10)] in two byte representation
with the high-order byte zero], the next 32 bits will be the Extended SI units
description described above and the rest of the Units Descriptor field will be
ignored. See Table 13 for a listing of the <FBE> commands.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
--```,``-`-`,,`,,`,`,,`---
DISCRETE VALUE WITH ENUMERATION SET CODE NUMBER:
Most of the discrete I/O parameters and any discrete Setpoints and PV's in
the Standard function blocks are provided with their own user-specified
enumeration codes. In many algorithms, one code will serve for several block
parameters. For example, the Setpoint, Feedback, and Output in the Device
Control Block all use the same code.
It is assumed that the Human I/F will provide, in the proper alphabet and
language, certain simple enumeration sets that have been defined by this
Standard. In addition, certain enumeration sets particularly applicable to the
Device Control Block are defined and may be provided by the Human I/F. The Human
I/F might also allow a user to enter other sets of enumerations corresponding to
the "manufacturer specific" and "user specific" code numbers. Table 2 (attached)
defines the code numbers for the defined enumerations. (The code numbers for the
enumerations are defined to be in the range of 0 - 255.) The "range" defines the
number of least significant bits in the bit string that are taken as the
enumeration.
Table 3 defines the three enumeration sets for binary, decimal, and
hexadecimal numbers. Tables 4 to 7 define a set of enumerations designed for the
Device Control Block. However, it is recognized that the length of the display
field and the desired alphabet and language will vary. Therefore, it is assumed
that a Human I/F will provide a customized set of enumerations with meanings
faithful to the meanings of the enumerations as given in Table 8.

342
Many discrete variables will have an associated "Display Code". This code is
based on a display model derived from panel-board lights - 1, 2, or 3 lights
being defined by one display code to display one discrete variable - up to 3 bits
long. An individual light will be assigned to one bit of the discrete variable.
By convention, the first "light" is at the top or the left of the display. Each
"light" is then configured with one of eight codes to define the display
characteristics of the light when the bit is set and 1 bit to define the display
characteristics of the light when the bit is reset.
Since the "Display Code" is set up for three lights, it will only consider
the low three bits of a discrete variable. Therefore, the bit connected to the
third "light" is determined by default once the first two connections are
defined.
The full detail of the Display Code word is:

Bits 0&1 - 00 = top (left) light connected to bit 0
01 = top (left) light connected to bit 1
10 = top (left) light connected to bit 2
11 = top (left) light not in use
Bits 2-4 - code between 0 and 7 defining the display format to use
for the top (left) light when the bit is set.
(this code is defined by the Human Interface)
Bit 5 - code of 0 or 1 defining the display format to use for
the top (left) light when the bit is reset.
(this code is defined by the Human Interface and may or
may not be defined in conjunction with bits 2-4)
(it is assumed that all zero's in bits 2-5 will result
in the light "disappearing" into the background of the
display).
Bits 6&7 - 00 = middle light connected to bit 0
01 = middle light connected to bit 1
10 = middle light connected to bit 2
11 = middle light not in use
Bits 8-A - code between 0 and 7 defining the display format to use
for the middle light when the bit is set.
Bit B - code of 0 or 1 defining the display format to use for
the middle light when the bit is reset.
Bits C-E - code between 0 and 7 defining the display format to use
for the bottom (right) light when the bit is set.
Bit F - code of 0 or 1 defining the display format to use for
the bottom (right) light when the bit is reset.
--```,``-`-`,,`,,`,`,,`---
It is suggested that the following procedures be applied to display these

values:
1) The Human I/F should provide a basic set of enumerations that
correspond to the enumerations defined in this paper.
2) The Human I/F should provide a method for the user to define
additional sets of enumerations and display code definitions.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
3) determine from the block type data in the HI/F device which
parameter describes the enumeration code and/or display code.
4) Read the code from the field device.
5) Obtain the enumeration display string or display information
from the table contained in the Human I/F device.
DATA SETS:
It is recognized that Human Interface devices will need to display values
quickly after an initial request for a particular display. In order to avoid
multiple access calls over Field Bus to support the initial call-up and
subsequent refresh of displays, each Standard Block will have several parameters
called "display sets". In general, there are complementary sets: the "call-up"
AND the "refresh" display set are needed for initial screen build while only the
"refresh" display set is needed for the equivalent refresh.

343
A display set will be defined for simple displays of the important tag data -
PV. If the tag supports the PV function, it will consist primarily of the PV,
Target, Output #0, the block mode, and the range and display information needed
to display them. If the tag does not support the PV function, the default
parameters defined for the PV function will be substituted. For example, the PID
defines its default PV pointers as Setpoint for the Target and Input #1 for the
PV. If the PV function is supported, the set will include the PV and Target. If
the PV function is not supported, the set will include the Setpoint and Input #1.
The "Tag" display set is designed for a summary of the whole tag knowing only
the tag name and its algorithm number. This set will be defined for every
standard algorithm and node. In general, this display set will be designed such
that the 117 byte message length is fully utilized but it will specifically
exclude the variables contained in the PV display set. Thus, a Human Interface
would only need to read four parameters (in parallel) to access most of important
data in a tag.
In all cases, the display sets will be less than 117 bytes long so that they
can be obtained with a single simple read command.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
MANUFACTURER PUBLIC DATA (Auto-Format Variables):

Most of the standard function blocks have been defined sufficiently to allow
interchangeability. Even so, there are still a number of situations in which a
function block or its associated physical hardware will include mathematical
relationships that are not defined in the standard, even as to the form of the
equation. For example, a differential pressure transmitter may include a complex
mathematical equation to calculate the differential pressure based on a primary
measurement, several secondary physical measurements, and several equation
coefficients that are unique to that particular device. Such equation
coefficients (or more generally, parameters) are called "manufacturer data". The
manufacturer may choose to provide the user with a method of calculating revised
--```,``-`-`,,`,,`,`,,`---
parameters. In that case, the user will need a method that allows him to enter
the parameters Using a human interface or a higher level device that is unknown
to the instrument manufacturer. This is called "manufacturer public data".
Attachment 1 defines a procedure call "auto-formatting". This procedure

allows a manufacturer to define a string of data in almost any arrangement. The
manufacturer can decide the extent to which he or the user can enter formatting
information in the same parameter that will allow a higher-level device to
interpret and display the data in the parameter. It also allows the user, if
allowed by the manufacturer's design of the device, to enter changes to the data
as well as to the format interpretation instructions for the data.
All of the auto-format variables will support two parameter numbers, both of
which access this value. The first parameter (low bit reset) will refer to a
data base structure that is in the exact form of the auto-formatting parameter
defined in Attachment 1. The second parameter (low bit set) will refer to just
the data portion of the same parameter (NOT the "header" NOR "format" portion).
In addition, when the Auto-Formatting variable is used in conjunction with I/O
hardware instances it will have two more parameter numbers. The first two
numbers will be used to access the parameter using the physical node tag name.
The third and fourth numbers will be used with the function block tag name. The
actual data for all four parameter numbers will map together, not into separate
data base values as is done with the status byte parameters.
Each tagged object (TO) will have a record in the "Data Dictionary" that is
kept by every application layer on the Field Bus. This data is available quickly
to each higher level device. In that data record (see the paper "Application
Support Services Interface" for the definition of these records), there will be 3
six bit unsigned integers that define the number of auto-formatting variables
that are present in the data base. Since they will have sequential parameter
numbers in known ranges, they can be directly accessed by a human interface.

344
Using this procedure, the manufacturer can define a new variable in the data
base, including the auto-formatting format data and a default descriptor. The
user can, if the manufacturer allows it, change the format data and/or the
descriptor. For example, the user could change the language of the descriptor.
A human interface that knew nothing about this variable could determine that
it exists by inspecting the information in the data dictionary on "its end" of
Field Bus. It could then read the full variable to determine the formatting and
descriptor information needed to build a display. For refresh information, the
human interface could read the parameter number one higher to obtain just the
dynamic data from the variable.
The manufacturer specific data that is contained in the physical node's data
base is assumed to be specific to the physical node, not to the service in which
the physical node is currently applied. For example, calibration data for a
transmitter measuring a flow rate would be specific to the transmitter, not to
the flow measurement application. Therefore, the auto-formatting variables that
are hardware related (i.e., that are in the physical node's data base) WILL NOT
be covered by the physical node's data base revision number and should not be
included in any images of the data base retained by higher level devices for
purposes of restoring a physical node's data base. It is assumed that this data
will be stored in retentive memory in the physical device.
This standard does not address the handling of "manufacturer private data" as
would be encountered in a situation where the manufacturer has a unique entry
procedure or violates the definition of the parameter data string given in
Attachment 1.
EXTENDED PARAMETERS:
A manufacturer may optionally include parameters in a tagged object in
addition to the ones defined by the Standard. The Auto-formatting variables
defined above are one form of such extensions. Another form is defined in some
function blocks; they give the formatting information in defined and directly
addressable variables. The Standard includes an array of names for these
parameters and a method of indicating the existence of them using a special
"options bit string" defined for the algorithm (see the definition of EXTEND in
the paper "Interoperable Generic Block"). Although both of these procedures
extend the data base of a defined tagged object, they are not referred to as
"extensions"; that word is reserved for the next procedure.
--```,``-`-`,,`,,`,`,,`---
The options bit strings for all tagged objects that are stored in the data
dictionary (called "PN", "LN", or "FB") will include an "options bit" that will
indicate the existence of yet another form of extension. If the bit used to
indicate the existence of extension variables is set, one of the parameters
"EXP0", "EXL0", or "EXB0" must exist in the data dictionary. See Attachment 2 -
"Extended Parameters" to the paper "Application Support Services Interface" for a
detailed explanation of this procedure.
Note: it might be well to note again that a block that ADDS parameters
to a Standard function block, and defaults back to the Standard
block functionality if the parameters are never changed from their
default values, is called an "Extended Standard" block. The above
are three ways of adding the extended parameters.
A block that adds parameters to an Alternate block, and defaults

back to the Alternate block's functionality if the parameters are
never changed from their default values, is called an "Extended
Alternate" block. A block that adds parameters and does NOT
default to a Standard or Alternate function block's functionality,
is called a "Generic" block.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
345
PHYSICAL NODE CLIPBOARD:

A manufacturer can optionally include a "clipboard" in a physical device's
data base. The clipboard is intended to provide the ability for the manufacturer
and/or the user to enter free-format visible strings that can be accessed and
displayed by generic human I/F devices. However, in order to allow relatively
simple HI/F devices to display and enter this data, the data format must be
somewhat constrained.
In addition to the free-format visible strings, the clipboard may also

contain specially coded data sets that will provide material of construction data
for physical I/O hardware and for coded data that will provide easy entry of user
maintenance information. The following is a list of all of the clipboard
information that has been planned:
1) codes to identify the hardware I/O point being described.
2) "part/material" groups to describe the material of construction of
parts of a device.
3) visible strings entered by the manufacturer.
4) codes to indicate that one or more of the part/material groups
(possibly recorded in ROM) should be ignored.
5) visible strings entered by the "Shop" or "Calibration Laboratory" of
the user.
6) "maintenance activity" groups to describe a particular maintenance
event.
7) visible strings entered by or for the maintenance person.
8) automatically entered "triggered calibration" records.
Delimiters defined by this standard will allow the type of the record to be
--```,``-`-`,,`,,`,`,,`---
identified and, in the case of items (1), (2), (4), (6) and (8), decoded
into any language and display format.
The following procedures are designed to provide a method of entering

materials of construction of the Field Device in a highly coded form. A
manufacturer can also choose to enter that information as visible strings. The
use of the coded form is strongly encouraged for the following reasons:
- achieves language independence for the Field Device.
- much more compact form - saves memory, Field Bus capacity, and display
time.
- much more explicit.
- allows human interfaces to choose the best display format.
- allows a higher level system to do on-line searches for instances
of specific materials of construction.
- allows a higher level system to form an "Instrument Record System"
data base that can be easily manipulated (i.e., searched for specific
materials of construction and sorted by any of the parts codes or
materials of construction).
Because of the above considerations, there are two bits in the physical node
options bit string that allow higher level devices to determine the style and
scope of the clipboard data. The first pertains to the style: if all entries of
parts/material of construction are as fully coded as is permitted by the Standard
(the codes given in the following coding methods contain all the information
presented but redundant visible strings permitted), then the "coded" bit is set.
The second pertains to the completeness: if all parts of the device that, in
normal operation, come into contact with the "process fluid/material" have
materials descriptions in the clipboard information (as shipped from the
manufacturer), then the "complete description" bit is set.
To illustrate the use of the codes, assume that a manufacturer included some
materials of construction as coded information in the clipboard, some other parts
were described using visible strings, and two process-wetted gaskets were not
described at all. Neither of the two bits can be set. If the two gaskets were
also described, then the "complete" bit could be set but not the "coded" bit. It
the coded material covered all parts and some of the parts were ALSO described
with visible strings, then both bits could be set. Even without the visible
descriptions, both bits could be set in the last case. If the device included a

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
346
wetted part for which there is no part code, both bits can be set even though
that part is described but not coded.
The clipboard will have multiple "pages". Each page will be 116 bytes long
so that it can be read in one Field Bus command and be easily handled by a simple
human I/F. The physical node data base MUST include the parameter - MAX_CLIP_P
if bit 5 in the physical node options string is set. This is a 16 bit binary
string that is read-only. If bit 5 is set, MAX_CLIP_P must be 1 or greater. Its
low 8 bits define the maximum number of 116 byte "pages" of clipboard information
that this device supports (255 or less). The rest of this discussion assumes
that bit 5 in the options string is set.
Three other variables must be present to support the clipboard if bit 5 is

set. The integer variable CUR_CLIP_P will contain the number of the current last
page of the clipboard that is in use (zero based count; i.e., if clipboard page 0
is the only page currently in use, CUR_CLIP_P = 1) . This value must, of course,
be less than, or equal to the value of the low 8 bits of MAX_CLIP_P. Each page
will be accessed using the parameter name for clipboard pages plus an index
identifying the page. The first CUR_CLIP_P pages will contain useful
information.
The manufacturer may decide to make part of the clipboard read-only. This is
permitted by the introduction of the third required variable. This is an integer
that defines the number of pages, from the beginning of the clipboard, that are
read-only. Rather than defining a new Field Bus parameter, the high order 8 bits
in MAX_CLIP_P are used for this variable, leaving the low 8 bits for the number
of pages. Hence, the clipboard "book" can be a total of 255 pages (29,580 bytes)
long and any part of it (in whole pages) can be read-only.
The final variable that is needed is CLIP_REV_P, a standard 16 bit revision

number for the total set of clipboard pages (the whole book). This number will
be set equal to zero when all of the following are true:
1) the physical device just started.
2) all or part of the clipboard is implemented in static (not ROM)
memory.
3) static memory integrity was lost during the shut-down.
When the revision number is reset, CUR_CLIP_P will be set equal to the size of
the read-only portion of the clipboard book divided by 116 and rounded up. At
all other times, the revision number will simply be incremented by one every time
there is a change to the clipboard.
The above discussion and the one that follows are based on a relatively
simple implementation model of the clipboard. It is assumed that the first
portion of the clipboard is contained in ROM type memory, not volatile nor
changeable. The size of this portion is defined in the high 8 bits of
MAX_CLIP_P. Then, the clipboard can continue into writeable memory. This would
be the area where user-entered data would be stored. This second portion of the
clipboard might have a check-sum or other type of validity indicator. None of
the clipboard is modeled as being in dynamic type memory.
The data that is contained in the clipboard is assumed to be specific to the

physical node, not to the service in which the physical node is currently
applied. For example, the materials of construction data for a transmitter
measuring a flow rate would be specific to the transmitter, not to the flow
measurement application. Therefore, the clipboard data WILL NOT be covered by
the physical node's data base revision number and should not be included in any
images of the data base retained by higher level devices for purposes of
restoring a physical node's data base. It is assumed that this data will be
stored in retentive memory in the physical device.
There may be instances in which some of the data in the clipboard is in fact
service, not device, related. For example, many of the maintenance instances
will be in this category. It is assumed that the higher level system will
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
retrieve such data and delete it from the clipboard rather than maintain it in
the device's clipboard.
--```,``-`-`,,`,,`,`,,`---

347
It is recognized that there will be instances when two separate clipboards

will be advantageous. The second clipboard can be used in any device. Its
presence, style, and scope is indicated by bits 6, 9, and AH in the physical
node's options bit string. There is one situation in which its use is required.
If the Field Device is a scalar output hardware device that is easily dismounted
from the physical device that it controls, as a valve positioner is easily
removed from a control valve, then the positioner clipboard data must not be
mixed with the valve clipboard data. If the manufacturer puts clipboard data for
both devices in such a scalar output hardware device, then the manufacturer will
support a second clipboard and separate the data.
The second clipboard will contain data for the "associated" device. The
second clipboard will operate exactly the same as the first. Its parameter names
will be the same except that the "_P" (for primary) will be replaced with a "_A"
(for associated). The actual parameter codes will, of course, be a separate set
of integers. For the rest of this paper, the general term "clipboard" will refer
to either the primary or associated clipboard.
The hierarchy of the clipboard structure is based on the terms used by the
standard control commands:
- a "file" corresponds to an entire page of the clipboard; its beginning
and end are indicated by "file separator" commands <FS> [Char.
28 (base 10)].
- multiple groups can exist in one file. A group can not span files
(and hence can not span clipboard pages). The "group separator"
command <GS> [Char. 29 (base 10)] is used to indicate the beginning
and end of one kind of group - a part/material description. The "Field
Bus escape" command <FBE> [Char. 25 (base 10)] is used in
conjunction with sub codes to indicate the beginning and end of all of
the other types of groups.
- multiple records can exist in one group. Within the clipboard, the
<FBE> escape command is used to indicate the beginning and end of
all records.
- the concept of "units" is not used in Field Bus.
- a "field" is a general term that can be either a group or a record.
The clipboards must be formatted using certain rules. First, no file, group,
or record can span two clipboard pages. Second, most files, groups, and records
must start and finish with defined parsing commands. The only exceptions are the
fields that have an explicitly defined structure. Table 10 provides the single
character non-print commands that will be used in the clipboards, Table 11
provides the single character printable characters that will be used, and Table
13 details the <ESC> and <FBE> escape command structures.
One of the functions of the clipboard is to provide a method of storing and

displaying the materials of construction of the physical I/O devices. The
following two strings of information, all in encoded form, can be entered in any
of the groups. The first string defines the hardware I/O to which one or more
material of construction codes will refer. The second string codes the
part/material of construction information. There can be multiple instances of
either string and they can appear in any group in the clipboard
1) the non-printable command<FBE><#> [Char. 25 (base 10) + Char. 35
(base 10)] that indicates that all I/O hardware material of
construction references in the clipboard after this position and
before the next such command refer to the particular hardware I/O
point defined by the next several characters:
a) two letters and an integer that define the particular hardware.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
The two letters will be the letters used to identify the types
of hardware points in the paper "Data Owner Structure -
Hardware", page 3 and will be entered as capital alpha visible
characters - one byte representation. The integer will be
entered in the form of 1 to 4 numeric visible characters - one
byte representation - and will indicate the index of the
hardware point (using zero based numbering).
b) The numeric characters can optionally be followed by the visible
character representing a dash (-) [Char. 45 (base10)]. The
dash indicates that a range of hardware I/O points are to be
--```,``-`-`,,`,,`,`,,`---

348
referenced. If the dash is entered, it must be immediately

followed by another integer. Again, the integer will be entered
in the form of 1 to 4 numeric visible characters and will
indicate the index of the hardware point of the (inclusive) end
of the range of hardware points being referenced.
c) there are no terminators for this string because its form is
defined.
2) a non-printable command<GS> [Char. 29 (base 10)] that essentially
says: "the code numbers for a part and its material of construction
follow". This command must be followed by:
a) the code number for a part as defined by this Standard (Table
15).
b) a non-printable command<RS> [Char. 30 (base 10)] that says: "a
Standard material definition follows".
c) a Standard material description as defined in Attachment 2.
d) a non-printable command<US> [Char. 31 (base 10)] that
essentially says: "that is the end of the Standard material
description.
e) a repeat of the <GS> command that, in this context, essentially
says: "the code numbers for the part and its material of
construction are finished".
All of the information is entered in coded form so that a Field Device does
not have to contend with different languages.
The particular hardware point must be identified even if the device only has
one hardware point so that a search of the clipboard by a higher level device can
be relieved of determining the type of field device. A set of 5 to 13 characters
corresponding to item (1) above can be inserted any place in the clipboard, thus
allowing several hardware points to be described. One special case is defined:
if all of the instances of a particular hardware type, for example all of the
SI's in the physical node, are to be referenced, the visible character for space
[32 (base 10)] will be taken to mean "all". In this special case, item (1) above
reduces to only 5 total characters.
Table 14 gives a listing of "standard" device parts. This list of parts is

designed to allow the definition of those parts whose materials of construction
are of interest to the user. This standard does not include coding intended to
describe the total physical construction of the device. It is assumed that that
information is largely implied by the manufacturer's model number. It is
intended that the code for one of these parts will form one-half of each coded
"part/material of construction" set in the physical node clipboard. For example,
a set may indicate that "for SI-2, the body material is 316 stainless steel".
The "SI-2" is defined by item (1) in the list immediately above; the "body" is
defined by item (2a); the "steel" is defined by (2c).
Table 14 is arranged by device type/function. It is intended that a code

from the list for a particular device type be used preferentially in the
clipboard. The first alternative, if a suitable part is not coded, would be to
use the code for a part defined for some other device type. Either of these two
approaches is considered "coded" for purposes of setting the coded bit in the
options bit string.
Table 15 includes codes T0 - T9 for parts called "Temp-Partx" where "x" is a

digit between 0 and 9 that corresponds to the units digit of the code. Temp-
Partx can then be defined in the free-format section of the clipboard. It is
intended that these codes would form a second alternative if no specific part
name in Table 14 is appropriate. A third alternate would be to use a
manufacturer specific code number and define the part in the free-format part of
the clipboard or in the manufacturer's documentation. However, neither of these
procedures meet the requirement of the "complete" bit defined above IF any coded
part is appropriate; they are NOT considered as "coded".
The parts listed in Table 14 are consolidated, alphabetized, and assigned a

code number in Table 15.
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
349
Attachment 2 defines a system for describing the Standard materials of

construction and their code numbers.
There are two features of Table 13 that require some explanation. First, it
is anticipated that some manufacturers will enter the materials of construction
in read-only memory. However, it is possible that maintenance on the hardware
will result in major changes to the materials of construction. Since the
materials of construction data is in ROM memory, it is not changeable by the
user. One alternative is to enter new information to override each of the
earlier entries. By definition, the later enter will override the earlier entry.
A second sweeping method is also provided: there are two codes in Table 13 that
can be used to indicate that all of the materials of construction in the portion
of the clipboard before the code are to be ignored. One code applies to the
individual hardware I/O currently defined (i.e., the last statement by item (1)in
the above list). The other code clears ALL of the materials of construction
information.
The second feature of the table that requires explanation is the presence of
two formats for time: code letters "B" and "C". The purpose of having both
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
formats is to allow flexibility for alternate sources of the data. If a human
enters the data, it is advantageous to have a variable precision. Alternately,
if it is entered automatically by the field device or the hand held communicator,
it is simpler to use the format of the Field Bus's social time. This also makes
it practical for a simple hand held communicator to not support the code required
to convert one form to the other and to not have the conversion code in the field
device itself.
Given that a method of describing parts/materials of construction is

standardized, it is simple to plan for a second group in the clipboard for the
use of a "repair shop" or "calibration laboratory". Although a field device
manufacturer would not enter any data in the clipboard for this group, the
manufacturer could anticipate the clipboard space that this type of record would
need. In addition, manufacturers of Human Interface devices could include menus
and entry methods to assist in the use of this area.
--```,``-`-`,,`,,`,`,,`---
Another function that has been standardized for the clipboard is a method of
storing and displaying data on field maintenance activities. Again, the
manufacturer of a field device can only anticipate the need for clipboard space
for this information. However, since the information would be entered by a "hand
held human I/F" and extracted by higher level control systems, there is a need
for standardization of the coding procedures.
Therefore, the "Maintenance activity group" is defined. It is anticipated

that a separate group would be used for each "activity".
The first record in a maintenance activity group - a time stamp - is

optional. It might be entered by the maintenance person and be in the form of
<FBE>. Alternately, it might be inserted automatically by a "hand held human
interface" and be in the form of <FBE><C>. Table 13 indicates the details of
these two codes.
The second record in the group - the identification of the maintenance person
- is independently optional. Again, Table 13 indicates the details of this
record. It is intended that the field be relatively small, enough for a person's
initials, identification number, etc.
The third record in the group - the "maintenance work order number" - is also
independently optional. Table 13 indicates the details of this record. It is
intended that the field be simply a string of printable alpha-numeric characters.
The next record is the one that must be defined in order to achieve
integration of the hand held human interface and the higher level control system.
Table 16 gives the details of a record that contains three fields: two characters
to describe a device component, one character to describe the maintenance
activity trigger, and two characters to describe the result of the activity.
Coded values for each of the fields are given in Table 16. It is the intent of

350
--```,``-`-`,,`,,`,`,,`---
the Standard that both the hand held human interface devices and higher level
control systems would incorporate methods of allowing easy use of these codes.
The final group that is defined for the clipboard is defined in the following
section - the automatic record entered by the optional "triggered calibration"
service.
A higher level device will address each clipboard page by its

parametername/index. If it writes a clipboard page, it will use the special
command provided by the complex write services of the Data Base Write Service.
TRIGGERED CALIBRATION:
Most of the interaction between a human and a Field Bus device will be with
specific Tag.parameter values and will not involve complex scenarios. However,
one exception to this generality concerns the user calibration of I/O devices.
Many of the Input and Output blocks will include a set of parameters, including a
trigger mechanism, designed to simplify device calibration.
The basis for the design of the procedure is:
1) it is assumed that true "calibration" will be done in a "shop"
environment and will use the procedures and Auto-formatted variables
defined by the manufacturer. The procedures may well include some
sort of human interface that is knowledgeable about the instrument
model being calibrated. Standard Field Bus devices will handle these
variables as Auto-format variables.
2) Since most of the "field calibration" done by a user will involve no
more than 2 calibration points, frequently only one, Field Bus will
only support linear calibration of field devices by the user.
3) Each analog I/O algorithm will define the proper place in the
procedure for the user calibration. For example, it will adjust the
value of Input #0 in the AI blocks, the value of "Feedback" in an AO
block with actual positional (measured) feedback, and it will adjust
the physical output for AO blocks without feedback.
4) In the calibration procedure, the user will set the external variable
and indicate the proper value of the function block value to the
Field Bus device. For example, he will set the actual analog input
variable and define the correct converted value in the AI block. For
an AO block with no feedback, he will set the output at a position
and define to the AO block the correct output value in percent. For
an AO block with feedback, he will set the valve position and define
to the AO block the correct feedback value in percent.
The steps of the procedure are:

1) The user will select one of two calibration procedures:
a) calibration at one "target calibration" point with the
correction at the other point not changing (this can, of course,
be followed by the calibration of the second calibration point).
b) the calculation of a bias at one "target calibration" point with
the bias applied equally to both points.
2) The user enters a "target value" for the reading corresponding to the
external signal he will set.
3) The user will set the block to the defined mode - LO mode for an
input block, Man for an output block.
4) The user will apply the proper external signal to an input sensor or
adjust an output to the specified position.
5) The user will set the value of a bit string to indicate his choice of
procedures from item (1) and to indicate that the calibration signal
is set.
6) The field device will calculate the adjustment that it must make to
its calculation equations. Note that the adjustments are always
linear vs. two user-defined calibration points.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
351
The parameters in the calibration set are defined using an "upper" and
"lower" notation. By definition, "upper" will refer to the algebraically larger
value of the "calibration unit value". The triggered calibration procedure
involves a total of seven parameters:
1) LO_CAL and HI_CAL:
The lower and upper current calibration points - the measurement
value at which the currently active calibration curve was determined.
32 bit floating point numbers - in units defined by the algorithm
2) LO_ADJ and HI_ADJ:
The lower and upper adjustments - the actual adjustment included in
the device's displayed value that is being used at the upper and
lower calibration points. 32 bit floating point numbers - in the
units defined by the algorithm.
3) LO_TARGET and HI_TARGET:
The lower and upper target calibration points - the measurement value
at which the current calibration is being done or the points for
which the adjustments are to be shown. 32 bit floating point numbers
- in units defined by the algorithm
--```,``-`-`,,`,,`,`,,`---
4) LO_TARGET_ADJ and HI_TARGET_ADJ:

The adjustments that would be used at the lower and upper target
values 32 bit floating point numbers - in the units defined by the
algorithm.
5) TRIGGER:
The trigger bit string: 8 bit binary string
bit 0 - calibrate lower
1 - calibrate upper
2 - bias adjust based on the lower point
3 - bias adjust based on the upper point
4 - zero both bias values
5 - 7 reserved.
The function block will immediately reset all eight bits when it does
the action of the lowest bit set. For example, when bits 1-4 are
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
set, the action of bit 1 will be executed. After the action is done,
all of bits 0-7 will be reset.
Bit 0 (or 1):

The block will set the lower (higher) calibration point to the
lower (higher) target point, and calculate a new lower (higher)
adjustment. Internally, it will start using a modified user
calibration curve but the curve will still pass through the
higher (lower) calibration point as determined at the previous
calibration.
Bit 2 (or 3):

The block will set the lower (higher) calibration point to the
lower (higher) target point, and calculate a change to the lower
(higher) adjustment. It will then add the change to BOTH the
lower and higher adjustments. It will then use the shifted
calibration curve. The shifted curve will not pass through
either of the former points.
Bit 4:
The adjustment at both the lower and higher calibration point
will be set to zero.
The first 6 parameters will be stored in the NORMAL STATIC DATA BASE of the
function block and they will be under the associated static data base revision
number.
The first eight values are always "alive". Each cycle, the function block
will calculate the 2 adjustments it would make at the 2 target values. The two
calibration values always indicate the last calibration points. However, there is
one misleading situation built into this design. Consider a differential
pressure transmitter calibrated at 0 and 100 inches of water. Later, the user
does a bias adjustment at 0 inches of water. The adjustment at 100 inches of
water will change because it will include the same bias adjustment as was

352
determined for 0 but there is no indication that the bias adjustment was done.
Everything in the data base is consistent with the original calibration at 100
inches still being the true basis for calibration at 100 inches. It is assumed
that the user's maintenance procedures will consider this situation.
A manufacturer may choose to provide one optional, Standard extension of the

functionality described above: automatic data recording. This option is
indicated in the non-time critical options bit string of the logical node and can
only be activated in logical nodes that support triggered calibration and that
exist in physical nodes that support a clipboard that consists of at least one
page in writeable memory. The non-time critical options bit string is defined on
page 23 of the paper "Data Owner Structure - Logical Nodes". The variables and
codes used below are defined and explained in the current paper, page 14 and in
Table 13.
If this option is supported, then the following additional steps will be

appended to the above procedure:
7) the algorithm will use the clipboard variable CUR_CLIP_P to locate
the current end of the clipboard data. If there is insufficient room
remaining in the CUR_CLIP_P page for the following record, then the
next page, if it exists, will be used and CUR_CLIP_P will be
incremented by 1. If there are no further pages available, the
complex write command will fail.
8) The following "group" will be added to the clipboard (see Table 13
for the exact characters defined to represent the following codes):
- Field Bus escape.
- character designating the "start of triggered calibration group".
- the tag name in visible characters BUT WITH ALL SPACES ELIMINATED.
- character designating the start of binary data.
- the TRIGGER byte.
- the high order three bytes of Social time, low order byte first.
- the new LO_CAL point in 4 byte floating point notation, low order
byte first.
- the new HI_CAL point in 4 byte floating point notation, low order
byte first.
- LO_ADJ at the new LO_CAL point in 4 byte floating point
notation, low order byte first.
- HI_ADJ at the new HI_CAL point in 4 byte floating point
notation, low order byte first.
- the ADJ_MV that would have been used at the calibration point.
using the old calibration in 4 byte floating point notation, low
order byte first. See the algorithm pseudocode for the definition
of ADJ_MV.
- Field Bus escape.
- character designating the "end of triggered calibration group".
Note that this record is one of the few in the clipboard that
contains binary data. The binary data portion must be exactly 24
bytes long and must follow immediately after the indicated
escape/code and be followed immediately by the indicated escape/code.
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
353
--```,``-`-`,,`,,`,`,,`---
Attach. 1 Auto-Formatting
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Most of the parameters that are defined for the Standard and Alternate
function blocks are single value parameters with detailed, widely known
definitions. However, there are some instances, particularly for the I/O blocks
and blocks with extensions, in which a manufacturer needs the ability to include
sets of data in the device that are not defined in the Standard and to provide
read/write access to the data. This section will describe the autoformatting
procedure that is defined and available for use in Standard Field Bus devices.
This method supports the display of multiple values from one parameter.

INTRODUCTION
AUTO-FORMATTING PARAMETER STRUCTURE
DETAILED DEFINITIONS
Parameter Header
Read Message
Write Message
Data and Detail Format Area
STANDARD FORMATS
OVERVIEW OF THE AUTO-FORMATTING METHOD
DETAILS OF THE AUTO-FORMATTING METHOD
Detail Flow Word
Data Format Word
Detail Control Word
Table 1 - Code Values for Data Display Types
Figure 1 - Auto-Formatting Parameter Layout
Figure 2 - Auto-Formatting Parameter Header
Figure 3 - Auto-Formatting Detail Words
INTRODUCTION:
The Standard defines several parameters that are combinations of
configuration data words. For example, the Boolean operators that can be
included in some function blocks combine all of their configuration data into one
parameter. These parameters are defined to be of the type described here. This
provides the mechanism for (selectively) writing to the data.
If the manufacturer chooses to provide the memory room, this procedure

provides a method for including user-defined formatting, visible character
descriptors, and access control data. However, some data parameters may be too
complex for the formatting rules of this procedure. For example, the Boolean
function configuration is too complex to format but the procedure can be applied
to the simple case of pointer configuration. The complex parameters defined by
the Standard can be formatted by higher level devices because the combination
rules are defined in the Standard and apply to all instances of the parameter.
This procedure can support selective writing into the parameters even if they are
too complex to format.
A basic assumption of this procedure is that the Field Device itself

interacts with the data - either it generates the data or uses it or both - and
therefore the data can not be rearranged within the device's data base.
The following description is written based on a simple model of the

procedure. Specifically, it is assumed that the data base parameter is stored in
the field device's data base in exactly the same form as the data that is
returned by a read of the parameter. This is certainly not required but is used
to frame the words of the following description. Any Standard implementation
need only provide the same functionality as viewed from a higher level device on
the Field Bus.

354
AUTO-FORMATTING PARAMETER STRUCTURE:

The total variable can be up to 232 bytes long. The contents of the
parameter will be arranged in the following fashion (illustrated in Figure 1 -
"Auto-Formatting Parameter Layout"):
1) Mandatory 2-word "Header":
The header will indicate the total number of words in the
parameter, the code number of the formatting definition being
used, and certain definition data that can not be changed by the
user.
2) Parameter Data:
This data is in a contiguous field starting with parameter word
2 (zero based) and can be no more than 56 words (112 bytes) in
size.
The parameter data itself may be generated or used by the field
device.
It is assumed that the user can not rearrange the data because
the Field Device was designed for a particular arrangement of
the data.
3) Optional Detail Format:
Present only if the field size definitions in the Parameter
Header indicate that there is room for format information.
Must start on a 16-bit boundary at the end of the parameter data
area.
The data field size is not defined but the total length of the
variable can not be greater than 116 words (232 bytes).
The parameter data layout is defined by the format data using
the formatting method specified in the Parameter Header.
The manufacturer may choose to leave no room in the parameter for the detail
format. He may choose to install all of the detail format and not allow the user
to change it. Between those two extremes, he may choose to provide space for the
parameter to be expanded from its original size by the addition of user-
configured detail formats. In any event, the field device is assumed to totally
ignore the detail format information - it is assumed to simply store the data for
the higher level devices. It makes the format data available to be read and, at
the manufacturer's option, can accept writes into the format data area.
An auto-format variable is a single data field in a Standard Field Bus

device. Every instance of the parameter will be assigned two parameter numbers:
a base number that is even (low order bit reset) and the next higher odd value.
By definition, the even parameter number will refer to the entire variable as
defined in this Attachment. The odd parameter number will refer to the parameter
header plus the data portion of the variable. The message returned by the odd
parameter will be identical to the first portion of the message returned by the
even parameter.
The maximum sizes of the total variable and the data field allow either
parameter to be written using any one of several of the "complex write services"
defined in the paper "Data Base Write Services" without overflowing one or two
words into another message segment.
DETAILED DEFINITIONS:
Parameter Header:
The format of the Parameter Header is diagrammed in Figure 2 - titled "Auto-

Formatting Parameter Header".
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:
--```,``-`-`,,`,,`,`,,`---

355
The most important function of the header is to provide the number of bytes
in the entire parameter or write message. If the manufacturer allowed extra room
for detail format information but the user has not yet used that room, then that
room will NOT be included in this value. The parameter "N" is defined as one-
half of this number - the number of words in the message. The total number of
bytes must be an even number so that N is a whole number.
When the parameter is read, the first byte of the response message will be
the size of the parameter as read from the data base. In a write command, the
size of the write message will be contained in this location.
The second byte of the parameter's header is the code number of the
formatting procedure that is to be used for the parameter data. The first 64
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
code numbers are reserved for use by the Field Bus Standard. The second 64
numbers are reserved for Field Device manufacturers. The third set of 64 codes
are reserved for manufacturers of higher level devices while the last 64 are
reserved for user-specific applications.
The third and fourth bytes of the parameter or write message will be referred
to as "word 1". The format of this word will be significantly different
depending on whether it exists in a read (i.e., in the parameter data base) or in
a write message. This word is the only one in the whole parameter that can never
be actually written into the device's data base by a Standard Field Bus write
message.
In a read, the following format is defined:

--```,``-`-`,,`,,`,`,,`---
1) The low order 7 bits define the start of the detail format area in
the parameter. The value entered is the starting word number ("F")
based on 16 bit words and a zero based numbering of words in the
parameter. This value can not be less than 3 because the header is
in words 0 and 1 and there must be at least one data word.
2) Bits 7 through CH define the maximum possible size of the parameter.
No write message can write data beyond the end of this area. The
integer value in this field is the maximum size, in words ("M"),
divided by 2. Therefore, the maximum size of a parameter - M - must
always be an even number of words.
3) Bit DH will be set if the user can not write into the format area.
4) Bits EH and FH define the minimum priority mode-level access to the
data area:
00 - Read only - the user can not write to the data area.
01 - Write only in O/S mode
10 - Write only in Man or O/S mode.
11 - Freely writeable.
This code identifies the minimum priority mode-level required to
execute a write. It is the most severe restriction needed by any of
the data in the parameter. The detail formatting can relax the access
for selective writing of the less critical parts of the total data
set. However, it can never relax code 00.
In a write message, the following format is defined:

1) The low order 7 bits define the number of the word in the parameter
at which the written data will start. It is again a number based on
16 bit words and a zero based numbering of words in the parameter.
This value can not be less than 2 because the header is in words 0
and 1.
2) Because of the existence of status bytes for many of the integers and
floating point numbers, there will be frequent occurrences of data
items that have an odd number of bytes. Therefore, an easy method of
masking off the first or last byte of a write is provided. If bit 7
is set, the first byte of the write will be masked off. If bit 8 is
set, the last byte of the write will be masked off.
3) Bit 9 is spare. It will be reset until defined by the Field Bus
Standard.
4) Bit AH will be set if the value (2*N) of the write message is to be
placed into the parameter data base. [If this bit is set, then the
value of the writing method code (see below) must be 0 or 10B].
5) Bit BH will be set if the procedure code in word 0 of the write

356
message is to be placed into the parameter data base.

6) Bits CH and DH will contain a writing method code. The four possible
values for this code and their meaning are:
00 - a normal write message, all words 2+ written to the data base.
01 - a masked write. The write message will contain 16 bits in
--```,``-`-`,,`,,`,`,,`---
word 2 that are to be written through the mask in word 3 and

into the location specified by the low order 7 bits. The only
bits in word 2 that are actually written into the data base
are those whose corresponding bits in word 3 are set. Those
two words are then followed in order by "n" sets of data and
masks to the end of the write message. If bits 7 and 8 are
used simultaneously with a masked write, either masking method
will prevent the write.
10 - a "long" write. In this case, the higher level device is
writing the detailed format words but did not "bother" to
delete the parameter data from the string before writing it
down. The Data Base Write Service has access to the parameter
"F" in the low 7 bits of word 1 of the parameter in the
device's data base. The words that are to be actually written
to the data base start in word "F" of the write message.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
11 - Illegal
7) Bits EH and FH define the "minimum" mode that must exist at the time
of the actual writing of the message data into the data base.
00 - Error - a write message can not contain 00 in this location.
01 - Write the message only if the block is in O/S mode
10 - Write the message only if the block is in Man or O/S mode.
11 - Any mode will do.
Data and Detail Format Area:
The data area will be considered to be composed of "data items". Most of

these data items will be complete data entities and will be displayed as a
display variable. However, there are several instances in which data items are
combined into a display variable. For example, the eight bits of a displayable
character constitute a data item but the procedure allows the characters to be
assembled into a string for display. The following discussion will refer to data
items being combined into display items.
In a read message or in the parameter data base, the data will start in word
2 of the record and continue through to the word before the start of the detailed
format area [i.e., through (F - 1)]. This area's data format method is defined
by the format code in the second byte of the parameter's data base.
In a write message, there is almost no distinction between the parameter data

and the format area. Rather, the write message indicates the word in the
parameter at which the written data is to start. The first byte of the write
message indicates the number of words in the write message (N). If the code
number in bits CH and DH in word 1 is 0, then the number of words to be written
is (N-2).
If the code is 1, then the number of words to be written is (N-2)/2. This

follows from the fact that N is the total length of the message, there are two
header words, and each word to be written has an accompanying mask.
If the code is 10B, then the higher level device did not "bother" to remove
the parameter data from the message string that it read up before modifying the
detail format data and writing it back to the field device. In this case, the
parameter data words in the written message must be skipped. Thus, the words to
be written start in word F of the write message. The value in W will still be
honored as the starting point in the parameter although it is expected that W
will almost always be equal to F in this particular case.

357
The code is not allowed to be 11B because there is no practical need to

retain the format of the original read when the higher level device formats a
masked write.
STANDARD FORMATS:
At this time, there are relatively few Standard formats defined. They are:
0 - Default the parameter data is to be assumed to be a set of 32 bit

floating point numbers that are to be displayed in
scientific notation (i.e., the exponent is adjusted to
have one digit before the decimal point). The human
interface will determine the number of significant figures
displayed. The values will be assumed to be in static
data, to contain no status bytes, and to be instrument
calibration data.
1 - Auto The Auto-formatting procedure will be defined below.
2 - Boolean the parameter data is a standard configuration of a
Boolean function's configuration words. See the
description of the Boolean function in the "Standard Block
Functions" paper for the format. (There would normally be
no detailed format data in a parameter with this code
because of the complexity of the format.)
3 - Logic the parameter data is a standard set of Logic block
instructions. See the description of the Logic block for
the format. (There would normally be no detailed format
data in a parameter with this code because of the
complexity of the format.)
4 - Pointer The parameter data is a standard set of Pointer
configuration words. See the description of the Pointer
function in the "Standard Block Functions" paper for the
format. This code will only be used in those cases in
which there is no detailed format data. The manufacturer
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
may choose to allow room for detailed format information

for a parameter with this format because the pointer
configuration has a simple repeat pattern. However, if
the manufacturer adds detailed format data, or if the user
adds it later, the format code should be changed to
reflect the specific formatting method being used -
possibly code 1.
5 - 63 Reserved for Field Bus Standard Definition
64 - 127 Free for use by manufacturers of field devices.
128 - 191 Free for use by manufacturers of higher level devices.
192 - 255 Free for use by users.
OVERVIEW OF THE AUTO-FORMATTING METHOD:

The auto-formatting procedure header has been set up to allow any one of a
variety of detail formatting methods. However, only one method has been fully
defined - the "Auto" method.
The Auto formatting method provides a method of defining a "pattern" in the

data. The pattern may be a defined arrangement of up to 4 types of data items.
A data item may have a length of 32-bits, 16 bits, 8 bits, 4 bits, or even a
--```,``-`-`,,`,,`,`,,`---
single bit but all patterns ultimately repeat on byte boundaries. The directives
for displaying the pattern are defined using a "Detail Flow Word", 0 to 4
optional "Data Format Words", 0 to 8 SI units words, one "Data Control Word", and
0 to 8 "Mask Words".
Immediately following the last display directive, there can be visible

character fields that are referenced by the display directives.

358
The display directives that are included are:

1) data format as stored - 32 bit float, 8 and 16 bit integers with a
sign, 16 bit, 8 bit, 4 bit, and 1 bit binary, characters, delta
millisecond time, and clock time.
Note: a method is included to "continue" these basic formats - for
example, a 16 bit signed integer data format can be "continued"
to form a 32 bit integer data item. The combination will be
handled as a 32 bit signed integer, NOT as 2 - 16 bit signed
integers strung together. The Floating Point variables will be
handled in the same way - two 32 bit floating point numbers
"continued" will result in a valid 64 bit floating point
number.
2) data format to display - scientific float, engineering float, fixed
point, decimal, hex, binary, character,
time, and SI units definitions.
3) delete (i.e., ignore) data from this data item.
4) "display type" to infer color, font, etc.
5) option to display status.
6) option to appended a visible character string.
7) carriage return/line feed after the data.
8) mode-level write access relaxation.
9) authority write access relaxation.
The display directives associated with one "Detail Flow Word" can be applied
to a specified number of bytes in the parameter. After the required number of
bytes are processed, the display control can pass to the next set of formatting
words or control can be recycled back to earlier formatting words.
It is important to define the constraints on the recycling control that can

be used in the formatting definitions. The following is a representation of the
flow of control through several "Detail Flow Words":
1 - 2 - A - B - C - Y - Z
x x
xxx < xxx
In this representation, the flow is through words 1, then 2, then A, B, then

to C. After the C detail has been used, control can be forced to recycle back to
Detail Flow Word A. The loop can be repeated any number of times until it is
opened and words Y and Z are used. The constraints on the recycle definition
are:
1) The first Detail Flow Word definition is automatically used first.
This statement overrides any of the following statements. This would
be the normal start trigger for the Detail Flow Word 1 shown above.
2) A Detail Flow word can define the parameter data byte for which it
will take control. This statement overrides any of the following
statements. This could be used by steps 2, A, Y, and Z and must be
the one used by step Y in order to break the recycle loop at the
desired parameter data word.
3) If the Detail Flow Words are exhausted before the data in the
parameter is finished, the last Detail Flow Word is used for the
remainder of the parameter's data words. However, if the number of
remaining bits is less than the length of the display item specified
by the last Detail Flow Word's active format, the remaining bits will
be ignored. This statement overrides any of the following
statements.
4) A Detail Flow Word's definition can simply define the number of bytes
for which it is to apply. This could be done by any of the steps
shown except step C but would be meaningless for the last step, step
Z, because it is used until the data in the parameter are exhausted.
5) A Detail Flow Word can define the number of bytes for which it is to
apply and the byte number of the Detail Flow Word that is to apply
next. This could be used by any of the steps except Y and must be
used by detail C to form the recycle loop.
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
359
Notice that there is no provision for the values of the parameter data to
control the recycle loop. Also, the detail formats within the loop can not
change as a function of the pass number. For example, if there were to be fewer
words for a particular detailed format during the second pass than during the
first pass, that can not be done (with one exception - detail Y could cause an
early termination of the loop because it could take control at a specific
parameter data byte).
There is also no way to count the number of loops. The only way a loop can
be stopped is to reach the end of the data or for detail Y to take control at a
specified data byte.
The format of the formatting words is illustrated in Figure 3 - titled "Auto-

Formatting Detail Words" attached.
DETAILS OF THE AUTO-FORMATTING METHOD:
A) Detail Flow Word (mandatory)
The first "Detail Flow Word" must always be located at word F in the
parameter [if N > (F-1)]. Bits 0 through 8 will contain an unsigned integer "X".
The meaning of X is actually dependent on the value of X! If (X/2) < F, then it
refers to parameter data. It will identify the number of the byte in the
parameter data at which this detail format should start. If that particular byte
has already been processed, X is ignored.
If (X/2) => F, then it will identify the number of the byte in the parameter
--```,``-`-`,,`,,`,`,,`---
to which formatting control should pass after this detail format has finished its
specified number of bytes. The word at that location MUST be a "Detail Flow
Word". Also, since the formatting area must start on a word boundary and all
formatting data is entered as words, x must be even for this case.
Bits 9 through EH define the unsigned integer value of the number of data
area bytes that this display pattern will process before control will pass on to
the next Detail Flow Word. Note that the maximum value of this integer is 64
bytes. This means that only 12 - 32 bit floating point numbers with status bytes
can be formatted with one Detail Flow Word. If there are more data items than
that, a second Detail Flow Word will be needed simply because of this constraint.
The procedure allows up to 4 different data formats to be defined and used

within one detail definition. Because of the way they are controlled, the four
formats are referenced as the "primary" and "secondary" data format types in each
of the data format "sets" 0 and 1. One word is required to define one data
format. Up to four words follow the Detail Flow Word to define the four formats.
Bit FH in the Detail Flow Word indicates, when set, that the very next word is a
Data Format Word. If it is reset, a "Detail Control Word" will be next.
B) Data Format Word (mandatory if bit FH set in Detail Flow Word)
A "Data Format Word" completely defines a data format. The definition of a

format, once entered, remains available for the rest of the whole parameter
unless and until replaced using another Data Format Word to set that particular
data format. The format of each Data Format Word is defined
here:
Bit 0: Defines whether this Format is for one of the two formats in the
primary set (bit reset) or in the secondary set of formats.
Bit 1: Defines whether this Format is for one of the two formats in
Set 0 (bit reset) or in format Set 1.
Bits 2-7: an integer that defines the particular combination of data
type and display format for a data item. The codes are defined

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
360
in the attached Table 1. One of the codes defines a variable in

terms of the Standard extended SI units descriptor. This data
display code will require two SI units words immediately
following the Data Format Word.
Bit 8: If this bit is set, the display item is indicated as being stored
in the dynamic data area of the field device's memory, else it is
in static memory.
Bit 9: If this bit is set, the data is indicated as having a status byte
For most data types, there will be one status byte immediately
following a display item in the data area. A binary string is
assumed to have a status byte for each of its bits when this bit
is set. The procedure provides for a later modification to
indicate that a bit string has a single status byte for the whole
string and that status byte precedes the binary string.
Bit AH: If this bit is set, the status information should be displayed,
else it is suppressed.
Bit BH: If this bit is set, the procedure is instructed to append the
next visible character string to this display item (the visible
character strings are placed in order following the last of the
format control words). The addition of the visible character
string occurs before the execution of the carriage return/line
feed command that will be discussed below.
The visible character strings are separated by instances of the

<GS> command (a non-printable character with a value of 2910 ).
Note: This command appends the NEXT visible character string, not
a particular one. For example, in a recycle through Detail
Formats, the string that is added by the above command can
be different each time the command is executed.
Bits CH-EH:
The display type is intended to be a description of the data that
can be used by the higher level device to INFER a color, font,
blink command, etc. to the human interface. The display types
are described in general terms in the Standard so that a
manufacturer can set the type of data in a format without knowing
how the Human Interface will customize the display of each data
type. A user or the manufacturer of the human interface can
assign colors, etc. to each display type as appropriate without
knowing particular field device instances. The defined display
types and their codes are:
000 - Background - the variable is advisory and should be
displayed to recede into the background;
--```,``-`-`,,`,,`,`,,`---
for example, limit values on the range of

another variable.
001 - Instrument Description - data (visible character
string?) that describes an
aspect of the instrument
itself.
010 - Instrument Calibration - a variable that is a
calibration value for the
instrument; for example,
thermocouple linearization
data.
011 - Instrument Condition - a variable that is a measured
property of the instrument
itself, such as the body
temperature.
100 - Instrument Operation - a variable that is a measure of
the operation of the instrument,
such as an error rate, measured
noise, etc.
101 - Block Description - data (visible character string?)
that describes an aspect of the
function block.
110 - Block Configuration - configuration data and tuning
constants for a function block.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
361
111 - Process Measurement - a variable that is a measurement

from the process.
Bit FH - if this bit is set, another Data Format Word follows after any
SI units descriptors required by SI data display types. If
reset, then any SI descriptors are followed by a Detail Control
Word.
There can be 0 to 12 data format words following the Detail Flow Word and
before the Detail Control Word. They will appear in the following order with
unneeded words simply eliminated:
0) Detail Flow Word (mandatory)
1) Data Format Word - (mandatory if bit EH set in Detail Flow Word)
2) First SI units word (if data display type "SI")
3) Second SI units word (if data display type "SI")
4) Data Format Word - (mandatory if bit FH set in word 1 above)
--```,``-`-`,,`,,`,`,,`---
13) Detail Control Word (mandatory)
C) Detail Control Word (mandatory)

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
The Detail Flow Word and the 0 to 12 data format words are followed by the
required "Detail Control Word". This word can serve either of two functions. It
can define the display directives or it can indicate that a particular display
directive is defined by a separate word (a "mask") of its own. In the former
case, the one display directive is used for all repeats of the detail format. In
the latter case, there are up to 16 instances defined for a particular display
directive: they are applied in order, then repeat until the Detail Flow Word is
completed.
The low order 6 bits are arranged into three pairs of bits as shown on
the figure. The three pairs are similar. The first pair is used to
define the access authority. The whole parameter, its data and detail
format information, is assumed to require a "high" (i.e., "restricted")
level of authority for write access. (There is nothing that requires
that that assumption be followed by a higher-level device, it is simply
the assumption for the design of this function.) The following table
gives the meaning of the four possible values of this pair of bits:
0 = continue with "high" access
1 = all of the patterns of data being formatted will be
relaxed to "low" (i.e., less restricted) access.
2 = the first word after this word contains a 16 bit
string that is to be used to define the access for
each of the data items in this detail format. Bit 0
in that word will be used for the first data item,
then bit 1, etc. until bit 16 is used. If the
Detail Flow Word allows the decoding to continue to
17, bit 0 will repeat, then bit 1, etc.
3 = illegal
Bits 2 and 3 operate exactly the same as the first pair except that
they define the patterns that can have a mode priority access level
1 level more relaxed than the level defined for the whole parameter
in bits FH and EH of Word 1 of the parameter header.
Bits 4 and 5 operate exactly the same as the first pair except that
they define the patterns that can have a mode priority access level
2 levels more relaxed than the level defined for the whole
parameter in bits FH and EH of Word 1 of the parameter header.

362
Note: the two "mode access relax" directives can not add because
"Read Only" can not be relaxed. The remaining 3 levels only
represent two steps of relaxation. If the 2-Step directive
is set, the 1-Step directive will be ignored.
Bits 6 through 9 are arranged into two pairs of bits as shown on the
figure. The two pairs are similar. Bits 6 and 7 are used to direct a
carriage return/line feed AFTER the display item (and its optional
visible character string) or to indicate the presence of a mask for this
option. The following table gives the meaning of the four possible
values of this pair of bits:
0 = after the pattern ends, do not advance one line in
the display
1 = after each display item and its optional visible
character string, advance one line in the display.
2 = a word following this word contains a 16 bit string
that is to be used to define the CR/LF for all of the
data items of this Detail Flow Word. Bit 0 in the
string will be used for the first instance, then bit
1, etc. until bit 16 is used. If the repeats
continue to 17, bit 0 will repeat, then bit 2, etc.
3 = illegal
Bits 8 and 9 are used in a similar way except that they direct that
the display item (but NOT its optional visible character string)
not be displayed on the human interface device:
0 = display this display item as otherwise directed.
1 = do not display this display item.
that is to be used to determine whether the data item
is to be displayed or deleted for each of the
instances of data items under this Detail Flow Word.
Bit 0 in that word will be used for the first
instance, then bit 1, etc. until bit 16 is used. If
the instances continue to 17, bit 0 will repeat, then
bit 2, etc.
3 = illegal
In simple applications, there may be one data format defined. The data
that has been discussed already is sufficient to fully define the
display of one or more items in the data field each with the same
format.
Sometimes, it will be convenient to define more than one format (up to

4) and define a pattern for applying the formats to succeeding data
items. The 4 specific data formats that can be used within one detail
format are called the primary and the secondary display type for each of
sets 0 and 1. Individual data items can be assigned any one of the four
display types.
As mentioned above, data items may be combined to form display items.

The Field Control mask bits are used to indicate how the data items
should be combined. The Field Control bit that corresponds to a data
item that is to form the first part of a display item is set to EITHER 0
or 1. As long as the state of the bit does not change, the human
interface is to concatenate the data items onto the least significant
bit side of the previous data item. When the state of the Field Control
bit changes, the human interface is to break the string immediately
prior to the data item with the new state - convert it to its display
format, insert a space or, if directed, a CR/LF, and display the
concatenated display item using the directives of the first data item.
Bits AH and BH in the Detail Control Word form four control codes for
the "Field Control". They are as follows:
00 = Continue - the last display item from the previous
detail control word is to be continued using the
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
363
first data item being controlled by this Detail

Control Word.
01 = New - the first data item under the control of this
Detail Control Word is to start a new display item.
10 = Reset and Mask - the sense of the carried
continuation bit is to be reset, a mask for field
--```,``-`-`,,`,,`,`,,`---
control is to be expected after this Detail Control

Word, and the first bit in the mask is to be compared
to the reset state to determine if it changed.
11 = Illegal - not defined and do not use.
Bits CH through FH of the Detail Control Word are arranged into two
pairs of bits as shown on the figure. The two pairs are related. Bits
CH and DH are used to direct either the primary or secondary display
type. Bits EH and FH are used to direct type set 0 or type set 1. The
following table gives the meaning of the four possible values of bits CH
and DH:
0 = display this pattern using the primary data type.
1 = display this pattern using the secondary data type.
that is to be used to define the display type for all
of the repeats of this detail format. Bit 0 in that
word will be used for the first instance, then bit 1,
etc. until bit 16 is used. If the repeats continue
to 17, bit 0 will repeat, then bit 2, etc. If the
bit is set, use the secondary data type.
3 = illegal
The following table gives the meaning of the four possible values of
bits EH and FH:
0 = display this pattern using type set 0.
1 = display this pattern using type set 1.
that is to be used to define the type set for all of
the repeats of this detail format. Bit 0 in that
word will be used for the first instance, then bit 1,
etc. until bit 16 is used. If the repeats continue
to 17, bit 0 will repeat, then bit 2, etc. If the
bit is set, use type set 1.
3 = illegal
The procedure allows up to eight "Masks" to be defined immediately

following the detail control word. The first bit in each mask applies
to the first data item. The bits define the eight pieces of information
controlled by the Detail Control Word:
- Access Authority
If set, relax the Access Authority.
- Base Read/Write + 1
If set, relax the Base R/W mode access by 1 mode level.
- Base Read/Write + 2
If set, relax the Base R/W mode access by 2 mode levels and
ignore the command for "Base Read/Write + 1".
- Carriage Return/Line Feed
If set, insert a carriage return after the data item (and it's
optional visible character string).
- Delete
If set, do not display the data item but do display its
visible character string.
- Field Control
If different from the previous state, this data item is the
start of a new display item.
- Primary/Secondary Data Format Type
If set, use the secondary data format
- Data Format Set
If set, use data format set 1

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
364
As the data items are processed, control moves across the masks, one bit
at a time, thus manipulating the treatment accorded to each data item.
When 2 or more data items are combined into one display set, there can
be multiple copies of display directives. Therefore, there can be
conflicts in the directives. All eight pieces of information will be
used from the first data item in the data display that is encountered.
The only information that will be used from succeeding data item formats
will be the information necessary to determine the number of bits to add
to the already started display item. Status byte information
specifically will be ignored for the succeeding data items.
There is one question unanswered by the above procedure. How does the
Field Control mask string get started - can the first data item
encountered be concatenated with the immediately previous item left over
from the previous Detail Control Word? The answer is yes - by using a
Field Control code of "00" (continue) or "10" (reset and mask). The
former is used for one or more data items with no Field Control mask -
all of the items will be concatenated together. The latter is used with
a Field Control mask. The "old" mask bit will be reset. If the new
mask bit is reset, the concatenation will continue.
There can be 0 to 8 data format words indicated by the detail control word.
They will appear in the following order with unneeded words simply eliminated:
0) Detail Control Word (mandatory)
1) Access authority mask (if detail control word bits 0 and 1 = 10)
2) Base R/W + 1 mask (if detail control word bits 2 and 3 = 10B)
3) Base R/W + 2 mask (if detail control word bits 4 and 5 = 10B)
4) CR/LF mask (if detail control word bits 6 and 7 = 10B)
5) Delete mask (if detail control word bits 8 and 9 = 10B)
6) Field Control mask (if detail control word bits AH and BH = 10B)
7) Primary/Secondary Type mask (if detail control word bits CH and DH =
10B)
8) Type Set mask (if detail control word bits EH and FH = 10B)
9) end of display directives for this Detail Flow Word. The next item
can be:
- the next Detail Flow Word
- the start of the visible character fields
- the end of the parameter
--```,``-`-`,,`,,`,`,,`---
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

365
HIF Attach. 1 Table 1 - Code Values for Data Display Types

Data
Display
Code
(hex) Data Description Display Description
0 Null - bypass this data item None
1 Floating Point, 32 bits Fixed point, 0 places after dec.
2 " " 1 "
3 " " 2 "
4 " " 3 "
5 " " 4 "
6 " " 5 "
7 " " 6 "
8 " Sci. Flt. Pt.*, 3 places after dec.
9 " " 4 "
A " " 5 "
B " " 6 "
C " " 7 "
D " Eng. Flt. Pt.#, Exp. = -9
E " " -6
F " " -3
10 " " -2
11 " " 0
12 " " 3
13 " " 6
14 " " 9
15 " As directed by SI display codes@.
16 Integer with sign, 16 bits Decimal Integer with sign
17 Integer with sign, 8 bits Decimal Integer
18 Enumeration, 8 bits Enumerated String
19 Visible Char., 8 bits Visible Character
1A Binary string, 16 bits,
condensed status byte Binary string
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
1B " Decimal integer
1C " Hex integer
1D Binary string, 16 bits Binary string
1E " Decimal integer
1F " Hex integer
20 Binary string, 8 bits Binary string
21 " Decimal integer
22 " Hex integer
23 Binary string, 4 bits Binary string
25 " Hex integer
26 Binary string, 1 bit,
condensed status byte Binary string
28 " Hex integer
29 Binary string, 1 bit Binary string
2A " Decimal integer
2B " Hex integer
2C Millisecond Time Millisecond Time
2D " Clock Time
2E Clock Time Clock Time
2F-36 Reserved for Field Bus Revisions
37-3A Human Interface Manufacturer Specific
3B-3F Field Device Manufacturer Specific
Notes:
1 - All stated data item lengths exclude the status byte. The
length of the status bytes must be included in the data field
length and byte numbers of this procedure.
2 - Time can be stored in the Field Device in either of two general
forms - as a difference in time expressed in milliseconds and
--```,``-`-`,,`,,`,`,,`---

366
as clock time. The Field Device will express its time as

millisecond time. The format of the clock time is determined
by the higher level device that originally wrote it.
* = The number of display figures after the decimal point is
defined; the display is to be in scientific floating point
notation (decimal positioned to give 1 figure before the
decimal point).
# = The number of display figures after the decimal point is
defined by the display; the display is to be in floating point
notation with the indicated exponent.
@ = SI special - the value is in terms of SI units, two words
follow in the same format as the SI units words described
earlier in this paper. The two SI units words will immediately
follow this data format word.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
--```,``-`-`,,`,,`,`,,`---

367
Figure 1 AUTO-FORMATTING
PARAMETER LAYOUT
Parameter:
Bytes 2*N
4
Header Data 1 Format
2
W
Words F
N
M
Write:
Header 1
Writing Code = 00
Words 2
N
Figure 38:HIF Figure 1, Auto-Formatting Parameter Layout

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@
SP-50 User Layer Technical Report Human Interface Considerations

--```,``-`-`,,`,,`,`,,`---

368
Figure 2 AUTO-FORMATTING PARAMETER HEADER
F E D C B A 9 8 7 6 5 4 3 2 1 0
2#n where n= Parameter size in words.

(1 < N 117)
C = Formatting procedure code. (0 =<C < 256)
F E D C B A 9 8 7 6 5 4 3 2 1 0
--```,``-`-`,,`,,`,`,,`---
F =Start of Format Words.

(2 <F < 59)
M/2 where M = Maximum possible size of
Parameter (words). (c < M< 117)
Set if format area is read-only.
Minimum mode-level access to the data area:
00 = Read Only. 10 =Write in Man or O/S only
01 = Write in O/S only. 11 = Freely write.
F E D C B A 9 8 7 6 5 4 3 2 1 0
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
W = First word in parameter to
be written. (1 < W < 128)
Mask off first byte of write.
Mask off last byte of write.
Free.
Set if 2*N is to be written into data base.
Set if C is to be written into data base.
Writing code: 00 = Normal write. 10 = Long write.
01= Masked write. 11 = Error
Required mode-level access.
00= Error. 10 = Write in Man or O/S only.
10 = Write in O/S only. 11 = Freely write.
Figure 39:HIF Figure 2, Auto-Formatting Parameter Header

369
Figure 3 AUTO-FORMATTING DETAIL WORDS

F E D C B A 9 8 7 6 5 4 3 2 1 0
X =Data Byte Pointer

P = Bytes to Process with this format.
Bit set if a data format word follows.
--```,``-`-`,,`,,`,`,,`---
F E D C B A 9 8 7 6 5 4 3 2 1 0 Pri/Sec. Type.
Type set
Data display
0 = Static, 1 = Dynamic Data
0 =No Status Byte, 1 =Present
1= Append Next ASCII string.
Display type
000 = Background 101 = Proc. Desc.
001 = Inst. Desc. 110 = Bit Conf.
010 = Inst. Calibra. 111 = Proc. Meas.
011 = Inst. Cond.
100 = Inst. Oper.
Bit set if a Data format Word follows.
F E D C B A 9 8 7 6 5 4 3 2 1 0
00 = base value
Access Authority 01 ==relax
Base R/W + 1 10 = mask
Base R/W + 2 11 = illegal
CR/LF 00 = no effect 10 = reset
01 = apply 11 = illegal
Delete
00 = continue 10 reset and mask
Field control 01 = secondary type 11 = illegal
00 = Primary type 10 = mask

Pri/Sec. Data Format 01 = Secondary type 11 = illegal
00 = type set 0 10 =mask
Data Format Set 01 = Type set 0 11= illegal
Figure 40: HIF Figure 3, Auto-Formatting Detail Words

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
370
HIF Table 1, Extended SI Units

EXTENDED SI UNITS
CODE
NUMBER DESCRIPTION
------ --------------------------------------------
0 Unit-less
2 Count
4 Absorbed dose: grav = Gr
6 Acceleration: m^2/s
8 Acidity: pH
10 Amount of substance: mole = mol
12 Angle: radian = rad
14 Area: meters^2= m^2
16 Conductance = S
18 Density = kg/m^3
20 Electrical capacitance: Farad = F
22 Electrical inductance: Henry = H
24 Electrical resistance: Ohm
26 Electric current: Ampere = A
28 Electric potential: Volt = V
30 Electric quantity: Coulomb = C
32 Energy: Joule = J
34 Force: Newtons = N
36 Frequency: Hertz = Hz
38 Illuminance: lux = lx
40 Illuminour flux = l
42 Kilogram*Kelvin = kg.K
44 Kinematic viscosity: stoke = dyne-sec. *
cm/gm
46 Length: meters = m
48 Luminous intensity: candela = cd
50 Magmeter flux: Weber = Wb
52 Magmeter flux density: Tesla = T
54 Mass: kilogram = kg
56 Meter*Kelvin = m.K
58 Meter^2*Steradian = m^2.Sr
60 Mole*Kelvin = mol.K
62 Moment of Force: Newton*meters = N.m
64 Percent (%)
--```,``-`-`,,`,,`,`,,`---
66 Power: Watt = W
68 Power Ratio: decibels (ten times the
logarithm of the power ratio relative
to an arbitrarily chosen base level).
70 (Absolute) Pressure: Pascal = Pa
72 (Relative) Pressure: Pascal gauge = Pag
74 (Square Root) Pressure: (Pa)^(1/2)
76 Solid angle: steradian = sr
78 Speed = m/s
80 Temperature interval: Kelvin = K
82 Time: seconds = s
84 Time^2: seconds^2 = s^2
86 Valve Size or opening: CV = US Gal/Minute
(measured at 1 pound per square inch
differential pressure)
88 Viscosity: poise = dyne-seconds per cm^2
90 Volume: meters^3 = m^3
All values < 140 - Reserved
All values 140 - 199 - Manufacturer Specific
All values 200 - 255 - User Specific
NOTES:
The units for gauge pressure and the square root of differential pressure
were added for those cases where mathematical expressions prevented the easy
conversion of relative to absolute values.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
371
The units of acceleration, CV, kinematic viscosity, moment of force, speed,

and viscosity were added because of their frequent use and to ease the conversion
of Extended SI units to local units. The basic SI units for these measurements
will not be used in a standard Field Bus device.
The units of time^2 and the units with codes 42, 56, 58, and 60 were added to
condense certain more complex units so that they would fit within the abc form of
the expression.
--```,``-`-`,,`,,`,`,,`---

//^:^^#^
372
HIF Table 2 Enumeration Set Code Numbers

ENUMERATION SET CODE NUMBERS
This table lists a simple description of each Standard enumeration set vs.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
the code number that will be used for the set. The "range" defines the number of
least significant bits in the bit string that are taken as the enumeration.
The description includes a reference to succeeding Tables that give complete

definitions of each enumeration set. The descriptions given for each enumeration
are defined in Table 8.
Enumeration
Code Range Enumeration Set
0 - None.
1 - User definable.
--```,``-`-`,,`,,`,`,,`---
2 All Express the enumeration as a binary number - see Table 3.
3-8 - User definable.
9 1 Single Bit Yes/No - 0 = "No", 1 = "Yes"
10 All Express the enumeration as a decimal number - see Table 3.
11 1 Single Bit Pass/Fail - 0 = "Fail", 1 = "Pass"
12 1 Single Bit Go/Stop - 0 = "Stop", 1 = "Go"
13 1 Single Bit Full/Empty/ - 0 = "Empty", 1 = "Full"
14 1 Single Bit Hi/Lo - 0 = "Lo", 1 = "Hi"
15 1 Single Bit Fast/Slow - 0 = "Slow", 1 = "Fast"
16 All Express the enumeration as a Hexidecimal number -seeTable 3.
17 1 Single Bit Normal/Reset - 0 = "Reset", 1 = "Normal"
18 1 Single Bit Hi/Normal - 0 = "Normal", 1 = "Hi".
19 1 Single Bit Lo/Normal - 0 = "Normal", 1 = "Lo".
20 1 Single Bit Abnormal/Normal - 0 = "Normal", 1 = "Abnormal".
21 1 Single Bit On/Off - 0 = "Off", 1 = "On".
22 1 Single Bit Open/Close - 0 = "Close", 1 = "Open".
23 1 Single Bit Raise/Lower - 0 = "Lower", 1 = "Raise".
24 1 Single Bit Run/Stop - 0 = "Stop", 1 = "Run".
25 1 Single Bit Set/Reset - 0 = "Reset", 1 = "Set".
26 1 Single Bit True/False - 0 = "False", 1 = "True".
27 1 Single Bit Up/Down - 0 = "Down", 1 = "Up".
28 1 Single Bit Fill/Drain - 0 = "Drain", 1 = "Fill"
29 1 Single Bit Filling/Draining - 0 = "Draining", 1 = Filling".
30 3 Alarm Indication Hi/Hi/Hi -
if all bits are set, enumeration = "Hi-Hi-Hi"
if bit 2 is set and (bit 0 or bit 1 is reset),
enumeration = "Hi-Hi-Hi?"
if bit 2 is reset and bits 0 and 1 are set,
enumeration = "Hi-Hi"
if bits 0 and 2 are reset and bit 1 is set,
enumeration = "Hi-Hi?"
if only bit 1 is set, enumeration = "Hi"
if no bits are set, enumeration = "Normal"
31 3 Alarm Indication Lo-Hi/Hi -
if bits 1 and 2 are set and bit 0 is reset,
enumeration = "Hi-Hi"
if bit 2 is set and (bit 1 is reset or bit 0 is
set), enumeration = "Hi-Hi?"
if only bit 1 is set , enumeration = "Hi"
if only bit 0 is set, enumeration = "Lo"
if bits 0 and 1 are set, enumeration =
"Impossible"
32 3 Alarm Indication Lo/Lo-Hi -
if only bit 2 is set, enumeration = "Hi"
if only bit 1 is set , enumeration = "Lo"
if bit 0 is set and (bit 1 is reset or bit 2 is
set), enumeration = "Lo-Lo?"

373
if bits 0 and 1 are set and bit 2 is reset,

enumeration = "Lo-Lo"
if bits 1 and 2 are set, enumeration =
"Impossible"
33 3 Alarm Indication Lo/Lo/Lo -
if all bits are set, enumeration = "Lo-Lo-Lo"
if bit 0 is set and (bit 1 or bit 2 is reset),
enumeration = "Lo-Lo-Lo?"
if bit 0 is reset and bits 0 and 1 are set,
enumeration= "Lo-Lo"
if bits 0 and 2 are reset and bit 1 is set,
enumeration= "Lo-Lo?"
if only bit 1 is set, enumeration = "Lo"
34 3 Default Device True/False - all enumerations equal
"Impossible" except 1 = "True" and 2 = "False".
35 3 Default Device On/Off - all enumerations equal
"Impossible" except 1 = "On" and 2 = "Off".
36 3 Default Device Open/Close - all enumerations equal
"Impossible" except 1 = "Open" and 2 = "Close".
37 3 Default Device Stop/Run - all enumerations equal
"Impossible" except 1 = "Run" and 2 = "Stop".
38&39 3 Reserved.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
40 5 Motor - On/Off - State Feedback - see Table 4.

41 5 Pump - Run/Stop - State Feedback - see Table 4.
42 5 Lift - Raise/Lower - State Feedback - see Table 4.
43 5 Tank - Fill/Drain - State Feedback - see Table 4.
44 5 Mixer - Fast/Slow - State Feedback - see Table 4.
45 5 Heater - Heat/Fan - State Feedback - see Table 4.
46 5 Cooler - Cool/Fan - State Feedback - see Table 4.
47 5 Alarm - Normal/Abnormal - State Feedback - see Table 4.
48 5 State - Set/Reset - State Feedback - see Table 4.
49 5 Reserved
50 5 Motor - On/Off/Reverse - State Feedback - see Table 5.

51 5 Reserved
52 5 Lift - Raise/Stop/Lower - State Feedback - see Table 5.
53 5 Tank - Fill/Hold/Drain - State Feedback - see Table 5.
54 5 Mixer - Fast/Stop/Slow - State Feedback - see Table 5.
55 5 HVAC - Heat/Fan/Cool - State Feedback - see Table 5.
56-58 5 Reserved
59 5 Resource - Claim/Standby/Release - State Feedback - see
Table 5.
60 5 Motor Operated Valve - Open/Close - Limit Feedback - see
Table 6.
61 5 Reserved
62 5 Diverter Valve - Straight/Divert - Limit Feedback - see
Table 6.
--```,``-`-`,,`,,`,`,,`---
63 5 Elevator - Raise/Lower - Limit Feedback - see Table 6.

64 5 Tank - Fill/Empty - Limit Feedback - see Table 6.
65 5 Machine - Start/Stop - Limit Feedback - see Table 6.
66-69 5 Reserved
70 5 Motor Operated Valve - Open/Close/Stop - Limit Feedback -
see Table 7.
71 5 Motor Operated Charge Valve - Open/Close/Dribble - Limit
Feedback - see Table 7.
72 5 Diverter Valve - Straight/Divert/Stop - Limit Feedback - see
Table 7.
73 5 Elevator - Up/Down/Stop - Limit Feedback - see Table 7.
74 - 127 Reserved.
128 - 200 Manufacturer Specific.
200 - 255 User Definable.

374
HIF Table 3 Number Systems

TABLE 3
NUMBER SYSTEMS
ENUMERATION SET 2
(Binary Numbers)
Value
(Hex) Display Meaning
0 &B00000000 Number in Binary
1 &B00000001 "
2 &B00000010 "
3 &B00000011 "
' ' '
' ' '
' ' '
FF &B11111111 "
ENUMERATION SET 10
(Decimal Numbers)
Value
0 0 Number in Decimal
1 1 "
2 2 "
' ' '
' ' '
9 9 "
A 10 "
' ' '
F 15 "
10 16 "
etc. etc. etc.
ENUMERATION SET 16
(Hexidecimal Numbers)
Value
0 0 Number in Hexidecimal
1 &H1 "
2 &H2 "
' ' '
' ' '
A &HA "
10 &H10 "
' ' '
FF &HFF "
etc. etc. etc.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

--```,``-`-`,,`,,`,`,,`---

375
HIF Table 4 Two State "State" Feedback

TABLE 4
TWO STATE - "STATE" FEEDBACK

ENUMERATION SETS 40 - 49
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
(Feedback Bit #2 Pointer = Null)
The nine applications in this table are:

- 40 - On/Off - 45 - Heating and ventilation unit
- 41 - Running/Stopped - 46 - Cooling and ventilation unit
- 42 - Raise/Lower - 47 - Normal/Abnormal
- 43 - Filling/Draining - 48 - Set/Reset
- 44 - Fast/Slow
Value 40 41 42 43 44
--```,``-`-`,,`,,`,`,,`---
(Hex) Motor Pump Lift Tank Mixer
0 No Feedback? --------------------------------------------------->
1 On Run Raise Fill Fast
2 Off Stop Lower Empty Slow
3-7 Impossible ---------------------------------------------------->
8 No Feedback? --------------------------------------------------->
9 On Running Raising Filling Fast
AH Off Stopped Lowering Emptying Slow
BH-FH Impossible ---------------------------------------------------->
10H No Feedback? --------------------------------------------------->
11H-17H Impossible ---------------------------------------------------->
Value 45 46 47 48
(Hex) Heater Cooler Alarm State
0 No Feedback? --------------------------------------->
1 Heat Cool Normal Set
2 Fan Fan Abnormal Reset
3-7 Impossible ---------------------------------------->
8 No Feedback? --------------------------------------->
9 Heating Cooling Normal Set
AH Fan Fan Abnormal Reset
BH-FH Impossible ---------------------------------------->
10H No Feedback? ---------------------------------------->
11H-17H Impossible ----------------------------------------->

376
HIF Table 5 Enumeration Sets 50 - 55 & 59

THREE STATE - "STATE" FEEDBACK
ENUMERATION SETS 50 - 55 & 59
The six applications in this table are:

- 50 - a reversible motor
- 52 - a "lift" type device that has states of raising, lowering
and stopped.
- 53 - a device such as a tank that can be in the state of filling,
draining, or holding.
- 54 - a two speed device that has a fast and slow speed in addition
to stopped such as a mixer.
- 55 - heating, ventilation, and air conditioning unit that has a
selectable "cool" and "heat" option. When cooling, it can
be cooling or fan only; when heating, it can be heating or
fan only.
- 59 - a "resource": perhaps a piece of shared equipment in a batch
process that needs to be acquired by a sequence. If the
resource has only two states (on/off or open/close), then:
Acquire = both acquiring the resource and turning it on;
Standby = turning it off but retaining control of it;
Release = releasing it without changing the current state.
Value 50 52 53 54
(Hex) Motor Lift Tank Mixer
0 No Feedback? ----------------------------------------------->
1 On Raise Fill Fast
2 Off Stop Hold Stop
3 Impossible ------------------------------------------------>
4 Reverse Lower Empty Slow
5 Impossible ------------------------------------------------>
6 Impossible ------------------------------------------------>
7 Impossible ------------------------------------------------>
8 No Feedback? ----------------------------------------------->
9 On Rising Filling Fast
AH Off Stopped Holding Stopped
BH Impossible ------------------------------------------------>
CH Reverse? Lowering? Emptying? Slow?
DH Impossible ------------------------------------------------>
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
EH Impossible ------------------------------------------------>
FH Impossible ------------------------------------------------>
10H No Feedback? ----------------------------------------------->

11H On? Rising? Filling? Fast?
12H Off Stopped Holding Stopped
13H Impossible ------------------------------------------------>
14H Reverse Lowering Emptying Slow
15H Impossible ------------------------------------------------>
16H Impossible ------------------------------------------------>
17H Impossible ------------------------------------------------>
Value 55 59
(Hex) HVAC Resource
0 No Feedback? ------------------------------------------------->
1 Heat Acquire
2 Fan Standby
3 Impossible -------------------------------------------------->
4 Cool Release
5 Impossible -------------------------------------------------->
6 Impossible -------------------------------------------------->
7 Impossible -------------------------------------------------->
--```,``-`-`,,`,,`,`,,`---

377
8 No Feedback? ------------------------------------------------->
9 Heating Acquired
AH Fan Standby/Acqui'd
BH Impossible -------------------------------------------------->
CH Cooling? Released?
DH Impossible -------------------------------------------------->
EH Impossible -------------------------------------------------->
FH Impossible -------------------------------------------------->
10H No Feedback? ------------------------------------------------->

11H Heating? Acquired?
12H Fan Standby/Released
13H Impossible -------------------------------------------------->
14H Cooling Released
15H Impossible -------------------------------------------------->
16H Impossible -------------------------------------------------->
17H Impossible -------------------------------------------------->
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
378
HIF Table 6 Two State "Limit" Feedback

TABLE 6
ENUMERATION SETS 60 AND 62 - 64

(Used with "Limit" Feedback)
(Feedback Bit #1 Pointer = Null)
The five applications in this table are:

- 60 - a motor operated valve with open/close commands.
- 62 - a diverter valve that has straight/divert commands.
- 63 - a simple elevator with limit switches, no intermediate stop.
- 64 - a device such as a tank that can be "filled" and "emptied".
- 65 - a device that has a long wind-up or wind-down time.
Value 60 62 63 64 65
(Hex) Valve Div. Valve Elevator Tank Machine
0 Traveling Traveling Traveling Changing Changing
1 Open Divert Raise Fill Start
2 Impossible ------------------------------------------------------->
3 Impossible ------------------------------------------------------->
4 Close Straight Lower Empty Stop
--```,``-`-`,,`,,`,`,,`---
5 Impossible ------------------------------------------------------->
6 Impossible ------------------------------------------------------->
7 Impossible ------------------------------------------------------->
8 Opening Diverting Rising Filling Starting

9 Opened Diverted Up Full Running
AH Impossible -------------------------------------------------------->
BH Impossible -------------------------------------------------------->
CH Closed? Straight? Down? Empty? Stopped?
DH Impossible -------------------------------------------------------->
EH Impossible -------------------------------------------------------->
FH Impossible -------------------------------------------------------->
10H Closing Straightening Lowering Emptying Stopping

11H Opened? Diverted? Up? Full? Running?
12H Impossible -------------------------------------------------------->
13H Impossible -------------------------------------------------------->
14H Closed Straight Down Empty Stopped
15H Impossible -------------------------------------------------------->
16H Impossible -------------------------------------------------------->
17H Impossible -------------------------------------------------------->
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

379
HIF Table 7 Three State "Limit" Feedback

TABLE 7
ENUMERATION SETS 70 - 73
(Used with "Limit" Feedback)
The four applications in this table are:

- 70 - a motor operated valve with open/close/stop commands
- 71 - a charging valve, perhaps on the feed to a reactor under batch
control, that is manipulated from above the Device block to
have a "dribble" position during closing.
- 72 - a diverter valve that has straight/diverted/stop commands
- 73 - a simple elevator with limit switches and stop.
Value 70 71 72 73
(Hex) Valve Chg.Valve Div. Valve Elevator
0 Traveling Traveling Traveling Traveling
1 Open Open Divert Raise
2 Stop Stop Stop Stop
3 Open/Stopped Open/Stopped Diverted/Stopped Up/Stopped
4 Close Close Straight Lower
5 Impossible ---------------------------------------------------->
6 Closed/Stopped Closed/Stopped Straight/Stopped Down/Stopped
7 Impossible ---------------------------------------------------->
8 Opening Opening Diverting Rising

9 Open/Running? Open/Running? Diverted/Running? Up/Running?
AH Stopped Stopped Stopped Stopped
BH Open/Stopped Open/Stopped Diverted/Stopped Up/Stopped
CH Closed/Running? Closed/Running? Straight/Running? Down/Running?
DH Impossible ---------------------------------------------------->
EH Closed/Stopped? Closed/Stopped? Straight/Stopped? Down/Stopped?
--```,``-`-`,,`,,`,`,,`---
FH Impossible ---------------------------------------------------->
10H Closing Closing Closing Lowering

11H Open/Running? Open/Running? Diverted/Running? Up/Running?
12H Stopped Dribble Stopped Stopped
13H Open/Stopped? Open/Stopped? Diverted/Stopped? Up/Stopped?
14H Closed/Running? Closed/Running? Straight/Running? Down/Running?
15H Impossible ---------------------------------------------------->
16H Closed/Stopped Closed/Stopped Straight/Stopped Down/stopped
17H Impossible ---------------------------------------------------->

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
380
HIF Table 8 Glossary of Enumeration States

TABLE 8
GLOSSARY OF ENUMERATION STATES
The enumerations given below are intended to be the basis for enumerations
used for North American English versions of Conformant equipment. The strings
given require a 17 character display window. The following table expands each of
the enumerations to a full expression:
Abnormal The tag is in an Abnormal state.
Acquire Command to Acquire the resource or the resource has

been acquired successfully.
Acquired The resource is Acquired successfully.
Acquired? The resource is Acquired but the last command was
to Release it.
Changing The state of the device is Changing.
Close Close the valve.
Closed The valve is Closed.
Closed/Running? The valve is Closed but the motor is still running.
Closed/Stopped The valve is Closed and the motor is Stopped.
Closed/Stopped? The valve is Closed and the motor is Stopped but
the last command was to open the valve.
Closed? The valve is Closed but the last command was to
Open it.
Closing The valve is Closing.
Cool Command the HVAC system to Cool.
Cooling The HVAC is cooling.
Cooling? The HVAC is cooling but the last command was to
heat.
Divert Command the valve to Divert.
Diverted The valve is Diverted.
Diverted/Running? The valve is Diverted but the motor is still
running.
Diverted/Stopped The valve is Diverted and the motor is Stopped.
Diverted/Stopped? The valve is Diverted and the motor is Stopped but
--```,``-`-`,,`,,`,`,,`---
the last command was to straighten the valve.
Diverted? The valve is Diverted but the last command was to
straighten it.
Diverting The valve is Diverting.
Down The elevator is Down.
Down/Running? The elevator is Down but the motor is still running
Down/Stopped The elevator is Down and the motor is Stopped.
Down/Stopped? The elevator is Down and the motor is Stopped but
the last command was to Raise the elevator.
Down? The elevator is Down but the last command was to
Raise the elevator.
Dribble The valve is in the Dribble position.
Empty Command the device to empty / the device is empty.
Empty? The device is empty but the last power command was
to fill it.
Emptying The device is emptying.
Fan Command the HVAC system to Fan-only.
Fan/Cooling The HVAC system is Fan-only and in the cooling mode
Fan/Heating The HVAC system is Fan-only and in the heating mode
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Fast Command the device to go to its fast operating

state/ the device is operating in its fast state.
Fast? The device is in its fast operating state but the
last power command was to go to its slow state.
Fill Command the (tank) to be filled.
Filling The (tank) is filling.
Filling? The (tank) is filling but the last power command
was to empty.
Full The device is full.
Full? The device is full but the last power command was

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
381
to empty it.
Heat Command the HVAC system to Heat.
Heating The HVAC system is Heating.
Heating? The HVAC system is Heating but the last command was
to Cool.
Hold Command the device to hold its present position or
state.
Holding The device is holding its present position or state
Impossible The feedback signals are crazy.
Lower Command to Lower the elevator.
Lowering The elevator is Lowering.
Lowering? The elevator is Lowering but the last power command
was to raise it.
No Feedback? There is no Feedback but there should be.
Normal The tag is in its normal state.
Off Command the device to turn off or the device is off
On Command to turn the device On or the device is On.
On? The motor is On in the Forward direction but the
last command was to turn it On in the Reverse
direction.
Open Command the valve to Open.
Opening The valve is Opening.
Open/Running? The valve is Open but the motor is still running.
Open/Stopped The valve is Open and the motor is Stopped.
Open/Stopped? The valve is Open and the motor is stopped but the
last command was to close the valve.
Opened? The valve is Open but the last command was to Close
it.
Raise Command to Raise the elevator.
Release Command to Release the resource.
Released The resource has been Released.
Released? The resource is released but the last command was
to Claim it.
Reset Command the device to go to its reset state/
the device is in its reset state.
Reverse Command to turn the device On in the reverse
direction or the device is On in the Reverse
direction.
Reverse? The device is On in the Reverse direction but the
last command was to turn it On in the Forward
direction.
Rising The elevator is Rising.
Rising? The elevator is rising but the last power command
to it was to lower.
Run Command the device to run.
Running The device is in its run state.
Set Command the device to go to its set state/ the
device is in its set state.
Slow Command the device to go to its slow operating
state/ the device is operating in its slow state.
Slow? The device is in its slow operating state but the
last power command was go go to fast.
Standby Command to put the resource into Standby.
Standby/Claimed The resource is in Standby; it is Claimed.
Standby/Released The resource is in Standby; it is Released.
Stop Command the device to Stop or the device is Stopped
Stopped The device is stopped.
Straight Command the diverter valve to move to the Straight
position.
Straightening The diverter valve is Straightening.
Straight/Running? The diverter valve is Straight but the motor is
still Running.
Straight/Stopped The diverter valve is Straight and the motor is
Stopped.
Straight/Stopped? The diverter valve is Straight and the motor is
Stopped but the last command was to Divert.
Straight? The diverter valve is Straight but the last command

--```,``-`-`,,`,,`,`,,`---

382
was to Divert.
Traveling The valve or elevator is Traveling.
Up The elevator is in the Up position.
Up/Running? The elevator is in the Up position but the motor is
still Running.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Up/Stopped The elevator is in the Up position and the motor is

Stopped.
Up/Stopped? The elevator is in the Up position and the motor is
Stopped but the last command was to Lower it.
Up? The elevator is in the Up position but the last
command was to Lower it.
--```,``-`-`,,`,,`,`,,`---

383
HIF Table 9 Recognized General Single Character Non-Print

Commands
TABLE 9
RECOGNIZED GENERAL SINGLE CHARACTER NON-PRINT COMMANDS
This table lists the commands that the Field Bus Standard recognizes as the
common meaning of single non-printable visible characters. Table 10 will present
alternate or more precise definitions and/or codes for the 21 commands shown with
a "*". For the rest of these commands, the Field Bus definition will be exactly
the same as the generally recognized definition.
Character
Value
(Base 10) Code Meaning
* 0 NUL Null Character
1 SOH Start Of Heading
2 STX Start Text
3 ETX End Text
4 EOT End Of Transmission
5 ENQ Enquiry
6 ACK Affirmative Acknowledge
7 BEL Bell
8 BS Backspace
--```,``-`-`,,`,,`,`,,`---
* 9 HT Horizontal Tabulation
* 10 LF Line Feed
* 11 VT Vertical Tabulation
* 12 FF Form Feed
* 13 CR Carriage Return
* 14 S0 Select Double-width Mode - 1 line (see 20)
* 15 S1 Select Condensed Mode (see 18)
16 DLE Data Link Escape
* 17 DC1 Select Printer (see 19)
* 18 DC2 Cancel Condensed Mode (see 15)
* 19 DC3 Deselect Printer (see 17)
* 20 DC4 Cancel Double-width Mode - 1 line (see 14)
21 NAK Negative Acknowledge
22 SYN Synchronous Idle
23 ETB End Transmission Block
* 24 CAN Cancel Line
* 25 EM End Medium
26 EOF End of File (as in CP/M and DOS Operating Systems)
* 27 ESC Escape
* 28 FS File Separator
* 29 GS Group Separator
* 30 RS Record Separator
* 31 US Unit Separator
* 32 SP Space
*127 (Various)
*255 SP Space
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Note: the Field Bus definitions for the structure of the clipboard will
use the hierarchy of: record, group, and file (in order, from
lowest to highest classification). "Unit" will not be used.

384
HIF Table 10 Fieldbus Defined Single Character Non-Print

Commands
TABLE 10
FIELD BUS DEFINED SINGLE CHARACTER NON-PRINT COMMANDS
This table lists the single character "non-printable" visible characters

whose general definitions are made more precise or changed by the Field Bus
Standard.
Character
Value
(Base 10) Code Meaning
0 NUL Null Character (ignore in display/print string - do
not display/print, do not skip a space, but
include in all error detection procedures as if a
read character)
9 HT Horizontal Tab [tab positions fixed at every 8
character positions starting at the leftmost
position in the display (print) field - positions
0, 8, 16, etc.].
10 LF Line Feed (line feed will IMPLY a carriage return)
11 VT Vertical Tab (tab positions fixed at every line -
this control character will advance one line
with no horizontal change in position)
12 FF Form Feed [clears display (advances to top of paper)
and positions cursor (printer) at top left
position]
13 CR Carriage Return [returns carriage (cursor) to left-
most position BUT DOES NOT IMPLY a line feed].
14 SD Select Double-width Mode - 1 line (remains in effect
until <LF> or <CD>) (default is single-width
mode)
15 SC Select Condensed Mode (see <CC>) (default is normal
mode).
17 SP Select Printer (see <DP>) (will cause printing to
start- note that default is printer selected)
18 CC Cancel Condensed Mode (see <SC>)
19 DP Deselect Printer (see <SP>) (will cause printing to
stop - note that default is printer selected)
20 CD Cancel Double-width Mode - (see <SD>) (default is
single-width mode)
24 HB High Bit - this character will be treated exactly as a
NUL except the immediately next character will
--```,``-`-`,,`,,`,`,,`---
have its high-order bit set. (This will allow a
7-bit communication link to activate the extended
characters.)
25 FBE Field Bus Escape (see Table 13)
27 ESC Escape
28 FS File Separator - used in a Field Bus clipboard to
denote BOTH the beginning and end of the
meaningful data on a single page of the
clipboard. If the clipboard has any meaningful
data, <FS> will be the first character on the
page. There can only be 0 or 2 of these commands
on a page of the clipboard. (see p15, "Human
Interface Considerations").
29 GS Group Separator - used in a Field Bus clipboard to
denote BOTH the beginning and the end of a
part/material description. The GS commands must
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
be used in matched pairs, one pair can not exist

within another pair, and both members of a pair
must be on a single page of the clipboard. The
first member of the pair must be followed
immediately by two visible characters. These
constitute the part number. The command <RS>

385
then follows immediately. (see p16, "Human

--```,``-`-`,,`,,`,`,,`---
This command is used in records outside of the

clipboard to indicate the separation between
groups. Specifically, see p10 of Human Interface
Considerations, Attachment 1 for its use in the
Auto-Formatting procedure.
30 RS Record Separator:
- If inside of a <GS> pair: used in a Field Bus
clipboard to denote the beginning of a material
description. (see p17, "Human Interface
Considerations" and called the MD-Start in
Attachment 2 of Human Interface Considerations).
- If outside of a <GS> pair: indicates the end
of a visible string whose last display line is to
be right justified (see p4 of the paper "Human
Interface Considerations")
31 US Unit Separator:
- If inside of a <GS> pair: used in a Field Bus
clipboard to denote the end of a material
description. (see p17, "Human Interface
Considerations" and called the MD-End in
Attachment 1 of Human Interface Considerations).
- If outside of a <GS> pair: indicates the end
of a visible string (see p4 of the paper "Human
32 SP Space (can be used by word-wrap procedures as a break)
127 SPH Hard Space (will not be recognized by word-wrap
procedures as a break)
255 SPH Hard Space - same as 127
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

386
--```,``-`-`,,`,,`,`,,`---
HIF Table 11 Recognized General Single Byte Font Codes

TABLE 11
RECOGNIZED GENERAL SINGLE BYTE FONT CODES
This table lists the fonts that the Field Bus Standard recognizes as the
common meaning of single byte CODES. These codes and fonts are identical to
those found in the "Alternate" character set in the "IBM Proprinter".
Character Character Character Character

Value Value Value Value
Decimal Hex Font Decimal Hex Font Decimal Hex Font Decimal Hex Font
33 21 ! 133 85 174 AE 215 D7
34 22 " 134 86 175 AF 216 D8
35 23 # 135 87 176 B0 217 D9
36 24 $ 136 88 177 B1 218 DA
37 25 % 137 89 178 B2 219 DB
38 26 & 138 8A 179 B3 220 DC
39 27 ' 139 8B 180 B4 221 DD
40 28 ( 140 8C 181 B5 222 DE
41 29 ) 141 8D 182 B6 223 DF
42 2A * 142 8E 183 B7 224 E0
43 2B + 143 8F 184 B8 225 E1
44 2C , 144 90 185 B9 226 E2
45 2D - 145 91 186 BA 227 E3
46 2E . 146 92 187 BB 228 E4
47 2F / 147 93 188 BC 229 E5
48-57 30-39 0-9 148 94 189 BD 230 E6
58 3A : 149 95 190 BE 231 E7
59 3B ; 150 96 191 BF 232 E8
60 3C < 151 97 192 C0 233 E9
61 3D = 152 98 193 C1 234 EA
62 3E > 153 99 194 C2 235 EB
63 3F ? 154 9A 195 C3 236 EC
64 40 @ 155 9B 196 C4 237 ED
65-90 41-5A A-Z 156 9C 197 C5 238 EE
91 5B [ 157 9D 198 C6 239 EF
92 5C \ 158 9E 199 C7 240 F0
93 5D ] 159 9F 200 C8 241 F1
94 5E ^ 160 A0 201 C9 242 F2
95 5F _ 161 A1 202 CA 243 F3
96 60 ` 162 A2 203 CB 244 F4
97-122 61-7A a-z 163 A3 204 CC 245 F5
123 7B { 164 A4 205 CD 246 F6
124 7C | 165 A5 206 CE 247 F7
125 7D } 166 A6 207 CF 248 F8
126 7E ~ 167 A7 208 D0 249 F9
127 7F 168 A8 209 D1 250 FA
128 80 169 A9 210 D2 251 FB
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
129 81 170 AA 211 D3 252 FC

130 82 171 AB 212 D4 253 FD
131 83 172 AC 213 D5 254 FE
132 84 173 AD - 214 D6 255 FF

387
HIF Table 12 Recognized General Two Byte Font Codes

TABLE 12
RECOGNIZED GENERAL TWO BYTE FONT CODES
This table lists the two byte codes that the Field Bus Standard recognizes
for each of the fonts given in Table 11. These codes are identical to the codes
found in the "Unicode" character set. The leading two zeros have been omitted
from many of the hex values for clarity.
Character Character Character Character

Value Value Value Value
Decimal Hex Font Decimal Hex Font Decimal Hex Font Hex Font
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
33 21 ! 224 E0 171 AB 256B

34 22 " 229 E5 184 BB 256A
35 23 # 231 E7 2591 2518
--```,``-`-`,,`,,`,`,,`---
36 24 $ 234 EA 2592 250C
37 25 % 235 EB 2593 2588
38 26 & 232 E8 2502 2585
39 27 ' 239 EF 2524 258B
40 28 ( 238 EE 2561 2590
41 29 ) 236 EC 2562 2580
42 2A * 196 C4 2556 03B1
43 2B + 197 C5 2555 03B2
44 2C , 201 C9 2563 0393
45 2D - 230 E6 2551 03C0
46 2E . 198 C6 2557 03A3
47 2F / 244 F4 255D 03C3
48-57 30-39 0-9 246 F6 255C 03BC
58 3A : 242 F2 255B 03C4
59 3B ; 251 FB 2510 03A6
60 3C < 249 F9 2514 0398
61 3D = 255 FF 2534 03A9
62 3E > 214 D6 252C 03B4
63 3F ? 220 DC 251C 221E
64 40 @ 162 A2 2500 03C6
65-90 41-5A A-Z 163 A3 253C 03B5
91 5B [ 165 A5 255E 03B7
92 5C \ 20A7 255F 039E
93 5D ] 0192 255A 177 B1
94 5E ^ 225 E1 2554 2265
95 5F _ 237 ED 2569 2264
96 60 ` 243 F3 2566 2320
97-122 61-7A a-z 250 FA 2560 2321
123 7B { 241 F1 2550 247 F7
166 A6 | 209 D1 256C 2248
125 7D } 170 AA 2567 176 B0
126 7E ~ 186 BA 2568 2219
32 20 191 BF 2564 183 B7
199 C7 2310 2565 221A
252 FC 172 AC 2559 207F
233 E9 189 BD 2558 178 B2
226 E2 188 BC 2552 25AA
228 E4 161 A1 - 2553 32 20

388
HIF Table 13 Recognized "Escape" and :"Fieldbus Escape"

Commands
TABLE 13
RECOGNIZED "ESCAPE" AND "FIELD BUS ESCAPE" COMMANDS
This table lists the characters that can follow the "Escape" and "Field Bus
Escape" characters as defined in this Standard and gives the meaning of each set
of characters (i.e., each "escape command").
The two major parts of this table are:

Characters after "Escape"
Characters after "Field Bus Escape"
Note that the enabling and suppression of 8-bit Japanese codes are unique to
--```,``-`-`,,`,,`,`,,`---
this Standard. The default condition for the clipboard will be single byte
(Table 11) mode enabled and 8-bit Japanese modes disabled.
Characters After "Escape" (<ESC>), (27 base 10):

Character
Value
(Base 10) Symbol Meaning
36,64 $@ Start of two-byte, 7-bit Japanese Codes (Old-JIS)
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
36,66 $B Start of two-byte, 7-bit Japanese Codes (New-JIS,

JIS)
40,66 (B Start of one-byte (Table 11) codes AND start of
8-bit Japanese mode suppression (default
condition).
Note: <ESC><(B> can be used while in one byte mode to
suppress 8-bit Japanese mode.
40,74 (J Start of one-byte per character JIS-Roman
72 H End of 7-bit Japanese Codes (NEC KANJI) AND enable
8-bit Japanese mode.
Note: <ESC><H> can be used while in one byte mode to
enable 8-bit Japanese mode.
73 I Start of multibyte per character representation
according to ISO 10646.
Note: in the absence of defined escape sequences FROM
10646 BACK to single byte (Table 11)
representation, the sequence indicating
<Esc> in 10646 notation will be used.
75 K Start of two-byte, 7-bit Japanese Codes (NEC KANJI)
85 U Start of two-byte per character representation
according to Unicode.
Note: in the absence of defined escape sequences FROM
Unicode BACK to single byte (Table 11)
representation, the sequence U+001B, U+0055
will indicate the return (i.e., <Esc> using
2 bytes per character in Unicode).
Characters After "Field Bus Escape" (<FBE>),(25 base 10) (see Note (1)
below):
Note: links
built on the character symbol refer to notes at the end of the table.
Character
Value
- any 4 bytes - In the first (left most) character of a Units
Description field, <FBE> indicates that the next
4 bytes are to be interpreted as an "Extended SI"
description (see p4 of Human Interface
Considerations) and the rest of the field is to
be ignored.
35 # Start of Hardware I/O Reference Definition (see item
1, p16, "Human Interface Considerations"). Can
be used outside of any clipboard group or inside

389
of any group but can not be within a command nor

record. (Even if the physical device only has
one hardware I/O point, its type must be stated
explicitely in the clipboard if part/material
descriptions are to be used.) Must be followed
immediately by:
1) Two alpha characters denoting the type of
hardware point:
CO = composition (logical node
type multicomponent/
multistream
CT = counter input
DR = discrete register
HI = human interface
PO = pulse output
PS = property scanner
SI = scalar input
SO = scalar output
SR = serial communication port
TK = tank gauge
VD = voted discrete outputs
(complex device only)
VS = voted scalar outputs
(complex device only)
2) The two alpha characters must be followed
immediately by 1 to 4 numeric characters
denoting the index number of the point
(zero based numbering required).
3) The numeric characters can terminate the
string or, optionally, they can be
followed by both of:
a) a dash (-)
b) 1 to 4 numeric characters
denoting the (inclusive) end of
the range of hardware points
being referenced.
The entire string must be on one clipboard page.
87 W Start of Manufacturer's Information group.
88 X Start of a Manufacturer's visible information
record.
89 Y End of a Manufacturer's visible information
record.
90 Z End of Manufacturer's Information group.
49 1 Start of information group entered by "Repair shop"

(Calibration Laboratory). Can not be used
by an original manufacturer.
50 2 Command to ignore all previous part/material
information. Can be used outside of any
clipboard group or inside of any group
except the "Manufacturer's Information"
group. Can not be within a command nor
record. Can not be used by an original
manufacturer.
51 3 Command to ignore previous part/material
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
information for the currently defined

hardware. Can be used outside of any
clipboard group or inside of any group
except the "Manufacturer's Information"
group. Can not be within a command nor
record. Can not be used by an original
manufacturer.
52 4 Start of a Laboratory information visible record.
--```,``-`-`,,`,,`,`,,`---
Must be used within the "repair shop" group.

53 5 End of a Laboratory information visible record.
54 6 End of information group entered by repair shop
(calibration laboratory).

390
65 A Start of maintenance activity group. Can not be used

by a manufacturer.
66 B Start of maintenance time (clock time in Field
Bus notation must follow immediately).
--```,``-`-`,,`,,`,`,,`---
Time will be entered in this record in the

form:
uuhhddmmyyyy
where: uu = TWO visible numeric characters
showing minutes. The value
must be 00 - 59 or 99. The
latter will be interpreted as
"unknown".
hh = TWO visible numeric characters
showing the hour in military
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
time (i.e., 00-23, not 00-11)
The value must be 00 - 23 or
99. The latter will be
interpreted as "unknown".
dd = TWO visible numeric characters
showing the day of the month.
mm = TWO visible numeric characters
showing the month of the year.
yyyy = FOUR visible numeric
characters showing the year.
Can also be used in the "repair shop" group
but can not be used by an original
manufacturer.
67 C Start of maintenance time (the high order
three bytes of Field Bus Social Time must
follow immediately, low order byte first.
Note that this is one of the few records in
the clipboard that is in binary format. It
must always consist of exactly 5 bytes
including the <FBE>, the letter "C", and
the three bytes of time.
68 D Start of maintenance person identification record
manufacturer.
69 E End of maintenance person identification record.
70 F Start of maintenance work order number record.
manufacturer.
71 G End of maintenance work order number record.
72 H Start of coded maintenance record (two-character
maintenance code from Table 16 must follow
immediately; it in turn must be immediately
followed by the other 3 characters of the
record). Can also be used in the "repair
shop" group but can not be used by an
original manufacturer.
74 J Start of free visible maintenance record.
Can only be used in the "maintenance
activity" group.
75 K End of free visible maintenance record.
76 L End of Maintenance activity group.
77 M Start of User's free information group.
Can not be used by an original manufacturer

391
--```,``-`-`,,`,,`,`,,`---
78 N Start of a User's information record.

Can only be used in the "User's free
information group.
80 P End of a User's information record.
81 Q End of User's free information group.
82 R Start of triggered calibration group.
83 S Start of binary data.
84 T End of triggered calibration group.
73&79 I&O Purposely skipped.

81-86 U&V Reserved.
55-57 7-9 Reserved.
Notes: 1) No escape command string can cross clipboard pages.

2) all encoded maintenance information will be entered relative
to hardware I/O points under the Physical Node Tag Name, NOT
relative to individual function block names. <FBE><#> may be
used in any of the groups defined below.
3) <FBE><X> and <FBE><Y> must exist in pairs and both must be on
the same clipboard page. Multiple pairs can exist within the
Manufacturer's information group but they can not be nested.
4) <FBE><W> and <FBE><Z> must exist in pairs and can be on
different clipboard pages. There can be multiple pairs in one
total clipboard but they can not be nested.
5) <FBE><1> and <FBE><6> must exist in pairs and can be on
6) <FBE><2> and <FBE><3> can exist multiple times in any group.
7) <FBE> & <FBE><C> can be used in the repair shop record.
8) <FBE><D> and <FBE><E> must exist in pairs and both must be on
repair shop's information group but they can not be nested.
9) <FBE><D>-<FBE><E> can be used in the repair shop record.
10) <FBE><F>-<FBE><G> can be used in the repair shop record.
11) <FBE><F> and <FBE><G> must exist in pairs and both must be on
12) <FBE><4> and <FBE><5> must exist in pairs and both must be on
13) <FBE><A> and <FBE><L> must exist in pairs and can be on
14) The total record for each of <FBE> and <FBE><H> must exist
on one clipboard page.
15) <FBE><J> and <FBE><K> must exist in pairs and both must be
on the same clipboard page. Multiple pairs can exist within a
single maintenance activity group but they can not be nested.
16) <FBE><N> and <FBE> must exist in pairs and both must be on
User's information group.
17) <FBE><M> and <FBE><Q> must exist in pairs and can be on
18) <FBE><R> and <FBE><T> must exist in pairs and can be on
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
total clipboard but they can not be nested. The <FBE><S> must
immediately precede the binary data. A page break can not
separate the <FBE><S> from the binary data and the binary data
can not itself be split by a page break nor be separated from
the trailing <FBE><T> by a page break. The binary data must
be exactly as long as is specified.

392
HIF Table 14 Materials Specification List by Device

TABLE 14
MATERIALS SPECIFICATION LIST BY DEVICE
This Table presents a list of part descriptions arranged by type of field

device. When a part description is being chosen, preference must be given to the
part descriptions listed for the device in this table.
If there is no appropriate description listed for the device being described,

then see Table 15. The primary devices listed are:
Pressure Turbine Meter Temperature
Meter Runs Variable Area Centrifical Pump
Positive Disp. Vortex Shedding Agitator
Magnetic Flow Mass Flow Valve
Target Meter Level Solenoid Valve
There are four sources for the parts definitions/descriptions used in this
table. They are:
1) ISA SP-16.s - "Variable Area Meters"
2) ISA SP-20 - "Specification Forms"
3) ISA SP-75.05 - "Control Valve Terminology"
4) ISA SP-50 definition.
References are given for all parts defined in sources 1-3.
Editor's Note: code numbers will be brought back to this table

from Table 15 later.
Field Bus Device:

Power drawn from the Bus
Lift-off voltage
Note: this "part" will apply only to the physical node; it will be
independent of the hardware I/O point identified.
Associated Device Identification:

Note: the physical node has provision for two clipboards, one to
describe the Field Bus device itself (for example, a valve
positioner) and the second for an "associated" device (for
example, a valve).
Associated device Manufacturer's Name (use "VC" type materials code).
Associated device Model number (use "VC" type materials code).
Associated device Serial number (use "VC" type materials code).
Associated device installation date (i.e., time of joining of the two
devices) (to be considered "coded", this part number MUST be
combined with a "VD" type of materials description).
--```,``-`-`,,`,,`,`,,`---
Pressure Transmitter
Pressure Transmitter (gauge, absolute, or differential), Differential Pressure
Transmitters Used As Level Transmitters, and Pressure Switches:
Body (wetted parts of)
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
(ISA-S20-1981, Form S20.20a, line 19)

Body Flanges
Body Seals
Body-to-Body Bolts
Bubbler Fluid
Capillary Fill Fluid
Chemical Seals
Element (i.e., diaphragm, bourden tube, bellows)
(ISA-S20-1981, Form S20.20a, line 19)
(ISA-S20-1981, Form S20.40a, line 19)

393
(ISA-S20-1981, Form S20.42a, line 5)

Fill Fluid
Purge Fluid
Switch Contact Plating
Pre-Fabricated Meter Run Assembly:

Codes from the appropriate meter/transmitter set.
Orifice Flanges
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
(ISA-S20-1981, Form S20.21, line 10)

Pipe
Pipe Flanges
Pipe Gaskets
Primary Element (orifice, nozzle, tube, etc.)
(ISA-S20-1981, Form S20.21, line 4)
Ring Joint Assembly Material
(ISA-S20-1981, Form S20.21, line 5)
--```,``-`-`,,`,,`,`,,`---
Positive Displacement Flowmeter

Bearings
(ISA-S20-1981, Form S20.25, line 17)
Blades
(ISA-S20-1981, Form S20.25, line 16)
(ISA-S20-1981, Form S20.25, line 12)
Body Cover
(ISA-S20-1981, Form S20.25, line 13)
Body Flanges
Packing (/Seals)
(ISA-S20-1981, Form S20.25, line 18)
Rotating Element (ex. blades)
(ISA-S20-1981, Form S20.25, line 14)
Shaft
(ISA-S20-1981, Form S20.25, line 15)
Magnetic Flow Meter

Connection Pipe Flange
(ISA-S20-1981, Form S20.23, line 7)
Connection Pipe Sections (up and down stream runs)
(ISA-S20-1981, Form S20.23, line 5)
Electrode
(ISA-S20-1981, Form S20.23, line 11)
Grounding Rings
Tube
(ISA-S20-1981, Form S20.23, line 8)
Tube Lining
(ISA-S20-1981, Form S20.23, line 9)
Target Flowmeter
Body Flanges
Force Bar
Force Bar Seal
Target

394
Turbine Flow Meter

Bearings
(ISA-S20-1981, Form S20.24, line 18)
(ISA-S20-1981, Form S20.24, line 12)
Body Flange
(ISA-S20-1981, Form S20.24, line 15)
Connection Pipe Sections (up and down stream runs)
Meter (Rotor) Support
(ISA-S20-1981, Form S20.24, line 13)
Rotor
(ISA-S20-1981, Form S20.24, line 16)
Rotor Shaft
(ISA-S20-1981, Form S20.24, line 14)
Straightening Vanes
Variable Area Flowmeters:

End Fittings
(ISA-S20-1981, Form S20.22, line 9)
(ISA-RP16.1,2,3-1959, Section 5, Part No. 1)
Extension Well/Housing
(ISA-S20-1981, Form S20.22, line 30)
Extension Well to Body Gasket
(ISA-S20-1981, Form S20.22, line 31)
Float/Displacer (including rod)
(ISA-S20-1981, Form S20.22, line 13)
(ISA-RP16.1,2,3-1959, Section 5, Part No. 8 or 8a)
Plug Gasket
Tube Material
(ISA-S20-1981, Form S20.22, line 13)
(ISA-RP16.1,2,3-1959, Section 5, Part No. 6 or 29)
Tube Packing (tube seat gasket)/Tube O-Ring
(ISA-S20-1981, Form S20.22, line 10)
(ISA-RP16.1,2,3-1959, Section 5, Part Nos. 5 & 9)
Vortex Shedding Flow Meter

Bluff Body (shedder)
Body Flange
Sensor
Sensor Diaphragms
Mass Flow Meter (Coriolis)

Enclosure ("Secondary", "Pressure")
Pipe Flange
Tube
Level Transmitter:
Body-to-Chamber Bolts
Cage/Chamber (wetted parts of)
(ISA-S20-1981, Form S20.26, line 4)
Cage/Chamber Flange
Displacer Trim
Float/Displacer (including rod)

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
395
(ISA-S20-1981, Form S20.26, line 16)

Float/Displacer Cable/Spring/Tape/Tube
(ISA-S20-1981, Form S20.26, line 17 with "tape/cable" added)
Packing/Seals
Level Instruments, Capacitance Type

Body Flange
Probe
(ISA-S20-1981, Form S20.27, line 10)
Probe Sheath
(ISA-S20-1981, Form S20.27, line 11)
Sealing Gland
(ISA-S20-1981, Form S20.27, line 14)
Temperature Transmitter:
Head
(ISA-S20-1981, Form S20.12a, line 7)
(ISA-S20-1981, Form S20.13a, line 4)
Packed Connector
(ISA-S20-1981, Form S20.12a, line 5)
Thermocouple/RTD Type
(ISA-S20-1981, Form S20.12a, line 2)
(ISA-S20-1981, Form S20.13a, line 6)
Thermocouple/RTD Sheath
(ISA-S20-1981, Form S20.12a, line 3)
(ISA-S20-1981, Form S20.13a, line 10)
Thermowell/Tube
(ISA-S20-1981, Form S20.11a, line 22)
(ISA-S20-1981, Form S20.12a, line 9)
(ISA-S20-1981, Form S20.13a, line 13)
Centrifugal Pump:
Body Gasket
--```,``-`-`,,`,,`,`,,`---
Body Lining
Connection Pipe Gaskets
Connection Pipe Sections
Impeller
Shaft
Rotating Shaft Seal
Agitator:
Shaft
Impeller
Rotating Shaft Seal
Valve
Valve (valve information in positioner delivered as part of the valve assembly):
(ISA-S20-1981, Form S20.50, line 9)
(ISA-S20-1981, Form S20.51, line 10)
(ISA-S75.05-1983, Section 4.1)
Body Seal
(ISA-S75.05-1983, Drawing 5.1{b})
Body-to-Body Bolts
(ISA-S75.05-1983, Drawing 5.1{b})

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
396
Bonnet
(ISA-S75.05-1983, Section 4.2)
Bonnet-to-Body Bolts (Bonnet bolting)
(ISA-S75.05-1983, Section 4.2.3)
Bonnet-to-Body Gasket (Bonnet gasket)
(ISA-S75.05-1983, Section 4.2.2)
Bottom Flange Gasket
Flexible Closure Member/Elastomeric Tubular Member/Body Liner
(ISA-S75.05-1983, Section 5.3, Section 5.4, Appendix B)
Guides (bearings, bushings, or cage)
(ISA-S75.05-1983, Sections 4.7 and 5.1.4)
--```,``-`-`,,`,,`,`,,`---
Plug Contour
Used as the part description for the hardening material description
when the entire plug contour is hardened (material description is a
hardening process) or a plug insert is used (material description
is a material) (see "Trim").
Seal Back-up Ring
Seat and Orifice
Used as the part description for the hardening material description
when the entire seat and orifice is hardened (see "Seat/Seal")
Seat Ring/Seal (Primary)
(ISA-S20-1981, Form S20.50, line 14)
(ISA-S20-1981, Form S20.51, line 16)
(ISA-S75.05-1983, Section 4.4.1)
Note: an indication of hardening will imply only the seal edge of
the seat (see "Seat and Orifice")
Secondary (Back-up) Seal Ring
Shaft/Stem
(Shaft: ISA-S20-1981, Form S20.50, line 14)
(Stem: ISA-S75.05-1983, Section 4.5)
Stem Bellows (Bellows Stem Seal)
(ISA-S75.05-1983, Section 4.6.3)
Stem Packing
(ISA-S20-1981, Form S20.50, line 10)
(ISA-S20-1981, Form S20.51, line 11)
(ISA-S75.05-1983, Section 4.6.1)
Trim (i.e., ball, cage, disk, gate, plug, seat ring, stem, but not
seat nor shaft/stem)
(ISA-S20-1981, Form S20.50, line 14)
(ISA-S20-1981, Form S20.51, line 15)
(ISA-S75.05-1983, Sections 4.3, 4.4, and 4.5)
Note: if hardening or surface treating is shown for "trim", it
will be known to apply to the sealing edge of the
ball/disk/gate/plug only (see "Plug Contour"). If a
surface covering is indicated, such as a rubber liner, it
will be known to apply to the disk/gate/plug only.
Solenoid Valve:
(ISA-S20-1981, Form S20.55, line 8)
Diaphragm
(ISA-S20-1981, Form S20.55, line 10)
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Packing
(ISA-S20-1981, Form S20.55, line 12)
Seat
(ISA-S20-1981, Form S20.55, line 9)

397
HIF Table 15 Materials Specification List by Code Number

This Table presents a list of part descriptions arranged by code number.
When a part description is being chosen, preference must be given to the part
descriptions listed for the device in Table 14.
If there is no appropriate description listed for the device being described,

then an appropriate part can be chosen from the 0 to 189 range of coded parts in
the following table.
If there is no appropriate description listed for the part in 0 to 189 range

of the following table, then "temp-partx" can be used in the part description and
defined in the free-format portion of the clipboard. Alternately, a manufacturer-
specific code can be used and defined in the manufacturer's literature.
The general ranges of the codes are:

1-9 10-19 20-29 30-39 40-49 50-59 60-69 70-79
80-88 89-99 Tx a0-z9 0a-9z
Code PART DESCRIPTION

0 Null
1 Associated device Manufacturer's Name
2 Associated device Model number
3 Associated device Serial number
4 Associated device installation date
--```,``-`-`,,`,,`,`,,`---
5 Bearings
6 Blades
7 Bluff Body (shedder)
8 Body (wetted parts of)
9 Body-to-Chamber Bolts
10 Body Cover
11 Body Flanges
12 Body Lining
13 Body Seal(s)
14 Body-to-Body Bolts
15 Bonnett
16 Bonnett-to-Body Bolts
17 Bonnett-to-Body Gasket
18 Bottom Flange Gasket
19 Bubbler Fluid
20 Bulb
21 Cage/Chamber (wetted parts of)
22 Cage/Chamber Flange
23 Capillary
24 Capillary Fill Fluid
25 Chemical Seals
26 Connection Pipe Flange
27 Connection Pipe Gaskets
28 Connection Pipe Sections (up and down stream runs)
29 Diaphragm
30 Displacer Trim
31 Electrode
32 Element (i.e., sensing diaphragm, bourden tube, bellows)
33 Enclosure ("Secondary", "Pressure")
34 End Fittings
35 Extension Well/Housing
36 Extension Well to Body Gasket
37 Fill Fluid
38 Flange, other (not Body, Bottom Flange, Cage/Chamber,
connection Pipe, Orifice, nor Pipe flange)
39 Flexible Closure Member/Elastomeric Tubular Member/Body Liner
40 Float/Displacer (including rod)
41 Float/Displacer Cable/Spring/Tape/Tube
42 Force Bar
43 Force Bar Seal

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
398
44 Gasket, other (not Bonnett-to Body, Bottom Flange, Extension

Well to Body, Pipe, Plug, nor Tube Seat basket)
45 Grounding Rings
46 Guides (bearings, bushings, or cage)
47 Head
48 Impeller
49 Lift-off voltage
50 Meter (Rotor) Support
51 Orifice Flanges
52 Packed Connector
53 Packing/Seals
54 Pipe
55 Pipe Flange(s)
56 Pipe Gaskets
57 Plug Contour
Used as the part description for the hardening material
description when the entire plug contour is hardened
(material description is a hardening process) or a plug
insert is used (material description is a material) (see
"Trim").
58 Plug Gasket
59 Power
60 Primary Element (orifice, nozzle, tube, etc.)
61 Probe
62 Probe Sheath
--```,``-`-`,,`,,`,`,,`---
63 Purge Fluid
64 Ring Joint Assembly Material
65 Rotating Element (ex. blades)
66 Rotating Shaft Seal
67 Rotor
68 Rotor Shaft
69 Seal Back-up Ring
70 Sealing Gland
71 Seat and Orifice
Note: Used as the part description for the hardening
material description when the entire seat and
orifice is hardened (see "Seat/Seal")
72 Seat Ring/Seal (Primary)
Note: an indication of hardening will imply only the seal
edge of the seat (see "Seat and Orifice")
73 Secondary (Back-up) Seal Ring
74 Sensor
75 Shaft
76 Shaft/Stem
77 Stem Bellows
78 Stem Packing
79 Straightening Vanes
80 Switch Contact Plating
81 Target
82 Thermowell/Tube
83 Thermocouple/RTD Sheath
84 Trim (i.e., ball, cage, disk, gate, plug, seat ring, stem, but
not seat nor shaft/stem)
Note: if hardening or surface treating is shown for
"trim", it will be known to apply to the sealing
edge of the ball/disk/gate/plug only (see "Plug //^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Contour"). If a surface covering is indicated,
such as a rubber liner, it will be known to apply
to the disk/gate/plug only.
85 Tube
86 Tube Lining
87 Tube Material
88 Tube Packing (tube seat gasket)/Tube O-Ring
89-99 Reserved for future SP-50.

399
Tx Temp-Partx
where x = last digit of the code number. The free-format
part of the clipboard can then be used to define
Temp-Partx.
a0-z9 Reserved for future standards.
where "a" to "z" represents any capital alpha letters except
the letter "T".
0a-9z Manufacturer Specific
where "a" to "z" represents any capital alpha letters.
--```,``-`-`,,`,,`,`,,`---
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

400
HIF Table 16 Suggested Maintenance Codes

TABLE 16
SUGGESTED MAINTENANCE CODES
The maintenance code that must follow the "Field Bus Escape, H" characters in
the clipboard will be composed of 5 characters, arranged into records of 2, 1,
and 2 characters. The first field identifies the component of the field device
that was the object of the maintenance work (essentially the noun of the code);
the second identifies the trigger for the work; and the third identifies the
resolution of the work (essentially the verb).
This table lists the basic codes suggested for each field and their
descriptions. The table includes a "major group" description for the groups of
two-character codes. This entry is for information only: the symbols ending in
a "-" are never actually used in a clipboard.
Characters After "Field Bus Escape - H" (26 base 10 + 72 base 10):
Character
Value
Field 0 - first two characters - device component:

-- Any identifier from the parts list
(See Table 14- "Human Interface Considerations")
(Note that the identifier from the parts list
will always have a lead numeric character.)
A- Major group "Air supply"
65,83 AS Air supply
65,70 AF Air supply filter
65,85 AU Air supply pressure gauge/block valve - upstream side
65,82 AR Air supply regulator
65,76 AL Air supply pressure gauge/block valve - load side
65,84 AT Air supply tubing/pipe
--```,``-`-`,,`,,`,`,,`---
C- Major group "Cabinet"
67,80 CP Cabinet/enclosure purge supply
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
67,70 CF Cabinet/enclosure purge supply filter
67,85 CU Cabinet/enclosure purge supply pressure gauge/block
valve - upstream side
67,82 CR Cabinet/enclosure purge supply regulator
67,76 CL Cabinet/enclosure purge supply pressure gauge/flow
indicator/block valve - load side
67,84 CT Cabinet/enclosure purge supply tubing/pipe
67,67 CC Cabinet/enclosure cooler
67,69 CE Cabinet/enclosure electrical heater
67,83 CS Cabinet/enclosure steam heater
67,78 CN Cabinet/enclosure fan
67,72 CH Cabinet/enclosure hydrocarbon sensor
67,68 CD Cabinet/enclosure door/cover - gasket/hinge/latch/
bolts
67,73 CI Cabinet/enclosure door/cover interlock switch/wire
67,77 CM Cabinet/enclosure corrosion monitor
D- Major group "Display"

68,87 DW Local display - window
68,68 DD Local display - display element
68,73 DI Local display - input element/buttons/switches (not
power switch).
68,76 DL Display Lamp
68,65 DA Alarm display window
68,72 DH Annunciator horn
68,77 DM Paper drive motor

401
68,80 DP Recorder pen and pen drive
E- Major group "Local Electric Power"

69,80 EP Local electric power supply (used in conjunction with
"connected" maintenance service)
69,83 ES Local secondary selective power supply
69,71 EG Local battery/battery charger
69,66 EB Local electric power distribution box - breaker/fuse
69,67 EC Local electric power distribution box cover/bolts/
gasket.
69,76 EL Local electric power lines
69,70 EF Local electric power line filter
69,88 EX Local electric power lines flex/conduit
F- Major group "Field Bus" (note: not at instrument site)

70,74 FJ Junction box connection
70,84 FT Terminator
70,67 FC Shield connection
70,71 FG Shield ground
70,76 FL Lightning surge protector
70,66 FB Barrier
70,69 FE Barrier earth
70,70 FF Field Bus power fuse/resistor
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
70,83 FS Field Bus switch
G- Major group "Purge fluid"

(Note: this group is used for valve stem packing
purge systems and sample purge systems, NOT
cabinet.)a
71,83 GS Purge fluid supply
71,70 GF Purge fluid supply filter
71,85 GU Purge fluid supply pressure gauge/block valve -
upstream side
71,82 GR Purge fluid regulator
71,76 GL Purge fluid supply pressure gauge/flow indicator/block
valve - load side
71,84 GT Purge fluid tubing
H- Major group "Hydraulic fluid"

72,83 HS Hydraulic fluid supply
72,70 HF Hydraulic fluid supply filter
72,85 HU Hydraulic fluid supply pressure gauge/block valve -
upstream side
72,82 HR Hydraulic fluid regulator
72,76 HL Hydraulic fluid supply pressure gauge/block valve -
load side
72,84 HT Hydraulic fluid tubing/pipe
I- Major group "Instrument"
--```,``-`-`,,`,,`,`,,`---
73,80 IP Power supply board
73,77 IM Main Circuit board
73,68 ID Daughter board
73,70 IF Field Bus driver board
73,73 II Input board/module
73,79 IO Output (or I/O) board/module
73,65 IA Instrument alarm switch
73,66 IB Field Bus connection to field instrument.
73,87 IW Field Bus wire at field instrument (used in
conjunction with "connected" maintenance
service.)
73,88 IX Field Bus flex/conduit
73,71 IG General electronics (used in conjunction with
"started" and "commissioned" maintenance
services.)
73,67 IC Electronics cover/bolts/gasket
73,76 IL Field instrument local ground system
73,69 IE Wire entry cover/bolts/gasket

402
73,83 IS Power Switch

73,48 I0 Circuit breaker - primary power
73,49 I1 Circuit breaker - secondary power
73,50 I2 Circuit breaker - battery
73,51 I3 Circuit breaker #1
73,52 I4 Circuit breaker #2+
73,53 I5 Fuse - primary power
73,54 I6 Fuse - secondary power
73,55 I7 Fuse - battery
73,56 I8 Fuse #1
73,57 I9 Fuse #2+
M- Major group "Miscellaneous"

77,77 MM Motor/Actuator
77,76 ML Actuator linkage
77,67 MC Actuator compensation
77,86 MV Associated process valve
77,66 MB Instrument mounting
77,70 MF Fireproofing
--```,``-`-`,,`,,`,`,,`---
77,83 MS Solenoid
77,82 MR Relay
77,76 ML Loop
77,49 M1 Block Valve
77,50 M2 Cotter Pin
77,51 M3 Cutout switch
77,52 M4 Sample time stamp switch
77,53 M5 Switch contacts
77,54 M6 Tape
77,55 M7 Turnbuckle
77,56 M8 Union
77,57 M9 Union w/ Plug
P- Major group "Process"

80,67 PC Process connection lines (used in conjunction with
"blew down" and "bored out" maintenance
services.)
80,83 PS Seal legs
80,77 PM Process connection manifold
80,73 PI Process connection lines - isolation valve(s)
80,66 PB Process connection lines - balancing valve
80,70 PF Process fluid filter
80,80 PP Primary sample loop regulation
80,49 P1 Secondary sample loop
80,50 P2 Secondary sample loop filter
80,51 P3 Secondary sample loop regulation
80,68 PD Drain/Sample valve
R- Major group "Remote"

(Note: this group is intended to refer to devices
that are geographically separate from the
Field Instrument.)
82,83 RS Remote sensor switch
82,80 RP Remote primary transducer
82,84 RT Remote analog transmitter
82,87 RW Remote sensor wire/tube
82,82 RR Remote sensor dropping resistor
82,77 RM Remote sensor - mechanical
S- Major group "Sensor"

(Note: this group is intended to refer to devices
that are an integral part of the Field
Instrument.)
83,80 SP Sensor probe
83,77 SM Sensor mounting
83,83 SS Sensor probe safety chain
83,84 ST Sensor probe spot (tack) weld
83,86 SV Sensor probe installation valve

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
403
83,72 SH Sensor probe head

83,71 SG Sensor probe head cover gasket/seal/bolts
83,87 SW Sensor probe well
83,49 S1 Sensor, primary (used in conjunction with
"calibration" type maintenance services).
83,50 S2 Sensor, secondary (used in conjunction with
83,51 S3 Sensor, tertiary (used in conjunction with
83,52 S4 Sensor, fourth (used in conjunction with "calibration"
type maintenance services).
83,67 SC Compensator
83,88 SX Proximeter
T- Major group "Transducer"

84,70 TF F/I Transducer
84,73 TI I/P Transducer
84,80 TP P/I Transducer
84,86 TV V/I Transducer
W- Major group "Winterize"

87,83 WS Steam Tracing - lines
87,84 WT Steam Trap
87,69 WE Electrical Heat Tracing - lines
87,80 WP Electrical Heat Tracing - Power Supply
87,76 WL Insulation - lines
87,68 WD Insulation - device
Field 1 - fourth character - maintenance type:
65 A Accounting
67 C Critical
50 2 Critical, call-out
73 I Installation
84 T Turnaround
82 R Routine - scheduled
85 U Routine - unscheduled
83 S Safety - scheduled
49 1 Safety - unscheduled
Field 2 - fifth and sixth characters - service type:
C- Major group "Calibration"

67,72 CH Checked high calibration - no significant change
67,76 CL Checked low calibration - no significant change
67,49 C1 Checked high and low calibration - no significant
change
67,50 C2 Calibrated - high
67,51 C3 Calibrated - low
67,52 C4 Calibrated - high and low
67,65 CA Adjusted
67,66 CB Blew-down
67,73 CI Can't calibrate/test/prove - instrument fault
67,74 CJ Can't calibrate/test/prove - need process
67,75 CK Can't calibrate/test/prove - turnaround only
67,79 CO Can't calibrate/test/prove - must be offline
67,80 CP Proved
67,84 CT Tuned
67,85 CU Finished auto-tuning
D- Major group "Maintenance Delayed" (intention: if plant

uses work orders, this DOES NOT terminate work
order)
68,69 DE Maintenance delayed - no local electric power
68,72 DH Maintenance delayed - hot work

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
404
68,73 DI Maintenance delayed - inaccessible

68,77 DM Maintenance delayed - awaiting material
68,80 DP Maintenance delayed - process
68,84 DT Maintenance delayed - awaiting tools
E- Major group "Electrical"

69,66 EB (Breaker) open - closed
69,70 EF (Fuse) blown - replaced
69,71 EG Grounded - fixed
69,72 EH Hard reset - restarted
69,73 EI New firmware installed and restarted
69,74 EJ Jumpered
69,76 EL Loose/corroded (contacts) - cleaned and tightened
69,79 EO Open (wire/circuit) - fixed
69,82 ER Old firmware reinstalled and restarted
69,83 ES Shorted (wire/circuit) - fixed
69,87 EW Wet - dried out and restarted
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
H- Major group "Hardware"
72,65 AA Adjusted (but not "calibrated/tuned/proved")
72,66 AB Broken - replaced
72,67 AC Car-seal missing - replaced
72,76 AL Loose - fixed
72,77 AM Missing - replaced
72,79 AO Open - closed/resealed.
I- Major group "Installation/mothballing"

73,69 IS Sealed for mothballing
73,73 II Installed
73,67 IC Connected
73,68 ID Drained for mothballing
73,70 IF Filled
73,71 IG Greased/lubricated for mothballing
73,76 IL Loop checked
73,79 IO Configured
73,83 IS Started
73,67 IC Commissioned
L- Major group "Lubrication"

--```,``-`-`,,`,,`,`,,`---
76,65 LA Adjusted lubricator

76,67 LC Checked lubricator
76,76 LL Lubricated
76,77 LM Checked/adjusted mister
76,79 LO Checked/leveled oil
76,82 LR Replaced lubricator
M- Major group "Miscellaneous" (intention: never

electrical)
77,65 MA Added
77,66 MB Bored out
77,67 MC Cleaned
77,68 MD Drained
77,69 ME Engineering change completed
77,70 MF Bad/broken - fixed
77,71 MG Plug removed
77,73 MI Isolated from process
77,76 ML Leaking - fixed
77,78 MN No problem found
77,79 MO Oil in lines - drained
77,80 MP Position wrong - fixed
77,82 MR Repaired
77,83 MS Stuck - freed
77,84 MT Tightened
77,87 MW Water in - drained (not electrical)
77,88 MX Diagnostic cleared
77,90 MZ Deleted
77,48 M0 Corroded - cleaned (not electrical wires)

405
77,49 M1 Corroded - cleaned - needs watching (not electrical

wires)
77,50 M2 Loose - adjusted (not electrical wires)
77,51 M3 Relocated
77,52 M4 Retubed/repiped
77,53 M5 Tuned
77,54 M6 Wrong - fixed
O- Major group "overhaul"

(Note: it is expected that each user would define
overhaul classes for each type of
instrument.)
79,49 O1 Overhaul - Class 1
79,50 02 Overhaul - Class 2
" " "
79,57 09 Overhaul - Class 9
P- Major group "Packing"

80,65 PA Adjusted packing follower
80,67 PC Checked packing
80,82 PR Added/replaced packing
S- Major group "Maintenance Stopped" (intention: if plant

uses work orders, this DOES NOT terminate work
order)
83,69 DE Maintenance stopped - lost local electric power (for
work, not for the instrument)
83,72 DH Maintenance stopped - hot work permit expired
83,73 DI Maintenance stopped - awaiting help
83,77 DM Maintenance stopped - awaiting material
83,80 DP Maintenance stopped - process
83,84 DT Maintenance stopped - awaiting tools
83,90 DZ Maintenance stopped - higher priority interrupt
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
W- Major group "Warning" (intention: statement of fact:
not proceeding to fix).
87,65 WA Calibration needed
87,66 WB Cover bolts missing
87,67 WC Cover missing
87,69 WE Engineering change required
87,70 WF Fireproofing needed/damaged
87,71 WG Cover gasket missing
87,72 WH Cover hinge broken
87,73 WI Insulation needed/damaged
87,76 WL Leaking - can't stop
87,80 WP Poor condition
87,82 WR Extensive corrosion
87,87 WW Winterizing not working
X- Major group "Can't work" (intention: if plant uses

work orders, this terminates this work order)
88,66 XB Can't work - block valves no good - can't isolate
88,69 XE Can't work - no local electric power (for work, not
for instrument)
88,72 XH Can't work - hot work
88,73 XI Can't work - inaccessible
88,77 XM Can't work - materials unavailable
88,80 XP Can't work - process
88,84 XT Can't work - required tools unavailable
88,84 XW Can't work - needs electrician
88,84 XX Can't work - needs pipe fitter
88,84 XY Can't work - needs instrument mechanic
Z- Major group "Beyond Repair" (intention: if plant uses

work orders, this terminates this work order)
90,65 ZA Replaced - previous device held for analysis
90,76 ZL Replaced - previous device to local spares

--```,``-`-`,,`,,`,`,,`---

406
90,80 ZP Replaced - previous device to plant spare

90,83 ZS Replaced - previous device to shop
90,84 ZT Replaced - previous device trashed
90,66 ZB Bad/broken - left as found
90,67 ZC Confirmed bad - blocked from process
90,68 ZD Disconnected/bypassed
90,70 ZF Field Bus disconnected
90,72 ZH Problem in control house
90,69 ZE Out of service - no local power for instrument
90,73 ZI Incorrect for service - left out of service
90,81 ZQ Appears unreliable - left in service
90,82 ZR Appears unreliable - left out of service
90,50 Z1 Leaking - left as found
90,51 Z2 Leaking - disconnected from process
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
90,52 Z3 Not confirmed bad - blocked from process
90,53 Z4 Sent out for repairs, not replaced
90,90 ZZ No appropriate code
--```,``-`-`,,`,,`,`,,`---

407
Attach. 2 - Material Description
Material Description
This attachment defines the exact structure of a "material description" used
in a standard SP-50 Field Bus clipboard. The material description is combined
with a part code to indicate the material of construction of a part of a field
device. The procedure is primarily oriented toward describing the material of
construction of parts of the field device that are "wetted" by process fluids and
hence more susceptible to corrosion.

MD FORMAT
NATIONAL DESCRIPTION
CLASS DESCRIPTION
NATIONAL/CLASS DEFINITIONS
AB - Ring-Joint Gaskets.
VC - Visible Characters.
ZC - Industrial Ceramics, Cermets, and Powder Met.
AD - Double-Jacketed Metallic Gaskets.
VD - Visible Date.
AE - Electrical Classification.
AF - Nonmetallic Gasket Materials.
AG - Other Gaskets and Non-plastic Diaphragms.
AI - Rubber-Gasket Joints for Ductile-Iron Pressure Pipe.
ZL - Liquids and Gases.
ZM - Miscellaneous Material Descriptions.
ZN - Null - material not defined.
AP - Plastic Materials.
AR - Rubber and Rubber Latices.
AS - Spiral-Wound Metallic Gaskets.
ZT - Thermocouples and Resistance Temperature Devices.
AU - Metal and Alloys.
ZV - Stem and Shaft Packing Materials and Seals.
ZW - Power Demand.
AX - Service Pressure Limit.
ZY - Surface Treating and Hardening, Material Color, and
Paint Systems.
--```,``-`-`,,`,,`,`,,`---
?9&?Z - Material Descriptions Defined by the Manufacturer
Table 1 - Industrial Ceramics, Cermets, and Powder Metallurgy
Table 2 - Miscellaneous Material Descriptions
Table 3 - Surface Treating and Hardening, Material Color, and
Paint Systems
MD FORMAT:
The clipboard uses the non-printable ASCII command <GS> (Char. 29) to
indicate the beginning and the end of a part/material description. The first
<GS> is followed by the code for the part as defined in the Human Interface
Considerations document. That is followed by the material description described
in this attachment. The second <GS> command follows the (last) material
description.
In all cases, the material description will start with a non-printable

command to facilitate data base parsing. The command will be the ASCII command
<RS> (value of 30 decimal, 1E hex). Hereafter in this specification, it will be
referred to as the "MD-Start" symbol. The character value of 30 can not be used
within a pair of <GS> commands for any other purpose in the clipboard.
Many of the "material" descriptions will reference national and international

standards. The second character of the "material" description will be a Field

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
408
Bus defined alpha character denoting the nationality of the standard referenced
and hereafter called "National".
The third character of the "material" description will be a SP-50 defined

alpha-numeric character denoting the description "Class". In some cases, the
information that follows the alpha-numeric character will describe a single
material. In other cases, the information will describe a complex composition or
a fabricated article. Some of the complex descriptions incorporate other
material descriptions: these descriptions can be descriptions of single
materials or even other complex descriptions. The entire set of descriptions is
defined so that a clipboard in a field device can be automatically searched by a
higher level device for a particular material or the description of a particular
part.
The following rules will refer to a "line call-out". This is a definition,

at the individual character level, of the exact format of the main body of the
material description. It is required that all Field Bus devices that include a
Field Bus Standard clipboard follow the exact instructions of the call-out in
order to facilitate the implementation of higher-level interfaces to the
clipboard data.
Unless explicitly stated otherwise, all alpha characters in the line called
out will be upper case.
--```,``-`-`,,`,,`,`,,`---
In all cases, the material description will end with an ASCII non-printable
command to facilitate data base parsing. The command will be the ASCII command
<US> (value of 31 decimal, 1F hex). Hereafter in this specification, it will be
referred to as the "MD-End" symbol. The ASCII character 31 can not be used
between a pair of <GS> commands for any other purpose in the clipboard.
Unless specifically stated otherwise, references to the line called out in

the following definitions DO NOT include the MD-Start symbol, the National alpha
character, the Class alpha-numeric character, nor the MD-End symbol of the
immediate material description. Because of the nesting mentioned above, the line
call-out may include other material descriptions which will include their own MD-
Start, national, Class, and MD-End symbols. Most call-outs allow the description
to be terminated short but the portion presented must be in order as given in the
call-out. The MD-Start symbol, the National and the Class characters, and the
MD-End symbol must be present.
NATIONAL DESCRIPTION:
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
The "National" alpha character will denote:

A - USA based standards (ANSI, API, ASME, ASTM, AWWA, ISA, MMS,
NFPA)
B - British standards (BS)
C - Canadian based standards
D - German standards (DIN, WBL)
E - CENELEC
F - French standards (AFNOR)
I - IEC and ISO standards
J - Japanese standards (JIS)
N - Belgian standards (NBN)
U - Italian (UNI)
V - Special Case - Used as VC and VD for "visible".
Z - Classification systems that are not standards based
All other letters - reserved for future Field Bus Standards
definition.

409
CLASS DESCRIPTION:
The alpha-numeric "Class" character, combined with the leading National
identifier, defines a material description as being based on (note that this
table is arranged in Class order):
AB - The standard "Ring-Joint Gaskets and Grooves for Steel Pipe
Flanges" (ANSI B16.20).
VC - The material of construction will be given as visible characters.
ZC - A description system for industrial ceramics (including glass and
refractories), cermets, and powder metallurgy.
AD - The standard "Double-Jacketed Metallic Gaskets" (API 601).
VD - The date will be given as visible characters.
AE - A description system for defining the most severe electrical
classification for which the device is suitable (NFPA - NEC).
AF - The standard "Standard Classification System for Nonmetallic
Gasket Materials" (ASTM F 104).
AG - A description system for all other gaskets and non-plastic
diaphragms.
AI - The standard "Rubber-Gasket Joints for Ductile-Iron Pressure Pipe
and Fittings - (ANSI/AWWA C111/A21.11). (Current version - 1990.)
ZL - A set of material descriptions for liquids and gases.
ZM - A set of miscellaneous material descriptions defined by the SP-50
Standard.
ZN - Null - material not defined.
AP - The standard "Standard Classification System for Specifying
Plastic Materials" (ASTM D-4000).
AR - The standard "Standard Practice for Rubber and Rubber Latices -
Nomenclature" (ASTM D-1418).
AS - The standard "Spiral-Wound Metallic Gaskets" (API 601).
ZT - A description system for thermocouples and resistance temperature
devices.
AU - The standard "Unified Numbering System for Metal and Alloys" (ASTM
--```,``-`-`,,`,,`,`,,`---
DS-56)
ZV - A description system for all stem and shaft packing materials and
seals.
ZW - A description system for defining power demand.
AX - A description system for defining the service pressure limit.
ZY - A description system for surface treating and hardening, material
color, and paint systems.
?9&?Z - A set of material descriptions defined by the manufacturer where
"?" is the nationality of the manufacturer or "Z".
All other characters - reserved.
NATIONAL/CLASS DEFINITIONS:
The definition of the call-out for the material description is given below
for each of the classes in the order shown above.
AB - Ring Joint Gaskets

AB - The standard "Ring-Joint Gaskets and Grooves for Steel Pipe Flanges"
(ANSI B16.20). (Current version - 1973.)
+ This class will not be used for gaskets that meet API Standard
"6A-Wellhead Equipment". (API = American Petroleum Institute.)
+ The ANSI B16.20 standard does not define a specific line call-
out: that will be accomplished as part of SP-50. The
terminology of the definition of the line call-out in SP-50 will
use the terminology of ANSI B16.20. (ANSI = American National
Standard Institute.)
+ If the line called out is not zero length, the first character of
the line (immediately following the class symbol "B") will be a
single alpha-numeric character that defines the shape of the

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
410
cross section of the gasket. The definition of this character is

completely consistent with ANSI B16.20. However, in a Standard
Field Bus clipboard, the character must be provided and will be
one of:
T = Octagonal
V = Oval
R = RX gaskets
X = Unknown
All other characters - reserved for assignment by the Field
Bus standard to ANSI B16.20 standard
cross-sections.
+ If the line called out for the gasket is longer than one
character, the second character will be the start of a material
description for the gasket. (The 1973 version of ANSI B16.20
essentially requires that the material be a metal or alloy
(material National/Class "AU").) The description will start with
its own MD-Start symbol and end with its own MD-End symbol.
The abbreviations given in ANSI B16.20 for the gasket material

specifically WILL NOT be used in the SP-50 version of the
call-out. The following table gives the conversion between the
1973 list of gasket materials and the call-out for the
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
National/Class "AU" system:
Soft Iron K00YYY

Low-Carbon Steel G10YYY
4-6 Percent Chrome, 1/4%
Molyb. Steel K42544
Type 410 Steel S41000
If there is only one character in the entire line called out, the
gasket material will, by default, be G10YYY (generic low-carbon
steel).
+ The last character of the description will be a standard MD-End

symbol (not part of the call-out) even if that results in two
such symbols in series.
VC - Visible Characters
VC - The "material of construction" will be given as a string of visible
characters. The characters given in Table 9, unless prohibited by
formatting rules, can be used as control characters. Also, the
escape characters (the special codes that start with the "Escape"
code) in Table 13 will be allowed in this field.
--```,``-`-`,,`,,`,`,,`---
ZC - Industrial Ceramics, Cermets, and Powder Met.
ZC - A description system for industrial ceramics (including glass and
refractories), cermets, and powder metallurgy.
The attached Table 1 provides definitions for this class of

materials.
The Field Bus Standard line call-out for this class of

materials is as follows:
+ The first character of the call-out will be a single alpha-

numeric character that defines the general type of material
or process:
A - Cermet coating
B - Bonded abrasive
C - Cermet

411
D - Dry process porcelain enamel

E - Porcelain enamel (process not specified)
F - Wet process porcelain enamel
G - Glass or Glass-ceramic coated or lined
M - Powder metallurgy
P - Porcelain (Porcelain whiteware)
R - Bonded refractory
V - Ceramic Coating
W - Whiteware (Ceramic whiteware)
X - Material used directly
9&Z - Manufacturer specific
All other characters - reserved
+ If the first character was a D, E, F, or P, (porcelains) or
V or W (ceramics), the line called out may optionally
terminate at this point.
+ If the first character of this material's line called out
was an "M", (powder metallurgy), the full material
description for a metal or alloy will follow immediately
(for example, a National/Class "AU" material description).
The powder described must be the major component in the
powder mixture. This description will start with its own
MD-Start symbol and end with its own MD-End symbol.
+ In all other cases, the second and third character of the
line called out will be an integer chosen from the following
list of materials (both digits must be used):
Abrasives:
02 - Carborundum (used only for abrasives) (see
silicon carbide).
04 - Fused alumina (used for abrasives, not
ceramics) (see Alumina).
06 - Fused zirconia (used for abrasives, not
ceramics) (see Zircon).
08 - Quartz (used for abrasives, not ceramics)
(see Silica).
Carbides and Nitrides:
10 - Boron nitride (see Note 2 below).
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
11 - Chromium carbide (see Note 1 below).
13 - Silicon carbide (see Note 1 below) (see
Carborundum).
15 - Tantalum carbide (see Note 1 below)
16 - Titanium carbide (see Note 1 below)
17 - Titanium nitride (see Note 2 below)
18 - Tungsten carbide (see Note 1 below)
19 - Zirconium nitride (see Note 2 below)
Ferrites
22 - Iron oxide + barium oxide (barium ferrite)
24 - Iron oxide + manganese oxide
26 - Iron oxide + nickel oxide + zinc oxide
Glass:
30 - Aluminosilicate (chemically resistant
borosilicate glass (80% SiO2, 12%
B2O3, 4% N2O, 2% Al2O3)
Borosilicate crown glass:
31 - 70/75% SiO2, 5/10% B2O3
32 - 65/70% SiO2, 10/15% B2O3
33 - 60/65% SiO2, 15/20% B2O3
35 - Fused silica (100% SiO2)
36 - 96% Silica glass (96% SiO2, 3% B2O3)
37 - Soda-lime (SiO2, Na2O, and CaO)
38 - Lead glass
39 - Other
Piezoelectrics
42 - Barium titanate
44 - Lead niobate
46 - Lead zirconate + lead titanate
Porcelain enamels:
50 - Aluminum enamel

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
412
52 - Iron enamel
54 - Copper enamel
60 - Alumina (used for ceramics and cermets, not

abrasives) (see Note 3 below) (see Fused Alumina).
62 - Beryl (aquamarine, emerald)
64 - Beryllium oxide (BeO) (normally used as the ceramic
in an oxide cermet).
65 - Clay
66 - Common ceramic (not specified)
67 - Cordierite
68 - Corundum (ruby, sapphire, synthetic sapphire)
70 - Fluorite
71 - Forsterite
73 - Glass-ceramic
74 - Glass-reinforcement (generic) (used for reinforced
materials) (defined to match the symbol "G" in Table
2, ASTM D 4000-89)
76 - Lava
78 - Magnesia (see Note 3 below)
79 - Mullite
80 - Silica (used for ceramics, not abrasives) (see
Quartz).
82 - Steatite
84 - Talc
86 - Titania
88 - Zircon (used for ceramics, not abrasives) (see Fused
Zirconia).
All other numbers < 90 - reserved
90-99 - Manufacturer specific.
All other numbers - reserved.
Note 1: This symbol has two meanings. When used as the
first material in a cermet, it refers to the
powdered carbide. Elsewhere it refers to the
cemented carbide and implies a cobalt cement.
--```,``-`-`,,`,,`,`,,`---
powdered nitride. Elsewhere it refers to the

cemented nitride and implies a cobalt cement.
powdered mineral. Elsewhere it refers to the
type of ceramic.
+ If the first character was a "C" (cermet), then the material
code can optionally be immediately followed with a metal or
alloy material descriptor (for example, a National/Class
"AU" material descriptor). This descriptor will define the
metal in the cermet mixture. This description will start
with its own MD-Start symbol and end with its own MD-End
symbol.
+ If the first character of this material description was a

"M", (powder metallurgy), one or more full material
descriptions for a metal or alloy (for example, a
National/Class "AU" material) can optionally follow. The
powders described must be minor components in the powder
mixture. Each of these descriptions will start with their
own MD-Start symbol and end with their own MD-End symbol.
+ The last character of the description will be a standard

MD-End symbol (not part of the call-out) even if that
results in two such symbols in series.

413
AD - Double-Jacketed Metallic Gaskets

AD - The standard "Double-Jacketed Metallic Gaskets" (API 601). (Current
version - March 1988).
+ The API 601 standard does not define a specific line call-out:
that will be accomplished as part of SP-50. The terminology of
the definition of the line call-out in SP-50 will use the
terminology of API 601. (API = American Petroleum Institute.)
+ If the line being called out is not zero length, the first
character of the line (immediately following the class symbol
"D") will be a a single alpha-numeric character that defines the
pipe flange standard for which the gasket is suitable. The
definition of this character is completely consistent with API
601. However, in a Standard Field Bus clipboard, the character
must be provided and will be one of:
A - Suitable for use with flanges conforming to API
Standard 605.
M - Suitable for use with flanges conforming to MSS
SP-44. (MMS = Manufacturers Standardization Society
of the Valve and Fittings Industry).
--```,``-`-`,,`,,`,`,,`---
T - Suitable for use with flanges conforming to ANSI

B16.5. (ANSI = American National Standards
Institute).
B - Both API 605 and MSS SP-44.
C - Both API 605 and ANSI B16.5.
D - All three
N - Both MSS SP-44 and ANSI B16.5.
Bus standard to API 601 recognized
flange standards.
+ If the line being called out for the gasket is longer than one
description for the jacket. (The 1988 version of API 601
requires that the material be a metal or alloy (material
National/Class "AU").) The description will start with its own
The abbreviations given in API 601 for the materials for the
jacket specifically WILL NOT be used in the SP-50 version of the
1988 list of jacket materials and the call-out for the
Stainless Steels SYYYYY
Inconel 600 N06660
Inconel 625 N06625
Incoloy 800 N08800
Monel N04YYY
Titanium R5YYYY
Nickel N0YYYY
Inconel X750 N07750
Copper C1YYYY
Zirconium R6YYYY
Tantalum R05YYY
Hastelloy B N10001
Hastelloy C N10002
Carbon Steel K0YYYY
If there is only one character in the entire line being called

out, the jacket material will, by default, be K0YYYY (generic
carbon steel).
+ If the line being called out for the gasket continues past the
first material description, the next character will be the start
of a standard material description for the filler. A binder will
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
be implied as appropriate. The description will start with its

own MD-Start symbol and end with its own MD-End symbol.

414
filler specifically WILL NOT be used in the SP-50 version of
the call-out. The following table gives the conversion between
the 1988 list of filler materials and the SP-50 material
descriptions (the call-out plus the National/Class code but not
including the required MD-Start and MD-End symbols):
Asbestos with binder ZM04

Polytetrafluorethylene APPTFE
Flexible graphite ZM14
Ceramic ZCW
If the line being called out terminates before the second

material description, the filler material will, by default, be
ZM04 (chrysotile asbestos).

VD - Visible Date
VD - The "material of construction" will be given as a visible date.
This form requires the following format immediately after the
letters VD:
ddmmyyyy
where dd = the day as a TWO digit integer, 01 - 31 only.
A value of 00 will be allowed for the day and
will be taken to mean "not known".
mm = the month as a TWO digit integer, 01 - 12 only.
A value of 00 will be allowed for the month and
will be taken to mean "not known".
yyyy = the year as a four digit integer.
This field MUST consist of 8 visible number characters.
AE - Electrical classification
AE - A description system for defining the most severe electrical
classification for which the device is suitable (NFPA - NEC).
Reminder: this description system is only intended for
the National description "A" and those other
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
National applications that find it convenient
to follow essentially the same definitions.
+ This description system will be a pure superset of the NFPA
(National Fire Protection Association) "National Electric Code",
Article 500. That is, all portions of the system that refer
to the NFPA marking procedures will be entirely consistent with
those procedures as of the date of manufacture of the device.
+ The Field Bus Standard basic line call-out for this class will
consist of a highly variable string of characters that can be
parsed into individual groups of descriptions. The parsing
will depend on the restrictions imposed on the use of certain
characters.
+ The clipboard may contain more than one of these descriptors
in those cases where a device is designed to be used in a
variety of hazardous applications. Note, however, that the
description of the protective technique that is used can be
repeated within one descriptor.
+ The first one or more characters will indicate the protective
technique used. At least one character must be present.
The character(s) will be:
D - Flameproof (explosion proof) enclosure
E - Reserved (if NEC gives recognition to the equivalent of
the CENELEC method called "Increased safety", then this
letter will automatically become available for use for
that NFPA method).

--```,``-`-`,,`,,`,`,,`---

415
G -
General Purpose
I -
Intrinsic safety
M -
Encapsulation
N -
Non-incendive
O -
Oil filled
P -
Dust-ignition-proof
Q -
Powder filling
S -
Special
V -
Outside of the scope of the Field Bus description method.
X -
Purging - Type X installation as defined by NFPA 496.
Note: if more than 1 technique code is used and X is one
of them, then the letter X MUST be first.
Y - Purging - Type Y installation as defined by NFPA 496.
Z - Purging - Type Z installation as defined by NFPA 496.
All digits and the letters A,C,F,K, and T must never be used.
+ The second character (optional) will be a digit that defines the
most severe division in Class I for which the device is
applicable:
0 - Reserved (if NEC gives recognition to the equivalent of
CENELEC zone 0, then this digit will automatically become
available for use for that NFPA "division").
1 - Division 1
2 - Division 2
3 - Reserved (if NEC gives recognition to the equivalent of
CENELEC zone 1, then this digit will automatically become
available for use for that NFPA "division").
9 - General Purpose/not rated
4 - reserved
5-8 - must never be used
All alpha characters - must never be used.
--```,``-`-`,,`,,`,`,,`---
+ If the Class I Division is defined, then the next character must
be present and will be a letter that defines the Group(s) within
Class I for which the device is applicable:
A - Group A, B, C, and D
B - Group B, C, D
C - Group C and D
D - Group D
E - Group A, C, and D but not B
F - Group A only
Z - not applicable
All other alpha characters - reserved
All digits - must never be used
+ The basic description can terminate after the above characters.
Alternately, a digit can follow that defines the most severe
division in Class II for which the device is applicable:
5 - Division 1
6 - Division 2
4 - reserved
All other digits - must never be used.
+ If the Class II division is defined, it must be followed by an
alpha character. The character will define the most severe Group
for which the device is applicable:
E - Group E
F - Group F
G - Group G
Z - not applicable
All digits - must never be used.
All other letters - reserved
+ The basic description can terminate with only the above
characters. Alternately, a digit can follow that defines the
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
most severe division in Class III for which the device is

applicable:
7 - Division 1
8 - Division 2
4 - reserved

416

All other digits - must never be used.
+ Any combination of the above sets of characters can optionally be
followed by one of the following two sets of characters:
- the appropriate maximum temperature identification code
number as given in the NEC. This code will always start
with the letter "T" followed by a digit. There may be a
third character that, if present, must be an alpha
character but can not be the letters "X" nor "A".
- the maximum surface temperature. The set of characters
must be an alpha character followed by 1 to 4 digits. The
digits will be the maximum temperature and the alpha
character will be one of:
C = indicating degrees Celsius
F = indicating degrees Fahrenheit
K = indicating degrees Kelvin
+ The letter "A" can follow any legal combination of the above sets
of descriptors to indicate that one or more letters will follow
to identify the testing/listing/approval source. The defined
letters are:
C = Canadian Standards Association
F = Factory Mutual Research Corporation
M = the Manufacturer
U = Underwriters Laboratories, Inc.
The letters "T", "S", "E", and "I" are reserved.
The letter "X" must never be used.
All other letters are free.
+ Any combination of the above characters can optionally be
followed by the letter "X". This symbol will indicate that there
are approval considerations beyond the scope of this marking
system that should be referenced by the user.
symbol (not part of the call-out).
AF - Nonmetallic Gasket Materials

AF - The standard "Standard Classification System for Nonmetallic Gasket
Materials" (ASTM F 104). (Current version - approved 6/88.)
+ This name class will NOT be used for:

- Diaphragms
- Packing
- O-Rings
- D-Rings
+ This name class will NOT be used for the following parts unless
a revision of the F 104 standard is available that addresses the
specific features of:
- Gaskets containing any kind of metal
- Gaskets containing any kind of reinforcement or filler
+ In general, this class of material description will give a
detailed description of the principal material of the gasket (in
Field Bus notation) followed by the line call-out from the ASTM F
104 Standard. This is done because the F 104 Standard does not
give a full, detailed description of the principal material of
the gasket.
+ If the line being called out is not zero length, the first entry
in the line of this class will be a SP-50 material description.
The description will clearly define the principal component of
the gasket. Note that this description duplicates the "type of
material" identifier in F 104 but allows a much more detailed
definition. This description must be present. The description
will start with its own MD-Start symbol and end with its own
MD-End symbol.
+ The description of the principal material will optionally be
followed immediately by the "line call-out" specified in ASTM F
104. That specification will be obeyed exactly with the

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
417
following exceptions:
- The "ASTM F 104 (F" at the beginning of the line and the ")"
at the end of the line will be deleted.
- The remaining portion of the line call-out must be
structured as specified. It can contain only capital
letters, digits, and a single dash with no spaces.
- Any one of the first six numbers have a meaning of "not
specified" when set equal to zero. When applied in
an SP-50 clipboard, any one or more of the numbers can
be replaced with a "X" to mean "unknown".
- As specified by the F 104 standard, any one of the numbers
has a meaning of "as specified" when set to 9. This
reference can be to the free-format portion of the clipboard
as well as to the references mentioned in F 104.
- The suffix letter-numeral symbols are optional. If a
suffix is used, neither the letter nor the number can
be replaced with a "X".
- The portion of the material description derived from F 104
can be truncated at any position (including before the
first digit!).
- The portion of the call-out obtained from F 104 does not
have a terminator.
+ Note: reference can be made to ASTM F 36 - 88, Table 1 for
examples of materials described using the F 104 Standard.
AG - Other Gaskets and Non-plastic Diaphragms

AG - A description system for all other gaskets and non-plastic
diaphragms.
Note: Materials normally classified as rubber compounds are not

included in ASTM F 104 since they are covered in ASTM D 2000.
However, the current version of D 2000 is structured as a
properties specification, not as a material identification.
Since the object of the SP-50 material definitions is to
identify the material, not the specification of the service,
D 2000 is not useful.
+ ASTM D 1566 defines "rubberize" as - "to impregnate or coat, or

both, a substrate with rubber". This class will not
differentiate between "diaphragms" and "rubberized articles".
+ This class may be used for a gasket that can be described by
National/Class AF.
+ This class shall not be used for diaphragms whose elastomeric
portion consists purely of National/Class "AP" materials (use
National/Class "AP").
+ This class shall not be used for gaskets that conform to
National/Classes "AB", "AD", "AI", or "AS".
+ This class shall not be used for stem or shaft packing material
(use National/Class "ZV") unless it is an O-Ring.
+ The Field Bus Standard line call-out for this class of materials
is as follows:
- The first character of the line will be a single
alpha-numeric character that defines the general type of
article (the line for this class can not be zero length):
A - Suitable for small male and female pipe flanges.
B - Suitable for small tongue and groove pipe flanges.
D - D-Ring
Note: the following definition of a D-Ring will
be used: a product essentially similar to
an O-Ring except that the torus
configuration is modified to resemble the
letter D or any other closed shape except a
SP-50 User Layer Technical Report

--```,``-`-`,,`,,`,`,,`---
Human Interface Considerations

//^:^^
418
circle (see O-Ring definition below).

E - Envelope
Note: enveloped gaskets are described as gaskets
having some corrosion-resistant covering over
the internal area normally exposed to the
corrosive environment. The shield material may
be plastic (such as polytetrafluoroethylene) or
metal (such as tantalum). A resilient
conformable filler is usually used inside the
envelope (ASTM F 112-80, section 1.1)
F - Flat metal not defined in other types
G - Full face, suitable for flat face pipe flanges, not
referencing ANSI B16.21
H - Self-centering flat ring, not referencing ANSI
B16.21, suitable for raised face pipe flanges.
I - Small flat ring, not referencing ANSI B16.21,
suitable for raised face pipe flanges.
J - Suitable for large male and female pipe flanges, not
referencing ANSI B16.21.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
K - Suitable for large tongue and groove pipe flanges,
not referencing ANSI B16.21.
O - O-Ring
Note: the following definition of an O-Ring will
be used: a product of precise dimensions
molded in one piece to the configuration of
a torus with circular cross section
suitable for use in a machined groove for
static or dynamic service. (ASTM D
1566-90)
R - Non-plastic Diaphragms
T - Full face, meeting ANSI B16.21, suitable for flat
face pipe flanges.
U - Self-centering flat ring, meeting ANSI B16.21,
suitable for raised face pipe flanges.
V - Small flat ring, meeting ANSI B16.21, suitable for
raised face pipe flanges.
W - Suitable for large male and female pipe flanges,
meeting ANSI B16.21.
X - Gasket not meeting any other gasket class in this
table.
Note: Materials that are liquid and are applied as a
bead or other form to one or both mating faces
of a joint and act as a static seal are
included in the ZL material description class.
Y - Suitable for large tongue and groove pipe flanges,
meeting ANSI B16.21.
Z - Manufacturer specific.
0 - Facing material (gasket not fully enveloped)
1 - Envelope material
Note: enveloped gaskets are described as gaskets
having some corrosion-resistant covering over
the internal area normally exposed to the
corrosive environment. The shield material may
be plastic (such as polytetrafluoroethylene) or
metal (such as tantalum). A resilient
conformable filler is usually used inside the
envelope (ASTM F 112-80, section 1.1) For Field
Bus:
- the term envelope will serve for any
covering that totally encloses the
resilient filler.
- the term "base material" will refer to the
majority component of the resilient
(enclosed) portion of the gasket.
2 - Gasket (diaphragm) base material
3 - Gasket (diaphragm) base material filler/binder
4 - Gasket (diaphragm) substrate - fiber/wire

--```,``-`-`,,`,,`,`,,`---

419
5 - Gasket (diaphragm) substrate cloth - 1 ply

6 - Gasket (diaphragm) substrate cloth - 2 ply
7 - Gasket (diaphragm) substrate cloth - 3+ ply
8 - Lubricant incorporated into base material
9 - Surface lubricant
- If the line being called out in longer than one character
and the first character is alpha, then the second character
will be the start of the first standard material description
in a string of descriptors. The number of descriptions that
can be used is not defined. Each description will be a
National/Class "AG" description with a digital general type.
If the line being called out is longer than one character

and the first character is a digit, then the second
character will be the start of one (and the only one)
standard material description.
Each of these standard material descriptions will include

their own MD-Start symbol, class code, and MD-End symbol.

Note: the material description for a particular gasket may require

that several different types of materials be described.
National/Class "AG" has been defined in a way that allows one
to select the particular part of the gasket to be described.
A typical description would use an alpha general type to
describe the gasket, then include several National/Class
"AG", digital general type descriptions to cover the several
parts of the gasket. This would all be listed for one field
device part.
--```,``-`-`,,`,,`,`,,`---
AI - Rubber-Gasket Joints for Ductile-Iron Pressure Pipe
AI - The standard "Rubber-Gasket Joints for Ductile-Iron Pressure Pipe
and fittings - (ANSI/AWWA C111/A21.11). (Current version - 1990.)
+ The ANSI C111 standard does not define a specific line call-out:
that will be accomplished as part of SP-50. The terminology of
the definition of the line call-out in SP-50 will use the
terminology of ANSI C111 (ANSI = American National Standard
Institute.)
+ In the 1990 version of C111, flanged-joint gaskets are described
in Appendix B, which is for information only and is not a part of
ANSI C111. The SP-50 reference below is to the appendix
material.
+ If the line called out is not zero length, the first character of
the line (immediately following the class symbol "I") will be a
single alpha-numeric character that defines the type of gasket.
The definition of this character is completely consistent with
ANSI C111. However, in a Standard Field Bus clipboard, the
character must be provided and will be one of:
D = Push-on joint - dual rubber hardness
F = Flanged joint - full face gasket
M = Mechanical joint gasket
R = Flanged joint - ring gasket
S = Push-on joint - single rubber hardness
Z = modified but meets the performance requirements
+ If the line called out for the gasket is longer than one
description for the gasket. The description will start with its

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
420
If there is only one character in the entire line called out, the
gasket material will, by default, be SBR (styrene-butadiene
rubber).

ZL - Liquids and Gases

ZL - A set of material descriptions for liquids and gases.
This class of material descriptions is provided to describe,

but is not limited to, instrument impulse line sealing fluids,
line purges, and sealing fluids that are incorporated in a
field device itself.
Materials that are liquid and are applied as a bead or other form to
one or both mating faces of a joint and act as a static seal are
also covered by this class of materials
The line call-out will consist only of the two-digit code number
that is assigned to the material by the SP-50 Standard. Either the
line being called out can be zero length or both digits must be
supplied. The following material names are provided:
"Antifreeze":
00 - 40% Calcium chloride solution (CaCl2)
01 - Ethyl alcohol, (C2H6O)
02 - Ethyl alcohol in ethylene glycol
03 - Ethylene glycol, (C2H6O2)
05 - 50% Ethylene glycol in water
08 - Glycerin (glycerol), (C3H8O3)
09 - Glycerin in water
Gases:
10 - Air
12 - Heated N2
13 - Helium
15 - Inert Gas
17 - Natural Gas
18 - Nitrogen
Liquid gaskets:
24 - Shellac type sealant ("liquid gasket") compounds
26 - Sealant ("liquid gasket") compound, not shellac,
PTFE, nor silicone).
27 - PTFE based sealant ("liquid gasket") compounds.
--```,``-`-`,,`,,`,`,,`---
28 - Silicone based sealant ("liquid gasket") compounds,
Mineral Oils:
30 - Benzene, (C6H6)
32 - Heavy virgin gas oil
33 - Kerosene
35 - Light virgin gas oil
36 - Mineral Oil
38 Toluene, (C6H5CH3)
39 - Virgin naphtha
Misc. Liquids:
43 - Mercury
45 Process Fluid (clean)
46 - Sodium/Potassium
47 - Syltherm 800
49 - Water
Silicone Fluids
52 - Dimethylsiloxane

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
421
Silicone fluid
56 - pour point approx. -85 deg. F.
--```,``-`-`,,`,,`,`,,`---

Specialty Fluoro Fluids:
61 - Nitrogenated Fluoroliquid, ((C4F9)3N) - freeze
point approx. -60 deg. F.
62 - Oxygenated Fluoroliquid, (C8F16O) - freeze point
approx. -150 deg. F.
Trifluorovinyl chloride polymers -
64 - pour point approx. -60 deg. F
65 - pour point approx. +10 deg. F
66 - pour point approx. +60 deg. F
Trifluorochloroethylene polymers -
68 - pour point approx. 0 deg. F.
69 - pour point approx. +35 deg. F.
Specialty Non-Fluoro Halogen Fluids:
70 - Acetylene tetrabromide (tetrabromoethane),
(C2H2Br4)
72 - O-Dibromobenzene, (C6H4Br2)
73 - 1,1-Dibromoethane, (C2H4Br2)
77 - Perchlorethylene (C2Cl4)
Specialty Oxygenated Hydrocarbon Fluids:
81 - Butyl cellosolve (ethylene glycol monobutyl ether)
(glycol monoethyl ether) (2-ethoxy Ethanol),
(C6H14O2)
83 - Carbutol solvent (carbitol) (diethylene glycol
monoethyl ether) (2-(B-ethoxyethoxy)ethanol),
(C6H14O3)
85 - Dibutyl phthalate, (C16H22O4)
All other numbers - reserved.
ZM - Miscellaneous Material Descriptions

ZM - A set of miscellaneous material descriptions defined by the SP-50
Standard.

materials.
The Field Bus Standard line call-out for this class of

materials consists of a two-digit integer; both digits must be
used. The meaning of each value of the integer is:
Asbestos:
00 - Actinolite asbestos
02 - Amosite asbestos
03 - Asbestos (generic)
04 - Chrysotile asbestos
06 - Crocidolite asbestos
08 - Tremolite asbestos
Carbon:
10 - Activated charcoal
11 - Carbon and graphite fiber (generic) (used for fiber-
reinforced materials) (defined to match the
symbol "C" in Table 2, ASTM D 4000-89) The same
symbol will be used for carbon yarn packing.
12 - Diamond
13 - Graphite (pure)
14 - Graphite (with binder - flexible)
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
15 - Impervious Carbon (carbon + phenolic resin impregnant)

16 - Impervious Graphite, phenolic (graphite + phenolic
resin impregnant) (standard type of impervious
graphite)

422
17 - Impervious Graphite, modified (graphite + resin

modified for alkaline and oxidizing environments)
18 - Impervious Graphite, furan (graphite + furan
thermosetting resin)
19 - Impervious Graphite, epoxy (graphite + epoxy
thermosetting resin)
Temporary:
20 - Temp_Mtl0 | see elsewhere in the clipboard for a
21 - Temp_Mtl1 |-- definition of this material (note that a
22 - Temp_Mtl2 | "Temp_Mtlx" material can be defined by
23 - Temp_Mtl3 | other part/material specifications).
Animal or Plant Based:

30 - Animal fat
31 - Animal fat and petrolatum
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
33 - Cellulose
34 - Cotton
36 - Felt (any of wool, fur, or hair)
37 - Leather
39 - Wood
Misc.:
42 - Asphalt
46 - Combinations of reinforcements and fillers (generic) (used
for reinforced materials) (defined to match the symbol
"R" in Table 2, ASTM D 4000-89)
50 - Petroleum based Grease
54 - Lithium base white grease
56 - Lubricated (used for filled/reinforced materials) (defined
to match the symbol "L" in Table 2, ASTM D 4000-89)
58 - Manufacturer Proprietary
60 - Mica
62 - Mineral reinforcement (generic) (used for reinforced
materials) (defined to match the symbol "M" in
Table 2, ASTM D 4000-89)
64 - Molybdenum Disulfide
68 - Petroleum Wax (Petrolatum)
72 - Stem packing "plastic"
ZN - Null - material not defined

ZN - Null - not defined.
The call-out for this class will be a null string. The entire
material description will consist of the MD-Start symbol, the
letters "ZN", and the MD-End symbol.
AP - Plastic Materials
AP - The standard "Standard Classification System for Specifying Plastic
Materials" (ASTM D-4000) (Current version - Nov. 1989)
+ This name class WILL NOT be used for non-plastic materials nor
blends of elastomers that contain one or more non-plastic
components or more than one generic family (use class "R").
+ The "line call-out" specified in ASTM D-4000 will be obeyed
exactly except that the "ASTM D 4000" at the beginning of the
line will NOT be included.
+ The line being called out must present all of its components in
order but it may terminate at any location including the
beginning (thus generating the simple "plastic" description).
However, the line must not terminate within the generic family
name.

--```,``-`-`,,`,,`,`,,`---

423
+ Note that this called out line may start with either a digit
followed by at least two alpha characters or it may start with at
least two alpha characters.
+ It is possible that the third or subsequent character in the
generic family name (the fourth or subsequent character in the
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
call-out if the line starts with a digit) may be a "+". (See
abbreviation for a polyamide blend in ASTM D-1600.)
AR - Rubber and Rubber Latices

AR - The standard "Standard Practice for Rubber and Rubber Latices -
Nomenclature" (ASTM D-1418) (Current version - March 1985)
+ This name class will NOT be used for:

- Diaphragms with any type of reinforcement-filler
- Gaskets
- O-Rings
- D-Rings
- Packing
+ If a material consists of a mix of plastics or a mix of plastic
and rubber, this class can be used. Append a LOWER CASE "p" to
the name of all plastics.
+ The line call-out will obey the rules set forth in ASTM D-1418.
Note that the current version of the standard does not allow any
spaces in the name of a rubber. The only valid characters in the
call-out are alpha characters, one or more "/"'s, and one or more
"-"'s.
+ The line called out can be zero length (thus generating the
simple "rubber" description) or the full ASTM D-1418 generic
name.
AS - Spiral Wound Metallic Gaskets

AS - The standard "Spiral-Wound Metallic Gaskets" (API 601) (Current
version - March 1988).
+ The API 601 standard does not define a specific "line

call-out": that will be accomplished as part of SP-50. The
terminology of the definition of the line call-out in SP-50
will use the terminology of API 601.
+ If the line being called out is not zero length, the first
character of the line will be a single alpha-numeric character
that defines the pipe flange standard for which the gasket is
suitable. The definition of this character is completely
consistent with API 601. However, in a Standard Field Bus
clipboard, the character must be provided and will be one of:
A - Suitable for use with flanges conforming to API
Standard 605.
M - Suitable for use with flanges conforming to MSS
SP-44. (MMS = Manufacturers Standardization Society
of the Valve and Fittings Industry).
T - Suitable for use with flanges conforming to ANSI
B16.5. (ANSI = American National Standards
Institute).
B - Both API 605 and MSS SP-44.
C - Both API 605 and ANSI B16.5.
D - All three
N - Both MSS SP-44 and ANSI B16.5.
Bus standard to API 601 recognized
flange standards.
+ If the line called out is longer than one character, the second
character of the call-out will be a single digit. If the digit
is 1, an inner ring is provided, else the digit is a zero. (Note
that Section 3.1.6 of the current version of API 601 requires an

--```,``-`-`,,`,,`,`,,`---

424
inner ring under certain circumstances). If the digit is

truncated, the minimum requirement indicated in the applicable
standard will be assumed.
+ If the line called out is longer than two characters, the third
character of the call-out will be a single digit. If the digit
is 1, a centering ring is provided, else the digit is a zero.
(Note that Section 3.1.6 of the current version of API 601
requires a centering ring under certain circumstances). If the
digit is truncated, the minimum requirement indicated in the
applicable standard will be assumed.
+ If the line called out for the gasket is greater than three
characters, the fourth character will be the start of a standard
material description for the winding material. (The 1988 version
of API 601 requires that the material be a metal or alloy
(material National/Class "AU").) The description will start with
its own MD-Start symbol and end with its own MD-End symbol.
winding specifically WILL NOT be used in the SP-50 version of the
1988 list of winding materials and the call-out for the
Type 304 stainless steel S30400
Monel N04YYY
Nickel N0YYYY
Titanium R5YYYY
Alloy 20 N08020
Carbon Steel K0YYYY
Hastelloy B N10001
Hastelloy C N10002
Inconel N06YYY
If there are less than three characters in the entire line being
called out, the winding material will, by default, be S30400
(18Cr-8Ni stainless steel, AISI Type 304).
+ If the line called out for the gasket continues past the first
material description, the next character will be the start of a
standard material description for the filler. A binder will be
implied as appropriate. The description will start with its own
filler specifically WILL NOT be used in the SP-50 version of
the call-out. The following table gives the conversion between
the 1988 list of filler materials and the SP-50 material
descriptions (the call-out plus the National/Class code but not
including the required MD-Start and MD-End symbols):
Chrysotile asbestos ZM04
Blue African asbestos ZM06
Polytetrafluoroethylene APPTFE
Ceramic ZCW
Flexible graphite ZM14
If the line being called out terminates before the second

material description, the filler material will, by default, be
ZM04 (chrysotile asbestos).
second material description, the next character will be the start
of a standard material description for the inner ring. If the
line terminates before the second material description, the inner
ring material will, by default, be S30400 (18Cr-8Ni stainless
steel, AISI Type 304). The description will start with its own

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
425
third material description, the next character will be the start
of a standard material description for the centering ring. The
description will start with its own MD-Start symbol and end with
its own MD-End symbol.
If the line being called out terminates before the fourth

material description, the centering ring material will, by
default, be K0YYYY (generic carbon steel).

ZT - Thermocouples and Resistance Temperature Devices

ZT - A description system for thermocouples and resistance temperature
devices.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
must be at least one character long but can optionally be
extended to include two characters giving concise information and
two standard material descriptions.
- The first character of the call-out will be a single
character that indicates one of the following types of
material:
B - Platinum-30% Rhodium/Platinum-6% Rhodium (type B)
C - Tungsten-5% Rhenium/Tungsten-26% Rhenium (type C)
D - Tungsten-3% Rhenium/Tungsten-25% Rhenium (type D)
E - Chromel/Constantan (type E)
G - Tungsten/Tungsten-26% Rhenium (type G)
I - Nickel-10% Chromium (Tophel II)/Nickel-2.5%
Silicon (Nial II) (note: closely models type K)
J - Iron/Constantan (type J)
K - Chromel/Alumel (type K)
L - Platinel 5355/Platinel 7674 (type L)
Note: Platinel is a trademark of the Engelhard
Industries, Inc.
M - Nickel-18% Molybdenum/Nickel-1% Molybdenum
N - Nicrosil/Nisil (type N)
Nickel-14.2% Chromium/Nickel-4.4% Silicon-0.1%
Magnesium
O - Thermistor
P - Chromel/Gold-0.07% Iron
Q - Platinum-40% Rhodium/Platinum-20% Rhodium
(Land-Jewell)
R - Platinum-13% Rhodium/Platinum (type R)
S - Platinum-10% Rhodium/Platinum (type S)
T - Copper/Constantan (type T)
U - Platinum-20% Rhodium/Platinum-5% Rhodium
V - Platinum-13% Rhodium/Platinum-1% Rhodium
Y - Platinum RTD, 50 Ohms
Z - Platinum RTD, 100 Ohms
0 - Platinum RTD, 200 Ohms
1 - Platinum RTD, 500 Ohms
2 - Nickel RTD, 10 Ohms
5 - Nickel/Iron, 2000 Ohms
6 - Nickel/Iron, 10000 Ohms
7 - Copper RTD, 10 Ohms
8 - Copper RTD, 25 Ohms
9 - Copper RTD, 100 ohms
W & X - Manufacturer specific.
+ If the called out line for the material description is longer
than one character, the next character may be a single letter

--```,``-`-`,,`,,`,`,,`---

426
that indicates the electrical isolation of the tip of the

temperature measuring device or the type of device as follows:
B - Bead (as in thermistors)
M - Metallized Surface Contacts (as in thermistors)
W - Thermocouple, unexposed, ungrounded
X - Thermocouple, exposed, ungrounded
Y - Thermocouple, exposed, grounded to probe
Z - Thermocouple, unexposed, grounded to probe
0 - Reserved - must not be used.
3 - 3-Wire RTD
4 - 4-Wire RTD
All other letters and digits reserved except:
5 - 9 = Manufacturer specific.
The above single character may be followed by, or replaced by, a
string of digits (any length but only digits) that indicate the
"x"'s in the following:
"The temperature coefficient of this RTD is 0.xxxxx ohms/
ohm - deg. C."
Note that the first "x" will always be a zero. That is why a
zero was prohibited in the previous list - it becomes the parsing
key.
+ The line being called out may continue beyond the above with the
a standard material description for the probe material. The
+ If the line being called out continues past the previous material
description, the next character will be the start of a standard
material description for the probe packing material. The
AU = Metal and Alloys

AU - The standard "Unified Numbering System for Metal and Alloys" (ASTM
DS-56) (Current version - Fifth edition - June, 1989)
will start with the 6 character Unified Numbering System (UNS)
number. This number can not be truncated.
+ Immediately following the UNS number, a standard material
description can optionally be appended. Such an appended
description must be self-defining. An example of the application
of this option would be the addition of a class "Y" description
to indicate surface treating of the metal.
The second material description can not be used to describe a

liner, coating, surface treatment, etc. if there is an
appropriate standard part designation in Table 11 . For example,
assume that Table 11 included "pipe" and "pipe liner". The
second material description could not be added to the material
description of the pipe to describe the pipe liner. However, a
second material description could be added to describe surface
treating of the pipe (providing Table 11 did not also include
"pipe surface treating").
The UNS uses very specific notation for metals and alloys and does
not always represent a clean hierarchical structure. Therefore, the
UNS will be extended in the SP-50 clipboards by the following
conventions and definitions:
+ Where there is a hierarchical structure, digits of the name
structures may be substituted with the capital letter "X".
Higher level systems will recognize the "X" as a "wild-card"
that can be considered to be any digit.

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
427
+ In order to provide some generic metal descriptions, the

following symbols are defined using a form of notation that will
be used only for symbols defined by the SP-50 Committee. These
generic descriptions are defined so that material descriptions
can be entered on a clipboard despite the fact that exact UNS
metal definitions are not known. The generic descriptions
defined by SP-50 are:
C1YYYY Generic copper
C230YY Generic red brass
C44YYY Generic naval brass
C5YYYY Phosphor bronze
F1YYYY Generic gray cast iron
F2YYYY Generic malleable cast iron
F3YYYY Generic ductile cast iron
F4YYYY Generic cast iron
G10YYY Generic low-carbon steel
G4YYYY Generic low-alloy steel
J9YYYY Generic cast corrosion-resistant stainless
K00YYY Generic Soft Iron
K0YYYY Generic carbon steel
L13YYY Babbitt
N0YYYY Nickel
N04YYY Monel
N06YYY Inconel
N08020 Alloy 20
N08YYY Incoloy
N10YYY Hastelloy
R05YYY Generic Tantalum
R5YYYY Generic Titanium
R6YYYY Generic Zirconium
SYYYYY Generic stainless steel
S3YYYY Generic wrought austenitic stainless steel
S41YYY Generic wrought martensitic stainless steel
S43YYY Generic wrought ferritic stainless steel
S63YYY Valve steel
T30YYY Tool steel
T90YYY Cast tool steel
Z1YYYY Generic zinc
--```,``-`-`,,`,,`,`,,`---
ZV - Stem and Shaft Packing Materials and Seals

ZV - A description system for all stem and shaft packing materials and
seals.
+ This class shall be used for all stem and shaft sealing materials
except O-Rings.
+ This class shall not be used for any material other than stem or
shaft sealing.
+ The description of a packing system is based on the following
structure of the necessary information:
- four single characters of concise data.
- up to six material identifiers.
+ If a valve is shown as having a bellows seal and a stem packing
assembly, it will be understood that the stem packing assembly
is the secondary seal.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
is as follows:
- The first character of the call-out will indicate the type
of packing box or seal (the line being called out must be at
least one character long):
S - Screwed packing box
B - Plain bolted box, packing follower, packing flange
L - As in B plus lantern ring and lubricator
I - As in L plus isolating valve
F - As in B plus freeze-seal
M - Mechanical Seal

428
P - Two packings with pressurized fluid - call-out for

process packing
Q - Two packings with pressurized fluid - call-out for
clean packing
V - Two packings with vent - call-out for process
packing
W - Two packings with vent - call-out for clean packing
X - Not specified
9&Z - Manufacturer specific.
- If the line being called out is more than one character
long, the second character of the line will be a single
digit that indicates the presence of multiple packings or
multiple types of packing:
0 - One type of packing
1 - Call-out for end wiper rings
2 - Call-out for interior rings
3-7 - Reserved
8&9 - Manufacturer specific.
- If the line being called out is more than two characters
long, the third character of the call-out will be a single
digit that indicates the presence of a corrosion inhibitor/
solid cover.
0 - No inhibitor/no cover
1 - A zinc corrosion inhibitor
2 - Non-zinc corrosion inhibitor
3 - Solid cover
4-5 Reserved.
6 - Manufacturer specific inhibitor - see free format
section of this clipboard.
7 - Manufacturer specific inhibitor - consult
manufacturer.
8&9 - Manufacturer specific inhibitor
Note: a code 8 or 9, combined with the manufacturer's
name, results in a specific material. Code 7 is
an indicator that the user must consult the
manufacturer to determine the material.
- If the line being called out is longer than three
characters, the fourth character of the line will be a
single alpha- numeric character that defines the general
structure of the packing ring.
B - Braid-over-braid (round braid) (cover-on-cover) - the
packing is built up to size by braiding successive
covers, one on another, over a central core. Each
cover is entirely separate from the core and all
other covers.
D - Die-formed - pre-compressed rings supplied to a
controlled density and size in square cross-section.
F - Flexible ribbon - a long, thin ribbon is wrapped
around the stem to produce an endless ring.
I - Interbraid (interlock braid) - every strand passes
entirely through the body of the packing at an angle
of about 45 degrees, making a completely unified
structure.
L - Laminated - slabs formed of plies or sheets cemented
together, from which strips or rings of the required
packing size are cut.
M - Metal foil - metal foil packing rings are formed when
a strip of foil is twisted, rolled, or folded upon
itself, generally with the simultaneous introduction
of grease and graphite.
P - Plastic packing - a formed packing ring containing a
fiber, lubricant, and binder, with optional inclusion
of particles. Note: here, the term "plastic" has
nothing to do with material National/Class "AP".
S - Square braid (plaited braid) - each strand passes
over and under other strands. In general, strands do

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
429
not pass entirely through the packing, and a single

strand is not necessarily linked with all others.
T - Shredded packing
R - Solid ring
V - V-Ring
9&Z - Manufacturer specific.
- The remainder of the call-out consists of a string of
material descriptions. These descriptions must be given in
order but:
+ any of them can use the "ZN" (Null) class.
+ the string can be terminated before any one of the
descriptors including the first.
- If the line being called out is more than 4 characters long,
the fifth character of the call-out will be the start of a
standard material description for the principal component of
the packing. The description will start with its own
- If the line being called out does not terminate after the
first material description, the next character of the line
--```,``-`-`,,`,,`,`,,`---
will be the start of a standard material description for the
treating material/lubricant in the packing. If the third
character of the line is the digit 3 (solid cover), the
material description will identify the cover material. The
description will start with its own MD-Start symbol and end
with its own MD-End symbol.
second material description, the next character of the line
binder in the packing. The description will start with its
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
third material description, the next character of the line

reinforcement component of the packing. The description
will start with its own MD-Start symbol and end with its own
MD-End symbol.
fourth material description, the next character of the line
primary material of the core of the packing. The
fifth material description, the next character of the line
secondary material in the core of the packing. The

ZW - A description system for defining power demand.
+ The Field Bus Standard line call-out for this class will consist
of an alpha character followed by any number of digits.
+ The first character will be an alpha character indicating the
following:
D - the DC power drawn by the field device from its own
power source - in watts.
M - the milliwatts of power drawn from Field Bus
P - the milliwatts of power supplied to Field Bus

430
S - the single phase AC power drawn by the field device

from its own power source - in watts.
T - the three-phase AC power drawn by the field device from
its own power source - in watts.
Z - manufacturer specific.
+ The first character will be followed by digits indicating the
quantity of power.
symbol (not part of the call-out).
AX - Service Pressure Limit

AX - A description system for defining the service pressure limit.
The Field Bus Standard line call-out for this class will consist of
one alpha character followed, optionally, by one integer of any
length. The first character will be a character indicating the
following:
A - atmospheric to 100 inches water column
B - atmospheric to 15 psig
C - atmospheric to 25 psig
D - atmospheric to 125 psig
E - full vacuum to 100 inches water column gauge
F - full vacuum to 15 psig
G - full vacuum to 25 psig
H - full vacuum to 125 psig
--```,``-`-`,,`,,`,`,,`---
I - full vacuum to 150 psig
J - full vacuum to 250 psig
K - full vacuum to 300 psig
L - full vacuum to 400 psig
M - full vacuum to 600 psig
N - full vacuum to 800 psig
O - full vacuum to 900 psig
P - full vacuum to 960 psig
Q - full vacuum to 1500 psig
R - full vacuum to 2000 psig
S - full vacuum to 2500 psig
T - full vacuum to 2900 psig
U - full vacuum to 3000 psig
V - full vacuum to 5000 psig
W - full vacuum to 10000 psig
X - reserved
Y - maximum vacuum follows (in units of inches of Hg.)
Z - maximum pressure follows (in units of psig)
ZY Surface Treating and Hardening, Material Color and Paint Systems

ZY - A description system for surface treating and hardening, material
color, and paint systems.

materials.
The Field Bus Standard line call-out for this class will consist of
two alpha-numeric characters. It can not be truncated. The first
character will be a digit indicating the following:
0 - Alpha letter applies to the material itself (hardening,
coloring constituents, material color)
1 - Alpha letter applies to an anodizing treatment or a
surface layer of metal as in electroplating,
metallizing, sherardizing, etc.
2 - Alpha letter applies to the first paint coat, applied
cold, air dried
3 - Alpha letter applies to the build paint coats, applied

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
431
cold, air dried

4 - Alpha letter applies to the top paint coat, applied
cold, air dried
5 - Alpha letter applies to the first paint coat, applied
hot, air dried (coal tar) or applied cold, baked (all
other paints).
6 - Alpha letter applies to the top paint coat, applied
hot, air dried (coal tar) or applied cold, baked (all
other paints).
7&8 - Reserved
9 - Manufacturer specific
The second character of the call-out will be an alpha-numeric
character that has the following meaning:
A - Anodized (see Note 1)
B - Black color
C - Carburizing surface treatment
D - Clear (no) color
E - Electroplate (see Note 1)
F - Flame hardening surface treatment
G - Galvanized
H - Anti-corrosion impregnant
I - Induction hardening surface treatment
J - Carbon black (pigment for rubber and plastics)
K - Appearance impregnant
M - Metallized (see Note 1)
N - Nitriding surface treatment
P - Plastic (see Note 1)
R - Rubber (see Note 1)
S - Sherardized layer (iron plus zinc)
T - Titanium dioxide (pigment for rubber and plastics)
W - White color
Y - Cyaniding surface treatment
Z - Manufacturer specific
0 - Acrylic paint (water base)
1 - Alkyd paint
2 - Elastomeric polyurethane paint
3 - Epoxy paint
4 - Polyurethane paint
5 - Vinyl copolymers paint
6 - Inorganic zinc silicate paint
7 - Zinc silicone paint
8 - Coal tar (see Note 1)
9 - Asphalt
All other characters - reserved
Note 1:
A description using this second character may optionally
follow the second character with a standard material
description of the coating material (or, for coal tar, the
plastic portion of the coating). The description will start
with its own MD-Start symbol and end with its own MD-End
symbol.

?9 & ?Z - Material Descriptions Defined by the Manufacturer

?9&?Z - A set of material descriptions defined by the manufacturer where
"?" is the nationality of the manufacturer or "Z".
A manufacturer may define a material description for use in the

clipboard provided it's definition is totally consistent with the
other material descriptions defined above. It is necessary that the
total material description (the call-out):

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
432
- the nationality code can be the nationality of the

manufacturer (if desired and if an appropriate code is
defined) or the letter "Z".
- retain the class code "Z" or "9".
- not contain an ASCII(30) nor an ASCII(31) within it.

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
433
TABLE 1
Table 1 Industrial ceramics, Cermets, and Powder

Metallurgy
Definition of Terms for Material National/Class "ZC"
INDUSTRIAL CERAMICS, CERMETS, AND POWDER METALLURGY
Several important, general terms used to define the materials in this class
will be defined. Those definitions will be followed by a larger set of
definitions of more specific terms.
GENERAL DEFINITIONS:
Industrial ceramics - industrial ceramics may be considered to be those

materials and products, except for the metals, that are chemically
inorganic and that are usually rendered serviceable through high
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
temperature processing in manufacture or in preparation of the

materials used.
The usual classification of industrial ceramics includes:

- structural clay products
- whitewares
- porcelain enamels
- glass
- refractories
- abrasives
- cements, lime, and gypsum
(above extracted from "Industrial Ceramics", Encyclopaedia
Britannica.)
The SP-50 Field Bus Standard will not be concerned with the first
and last classes. Note that the class "whitewares" includes
chemical and electrical porcelain and products with good mechanical
and thermal properties.
Metal - any of a class of substances distinguished by their high

conductivity for electricity and heat (their electrical
conductivity decreasing with increasing temperature), by their high
reflectivity for light (their metallic luster), and by their
formation of basic oxides and hydroxides.
Ceramic article - an article having a glazed or unglazed body of crystalline

or partly crystalline structure, or of glass, which body is
produced from essentially inorganic, non-metallic substances and
either is formed from a molten mass which solidifies on cooling, or
is formed and simultaneously or subsequently matured by the action
of the heat (ASTM C 242-90).
The join of "Porcelain", "Whiteware", and "Material used directly -

Glass" in Field Bus.
Porcelain article - a glazed or unglazed vitreous ceramic whiteware made by

a process in which a ceramic body and glaze are matured together in
the same firing operation and used for technical purposes. This
term designates such products as electrical, chemical, mechanical,
structural, and thermal wares when they are vitreous (ASTM C
242-90).
Note: some references define a class of whiteware called
"stoneware" that is differentiated from porcelain
by the modulus of elasticity. If the modulus is less
than 10**7 lb/in*2, it is called stoneware. This
work will ignore the term stoneware.
Porcelain enamel - a substantially vitreous or glassy, inorganic coating

bonded to metal by fusion at a temperature above 800 deg. F (425
SP-50 User Layer Technical Report Array of Basic Parameters

--```,``-`-`,,`,,`,`,,`---

434
deg. C approximate) (ASTM C 286-83a).
Vitreous (vitrified) - that degree of vitrification evidenced by low water

absorption. The term vitreous generally signifies less than 0.5%
absorption, except for floor and wall tile and low-voltage
electrical porcelain which are considered vitreous up to 3.0% water
absorption (ASTM C 242-90).
Glass - glass is an inorganic product of fusion which has cooled to a rigid

condition without crystallizing.
Glass-ceramics - glass-ceramics are a family of crystalline materials made

from non-crystalline glass. Glass-ceramics is made by adding
nucleating agents to the raw materials for glass. The material is
melted and formed into an article by conventional glassmaking
techniques. It is cooled to temperatures which precipitate the
nucleating agents, and then is re-heated to grow crystals around
the nuclei. The resultant product is a crystalline ceramic
substantially the shape and size of the original glass article, but
characterized by greater strength and hardness, with greater
abrasion resistance and improved electrical and thermal properties.
Refractory - a refractory is an inorganic, non-metallic material that will

retain its chemical and physical identity and its mechanical
function at elevated temperatures.
Abrasive - a ceramic material suitable for use in products, such as grinding

wheels and sandpaper, intended to be used to abrade the surface of
--```,``-`-`,,`,,`,`,,`---
an article.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Note: In the SP-50 clipboard, materials that are prepared by the

cermet process will specifically NOT be referred to as
abrasives.
Cermet - a composite material or article comprised of a ceramic and a metal

or metal alloy, interdistributed in any of various geometrical
forms but intimately bonded together (ASTM C 1145-89).
In the SP-50 clipboard, a "part" definition using the cermet

notation will imply an actual cermet part. When the cermet
notation is used as the material of a coating or as the second
material description for a metal in the National/Class "AU", it
will imply an electric arc or sputtered coating. Note that use of
this term in SP-50 is restricted to those cases in which at least
one of the powder components, not considering a minor lubricant, is
a non-metal (see "powder metallurgy"). Also note that cemented
carbides, nitrides, etc. are products of a cermet operation but
some of them are listed as specific National/Class "AC" materials
in this standard.
DETAIL DEFINITIONS:
Alloy - a substance composed of two or more metals fused together (Webster).

Alumina Porcelain - any vitreous ceramic whiteware in which alumina
(Al2O3) is an essential crystalline phase (ASTM C 242-90).
Alumina Whiteware - any ceramic whiteware in which alumina (Al2O3) is an
essential crystalline phase (ASTM C 242-90).
Aluminum enamel - a porcelain enamel specifically designed for application
to aluminum (ASTM C 286-83a).
Base metal - the metal to which porcelain enamel is applied (ASTM C 286-83a)
Beryl - the commercial source of beryllium - Be3Al2Si6O18 - harder
than quartz - commonly pale green but it may be deep green, blue,
yellow, brown, colorless, or pink. Special names are given to the
colored gem varieties. Emerald is deep green, colored by a small
amount of chromium; aquamarine is pale blue-green; morganite is
pink, probably colored by cesium; golden beryl is yellow
(Encyclopaedia Britannica).

435
Beryllium Oxide - (BeO) - (beryllia) - an inorganic material of

exceptionally high thermal conductivity which is toxic in the
powder form (ASTM C 242-90).
Bonded refractory/bonded abrasive - a refractory or abrasive article whose
macro form is dependent on the structural contribution of a
"bonding agent" but whose micro properties are derived from the
named material. For example, a grinding wheel's shape and
structural strength is due to the bonding agent but its grinding
ability is due to the abrasive material named.
Carborundum - silicon carbide (SiC) - has almost the hardness of diamond
Cast iron enamel - a porcelain enamel specifically designed for application
to cast iron (ASTM C 286-83a).
Note: the Field Bus Standard will only consider the more general
class "iron enamel".
Ceramic coating - an inorganic, essentially non-metallic coating, on metal
(ASTM C 286-83a).
Ceramic-metal coating - (cermet coating) - a mixture of one or more ceramic
materials in combination with a metallic phase applied to a
metallic substrate which may or may not require heat treatment
prior to service. This term may also be used for coatings applied
to nonmetallic substrates, for example, graphite (ASTM C 286-83a).
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
See "Cermet".
Ceramic Whiteware - a fired ware consisting of a glazed or unglazed ceramic
body which is commonly white and of fine texture. This term
designates such product classifications as tile, chine, porcelain,
semivitrous ware and earthenware (ASTM C 242-90). Called
"whiteware" in Field Bus.
Clay - a natural mineral aggregate, consisting essentially of hydrous
aluminum silicates; it is plastic when sufficiently wetted, regid
when dried en masse, and vitrified when fired to a sufficiently
high temperature (ASTM C 242-90).
Copper enamel - a porcelain enamel specifically designed for application to
copper (ASTM C 286-83a).
Cordierite Porcelain - any vitreous ceramic whiteware in which cordierite
(2MgO.2Al2O3.5SiO2) is the essential crystalline phase (ASTM
C 242-90).
Cordierite Whiteware - any ceramic whiteware in which cordierite
--```,``-`-`,,`,,`,`,,`---
(2MgO.2Al2O3.5SiO2) is the essential crystalline phase (ASTM
C 242-90).
Corundum - a naturally occurring hexagonal mineral of the composition
Al2O3 which can also be prepared synthetically to high purity.
It is noted for its hardness and refractoriness. It forms the gem
varieties ruby and sapphire with appropriate impurities (chromium
produces the read of ruby, iron and titanium produce the blue of
sapphire (Encyclopaedia Britannica)). It may contain associated
minerals such as diaspore or various silicates, or both (ASTM C
242-90).
Decarburized enameling steel - a special type of steel sheet of extremely
low carbon content, suitable for porcelain enamel cover coat
application direct to the metal (UNS K00100) (ASTM C 286-83a).
Dry process - the method of preparation of a ceramic body wherein the
constituents are blended dry, following which liquid may be added
as required for subsequent processing (ASTM C 242-90).
Dry process enameling - a procelain enameling process in which the metal
article is heated to a temperature above the maturing temperature
of the coating (usually 1600 to 1750 deg. F, (approximately 870 to
955 deg. C)), the coating materials applied to the hot metal as a
dry powder, and fired (ASTM C 286-83a).
Fluorite (fluorspar) (CaF2) - a common mineral and is the principal
fluorine mineral. It has a low melting point and is used in
metallurgy as a flux. Most varieties fluoresce strongly under
ultraviolet light (Encyclopaedia Britannica).
Forsterite Porcelain - any vitreous ceramic whiteware in which forsterite
(2MgO.SiO2) is the essential crystalline phase (ASTM C 242-90).
Forsterite Whiteware - any ceramic whiteware in which forsterite
(2MgO.SiO2) is the essential crystalline phase (ASTM C 242-90).

436
Fusion - the process of melting; usually the result of interaction of two or

more materials (ASTM C 242-90).
Fusion point - the temperature or range of temperatures at which melting or
softening, as a result of partial melting, of a composition, will
occur (ASTM C 1145-89).
Glass-coated steel, glass-lined steel, glassed steel - designations
generally applied to a class of porcelain enamels that have high
resistance to chemical attack at elevated temperatures and
pressures (ASTM C 286-83a).
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
In Field Bus, "Glass or Glass-ceramic coated or lined" (general
type "G" in National/Class "ZC") will refer to an article with a
coating material that is not crystallized (glass) or is
specifically a "glass-ceramic" material. "Porcelain enamel"
(general types "D", "E", and "F" in National/Class "ZC") will refer
to an article with a coating material that is crystallized and not
a glass-ceramic. See definition of "Glass-ceramic)
Glaze - a ceramic coating matured to the glassy state on a formed ceramic
article, or the material or mixture from which the coating is made
(ASTM C 242-90).
Ground coat - (1) a porcelain enamel applied directly to the base metal to
function as an intermediate layer between the metal and the cover
coat.
(2) - on sheet steel, a porcelain enamel coating containing
adherence-promoting agents which may be used either as an
intermediate layer between the metal and the cover coat or as a
single coat over the base metal. (ASTM C 286-83a)
--```,``-`-`,,`,,`,`,,`---
Impervious - that degree of vitrification evidenced visually by complete
resistance to dye penetration. The term impervious generally
signifies zero absorption, except for floor and wall tile which are
considered "impervious" up to 0.5% water absorption (ASTM C 242-90)
Magnesia - magnesium oxide (MgO), calcined or hard burned as periclase.
Loosely applied also to the hydrate Mg(OH)2. Made synthetically
from seawater or brine, or (impure) from magnesite. Used in basic
refractories, as a filler in rubber, and elsewhere (ASTM C 242-90).
Maturing temperature - the temperature at which porcelain enamel must be
held for a selected time to achieve the desired properties (ASTM C
286-83a).
Mullite Porcelain - any vitreous ceramic whiteware in which mullite
(3Al2O3.2SiO2) is the essential crystalline phase (ASTM C
242-90). One uncommon source mineral, dumortierite, is especially
desirable for spark plugs and laboratory ware. Other minerals that
convert to mullite when heated are topaz and kyanite (Encyclopaedia
Britannica).
Mullite Whiteware - any ceramic whiteware in which mullite
(3Al2O3.2SiO2) is the essential crystalline phase (ASTM C 242-90).
Powder Metallurgy - the fabrication of useful items from a metal powder or a
mixture of metal powders, followed by sintering (Encyclopaedia
Britannica).
Note that use of this term in SP-50 is restricted to those cases in

which ALL of the powder components, not considering a minor
lubricant, are metals (see "Cermet"). Also note that cemented
carbides, nitrides, etc. are products of a cermet operation, not
products of powder metallurgy by these definitions.
Refractory composite coating - a combination of heat-resistant ceramic
materials applied to a metallic substrate which may or may not
require heat treatment prior to service. This term may also be
used for coatings applied to nonmetallic substrates, for example,
graphite (ASTM C 286-83a).
In Field Bus, this coating will be shown as simply a "ceramic

coating" (general type "V" in National/Class "ZC") or a "porcelain
enamel" (general type "D", "E", or "F" in National/Class "ZC")
depending on the degree of vitrification.
Rutile - the most abundant of the three native forms of titanium dioxide,
the others being anatase and brookite. Ordinary rutile is red or

437
brown (Encyclopaedia Britannica).

Silica - (SiO2) - the common oxide of silicon usually found naturally as
quartz or in complex combination with other elements as silicates
(ASTM C 242-90).
Sinter - 1) a ceramic material or mixture fired to less than complete
fusion, resulting in a coherent mass, or the process involved (ASTM
C 242-90).
In Field Bus, materials covered by this definition are included in
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
the general types of ceramics and porcelains. 2) Solid state
powder metallurgy sintering: the sintering temperature is such
that there is no molten metal present during the major portion of
the sintering period (Encyclopaedia Britannica).
3) Liquid phase powder metallurgy sintering: carried out with a

mixture of low- and high-melting-point metal powders. The
sintering temperature is above the melting point of the lower
melting compound (Encyclopaedia Britannica).
In Field Bus, materials covered by definitions (2) and (3) are

included in the general type "Powder metallurgy" (general type "M"
in National/Class "ZC") and are not distinguished from solid state
powder metallurgy.
Soapstone - see talc
Steatite Porcelain - any vitreous ceramic whiteware in which magnesium
metasilicate (MgO.SiO2) is the essential crystalline phase (ASTM
C 242-90).
Steatite talc - massive talc or the pulverized product thereof having the
general formula 3MgO-4SiO2-H2O (ASTM C 242-90).
The Field Bus standard will consider it Talc.
Steatite Whiteware - any ceramic whiteware in which magnesium metasilicate
(MgO.SiO2) is the essential crystalline phase (ASTM C 242-90)
Talc - Talc is the mineral name for the familiar hydrous magnesium silicate.
Talc is distinguished from almost all other minerals by its
extreme softness. The hardness of 1 imparts a soapy or greasy feel
which accounts for the name soapstone or steatite for the compact
aggregates of talc. (Encyclopaedia Britannica).
- a phyllosilicate mineral having the general formula

3MgO-4SiO2-H2O. Noted for its extreme softness, low thermal
and electrical conductivity, and fire resistance. (ASTM C 242-90).
Tantalum Carbide - (TaC) - has the highest melting point of any known
substance (4150 deg. C) (Encyclopaedia Britannica).
Titania Porcelain - any vitreous ceramic whiteware in which titania (TiO2)
is the essential crystalline phase (ASTM C 242-90)
Titania Whiteware - any ceramic whiteware in which titania (TiO2) is the
essential crystalline phase (ASTM C 242-90).
Tungsten Carbide - (WC) - refractory
Wet process - the method of preparation of a ceramic body wherein the
constituents are blended in a sufficient liquid to produce a fluid
suspension for use as such or for subsequent processing (ASTM C
242-90).
Materials made by this process are not differentiated from dry

process ceramic materials in Field Bus.
Wet process enameling - a method of porcelain enameling in which slip is
applied to a metal article at ambient temperature, dried and fired
(ASTM C 286-83a).
Whiteware - see ceramic whiteware
Zircon Porcelain - any vitreous ceramic whiteware in which zircon
(ZrO2.SiO2) is the essential crystalline phase. (ASTM C 242-90).
Zircon Whiteware - any ceramic whiteware in which zircon (ZrO2.SiO2) is
the essential crystalline phase (ASTM C 242-90).

--```,``-`-`,,`,,`,`,,`---

438
TABLE 2
Table 2 Miscellaneous Material Descriptions

MISCELLANEOUS MATERIAL DESCRIPTIONS
Definition of Terms for Material National/Class "ZM"
Several important terms used to define some of the materials in this class
will be defined.
GENERAL DEFINITION:
Asbestos - a general term applied to any mineral that can be easily

separated into flexible fibers and that can be spun or felted to
make noncombustible fabrics. Of the several types of asbestos,
chrysotile, the fibrous variety of serpentine, is the most
important; the others all belong to the amphibole group of minerals
of which anthophyllite, amosite, crocidolite, and
tremolite-actinolite are the principal varieties (Encyclopaedia
Britannica)
DETAIL DEFINITIONS:
Actinolite asbestos (green asbestos) - see tremolite-actinolite asbestos.

Amorphous - not crystallized (Webster)
Amosite asbestos - an iron-rich anthophyllite, is variously colored and may
be brown, gray, or yellowish-green. More brittle than chrysotile
but more acid resistant. World's supply from South Africa
--```,``-`-`,,`,,`,`,,`---
Carbon - essentially pure amorphous elemental carbon; includes coke,
lampblack, carbon black, gas black, gas carbon, retort carbon,
soot, and charcoal (Encyclopaedia Britannica).
Chrysotile asbestos (Canadian asbestos) -fibrous form of the mineral
serpentine (Mg3Si2O5(OH)4. The source of the bulk of
commercial asbestos. Individual fibers are white, but the color of
the aggregate in the veins varies from green to greeenish-yellow to
amber (Encyclopaedia Britannica).
Crocidolite Asbestos (blue African) - (Na2(Fe(2+)3Fe(3+)2)-
Si8O22(OH)2). Dull blue Higher tensile strength than
chrysotile but is less resistant to heat: fuses to a black glass
at a relatively low temperature. Most of the world's supply from
South Africa (Encyclopaedia Britannica).
Diamond - a mineral consisting of the element carbon, crystallizing in the
cubic system (Encyclopaedia Britannica).
Graphite - a mineral consisting of the element carbon, crystallizing in the
hexagonal system. Graphite is manufactured from petroleum coke.
Tremolite-actinolite asbestos - the type of asbestos referred to under the
names "amphibole asbestos", "hornblende asbestos", or merely
"asbestos". The chemical composition of tremolite is
(Ca2Mg5Si8O22(OH)2). Iron may substitute in part for the
magnesium, and when it reaches 2%, the mineral is called
actinolite. Pure tremolite asbestos is white, actinolite is green

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
439
TABLE 3
Table 3 Surface Treating and Hardening, Material

Color, and Paint Systems
Definition of Terms for Material National/Class "ZY"
SURFACE TREATING AND HARDENING, MATERIAL COLOR, AND PAINT SYSTEMS
Several important terms used to define the materials in this class will be
defined.
Anodized - a metal surface on which a chemical coating has been produced by

making it the anode in an electrolytic bath.
In Field Bus, the word "electroplate" will be used if the coating

formed by the electric current is a metal. See the definition of
"Anodized aluminum".
Anodized aluminum - an aluminum article that has a protective coating of
aluminum oxide produced by anodic oxidation of the base aluminum in
certain electrolytes such as dilute sulfuric acid or chromic acids.
These coatings are adsorbent and may be impregnated with dyes or
mineral pigments to produce pleasing finishes, or with salts of
chromic acid to improve their protection against corrosion
In Field Bus, the base metal composition can be defined by the

metal description. The term "anodized" would then indicate the
coating (see definition of anodized above). The type of impregnant
can then be defined by the subsequent material description.
Carburizing - A process for the surface hardening of steel. The low-carbon
steel acticle is heated to about 900 deg. C in a carburizing
atmosphere, usually a gas mixture of carbon monoxide and carbon
dioxide. The product is quenched to harden the "case"
Cyaniding - A process for the surface hardening of steel. The steel article
is heated to about 1600 deg. F and immersed into a liquid cyanide
salt [usually potassium cyamide (KCN)]. (Encyclopaedia
Britannica).
Electric Arc - This term is only recognized as a method of applying a
surface coating of a cermet. See the definitions of "Metallized"
below and "Cermet" in Table 1
Electroplated - an article that has a coating of metal produced through the
action of an electric current flowing in a liquid bath.
Galvanized - an article that has a surface coating of zinc which was applied
to a base metal by dipping the article in a bath of molten zinc.
In Field Bus, "Galvanized" will imply hot-dipped galvanizing.
--```,``-`-`,,`,,`,`,,`---
Other terms defined here are used for a zinc coating applied using
other methods.
Induction Hardening - A process for the surface hardening of steel. The
surface of the article is rapidly heated to above the critical
temperature range by means of a high frequency induced current and,
after a period varying from a second to a few minutes, the article
is quenched. (Encyclopaedia Britannica).
Metal Sprayed - see "Metallized", the term used by Field Bus.
Metallic Sprayed - see "Metallized", the term used by Field Bus.
Metallized - an article that has a surface coating of overlapping scales of
a metal applied as a fine spray or cloud of metallic globules.
In Field Bus, the methods of generating the spray or cloud and the
method of propelling the globules to the article are not specified.
Nitriding - A process for the surface hardening of steel. The special alloy
steel acticle is heated in contact with ammonia at temperatures
below the transformation range for steels, usually between 950 deg.
F and 1050 deg. F., for periods of from 5 to 100 hours.
Sherardized - a steel article that has a protective coating of intermetallic

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
440
compounds of iron and zinc formed by heating the article in a

sealed and slowly rolling container and in the presence of finely
divided zinc at temperatures below its melting point (Encyclopaedia
Britannica).
Sputtered - This term is only recognized as a method of applying a surface
coating of a cermet. See the definitions of "Metallized" above
and "Cermet" in Table 1
--```,``-`-`,,`,,`,`,,`---
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

441
Array Of Basic Parameters

The previous papers in the "Structure" section of this Technical Report have
defined a number of parameters that will be accessible over Field Bus. Some of
these parameters are required and some are optional. This paper will outline the
arrangement of the parameter numbers, collect together the parameters that have
been defined for physical and logical nodes, and assign them individual parameter
numbers. It will define and assign parameter numbers to the parameters that
occur in all Standard Function Blocks. It will define parameter numbers for some
parameters that are simply assigned names available for use by extensions.
A separate paper, "Array of Standard Block Parameters" will define the

parameters for the individual function blocks.

BACKGROUND
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
SPECIAL DEFINITIONS
FUNDAMENTAL DESIGN BASIS
PARAMETER RANGE DEFINITIONS
Virtual Ranges
Protocol Selectors
Mode Restrictions
Secondary Ranges
DEFINED GROUPS
EXPLANATION OF Table 1
HELPFUL READER GUIDE
Table 1 - Parameter List - QUATRO-PRO Presentation (Guide)
- simplified text version.
- else see paper version.
BACKGROUND:
All parameters in the data base of a field device will appear to be accessed
over Field Bus using a "TAG.PARAMETER" format where "PARAMETER" is a 16 bit
unsigned integer. This Technical Report defines certain ranges of the parameter
numbers so that the lower layers of the Field Bus protocol (see the paper
"Application Support Interface"), the User Layer's write handling services, and
the Data Base Write Service (DBWS) (see the DBWS paper) can determine the
required handling of the parameters simply by the range of the parameter number.
Within each of the defined ranges, this Technical Report defines the parameters
needed by the Standard nodes and function blocks, leaving room in each range for
extensions.
--```,``-`-`,,`,,`,`,,`---
There are basically six absolute constraints on the design undertaken by this
paper. These constraints are given in the papers of the "Structure" section of
this Report. They are:
1) the Application Layer Interface will use the three high order bits of
the 16 bit parameter number field to define access restrictions for
each parameter. Those bits must be defined for each parameter (see
the paper "Application Support Services Interface", page 16)
2) Because the high order 3 bits are not transmitted by the Field Bus,
each parameter must have a parameter number that is unique within
the node or block and whose uniqueness is in the low 13 bits.
3) since the parameters for a physical node, a logical node, and a
function block collapse together if there is only one block in the
logical node and only one logical node in the physical node, the
parameters within the resulting collapsed entity must retain their
uniqueness (see the paper "Data Owner Structure - Logical Nodes",
page 2).
4) an agent that is to select an individual bit from a parameter's value
only has room in its configuration for the low order 10 bits of the
parameter's number; the high 6 bits are "virtual" and are defined to

442
be reset. Therefore, agents can only address individual bits in

parameters assigned one of the first 1024 parameter numbers (see the
paper "Agents", page 16).
5) all parameters that have status information must have four assigned
parameter numbers, the numbers have to be consecutive, and the first
number must have its two low order bits reset (see the paper
"Function Block Structure", page 9).
6) all parameters that are "auto-format" variables (see the paper "Human
Interface Considerations", page 11) must have two assigned parameter
numbers. One number will refer to the whole variable and the other
will refer to only the data portion.
The three access restriction definitions that have to be defined for each
parameter are:
1) can this parameter be directly/cyclically read or does it require
that reading be done via. a read handler?
2) can this parameter be directly written or does it require that
writing be done via. a write handler?
3) is this parameter read-only?
It is desirable to convey certain information about a parameter in its

parameter number to simplify the User Layer's write handler and the DBWS.
Specifically, the following information will be indicated by the parameter number
range:
1) does the User Layer logic engine have to be stopped in order to write
this parameter?
2) is this parameter "under" a data base revision number?
3) is the parameter an "auto-format" parameter? If so, is it associated
with the Field Device's hardware or with the process application?
4) is the parameter associated with a status parameter?
5) is there a special DBWS rule for this variable?
6) for logical node variables:
a) is the write accessibility of this parameter a function of
--```,``-`-`,,`,,`,`,,`---
its agent's type?
7) for function block parameters:
a) is the write accessibility of this parameter a function of
its agent's type?
b) does the function block have to be in O/S (actual) mode
before the parameter can be changed?
c) does the function block have to be in O/S or Man requested
mode with LO mode not set in the actual mode before the
parameter can be changed?
d) does the function block have to be in a mode of higher
priority than Auto before the parameter can be changed?
e) does the function block have to be in a mode of higher
priority than Cas before the parameter can be changed?
All of these attributes of a parameter will be described by the individual

number ranges that are established for parameter numbers.
One should note that there are only 5 Standard logical node parameters, and
no Standard physical node parameters, that have status bytes.
SPECIAL DEFINITIONS:
Throughout this entire Technical Report, parameters have been given alpha-
numeric names. These names are intended to make the Technical Report easier to
understand compared to using parameter numbers. An actual implementation of this
Standard will only be concerned with the parameter number that is assigned to a
parameter and the defined meaning of that parameter. Its visible name is freely
determined by the higher level control system or by the human interface. The
implemented visible name will usually be in the language used at the User's site.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
443
Certain information in the data base of the field device will be entered by
the user, will be necessary for the correct operation of the device, and will be
changed infrequently. This data is called "static" data. The User Layer design
supports an operation in which a higher level device on Field Bus maintains a
copy of this data and can write it to the field device if that device should
loose its data or be replaced. In order to have anup-to-date copy of the data,
the higher level device must monitor the field devices for changes in the data
base. Field Bus supports this by providing "static data base revision numbers".
A single number would be associated with a portion of the data base in a field
device. Any time a change is made to that data set in the field device, the
revision number is incremented and an alert report is sent. The DBWS defines a
special procedure for handling these values. If the low order bit of the
revision number is set, the data base covered by the revision number is currently
being modified. If the revision number is not zero, the DBWS will require that
the number be incremented by itself rather than written by any other Field Bus
device. When the changes are completed, it will be incremented by a value that
indicates the total number of data changes that occurred since the previous
value.
There will be a static data base revision number in each tagged object (TO)
that covers all "static" data except the auto-format variables; their names are
PN_SDBRN, LN_SDBRN, and FB_SDBRN across the three types of tagged objects.
There will be a second data base revision number in each TO that covers all
of the auto-format variables in that TO except for auto-format variables
associated with hardware in the physical node. Their names will be PN_AFRN,
LN_AFRN, and FB_AFRN, again across the three types of TO's. The appropriate one
of these three parameters will be required if there are any Auto-format variables
in the individual TO other than ones associated with hardware. (Note that the
auto-format variables associated with the hardware in the physical node are
called I/O_AF and I/O_Type_AF.) Individual ones of these variables are also
labeled with a function block parameter and can be addressed from the associated
block. These variables, no matter how addressed, are NOT under the revision
numbers.
The requested mode and FAIL-SAFE will not be under a static data base
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
revision number but a change in either of them will cause an alert report
(function block or logical node alert, respectively) just as if it were. By
monitoring the alert reports and the revision numbers, a higher level device can
ensure that it has an up-to-date copy of all of the static data plus the
requested mode without excessive communication on the Field Bus.
Immediately above, and throughout this paper, parameters are labeled as being
stored in a specific type of memory. These references are used as convenient
labels but are not intended to require any particular type of implementation in
actual Field Bus devices. The only meaning of the "types" of memory is the
following:
Static specifically requires two separate but concurrent concepts.
First, the appropriate static data base revision number will
be incremented and an alert reported if the parameter is
changed (or simply an alert in the case of the two specified
parameters). Second, if the field device implements the
restart timers (see the paper "Field Device Start and
Restart", page 2) there must be some way to hold this
parameter through the stopped condition and to confirm its
validity upon restart.
EEPROM describes a parameter whose value can be written by the User

and is retained across a power outage of unlimited length.
Included in this category are the hardware calibration values
and the physical node tag name. These parameters are
intended to be written into the Field Device in a maintenance
shop environment (the calibration data) or before connection
to the Field Bus (tag name). These parameters may be under a
static data base revision number (i.e., the tag name), or
they may not (i.e., the calibration data).

--```,``-`-`,,`,,`,`,,`---

444
ROM describes a parameter whose value could be permanently fixed

at manufacture. If not permanently fixed, the value might
be calculated by the Field Device any time it is operating.
However, it is a value that is NOT under the static data base
revision number and does NOT have to be externally set in
in order to operate the device.
Physical refers to a parameter that functions as if its value is

directly reflecting a hardware I/O value. It specifically is
NOT under the static data base revision number and does NOT
have to be externally set in order to operate the device.
Dynamic essentially all other parameters. Specifically, a parameter

that is NOT under the static data base revision number.
FUNDAMENTAL DESIGN BASIS:

The Application Layer Interface Services have been defined on the basis of
using the high order three bits of the parameter name for access definitions.
Those three bits would NOT be transmitted in the actual parameter number in
messages.
The "remaining" 13 bits represent the "actual" parameter number. They must
provide a unique identification of a parameter since the high-order 3 bits will
not be transmitted as part of the TAG.PARAMETER variable identification.
The "remaining" 13 bits have been divided into essentially five sets. Bits 12
--```,``-`-`,,`,,`,`,,`---
and 11 are used to define four different parameter number decoding protocols.
Bits 10 and 9 are used to define the mode status required for writing for two of
the four protocols.
In the two protocols that use the mode restriction definitions in bits 10 and
9, bits 8 and 6 are sometimes used to add bit-specific definitions to the
parameters. Bits 1 and 0 are sometimes used to select members of a parameter
set. The remaining bits are used to identify specific instances of parameters.
This overall method of assigning parameter numbers is relatively wasteful of

potential parameter numbers in the 64k range possible. However, it makes the
Application Layer Interface and the DBWS much more efficient.
PARAMETER RANGE DEFINITIONS:

The parameter numbers assigned to a data base variable can be though of as
being a 16 bit integer where the high order three bits are virtual. They are
only explicit in the data owner and then only in an array of descriptions that is
passed to the owner's Application Layer. They are also needed by higher level
systems to check configuration, design parameter lists for data base backup, etc.
The low order 13 bits must uniquely identify a parameter since the high order 3
bits are not transmitted in a TAG.PARAMETER label.
In a TAG.PARAMETER label, the high three bits of the parameter field will be
reset. When configuration data that includes a field for a PARAMETER is written
over the Field Bus to Standard field devices, the information in bits 15-13 will
never be included. If the bits exist in the field, they will be reset.
In this paper, the parameter numbers will be presented as 16 bit unsigned

integers.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
445
Virtual Ranges:
The separate (virtual) three bits of information essentially define
eight primary ranges of parameters consisting of all combinations of
the following:
1) any parameter with bit 15 set can not be directly/cyclically
read.
2) any parameter with bit 14 set can not be directly written.
3) any parameter with bit 13 set is read-only.
There is an important observation that can be made concerning these

ranges: two of the eight ranges formed by the combination of bits are
void since restrictions 2 plus 3 overlap.
Note that auto-format variables are always defined as writeable

even though they may define themselves, in their header, as read only
(see the paper "Human Interface Considerations", Attachment 1, page 3).
There is a special situation for the "direct write" restriction on

the values of Input words and logical node variables. They will be
shown, in this paper, as "directly writeable". However, if their agent
is not of the type "writeable" or "required writeable", then the User
--```,``-`-`,,`,,`,`,,`---
Layer of the data owner will change bit 14 to set. At the same time,
this paper will define the rules and the corresponding parameter bits 13
- 0 for indirect, restricted writing.
The three virtual bits have direct and simple configuration rules
in Standard function blocks:
- No function block agent can be configured with a pointer to a
parameter that can not be directly/cyclically read.
- No function block output agent can be configured with a pointer
to a parameter that is read-only OR can not be directly written.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Protocol Selectors:
Bit 12 will be used to disable the mode restriction definitions for
bits 10 and 9 that will be defined below. If Bit 12 is reset, bits 10
and 9 define the mode required before the block can be written. If Bit
12 is set, bits 10 and 9 are simply part of the consecutive number set
formed by the lower order bits.
Bit 11 will be used as a secondary selector within the protocol

selector. When bit 12 is reset, there is a highly defined set of rules
defined by the lower order bits (which may, in turn, disable mode
restrictions): bit 11 is used in those rules. When bit 12 is set, bit
11 will indicate if the parameter is under a data base revision number
(bit 11 = set = under a revision number). It is important to note that
an agent can be configured to directly write a parameter that has bit 11
set in its parameter number. If that is done, the data base revision
number will NOT be incremented when those direct writes are performed
by that agent.
The Application Layer design requires that the special case of all
bits set in the full parameter number be reserved. That special number
falls under the case of bits 12 and 11 both set. Therefore, the unique
parameter number with bits 12-0 all set must not be assigned to any
parameter.
It is sometimes necessary for the DBWS to supply special services

for writes. Several of those services have been identified as "complex
writes" in which the write to one parameter is dependent on the value of
a specified parameter. A special range of parameter numbers are
reserved for "actor" parameter numbers that will trigger these services:
the range where bits 15 - 6 = 1101000000B. This leaves 64 values for

446
this use by DBWS (see Attachment 1, "Complex Write Services" to the

paper "Data Base Write Service").
There are 2 last groups that will be set aside in the "Bit 12 =
--```,``-`-`,,`,,`,`,,`---
set" range for the convenience of the DBWS:

- All parameters with bits 15-6 = xx01x00001 (where x = "don't
care") will be reserved for the 2 * 64 parameters that have
parameter-specific rules to limit writing but the rules are
NOT mode specific. Specifically, in the xx01000001 range,
the low 16 values will be used for data base revision
numbers.
- All parameters with bits 15-6 = xx01x00010 (where x = "don't

care") will be reserved for the 2 * 64 parameters that:
+ are floating point numbers
AND
+ can not be written with negative values.
Note particularly that bits 12 and 11 must be reset in any

parameter that is to be accessed bit-wise by an agent.
Mode Restrictions:
When bit 12 is reset, the mode restrictions defined by bits 10 and
9 will apply. Note particularly that the mode restrictions plus the
states of bits 14 and 13 are taken to IMPLY whether the parameter is
under a data base revision number.
SELECT CASE (Bits 10 & 9)

CASE 00B
There is no mode restriction on the writing of this
parameter OR it is not writeable at all.
IF the parameter is indirectly but not directly writeable,

then
The parameter is under a data base revision number.
ELSE
The parameter is not under a data base revision number.
CASE 01B
There is a special restriction on the writing of this
parameter (the lower order bits will define exactly which
special restriction).
The parameter is NOT under a data base revision number

unless the lower lever bits specifically define it
to be.
CASE 10B
This parameter can only be written IF
This parameter is in a function block AND
Its LO actual mode bit is NOT set AND
its requested mode is higher in priority than Auto.
OR
This parameter is in a logical node AND
All function blocks in the logical node have:
Their LO actual mode bit reset AND
IF the algorithm of the block does not
support Man mode, then
The requested mode is higher priority
than Cas
ELSE
than Auto.
OR
This parameter is in a physical node AND
None of the outputs associated with the parameter to

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
447
be written have a hardware LO keylock set AND

Each function block that has a hardware pointer
pointing to the hardware associated with the
parameter to be written meets the following
conditions:
The block does not have LO set in the actual
mode AND
IF the algorithm of the block does not
support Man mode, then
than Cas
ELSE
than Auto.
Note: The variables that are associated with only

one instance of hardware will only depend on
the mode of one function block (except for
the counter and serial ports). The variables
that are associated with a hardware type may
depend on a large number of blocks.

then
ELSE
The parameter is NOT under a data base revision number.
CASE 11B
This mode subclass is the same as CASE 10B except that the
only requested mode that is acceptable is O/S.

then
ELSE
The parameter is NOT under a data base revision number.
END SELECT
Secondary Ranges:
There is no structure defined for bits 10-0 in variables whose
parameter numbers have bit 12 set. They are assigned in random order
but, again, those parameters can not be accessed bit-wise by agents. In
addition, there will, of course, be no generalized logic in the DBWS to
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
handle these parameters. They will be assumed to be:

- under a data base revision number if bit 11 is set.
- there will be no mode restrictions limiting a write.
Most of the parameter numbers that will be assigned by the User

Layer Standard will be based on a system that assigns specific meaning
to the high order bits of the 13 "remaining" bits in the parameter
number. This system will be invoked when bit 12 is reset.
The following is the detailed statement of that system. In each

case, the required states of the higher order bits in the full 16 bit
parameter number are given in parenthesis (using an "x" for "either
state is acceptable" - some specific combinations of x's may be
excluded).
SELECT CASE (Bit 11)

CASE 0 'Bits 12&11 = 00B
Note: a fundamental restriction of the parameter number design
is that any parameter with bit 11 set can not be
accessed bit-wise by an agent. The set of parameters

--```,``-`-`,,`,,`,`,,`---

448
under this logic are therefore the only ones that are
accessible to such agents.
IF Bit 8 = set, then
This parameter is associated with a set of parameters that
has a status byte or a set of status bytes. (xxx00xx1)
IF Bits 1 & 0 = 10B, then this parameter can NEVER be written.

Note: (see parameter "z+2" in Drawing 2 in the paper
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
"Application Support Services Interface").
IF Bits 10 & 9 = 01B, then
This parameter can only be written IF
The actual block mode = O/S, OR
(The requested block mode = O/S AND the actual
block mode does not have LO set.) OR
The agent is type writeable, OR
The agent is type required writeable OR
[(The agent is NOT type "null" NOR type "immediate")
AND
The status = No-Com] OR
[The agent is type "immediate" AND
the agent is associated with an Output Word AND
the block is in one of the following mode
states:
The highest priority active mode bit set =
Man
OR
(Requested mode = Man AND the active mode
does not have LO nor IMan set)]
ELSE 'bits 10 & 9 <> 01B
Follow the mode rules given above.
Bits 7-2 are available for specific parameter

number assignment (32 instances in each of the 4 mode
restriction set). Bits 1 & 0 are used to select one of the
four parameters in the status byte set.
ELSE 'bit 8 is reset
IF (Bits 10 & 9 = 00B AND Bits 7 & 6 = 11B), then
This parameter must be written through the DBWS. The
DBWS will use parameter specific rules to limit the
writing of this value but those rules are NOT block
mode specific. The rules will specify when the
parameter is under a revision number. (64 instances).
(xxx 00 00011)
ELSEIF Bits 10 & 9 <> 01B, then
Bits 7-0 are available for specific parameter assignment
(256 instances in each of 2 mode categories plus
192 in the third). (xxx00xx0)
There is one restricted sub-range of parameter

numbers in this set that has been specifically
defined. See page 3 of the paper "Standard Block
Functions" for the definitions of the parameter
numbers 0000H to 0005H.
ELSE 'bits 10 & 9 = 01B
SELECT CASE (Bits 7 & 6)
CASE 00B
The parameter must be in a function block. In
order to write the parameter, the block must be
in a requested mode of higher priority than
Auto AND the LO actual mode bit must not be
set.

assignment (32 instances). (xx00001000)
CASE 01B
The parameter must be in a function block. In
order to write the parameter, the block must:

--```,``-`-`,,`,,`,`,,`---

449
{(Be in a requested mode of higher

priority than Cas) AND NOT
[(IF the requested mode is NOT O/S) AND
(the parameter is the Setpoint) AND (Input
#1 tracking is enabled)]}

CASE 10B
This subclass is reserved for future Standard
definition.

CASE 11B
The parameter must be processed under
parameter-specific rules by the DBWS. The
rule will be at least partially mode specific.
The rules will specify when the parameter is
under a revision number.

CASE 1 'bits 12&11 = 01B
The parameter is in a "special" category (the lower order bits will
define exactly which special category). (xxx01)
Note: a fundamental restriction of the parameter number design

is that any parameter with bit 11 set can not be
accessed bit-wise by an agent. All parameters in the
"special" categories will therefore be inaccessible to
such access.
IF Bit 8 = reset, then
This parameter is an Auto-Formatted variable. (xxx01xx0)
IF Bit 7 = reset, then

This parameter is associated with hardware.

This parameter is associated with a hardware type.
The mode restriction is exactly the same as for

mode restriction 10B.
Bits 6 - 1 of the parameter number specify the

hardware type - the code is the same as used for
the data dictionary variable PN plus code 3FH
specifies "the hardware type of the hardware pointed
to by the hardware agent of this TO".
Bit 0 in the parameter number specifies the whole

auto-format variable (bit 0 = reset) or just the
header and the data portions (bit 0 = set).
The index of the parameter specifies which of the

seven possible instances of auto-format variables
is addressed.
See the description of item 12 in the data

dictionary variable PN on page 8 of the paper
"Application Support Services Interface".

This parameter is associated with a hardware
instance.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^
Bits 6 - 1 in the parameter number specify the

--```,``-`-`,,`,,`,`,,`---

450
hardware type - the code is the same as used for

the data dictionary variable PN plus code 3FH
specifies "the hardware pointed to by the hardware
agent of this TO".
Bit 0 in the parameter number specifies the whole

auto-format variable (bit 0 = reset) or just the
header and the data portions (bit 0 = set).
The index of the parameter specifies which one of

the auto-format variables associated with this
hardware instance is addressed.
See the description of bits 9 and 10 in item 12 in

the data dictionary variable PN on page 8 of the
paper "Application Support Services Interface".
ELSE 'bits 10 & 9 = 00B or 11B

Available for hardware related auto-format variables
with the two types of mode constraints. Not under
a revision number.
ELSE 'bit 7 = set

Auto-format variables not associated with hardware.
Bits 6-1 are available for specific parameter number

assignment (64 instances in each of the four mode groups).
Bit 0 is used to select the following:
IF Bit 0 = 0, then
access the entire parameter.
ELSE 'bit 0 = 1
access only the header and data portion of the
parameter.
ELSE 'bit 8 is set
IF Bits 7&6 <> 11B, then
This range will be used for normal variables that will
not be bit-wise accessible by agents.
For each of the 3 permutations of bits 7&6 excluding 11B,

the first 16 parameter numbers in each range are reserved
for "no-cross-over" parameters. Specifically, any
parameter in this range with its low order bit set will
be of the same data type as the parameter with the next
lower number. In addition, the odd numbered parameter
CAN NOT be equal to or smaller than the preceding even
numbered parameter. If both parameters are written by
one write message, the intermediate state, after one of
the parameters is written, will NOT be checked. Only the
final state must satisfy the rule.
For each of the 3 permutations of bits 7&6 excluding 11B,

the high order 8 parameter numbers in each range are
reserved for parameters whose value can not be written as
a negative number.

assignment (64 instances in each of the three
permutations of bits 7 & 6 for each of the 4 mode
restriction groups = 768 values). (xxx01xx1xx)
IF bits 7&6 = 11B, then
This parameter is addressed to a "physical" memory

location.
This parameter is the process value of a hardware

connection or a special physical node variable.

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
451
(0000101111)
One example of this type of parameter is the "RESTART"

parameter: a discrete which, when set, starts the
operation of the logic engine.
This range of parameter numbers is also used for "I/O

Values". They relate directly to the physical input or
output values, and can only be written if the User Layer
logic engine is stopped. Their design is included in the
definition of the individual function blocks that can
connect to each of the types of hardware. The
Application Support Services will not prevent a higher
level device from trying to write to an input but they
will prevent ANY write if the logic engine is running.
These values are never under a static data base revision
number.
Bit 14 must be reset.
IF bits 10 & 9 = 00B, then

assignment (64 instances).
ELSEIF bits 10 & 9 = 01B, then
Bits 5 - 0 in the parameter number specify the
hardware type - the code is the same as used for the
data dictionary variable PN plus code 3FH specifies
"the hardware type associated with the function
block addressed".
The index specifies which instance of the hardware

type is addressed.
ELSE 'bits 10 & 9 = 10B or 11B
No Standard parameters defined in this range.
DEFINED GROUPS:
The Application Support Service Interface has the ability to "group"
parameters in response to a suitable command from a higher level device. However,
it is clear that communication efficiency can be obtained by permanently defining
certain groups. Groups of parameters can be identified that will be read
frequently as part of the updating of the backup copy of the static data base.
By permanently defining these groups, the higher level device does not have to
command the grouping and the Field Device can employ a more efficient method of
implementation.
--```,``-`-`,,`,,`,`,,`---
It is assumed that the group parameters are simply a mapping of the already
existing data base items into one readable and writeable set.
The group variable "BACK_UP(0)" is defined for each type of tagged object.
All of the parameters in each set are static data base items that are freely
writeable. With one exception, the parameters are required in all Standard TO's.
The required parameters will be mapped into BACK_UP(0) in the order of their
parameter numbers, low parameter number first. The exception involves three
parameters (in a Physical node, 2 in logical nodes and function blocks) that are
part of one option - alert reporting. If the tagged object supports alert
reporting, the three parameters will be appended to the end of the list
(subordered in the order of their parameters numbers). If the three parameters
are in a list written to a TO that does not support the option, they will simply
be ignored. The exact parameters included will be identified in the next
section.
A second group variable, "BACK_UP(1)", is defined for logical nodes. It

contains all of the static data for the logical node variables. If the logical

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
452
node supports logical node variables, then it must support "BACK_UP(1)". Again,
the parameters will be identified in the next section and will be entered in
BACK_UP(1) in the order of their parameter numbers, low number first.
EXPLANATION OF TABLE 1
The attached Table 1 lists all of the parameters that have been assigned
parameter numbers in the physical and logical nodes. In addition, it contains
all of the function block parameters whose existence is independent of the
algorithm number.
The body of the table is broken into three sections: PHYSICAL NODES, LOGICAL
NODES, AND FUNCTION BLOCKS. Note that the low 13 bits in the actual parameter
numbers must be unique across ALL THREE sections because of the collapsing of the
data bases.
The first column gives the name of the parameter as used in the other papers
of this report. This name is often NOT unique across sections. If the name is
followed by the notation "(i)", then that parameter will use an index. If the
maximum possible value of the index is known (and is reasonable), the maximum
value will be shown within the parentheses instead of the "i".
The second and third columns give an exact paper and page reference to the
definition of the parameter.
The fourth column gives the data type of the variable using the following
names:
Visible a visible string (refer to the paper "Human I/F
Considerations", page 2)
U-Int. an unsigned integer.
S-Int. a signed integer.
Float a floating point number.
Bit Str. a bit string.
Discrete an 8 bit value whose low order bit indicates Set
(1)/Reset (0).
Auto-F an Auto-format parameter.
Pack U-I a complex data type consisting of packed unsigned
integers (may not be on byte boundaries and
may include some discrete bit assignments).
Complex a complex data type containing a variety of data types.
? the data type depends on other information - see the
defining reference.
--```,``-`-`,,`,,`,`,,`---
Refer to the paper "References" for the definition of these data types.
The fifth column gives the size of the parameter's value in bytes. In some
cases, a parameter number has been assigned to a parameter that is otherwise
undefined; in those cases, the size of the parameter may be shown as "?" because
the manufacturer must define the size. In the case of auto-format parameters,
the parameter size is not defined but the variable will self-define its size.
Therefore, that data type is always shown with the letter "S" under the size
column.
The sixth column gives the memory "type", using the definitions given above.
When the memory is given as "ROM/Dyn.", it is possible for either type of memory
to satisfy all requirements of the Standard depending on the Field Device design.
When the memory is given as "ROM/Stat", it is recognizing the option of having
part of the parameter in ROM and part in Static. See the defining reference.
Some of the entries for "Static" in this column are followed by a "*". This
notation identifies the specific parameters that are grouped into the parameter
BACK_UP0. The entry for BACK_UP0 also has the "*". The entries under Logical
Nodes that have two "*"'s after "Static" are the specific parameters that are
grouped into the parameter BACK_UP1. The entry for BACK_UP1 also has the two
"*"'s.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
453
The seventh column indicates which parameters are "required" and which are
"optional" as defined in the reference. The entries in this column require
"expansion" due to the lack of space in the Table. Their meanings are:
Req. - Required
Opt. - Optional. For Standard tagged objects, the presence of the
option will be indicated in the "Option Bit Strings".
Note: "Optional" is used here in the total device sense.
Many parameters shown here as "Optional" are referred
to as required in the reference paper. In all such
cases, the section of the reference paper has
previously focused on an optional function. Once that
function is supported, a whole set of parameters become
"required" in the context of the reference.
Note: the existence of every "Optional" parameter is
indicated, directly or indirectly, by a time critical
option bit string bit. If there is no directly related
bit defined, then the "Optional" parameter is one
defined as "required" once some functional option is
shown as supported by one of the defined option bits.
R-I/O - Required if the physical node has any I/O hardware.
R-FB1 - Required if the physical node has a second Field Bus
Interface (redundant or independent).
RxUD - A logical node variable that is required expect for
"Undefined" type logical nodes.
R-C&T - A logical node variable that is required in all Cycle/Phase
and Timed Standard type logical nodes.
R-CP - A logical node variable that is required in all Cycle/Phase
type logical nodes.
R-LNV - Required if the logical node supports logical node
variables.
R-Off - Required if the logical node supports off-logical node
agents.
The eighth column indicates if the parameter is required to be written

through a write handler (i.e., through the DBWS). If it is required, then a
"Yes" is entered in this column and bit 14 will be set. If not, a "No" is
entered. If the variable is "read-only", a "-" is given but bit 14 will still be
set. The value of Input Words and logical node variables will be shown as "Agt."
to highlight the special conversion of this status to "No" if the agent type is
not "Writeable" and "Required Writeable". Note that there is no column for the
read handler because no variable in the entire list of parameters requires a read
handler. All of the parameters can be read directly and bit 15 will always be
reset for these parameters. (There will be parameters in some of the Function
Blocks that will require a read handler).
The ninth column indicates if the parameter is read-only. If it is, then a

"Yes" is entered in this column and bit 13 will be set. If the parameter does
not have a status but requires not only the write handler but also requires a
masked write and/or a "compare-check" write (see "Complex Write Service" in the
paper "Data Base Write Service"), then the entry will be "Spl.".
The tenth column indicates if the parameter is under a data base revision
number. If it is, then a "Yes" is entered in this column; if not, a "No" is
entered; a "-" is entered if the variable is read-only. Two standard parameters,
REQ_MODE and FAIL_SAFE, are not under any revision numbers but are expected to be
handled as special cases by higher level devices. Therefore, when either of
these parameters is written, a special alert may be required. In these cases,
this column shows the entry "Part", short for partial. See the paper "Data Base
Write Service" for the exact handling of these two variables.
The eleventh column indicates the write access control that applies to the
parameter. It describes not only block mode constraints, but also includes
consideration of agent type, hardware status, and other special considerations.
In function blocks, this column will be dominated by mode considerations. It can
have one of the following indications:
"-" - the variable is read-only
"Free" - the variable is freely writeable

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
454
--```,``-`-`,,`,,`,`,,`---
"Spl." - access is defined by lower bit definitions.

"Yes" - access is limited at least partially by mode
Note that the logical node variable values are defined as being able to be
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
directly written but the parameter (z+2) never is and the agent itself will
restrict the other three parameters if the agent type does not allow direct
writes.
The twelfth column gives the high-order bits in the parameter number that is
assigned to the parameter IN BINARY NOTATION. Bits 15-13 are shown separated
from the lower order bits and bits 12 & 11 are also separated from their lower
order bits, in both cases to improve readability. Because of the definitions of
the bits given above, the length of these bit strings vary.
The thirteenth column gives the sequence number, in hex, which normally forms
the low order portion of the parameter number. However, there are three special
cases. For the parameters that use the hardware type in their parameter numbers,
the hardware type code is indicated by "HT". An entry of "SP" for special is
used for the sequence number of I/O_AF (i) because its index is compound. For
all auto-format variables, the least significant bit selects a partial or full
access of the variable, it is shown as an "x" to the right of the sequence
number. Finally, for parameters associated with a status byte, the low two bits
are used to distinguish between the set of four parameters. They will be shown
by two "x"'s to the right of the sequence number.
The next to the last column defines the "default" value that is to be used
for all of the static parameters and for some of the dynamic parameters. The
default value will be entered into the value of the parameter whenever:
1) the device starts up with an invalid data base (static or dynamic, as
appropriate).
2) the TO_TYPE is changed.
In case 2, the requested, not the default, value for TO_TYPE is obviously used
and the TAG_DESC is not to be altered. In general, the default values are
designed to set all node/algorithm options to the do-nothing value (usually
zero).
The notation used in the entries in the column are:

"0" - zero. If a discrete, all reset; if a signed integer,
+0.; if a bit string, all reset, if a visible string,
a string of nulls (0's). If an auto-format variable,
the default value will have a valid header and
whatever data is appropriate. Within a data string,
particular values may be set to their default value,
preferably a do-nothing value (zero?).
"xB" - a binary value of x.
"xH" - a hexadecimal value of x.
"Def./AL" - the default value is to be defined by the Application
Layer, not by the User Layer.
" Note 1" - there is no way to provide useful default data for
most visible strings. Therefore, these parameters
will default to a <US> [Unit separator - 31 (base10)]
indication in the first character position followed by
null characters (0's) in the other positions.
"Mfg. Dflt" - in some cases, a manufacturer may define a useful
default visible string. The user could then
modify it to a different language or semantics. This
notation is used to identify such opportunities.
"Mfg. Sub" - this note is used only for the TO_USER_SUBTYPE. This
parameter will default to the value, in the same TO,
of TO_MFG_SUBTYPE.
"Act or xH" - this note is used only for TO_TYPE. It indicates that
the TO_TYPE parameter will default to the actual
TO_TYPE if there is only one TO_TYPE that can be
supported by the TO. If the TO_TYPE of the TO can be
configured by the user, then the default value will be
xH.
"Note 2" - this note is used only for the clipboards. The
default value of CUR_CLIP_x (the current last page of

455
the clipboard) is the value shown in the high 8 bits

of MAX_CLIP_x (the number of pages of the clipboard
that are in ROM).
"Note 3" - this note is used only for the value CB (current
number of blocks being executed) in a logical node.
It will default to:
1 IF MBC (maximum blocks per cycle) = 1 at the
default CX.
ELSE
n where n is the lesser of (x+1) and y.
x = the block number of the highest numbered
block that has a valid static data base.
If there are none, then x = -1.
y = the maximum blocks per cycle at the
default CX.
"Note 4" - this note is used only for the value CX (current
cycle time exponent) in a logical node. It will
default to:
7 if this logical node supports active off-
physical node agents
ELSE
n where n is the value of CX that will allow
MBC to be equal to or greater than the value
of (x+1) defined above.
Note: a manufacturer of a device that supports active
off-physical node agents is specifically
encouraged to include the capability to scan the
configuration of the logical node. If no "off-
physical node but on-Field Bus" agents are
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
configured, then CX can default to n.
The last column gives a brief description of the parameters.
The entries for the logical node variables in the Table require explanation.
The first two logical node variables can be either analog or discrete. The other
three can only be discrete. There are 7 parameters defined for LN_VAR0 in the
table. For LN_VAR1 there is simply a note that the same 7 parameters are
repeated using the format for the name as indicated. In both of these cases, the
value can be either analog or discrete. For LN_VAR2, there is a new (specific)
definition of the data type. The other 6 parameters simply repeat. Then for
LN_VAR3 and LN_VAR4, the full 7 parameter set from LN_VAR2 repeats.
HELPFUL READER GUIDE:

The decoding of the parameter numbers is relatively simple at the more
general level but becomes quite complex for a few instances. The following
simple guide will decode most (but not all) of the parameter numbers:
- bit 15 set requires a read handler (rare).
- bit 14 set requires a write handler (normal).
- bit 13 set is read-only (fixed data).
- Normal Read, NOT Writeable:

+ 011 10 (s) - NOT bit-wise accessible by an agent.
s = 11 bit sequence number (in the
"xxx10" series).
+ 011 00 - bit-wise accessible by an agent.
- Normal Read, Writeable through DBWS:

+ 010 11 (s) - NOT bit-wise accessible by an Input agent,
NO mode/state controls,
UNDER revision number.

--```,``-`-`,,`,,`,`,,`---
Array of Basic Parameters

456

"xxx11" series).
+ 010 x0 00 011 - bit-wise accessible by an Input agent
if x = 0,
PARAMETER-SPECIFIC mode based rules,
revision number BY THE RULES.
+ 010 00 01 0xx - bit-wise accessible by an Input agent,
MODE BASED rules,
revision number BY THE RULES.
x <> 11B
- Direct Read and Write:

+ 000 00 00 0xx - bit-wise accessible by any agent.
NO revision number.
xx <> 01B
+ 000 10 (s) - NOT bit-wise accessible by any agent.
NO revision number.
"xxx10" series).

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
457
Array of Basic Parameters Table 1 Parameter List

Table 1
PHYSICAL, LOGICAL, AND BASIC FUNCTION BLOCK

PARAMETER LIST
Parameter Reference Data Memory Param.Num. Seq.

____Name_______ __Paper__ Page Type Bytes Type (Binary) Num. Comments
PHYSICAL NODES:
TAG Hardware 2 Visible 16 EEPROM 011 10 16 char. visible name for the physical node.
Dflt = set by Appl. Layer
ADDRESS Hardware 2 U-Int. 2 Static 011 10 Application Layer assigned Field Bus
address.
Dflt = set by Appl. Layer.
TAG_DESC Hardware 2 Visible 64 Static* 010 11 32 Character descriptor of the tag.
Dflt = <us> + zero's
MFG_NAME Hardware 21 Visible 32 ROM 011 10 Manufacturers name (single byte per char.).
MODEL_NUMBER Hardware 21 Visible 32 ROM 011 10 Physical device's model number
(1 byte/char).
SERIAL_NUMBER Hardware 21 U-Int. 4 ROM 011 10 Physical device's serial number.
FIELD_BUS_REV Hardware 22 U-Int. 2 ROM 011 10 Revision number of Field Bus standard used.
DEVICE_REV Hardware 22 U-Int. 2 ROM 011 10 Revision number of the device's program.
FB_POWER Hardware 22 Float 4 ROM 011 10 Power drawn from Field Bus - milliwatts.
FB_CAPAC Hardware 22 Float 4 ROM 011 10 Device capacitance on Field Bus - mf.
FB_INDUCT Hardware 22 Float 4 ROM 011 10 Device inductance on Field Bus - mH.
ASK Alert 2 U-Int. 1 Static* 010 11 Alarm Sort Key for Physical Node.
Dflt = 0
BASK Alert 2 U-Int. 2 Static* 010 11 Batch Alarm Sort Key for Physical Node.
Dflt = 0
TO_TYPE Log. Nodes 3 U-Int. 1 Static 010 01 001xx Actual type of the Physical Node (xx<>11B).
Dflt = Actual or 0H
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
TO_MFG_SUBTYPE Log. Nodes 3 U-Int. 1 ROM/Dyn. 011 10 Manufacturer-assigned display type for PN.
TO_USER_SUBTYPE Log. Nodes 3 U-Int. 2 Static* 010 11 User-assigned (display) type for PN.
Dflt = TO_MFG_SUBTYPE
SFAIL-SAFE Start-Rest 3 Bit Str. 1 Static 010 00 00011 "System" Fail-safe option.
Dflt = Bit1 = Bit 0
RESTART Start-Rest 3 Discrete 1 Physical 000 01 00111 Writeable "start" button.
Dflt. = 0
NODE_TIME Hardware 14 U-Int. 6 Dynamic 011 10 48 Bit, 1/32 of millisec.
time since start-up.
Dflt. = 0
OFFSET_DB Hardware 15 U-Int. 2 Static 010 11 Deadband on bias adjustment alert report .

--```,``-`-`,,`,,`,`,,`---

458
Dflt = 1B
ALARM_TIME Hardware 18 U-Int. 6 Static 010 11 48 Bit, 1/32 of millisec. time to "set
alarm".
Dflt = 0
ALARM Hardware 18 Bit Str. 1 Dynamic 010 00 00011 Bit 0- Alarm clock rang / Bit 1- clock
lost.
TIME_CRIT0 Hardware 20 Bit Str. 2 ROM 011 10 Time critical options bit string #0.
TIME_CRIT1 Hardware 23 Bit Str. ? ROM 011 10 Time critical options bit string #1.
TIME_CRIT2 Hardware 23 Bit Str. ? ROM 011 10 Time critical options bit string #2.
MIN_TC0 Hardware 22 Bit Str. 2 Static* 010 11 User set "minimum" TIME_CRIT0.
Dflt = 0
N_TIME_CRIT0 Hardware 23 Bit Str. ? ROM 011 10 Non-time critical option bit string #0.
CLEAR_OUT Hardware 12 Discrete 1 Dynamic 010 00 00011 Discrete to force unused outputs off.
Dflt. = 0
AX Hardware 14 S-Int. 1 ROM/Dyn. 011 10 Physical node self-diagnostic cycle time.
EXPOSE Alert 10 U-Int. 4 Static* 010 11 Min. time in Application Layer Alert
Buffer. Dflt = 5 min.
ALERT_UNACK_OPT Alert 6 Bit Str. 4 Static* 010 11 First 32 alert codes - unack. option bits.
Dflt = 0
ALERT_UNACK_OPT1Alert 3 Bit Str. 4 Static 010 11 Second 32 alert codes - unack. option bits.
Dflt = 0
ALERT_PRIORITY Alert 6 Bit Str. 16 Static* 010 11 First 32 alert codes - priorities.
Dflt = All 10H
ALERT_PRIORITY1 Alert 3 Bit Str. 16 Static 010 11 Second 32 alert codes - priorities.
Dflt = All 10H
ALERT_SET0 Alert 7 Bit Str. 2 Dynamic 011 00 First 16 alert codes - current state.
Dflt. = 0
ALERT_SET1 Alert 7 Bit Str. 2 Dynamic 011 00 Second 16 alert codes - current state.
Dflt. = 0
ALERT_SET2 Alert 3 Bit Str. 2 Dynamic 011 00 Third 16 alert codes - current state.
Dflt. = 0
ALERT_SET3 Alert 3 Bit Str. 2 Dynamic 011 00 Fourth 16 alert codes - current state.
Dflt. = 0
ALERT_UNACK0 Alert 7 Bit Str. 2 Dynamic 000 00 000 First 16 alert codes - unack. state.
Dflt. = 0
ALERT_UNACK1 Alert 7 Bit Str. 2 Dynamic 000 00 000 Second 16 alert codes - unack. state.
Dflt. = 0
ALERT_UNACK2 Alert 3 Bit Str. 2 Dynamic 000 00 000 Third 16 alert codes - unack. state.
Dflt. = 0
ALERT_UNACK3 Alert 3 Bit Str. 2 Dynamic 000 00 000 Fourth 16 alert codes - unack. state.
Dflt. = 0
ALERT_UNRPT0 Alert 7 Bit Str. 2 Dynamic 011 00 First 16 alert codes - unreported state.
Dflt. = 0
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
No reproduction or networking permitted without license from IHS
459
--```,``-`-`,,`,,`,`,,`---
ALERT_UNRPT1 Alert 7 Bit Str. 2 Dynamic 011 00 Second 16 alert codes - unreported state.
Dflt. = 0
ALERT_UNRPT2 Alert 3 Bit Str. 2 Dynamic 011 00 Third 16 alert codes - unreported state.
Dflt. = 0
ALERT_UNRPT3 Alert 3 Bit Str. 2 Dynamic 011 00 Fourth 16 alert codes - unreported state.
Dflt. = 0
ALERT_DESC0 Alert 8 Visible 64 Static 010 11 Descriptor for alert #29.
Dflt = Mfg. Default
Reserve 1-18 Alert 8 Visible 64 Static 010 11 Reserved for Descriptors for alerts
#30 - #47. Dflt = Mfg. Default
REQ_TIME0 Start-Rest 2 U-Int. 2 Static 010 11 Requested "hot" restart timer setting.
Dflt = 4 sec.
REQ_TIME1 Start-Rest 2 U-Int. 2 Static 010 11 Requested "warm" restart timer setting.
Dflt = 6 min.
MAX_CLIP_P H I/F Con. 14 Bit Str. 2 ROM 011 10 Maximum number of primary clipboard pages.
CUR_CLIP_P H I/F Con. 14 U-Int. 1 Static 011 10 Current last page of primary clipboard.
Dflt = high 8 of MAX_CLIP_P
CLIP_REV_P H I/F Con. 15 U-Int. 2 Static 010 10 00001 6Primary clipboard revision number.
Dflt = 0
CPAGE_P (255) H I/F Con. 14 Visible 119 ROM/Stat 011 11 Individual primary clipboard pages.
MAX_CLIP_A H I/F Con. 15 Bit Str. 2 ROM 011 10 Maximum number of alternate clipboard pages.
CUR_CLIP_A H I/F Con. 15 U-Int. 1 Static 011 10 Current last page of alternate clipboard.
Dflt = high 8 of MAX_CLIP_A
Not for Resale
CLIP_REV_A H I/F Con. 15 U-Int. 2 Static 010 10 00001 7Alternate clipboard revision number.
Dflt = 0
CPAGE_A (255) H I/F Con. 15 Visible 128 ROM/Stat 011 11 Individual alternate clipboard pages.
COUNT_TIME0 Hardware 23 U-Int. 6 Dynamic 010 00 00011 48 Bit, 1/32 mill.time since zero counters.
Dflt. = 0
RESYNC_COUNT Log. Node 28 U-Int. 2 Dynamic 011 10 Number of resync. by all logical nodes.
Dflt. = 0
TOT_MESSAGES0 Hardware 23 U-Int. 4 Dynamic 011 10 Total messages (FB0).
Dflt. = 0
APPL_FAIL0 Hardware 23 U-Int. 2 Dynamic 011 10 Application Layer message failures (FB0).
Dflt. = 0
FRAMING_ERROR0 Hardware 24 U-Int. 2 Dynamic 011 10 Count of framing errors (FB0).
Dflt. = 0
CRC_ERROR0 Hardware 24 U-Int. 2 Dynamic 011 10 Count of CRC errors (FB0).
Dflt. = 0
PARAM_NOT0 Hardware 24 U-Int. 2 Dynamic 011 10 Count of times param. not supported (FB0).
Dflt. = 0
WRITE_BUF_FUL0 Hardware 24 U-Int. 2 Dynamic 011 10 Count of times write buffer full (FB0).
Dflt. = 0
READ_HAND_BSY0 Hardware 24 U-Int. 2 Dynamic 011 10 Count of times read handler busy (FB0).
Dflt. = 0
ALERT_BUF_FUL0 Hardware 24 U-Int. 2 Dynamic 011 10 Count of times alert buffer full (FB0).
Dflt. = 0
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
460
CYCLE_OVERRUN0 Hardware 24 U-Int. 2 Dynamic 011 10 Times write buffer not empty in cycle.
Dflt. = 0
ERROR_RATE0 Hardware 24 Float 4 Dynamic 011 10 Filtered framing + CRC error rate (FB0).
Dflt. = 0
FILTER0 Hardware 25 U-Int. 1 Static* 010 11 Filter factor for ERROR_RATE (FB0).
Dflt = 255
ERROR_RATE_LIM0 Hardware 25 Float 4 Static* 010 11 Alarm limit on ERROR_RATE (FB0).
Dflt = 0.01
COUNT_TIME1 Hardware 25 U-Int. 6 Dynamic 010 00 00011 48 Bit, 1/32 mill.time since zero counters.
Dflt. = 0
TOT_MESSAGES1 Hardware 25 U-Int. 4 Dynamic 011 10 Total messages (FB1).
Dflt. = 0
APPL_FAIL1 Hardware 25 U-Int. 2 Dynamic 011 10 Application Layer message failures (FB1).
Dflt. = 0
FRAMING_ERROR1 Hardware 25 U-Int. 2 Dynamic 011 10 Count of framing errors (FB1).
Dflt. = 0
CRC_ERROR1 Hardware 25 U-Int. 2 Dynamic 011 10 Count of CRC errors (FB1). Dflt. = 0
PARAM_NOT1 Hardware 25 U-Int. 2 Dynamic 011 10 Count of times param. not supported (FB1).
Dflt. = 0
WRITE_BUF_FUL1 Hardware 25 U-Int. 2 Dynamic 011 10 Count of times write buffer full (FB1).
Dflt. = 0
READ_HAND_BSY1 Hardware 25 U-Int. 2 Dynamic 011 10 Count of times read handler busy (FB1).
Dflt. = 0
ALERT_BUF_FUL1 Hardware 25 U-Int. 2 Dynamic 011 10 Count of times alert buffer full (FB1).
Not for Resale
Dflt. = 0
CYCLE_OVERRUN1 Hardware 25 U-Int. 2 Dynamic 011 10 Times write buffer not empty in cycle (FB1).
Dflt. = 0
ERROR_RATE1 Hardware 25 Float 4 Dynamic 011 10 Filtered framing + CRC error rate (FB1).
Dflt. = 0
FILTER1 Hardware 25 U-Int. 1 Static 010 11 Filter factor for ERROR_RATE (FB1).
Dflt = 255
ERROR_RATE_LIM1 Hardware 25 Float 4 Static 010 11 Alarm limit on ERROR_RATE (FB1).
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Dflt = 0.01
P_FREE_FLOAT0 Hardware 25 Float 4 Static* 010 11 Free floating point number for higher level.
Dflt = NaN
P_FREE_FLOAT1 Hardware 25 Float 4 Static* 010 11 Free floating point number for higher level.
Dflt = NaN
P_FREE_STRING0 Hardware 25 Bit Str. 2 Static* 010 00 000xx Free bit string for higher level (xx<>11B).
Dflt = 0
P_FREE_STRING1 Hardware 25 Bit Str. 2 Static* 010 00 000xx Free bit string for higher level (xx<>11B).
Dflt = 0
P-FREE_LABEL0 Hardware 25 Visible 32 Static 010 11 Free label for higher level.
P_FREE_LABEL1 Hardware 25 Visible 32 Static 010 11 Free label for higher level.
LN_TAG (255) Log. Nodes 2 Visible 16 Static 010 00 00011 Array of Logical Node tag names.
--```,``-`-`,,`,,`,`,,`---
461
Dflt = Def. by Appl. Layer

I/O_Value (8191)Hardware 12 U-Int. 2 Physical 000 01 01111 HT Array of physical I/O values.
I/O_AF (8) Hardware 11 Auto-F. S EEPROM 010 01 1000 SP,x Auto-Formatting variables for each I/O pt.
I/O_Type_AF (8) Hardware 11 Auto-F. S EEPROM 010 01 0100 HT,x Auto-Form. variables for each I/O type.
PN_AF_F (63) Hardware 12 Auto-F. S Static 010 01 0001 ,x Array of PN Auto-Form. variables -
Freely chg. Dflt. = 0
PN_AF_M (63) Hardware 12 Auto-F. S Static 010 01 1001 ,x Array of PN Auto-Form. variables -
Man to chg. Dflt. = 0
PN_AF_O (63) Hardware 12 Auto-F. S Static 010 01 1101 ,x Array of PN Auto-Form. variables -
O/S to chg. Dflt. = 0
PN_SDBRN Basic Parm 3 U-Int. 2 Static 010 10 00001 0 Physical node static data base
revision num. Dflt = 0
PN_AFRN Basic Parm 3 U-Int. 2 Static 010 10 00001 3 Physical node Auto-Format revision number.
Dflt = 0
P_BACK_UP(0) Basic Parm 14 Complex 112 Group* 010 11 Group of Static-Free-R/W parm.for
BU/Restore.
Subtotal - Req. (w/ 1 FB & I/O) 194 Static
51 Dynamic
105 Other
LOGICAL NODES:
LN_NUM Log. Nodes 2 U-Int. 1 ROM/Dyn. 011 10 Index number of logical node in physical
node. Dflt = set by Appl. Layer
TAG_DESC Log. Nodes 2 Visible 64 Static 010 11 32 Character descriptor for tag.
Dflt = set by Appl. Layer
--```,``-`-`,,`,,`,`,,`---
LN_OOS Log. Nodes 2 Discrete 1 Static* Logical Node - O/S. Dflt = 0
ASK Alert 2 U-Int. 1 Static* 010 11 Alarm Sort Key for Logical Node.
Dflt = 0
BASK Alert 2 U-Int. 2 Static* 010 11 Batch Alarm Sort Key for Logical Node.
Dflt = 0
TO_TYPE Log. Nodes 3 U-Int. 1 Static 010 01 111xx Actual type of the Logical Node (xx<>11B).
Dflt = actual or 10H
TO_MFG_SUBTYPE Log. Nodes 3 U-Int. 1 Dynamic 011 10 Manufacturer-assigned display type for LN.
TO_USER_SUBTYPE Log. Nodes 3 U-Int. 2 Static* 010 11 User-assigned (display) type for LN.
MB Log. Nodes 8 U-Int. 2 ROM 011 10 Maximum blocks allowed.
MV Log. Nodes 8 U-Int. 2 ROM 011 10 Maximum number of measured variables.
CB Log. Nodes 8 U-Int. 2 Static 010 00 00011 Current blocks being used.
Dflt = 1 or n (see Note 3)
MX Log. Nodes 9 S-Int. 1 ROM/Dyn. 011 10 Manufacturer's (min.) exponent for
cycle time.
CX Log. Nodes 9 S-Int. 1 Static 010 00 00011 Current exponent for cycle time.
Dflt = 7 or n (see Note 4)
AX Log. Nodes 7 S-Int. 1 ROM/Dyn. 011 10 Repeat rate of alert detection.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
462
MBC Log. Nodes 10 U-Int. 2 ROM/Dyn. 011 10 Maximum blocks per cycle allowed.
TIME_CRIT0 Log. Nodes 25 Bit Str. 2 ROM 011 10 Time-critical options bit string #0.
TIME_CRIT1 Log. Nodes 26 Bit Str. ? ROM 011 10 Time-critical options bit string #1.
TIME_CRIT2 Log. Nodes 26 Bit Str. ? ROM 011 10 Time-critical options bit string #2.
MIN_TC0 Log. Nodes 27 Bit Str. 2 Static* 010 11 User set "minimum" TIME_CRIT0.
Dflt = 0
N_TIME_CRIT0 Log. Nodes 27 Bit Str. 2 ROM 011 10 Non-time critical option bit string #0.
N_TIME_CRIT1 Log. Nodes 27 Bit Str. ? ROM 011 10 Non-time critical option bit string #1.
N_TIME_CRIT2 Log. Nodes 27 Bit Str. ? ROM 011 10 Non-time critical option bit string #2.
MIN_NTC0 Log. Nodes 27 Bit Str. 2 Static* 010 11 User set "minimum" N_TIME_CRIT0.
Dflt = 0
FAIL-SAFE Log. Nodes 23 Bit Str. 1 Static 010 00 00011 Fail-safe option bit string.
Dflt = 00B
FS_KILL Log. Nodes 23 Discrete 1 Static 000 00 000 Discrete to disable the fail-safe option.
Dflt = 0
FS_REPEAT Log. Nodes 23 U-Int. 1 Static 010 11 Repeat rate for "fail-safe inactive" alarm.
Dflt = 5 min.
IT Log. Nodes 21 U-Int. 2 Dynamic 000 10 Isolation timer current value.
Dflt. = 0
ISOLATE_TIME Log. Nodes 21 U-Int. 2 Static 010 11 Isolation timer setpoint.
Dflt = 0
NOWRITE Log. Nodes 23 Bit Str. 1 Static 010 00 00011 Bits to control option to prevent writing.
Not for Resale
Dflt = 0
PRIVATE_OFFSET Hardware 16 S-Int. 4 Dynamic 011 10 Private clock offset in 1/32 of
milliseconds. Dflt. = 0
P_OFFSET_DB Hardware 16 U-Int. 2 Static 010 11 Deadband on bias adjustment alert report.
Dflt = 0
ALGO_STR Log. Nodes 5 Bit Str. 32 ROM 011 10 List of supported algos in this log. node.
ALGO_STR1 Log. Nodes 5 Bit Str. 32 ROM 011 10 List of non-standard algos in this log node.
SYNC_POINT Log. Nodes 27 Bit Str. 2 Static* 010 11 Packed integers to control cycle sync.
SYNC_TOL Log. Nodes 28 Integer 2 Static* 011 10 Sync. tolerence (deadband).
Dflt = 0
Dflt = 0
Dflt = all 10H
Dflt = all 10H
Dflt = 0
Dflt = 0
Dflt = 0
--```,``-`-`,,`,,`,`,,`---
463
Dflt = 0
Dflt = 0
Dflt = 0
Dflt = 0
Dflt = 0
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Dflt = 0
Dflt = 0
Dflt = 0
Dflt = 0
Dflt = Mfg. Default
Reserve 1-18 Alert 8 Visible 64 Static 010 11 Reserved for descriptors for alerts #30 -
#47. Dflt = Mfg. Default
PHASE_MAP Log. Nodes 10 Pack U-I 16 Dynamic 011 10 Array of # blocks/phase in logical node.
Dflt = 0
--```,``-`-`,,`,,`,`,,`---
PREFETCH Appl. Sev. 19 U-Int. 2 Dynamic 011 10 Prefetch time for logical node variables.
Dflt = 0
MAX_PREFETCH Appl. Sev. 19 U-Int. 2 Static 0 0 High alarm limit for prefetch.
Dflt = (2**CX)/2
LN_VAR0 Log. Nodes 16

Dynamic ?
000 00 011 ?
|--->
23 byte Bit String if discrete;
9 byte Float/status if analog.
Logical node variable #0 (discrete or float). Dflt. = 0
L_AGENT-TYPE0 Agents 3 U-Int. 1 Static** 010 11 Agent type. Dflt = 0
L_STATIC_VALUE0 Agents 3 ? ? Static** 010 11 Static value - for Immediate type agent.
Dflt = 0 or NaN
L_POINT_TAG0 Agents 3 Visible 16 Static** 010 11 Pointer: tag name.
Dflt = 0
L_POINT_PARAM0 Agents 3 U-Int. 2 Static** 010 11 Pointer: parameter number.
Dflt = 0
L_REV-NUM0 Agents 3 U-Int. 2 Dynamic 011 10 Latest revision number (if supported).
Dflt = 0
L_NO_COM0 Agents 3 U-Int. 1 Dynamic 011 10 No_Com counter.
Dflt = 0
L_xxx1 ** 7 Agent parameters for opt. LN_VAR1 (analog or discrete) **
Set of 6 values as defined for LN_VAR0.

--```,``-`-`,,`,,`,`,,`--- 464
LN_VAR2 Basic Parm 18 Bit str. 23 Dynamic 000 00 011

Logical node variable #2 (discrete).
Dflt = 0
L_xxx2 ** Other 6 Agent param. for LN_VAR2 (discrete - no static value) **
L_xxx3 ** 7 Agent param. for opt. LN_VAR3 (discrete - no static value) **
L_xxx4 ** 7 Agent param. for opt. LN_VAR4 (discrete - no static value) **
L_FREE_FLOAT0 Hardware 25 Float 4 Static* 010 11 Free floating point number for higher level.
Dflt = NaN
L_FREE_FLOAT1 Hardware 25 Float 4 Static* 010 11 Free floating point number for higher level.
Dflt = NaN
L_FREE_STRING0 Hardware 25 Bit Str. 2 Static* 010 00 000xx Free bit string for higher level (xx<>11B).
Dflt = 0
L_FREE_STRING1 Hardware 25 Bit Str. 2 Static* 010 00 000xx Free bit string for higher level (xx<>11B).
Dflt = 0
L-FREE_LABEL0 Hardware 25 Visible 32 Static 010 11 Free label for higher level.
L_FREE_LABEL1 Hardware 25 Visible 32 Static 010 11 Free label for higher level.
ASSIGN_USER Modes 6 Pack U_I 11 Static* 010 11 String of parameters under User access.
Dflt = 0
LN_AF (63) Appl. I/F 12 Auto-F. S Static 010 01 0001 ,x Array of Log. Node Auto-Form. variables.
Not for Resale
Dflt = 0
FB_TAG (i) Log. Nodes 2 Visible 16 Static 010 00 01011 Array of function block names in LN.
Dflt = set by Appl. Layer.
LN_SDBRN Basic Parm 3 U-Int. 2 Static 010 10 00001 1 Logical node static data base revision
number. Dflt = 0
LN_AFRN Basic Parm 3 U-Int. 2 Static 010 10 00001 4 Logical node auto-format data revision
number. Dflt = 0
L_BACK_UP(0) Basic Parm 14 Complex 55 Group* 010 11 Group of Static-Free-R/W param.for
BU/Restore.
L_BACK_UP(1) Basic Parm 14 Complex 109 Group** 010 11 Group of Static-Free-R/W param.for
BU/Restore.
Subtotal - Req. (w/ 1 FB & I/O) 209 Static

13 Dynamic
43 Other
FUNCTION BLOCKS:
FB_NUM Log. Nodes 2 U-Int. 2 ROM/Dyn. 011 10 Index number of function blk. in
logical node.
TAG_DESC Log. Nodes 2 Visible 64 Static* 010 11 32 Character description of the tag.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
465
ASK Alert 2 U-Int. 1 Static* 010 11 Alarm Sort Key for function block.
Dflt = 0
BASK Alert 2 U-Int. 2 Static* 010 11 Batch Alarm Sort Key for function block.
Dflt = 0
ACQUIROR Modes 7 U-Int. 2 Static* 010 11 Higher level program that acquired tag.
Dflt = 0
TO_TYPE Log. Nodes 3 U-Int. 1 Static 010 01 111xx Actual type of the Function Block (xx<>11B).
Dflt = Actual or 20H
TO_TYPE1 Log. Nodes 4 U-Int. 1 Static 010 00 01011 Actual extended type of the Function Block.
Dflt = 0
TO_MFG_SUBTYPE Log. Nodes 3 U-Int. 1 Dynamic 011 10 Manufacturer-assigned display type for FB.
TO_USER_SUBTYPE Log. Nodes 3 U-Int. 2 Static* 010 11 User-assigned (display) type for FB.
BX Log. Nodes 10 U-Int. 1 Static* 010 11 Block exponent for cycle/phase function
blks. Dflt = 0
PN Log. Nodes 10 U-Int. 1 Static* 010 11 Phase index for cycle/phase function blocks.
Dflt = 0
TIME_CRIT0 Log. Nodes 25 Bit Str. 2 ROM 011 10 Time-critical options bit string #0.
MIN_TC0 Log. Nodes 27 Bit Str. 2 Static* 010 11 User set "minimum" TIME_CRIT0.
Dflt = 0
OPTIONS0 Algo. Bit Str. 2 Static* 010 11 User options bit string #0.
Dflt = 0
OPTION_INT0 Algo. U-Int. 1 Static* 010 11 User option integer #0.
Dflt = 0
Not for Resale
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
FAIL_OPT0 F.B.Struc. 23 Bit Str. 2 Static* 010 11 User options - bit pairs for failure alerts.
Dflt = 0
FAIL_OPT1 F.B.Struc. 23 Bit Str. 2 Static 010 11 User options - bit pairs for failure alerts.
Dflt = 0
Dflt = 0
Dflt = 0
Dflt = all 10H
Dflt = all 10H
Dflt = 0
Dflt = 0
Dflt = 0
Dflt = 0
Dflt = 0
--```,``-`-`,,`,,`,`,,`---
466
Dflt = 0
Dflt = 0
Dflt = 0
Dflt = 0
Dflt = 0
Dflt = 0
Dflt = 0
Dflt = Mfg. Default
Reserve 1-18 Alert 8 Visible 64 Static 010 11 Reserved for descriptors for alerts #30 -
#47. Dflt = Mfg. Default
PREFETCH Appl. Sev. 19 U-Int. 2 Dynamic 011 10 Pre-schedule time for off-node fetches.
Dflt = 0
MAX_PREFETCH Appl. Sev. 19 U-Int. 2 Static* 011 10 High alarm limit for PREFETCH time.
Dflt = (2**CX)/2
ACTUAL_MODE Modes 3 Bit Str. 1 Dynamic 011 00 Mode bit string calculated by block.
Dflt = 80H
REQ_MODE Modes 3 Bit Str. 1 Static 000 00 000 Requested mode.
Not for Resale
Dflt = 80H
TATTLE Modes 11 Bit Str. 1 Dynamic 010 00 00011 Bit string to report reset att/access bit.
Dflt = FFH
MODE_PERMIT Modes 4 Bit Str. 1 Static 010 00 00011 Bit string showing permitted modes.
Dflt = 80H
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
ATT_ACCESS Modes 5 Bit Str. 1 Static 010 00 00011 Bit string showing attributes and access.
Dflt = 38H
FREE_MODE Modes 12 Bit Str. 1 Static* 010 11 Byte left free for higher level ctl. system.
Dflt = 80H
F_FREE_FLOAT0 Hardware 25 Float 4 Static* 010 11 Free floating point number for higher level.
Dflt = NaN
F_FREE_FLOAT1 Hardware 25 Float 4 Static* 010 11 Free floating point number for higher level.
Dflt = NaN
F_FREE_STRING0 Hardware 25 Bit Str. 2 Static* 010 00 000xx Free bit string for higher level (xx<>11B).
Dflt = 0
F_FREE_STRING1 Hardware 25 Bit Str. 2 Static* 010 00 000xx Free bit string for higher level (xx<>11B).
Dflt = 0
F-FREE_LABEL0 Hardware 25 Visible 32 Static 010 11 Free label for higher level.
F_FREE_LABEL1 Hardware 25 Visible 32 Static 010 11 Free label for higher level.
FB_AF (63) Appl. I/F 12 Auto-F. S Static 010 01 0001 ,x Array of Fun. Block Auto-Form. variables.
Dflt = 0
--```,``-`-`,,`,,`,`,,`---
467
--```,``-`-`,,`,,`,`,,`---
FB_SDBRN Basic Parm 3 U-Int. 2 Static 010 10 00001 2 Function block static data base revision
num. Dflt = 0
FB_AFRN Basic Parm 3 U-Int. 2 Static 010 10 00001 5 Function block auto-format data revision
num. Dflt = 0
F_BACK_UP(0) Basic Parm 14 Complex 113 Group* 010 11 Group of Static-Free-R/W param.for
BU/Restore.
Not for Resale
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
468
Function Blocks:
--```,``-`-`,,`,,`,`,,`---
Introduction to Function blocks

The four types of logical nodes provided for the Field Bus User Layer
Standard and the services that they provide to their function blocks have been
described. This section of the Technical Report will provide definitions of the
individual function block algorithms that can be implemented within those node
types. Most of the Standard function blocks have been designed to operate in the
Timed Standard logical node type.
All function blocks on Field Bus must support a "tag name" and a "mode". See
page 2 of the paper "Data Owner Structure - Logical Nodes" for a discussion of
tag names and the "Block Modes" paper (both papers are in the Structure section
of this Technical Report) for a complete definition of mode.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
A major consideration of the design of the Standard function blocks was the
reaction of the block algorithm to unexpected changes in the status of input and
output variables. Analog numbers can have a "NaN" value; both analog and
discrete variables can be marked "Bad" or communications to them may fail.
Cascade structures can fail or be broken, etc. The control system must be robust
in the face of such unexpected events. The reader is referred to the sections in
the Structure part of the Technical Report that define the status byte (the paper
by that name), and Attachment 1 to the paper on "Function Block Structure" where
the detailed logic of the manipulation of the status bytes is defined.
The description for each function block will detail any deviations or
extensions to the "General" handling defined in these references. In particular,
the Selector and Splitter algorithms will have major additions to the procedure
because of their unique structure.
An "Open" and two "Generic" block types are defined for use in those
situations in which the more rigidly defined Standard, Extended, and Alternate
blocks are not suitable. These two types are defined in the immediately
following sections. Specific Extended and Alternate blocks are, of course, not
defined since they are manufacturer variants of Standard blocks.
Certain block features were found to be common to many of the Standard

function blocks. Examples are the "PV Pointer" service and "Output Limiting".
These features were generalized and are described before the blocks. They are
then referenced as "standard block functions" in the description of each
algorithm.
In any logical node that supports more than one type of function block, there
is a need for a "do nothing" block to serve as the initial default block
algorithm. The first Standard block defined will be the "Null" algorithm - truly
a do nothing.
The descriptions of many of the Standard function blocks will include

pseudocode for the most detailed level of definition of the functionality of the
algorithms. Many of the standard algorithms can utilize certain standard
functional procedures. This becomes particularly significant at the pseudocode
level of discussion. Therefore, there is a section of the report to define the
library of procedures that the pseudocode for the algorithms will call upon. The
pseudocode for the procedures is included.
Each of the 32 Standard algorithms are presented. One part of the section
for each algorithm will give an input/output drawing for each algorithm. The
variables shown in that drawing will almost always have their own agents and
status bytes - see the papers with those names for detailed descriptions of those
design elements.
SP-50 User Layer Technical Report Function Blocks

469
The succeeding portions of each algorithm description will outline the

function of the algorithm, identify user options, and identify the "standard
block functions" that are supported. Unique block features and deviations from,
or extensions to, the standard method of handling variations in the status of the
inputs and outputs will be highlighted.
Appendix papers have been prepared to assist the reader in understanding the
design basis or the application of certain features of some of the algorithms.
There are absolutely no normative statements in the Appendix papers. All
requirements for all algorithms are as stated in the Technical Report ex the
Appendix.
As a separate portion of the description of each algorithm, a complete

pseudocode listing is presented.
Finally, the last part of the algorithm section is an array showing the
parameters accessible from the Field Bus for each of the 32 algorithms. This
array will include only the parameters that are algorithm type specific. The
similar paper - "Array of Basic Parameters" in the Structure section defined all
of the node and universal function block parameters.
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
470
Open Blocks
The significant later sections of this paper are:

GENERIC BLOCK FEATURES
OPEN BLOCK PARAMETERS
Static Database
STANDARD BLOCK PARAMETERS
GENERIC BLOCK PARAMETERS
BASIC CHARACTERISTICS:
The following block characteristics apply to open-type blocks which are used
with standard, alternate, or generic blocks:
- The specifics of the algorithm and algorithm options of open blocks are
defined by the manufacturer. Rules and data for use with standard,
alternate, or generic blocks are defined by this standard.
- The standard block features which are used by open blocks are defined by
the manufacturer, except as required below. If a manufacturer chooses
to incorporate certain standard block features in a particular open
block, those features shall operate as described in the User Layer
Technical Report.
- The number and characteristics of input and outputs, and the means used
for off logical node connections via field bus, are specified by the
manufacturer.
- The number and characteristics of any other parameters are specified by
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
the manufacturer.
NODE FEATURES:
The following characteristics ARE REQUIRED for nodes supporting generic blocks
which are interworkable with standard, alternate, or other generic blocks:
- Open blocks operate in a logical node and are identified by a standard
tag identifier. The logical node may use any type of block scheduling
scheme, as required by the function of the block as determined by the
manufacturer.
Other characteristics of nodes supporting standard blocks, as described in the

User Layer Technical Report, ARE OPTIONAL for nodes supporting only open blocks.
These characteristics ARE REQUIRED for nodes supporting BOTH standard and open
blocks.
STANDARD BLOCK FEATURES:

Open blocks ARE REQUIRED to use the Block Tag method of identification and
addressing, as are all other blocks on field bus. All other standard block
characteristics defined in the User Layer Technical Report ARE OPTIONAL for open
blocks, and may be used as appropriate for connections to standard, alternate,
and generic blocks. Open blocks ARE REQUIRED to NOT interfere with the
characteristics of standard and alternate blocks which are defined in the User
Layer Technical Report.

--```,``-`-`,,`,,`,`,,`---

471
GENERIC BLOCK FEATURES:

Open blocks are required to use the Manufacturer's block subtype and the User's
block subtype as specified for Generic Blocks. All other generic block
characteristics ARE OPTIONAL for open blocks, and may be used as appropriate for
connections to standard, alternate, and generic blocks. Open blocks ARE REQUIRED
to NOT interfere with the characteristics of standard, alternate, and generic
blocks which are defined in the User Layer Technical Report.
OPEN BLOCK PARAMETERS:

These parameters support block characteristics which are required for open
blocks.
Static Database:
- MFG_SUBTYPE: Manufacturer's block subtype Required 16-bit integer
This is the manufacturer's subtype code for the generic
block algorithm code. It is set to a manufacturer- and
function-specific value by the manufacturer. A value of
Zero (0) will be interpreted as a "Null".
- USER_SUBTYPE: User's block subtype Required 16-bit integer

This is the user's subtype code for the generic block
algorithm code. It's value is initialized by the
manufacturer to Zero (0), which is interpreted as a "Null",
and may be changed by the user.
STANDARD BLOCK PARAMETERS:
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Explanations for parameters which are defined for Standard Blocks, and which
support functions described above as required or optional for Open Blocks, are
defined in the Process Control User Layer Technical Report section titled "Array
of Standard Block Parameters".
GENERIC BLOCK PARAMETERS:

Explanations for parameters which are defined for Generic Blocks, and which
support functions described above as required or optional for Open Blocks, are
defined in the Process Control User Layer Technical Report section titled
"Interoperable Generic Blocks".
SP-50 User Layer Technical Report Interoperable Generic Blocks

--```,``-`-`,,`,,`,`,,`---

472
Generic Block
Interoperable Generic Block

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

INTEROPERABLE GENERIC BLOCK PARAMETERS
Static Database
Access-Controlled Database
Dynamic Database
Table 1 - PV_BUILD and PV_REFRESH Display Sets for Generic Blocks
Table 2 - TAG_BUILD and TAG_REFRESH Display Sets for Gen. Blocks
Table 3 - OPTIONS Parameter Bit Assignments
Table 4 - EXTEND Parameter Bit Assignments
Table 5 - Data Type Encoding for Generic Block "Type" Parameters
The following block characteristics apply to generic blocks which are
interoperable with standard, alternate, or other interoperable generic blocks:
- The specifics of the algorithm and algorithm options of interoperable
blocks are defined by the manufacturer. Rules and data for use with
standard or alternate blocks are defined by this standard.
- The standard block features which are used by interoperable blocks are
defined by the manufacturer, except as required below. If a
manufacturer chooses to incorporate certain standard block features in a
particular interoperable block, those features shall operate as
described in the Process Control User Layer Technical Report.
- The number of input and outputs, their data types, and whether or not
they have status byes and/or off logical node agents, are specified by
the manufacturer.
- The number of extension parameters, and their data types, are specified
by the manufacturer.
- The number of mode-dependent parameters, and their data types, are
specified by the manufacturer.
NODE FEATURES:
which are interoperable with standard, alternate, or other interoperable generic
blocks:
- Interoperable blocks operate in a logical node and are identified by a
standard tag identifier. The logical node may be any type, as required
by the function of the block as determined by the manufacturer.
- Logical nodes supporting interoperable blocks support the Data Base
SP-50 User Layer Technical Report Interoperable Generic Blocks

--```,``-`-`,,`,,`,`,,`---

473
Write Service for standard parameters. This includes providing default

status bytes as required by the functions of the interoperable blocks as
determined by the manufacturer.
- Logical nodes supporting interoperable blocks support the Failsafe
Function specified for nodes with standard blocks.
- Logical nodes supporting interoperable blocks support the Start and
Restart logic specified for nodes with standard blocks.
The following characteristics ARE CONDITIONALLY REQUIRED, as described below, for

nodes supporting generic blocks which are interoperable with standard, alternate,
or other generic blocks:
- Logical nodes supporting only interoperable blocks may optionally

support the logical node variables (per Data Owner Structure - Logical
Nodes), if appropriate for the interoperable blocks' functions as
determined by the manufacturer. These registers are required, if bit
pointers are supported (see "Standard Block Features" below).
- Physical and logical nodes supporting only interoperable blocks may
optionally support the Alert Function as specified for standard blocks.
The Alert Function is required, if the PV Function is supported by a
interoperable block in the node (see "Standard Block Features" below).

User Layer Technical Report, ARE OPTIONAL for nodes supporting only generic
blocks. These characteristics ARE REQUIRED for nodes supporting BOTH standard
and generic blocks.

The following characteristics ARE REQUIRED for generic blocks which are
interoperable with standard, alternate, or other generic blocks:
- Block Tag Interoperable blocks shall use the Block Tag
method of identification and addressing, as do all
other blocks on field bus.
- Modes: Interoperable blocks shall support the standard
mode structure. This includes the Attribute and
Tattle Bytes. O/S mode is required; all other
modes may be used as appropriate for the block's
function as determined by the manufacturer.
- Cascade Structure: Interoperable blocks, which can be used in
initializable cascades with standard, alternate,
or other interoperable blocks, shall be consistent
with the standard cascade structure, as
appropriate for the block's function as determined
- Agents: Interoperable blocks which require the capability
of off-logical-node access for inputs and/or
outputs shall at least do so using agents. Other
means of parameter access via field bus which are
used by an interoperable generic block shall not
interfere with the Agents of other blocks on the
bus.
- Status Bytes: Status bytes ARE required for inputs and outputs
with agents. Status bytes ARE NOT required for
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
extension and tuning parameters.

- Output Revision Nos: Interoperable blocks which operate in a node with
Cycle/Phase or Unscheduled timing shall support
revision numbers for outputs.
- Static Database The Static Database Revision Counter is required.
Revision Counter:
--```,``-`-`,,`,,`,`,,`---
- Option Indicator: The OPTION and EXTEND parameters are required.

- Algorithm Number: The Algorithm Number is required. In addition,
Generic Blocks have a parameter for a
manufacturer-specific secondary algorithm number
SP-50 User Layer Technical Report Interworking Generic Blocks

474
(MFG_SUBTYPE). A corresponding USER_SUBTYPE

parameter is also required.
The following standard block characteristics ARE CONDITIONALLY REQUIRED, as

described below, for generic blocks which are interoperable with standard,
alternate, or other generic blocks:
- The PV Parameter is required, if the optional PV Function is provided.
If the optional PV Parameter is provided without the optional PV
Function, then the PV parameter will contain the value of a generic
block parameter specified by the manufacturer.
- The PV pointer and the PV_Build & PV_Refresh display sets are required,
if the optional PV function is supported.
- One autoformat parameter is required for an interoperable generic block,
if the autoformat option is supported.
Other characteristics of standard blocks, as described in the User Layer

Technical Report, ARE OPTIONAL for generic blocks which are interoperable with
standard, alternate, or other generic blocks.
Note that the optional PV_BUILD, PV_REFRESH, TAG_BUILD and TAG_REFRESH parameters
have required additions to meet the needs of generic blocks. These are specified
in Tables 1 and 2.
INTEROPERABLE GENERIC BLOCK PARAMETERS:

These parameters support block characteristics which are required or optional for
interoperable blocks.
Static Database:
- MFG_SUBTYPE: Manufacturer's block subtype Required 16-bit integer

This is the manufacturer's subtype code for the generic
block algorithm code. It is set to a manufacturer- and
function-specific value by the manufacturer. A value of
Zero (0) will be interpreted as a "Null".
- USER_SUBTYPE: User's block subtype Required 16-bit integer

This is the user's subtype code for the generic block
algorithm code. It's value is initialized by the
manufacturer to Zero (0), which is interpreted as a
"Null", and may be changed by the user.
- OPTIONS: Option Indicator Required 80-bit string

This standard block parameter indicates which options are
implemented for this generic block, one bit per option,
bit set means the option is provided. The individual bit
assignments for generic blocks are listed in Table 3.
- EXTEND: Parameters Indicator Required 80-bit string

This standard block parameter indicates which parameters
are implemented for this generic block, one bit per
parameter, bit set means the parameter is provided. The
individual bit assignments for generic blocks are listed
in Table 4.
- PV_BUILD: PV Display Build Set Optional per Table 1

The contents and structure of the PV_BUILD display set for
generic blocks are described in Table 1.
- TAG_BUILD: Tag Display Build Set Optional per Table 2

The contents and structure of the TAG_BUILD display set
for generic blocks are described in Table 2.
- IN_TYPEx: Input data type Required 8 bit string

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
475
X ranges from 0-7; one "IN_TYPEx" parameter is required

for each input used by this interoperable block (as
indicated by the "EXTEND" parameter). Data type is
encoded per Table 5.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
- IN_DISPLAYx: Input x display attribute As Applicable 8 bit string
X ranges from 0-7; one "IN_DISPLAYx" parameter is required
for each input used by this generic block (as indicated by
the "EXTEND" parameter). This parameter includes the
display attribute code as specified in the User Layer
Technical Report, "Human Interface Considerations".
- IN_UNITSx: Input parameter x units descriptor

As Applicable 12 Character
X ranges from 0-7; one "IN_UNITSx" parameter is required
for each input parameter used by this generic block (as
indicated by the "EXTEND" parameter). This parameter
includes the user-entered units descriptor. This
parameter is encoded as specified in the User Layer
Technical Report, "Human Interface Considerations, Visible
ASCII Strings". A value of all spaces (Char. 3210) will
be interpreted as a "Null".
- IN_DESCRx: Input parameter x parameter descriptor

X ranges from 0-7; one "IN_DESCRx" parameter is required
for each input parameter used by this generic block (as
includes the user-entered parameter descriptor. This
parameter is encoded as specified in the User Layer
Technical Report, "Human Interface Considerations, Visible
ASCII Strings".
- IN_LO_RANGEx: Input x Low Display Range As Applicable per IN_TYPEx

x ranges from 0-7; one "IN_LO_RANGEx" parameter is
required for each input used by this generic block (as
indicated by the "EXTEND" parameter). A value of all
spaces (Char. 3210), or all zeros (Char. 4810) will be
interpreted as a "Null".
- IN_HI_RANGEx: Input x High Display Range As Applicable per IN_TYPEx

x ranges from 0-7; one "IN_HI_RANGEx" parameter is
required for each input used by this generic block (as
--```,``-`-`,,`,,`,`,,`---
- IN_STATICx: Input x static value As Applicable per IN_TYPEx

Static value for "INPUTx", as specified in the User Layer
Technical Report, "Agents". X ranges from 0-7; one
"IN_STATICx" parameter is required for each input provided
with the agent function, as indicated by the "OPTIONS"
parameter.
- PV_TYPE: Principal Value data type Optional 8 bit string

This parameter is required if the optional PV parameter is
provided. Other requirements for this parameter is the
same as for "IN_TYPEx"
- PV_DISPLAY: Principal Value display attribute Optional 8 bit string

used by this generic block (as indicated by the "OPTIONS"
parameter). Other requirements for this parameter are the
same as for "IN_DISPLAYx".
- PV_UNITS: Principal Value units descriptor Optional 12 Character


476

parameter). This parameter includes the user-entered
units descriptor. Other requirements for these parameters
are the same as for "IN_UNITSx".
- PV_DESCR: Principal Value parameter descriptor

Optional 32 Character
parameter). This parameter includes the user-entered
parameter descriptor. Other requirements for these
parameters are the same as for "IN_DESCRx".
- PV_LO_RANGE: PV Low Display Range Optional per PV_TYPE

parameter). A value of all spaces (Char. 3210), or all
zeros (Char. 4810) will be interpreted as a "Null".
- PV_HI_RANGE: PV High Display Range Optional per PV_TYPE

parameter). A value of all spaces (Char. 3210), or all
zeros (Char. 4810) will be interpreted as a "Null".
- PV_TARGET: PV target value Optional per PV_TYPE

parameter).
- OUT_TYPEy: Output data type Required 8 bit string

Y ranges from 0-7; one "OUT_TYPEy" parameter is required
for each output used by this generic block (as indicated
by the "EXTEND" parameter). Encoding requirements for
these parameters are the same as for "IN_TYPEx"
- OUT_DISPLAYy: Output y display attribute As Applicable 8 bit string

Y ranges from 0-7; one "OUT_DISPLAYy" parameter is
required for each output used by this generic block (as
indicated by the "EXTEND" parameter). Other requirements
for this parameter are the same as for "IN_DISPLAYx".
- OUT_UNITSy: Output parameter y units descriptor

Y ranges from 0-7; one "OUT_UNITSy" parameter is required
for each output parameter used by this generic block (as
includes the user-entered units descriptor. Other
requirements for these parameters are the same as for
"IN_UNITSx".
- OUT_DESCRy: Output parameter y parameter descriptor

Y ranges from 0-7; one "OUT_DESCRy" parameter is required
for each output parameter used by this generic block (as
includes the user-entered parameter descriptor. Other
"IN_DESCRx".
- OUT_LO_RANGEy: Output y Low Display Range As Applicable per OUT_TYPEy

Y ranges from 0-7; one "OUT_LO_RANGEy" parameter is

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
477
- OUT_HI_RANGEy: Output y High Display Range As Applicable per OUT_TYPEy

Y ranges from 0-7; one "OUT_HI_RANGEy" parameter is
- OUT_LO_LIMITy: Output y Low Limit Optional per OUT_TYPEy

Y ranges from 0-7; one "OUT_LO_LIMITy" parameter is
required for each output provided with the optional output
limit function (as indicated by the "OPTIONS" parameter).
- OUT_HI_LIMITy: Output y High Limit Optional per OUT_TYPEy

Y ranges from 0-7; one "OUT_HI_LIMITy" parameter is
required for each output provided with the optional output
limit function (as specified in the OPTIONS" parameter).
- OUT_STATICy: Output y static value As Applicable per OUT_TYPEy

Static value for "OUTPUTy", as specified in the User Layer
Technical Report, "Agents". Y ranges from 0-7; one
"OUT_STATICy" parameter is required for each output
provided with the agent function, as indicated by the
"OPTIONS" parameter.
- EXT_TYPEz: Extension parameters data type Required 8 bit string
Z ranges from 0-15; one "EXT_TYPEz" parameter is required
for each extension parameter used by this generic block
(as indicated by the "EXTEND" parameter). Encoding
"IN_TYPEx"
- EXT_DISPLAYz: Extension parameter z display attribute

As Applicable 8 bit string
Z ranges from 0-15; one "EXT_DISPLAYz" parameter is
required for each extension used by this generic block (as
for these parameters are the same as for "IN_DISPLAYx".
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
- EXT_UNITSz: Extension parameter z units descriptor

Z ranges from 0-15; one "EXT_UNITSz" parameter is required
(as indicated by the "EXTEND" parameter). Other
"IN_UNITSx".
- EXT_DESCRz: Extension parameter z parameter descriptor

Z ranges from 0-15; one "EXT_DESCRz" parameter is required
(as indicated by the "EXTEND" parameter). This parameter
includes the user-entered parameter descriptor. Other
"IN_DESCRx".
- EXT_LO_RANGEz: Extension parameter z Low Display Range

As Applicable per EXT_TYPEz
Z ranges from 0-7; one "EXT_LO_RANGEz" parameter is
required for each extension parameter used by this generic
block (as indicated by the "EXTEND" parameter). A value
of all spaces (Char. 3210), or all zeros (Char. 4810)
will be interpreted as a "Null".
- EXT_HI_RANGEz: Extension parameter z High Display Range

As Applicable per EXT_TYPEz
Z ranges from 0-7; one "EXT_HI_RANGEz" parameter is

--```,``-`-`,,`,,`,`,,`---

478

--```,``-`-`,,`,,`,`,,`---
- TUNE_TYPEw: Tuning parameters data type Required 8 bit string

W ranges from 0-15; one "TUNE_TYPEw" parameter is required
for each tuning parameter used by this generic block (as
indicated by the "EXTEND" parameter). Encoding
"IN_TYPEx".
- TUNE_DISPLAYw:Tuning parameter w display attribute

As Applicable 8 bit string
W ranges from 0-15; one "TUNE_DISPLAYw" parameter is
required for each extension used by this generic block (as
for this parameter are the same as for "IN_DISPLAYx".
- TUNE_UNITSw: Tuning parameter w units descriptor

W ranges from 0-15; one "TUNE_UNITSz" parameter is
block (as indicated by the "EXTEND" parameter). Other
"IN_UNITSx".
- TUNE_DESCRw: Tuning parameter w parameter descriptor

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
W ranges from 0-15; one "TUNE_DESCRw" parameter is
block (as indicated by the "EXTEND" parameter). This
parameter includes the user-entered parameter descriptor.
Other requirements for these parameters are the same as
for "IN_DESCRx".
- TUNE_LO_RANGEw Tuning w Low Display Range As Applicable per TUNE_TYPEw

w ranges from 0-7; one "TUNE_LO_RANGEw" parameter is
required for each tuning parameter used by this generic
- TUNE_HI_RANGEw:Tuning w High Display Range As Applicable per TUNE_TYPEw

w ranges from 0-7; one "TUNE_HI_RANGEw" parameter is
required for each tuning parameter used by this generic
Access-Controlled Database:
Parameters in the "access-controlled" portion of a block database are changeable
via field bus, but only with the block in modes specified by the manufacturer.
Access-controlled parameters must at least be changeable with the block in
"Out-of-Service" (O/S) mode.
- IN_AGENT_TYPEx Input x agent type As Applicable 8 bit integer

Agent type for "INPUTx", as specified in the User Layer
Technical Report, "Agents". X ranges from 0-7; one
"IN_AGENT_TYPEx" parameter is required for each input
"OPTIONS" parameter. This parameter may be changed only
with the block in "O/S" mode.
- IN_TAGx: Input x agent pointer tag As Applicable 16 Character

479
Agent pointer tag for "INPUTx" agent, as specified in the

User Layer Technical Report, "Agents". X ranges from 0-7;
one "IN_TAGx" parameter is required for each input
--```,``-`-`,,`,,`,`,,`---
- IN_PARx: Input x agent pointer parameter As Applicable Integer

Agent pointer parameter for "INPUTx" agent, as specified
in the User Layer Technical Report, "Agents". X ranges
from 0-7; one "IN_PARx" parameter is required for each
input provided with the agent function, as indicated by
the "OPTIONS" parameter. This parameter may be changed
only with the block in "O/S" mode.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
- OUT_AGENT_TYPEy:Output y agent type As Applicable 8 bit integer
Agent type for "OUTPUTy", as specified in the User Layer
Technical Report, "Agents". Y ranges from 0-7; one
"OUT_AGENT_TYPEy" parameter is required for each output
- OUT_TAGy: Output y agent pointer tag As Applicable 16 Character

Agent pointer tag for "OUTPUTy" agent, as specified in the
User Layer Technical Report, "Agents". Y ranges from 0-7;
one "OUT_TAGy" parameter is required for each output
- OUT_PARy: Output y agent pointer parameter As Applicable Integer

Agent pointer parameter for "OUTPUTy" agent, as specified
in the User Layer Technical Report, "Agents". Y ranges
from 0-7; one "OUT_PARy" parameter is required for each
output provided with the agent function, as indicated by
the "OPTIONS" parameter. This parameter may be changed
only with the block in "O/S" mode.
- TUNEw: Tuning parameter w As Applicable per TUNE_TYPEw

W ranges from 0-15; one "TUNEw" parameter is required for
each extension parameter used by this generic block (as
indicated by the "EXTEND" parameter). Data type is as
indicated by parameter "TUNE_TYPEw". The manufacturer
specifies the block modes under which these parameters may
be changed, but they must at least be changeable with the
block in "Out-of-Service" (O/S) mode.
- AUTOFORMAT: Autoformatted variable Optional 128 bytes

This is the optional autoformat parameter, as specified in
the User Layer Technical Report, "Human Interface
Considerations, Attachment 1". It's use is indicated in
the "EXTEND" parameter.
Dynamic Database:
- PV_REFRESH: PV Display Refresh Set Optional per Table 1
The contents and structure of the PV_REFRESH display set
are described in Table 1.
- TAG_REFRESH: Tag Display Refresh Set Optional per Table 2

The contents and structure of the TAG_REFRESH display set
are described in Table 2.
- INPUTx: Input x parameter As Applicable per IN_TYPEx

480
X ranges from 0-7; one "INPUTx" parameter is required for

each input used by this generic block (as indicated by the
"EXTEND" parameter). Data type is as indicated by
parameter "IN_TYPEx".
- IN_STATUSx: Input x status byte As Applicable 8 bit string

X ranges from 0-7; either one "IN_STATUSx" parameter or one
"IN_EXT_STATx" parameter is required for each input used by
this generic block (as indicated by the "EXTEND"
parameter). For parameters with bit string data types (as
indicated by "IN_TYPEx"), this parameter is the "condensed"
status byte.
- IN_EXT_STATx: Input x bit status bytes As Applicable per description

X ranges from 0-7; either one "IN_STATUSx" parameter or one
"IN_EXT_STATx" parameter is required for each input with an
optional extended status byte (as indicated by the "EXTEND"
parameter). For parameters with a bit string data type (as
indicated by "IN_TYPEx"), this parameter is the "status
byte per bit", starting with the status for bit 0. The
data type is a bit string which is 8 times the length of
"INPUTx" (which in turn is indicated by "IN_TYPEx").
- IN_BOTHx: Input x parameter + status As Applicable per description

X ranges from 0-7; one "IN_BOTHx" parameter is required
for each input used by this generic block (as indicated by
the "EXTEND" parameter). This parameter includes the
concatenation of both INPUTx and IN_STATUSx.
- IN_BOTH_EXTx: Input x parameter + extended status

As Applicable per description
X ranges from 0-7; one "IN_BOTH_EXTx" parameter is
required for each input with an optional extended status
byte (as indicated by the "EXTEND" parameter). This
parameter includes the concatenation of both INPUTx and
IN_EXT_STATx.
- IN_NOCOMx: Input x NOCOM counter As Applicable 2-bit string

NOCOM counter for "INPUTx" agent, as specified in the User
Layer Technical Report, "Agents". X ranges from 0-7; one
"IN_NOCOMx" parameter is required for each input provided
with the agent function, as displayed in the "OPTIONS"
parameter.
- PV: Principal Value parameter Optional per PV_TYPE

The source of the optional PV parameter is determined by
the manufacturer, or via the optional PV Function PV
pointer. PV data type is as indicated by parameter
"PV_TYPE".
- PV_STATUS: PV status byte Optional 8 bit string

provided. This parameter is the special "PV Status" byte,
as specified in the User Layer Technical Report, "Standard
Block Functions".
- OUTPUTy: Output y parameter As Applicable per OUT_TYPEy

Y ranges from 0-7; one "OUTPUTy" parameter is required for
each output used by this generic block (as indicated by
the "EXTEND" parameter). Outputs should be numbered
sequentially, beginning with 0. Data type is as indicated
by parameter "OUT_TYPEy".
- OUT_STATUSy: Output y status byte As Applicable 8 bit string

Y ranges from 0-7; either one "OUT_STATUSy" parameter or
one "OUT_EXT_STATy" parameter is required for each output
used by this generic block (as indicated by the "EXTEND"

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
481
parameter). For parameters with a bit string data type

(specified in "OUT_TYPEy"), this parameter is the
"condensed" status byte.
- OUT_EXT_STATy: Output y bit status bytes As Applicable per description

Y ranges from 0-7; either one "OUT_STATUSy" parameter or
one "OUT_EXT_STATy" parameter is required for each output
used by this generic block (as indicated by the "EXTEND"
parameter). For parameters with a bit string data type (as
indicated by "OUT_TYPEy"), this parameter is the "status
byte per bit", starting with the status for bit 0. The
data type is a bit string which is 8 times the length of
"OUTPUTy" (which in turn is indicated by "OUT_TYPEy").
- OUT_BOTHy: Output y parameter + status

Y ranges from 0-7; one "OUT_BOTHy" parameter is required
for each output used by this generic block (as indicated
by the "EXTEND" parameter). This parameter includes the
concatenation of both OUTPUTy and OUT_STATUSy.
- OUT_BOTH_EXTy: Output y parameter + extended status

--```,``-`-`,,`,,`,`,,`---
Y ranges from 0-7; one "OUT_BOTH_EXTy" parameter is

required for each output with an optional extended status
byte (as indicated by the "EXTEND" parameter). This
parameter includes the concatenation of both OUTPUTy and
OUT_EXT_STATy.
- OUT_NOCOMy: Output y NOCOM counter As Applicable 2-bit string

NOCOM counter for "OUTPUTy" agent, as specified in the
User Layer Technical Report, "Agents". Y ranges from 0-7;
one "OUT_NOCOMy" parameter is required for each output
provided with the agent function, as displayed in the
"OPTIONS" parameter.
- OUT_REVy: Output y revision no. As Applicable 8-bit string

Revision number for "OUTPUTy", as specified in the User
Layer Technical Report, "Agents". Y ranges from 0-7; one
"OUT_REVy" parameter is required for each output which is
used by the block, as displayed in the "EXTEND" parameter,
in a node with Cycle/Phase or Unscheduled timing.
- EXTz: Extension parameter z As Applicable per EXT_TYPEz

Z ranges from 0-15; one "EXTz" parameter is required for
each extension parameter used by this generic block (as
indicated by the "EXTEND" parameter). Data type is as
indicated by parameter "EXT_TYPEz".

Generic blocks allow for up to 8 optional bit pointers, and up to 8
optional boolean operators (indicated in the "OPTIONS" parameter).
Parameters to support bit pointers and boolean operators are as specified in the
User Layer Technical Report, "Standard Block Functions".
Generic blocks require additional features in order to use the optional PV

Parameter and the display sets for standard blocks. These additions are
described above, under "Generic Block Parameters". Other aspects of the
optional PV Parameter, PV Functions, and display sets are as specified in the
User Layer Technical Report, "Standard Block Functions" and "Human Interface
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Considerations".

482
--```,``-`-`,,`,,`,`,,`---
Manufacturers may optionally provide one autoformatted parameter, AUTOFORMAT.

If autoformatting is supported, the option must be indicated in the "EXTEND"
parameter. Implementation of the autoformat parameter is as specified in the
User Layer Technical Report, "Human Interface Considerations, Attachment 1".
If the autoformat parameter is writeable via the field bus, then it must
be access-controlled (access modes determined by the manufacturer), and at
least changeable in O/S.
All other parameters which support functions described above as required or

optional for Interoperable Generic Blocks, and which are defined for
Standard Blocks, are listed in the User Layer Technical Report section titled
"Array of Standard Block Parameters".
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

483
IOWG Table 1 PV_Build, PV_Refresh, Display Sets for

Generic Blocks
The optional PV_Build & PV_Refresh display sets are defined as follows for
generic blocks:
PV_BUILD The PV_BUILD display set includes these parameters in order:

10 bytes OPTIONS
10 bytes EXTEND
12 bytes PV_UNITS
32 bytes PV_DESCR
1 byte PV_TYPE
2 bytes PV display (standard parameter)
12 bytes OUT_UNITS0,
32 bytes OUT_DESCR0
1 byte OUT_TYPE0,
PV_REFRESH The PV_REFRESH display set includes these parameters in order:

3 bytes mode, attributes, and tattle bytes
(standard parameters)
1-8 bytes PV - note 2
1-8 bytes PV_TARGET - notes 2 & 3
1 byte PV_STATUS
1-8 bytes PV_LO_RANGE - note 2
1-8 bytes PV_HI_RANGE - note 2
1-8 bytes OUTPUT0 - note 2
1 byte OUT_STATUS0 - note 1
1-128 bytes OUT_EXT_STAT0 - note 1 & 2
1-8 bytes OUT_LO_RANGE0 - note 2
1-8 bytes OUT_HI_RANGE0 - note 2
1-8 bytes OUT_LO_LIMIT0 - notes 1 & 2
1-8 bytes OUT_HI_LIMIT0 - notes 1 & 2
Notes:
1. The presence of the optional parameters must be determined by the
higher-level device, based on the contents of the OPTIONS and EXTEND
parameters contained in the PV_BUILD display set.
2. The byte counts for parameters associated with PV and Output must be
determined by the higher-level device, based on the contents of the
PV_TYPE and OUT_TYPE0 parameters contained in the PV_BUILD display
set.
3. PV_TARGET has the same range, units, and data type as PV.
4. PV_BUILD is likely to be longer than 128 bytes for most generic
blocks, depending on the data type of PV, PV_TARGET, and OUTPUT0.
PV_REFRESH will be less than 128 bytes for all of the data types
listed in Table 5 , if extended status bytes are not used.
5. The PV_BUILD and PV_REFRESH data sets include the character <RS>
(char. 30 base 10) at the end of the display set.

--```,``-`-`,,`,,`,`,,`---

//^:^
484
--```,``-`-`,,`,,`,`,,`---
IOWG Table 2 Tag_Build and Tag_Refresh display sets

for Generic Blocks
The optional Tag_Build & Tag_Refresh display sets are defined as follows for
generic blocks:
TAG_BUILD The TAG_BUILD display set is built up as follows:

The Tag Build Header segment, which includes:
10 byte OPTIONS
10 byte Includes string - note 3
2 byte User Display - standard parameter
The Inputs Build segment, which includes
(for each input bit set in the Includes string):
1 byte Input Type
32 bytes Input Description
12 bytes Input Units
The Outputs Build segment, which includes
(for each output bit set in the Includes string):
1 byte Output Type
32 bytes Output Description
12 bytes Output Units
The Extensions Build segment, which includes
(for each extensions bit set in the Includes string):
1 byte Extension Type
32 bytes Extension Description
12 bytes Extension Units
The Tuning Build segment, which includes
(for each tuning bit set in the Includes string):
1 byte Tuning Type
32 bytes Tuning Description
12 bytes Tuning Units
TAG_REFRESH The TAG_REFRESH display set is built up as follows:

The Tag Refresh Header segment, which includes:
10 byte OPTIONS
10 byte Includes string - note 3
3 byte std.mode bytes - standard mode, attribute
& tattle parameters
The Inputs Refresh segment, which includes
(for each input bit set in the Includes bytes):
1-8 bytes Input Low Range - notes 1 & 2
1-8 bytes Input Hi Range - notes 1 & 2
1-8 bytes Input Value - note 2
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
1 byte Input Status - note 1
1-128 bytes Input Extended Status - notes 1 & 2
The Outputs Refresh segment, which includes
(for each output bit set in the Includes byte):
1-8 bytes Output Low Range - notes 1 & 2
1-8 bytes Output Hi Range - notes 1 & 2
1-8 bytes Output Low Limit - notes 1 & 2
1-8 bytes Output Hi Limit - notes 1 & 2
1-8 bytes Output Value - note 2
1 byte Output Status - note 1
1-128 bytes Output Extended Status - notes 1 & 2
The Extensions Refresh segment, which includes
(for each extensions bit set in the Includes byte):
1-8 bytes Extension Low Range - notes 1 & 2
1-8 bytes Extension Hi Range - notes 1 & 2
1-8 bytes Extension Value - note 2
The Tuning Refresh segment, which includes
(for each tuning bit set in the Includes byte):
1-8 bytes Tuning Low Range - notes 1 & 2
1-8 bytes Tuning Hi Range - notes 1 & 2
1-8 bytes Tuning Value - note 2

485
Notes:
1. The presence of the optional parameters must be determined by the
higher-level device, based on the contents of the OPTIONS parameter
and the Includes string.
2. The byte counts for parameters whose data type is specified by the
field device manufacturer must be determined by the higher-level
device, based on the contents of the associated "Type" parameters
contained in the TAG_BUILD display set.
3. The Includes string has the same structure as the EXTEND parameter,
but with bits set only for those parameters which are included in the
tag display set.
4. TAG_BUILD and TAG_REFRESH may be longer than 128 bytes, depending on
the number and data types of parameters included in the display set
5. The TAG_BUILD and TAG_REFRESH data sets also include the following
delimiter characters:
<RS> (char. 30 base 10) at the end of each parameter
(except the last of a segment)
<GS> (char. 29 base 10) at the end of each segment (except
the last segment)
<FS> (char. 28 base 10) at the end of the display set.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

--```,``-`-`,,`,,`,`,,`---
Interworking Generic Blocks

486
IOWG Table 3 Options Parameter Bit Assignments

WORD BITS OPTION
0 0 Mode Functions (required, and therefore always
set, for interoperable generic blocks)
1-3 Cascade Structure (bits indicate that CAS, RCAS,
and ROUT transfer locations, respectively, are
supported)
4 PV Parameter supported
5 PV Functions supported
6 Setpoint Limit Function supported
7 Setpoint Ramp Function supported
8 Bypass Function supported
9 Tag Build and Display Sets supported
A Autoformatting supported
B-F Reserved for future Field Bus use
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
1 0-7 inputs 0-7 have agents

1 8-F outputs 0-7 have agents
2 0-7 inputs 0-7 have hardware pointers

2 8-F outputs 0-7 have hardware pointers
3 0-7 Reserved for future Field Bus use

3 8-F outputs 0-7 have output limits
4 0-7 bit pointers 0-7 used

4 8-F Boolean Operators 0-7 used
--```,``-`-`,,`,,`,`,,`---

487
IOWG Table 4 Extend Parameter Bit Assignment
WORD BITS OPTION
0 0-7 inputs 0-7 used

0 8-F outputs 0-7 used
1 0-7 inputs 0-7 have status bytes

1 8-F outputs 0-7 have status bytes
2 0-7 inputs 0-7 have extended status bytes

2 8-F outputs 0-7 have extended status bytes
3 0-F extension parameters 0-15 used
4 0-F tuning parameters 0-15 used
--```,``-`-`,,`,,`,`,,`---
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
488
IOWG Table 5 Data type Encoding for generic "Type"

Parameters
bit -> 7 6 5 4 3 2 1 0
data type
bit string - 1 bit 0 0 0 0 0 0 0 1 note 1
bit string - 8 bit 0 0 0 0 0 0 1 1
bit string - 16 bit 0 0 0 0 0 1 1 1
bit string - 32 bit 0 0 0 0 1 1 1 1
integer - 8 bit 0 0 1 0 0 0 1 1 note 2

integer - 16 bit 0 0 1 0 0 1 1 1
integer - 32 bit 0 0 1 0 1 1 1 1
float - 32 bit 0 1 0 0 1 1 1 1
float - 64 bit 0 1 0 1 1 1 1 1
BCD - 8 byte 0 1 1 1 1 1 1 1 note 3
relative time - 32 bit 1 0 1 0 1 1 1 1 note 4

universal time - 44 bit 1 0 1 1 0 1 0 1 note 5
--```,``-`-`,,`,,`,`,,`---
Octet string - 8 byte 1 0 0 1 1 1 1 1
Character string - 16 byte 1 1 1 0 0 1 1 1 note 6

Character string - 32 byte 1 1 1 0 1 1 1 1 note 6
Notes:
1. 1-bit string encoded as bit 0 (low order) of an octet, all unused
bits reset.
2. Enumerated states are represented by an 8-bit integer.
3. Two BCD digits per byte. Bytes 7-4 represent digits to the left of
the decimal, bytes 3-0 represent digits to the right of the decimal.
4. Time format is milliseconds from field device restart (49.7 days
maximum).
5. Time format is milliseconds from January 1, 1970, 00:00 am,
International Standard Time. The high-order bit (bit 43) is not used
(reset = 0).
6. Characterts are interpreted as defined in the User Layer Technical
Report, "Human Interface Considerations", Tables 9-12.
7. All other possible codes are reserved for future use by the Field Bus
standard.

489
Interworking Generic Block

INTERWORKABLE GENERIC BLOCK PARAMETERS
The following block characteristics apply to generic-type blocks which are
interworkable with standard, alternate, or other generic blocks:
- The specifics of the algorithm and algorithm options of interworkable
blocks are defined by the manufacturer. Rules and data for
interworkability with standard or alternate blocks are defined by this
standard.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
- The standard block features which are used by interworkable blocks are
defined by the manufacturer, except as required below. If a
manufacturer chooses to incorporate certain standard block features in a
particular interworkable block, those features shall operate as
described in the User Layer Technical Report.
- The number of input and outputs and their data types, and whether or not
they have off logical node agents, are specified by the manufacturer.
- The number of extension parameters, and their data types, are specified
- The number of mode-dependent parameters, and their data types, are
specified by the manufacturer.
NODE FEATURES:
which are interworkable with standard, alternate, or other generic blocks:
- Interworkable blocks operate in a logical node and are identified by a
standard tag identifier. The logical node may use any type of block
scheduling scheme, as required by the function of the block as
determined by the manufacturer.
The following characteristics ARE CONDITIONALLY REQUIRED, as described below, for

nodes supporting generic-type blocks which are interworkable with standard,
alternate, or other generic blocks:
- Logical nodes supporting only interworkable blocks may optionally
support the Data Base Write Service for standard parameters. Support of
Data Base Write Service is required, if Agents, as described below, are
supported. This includes providing default status bytes as required by
the functions of the interworkable blocks as determined by the
manufacturer.
- Logical nodes supporting only interworkable blocks may optionally
support the logical node variables (per Data Owner Structure - Logical
Nodes), if appropriate for the interworkable blocks' functions as
determined by the manufacturer. These registers are required, if bit
pointers are supported (see "Standard Block Features" below).

--```,``-`-`,,`,,`,`,,`---

--```,``-`-`,,`,,`,`,,`---
490
- Physical and logical nodes supporting only interworkable blocks may

optionally support the Alert Function as specified for standard blocks.
The Alert Function is required, if the PV Function is supported by a
interworkable block in the node (see "Standard Block Features" below).

User Layer Technical Report, ARE OPTIONAL for nodes supporting only generic
blocks. These characteristics ARE REQUIRED for nodes supporting BOTH standard
and generic blocks.

The following characteristics ARE REQUIRED for interworkable generic blocks:
- Block Tag Interworkable blocks are required to use the Block
Tag method of identification and addressing, as are
all other blocks on field bus.
- Agents: Agents are optional for inputs or outputs. Other
means of parameter access via field bus which are
used by an interworkable generic block shall not
interfere with the Agents of other blocks on the bus.
- Status Bytes: Status bytes are required for outputs
with agents. Status bytes are not required for
inputs, outputs without agents, or extension and
tuning parameters.
- Option Indicator: The OPTION and EXTEND parameters are required.
- Algorithm Number: The Algorithm Number is required. In addition,
Generic Blocks shall have a parameter for a
manufacturer-specific secondary algorithm number
(MFG_SUBTYPE). If the manufacturer does not support
secondary algorithm numbers, this parameter shall
contain a zero (0), which can be interpreted as a
"null" on field bus. A corresponding USER_SUBTYPE
parameter is required.
The following standard block characteristics ARE CONDITIONALLY REQUIRED, as

described below, for interworkable generic blocks:
- The PV Parameter is required, if the optional PV Function is provided.
If the optional PV Parameter is provided without the optional PV
Function, then the PV parameter will contain the value of a generic
block parameter specified by the manufacturer.
- The PV pointer and the PV_Build & PV_Refresh display sets are required,
if the optional PV function is supported. These display sets are as
defined as for interoperable generic blocks.
- The optional PV_Build, PV_Refresh, Tag_Build and Tag_Refresh display
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
sets, if supported for a particular interworkable generic block, are as
defined for interoperable generic blocks.
- One autoformat parameter is required for an interworkable generic block,
if the autoformat option is supported.
Other characteristics of standard blocks, as described in the User Layer

Technical Report, ARE OPTIONAL for generic blocks which are interoperable with
standard, alternate, or other generic blocks.
INTERWORKABLE GENERIC BLOCK PARAMETERS:

The parameters which are required for Interoperable Generic Blocks are also
required for Interworkable Generic Blocks, except for the parameters associated
with the use of Input and Output agents. The parameters which are required for
Interoperable Generic Blocks but are optional for Interworkable Generic Blocks
are as follows:
SP-50 User Layer Technical Report Standard Blocks 490

--```,``-`-`,,`,,`,`,,`---
491
- IN_AGENT_TYPEx: Input x agent type

- IN_STATICx: Input x static value
- IN_TAGx: Input x agent pointer tag
- IN_PARx: Input x agent pointer parameter
- IN_NOCOMx: Input x NOCOM counter
- OUT_AGENT_TYPEy: Ouput y agent type
- OUT_STATICy: Ouput y static value
- OUT_TAGy: Ouput y agent pointer tag
- OUT_PARy: Ouput y agent pointer parameter
- OUT_NOCOMy: Output y NOCOM counter
- OUT_REVy: Output y revision no.
The other parameters which are optional for Interoperable Generic Blocks are also
optional for Interworkable Generic Blocks.

The optional PV parameter, the optional PV_Build, PV_Refresh, Tag_Build and
Tag_Refresh display sets, and the optional bit pointers and boolean operators, if
supported for a particular interworkable generic block, are as defined for
interoperable generic blocks. Also, autoformatting for interworkable generic
blocks follow the same the requirements as for interoperable generic blocks.
All other parameters which support functions described above as required or

optional for interworkable generic blocks, and which are defined for Standard
Blocks, are listed in the User Layer Technical Report section titled "Array of
Standard Block Parameters".
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

492
Alternate and Standard Blocks:

--```,``-`-`,,`,,`,`,,`---
Standard Function Block Functions
In order to simplify the definitions of the individual block types, certain

standard functions have been arranged into a group called "Standard Block
Functions". Each standard block type definition includes a table that defines
the application of each of the standard functions to that block type. For
example, one of the functions is the mode structure. A particular block type may
not need one of the modes. Therefore, the table in that block's definition would
simply indicate that that mode is not applicable. All of the other mode details
are included by reference to the definition of the general mode structure.
In addition, certain block features were found to be "common" to many of the

algorithms. These features were generalized and are included in the list of
standard block functions. An example would be "bit pointers".
This paper explains the notation used for general architecture functions that
are detailed in other papers and explains in detail the "common" block functions:
+ General:
EXPONENTIAL FILTERS
TIME CRITICAL OPTION BIT STRING
MINIMUM OPTION INDICATOR
USER OPTION BIT STRING
USER OPTION INTEGER
HANDLING OF NaN, BAD, AND NOT-FROM-PROCESS
Default Values
Block Operation to Compliment Default Handling
Not-from-Process Status
+ Standard Block Functions:
1 - MODE
2 - HARDWARE AGENTS
3 - BIT POINTERS
4 - CASCADE STRUCTURE
Analog Blocks
Discrete blocks
5 - BY-PASS
6 - SET POINT LIMITS
7 - SETPOINT RAMP
8 - OUTPUT LIMITS
9 - PV POINTER
10 - BOOLEAN OPERATOR
+ GENERAL:
EXPONENTIAL FILTERS:
Many Standard algorithms call for a first order exponential filter. A direct
implementation of such a filter would require mathematical support that would
probably not be otherwise needed in the Field devices. In fact, most control
systems approximate the exponential calculation with a factorial expansion.
In all Standard Field Bus algorithms, therefore, the factorial expansion will
be DEFINED as being the correct solution of the exponential filter calculation
and the exact solution will, by DEFINITION, BE WRONG!

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
493
The first order exponential filter applied to the measurement "X" to produce
the filtered value "Y" will be calculated according to the following equation and
logic:
IF this is the first cycle after being in O/S mode, then
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Y = Xn
where Xn = linearized, unfiltered measured value at
cycle (n)
ELSE
Y = P * Yn-1 + (1-P) * Xn
where Y = linearized, filtered value at cycle (n)
P = filter constant
Yn-1 = filtered value at cycle (n-1)
P is nominally equal to e**(-T/TF)

where T = cycle time
TF = filter time constant
By definition of the first order filter in Field Bus:

e**x = 1 + x
Therefore,
P = 1 - T/TF
IF P<0, then
P=0
--```,``-`-`,,`,,`,`,,`---
TIME CRITICAL OPTION BIT STRING

Each algorithm will be defined with a base required level of functionality
plus one or more manufacturer's options. The data base for the function block
will include a 16 bit string - read only - that indicates which options are
implemented.
The Standard will assign one of the defined options to each bit in the bit
string. If the bit is set, the defined option is supported. In all cases,
support of the option directly implies the existence of one or more data base
parameters. If the option is not supported, the associated parameters should not
be assumed to exist.
This bit string will be called TIME_CRIT0. In some case, there may be a
second such string, TIME_CRIT1, defined by the Standard.
The parameter's name is derived from the fact that this data is time critical
to a human interface that does not know anything about a tag but must display its
data base. In order to avoid successive accesses to the tag's data base over the
relatively slow Field Bus, this parameter will be stored in the User Layer
Support Services' Data Dictionary. Therefore, the data will be available "on the
human interface's side" of Field Bus when needed.
Refer to the paper "Application Support Services Interface", page 9, items 8

and 9 for a example of how this data is stored in the Data Dictionary.
MINIMUM OPTION INDICATOR:

In many of the Standard algorithms, there is a great functional difference
between implementations with the minimum requirements of the algorithm and one
that implements all of the options. In many cases, the user will be critically
dependent on one or more of the options. When a particular field device is
replaced, it is necessary to check that the required options are present.
In order to meet this requirement, each Standard algorithm will include a

variable called MIN_TC0. It is defined to have exactly the same format and bit
SP-50 User Layer Technical Report Null Block

494
assignments as TIME_CRIT0. The algorithm does not use MIN_TC0 in any way: it
simply retains it in the static data base.
The intent is that the user will set the bits in MIN_TC0 that correspond to
manufacturer's options that are necessary for a particular application. When a
higher level device is restoring the static data base to a Field device, it can
read the TIME_CRIT0 from the device and compare it to MIN_TC0. If there are bits
RESET in TIME_CRIT0 that are SET in MIN_TC0, the Field device is not satisfactory
for the service and an alarm should be issued by the higher level device.
In those cases where there is a TIME_CRIT1, there will be a MIN_TC1.
USER OPTION BIT STRING:

Each algorithm will be defined to have one or more User's options. In order
to organize the data in the algorithms in a systematic way, a standard method has
been employed to collect the User's option selection together.
A variable called OPTIONS0 is a 16 bit, indirectly writeable binary string.

Each bit in the string is associated with a defined User's option. When the user
sets the bit, the algorithm will be configured to execute that option. In some
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
algorithms, there is a need for more than 16 bits:

OPTIONS1 is then used.
USER OPTION INTEGER:

Many algorithms require that the user specify one or more options in the form
--```,``-`-`,,`,,`,`,,`---
of an integer or enumeration variable. In all such cases, the Standard

algorithms have been designed to use one or more variables called OPTION_INTx
where "x" is a digit. In each case, the meaning of the integer will be defined
by the algorithm; in many cases, this integer could be interpreted as an
enumeration by human interfaces.
HANDLING OF NaN, BAD, AND NOT-FROM-PROCESS:

The exact handling of values that are NaN or Bad will be determined by each
algorithm. However, all of the Standard algorithms have a common design
philosophy; that philosophy will be defined here and will not generally be
restated in the individual algorithm definitions.
Any value that has a status of NaN will have a status of Bad. Any value that
has a status of Bad will be marked "Not-from-Process".
Default Values:
In general, values for parameters stored in the dynamic data
base are not known whenever a block's TO_TYPE is changed or the
device restarts after a power loss. Most static data is also
unknown whenever a block's TO_TYPE is changed and all static data
is unknown when the static data base integrity is lost. Data is
assumed to be lost in sets, not as individual items. The reader
is reminded of the discussion on page 11 of the paper "Field
Device Start and Restart" concerning the manufacturer's ability
to provide added integrity for all or part of this data and,
therefore, provide valid data under conditions that would
normally indicate that the data was lost.

495
When a set of data is unknown, the value of each parameter

in the set of unknown data will be set equal to the defined
"default" value of that parameter. The default values are given
in the lists of parameters in the papers "Array of Basic
Parameters" and "Array of Standard Block Parameters"
The algorithm TO_TYPE is known if the logical node can only

support one type of algorithm. Otherwise, the TO_TYPE defaults
to the null TO_TYPE (20H).
In general, all floating point ranges and limits default to

NaN. All tuning constants default to the "do-nothing" or "flush
through with a gain of 1" case. All user algorithm options
default to reset (off).
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Input and Output parameters and block Setpoints will default

to NaN if they are analog, else to reset. In either case, they
will be marked Bad. Likewise, the parameter "Output" in discrete
blocks will be reset and marked Bad.
Block Operation to Compliment Default Handling:

To compliment the above handling of default values, most
algorithms will obey the following rules:
- any algorithm that uses a Bad value will mark any
affected output Bad.
- any algorithm that uses a NaN value will react in a more
conservative way than its own response to a Bad value.
- ranges that are needed by the algorithm and are equal
to NaN will cause the algorithm outputs to be set to Bad.
If a range value is equal to NaN but it is not used by
the algorithm (at the moment or permanently), it will be
ignored
- range and alarm limits are ignored if they are set equal
to NaN (alarm states are trturned to reset).
- all algorithms that have a Setpoint will include the
proper responses and timing controls to handle the NaN
value and give it a chance to recover upon restart from a
power failure.
Not-from-Process Status:
--```,``-`-`,,`,,`,`,,`---
The reset Not-from-Process status can only be initiated by a
hardware input block or a higher level device. Each Field Bus
algorithm then has the task of properly handling that status and
calculating the status of its own outputs. In general, an
algorithm must have at least one input "from-Process" in order
to mark its output "from-Process". Some algorithms will require
that the "from-Process" indication must be supplied only by
certain inputs. The special agent type "immediate with status
reset" is provided to allow configured violation of these rules.
+ STANDARD BLOCK FUNCTIONS:
1 - MODE:
The mode structure has been defined in the paper "Block Modes". It consists
of a mode byte with the eight bits corresponding to the eight primary modes
possible for a functional block. The bits are defined in priority order. One
version of the mode byte, stored in the static data base, is called the
"requested mode". Field Bus writes can set one, and only one, bit in that byte.

496
Based on the requested mode and block conditions, the block algorithm generates a
second version of the mode byte, stored in the dynamic data base, called the
"actual mode". The highest priority bit set in the actual mode is the operative
mode but the lower priority bits allow the higher level nodes to interact
properly and provide valuable information for the operator interface.
The mode structure also includes four other 8-bit binary strings. The entire
mode structure is always required.
Some of the standard function block algorithms do not have an operating state
corresponding to one or more of the defined modes. Therefore, the "Standard
Block Functions" table includes an entry for "Mode" and shows the particular
modes (if any) that are not supported. Note that O/S must always be supported.
All of the above data base items will be present in a block's data base no matter
how many modes are not supported. The identification of a mode that is not
appropriate for a particular block type will result in the following conditions
for that mode:
1) Its actual mode bit will always be reset by the algorithm.
2) The corresponding mode permitted bit will always be reset.
3) The corresponding bit in the undefined byte will always be reset.
2 - HARDWARE AGENTS:
See the separate discussion of "Data Owner Structure - Hardware" for the
definitions of these hardware connections.
Some of the standard block types include hardware type agents in their
definitions. In all cases, the block type uniquely defines the type of hardware
that the block can access.
The "Standard Block Functions" table includes an entry for "Hardware Agents".
It will list "none" if that block can not access any hardware I/O. Alternately,
it will list the one type of hardware that can be accessed by that block type.
It will also indicate if the hardware agent must be used with an input or an
output word in the block.
3 - BIT POINTERS:
"Bit Pointers" are used to define the source of individual bits in the
configuration of the blocks. These pointers are significantly more limited than
the general I/O Word agents described in the "Agents" paper. All bit pointers
are restricted to being on-block or to 5 special registers in the local logical
node.
Bit pointers may be used to select the bits for the SP (if there is a SP) in
discrete blocks. They are always used to select the bits in the PV and Target
for the discrete PV Pointer function (described below); they are always used if
Boolean operators are supported (described below), and they may be used to select
the source of the bits in other parameters.
The "Standard Block Functions" table includes an entry for "Bit Pointers".
--```,``-`-`,,`,,`,`,,`---
It will list "none" if that block does not support any bit pointers.
Alternately, it will give the number of bit pointers in the block if any are
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
supported.
Most logical nodes that support blocks that include bit pointers must support
5 special registers in the data base of the logical node. See the description of
these registers in "Data Owner Structure - Logical Nodes".
The bit pointer configuration includes the parameter number of the source of
the bit but there is no provision for the source tag name since their reference

497
must be on-block (the logical node register parameter names appear as if they are
on-block because they are in the local logical node's data base). The pointer
has the ability to select one bit from the low 16 bits in the named parameter.
All bit pointers include the option to invert the state of the discrete that is
transferred.
The bit pointers are defined using one 16 bit word. The format of a bit
pointer configuration word is:
Bits 0 - 6: Parameter Number
7 - A: Bit Number
B: Invert state of bit if Set
C & D: If Bad: 00 - Null
01 - Use 0 and a generated status (see p3 of
the paper on "Status Byte")
10 - Use 1 and a generated status
11 - Keep Old with its old status but set bit 2
(not from process).
E & F: Force: 00 - Null
01 - Force to 0 and generated status
10 - Force to 1 and generated status
11 - Keep Old value but with a generated status
Bits 0 - AH define the bit to use. Bit BH of the bit pointer allows the
chosen bit to be inverted if desired. The pointer bits CH and DH define the
action to be taken if the chosen bit happens to be marked "bad". Finally, it is
sometimes necessary to force the value of the bit to a particular value, thus
disabling the action of a particular input bit. It is desirable to be able to do
this without loosing the normal configuration information. This is provided by
the "Force" option in the pointer bits EH and FH. The force option overrides the
value determined by the first 14 bits.
There are six special values for the bit pointer configuration word called
the "Detail Word (Pointer)". They are invoked by the following hex value in bits
0 - BH of that word:
1) value = 000: the bit is fixed to reset or "Off" (called the "Null"
value)
value status = the generated status
2) value = 001: the bit is fixed to reset or "Off" (called the "Null"
value)
--```,``-`-`,,`,,`,`,,`---
value status = the generated status except marked "Bad"

3) value = 002: the bit is fixed to set or "On"
4) value = 003: the bit is fixed to set or "ON"
5) value = 004: the bit value is "unknown" (see the Device Control
Block)
6) value = 005: the bit value is "unknown"
Note that the above defines bits 0 - BH. Bits BH - DH should not be used to
modify their value/status because of configuration clarity. However, bits EH and
FH can be used to override the normal configuration.
These special definitions have the result that parameters 0 through 5 can not
be addressed by bit pointers. Those five parameters are defined with that
limitation in mind.
When more than one bit pointer is necessary to define the source of a named
parameter, for example the three bit pointers for the SP, then the configuration
words for all of the bit pointers for that parameter are themselves combined
under one parameter name. The bit pointer definition word for the lowest order
bit (bit 0) is reported first.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
498
4 - CASCADE STRUCTURE:
Many of the standard blocks defined by Field Bus can be configured to have a
"cascade" structure. This structure allows the mode parameter to control the
source of the SP of the block and to control the access to the Output by a
configured higher level control device. This cascade structure can be found in
both analog and discrete blocks.
When the "Standard Block Functions" table indicates that a "Cascade

Structure" is included in the block structure, the following parameters will be
included in the block:
1) Cas transfer location (unless Cas mode not supported).
2) Cas transfer status byte(s) (unless Cas mode not supported).
3) Cas No-Communication_Counter (unless Cas mode not supported).
4) RCas transfer location (unless RCas mode not supported).
5) RCas transfer status byte(s) (unless RCas mode not supported).
6) RCas No-Communication_Counter (unless RCas mode not supported).
7) ROut transfer location (unless ROut mode not supported).
8) ROut transfer status byte (unless ROut mode not supported).
9) ROut No-Communication_Counter (unless ROut mode not supported).
Consult page 13 of the paper "Application Support Services Interface" for the
definition of the structures and actual number of parameters represented by each
of the above items.
The Cas and RCas transfer location values will, in general, have the same
data type and engineering units as the set point and the ROut transfer location
value will have the same data type and engineering units as Output Word 0. Any
exceptions to these rules will be explicitly defined in the algorithm. The No-
Communication_Counter will be reset every time there is a write to the associated
transfer location and it will be incremented every cycle by the block algorithm.
The algorithm will monitor the value and "count-out" the RCas or ROut mode if the
value exceeds 32 (for RCas, 8 for ROut). The Cas No-Communication_Counter, which
will count out at 32, can be used by an "active, on-block agent (counter)". This
process is also defined in the above referenced paper.
Note:
The standard function block types are defined as analog or discrete
according to the data type of their "PV Pointer" (see below). If
the PV Pointer is analog, then the block is considered as an analog
block. If the PV Pointer is discrete or not supported, then the
block is considered a discrete block.
Note:
In order to minimize the traffic on Field Bus, a higher level
device should never write to the RCas or ROut transfer locations
when all three of status bits 7, 6, and 3 are set (analog, when
value bits 7, 6, and 5 are set in discretes) (see Attachment 2 to
the "Status Byte" paper). Since the remote connection must execute
the Remote Handshake, there is no advantage to having the count-out
counters reset when the cascade is allowed. The Cas transfer
location should be written all of the time from peer blocks.
Note:
It is important that the primary's in a cascade structure properly
implement masking in order to correctly manipulate the status
bytes. Refer to the paper "Application Layer Service Interface"
for details on writing to the cascade connections.
Analog Blocks:
When the "Cascade Structure" is included in the block structure,
Input Word 0 and Output Word 0 are normally associated with the cascade
structure.
The mode of the block will determine the source of the SP. In any
mode of Auto or higher priority, the SP will not be changed by the

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
499
cascade structure. In Cas mode, the block will use the value pointed to
by the Input Word 0 pointer. Often, that will be the Cas transfer
location. In RCas mode, the block will use the value found in the RCas
transfer location as the block's SP. In any mode, the block will set
the new value of the SP into the two transfer locations and update the
status bytes of both.
The mode of the block will determine the source of the Output. In
IMan mode, the value of Output Word 0 will be left as set by the
location to which the Output was pointed. In LO mode, Output Word 0 can
not be changed at all. In Man mode, Output Word 0 can only be changed
by a write from the Field Bus. In Auto, Cas, and RCas mode, the block's
--```,``-`-`,,`,,`,`,,`---
algorithm (or by-pass) controls Output Word 0. In ROut mode, the value
in the ROut transfer location will be moved into Output Word 0. In all
cases, the new value in Output Word 0 will be set into the ROut transfer
location and the status byte of the transfer location will be updated.
The detailed definition of the combination of the mode and status

logic is given in Attachment 1 to the paper "Function Block Structure".
Discrete blocks:
There are two differences in the cascade structure between analog
and discrete blocks. First, there are no standard discrete blocks that
support ROut mode, hence there is no connection between the Cascade
structure and any particular Output Word. Second, the selection of the
source of the SP in Cas mode is more complex and does not necessarily
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
have anything to do with Input Word 0. Instead of one pointer, the

discrete blocks that use the Cascade Structure have bit pointers for the
source of the block's set point. They have as many bit pointers as
there are bits in the SP, usually three. In Cas mode, the first of the
three pointers is inspected. If it points to the Cas transfer location,
then the 3-bit string in that location is used as the SP. If it does
not point to the Cas transfer location, then the three pointers are used
to determine the source of the three bits. The new value of the SP is,
however, still written back into the Cas transfer location.
The "Status Byte" paper defines the rules that the algorithms will
follow in manipulating the bits in the status bytes and Attachment 1 to
the "Function Block Structure" paper gives the logic details.
Note that the "Data Base Write Service" paper defines a number of
constraints on, and functions to service, the Cascade transfer
locations. The most important service is the one that causes any write
to the block's SP to also be written to the Cas and RCas transfer
locations and the setting of the logical TRANSFER_VOID. This action
results in the rejection of the next write to the transfer location (see
the paper "Function Block Structure" and the Appendix paper "Fundamental
Control Structure" - page 14). Likewise, any write to Output Word 0 in
an analog block is also written to the ROut transfer location and its
TRANSFER_VOID is set. These functions are critical to the correct
functioning of the cascade structure.
The operation of the Cascade Structure defined in the Standard is

explained in the paper "Block Structure for Cascading" found in the
Appendix.

500
5 - BY-PASS:
All of the Standard function blocks have a defined algorithm. In general,
the algorithms use block inputs to manipulate the block outputs. In some
situations with some algorithms, the operator may want to simply bypass the
operation of the algorithm, moving a block input directly to an output. The "By-
Pass" function provides this option as a specific standard function.
In Standard blocks, by-pass can only be included in blocks that have

Setpoints. It always moves the block SP to the parameter Output (in discrete
blocks), to Output Word 0 (in analog control blocks), or to the physical output
(in the Analog Output block). For discretes, the bits of the SP will retain
their bit order and will be placed in the least significant three bit positions
of Output.
It is important to note that the operation of the block's mode is unaffected

by the activation of by-pass. The by-pass function is truly an alternate block
algorithm; it moves the SP to the Output. The mode still determines the source
of the SP and, in ROut, Man, or LO mode will block the by-pass function.
The "Standard Block Functions" table includes an entry for "By-Pass". It will
list "yes" or "no" to indicate if that block supports by-pass. Each function
block that permits by-pass will also include an 8 bit binary string to control
by-pass. The string, called "CONFIG_BY", will be a static data base item that is
structured as follows:
Bit 0 = set if bypass active.
Bit 1 = set if bypass prohibited.
Bit 2 = set if an authority 1 level higher than an operator's is
needed to change bit 0.
Bit 3 = set if an authority 1 level higher than an operator's is
Bit 4 = set if an authority 2 levels higher than an operator's is
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

Bit 5 = set if an authority 2 levels higher than an operator's is
Bits 6&7 = available for manufacturer.
--```,``-`-`,,`,,`,`,,`---
6 - SET POINT LIMITS:
Most of the analog blocks have a functional need for a method of limiting the
movement of the set point: "Set Point Limits". An alarm will be set when one of
the limits is reached. One alarm with the following detail codes will be
provided:
Detail code: 01 - LO Limit.
02 - HI Limit.
The presence of this function will require the presence of the following data
base items:
1) SP_LIM_HI = High set point limit (real) (in the same units as the SP)
(default = NaN).
2) SP_LIM_LO = Low set point limit (real) (in the same units as the SP)
(default = NaN).
3) SP_DB = Limit deadband (real) (in the same units as the SP) (default
= NaN).
If a limit value is equal to NaN, then that limit will be ignored. If the
deadband is equal to NaN, then both limits will be ignored. The high set point
limit will not be allowed to be written to a value lower than the low set point
limit and the low set point limit will not be allowed to be written to a value
higher than the high set point limit. A value of NaN can always be written and
will not prevent the writing of the companion limit.
The alarm function that is provided for all blocks will have provision for
the following data base items associated with this alarm (see the paper
describing the "Alert Function" for details on the following):

501
1) Alarm priority
2) Unacknowledged bit reset option
3) Alarm state
4) Alarm Unacknowledged bit
The "Standard Block Functions" table includes an entry for "Set Point
Limits". It will list "yes" or "no" to indicate if that block supports the
limits.
A block may have the capability of back-calculating its SP during Iman mode
and also have set point limits. Alternately, the block may provide PV tracking
which forces the SP to track the PV in IMan, LO, or Man mode (and optionally, in
ROut mode) while it also has set point limits. There can be situations in which
the back-calculated SP would be outside of the set point limits. THIS WILL BE
ALLOWED IF THE AUTO MODE BIT IS NOT SET IN THE ACTUAL MODE. If the setpoint is
being back-calculated and the Auto mode bit is reset, the value will be set as
calculated. When the block reverts to forward calculations, the limit that has
been exceeded will act as a "ballooning" limit. For example, consider a
situation in which the high set point limit was exceeded by the back-calculated
SP. When forward calculations resume, a new SP value will be limited by the
GREATER of:
1) the last SP value
2) the high SP limit
The design of the setpoint limits is such that they will not balloon when the
immediate block is the primary of the cascade. When the immediate block is a
secondary and normal control is interrupted by initialization, the setpoint of
the block will balloon because this block's setpoint limits are acting
essentially as output limits on the primary. Output limits are always allowed to
balloon.
Note that the status of the set point limiting is considered in the setting
of the ATW bits in the status byte as defined in the "Status Byte" paper. The
set point is to be considered to be limited in one direction any time it is in a
ballooning situation (i.e., any time the SP is equal to, or beyond, the
configured limit).
There are certain situations in which the engineering units value of certain
process variables appear to be "reversed". Consider the case of "inches of
vacuum". Field Bus will ignore this apparent reversal. The engineering units
value will be used "as is". Therefore, 30 inches of vacuum is "higher" than 20
inches of vacuum.
Some function blocks will define a "control range". This range will be
associated with the Setpoint and will be used to convert the Setpoint and other
block parameters (which will be in engineering units) to a "percent of range".
It is assumed that the control range will not normally be manipulated by the
operator of the control system. THE SETPOINT LIMITS WILL NOT BE ALLOWED TO BE
SET OUTSIDE OF THE CONTROL RANGE if a control range is supported by the function
block.
7 - SETPOINT RAMP:
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
There are many situations in which an operator may wish to change the
Setpoint of an analog control or output block but wants the change to be made
--```,``-`-`,,`,,`,`,,`---
slowly. Some of the Standard analog blocks allow this as a manufacturer's

option.
The following three parameters will be included in the block's data base to
support Setpoint ramps:
1) TARGET_SP - indicates the desired final value of the Setpoint. Will
be limited by the Setpoint Limits if present. (stored
in the dynamic data base).
2) RAMP_RATE - gives the ramp rate in units of (engineering units)/

502
minute. (Real number but can not be negative - stored in

the static data base).
3) RAMP_FLAG - a logical that initiates the ramp when it is set, stops
the ramp if it is turned off, and is turned off by the
block when the ramp is finished (initialized to reset,
stored in the dynamic data base).
The RAMP_FLAG will not be permitted to be set if any mode bit other than Auto
is set in the actual mode of the block. If the RAMP_FLAG is set and any actual
mode bit other than Auto is set, RAMP_FLAG will be reset and a notification alert
will be issued.
If the Setpoint of the block goes into either wound-up state (or both) while
the ramp is active, the ramp will continue unless some other condition that stops
the ramp accompanies the wound-up state.
If Input #1 of the block becomes Bad, the RAMP_FLAG will not be allowed to be
set. If it is already set, it will be reset and a notification alert will be
issued. In the special case of the Setpoint ramp in a PID algorithm, the
RAMP_FLAG will not be allowed to be set if Input #1 is not from the process
(i.e., status bit #2 set). If the ramp is already in progress, RAMP_FLAG will be
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
reset and a notification alert will be issued.
At each operation cycle, the block will compare the ramp target value to the
Setpoint limits. If the limits are moved such that the target value is outside
of the limits, RAMP_FLAG will be reset and a notification alert will be issued.
The "Standard Block Functions" table includes an entry for "Set Point Ramp".
It will list "yes", "optional", or "no" to indicate if that block must support,
can optionally (manufacturer's option) support, or does not support the limits.
8 - OUTPUT LIMITS:
Most of the blocks that generate an analog output value have a functional
need for a method of limiting the movement of that Output. The "Output Limits"
function provides limits on the freedom of movement of the Output. This
function, if present, will apply to Output Word 0. The block can define a second
and perhaps a third instance of Output Limits. In such cases, the second set
will apply to Output #1 and the third will apply to Output #2.
The "Standard Block Functions" table will include a line item for "Output
Limits". Following that item will be either "none" or the numbers 1, 2, or 3.
This number indicates the number of instances of Output Limits in that one block.
The presence of the "output limits" function will require the presence of the
following data base items for each instance of the limits (all of these
parameters are real, are in the same units as the output, default to NaN, are
under the tuning attribute, and are not mode controlled):
1) LIM_HI = High Output limit.
2) LIM_LO = Low Output limit.
3) LIM_DB = Limit deadband.
If a limit value is equal to NaN, then that limit will be ignored. If the
deadband is equal to NaN or 0, then no deadband will be applied.
The Output Limit function will support one alarm for each instance of Output
Limits. The detail code of the alarm is as follows:
Detail Code: 01 - LO Limit
02 - HI Limit
The alarm function that is provided for all blocks will have provision for the
following data base items associated with each of these alarms:
1) Alarm priority
3) Alarm state

--```,``-`-`,,`,,`,`,,`---

503
The Output limits WILL NOT apply to values of the Output written into he
Output parameter from the Field Bus. Note that these writes can only occur when
the block is in Man or O/S mode. The limits WILL NOT apply to the value obtained
from the ROut transfer location.
The Output limits and associated alarm will apply to the block's forward
calculation algorithm and to the by-pass function. If the actual mode of the
block has only the ROut bit set, or if any actual mode bits with higher priority
than Auto are set, and existing Output Limit alarm will be cleared and not re-
alarmed until the mode changes.
If a block is in a cascade structure, its Output will be supplied by its

secondary block during initialization. There can be situations in which the
initialization Output is outside of the Output limits. THIS WILL BE ALLOWED. If
the initialization Output is outside of the limits, the value will be set as
reported by the secondary block. Since the block must be in IMan mode when that
occurs, there will be no alarm.
When the block reverts to forward calculations, the limit that has been
exceeded will act as a "ballooning" limit. For example, consider a situation in
which the high Output limit was exceeded by an initialized or manually set
Output. When forward calculations resume, a new Output value will be limited by
the GREATER of:
1) the last Output value.
2) the high Output limit.
Since the mode will have changed to a mode that allows alarms, the Output Limit
alarm will be issued at that point.
Note that the status of the output limiting is considered in the setting of
the ATW bits in the status byte as defined in the "Status Byte" paper. The output
is to be considered to be limited in one direction any time it is in a ballooning
situation (i.e., any time the Output is equal to, or beyond, the configured
limit).
Some function blocks will define an "output control range". This range will
be associated with the Output and will be used to convert a calculated Output in
"percent of range" to the Output in engineering units. It is assumed that the
output control range will not normally be manipulated by the operator of the
control system. THE OUTPUT LIMITS WILL NOT BE ALLOWED TO BE SET MORE THAN 5%
OUTSIDE OF THE OUTPUT CONTROL RANGE if an output control range is supported by
the function block.
9 - PV POINTER:
The Field Bus Standard supports the concept that the fundamental variable of
a block (the "principle variable") is the "PV". In order to maximize the user's
flexibility to define the most important variable in a block, none of the
standard blocks identify any parameter as the PV. Rather, the PV is the
parameter defined by the "PV Pointer". It can be any parameter in the block of
--```,``-`-`,,`,,`,`,,`---
the same data type as the default value for the PV Pointer. The selected
parameter is the one that will be supplied when a Field Bus device requests the
"PV". It will also be the parameter that will have the standard "PV" alarms -
High PV, Low PV, Deviation, etc.
The "Standard Block Functions" table will include a line item for "PV
Function". Following that item will be either "none" or the default block
parameter to which the PV will point. All PV Pointers will be initialized to the
default parameter but any of them can be changed to point to any block parameter
of the same data type.
If a Standard block does not support the "PV Pointer", it will still support
a parameter called the "PV": the value of that parameter will be set equal every
cycle to the value of the default parameter defined above.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
504
The parameter "PV" will NEVER be writeable. Note that the parameter to which
the PV pointer points may be writeable; if so, it must be written by directly
addressing it, not by addressing the parameter "PV".
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
The data type of the default PV Pointer value is, as explained in the note
above, used to determine the classification of the whole block: either discrete
or analog.
The PV Function design includes a parameter called the "TARGET". This

parameter serves as the base for the deviation alarm. Like the PV, the TARGET
has a "pointer" that can be configured to define the parameter to which the
TARGET will be equated. Two additional parameters are also included to provide
the needed flexibility for the TARGET: FREE_STAT and FREE_DYNAMIC. These latter
two parameters are free variables in the static and dynamic data areas
respectively. They can be used to store values for use by TARGET.
The TARGET, its pointer, FREE_STAT, and FREE_DYNAMIC are required of all
blocks even if the PV Function is not supported.
The "PV Function" line item in the "Standard Block Functions" table will
include an entry that will be either "none" or the default block parameter for
the TARGET pointer . All TARGET pointers will be initialized to the default
parameter but any of them can be changed to point to any block parameter of the
same data type.
The parameter "Target" will NEVER be writeable. Note that the parameter to
which the Target pointer points may be writeable; if so, it must be written by
directly addressing it, not by addressing the parameter "Target".
The PV function will support the following alerts:

Analog: Discrete:
PV "Bad" PV - Bad, no bits set, or more than 1
bit set.
PV HIHI PV Bit 0 in wrong state
PV HI PV Bit #1 in wrong state
PV LO PV Bit #2 in wrong state
PV LOLO Change in the PV
PV Target "Bad" PV Target - Bad, no bits set, or more
than 1 bit set.
PV Deviation PV not equal to Target
The alert function that is provided for all blocks will have provision for
the following data base items associated with each of these alarms (see the paper
describing the "Alert Function" for details on the following):
1) Alarm priority
3) Alarm state
The parameters associated with the PV Function that are always required in
all analog blocks are:
1) PV = The PV parameter and its status byte (dynamic data base
items).
2) FREE_STAT = Free_Static_Variable. This parameter is a static
data base item of the same data type as the default PV. It has
no explicit range or engineering units specifiers. It can be
used as the "target" value for the PV Pointer function or as a
"free" variable for other purposes. It has no status byte.
Since it is located in the static data base it will be restored
on a memory reload but it must not be dynamically changed.
(Default value = NaN)
3) FREE_DYN = Free_Dynamic_Variable. This parameter is a dynamic
data base item of the same data type as the default PV. It has
no explicit range or engineering units specifiers. It can be
used as the "target" value for the PV Pointer function or as a
"free" variable for other purposes. It has no status byte.

--```,``-`-`,,`,,`,`,,`---

505
Since it is located in the dynamic data base it will not be

restored on a memory reload but it can be dynamically changed.
(Default value = NaN)
4) TARGET_PARAM = Parameter number of the parameter chosen to be
the "target" (must be on-block and the same type as the default
PV) (default value is the default parameter specified by the
algorithm definition).
5) TARGET = The target parameter value and its status byte (default
= NaN).
6) the parameters "PV_BUILD" and "PV_REFRESH". These parameters
are defined in the paper "Array of Standard Block Parameters".
The presence of the "PV Pointer" function will require the presence of the
following data base items for an analog block:
1) PV_PARAM = Parameter number of the parameter chosen to be the PV
(must be on-block) (default value specified for each standard
algorithm) (value in the static data base).
2) PV_HI_DISP = High display range for the PV (value in engineering
units of the PV; the value determines the value of the PV that
will be shown as full range in a graphical representation of the
PV) (static data base), (default value = NaN).
3) PV_LO_DISP = Low display range for the PV (value in engineering
units of the PV; the value determines the value of the PV that
will be shown as minimum range in a graphical representation of
the PV) (static data base), (default value = NaN).
4) A parameter value for each of the following items:
Note: in this list, it is recognized that the function
being described may be either a "comparator" or
an alarm. It is labeled a comparator with the
understanding that it will become an alarm if
it is assigned an alert priority greater than
one. However, the repeat function is not useful
as a comparator.
a) HIHI_ALARM = High, High PV comparator setting (in the units
of the PV) (default value = NaN).
b) HI_RPT_ALARM = High PV alarm repeat setting (in the units
of the PV) (must be a positive value; default value = NaN).
c) HI_ALARM = High PV comparator setting (in the units of the
PV) (default value = NaN).
d) LO_ALARM = Low PV comparator setting (in the units of the
e) LO_RPT_ALARM = Low PV alarm repeat setting (in the units of
the PV) (must be a positive value; default value = NaN).
f) LOLO_ALARM = Low, Low PV comparator setting (in the units
of the PV) (default value = NaN).
g) TARG_FILTER = Time constant for target filter (sec.)
(default value = 0)
h) DEV_ALARM = Deviation comparator setting - the difference
--```,``-`-`,,`,,`,`,,`---
between the filtered PV and the filtered target (in the
units of the PV) (Default value = NaN). where:
current deviation = filtered PV - filtered target
and "Hi" refers to a large positive deviation
i) DEV_LOGICAL = Deviation comparator definition - a 2 bit
logical:
Value = 0 if comparator inactive
Value = 1 if comparator on high only
Value = 2 if comparator on low only
Value = 3 if comparator on both high and low deviation
Default value = 0
5) COMP_DB = comparator deadband (real) (in the same units as the
The PV itself will not have a standard status byte. The following is the
definition of its unique status byte:
bit 0 = Set if No-Com (same as standard)
1 = Set if Bad (same as standard)
2 = Set if not from process (same as standard)

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
506
3 = Set if HiHi Alarm

4 = Set if Hi Alarm
5 = Set if Lo Alarm
6 = Set if LoLo Alarm
7 = Set if Deviation Alarm
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
There are three algorithm processing procedure details that must be observed
for the above data items. They are expressed here in pseudocode form:
1) If the PV Pointer is configured to provide a rate of change alarm on
the Output, it is necessary to suppress the alarm in Man mode in
order to avoid extraneous alarms when the operator moves the Output
value.
Therefore:
IF PV Pointer = Output 0 AND
Target Pointer = Output 0 AND
the Actual Mode has a priority of Man or higher, THEN
Before doing the alarm comparisons, set the filtered Target
equal to the Target
2) Likewise, if the PV Pointer is configured to provide a rate of change
alarm on the Setpoint, the alarm must be suppressed in Auto or any
higher priority mode. Therefore:
IF PV Pointer = Setpoint AND
Target Pointer = Setpoint AND
the Actual Mode has a priority of Auto or higher, THEN
Before doing the alarm comparisons, set the filtered Target
equal to the Target
3) Given the relatively large number of PV Function alarms, it is
beneficial to suppress the less meaningful alarms when there are
multiple alarms active.
For purposes of the following rules, the PV Function alarms will be

modeled as being tested in the order:
a) Bad PV
b) Bad Target
c) HHPV
d) LLPV
e) HPV
f) LPV
g) Deviation
Each of the HHPV, HPV, LPV, and LLPV alarms will be tested for their
alarm states independently. However,
IF the PV is "Bad", THEN
no PV function alerts other than "Bad PV" and "Bad Target"
will be reported (see the "Alert" paper for a definition of
"reported".
IF the HHPV alarm is set AND
IF the alert priority of the HHPV alarm is higher than, or
equal to, the alert priority of the HPV alarm, THEN
a HPV alarm will not be reported.
IF the LLPV alarm is set AND
IF the alert priority of the LLPV alarm is higher than, or
equal to, the alert priority of the LPV alarm, THEN
a LPV alarm will not be reported.
IF the target value is Bad, THEN
the Deviation alarm will not be reported.
--```,``-`-`,,`,,`,`,,`---
IF a HHPV, HPV, LPV, or LLPV alarm is set, THEN

IF there is a Deviation alarm, THEN
IF the Deviation alarm is equal to or lower in priority
then the set alarm, THEN
the Deviation alarm wil not be reported.
The parameters associated with the PV Function that are always required in
all discrete blocks are:
1) The 3-bit variable PV and its 3 status bytes.
2) FREE_STAT = Free_Static Variable. This parameter is a static

507
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
data base 3-bit string. It can be used as the "target" value
for the PV Pointer function or as a "free" variable for other
purposes. It has no status byte. Since it is located in the
static data base it will be restored on a memory reload but it
must not be dynamically changed. (Default value = reset.)
3) FREE_DYN = Free_Dynamic_Variable. This parameter is a dynamic
data base 3-bit string. It can be used as the "target" value
--```,``-`-`,,`,,`,`,,`---
for the PV Pointer function or as a "free" variable for other

purposes. It has no status byte. Since it is located in the
dynamic data base it will not be restored on a memory reload but
it can be dynamically changed. (Default value = reset.)
4) Three bit pointers to form the 3-bit string for "Target"
(TARGET_PARAM0, TARGET_PARAM1, and TARGET_PARAM2). This will
implement the standard discrete alarm "PV <> Target" (default
values are the Setpoint parameter number bits 0, 1, and 2).
5) The three bit variable Target and its 3 status bytes.
The presence of the "PV Pointer" function will require the presence of the
following data base items for a discrete block:
1) Three bit pointers to form the 3-bit string for "PV":
PV_PARAM0, PV_PARAM1, and PV_PARAM2.
(default value specified for each standard algorithm).
2) ALARM_LOGICAL = Eight bit string to control the alarms as
follows:
a) bit 0 set if alarm on PV bit 0 set
b) bit 1 set if alarm on PV bit 1 set
c) bit 2 set if alarm on PV bit 2 set
d) bit 3 set if alarm on PV bit 0 reset
e) bit 4 set if alarm on PV bit 1 reset
f) bit 5 set if alarm on PV bit 2 reset
g) bit 6 set if notification on any change in the PV
h) bit 7 free - reset unless specified
(Default value = all reset).
Note: the bad PV and bad target conditions are always alarmed.
3) ALARM_DOT = Alarm delay-off timer [the same setting applies
individually to all items 7(a) through 7(g) plus the bad PV and
bad target alarms] (real) (in seconds) (default value = 4)
The PV bits will not have standard status bytes. The following is the
definition of their unique format:
bit 0 = Set if No-Com (same as standard)
1 = Set if Bad (same as standard)
2 = Set if not from process (same as standard)
3 = Set if PV has other than 1, and only 1, bit set (will match
across all three status bytes)
3 = Set if Alarmed because this bit is reset
4 = Set if Alarmed because this bit is set
5 = Set if Target has other than 1, and only 1, bit set (will match
across all three status bytes)
6 = Set if the corresponding bit in Target is Bad.
7 = Set if not equal to corresponding bit in Target
Given the relatively large number of PV Function alarms, it is beneficial to

suppress the less meaningful alarms when there are multiple alarms active.
IF a PV bit is Bad, THEN
the PV Bad alarm will be reported with a detail code for Bad
no other PV Bad alarms will be reported
the Bad bit will not be tested for being in the wrong state
the Bad bit will not be tested for change
the Bad bit will not be compared to the corresponding target
bit
IF a Target bit is Bad, THEN
the PV Target Bad alarm will be reported with a detail code
for Bad
no other PV Target Bad alarms will be reported
the Bad bit will not be compared to the corresponding PV bit.

508
10 - BOOLEAN OPERATOR:
Some discrete blocks will include Boolean operators that can be used to
operate on discretes before they are fetched by the bit pointers servicing other
block parameters. For example, two input discretes may have to be "OR"ed
together before use as a bit in the SP.
The "Standard Block Functions" table will define how many Boolean operators
are included in the block.
The following Boolean Operator types will be provided:

0) Not Configured - the operator is null
1) AND - IF the two inputs are set THEN
the output is set
ELSE the output is reset
2) OR - IF either of the two inputs or both are set THEN
the output is set
--```,``-`-`,,`,,`,`,,`---
ELSE the output is reset.
3) XOR - IF either of the two inputs but not both are set THEN
the output is set
ELSE the output is reset.
4) Latch
a) IF Input 0 is set this cycle AND was reset last cycle THEN
set "a".
b) IF Input #1 is set this cycle AND was reset last cycle THEN
set "b".
c) Output = the value of Output from the last cycle.
d) IF Output = reset AND "a" is set THEN
set Output
e) IF Output = set AND "b" is set THEN
reset Output
5) 1-Shot Latch -
IF Input 0 is set this cycle AND
Input 0 was reset last cycle AND
Output was reset after the last cycle THEN
set Output
ELSE reset Output.
6) Delay On Timer -
a) IF Output was reset last cycle THEN
IF Input 0 is set this cycle THEN
IF timer is off THEN
start timer with the setpoint time.
leave Output reset.
IF timer is running THEN
IF timer has timed out THEN
set Output
IF timer has not timed out THEN
continue timer.
leave Output reset.
ELSE stop timer.
ELSE
IF Input 0 is reset this cycle THEN
reset output.
ELSE leave Output set.
7) Delay Off Timer -
a) IF Output was set last cycle THEN
IF Input 0 is reset this cycle THEN
IF timer is off THEN
start timer with the setpoint time
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
leave Output set.

ELSE
IF timer has timed out THEN
reset Output
reset timer.

509
ELSE continue timer

leave Output set.
ELSE reset the timer.
b) IF Output was reset last cycle THEN
IF Input 0 is set this cycle THEN
set output.
ELSE leave Output reset.
8) Pulse Timer
a) IF Input 0 is set this cycle AND was reset last cycle THEN
set "a"
ELSE reset "a".
b) IF Output was set last cycle OR "a" is set THEN
set "b"
ELSE reset "b".
c) IF this is the first cycle after transition from O/S mode THEN
reset "b"
d) IF "b" is set THEN
IF timer is on AND timed out THEN
turn off timer and reset Output.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
IF timer is on but not timed out THEN
continue timer and set Output.
ELSE start timer with setpoint value.
set Output.
ELSE Reset Output and reset the timer.
The timer will be considered to be "not expired" if there is any time left
when a cycle executes. For example, if an Off-Delay timer is set for 300
milliseconds and the node cycle time is set by CX = -2 (250 milliseconds), then
the timer will delay the action until the second cycle after reset; it will not
have expired after the first cycle; it will act exactly the same as if the time
were set to 251 or to 500 milliseconds.
Each Boolean operator defined above has one or two input bit pointers and one
Boolean operation. The Boolean Operators are always solved after the new Input
and Output Words are fetched. The Boolean Operators are always solved before any
other bit pointers are executed. The Boolean Operators are always solved in
order with Operator 0 first. The result is available to any of the input bit
pointers for the succeeding Boolean Operators and the other bit pointers in the
block but the state of the Boolean product is not available over Field Bus nor
off-block. It is also not available to any of the standard I/O Word pointers.
Note that the Boolean inputs can come from the low 16 bits of any on-block
parameter as well as from the 5 logical node words.
The Boolean operator has three words of configuration. The attached drawing
"Boolean Operator", illustrates the format of the words. The operator will
always have a definition word. If the word defines the Boolean Operator as an
"AND", "OR", "XOR", "Latch", or "1-Shot Latch", then the second and third words
are "detail words (pointer)" and define the two (1 for the 1-Shot Latch) bit
pointers.
The Boolean Operator will calculate a status byte for its output based on the
--```,``-`-`,,`,,`,`,,`---
stati of its inputs. There are four options defined in the configuration of each
bit pointer to influence this calculation. The four defined pointer options are:
1) Set Bad if No-Com
If this bit is set, a No-Com status for the input bit will cause
the fetched input bit to be marked as Bad. The No-Com status
will always be cleared in the fetched bit. The status of the
source bit will NOT be affected.
2) Clear Bad Stat.
If this bit is set, the Bad status will be unconditionally reset
in the fetched input bit. The status of the source bit will NOT
be affected.
3) Clear Override
If this bit is set, the not-from-process status will be
unconditionally reset in the fetched input bit. The status of
the source bit will NOT be affected.

510
4) Set Override
If this bit is set, the not-from-process status will be
unconditionally set in the fetched input bit. The status of the
source bit will NOT be affected.
In the determination of the status of the output, the output is considered to

be "bad" if any input that determined the value of the output was "bad". The
following table defines all cases for this determination. The table defines the
value of each Boolean operator input and whether it is "Bad" or "Good".
Input 0 Input 1 Operator Type Status of Output
Both (or the only one) = Good any Good

Both (or the only one) = Bad any ex Pulse Bad
Output = 1 and Input = Bad Pulse Good
Output = 0 and Input = Bad Pulse Bad
0 - Good 0 - Bad AND Good

1 - Good 0 - Bad AND Bad
0 - Good 1 - Bad AND Good
1 - Good 1 - Bad AND Bad
0 - Bad 0 - Good AND Good
1 - Bad 0 - Good AND Good
0 - Bad 1 - Good AND Bad
1 - Bad 1 - Good AND Bad
0 - Good 0 - Bad OR Bad

1 - Good 0 - Bad OR Good
0 - Good 1 - Bad OR Bad
1 - Good 1 - Bad OR Good
0 - Bad 0 - Good OR Bad
1 - Bad 0 - Good OR Bad
0 - Bad 1 - Good OR Good
1 - Bad 1 - Good OR Good
Either or Both Bad XOR Bad
Output = 0 and Input 0 = Bad Latch Bad

Output = 1 and Input 0 = Bad Latch Good
Output = 0 and Input 1 = Bad Latch Good
Output = 1 and Input 1 = Bad Latch Bad
In the determination of the status of the output, the output is considered to

be "from the process" if any input that determined the value of the output was
from the process. The following table defines all cases for this determination.
The table defines the value of each Boolean operator input and whether it is
"from the process" (FP) or "not from the process" (NFP).
Input 0 Input 1 Operator Type Status of Output

Both (or the only one) = NFP any NFP

Both (or the only one) = FP any FP
Either = FP Latch FP
0 - FP 0 - NFP AND FP
1 - FP 0 - NFP AND NFP
0 - NFP 0 - FP AND FP
0 - NFP 1 - FP AND NFP
0 - FP 0 - NFP OR FP

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~
511
0 - FP 1 - NFP OR NFP
0 - NFP 0 - FP OR FP
1 - NFP 0 - FP OR NFP
0 - FP 0 - NFP XOR FP
1 - FP 0 - NFP XOR FP
0 - FP 1 - NFP XOR NFP
1 - FP 1 - NFP XOR NFP
0 - NFP 0 - FP XOR FP
1 - NFP 0 - FP XOR NFP
0 - NFP 1 - FP XOR FP
1 - NFP 1 - FP XOR NFP
If the Boolean Operator is defined to be a timer, then the second word is a

"detail word (timer)" that stores the time set point in milliseconds. The third
word is a "detail word (pointer)" that defines the source of the single input
bit.
If the Boolean Operator is defined to be a 1-Shot Latch, then the second word
is a "detail word (pointer)" that defines the source of the single input bit.
The third word is not needed but it must be present in order to retain the
expected order of the configuration words. The contents of the word are not
significant.
All of the configuration words for the Boolean operators in one block are
reported under one parameter; the three words defining operator 0 are reported
first and the operator definition word is reported first in each set of three.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

--```,``-`-`,,`,,`,`,,`---

512
Null Algorithm
SUMMARY:
Required in all Standard Field Devices that support more than one type of
block and is then the default block type. Occupies the space of one Standard
function block and clearly identifies the block as being out of service.
Supports only basic required parameter and has no options.
BASIC ALGORITHM:
This block will force its null data base into the basic function block
Parameters that are identified in Table 1 of the paper "Array of Basic
Parameters". It adds no parameters of its own.
At each cycle, the block will force its REQ_MODE and ACTUAL_MODE to O/S. The
block will consume the entire time allocated to one function block in a timed
standard logical node. It will generate no alerts.
GENERAL DESCRIPTION:
The null algorithm is useful for several purposes. First, it is the default
algorithm in all logical nodes that support more than one type of function block.
When such a Field device is first activated but not downloaded with
configuration, all of its function blocks will be of this type.
The user can use the null block type for several purposes:
- force one block time in the cycle of function blocks
- clearly identify a function block that is to be reserved (this
is the application that requires access to the block descriptor).
- clearly identify the function blocks that have not (yet) been
configured.
- clearly identify the spare function blocks.
The block must support all of the parameters that are "basic" so that higher
level devices do not ever have to consult the TO_TYPE before accessing those
parameters. In addition, it will be useful to have access to the block
descriptor for entering appropriate "comments".
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

--```,``-`-`,,`,,`,`,,`---

513
Analog
Analog Input
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
SUMMARY:
Drives, and accepts measurements from, SI hardware. Converts major scalar
signal from measurement units to user selected units with linearization, damping,
clamping, and mode control. Converted major measurement provided as OUTPUT0.
Also converts major signal to user calibration units. Can optionally provide up
to three auxiliary measurements as Outputs 1-3. Can optionally accept, through
INPUT1, an analog value needed for generating the primary measurement.

DETAILS OF PARAMETERS
ALERT SUPPRESSION
HARDWARE FILTER
OPTIONAL INPUT1
GO BAD AT END OF RANGE
CALIBRATION UNITS CONVERSION
LINEARIZATION PROCEDURE
DAMPING PROCEDURE
USER UNITS CONVERSION
CLAMPING PROCEDURE
UUV RANGE
GENERAL DESCRIPTION
LINEARIZATION AND DAMPING DESCRIPTION
AI BLOCK APPLIED TO MULTIPLEXING
Table 1 - List of Linearization Codes
Figure 1 - Analog Input Algorithm
ANALOG INPUT PSEUDOCODE
BASIC ALGORITHM:
- Optionally provide a path for an external value from INPUT1 to the
measuring circuit, complete with units conversion and limiting.
- Apply linearization, damping, user unit conversion, and clamping to
the measurement of the major scalar input (INPUT0) to produce OUTPUT0.
- Apply calibration unit conversion to the measurement of the major
scalar input to produce the "calibration unit value" (CUV).
- Optionally apply linearization and user unit conversion to the
instrument limits of INPUT0 to obtain the "User Units Value" (UUV)
range in user units.
- If the optional triggered calibration procedure is supported, the
procedure will operate on the "CUV" value. The bias values calculated
by the procedure will be applied to the hardware value BEFORE it is
identified as INPUT0.
- Make any applicable auxiliary measurements available as Outputs 1, 2,
SP-50 User Layer Technical Report Analog In

--```,``-`-`,,`,,`,`,,`---

514
and/or 3 in "extended international standard" (ESI) units.

- Inputs: 1 required - hardware, SI type; 1 optional - optional
agent type
- Outputs: 1 required, 3 optional - Mode: not LO, Cas, RCas, nor Rout.
--```,``-`-`,,`,,`,`,,`---
- Bit Pointers: no - Output Limits: optional (with

- Boolean Operator: no clamping if present)
- By-pass: no - PV pointer: optional; analog; PV
- Cascade Structure: no defaults to OUTPUT0; TARGET
- Hardware Pointers: yes defaults to FREE_STAT.
INPUT0 = SI - Setpoint Limits: no
- Setpoint Ramp: no
UNIQUE BLOCK FEATURES:

- Hardware filter time constant with separate desired value.
- External value acquired via. INPUT1, converted, limited, and supplied
to the measuring section.
- The Output agents can be optionally limited to Null or Immediate.
- Output clamping added to optional Output limiting.
- Optional calculation of UUV range.
- Optional measurement revision numbers.
MANUFACTURER BLOCK OPTIONS:

- TIME_CRIT0 - Time-critical manufacturer's Options #0.
= 16 bit binary string, read-only
+ the statement is true if the assigned bit is set.
0) INPUT1 supported
1) INPUT1's agent is active (Note: this bit has no meaning if
bit 0 is reset).
2) IN0_LO and IN0_HI (instrument range limits) supported.
3) SI Hardware can run independently of the AI block and the
hardware value may be available (Note: this bit has no
meaning if bit 2 is reset).
4) UUV range calculated (Note: this bit has no meaning if bit 2
is reset).
5) OUTPUT1 is supported.
8) OUTPUT0 and any of OUTPUT's 1-3 that are present support
active agents.
9) Output limiting/clamping is supported.
AH) Revision number supported on all Outputs.
BH) Triggered calibration is supported.
CH) PV Pointer is supported.
DH and EH) Reserved.
FH) Extended variables present in this TO. align word
- N_TIME_CRITx - None-time-critical manufacturer's Options #0, 1, 2, and
3.
= 16 bit binary string, read-only
+ N_TIME_CRIT0
0) Hardware first order filter time can be set by configuration.
1) Triggered calibration only works if CX > MX (Note: this bit
has no meaning if bit BH in TIME_CRIT0 is reset.
2) set if OUTPUT1 = cold junction temperature.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
3) set if OUTPUT1 = body temperature.

Note: only 1 of bits 2 and 3 can be set at one time. Neither
bit has any meaning if bit 5 in TIME_CRIT0 is reset.
4) set if OUTPUT2 = process pressure (this bit has no meaning if
bit 6 in TIME_CRIT0 is reset).

515
5) set if OUTPUT3 = process fluid density (this bit has no

meaning if bit 7 in TIME_CRIT0 is reset).
6) N_TIME_CRIT1 is present.
(Note: this is the basic linearization list.)
(Note: this is the thermocouple extension list.)
(Note: this is the RTD extension list.)
9) Set if all Standard pseudocode checks and alerts are
implemented in the base algorithm and in all supported
options.
AH-FH) see Table 1 for the basic linearization types
indicated by these bits.
Bits AH-FH above and all of the bits in N_TIME_CRIT1-3
correspond to one of the linearization types listed in Table 1.
If a bit is set, the block supports the corresponding type of
linearization.
USER ALGORITHM OPTIONS:

- OPTIONS0 = user options string #0.
= 16 bit binary string, indirectly writeable, static data base
+ Clamp options:
Bit 0 = 0 = INPUT0 limited to IN0_LO.
1 = INPUT0 limited and goes Bad at IN0_LO.
Bit 1 = the same for the high limit of INPUT0.
Bit 2 = 0 = OUTPUT0 limited to LIM_LO but stays good.
1 = OUTPUT0 limited to LIM_LO and goes Bad.
Bit 3 = the same for the high limit of OUTPUT0.
Bit 4 = 0 = OUTPUT1 limited to OUT1_LO.
1 = OUTPUT1 limited and goes Bad at OUT1_LO.
--```,``-`-`,,`,,`,`,,`---
Bit AH = 0 = EV simply limits if below EV_LO.
1 = EV goes Bad if below EV_LO.
Bit BH = the same for the high limit of EV.
Bit CH = set Man mode if INPUT1 = Bad.
Bit DH = reserved.
Bits EH & FH = manufacturer specific.
- OPTION_INT0 = user options integer #0.
= 8 bit unsigned integer, indirectly writeable, static data base.
= linearization type - integer value.
AGENT TYPES:
The following agent types will be associated with the Input and Output words:
Note: "Active" agents will include Off-Field Bus types if, and only if,
the logical node supports that type.
INPUT0: Null, Physical I/O (SI type)
INPUT1:
IF TIME_CRIT0, bit 0 = set and bit 1 = reset:
Null, Immediate, Writeable.
IF TIME_CRIT0, bits 0 and 1 = set:
Null, Immediate, Writeable, and all Active except
physical I/O and revision number versions.
OUTPUT's 0-3
IF TIME_CRIT0, bit 8 = reset:
Null, Immediate.
IF TIME_CRIT0, bit 8 = set:
Null, Immediate, and all Active except physical I/O and

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
516
revision number versions.

In addition, IF TIME_CRIT0, bit AH = set, add
--```,``-`-`,,`,,`,`,,`---
related "with revision number" types.
ALGORITHM OPERATION:
Refer to the pseudocode for the details of the operation of this algorithm.
- The user-entered desired hardware filter time is moved to hardware (if
it is alterable); the hardware value is unconditionally moved to the
data base parameter showing the hardware filter time.
- Convert INPUT1 to ESI units, limit it, and move it to the manufacturer
specific processing area.
- Bring in the value of the major measurement and apply the triggered
calibration bias, generating INPUT0. Alternately, if triggered
calibration is triggered, back-calculate the calibration bias.
- Form INPUT0's status byte from the hardware indication of Good/Bad:
+ set bits 1 (Bad) and 2 (Not-from-Process) if Bad
+ set bit 4 (Failed) if the hardware has failed.
+ always set bit 5 (No-path-to-Process)
+ always reset all of the other 4 bits.
- Set INPUT0's status byte, bit 1 (Bad) if:
+ Bit 0 of OPTIONS0 is set and INPUT0 <= IN0_LO
+ Bit 1 of OPTIONS0 is set and INPUT0 >= IN0_HI
- Set INPUT0's status byte, bit 6 (ATW-h) if:
+ INPUT0 >= IN0_HI
- Set INPUT0's status byte, bit 7 (ATW-l) if:
+ INPUT0 <= IN0_LO
- Limit INPUT0 to the IN0_LO to IN0_HI range.
- Convert INPUT0 to "CUV" - calibration unit value - and generate its
status byte.
- Linearize and damp INPUT0 to generate "LV" - linearized value and
generate its status byte.
- Convert LV to "UUV" - User unit value and generate its status byte.
- Clamp UUV to form "CV" (clamped value) and generate its status byte.
Set CV Bad if:
+ Bit 2 of OPTIONS0 is set and CV = LIM_LO
+ Bit 3 of OPTIONS0 is set and CV = LIM_HI
- As a function of mode, move CV and its status byte into OUTPUT0,
resetting status bits 4, 6, and 7 if the agent is active.
- Move any auxiliary variables to OUTPUT's 1-3, resetting their status
bits 4, 6, and 7 if the agent for the output is active.
STATUS VALUE HANDLING:

- INPUT1 may have a valid value but be marked Bad. If it is, its value
will be converted and set into EV; EV's value will be marked Bad.
Alternately, if the value of INPUT1 is NaN, the existing value of EV

will be left unaltered but it will be marked Bad.
In yet another alternate case, the value of INPUT1 may be Good but the
INPUT1 conversion may fail. In that event, EV will be marked Bad but
its value will be left unchanged. Similarly, EV may be at or beyond
its limit. It will be clamped at the limit and optionally marked Bad
(based on Bits AH or BH of OPTIONS0).
If EV has a valid value but is marked Bad, its value will be passed to
the measurement circuit and the major measurement returned by the
circuit will be marked Bad. Those auxiliary variables that depend on
the EV will also be marked Bad.
Any time a value is marked Bad, it will also be marked "Not-from-

Process". INPUT1 and EV will always be marked "No-path-to-Process".
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#

517
If INPUT1 is supported, then bit CH in OPTIONS0 selects the response

to a Bad value in INPUT1. If that bit is set, the block is not in O/S
mode, and INPUT1 is Bad, the block will change to Man mode and issue a
"Man mode forced by Bad INPUT1" alert.
- Bad may be set for the major measurement by the hardware input to
INPUT0. It may also be set if INPUT0 is at or beyond the instrument's
range limit and OPTIONS0, bit 0 or 1, whichever is applicable, is
set.
The Good/Bad of INPUT0 flows serially to the LV, UUV, and then CV. At
each step, the flowing Good/Bad status will be set Bad if the
operation fails. If the value exceeds the output limits, it will be
limited and can optionally be marked Bad. In Auto mode, the status of
CV is placed into OUTPUT0.
In Man mode, the Good/Bad status of OUTPUT0 is left alone.
Bad is set in all status bytes unconditionally on transition to O/S

but not during O/S.
- Bad may be set for any individual auxiliary measurements by the
hardware; the Good/Bad status will flow to their OUTPUTx.
- "Not-from-Process" is set any time a value with a status byte is not
derived from the process hardware, including when the value is Bad.
If INPUT1 is "From-Process", then that status can flow to EV but not
if the INPUT1 Conversion fails. "Not-from-Process" is set in OUTPUT0
when the mode is not in Auto except it is set on transition to O/S,
not during O/S.
- The "Fail" bit of the status byte of INPUT0 is set if the hardware
indicates a failure (independent of bit 9 in FAIL_OPT0). The "Fail"
bit of the status bytes of OUTPUT1-3 are set if the hardware indicates
a failure and the appropriate bits of FAIL_OPT0 are reset. A "Bad"
value of EV will NOT be a basis for setting "Fail". The current value
of the "Fail" status will flow through calibration unit conversion to
CUV and through the intermediate steps to CV. If the mode is Auto, it
will flow to OUTPUT0 under control of bit 9 in FAIL_OPT0. It will be
reset on transition to O/S mode and not changed during O/S mode.
- "No-path-to-Process" is always set in all status bytes except it is
set on transition to O/S, not during O/S. The path through INPUT1
to the measuring hardware IS NOT a "path to the process".
- Bits 6 & 7 (wound-up-hi and wound-up-lo) in all status bytes are
always set on transition to O/S mode but not during O/S. The existing
state of bits 6 & 7 will not be manipulated on transition to, or
during, IMan or Man mode. In addition, bits 6 & 7 in the status bytes
of the main measurement values and of all of the output values will
reflect any hardware or software limits.
- Status bits 3 and 4 are always reset in all status bytes xcept:
--```,``-`-`,,`,,`,`,,`---
+ bit 0 (No-Com) may be set if the INPUT1 agent is active.
+ they are reset on transition to O/S mode, not during O/S mode.
DETAILS OF PARAMETERS:
- Hardware Value
+ Physical node data base, parameter "I/O_VALUE".
+ Supported if bit 3 in TIME_CRIT0 is set.
+ Defined in the physical node as 16 bit unsigned integer.
+ Major measured input, before triggered calibration bias, provided
as a fraction of the full instrument range (all bits to the right
of the radix point).
- I/O Parameters:
+ INPUT0 = hardware value with optional triggered calibration bias.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
= read-only
= 4 byte floating point, with status
= in ESI units.
+ INPUT1 = present if, and only if, bit 0 set in TIME_CRIT0.

518
= writeable according to the normal agent rules.

= 4 byte floating point, with status.
+ OUTPUT0 = Output of the block (after output limits)
= major measurement linearized, damped, converted
to user selected units, clamped, and mode controlled.
= indirectly writeable in any mode except Auto.
+ OUTPUT1 = present if, and only if, bit 5 is set in TIME_CRIT0.
= value of auxiliary variable 1 in ESI units.
- if the cold junction temperature in a temperature
transmitter is one of the auxiliary variables, it
must be assigned to this Output. Otherwise, if the
body temperature of the transmitter is one of the
auxiliary variables, then it must be assigned to this
Output.
= indirectly writeable only in O/S mode.
- if the process fluid pressure is one of the auxiliary
variables, it must be assigned to this Output.
- if the process fluid density is one of the auxiliary
variables, it must be assigned to this Output.
--```,``-`-`,,`,,`,`,,`---
Note: if bit 8 is set in TIME_CRIT0, then the OUTPUT's can support
an active agent. Therefore, they need a cyclic read buffer
and the local variable versions of the OUTPUT value (see page
10 of the paper "Function Block Structure").
- User Set Parameters (under the tuning attribute)(not mode controlled):

+ DAMP = Software damping time constant.
= floating point value, expressed in seconds
+ FREE_STAT = free static data base floating point value.
- Stored Internal Parameters:
+ MIN_TC0- "Minimum" image of TIME_CRIT0 defined above.
= required
= 16 bit binary string, static data base, indirectly
writeable.
= see the paper "Data Owner Structure - Hardware", page 22,
for a description of the exactly analogous variable in the
physical node.
+ HFILTER_SP = Desired hardware filter time.
= always present, even if filter not adjustable.
= 16 bit unsigned integer, first order filter
time constant, expressed in milliseconds.
= static data base, indirectly writeable
+ INPUT1
@ These parameters only exist when Bit 0 of TIME_CRIT0is set.
@ IN1_UNIT_DESC = Units description for INPUT1.
= static data base, indirectly writeable.
(See page 7 of "Human I/F Considerations" paper.)
@ IN1_DESC_ATT = Descriptor attribute for INPUT1.
@ IN1_DISPLAY_LO and IN1_DISPLAY_HI = display range of INPUT1.
@ START_BAD_LIMIT = number of cycles after FORCE_INIT goes to
zero before the mode will automatically
switch to Man with INPUT1 Bad and the
option set by the user.
= unsigned 8 bit integer, defaults to 0.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
519
+ EV
This set of parameters is present if, and only if, bit 0
is set in TIME_CRIT0 options bit string.
@ External Value = EV = INPUT1 converted to ESI units.
= in ESI units.
= dynamic data base, read-only
@ EV_LO and EV_HI = instrument limits for EV
= same ESI units as EV
= 4 byte floating point, without status
= ROM
@ EVM and EVB = INPUT1 conv. slope and bias constants.
= 4 byte floating point, no status.
EVM units not stated.
EVB in units of EV.
@ EV_SI_UNIT0 and EV_SI_UNIT1 = ESI units for EV
= ROM
(See page 7, "Human I/F Considerations" paper.)
+ INPUT0
@ HFILTER = the actual hardware first order filter time.
= 16 bit unsigned integer - value in milliseconds.
= always present, even if filter not adjustable.
= read-only
@ IN0_LO and IN0_HI = instrument limits for INPUT0
= exist if, and only if, bit 2 of TIME_CRIT0 is set.
= in the same ESI units as INPUT0.
= 4 byte floating point, no status, read-only if
triggered calibration is supported, else ROM.
Note: if triggered calibration is supported, then these
values must include the effect of the bias terms.
The values must correspond to INPUT0 at the
limits. In addition, these are to be hard
limits, not nominal limits nor necessarily the
range for which accuracy is quoted.
@ IN0_SI_UNIT0 and IN0_SI_UNIT1 = ESI units for INPUT0
= ROM
+ CUV
@ Calibration Unit Value = CUV = INPUT0 converted to user
--```,``-`-`,,`,,`,`,,`---
defined calibration units.

= in user defined calibration units.
@ CUM and CUB = coefficients in calibration unit conversion
equation
= always present.
= 4 byte floating point.
CUM units not stated.
CUB in units of CUV
@ CUV_UNIT_DESC = Units description for CUV
@ CUV_DESC_ATT = Descriptor attribute for CUV.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
+ LV
@ Linearized Value = LV = INPUT0 linearized, then damped
= in ESI units.
@ LVM, LVB, AND LVC = coefficients in linearization equation.
= always present independent of supported
linearization types.

520
LVM = multiplier in the linearization equation

(units not stated).
LVB = bias in the linearization equation (units
of LV).
LVC = dimensionless exponent in the
linearization equation.
@ LVB_SI_UNIT0 and LVB_SI_UNIT1 = ESI units for LVB
@ LV_SI_UNIT0 and LV_SI_UNIT1 = ESI units for LV
= dynamic data base, read only.
+ UUV
@ User Unit Value = UUV = LV converted to user units.
= in user units.
= dynamic data base, read-only (units of
OUTPUT0).
@ UUV_LO and UUV_HI = instrument limits for UUV
= exist if, and only if, bit 4 of TIME_CRIT0
is set.
= in the same units as UUV.
= generated by passing IN0_LO and IN0_HI
through linearization and user units
conversion.
= 4 byte floating point, no status, read-only
(units of OUTPUT0).
@ UUM and UUB = coefficients in unit conversion equation
= always present.
UUM = multiplier in the units conversion
equation (units not stated).
UUB = bias in the units conversion equation
(units of OUTPUT0).
+ CV
@ Clamped Value = CV = UUV clamped.
= in user units.
= dynamic data base, read-only (units of
OUTPUT0).
+ OUTPUT0
@ OUT0_UNIT_DESC and OUT0_DESC_ATT - units description and
descriptor attribute for OUTPUT0.
(Also used for UUV and CV.)
@ OUT0_DISPLAY_LO and OUT0_DISPLAY_HI = display range of
OUTPUT0.
+ OUTPUT1
@ OUT1_LO and OUT1_HI = instrument limits for OUTPUT1
is set.
--```,``-`-`,,`,,`,`,,`---
= in the same ESI units as OUTPUT1.
= 4 byte floating point, no status, ROM
@ OUT1_SI_UNIT0 and OUT1_SI_UNIT1 = ESI units for OUTPUT1
= ROM
+ OUTPUT2
is set.
= ROM
+ OUTPUT3

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
521
is set.
= ROM
+ Parameters of the Triggered Calibration procedure (if, and only
if, TIME_CRIT0, bit BH is set).
+ As many sets of parameters of the Standard limiting function
parameters as there are Output's (if, and only if, TIME_CRIT0,
bit 9 is set) (operates on CV and OUTPUT1-3).
+ Parameters of the Standard PV function (if, and only if,
TIME_CRIT0, bit CH is set).
ALERT SUPPRESSION:
- In the scheme to suppress multiple hardware failure alerts, OUTPUT2
will be superior to OUTPUT3 and OUTPUT3 will be superior to OUTPUT1.
- A failure of INPUT0 will unconditionally suppress any alerts for
OUTPUT0-3 that occur in the same cycle.
- A failure of INPUT0 is reported only if bit 0 in FAIL_OPT0 is set.
HARDWARE FILTER:
- A manufacturer may allow the user to adjust a hardware first order
filter on the major measurement. This filter is intended to be
optimized for the best measurement of the process signal by the
instrument; it is not expected to be optimized for process control
(Note that damping for control should be done after linearization.)
- Since this filter is optional, there is a need to retain the optimum
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
filter value when a device without the option is used temporarily.

Therefore, there are two data base variables as well as the "remote
hardware setting":
+ HFILTER_SP = the desired hardware filter time
+ HFILTER = the actual hardware filter time
- If the device does not support adjustment of the hardware filter (bit
0 of N_TIME_CRIT0 = reset), then the value of HFILTER_SP will be
ignored (but allowed to remain unaltered in the static data base).
The value of HFILTER will be supported: it might be in ROM.
- If the device allows the adjustment of the hardware filter, the
algorithm will move HFILTER_SP into the hardware filter and into
HFILTER every block cycle.
OPTIONAL INPUT1
Some devices need an external variable in order to measure their major
variable. For example, some devices that measure the temperature of the contents
of a tank must be supplied with the tank level. INPUT1 will be used to introduce
such a value.
The existence of INPUT1 is optional. In addition, when INPUT1 is

implemented, the manufacturer can choose to provide only a null and two types of
writeable agents, or to provide a full active agent. The two option levels are
indicated by bits 0 and 1 in TIME_CRIT0, the manufacturer's option bit string.
The model of the Standard analog input block with INPUT1 is based on the
assumption that the value that is provided to the manufacturer specific portion
of the block is in the ESI units specified by the manufacturer. Therefore, the
INPUT1 value must be converted from user units to ESI units as shown in Figure 1.
The equation that will be used for the conversion is:
EV = EVM * INPUT1 + EVB
where EVM = the INPUT1 to EV unit conversion multiplier.
EVB is the INPUT1 to EV unit conversion bias.

--```,``-`-`,,`,,`,`,,`---

522
The converted value, in ESI units, is called the "External Value" (EV). The
lower and upper limits of EV are set by the ROM values EV_LO and EV_HI; they are
called the instrument limits for EV. If INPUT1 is supported, then the value of
EV will be forced to be between EV_LO and EV_HI. Options bits AH and BH in
OPTIONS0 will be supported; an outlying value of EV will be marked Bad according
to the options selected by the user in bits AH and BH.
If the field device supports triggered calibration (bit BH in TIME_CRIT0),
then it will accept the calibration points in terms of the units of CUV. The
bias will be applied to the major measurement value before it is identified as
INPUT0. In order to retain correspondence, the values of IN0_LO and IN0_HI will
also have to be adjusted.
GO BAD AT END OF RANGE:

It is assumed that INPUT0 and the 0 to 3 measurements that will form OUTPUTS
1-3 all have finite range limits that are known to the manufacturer or can be
determined in operation. When one of these values is supported and its value as
--```,``-`-`,,`,,`,`,,`---
obtained from the hardware is at a range limit, it may be marked Bad at the
option of the user. The option for INPUT0 is defined in bit 0 and 1 of the
OPTIONS bit string while the options for OUTPUTs 1-3 are defined in bits 4 - 9 of
the same parameter.
CALIBRATION UNITS CONVERSION:

- Calibration Unit Conversion is provided to allow the user to convert
INPUT0 (in ESI units) to units which relate to the calibration devices
in the user's facility. For example, many U.S. users calibrate
differential pressure transmitters with a signal in units of "inches
of water", not the ESI unit, Pa.
- CUV = CUM * INPUT0 + CUB
where CUM = the calibration unit conversion multiplier.
CUB is the calibration unit conversion bias.
- The multiplier CUM is not always positive. For example, if LV is a
pressure in Pag (Pa gauge), and the user displays UUV in "inches Hg
vacuum", CUM will be negative.
LINEARIZATION PROCEDURE:
- Correct for the non-linearity of the physical measuring system
using a user-selected linearization procedure. The manufacturer
indicates which of the procedures defined in Table 1 are supported
using N_TIME_CRIT0 and, optionally, any of N_TIME_CRIT1-3. The user
selects one of them by configuration by setting the integer identifier
of his choice in OPTION_INT0.
- Some of the linearization methods use the bias term LVB. Its ESI
units can be configured by the user. When LVB is active in the chosen
linearization equation, its ESI units descriptor and attributes will
be transferred from LVB_SI_UNIT0 and LVB_SI_UNIT1 to LV_SI_UNIT0 and
LV_SI_UNIT1 respectively. Otherwise, the values in the LVB locations
will be ignored and the block will set the values of the LV locations
based on the linearization method chosen.
DAMPING PROCEDURE:
- The "software" filter allows the user to apply a first order filter
to remove high frequency noise from the measurement value for purposes
of improving process control as opposed to signal measurement.
- The first order exponential filter will follow the rules for filters

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
523
given in the paper "Standard Block Functions".
USER UNITS CONVERSION:

- User Unit Conversion is provided to allow the user to convert LV (in
ESI units) to the engineering units appropriate for the use of the
measurement in the control scheme. For example, a differential
pressure in Pa**1/2 may be converted to barrels per day of flow.
- UUV = UUM * LV + UCB
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
where UUM = the unit conversion multiplier.
UUB is the unit conversion bias.
- The multiplier UUM is not always positive. For example, if LV is a
pressure in Pag (Pa gauge), and the user displays UUV in "inches Hg
vacuum", UUM will be negative. All references to "HI" and "LO" refer
to the algebraic value of the variable in its own units. For
example, INPUT0 could be near its HI limit and CV near its LO limit
simultaneously.
CLAMPING PROCEDURE:
The clamp function is a minor extension of the Standard block function called
limiting. It simply adds options (bits 2 and 3 in OPTIONS0) that allow the
following logic:
Retain the previous setting of the CV Bad status bit.
The status of CV = the status passed from UUV.
IF the value of UUV is within limits, then
The UUV value is moved to CV.
IF bit 2 in OPTIONS0 is set, then
IF CV was Bad after the last execution, then
IF [(CV - LIM_LO) < LIM_DEADBAND], then
mark the status of CV Bad
IF CV was Bad after the last execution, then
IF [(LIM_HI - CV) < LIM_DEADBAND], then
ELSE
The value of CV is set to the exceeded limit, LIM_LO or LIM_HI.
IF the low limit is exceeded, then
IF the high limit was exceeded, then
Note: any time Bad is set, "Not-from-Process" is also set.
If the user options are configured to "go Bad", the value of CV will be
marked Bad when a limit is exceeded and will remain Bad until UUV moves into the
good range by more than the configured deadband. This is done in order to avoid
chattering of the status byte and the "Bad" alarm.
There is no option to set the block mode to Man when OUTPUT0 goes to "Bad".
Since OUTPUT0 of an AI block may be used in a number of different applications in
parallel, including the normal process history collection system, the "go to Man"
option is provided at the blocks that would use OUTPUT0 (when appropriate) rather
than at the producer. Note that INPUT1 is an example of such a user.
UUV RANGE:
The instrument range is given by IN0_LO and IN0_HI. However, these two
values are in ESI units: units usually not very meaningful. As an option, the
manufacturer may choose to set bit 4 of TIME_CRIT0 and provide UUV_LO and UUV_HI.
These two values are calculated by passing IN0_LO and IN0_HI through
linearization and user unit conversion. Note that these conversions are modeled
as being done every cycle because the type of linearization and the coefficients

--```,``-`-`,,`,,`,`,,`---

524
for user unit conversion can change at any time. Also, the value of IN0_LO and
IN0_HI will change if triggered calibration is executed.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
An Analog Input (AI) block is used to measure one major physical variable
that is a scalar value, such as flow, temperature, pressure, or angle position.
It is associated, via. its hardware pointer, to a set of physical node hardware
of the scalar input (SI) type. There is hardware and software in the signal flow
of a measuring device, as shown in Figure 1. The physical variable is sensed
with a "primary sensor", typically using industry standard or industry-accepted
techniques. For example, an orifice plate for flow measurement, a thermocouple
for temperature measurement, a mechanical encoder for shaft angle, and so forth.
The output signal of the primary sensor is applied to the transmitter

hardware: to the SI connection. This connection may be "exposed", as in a
thermocouple transmitter, or it may be "hidden" within a single total device. If
it is exposed, the labeling rules given in the paper "Data Owner Structure -
Hardware" must be followed.
In Figure 1, the transmitter hardware is divided into "transmitter sensor",

"front-end circuit", and "analog to digital converter". Examples of the hardware
are the pressure sensor of a pressure transmitter, and the amplifier and cold
junction compensation of a temperature transmitter. The output of the
transmitter hardware is in a digital form.
Some measuring devices in which the hardware handles auxiliary variables

exist in industry today. An example is the meter body temperature of a
differential pressure transmitter. A simple provision for those variables is
included in the design of the Standard SI hardware and in the AI block.
The digital output of the hardware is sent to software, called

"Manufacturer's Signal Processing" (MSP). The MSP handles the unique
characteristics of the preceding transmitter hardware which are typically vendor
specific. Consequently, the design of the AI block assumes MSP, as indicated by
its name, to also be vendor-specific. The output of the MSP is scalar
information. If triggered calibration is supported, the bias term calculated
from the linear calibration correction will have been added to the value by the
MSP. For example, in a thermocouple transmitter, the output will already be cold
junction compensated and calibration corrected but it will be linear with the
thermocouple voltage, not with temperature. In a differential pressure
transmitter, it will be calibration corrected and linear with differential
pressure, not with flow.
The major measurement is called INPUT0 at this point. It is required by this

Standard to exist as a four byte floating point value in a worldly accepted type
of signal, expressed in "Extended International Standard" (ESI) units. For
instance, the accepted type of thermocouple signal is a voltage signal in the
units of volts (mostly x 10**(-3) V); and that of a differential pressure
transmitter for flow measurement is a pressure signal in Pascals (mostly x 10**3
Pa or kPa).
This Standard allows the major signal to be in any convenient units but
absolutely requires ESI units. It is expected that the signal type will be
designed to correspond to the recommended calibration signal. For example, most
temperature transmitters are calibrated with a millivolt generator, not with a
constant temperature bath. In addition to the major measurement, the MSP
provides information for the status byte associated with the major measurement
and the value and status of the auxiliary variable(s). The value of the
auxiliary variables are not accessible by Field Bus at this point. They can be
in any form.
This Standard makes no attempt to standardize the primary sensor, transmitter

hardware, and MSP portions preceding the AI block, other than the outputs of MSP
that are passed to the Standard AI block.

--```,``-`-`,,`,,`,`,,`---

525
The AI block receives the signals from MSP through the INPUT0 connection, a
hardware pointer. If the device supports auxiliary variables, they are included
as part of the INPUT0 connection. Physical devices that can support multiple
major SI signals would necessarily allow multiple AI blocks.
The connection between the MSP and the AI block is bi-directional. The data
flow in the reverse direction is, for example, data for setting the hardware
filter, triggering data conversion, and/or calibration of the MSP, as discussed
below. If the block supports INPUT1, then its value and status may flow to the
MSP. The bias values calculated by the triggered calibration procedure will be
added into the major value measurement before it exists as INPUT0.
The manufacturer may choose to design the Field device in such a way that the
hardware and the communication logic can continue to operate despite the fact
that the logic engine that executes the function blocks has failed. Given such a
design, the manufacturer may set bit 3 in the TIME_CRIT0 options bit string to
indicate to a higher level device that it may be able to read the value of the
input directly from the hardware in an emergency. When that functionality is
provided, the value of the major measurement will be found in the physical node
parameter "I/O_VALUE". The parameter will be a 16 bit unsigned integer; the
value is to be taken as a fraction of the instrument's range. The parameters
IN0_LO and IN0_HI define the range of INPUT0 and of this value. The
manufacturers of higher level devices are able to convert the value to a more
useful indication for the operator.
The AI block is modeled as transferring the auxiliary values from the

hardware directly to Outputs 1, 2, and/or 3. It is required that these Output
values be in ESI units and 4 byte floating point data format. They are available
for reading by other entities on Field Bus.
OUTPUT's 1-3 have status bytes. Bit 1 (Bad) and bit 2 (Not-from- Process)
will be set if the hardware indicates that the value is not good or, at the
user's option, at the range limit. Bit 4 will be set any time the hardware
recognized that the measuring equipment has failed. Bit 5 (No-path-to-Process)
will be set any time the block is not in O/S mode. Bits 6 or 7 will be set if the
value is at a limit. Status bits 0 and 3 will be reset.
When the block transitions to O/S mode, bits 1, 2, and 5 will be set
immediately after the transition. In subsequent cycles of O/S operation, all
values and status bytes will be left unaltered by the algorithm.
If the body temperature of the transmitter hardware is one of the auxiliary

values, the Standard requires that it be connected to OUTPUT1. In the particular
case of thermocouples, it is required that the cold junction temperature (CJT),
if presented as an auxiliary variable, must be connected to OUTPUT1; if both the
CJT and the device temperature are measured, the CJT will be assigned to OUTPUT1.
Likewise, if the static (process) pressure is one of the auxiliary variables,

it must be connected to OUTPUT2. If the fluid density is one of them, it must be
connected to OUTPUT3. There is no requirement that OUTPUT1 and/or OUTPUT2 be
supported when OUTPUT3 is supported.
--```,``-`-`,,`,,`,`,,`---
The AI block is modeled as applying "calibration unit conversion" to the

major measurement from the hardware to yield the "calibration unit value" (CUV).
The CUV is intended to provide the major measurement in the units desired for
calibration and maintenance. For example, the user of a differential pressure
transmitter may calibrate the transmitter in units of inches of water. In that
case, the calibration unit conversion simply converts Pascals to in. H2O. This
value has a status byte.
Most importantly, the AI block is modeled as applying a series of conversions

to the major signal obtained from the SI hardware. It applies "linearization and
damping" to the measurement of the major value to produce the "linearized value"
(LV). This value is required to be in ESI units. It applies "user unit
conversion" to the LV to generate the "user unit value" (UUV). This value is in
whatever units of measurement are desired by the user.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
526
Clamping is applied to the UUV to produce the "clamped value" (CV). The
clamping is simply the standard block function of limiting plus a user option to
set the value Bad if it is limited. The option is provided independently at the
low and high limits.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Finally, the CV is passed through mode control to the OUTPUT0 value. If the
mode is Auto, the value of CV is moved to OUTPUT0. If the mode is higher
priority than Auto but not O/S, the value in OUTPUT0 is left unaltered except bit
2 in the status (Not-from-Process) will be set. The value will be left unaltered
but marked "Bad" and "Not-from-Process" when the mode transitions to O/S mode.
For subsequent cycles in O/S, any value and status in the OUTPUT's will be left
unaltered.
All four of the values in this series are 4 byte floating point data types
and all have status bytes associated with them.
A manufacturer may decide to offer the ability to generate alarms on the

process values. If so, the optional "PV Pointer" standard block function will be
supported. When it is, the user can configure the PV pointer to select any of
the block variables defined here that have a 4 byte floating point data type as
the "PV". The block's alarm processing will be done on the selected variable.
When the PV pointer is not supported, the parameter "PV" must still be supported:
it will be identical to OUTPUT0 but there will be no process alarms. The
"target" value and its default parameter, FREE_STAT, will ALWAYS be provided.
It should be noted that application of the AI block is not limited to flow,

pressure, temperature, and level. It can handle any one of many instantaneous
physical variables that can be measured with a single sensor and converted to a
four byte floating point number via MSP. For clarification, consider a
mechanical encoder; some may call it a "mechanical analog digital converter". It
is used to measure mechanical position, level, shaft angle, and the like. Its
output is in a certain code, say gray code. The output may be received by a
(vendor-specific) MSP in the same physical node. This may convert the encoder
output to a four byte floating point signal which is transferred to the AI block.
The AI block converts the angle to the units desired by the user and presents the
result as OUTPUT0.
LINEARIZATION AND DAMPING DESCRIPTION:

The "Linearization and Damping" portion of an AI block receives INPUT0 and
its status byte from the MSP; it produces the linearized value (LV). Both values
must be 4 byte floating point numbers in ESI units.
The Standard types of linearization are specified in Table 1. The types are
prepared for the primary sensors that are industry standards or are widely
accepted by the industry. When a vendor-specific primary sensor that is non-
linear is used, the required linearization may be made by the MSP with the
configured linearization being set to unity. Alternately, it may use piecewise
approximation (multi-segment curve) or a polynomial in the linearization section.
It is necessary to define the units for LV. In many cases, the units are
known explicitly from the linearization method: they are either defined by the
method or are identically the same as the units of INPUT0. In other cases, the
units are only known to the configurator. However, in all of these latter cases,
the term LVB appears in the linearization equation and its units must be the same
as the units of LV. Therefore, the following procedure will be used in a
Standard AI block:
- the LVB term will always be supported in the data base (as well as
LVM and LVC)
- there will be SI_UNITx parameters to describe the units (ESI) of LVB.
- if the linearization method does not use LVB, the above parameters
will be ignored (and left unchanged). The algorithm will provide the
--```,``-`-`,,`,,`,`,,`---
units for LV.

- if the linearization method does use LVB, the SI_UNITx values of LVB

527
will be moved, by the block at every cycle, into the SI_UNITx of LV.
This will be done even if the value of LVB is equal to zero.
- The SI_UNITx of LV will always be read-only.
The specific form of the piecewise approximation and polynomial linearization

equations will be vendor-specific. (Although the general form of their equation
is know, the number of the approximation segments or the order of the polynominal
equation is selected by the vendor.) The coefficients that are needed by the
equation are to be defined using an optional physical node Auto-format variable,
either defined for each hardware instance or for the hardware type.
Piecewise approximation and polynomial curve representations may be used with

individually calibrated thermocouples, for example. Another example is a
radiation pyrometer with an input color filter. (A pyrometer that employs total
input radiation may use the exponential linearizer.)
In a device that supports the exponential type of linearization, a

manufacturer may have the calculation procedure convenient to calculate the
damping factor exactly instead of calculating it from the first two terms of the
factorial expansion. That is UNACCEPTABLE. The damping factor is DEFINED to be
based on the first two terms of the expansion.
In the exponent type of linearization, if INPUT0 is small, LV and its status

byte will be set as follows:
The manufacturer defines the minimum limit for the absolute value
of INPUT0.
Set an alarm if the absolute value of INPUT0 is smaller than the minimum
calculation limit.
Leave the previous value in LV unaltered.
Set bit 1 (Bad) in the status byte of LV, UUV, CV, and, if in Auto mode,
OUTPUT0.
--```,``-`-`,,`,,`,`,,`---
The trigonometry functions, sine or cosine, may be used to convert the angle
data received from a shaft encoder to an expression of linear position.
In the computation of the differential pressure flow linearization, INPUT0

may be found to be negative, as from a reverse flow measured by an orifice plate.
The computation will be done as shown in the table: the square root of the
absolute value of INPUT0 will be calculated, then multiplied by the sign of
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
INPUT0 and the coefficient.
The second portion of the "Linearization and Damping" step provides a simple
first-order exponential filter for the result of the linearization calculation.
It is absolutely required that the linearization be done first, then the damping.
Note that the first two terms of the factorial series expansion of the first
order exponential is defined to be the correct implementation of an exponential
filter - an exact solution is defined to be incorrect. The filter time is given
in seconds.
AI BLOCK APPLIED TO MULTIPLEXING:

In a multiplexer with n primary sensors or channels, n AI blocks will be used
with a tag name given to each block. For example, a 32 channel temperature
multiplexer using 32 thermocouples should use 32 AI blocks. If this is done in a
time standard logical node, the devie is NOT considered "a multiplexer".
A multiplexer based on AI blocks will only be considered "standard" when it

is implemented in a cycle/phase logical node. It:
1) Will support the BX and PN variables in each block.
2) Will support all of the required items listed for standard AI blocks
implemented in timed standard logical nodes.
3) Will typically support the "revision number" option (bit AH in
TIME_CRIT0 = set). This function will provide a 16 bit integer
revision number associated with all supported OUTPUTx's. The number
will be initialized to the system time when the logical node starts

528
in the same way that the block static data base revision number is
initialized. The number will be incremented every time the Output is
updated. The number can be read by an agent of the type "revision
number". The number will simply rollover when it reaches full scale.
If a multiplexer is designed to handle two or more thermocouple measurements,

and two or more of those thermocouples have a common cold junction compensation
circuit, and if the cold junction measurement itself can be connected to an AI
block, then the following logic will be followed:
CJ_BAD = reset ' logical to signal a "Bad" cold junction
IF the measured cold junction temperature is below the manufacturer's
limit, then
CJ_BAD = set
IF the measured cold junction temperature is above the manufacturer's
limit, then
CJ_BAD = set
IF an AI block is connected to the cold junction measurement, then
IF that AI block supports Output clamping, then
IF [(the measured cold junction is below the AI block's low
limit) AND (the AI block requests "go Bad" at the low
limit)], then
CJ_BAD = set
IF [(the measured cold junction is above the AI block's high
limit) AND (the AI block requests "go Bad" at the high
limit)], then
CJ_BAD = set
IF the logical node of that block supports Alert reporting, then
IF CJ_BAD = set, then
That AI block (only) will report the Bad cold junction.
CJ_BAD = reset
ELSE
IF CJ_BAD = set, then
IF the physical node supports alert reporting, then
That physical node will report the Bad cold junction
as a single physical node alert.
CJ_BAD = reset
(Refer to the Appendix paper, "Thermocouple Multiplexer and AI Blocks"

for more information.)
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
529
Analog Input - Table 1, List of Linearization Codes

Configuration
Code Bit Description Curves and Equations
0 Unity (Default) LV = INPUT0

Note: all devices must support this linearization type.
--```,``-`-`,,`,,`,`,,`---
Basic linearization types indicated by N_TIME_CRIT0:
AH AH Linear LV = LVM * INPUT0 + LVB

BH BH Differential Pres. Flow LV = LVM * (sign of INPUT0) *
[ABS(INPUT0)**1/2] + LVB
CH CH Type S Platinum-10% Rhodium/Platinum |
DH DH Type J Iron/Constantan | LV = f(INPUT0)
EH EH Type K Chromel/Alumel | f = T/C Curve
FH FH Type T Copper/Constantan |
Mathematical and Manufacturer Specific linearization types indicated

by N_TIME_CRIT1:
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
10H 0 Exponential LV = LVM * (INPUT0)**c + LVB

Note: this is the true exponential equation, not the
first two terms of the factorial expansion.
11H 1 Piecewise Approximation LV = f(INPUT0)
13H 2 Polynomial LV = f(INPUT0)
14H 3 Trigonometry - sin LV = LVM * sin(INPUT0) + LVB
15H 4 cos LV = LVM * cos(INPUT0) + LVB
5 - 9) Reserved.
AH - FH) Manufacturer specific.
Thermocouple extension types indicated by N_TIME_CRIT2:
20H 0 Type B (Platinum-30% Rhodium/Platinum-6% Rhodium)

21H 1 Type C (Tungsten-5% Rhenium/Tungsten-26% Rhenium)
22H 2 Type D (Tungsten-3% Rhenium/Tungsten-25% Rhenium)
23H 3 Type E (Chromel/Constantan)
24H 4 Type G (Tungsten/Tungsten-26% Rhenium)
25H 5 Nickel-10% Chromium (Tophel II)/Nickel-2.5%
Silicon (Nial II) (note: closely models type K)
26H 6 Type L Platinel 5355/Platinel 7674
Note: Platinel is a trademark of the Engelhard
Industries, Inc.
27H 7 Nickel-18% Molybdenum/Nickel-1% Molybdenum
28H 8 Type N Nicrosil/Nisil
29H 9 Nickel-14.2% Chromium/Nickel-4.4% Silicon-0.1%
2AH AH Chromel/Gold-0.07% Iron
2BH BH Platinum-40% Rhodium/Platinum-20% Rhodium
(Land-Jewell)
2CH CH Type R Platinum-13% Rhodium/Platinum
2DH DH Platinum-20% Rhodium/Platinum-5% Rhodium
2EH EH Platinum-13% Rhodium/Platinum-1% Rhodium
2FH FH Manufacturer Specific
RTD extension type indicated by N_TIME_CRIT3:
Note: In this list, two terms with the following meaning

will be used for Platinum RTD's:
Comm: common - an RTD with an actual temperature
coefficient of 0.003902 ohms/ohm-deg. C. This
is the result obtained for windings on pure
alumina mandrels.
IG: "International grade" temperature coefficient
based on slightly doped platinum wire. Sometimes
referred to as DIN 43 760. It has a coefficient

530
of 0.003850.
30H 0 Platinum 50 Ohms - IG LV = f(INPUT0); f = Plat. R/B Eq.
31H 1 Platinum 50 Ohms - Comm LV = f(INPUT0); f = Plat. R/B Eq.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Note: The following Nickel RTD's are assumed to have a

nonlinear temperature curve characterized by an
alpha temperature coefficient between 0 and 100 deg
C of 0.00672 ohms/ohm-deg. C.
38H 8 Nickel 10 Ohms LV = f(INPUT0); f = Ni R/B Eq.
39H 9 Nickel 50 Ohms LV = f(INPUT0); f = Ni R/B Eq.
3AH AH Nickel 100 Ohms LV = f(INPUT0); f = Ni R/B Eq.
Note: The following Nickel/Iron RTD's are assumed to have a

nonlinear temperature curve. The composition of the
alloy is 70 percent nickel/30 percent iron.
3BH BH Nickel/Iron 2000 Ohms LV = f(INPUT0)
3CH CH Nickel/Iron 10000 Ohms LV = f(INPUT0)
Note: The following RTD's are assumed to be composed of

pure copper.
3DH DH Copper 10 Ohms LV = f(INPUT0); f = Cu R/B Eq.
3EH EH Copper 25 Ohms LV = f(INPUT0); f = Cu R/B Eq.
3FH FH Copper 100 Ohms LV = f(INPUT0); f = Cu R/B Eq.
Note: the linearization option code is configured into OPTION_INT0 by

the user.
Note: default value of LVM = 1, of LVB = 0.
--```,``-`-`,,`,,`,`,,`---

531
Figure 1
ANALOG INPUT ALGORITHM
Physical Variable
Primary Sensor
Primary Signal
Vendor Specific
Transmitter Sensor
Transmitter Sensor Signal
Front-end Circuit & ADC
Digitized signal
Mfg's Signal Processing
Pointer Connection
Input 0
(SI Units) Calibration
Auxiliary Variable 1 (INPUT1)

Linearization Unit
and Damping Conversion

LV CUV
(Linearized (Calibration
EV (Ext Value)
User Unit Value (SI Units) Unit Value)

Conversion
UUV (User PV Pointer
Unit Value) Function
Clamp
Function
--```,``-`-`,,`,,`,`,,`---
CV
(Clamped
Man
INPUT1 Auto O/SValue)
Conversion
Input 1 Output 0 Output 1 Output 2 Output 3
Figure 41: Analog Input, Figure 1 Analog Input Algorithm

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

532
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Analog In Pseudocode
A Standard "Analog Input" function block is required to have a specified

functional performance. The performance is described here by a set of
"pseudocode". There is no requirement that the actual logic used be consistent
with the pseudocode in any way; only that the externally visible performance of
the actual device APPEAR to be the same as would be achieved using the
pseudocode.
The Analog Input block has several optional functions. The following
pseudocode includes all of the options. If the options bit string indicates that
one or more of the options are not supported, then the associated sections of the
following pseudocode can be ignored if there is no affect on the remaining
supported functions.
The pseudocode presented below provides the total definition of the mode and
status byte manipulation. It includes all of the applicable portions of the
pseudocode provided as Attachment 1 - "Status Logic" to the paper "Function Block
Structure".
Important aspects of the pseudocode, and absolute requirements for any

Standard implementation, are:
1) the hardware is not addressed when the block is in O/S mode.
2) the data base items that can be changed while in Auto mode are all
read from the public data base at one time as a coherent set.
3) the measurement results from the block's execution are all written
into the data base at one time, maintaining time-coherency.
4) any Field Bus access to the data base while the above data is being
read or written is blocked.
5) any Field Bus writes that occur while the block is processing but
the data base is not blocked will not be overwritten by the final
stores from the block.
6) all indicated data checking and alerts related to the base operation
and to the options that are supported are required to be implemented
in order to set bit 9 in the logical node's N_TIME_CRIT0
manufacturer's option bit string.
The manipulation of the two bit strings that report alarms and the 2 bit
strings that show unacknowledged alarms are not detailed in the pseudocode.
However, the bit strings are shown being written to the public data base at the
end of the procedure. All Standard implementations of the AI block will ensure
that these bit strings are updated coherently. Note that all alerts are released
to the User Layer Support Services immediately prior to the updating of the bit
--```,``-`-`,,`,,`,`,,`---
strings.
This pseudocode assumes that all agents are processed according to the
description in the paper "Agents". It assumes that input values are present hen
needed.
The pseudocode presented here includes certain validity checks on writeable

data that appear to duplicate the checks required in the Data Base Write Service
(DBWS). These checks must be included because the parameters in question can be
directly written from other blocks; such direct writes bypass the DBWS logic.
Alternately, if the DBWS did not include the checks, a human operator might not
be made aware of a faulty written value until up to 2 minutes after his write
command.
The pseudocode presented here uses the variable names defined in the
algorithm description paper. In addition, it uses the following notation:
MSP = the Manufacturer's Signal Processing section of the hardware.
T_VALUE = a temporary value without a status byte
T_STAT = a temporary status byte

533
T_VALUE + T_STAT = the combination of the two pieces of data to

form a value plus its status byte.
LV_x where x is an INPUT = the "local variable" version of the
or OUTPUT word I/O word - see Figure 3 in the paper
"Function Block Structure".
T_x where x is a variable = a temporary value of the variable
defined in the algorithm retained until the mass update of
description the data base values.
When referring to the block's mode, all references to a single bit will
use the word "bit"; any reference to the "byte" signifies operation
on the full byte. For example, "REQ_MODE byte = Man" means all
eight bits in the requested mode are manipulated with only the Man
mode bit remaining set to 1 at the completion of the operation.
Alternately, "Set Man bit in ACTUAL_MODE" would simply set the
manual bit in the actual mode, leaving the other 7 bits unaltered.
The sections of the pseudocode are:

Start
Read Public Data Base Values
Cleanup After Reading
Calculate External Variable (EV)
Calculate Major Values
Calculate INPUT0 - Triggered Calibration
Calculate OUTPUT0
Calculate PV Pointer Values
Get Hardware Values And Set OUTPUT1+
Wait For The End Of Block Time
Write To Data Base While Protected
ALGORITHM PSEUDOCODE:
START
' Internal parameters available to this code:
' FORCE_INIT (see the paper "Function Block Structure", page 24)
' OLD_CLAMPx
' (only exists if bit 9 in TIME_CRIT_0 is set - output
' limiting/clamping is supported)
' x = 0-3 for OUTPUT0-3
' 0 = no old clamp
' 1 = old low clamp
' 2 = old hi clamp
' IF TIME_CRIT0, bit 0 = set, then
' START_BAD_COUNT must be supported.
' This is the internal counter that is initialized to
' START_BAD_LIMIT (see the AI algorithm definition,
' page 7).
' SUPPRESS = control integer used to implement alert suppression
' as defined in the paper "Function Block Structure",
' page 23.
' 0 = no suppression
' 1 = suppress "Bad"
' 2 = suppress "Fail" and "Bad"
'
IF ACTUAL_MODE <> O/S, then
IF the hardware needs to be triggered ahead of time to snap a sample,
. then
' Note: If a user-configurable hardware filter or INPUT1 are
' supported, this is the least satisfactory time
' location to trigger the hardware that will satisfy the
' requirement of a Standard AI block.
. At the appropriate time to accomplish the timing required in the
. paper "Data Owner Structure - Hardware", page 9:
. IF N_TIME_CRIT0, bit 0 = set, then
. IF FORCE_INIT >= 2, then
. Hardware filter time constant = 0 or a manufacturer-
. set minimum reasonable value.

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
534
'A minimum value is entered for the

'FORCE_INIT = 3 and 2 cycles so that a
'long filter time constant does not lock
'a meaningless value in the filter.
. IF FORCE_INIT < 2, then
. Hardware filter time constant = HFILTER_SP
' HFILTER_SP is the configured hardware filter
' time.
' Note: after the FORCE_INIT = 3 and 2 cycles,
' the configured desired filter value
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
' will normally be used.

' Note: in some devices, it may be appropriate
' to delay the filter until INPUT1 is
' NOT Failed and NOT Bad. A manufacturer
' is encouraged to select the best
' handling and delay when INPUT1
' interactes with the filter.
. Trigger hardware to start analog to digital conversion.
' Note: When triggered here, the hardware will use a
' hardware filter time that is not time-coherent
' with the rest of the block data and, if INPUT1 is
' supported, this procedure will cause a 1-cycle
' delay in the value that is used. Such
' shortcomings are acceptable but not required
' nor desired.
At the start of the normal block algorithm time,
BAD_CONFIG = reset ' a logic flag, set if bad block config.
FORCE_OS = reset ' a logic flag, set if must force O/S mode.
SUPPRESS = 0
IF FORCE_INIT > 1, then
SUPPRESS = 1
TC = reset ' a logic flag, set if trig. cal. supported
IF {[TIME_CRIT0, bit BH = Set] AND [(N_TIME_CRIT0, bit 1 = Reset) OR (CX >
MX)]}, then
. TC = Set
' The IF tests to see if triggered calibration is supported.
' The calculation is done here once to gain efficiency and reduce
' the time that the Field Bus accessible memory is blocked.
IF this logical node supports alert reporting, then
. Capture node time
' The node time should be captured at this point; this is the
' time that should be used for all alerts generated during this
' cycle of this block.
' *************************************************************
' *************************************************************
' ** **
' ** READ PUBLIC DATA BASE VALUES **
' ** **
' *************************************************************
' *************************************************************
'
Request User Layer Support Services to block public access to this tag's
. memory.
Unconditionally reset all REQ_MODE bits except O/S, Man, and Auto.
Unconditionally reset all permitted mode bits except O/S, Man, and Auto.
IF REQ_MODE not permitted, then
. REQ_MODE byte = reset
IF [(no REQ_MODE bits are set) OR (two or more REQ_MODE bits are set)], then
. REQ_MODE byte = the mode of the lowest priority mode bit set in
. ACTUAL_MODE
. (no bits set if actual mode has no bits set).
IF no REQ_MODE bits are set, then
. REQ_MODE byte = O/S
IF the O/S mode bit is set in REQ_MODE, then
. IF ACTUAL_MODE <> O/S, then
. All status bytes in the block = 11100110B.
' The status bytes are all set to "Bad", "Not-from-Process",

--```,``-`-`,,`,,`,`,,`---

535
' "No-path-to-Process", and "wound-up".

. ACTUAL_MODE byte = O/S.
. FORCE_INIT = 3
ELSE
. IF the hardware was not triggered before the block executed, then
. IF N_TIME_CRIT0, bit 0 = set, then
. IF FORCE_INIT <= 2, then
. Hardware filter time constant = 0
. IF FORCE_INIT < 2, then
. Hardware filter time constant = HFILTER_SP
' Note: see comments at earlier instance of setting
' the filter time constant.
. IF hardware triggering can not wait until the next opportunity because
. of the time limit, then
' This place in the logic is ideal for triggering the
' hardware if INPUT1 is not supported because the time
' coherent value of the hardware filter is in place.
. HFILTER (hardware filter time) = Hardware filter time constant.
' this step is required even if HFILTER_SP is not supported.
'
'
' read user options
. T_OPTIONS0 = OPTIONS0 ' user option bit string
. T_OPTION_INT0 = OPTION_INT0 ' user option integer
' read block configuration that can be changed while mode <> O/S
. T_REQ_MODE = REQ_MODE ' requested mode (possibly modified)
. T_DAMP = DAMP ' software filter time constant
. T_CUM = CUM ' calibration units conv. slope
--```,``-`-`,,`,,`,`,,`---
. T_CUB = CUB ' calibration units conv. bias

. T_LVM = LVM ' linearization slope
. T_LVB = LVB ' linearization bias
. T_LVB_SI_UNIT0 = LVB_SI_UNIT0 ' ESI units for LVB
. T_LVB_SI_UNIT1 = LVB_SI_UNIT1 ' ESI units for LVB
. T_LVC = LVC ' linearization exponent
. T_UUM = UUM ' user units conv. slope
. T_UUB = UUB ' user units conv. bias
. IF TIME_CRIT0, bit 0 = set, then
' read block configuration associated with INPUT1
. T_EVM = EVM ' INPUT1 conversion slope
. T_EVB = EVB ' INPUT1 conversion bias
' read the variables associated with limiting
. T_LIM0_LO = LIM0_LO ' OUTPUT0 low limit
. T_LIM0_HI = LIM0_HI ' OUTPUT0 high limit
. T_LIM0_DB = LIM0_DB ' OUTPUT0 limit deadband
. IF bit 5 of TIME_CRIT0 = set, then
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

. IF TC = set, then
' read the variables associated with triggered calibration
. T_LO_TARGET = LO_TARGET ' the low target cal. point
. T_HI_TARGET = HI_TARGET ' the high target cal. point
. T_TRIGGER = TRIGGER ' the trigger string
' Bit 0 - calibrate lower point, leave upper alone
' 1 - calibrate upper point, leave lower alone
' 2 - bias adjust based on the lower point
' 3 - bias adjust based on the upper point

536
'
' read required variables associated with the PV function
. T_FREE_STATIC = FREE_STATIC ' free static variable
. T_FREE_DYN = FREE_DYN ' free dynamic variable
. T_TARGET_PARAM = TARGET_PARAM ' param. # of param. = target
. IF TIME_CRIT0, bit CH = set, then
' read the variables associated with the PV function that are
' present only if the function is supported.
. T_PV_PARAM = PV_PARAM ' param. # of param. = PV
. T_HIHI_ALARM = HIHI_ALARM ' hi-hi PV alarm point
. T_HI_RPT_ALARM = HI_RPT_ALARM ' high repeat alarm setting
. T_HI_ALARM = HI_ALARM ' high PV alarm point
. T_LO_ALARM = LO_ALARM ' low PV alarm setting
. T_LO_RPT_ALARM = LO_RPT_ALARM ' low repeat alarm setting
. T_LOLO_ALARM = LOLO_ALARM ' lo-lo PV alarm setting
. T_TARG_FILTER = TARG_FILTER ' target filter time constant
. T_DEV_ALARM = DEV_ALARM ' deviation alarm setting
. T_DEV_LOGICAL = DEV_LOGICAL ' deviation config. logical
. T_COMP_DB = COMP_DB ' comparator deadband
Execute Run-time Agent Logic (see the paper "Agents").
' The I/O words are assumed to have been processed by the logic
' defined for agents. Therefore, each of the non-hardware
' I/O words has already been converted according to the agents
' logic. They are thus available as LV_x and will be calculated as
' LV_x.
Request User Layer Support Services to permit public access to memory.
'
' Certain main memory values are read-only to Field Bus (at least
' if the mode <> O/S) and did not have to be read in while
' memory access was blocked. They are:
' Manufacturer's Variables:
' TIME_CRIT0
' N_TIME_CRIT0
' Variables associated with the PV function:
' PV
' Variables associated with triggered calibration:
--```,``-`-`,,`,,`,`,,`---
' LO_CAL = the current low calibration point
' HI_CAL = the current high calibration point
' Block data:
' ACTUAL_MODE = actual mode
' INPUT0
' CUV, LV, UUV, CV
' However, their new values must be written during the mass
' write to maintain coherency. Note that there are 2 mass
' writes - one if the block changes to O/S mode, the other at
' the conclusion of the normal block calculations. They are
' mutually exclusive.
'
' *************************************************************
' *************************************************************
' ** **
' ** CLEANUP AFTER READING **
' ** **
' *************************************************************
' *************************************************************
'
IF T_REQ_MODE = O/S, then
. BREAK
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
IF FORCE_INIT = 3, then
. IF the agent type for INPUT0 is not supported, then
. BAD_CONFIG = set
. IF agent type for INPUT0 = Null, then
. FORCE_OS = set
. IF the pointer for INPUT0 > number of SI hardware points in the
. physical node, then
. BAD_CONFIG = set
. IF TIME_CRIT0, bit 0 is set, then

537
. IF INPUT1 agent type not supported, then

. BAD_CONFIG = set
. ELSEIF agent type for INPUT1 = Null, then
. FORCE_OS = set
' Note: this last step can be eliminated if the block
' can determine a value for INPUT0 without a valid
' value for EV (for example, if it could assume a
' normal value for EV and simply loose accuracy
' vs. having a valid value for EV).
. IF the agent type for any supported OUTPUTx is not supported, then
. BAD_CONFIG = set
. IF agent type for OUTPUT0 = Null, then
. FORCE_OS = set
. IF BAD_CONFIG = set, then
. IF alert reporting is supported by this logical node, then
. Generate a "Bad Configuration" notification.
'Note: all alerts are held until the pseudocode indicates
' that alerts should be released to the Application
' Layer.
'Note: the use of the more detailed error codes is
' allowed and encouraged.
. IF [(BAD_CONFIG = set) OR (FORCE_OS = set)], then
. T_REQ_MODE byte = O/S
. ELSE
. Reset all agent count-out counters
. START_BAD_COUNT = START_BAD_LIMIT
. OLD_CLAMP0 = 0
. OLD_CLAMP1 = 0
. OLD_CLAMP2 = 0
. OLD_CLAMP3 = 0
. SUPPRESS = 1
. ENDIF
T_ACTUAL_MODE byte = T_REQ_MODE byte
Pass any accumulated alerts to the User Layer Support Service.
Request User Layer Support Services to block public access to this
tag's memory.
REQ_MODE byte = O/S
Update ALERT_SET0, ALERT_SET1, ALERT_UNACK0, and ALERT_UNACK1 as
necessary.
IF ACTUAL_MODE <> O/S, then
All status bytes in the block = 11100110B.
"No-path-to-process", and "Wound up".
ACTUAL_MODE byte = O/S.
. Request User Layer Support Services to permit public access to memory.
. FORCE_INIT = 3
. BREAK
'
' *************************************************************
' *************************************************************
' ** **
' ** CALCULATE EXTERNAL VARIABLE (EV) **
' ** **
' *************************************************************
' *************************************************************
'
IF TIME_CRIT0, bit 0 is set, then
. INPUT1 agent will have been processed according to the rules of agents.
. IF FORCE_INIT = 0, then
. IF LV_INPUT1 = Bad, then
. IF START_BAD_COUNT = 0, then
. IF bit CH in OPTIONS0 = set, then
. T_ACTUAL_MODE byte = Man
--```,``-`-`,,`,,`,`,,`---
. T_REQ_MODE byte = Man

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
538
. IF this logical node supports alert reporting, then

. Generate "Man mode forced by 'Bad' INPUT1"
. notification.
. ENDIF
. ENDIF
. ELSE DECREMENT START_BAD_COUNT
. ENDIF
. ELSE
. START_BAD_COUNT = 0
. ENDIF
. ENDIF
' Note: the above procedure allows a bad INPUT1 to exist for
' START_BAD_LIMIT cycles after FORCE_INIT goes to zero
' before the mode will switch. This allows time for a
' good value of INPUT1 to get through the block chain
' when there is a general restart.
. Calculate T_VALUE from the value of LV_INPUT1, T_EVM, and T_EVB.
. T_STAT = status of LV_INPUT1
. IF T_STAT, bit 1 = reset, then
. Clear any "INPUT1 Bad" alarm.
. Clear any "INPUT1 Failed" alarm.
. IF T_STAT, bit 4 = set, then
. IF FAIL_OPT0, bit 2 = set, then
. IF SUPPRESS < 1, then
. Set the alarm bits for an "INPUT1 Failure" alarm.
. IF alert reporting supported, then
. prepare the "Fail" alert.
. SUPPRESS = 1
' Note: this is set to 1, not 2, because the
' failure of INPUT1 will not cause a FAIL of
' INPUT0.
. Set the alarm bits for an "INPUT1 Bad" alarm.
. prepare the "Bad" alert.
. SUPPRESS = 1
. IF FAIL_OPT0, bit 3 = set, then reset T_STAT, bit 4
' FAIL_OPT can block the passing of the failure.
. IF T_VALUE = NaN, then
. Mark T_STAT "Bad" and "Not-from-Process".
. T_VALUE = value of EV
. IF [(T_VALUE <> NaN) AND (T_VALUE <= EV_LO)], then
. T_VALUE = EV_LO
. Set bit 7 in T_STAT
. Set the alarm bits for an "INPUT1 Low Limit" alarm.
. IF alert reporting supported, prepare the "INPUT1 Low Limit" alert.
. IF bit AH of T_OPTIONS0 = set, then
. T_STAT = "Bad" and "Not-from-Process".
. IF [(T_VALUE <> NaN) AND (T_VALUE >= EV_HI)], then
. T_VALUE = EV_HI
. Set the alarm bits for an "INPUT1 Hi Limit" alarm.
. IF alert reporting supported, prepare the "INPUT1 Hi Limit" alert.
. IF bit BH of T_OPTIONS0 = set, then
. T_STAT = "Bad" and "Not-from-Process".
. T_EV = T_VALUE + T_STAT
. Pass T_EV to MSP.
' Note: the Standard AI block does not require that the calculated
' value of EV be used this cycle - it may have a 1 cycle
' dead time.
IF the hardware has not already been triggered, then
' This is the ideal place in the logic to trigger the hardware
' if INPUT1 is supported because the time-coherent value of the
' hardware filter and the correct value of EV are in place.

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
539
'
'
' *************************************************************
' *************************************************************
' ** **
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
' ** CALCULATE MAJOR VALUES **

' ** **
' *************************************************************
' *************************************************************
'
T_STAT = 00100000B.
'Always set "No-Path-to-Process" in the INPUT0 to OUTPUT0 data chain.
T_VALUE = value of major measurement from the hardware.
' Note: refer to the timing requirement for this measurement given on
' page 9 of the paper "Data Owner Structure - Hardware".
' Note: If triggered calibration is supported, this value is not to
' include the calibration correction.
IF hardware indicates that the measurement has "Failed", then
' The manufacturer may base "Fail" on indications from the hardware
' itself and/or on reasonableness checks of the measurement from
' the hardware.
'
' For a standard AI block, the hardware alert reporting will be
' consolidated with the function block alert reporting if the
' hardware failure is discovered as part of the operation triggered
' by the block schedule.
. T_VALUE = value part of INPUT0
' Use the last good value if currently failed.
. Set bits 1, 2, 4, 6, and 7 in T_STAT
ELSEIF hardware indicates that the measurement is "Bad", then
' There may be reason to consider the measurement "Bad" BUT NOT
' "Failed". The most obvious cause would be a "Bad" INPUT1.
. T_VALUE = value part of INPUT0
' Use the last good value if currently bad.
. Set bits 1, 2, 6, and 7 in T_STAT
ELSEIF the mode just changed from O/S and early triggering was used, there
. may be no hardware value ready; then
. T_VALUE = value of INPUT0
. Set bits 2, 6, and 7 in T_STAT.
. IF the status of INPUT0 is Bad, then
. Set bit 1 in T_STAT.
ENDIF
IF the hardware does not supply the major value in 4 byte floating point and
. ESI units form, then
. Convert T_VALUE to the correct basis.
IF T_VALUE = NaN, then
. Set bits 1, 2, 6, and 7 in T_STAT.
ELSEIF T_VALUE <= IN0_LO, then
. T_VALUE = IN0_LO
. set bit 7 in T_STAT
. Set the alarm bits for an "INPUT0 Low Limit" alarm.
. IF alert reporting supported, prepare the "INPUT0 Low Limit" alert.
. IF bit 0 in OPTIONS0 = set, then
. T_STAT = "Bad" and "Not-from-Process"
ELSEIF T_VALUE >= IN0_HI, then
. T_VALUE = IN0_HI
. Set the alarm bits for an "INPUT0 Hi Limit" alarm.
. IF alert reporting supported, prepare the "INPUT0 Hi Limit" alert.
. IF bit 1 in OPTIONS0 = set, then
. T_STAT = "Bad" and "Not-from-Process"
ENDIF

--```,``-`-`,,`,,`,`,,`---

540
' *************************************************************
' ** **
' ** CALCULATE INPUT0 **
' ** TRIGGERED CALIBRATION **
' ** **
' *************************************************************
'
IF T_STAT, bit 1 <> 1, then
. IF TC = set, then
' This pseudocode will assume that:
' There is a correction "LO_ADJ" at T_VALUE = LO_CAL
' and "ADJ_HI" at T_VALUE = HI_CAL. Then, the actual
' correction to a measured value, ADJ_MV, is obtained by
' linear interpolation or extrapolation based on the
' actual T_VALUE.
. T_LO_CAL = LO_CAL
. T_HI_CAL = HI_CAL
. ADJ_MV = the adjustment at the current T_VALUE - interpolated or
. extrapolated using LO_ADJ and T_LO_CAL with ADJ_HI and
. T_HI_CAL.
. IF T_TRIGGER has no bits set, then
. T_VALUE = T_VALUE + ADJ_MV
' Note: T_TRIGGER is not checked for more than 1 bit set
' because it can only be written indirectly - the
' DBWS can guard this parameter.
. ELSE ' triggered calibration is active
. IF [(the actual mode <> Man) OR (FORCE_INIT > 0)], then
. T_TRIGGER byte = reset
. IF alerts are supported by this logical node, then
. Generate a "Wrong mode for Triggered Calibration"
. notification.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
. ELSE ' mode = Man
. IF bit 0 or bit 2 set in T_TRIGGER, then
' Doing the low: must have sufficient span
' relative to the old high point.
. IF [(T_HI_CAL - T_LO_TARGET) < manufacturer set
. minimum], then
. BAD_CONFIG = set
. IF alerts are supported by this logical node,
. then
. Generate an "Insufficient Triggered
. Calibration Span" notification.
' Doing the high: must have sufficient span
' relative to the old low point.
. IF [(T_HI_TARGET - T_LO_CAL) < manufacturer
. set minimum], then
. BAD_CONFIG = set
. then
. Generate an "Insufficient Triggered
. Calibration Span" notification.
. IF [(CUM = 0) OR (CUM = NaN) OR (CUB = NaN)], then
. ' Check for bad calibration units conversion
. BAD_CONFIG = set
. Generate a "Bad Data - Can't Calibrate"
. notification.
. T_TRIGGER byte = reset
. BAD_CONFIG = reset
. ELSEIF (bit 0 or bit 2 set in T_TRIGGER), then
' Doing calibration at the low calibration
' point.
. C_INPUT0 = the back-calculated T_VALUE from

--```,``-`-`,,`,,`,`,,`---

541
. T_LO_TARGET and the calibration

. units conversion.
. IF [ABS(C_INPUT0 - T_VALUE) > manufacturer's
. limit], then
. IF alerts are supported by this logical
. node, then
. Generate an "Excessive Adjustment
. Triggered Calibration" notification.
. ELSEIF [ABS(C_INPUT0 - T_VALUE) < manufacturer's
. limit], then
. node, then
. Generate a "Trivial Triggered Calibration"
. notification.
--```,``-`-`,,`,,`,`,,`---
. ELSE
. T_LO_CAL = C_INPUT0
. LO_ADJ = C_INPUT0 - T_VALUE
. T_VALUE = C_INPUT0
. IF bit 2 is set in T_TRIGGER, then
' Apply the same change in bias
' to the high calibration bias.
. ADJ_HI = ADJ_HI + (LO_ADJ - ADJ_MV)
. ENDIF
' Doing calibration at the high
' calibration point.
. C_INPUT0 = the back-calculated T_VALUE from
. T_HI_TARGET and the calibration
. units conversion.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
. IF [ABS(C_INPUT0 - T_VALUE) > manufacturer's
. limit], then
. node, then
. Generate a "Bad Triggered Calibration"
. notification.
. ELSEIF [ABS(C_INPUT0 - T_VALUE) < manufacturer's
. limit], then
. node, then
. notification.
. ELSE
. T_HI_CAL = C_INPUT0
. ADJ_HI = C_INPUT0 - T_VALUE
. T_VALUE = C_INPUT0
' Apply the same change in bias
' to the low calibration bias.
. LO_ADJ = LO_ADJ + (ADJ_HI - ADJ_MV)
. ENDIF
. ENDIF
. T_TRIGGER byte = all reset
. T_IN0_LO = hardware low range limit + adjustment at that
. value.
. T_IN0_HI = hardware high range limit + adjustment at that
. value.
. ENDIF
. ENDIF
. T_LO_TARG_ADJ = the adjustment at the current T_LO_TARGET value -
. the current T_LO_TARGET (in cal. units) is
. converted to ESI units using the calibration units
. conversion in reverse, then T_LO_TARG_ADJ is
. interpolated or extrapolated using T_LO_ADJ and

542
. T_LO_CAL with T_ADJ_HI and T_HI_CAL.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
. T_HI_TARG_ADJ = the adjustment at the current T_HI_TARGET value -
. the current T_HI_TARGET (in cal. units) is
. converted to ESI units using the calibration units
. conversion in reverse, then T_HI_TARG_ADJ is
. interpolated or extrapolated using T_LO_ADJ and
. T_LO_CAL with T_ADJ_HI and T_HI_CAL.
. ELSEIF TIME_CRIT0, bit BH = set, then
' This is the CX = MX case. If TIME_CRIT0, bit BH is set, the
' adjustment can not be lost when CX is changed to equal MX
' but no new triggered calibrations will be serviced.
. ADJ_MV = the adjustment at the current measured value -
. interpolated or extrapolated using LO_ADJ and T_LO_CAL
. with HI_ADJ and T_HI_CAL.
. LO_TARGET = 0
. HI_TARGET = 0
' Note: these two parameter writes are allowed to violate
' the time coherent, blocked writes requirement.
. T_LO_TARG_ADJ = 0
. T_HI_TARG_ADJ = 0
. TC = set
--```,``-`-`,,`,,`,`,,`---
. ENDIF
ENDIF
IF T_STAT, bit 1 = reset, then
. Clear any "INPUT0 Bad" alarm in this function block.
IF T_STAT, bit 4 = reset, then
. Clear any "INPUT0 Failed" alarm in this function block.
. Clear the contribution to any physical node "Cold junction compensation
. failure" alarms or any failure alarms by this hardware point.
IF T_STAT, bit 4 = set, then
. IF FAIL_OPT0, bit 0 = set, then 'failure reported
. IF the failure is caused by a cold junction compensation
. circuit that serves more than one measurement point, then
. DO NOT set a function block alarm nor issue a function
. block alert.
. IF the physical node alert for cold junctions (12H) is
. not set, then
. Set the physical node alarm bits.
. Generate the physical node alert.
. ELSEIF the failure is associated with a single cold junction
. compensation, then
. DO NOT set a physical node alarm nor issue a physical
. node alert.
. Set the alarm bits for the function block's "cold
. junction compensation" alarm.
. Generate a "Cold junction compensation" function block
. alert.
. SUPPRESS = 2
. ELSEIF the failure is associated with any other part of the
. hardware, then
. IF the priority of the physical node alarm for the
. failure of this SI hardware is equal to, or greater
. than, the priority of the function block alarm for
. INPUT0 failure, then
. DO NOT set a function block alarm nor issue a
. function block alert.
. Set the alarm bits for the physical node alarm.
. Generate a physical node "SI hardware failure"
. alert.
. IF the priority of the physical node alarm for the
. failure of this SI hardware is less than the
. priority of the function block alarm for INPUT0,
. then
. DO NOT set a physical node alarm nor issue a
. physical node alert.

543
. Set the alarm bits for the function block alarm.

. Generate a function block "INPUT0 failure" alert.
. SUPPRESS = 2
. ENDIF
ELSEIF T_STAT, bit 1 = set, then
. Set the alarm bits for an "INPUT0 Bad" alarm.
. IF SUPPRESS < 1, then 'no "Bad" or "Fail" reported yet.
. SUPPRESS = 1
ENDIF
T_INPUT0 = T_VALUE + T_STAT
IF FAIL_OPT0, bit 1 = set, then reset T_STAT, bit 4
'
' It is possible that INPUT0's value is, at this point, equal to NaN
' since INPUT0 may never have had a good value since startup. However,
' in that case, T_STAT will show Bad because hardware must still be Bad.
'
' *************************************************************
' ** **
' ** CALCULATE OUTPUT0 **
' ** **
' *************************************************************
'
T_CUV = value of CUV + a status of 11100110B
T_LV = value of LV + a status of 11100110B
T_UUV = value of UUV + a status of 11100110B
T_CV = value of CV + a status of 11100110B
BAD_CONFIG_D = reset ' a logic flag, set if bad damping coef.
'
' calculate CUV
IF T_INPUT0 <> NaN, then
. IF [(CUM <> 0) AND (CUM <> NaN) AND (CUB <> NaN)], then
' Check for bad calibration units conversion
. T_VALUE = "Calibration Unit Conv." operated on the value of
. T_INPUT0
'Note: T_VALUE may be NaN if the units conversion fails.
. IF T_VALUE <> NaN, then
. T_CUV = T_VALUE + status of T_STAT
. IF CUM is negative, then
. exchange bits 6 & 7 in the status of T_CUV
'
' calculate LV
. IF OPTION_INT0 = an unsupported linearization type, then
. BAD_CONFIG = set
--```,``-`-`,,`,,`,`,,`---

. ELSEIF any of the equation constants used by the linearization type are
. = NaN or if a coefficient that multiplies the input = 0, then
. BAD_CONFIG = set
. ELSEIF DAMP = NaN, then
. BAD_CONFIG_D = set
. ELSE
. IF configured linearization type has no LVB term, then
. T_LV_SI_UNIT0 = set from the linearization type
. T_LV_SI_UNIT1 = set from the linearization type
. ELSE
. T_LV_SI_UNIT0 = T_LVB_SI_UNIT0
. T_LV_SI_UNIT1 = T_LVB_SI_UNIT1
. IF FORCE_INIT > 1, then
. In the next step, set the output of the filter equal to the
. output of the linearization step.
' This prevents the filter from locking in an old value
' during the first 2 cycles after O/S mode.
. T_VALUE = "Linearization and Damping" operated on the value of

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
544
. T_INPUT0
' T_VALUE may be NaN if the linearization and damping
' calculations fail.
. IF dictated by the slope of the linearization equation, then
. exchange bits 6 & 7 in T_STAT
. T_LV = T_VALUE + T_STAT
. ELSE
. ENDIF
. ENDIF
'
' calculate UUV
IF T_LV value <> NaN, then
. IF [(UUM = 0) OR (UUM = NaN) OR (UUB = NaN)], then
' Check for bad user units conversion
. BAD_CONFIG = set
. ELSE
. T_VALUE = "User Unit Conversion" operated on T_LV
' T_VALUE may be NaN if the units conversion fails.
. IF UUM is negative, then
. exchange bits 6 & 7 in T_STAT
. T_UUV = T_VALUE + T_STAT
. ELSE
. ENDIF
. ENDIF
'
' calculate UUV_LO and UUV_HI
IF TIME_CRIT0, bit 4 = set, then
' Support for the calculation of these two limits.
. UUV_LO = NaN
. UUV_HI = NaN
. ELSE
. T_VALUE = "Linearization" (no Damping) operated on the value of
. IN0_LO
. T_VALUE = "User Unit Conversion" operated on T_VALUE
. T_UUV_LO = T_VALUE
. T_VALUE = "Linearization" (no Damping) operated on the value of
. IN0_HI
. T_VALUE = "User Unit Conversion" operated on T_VALUE
. T_UUV_HI = T_VALUE
'
' calculate CV
IF T_UUV <> NaN, then
. T_VALUE = value of T_UUV
' device supports Output clamping
. IF T_LIM_LO = NaN, then
. IF OLD_CLAMP0 <> 2, then
. OLD_CLAMP0 = 0
. ELSE
. IF T_VALUE <= T_LIM_LO, then
. T_VALUE = T_LIM_LO
. IF T_ACTUAL_MODE byte = Auto, then
. Set the alarm bits for an "OUTPUT0 Lo Limit" alarm.

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
545
. IF alert reporting supported, prepare the "OUTPUT0

. Lo Limit" alert.
. IF OPTION0, bit 2 = set, then
. Set bits 1 and 2 in T_STAT
. OLD_CLAMP0 = 1
. ELSEIF OLD_CLAMP0 = 1, then
. IF [(LIM_DB <> NaN) AND (T_VALUE < (T_LIM_LO + LIM_DB))],
. then
. IF OPTIONS0, bit 2 = 1 then
. ELSE
. OLD_CLAMP0 = 0
. ENDIF
. IF T_LIM_HI = NaN, then
. IF OLD_CLAMP0 <> 1, then
. OLD_CLAMP0 = 0
. ELSE
. IF T_VALUE >= T_LIM_HI, then
. T_VALUE = T_LIM_HI
. IF T_ACTUAL_MODE byte = Auto, then
. Set the alarm bits for an "OUTPUT0 Hi Limit" alarm.
. IF alert reporting supported, prepare the "OUTPUT0
. Hi Limit alert".
. OLD_CLAMP0 = 2
. IF [(LIM_DB <> NaN) AND (T_VALUE > (T_LIM_HI - LIM_DB))],
. then
. IF OPTIONS0, bit 3 = 2, then
. ELSE
. OLD_CLAMP0 = 0
. ENDIF
. T_CV = T_VALUE + T_STAT
'
' move CV to LV_OUTPUT0
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
IF only bit set in T_ACTUAL_MODE = Auto, then

. IF the OUTPUT0 agent = active, then
. reset bits 4, 6, and 7 in T_STAT
. LV_OUTPUT0 = value of T_CV + T_STAT
. IF FAIL_OPT0, bit 9 = set, then reset T_STAT, bit 4
ELSE
. Set bits 2 and 5 in the status of LV_OUTPUT0
' Set "Not-from-Process" and "No-path-to-Process".
. Clear any "OUTPUT0 Bad" alarm in this function block.
. Clear any "OUTPUT0 Failed" alarm in this function block.
. IF FAIL_OPT0, bit 8 = set, then 'alerts sent for OUTPUT0
. Set the alarm bits for a "OUTPUT0 Failure" alarm.
. IF SUPPRESS < 2, then 'no "Fail" alert yet.
. SUPPRESS = 2
. Set the alarm bits for a "OUTPUT0 Bad" alarm.
. IF SUPPRESS < 1, then 'no "Bad" alert yet.
. SUPPRESS = 1
'

--```,``-`-`,,`,,`,`,,`---

546
'clean up BAD_CONFIG alert

IF this logical node supports alerts, then
. IF [(BAD_CONFIG = set) OR (BAD_CONFIG_D = set)], then
. Generate a "Bad configuration" alert.
'
' *************************************************************
' *************************************************************
' ** **
' ** CALCULATE PV POINTER VALUES **
' ** **
' *************************************************************
' *************************************************************
'
IF TIME_CRIT0, bit CH = set, then
' device supports the PV Pointer
. Execute the PV Pointer pseudocode
' see the pseudocode attachment to the paper "Standard Block
' Functions".
'
' Suppress the PV alerts if SUPPRESS > 0.
ELSE
. Move value pointed to by TARGET_PARAM into TARGET.
. IF the value has a status byte, then
. Use it.
. ELSE use a default status byte of 00100100B
. T_STAT = status of LV_OUTPUT0
. T_STAT = T_STAT AND 00000111B
'Reset all PV status bits except No-Com, Bad, and Not-from-Process
'Set HiHi and LoLo alarm bits simultaneously as a flag.
. T_PV = value of LV_OUTPUT0 + T_STAT
'
'
' *************************************************************
' *************************************************************
' ** **
' ** GET HARDWARE VALUES AND SET OUTPUT1+ **
' ** **
' *************************************************************
' *************************************************************
'
Access hardware to get new values.
'
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
' The following procedure is detailed for OUTPUT1. The totally
' analogous procedure is to be followed for OUTPUT2 and OUTPUT3.
' The procedures are to be executed in the order:
' 1) OUTPUT2
' 2) OUTPUT3
' 3) OUTPUT1
' so that alert suppression will be in the rank order specified in the
' algorithm definition.
'
' bit 5 = set means OUTPUT1 is supported
' if cold junction temperature is an auxiliary value, then it must
' be here. Otherwise, if the instrument body temperature is an
' auxiliary value, then it must be here.
. T_STAT = 00100000B.
' Always set "No-path-to-process" in AI Outputs
. T_VALUE = value of auxiliary value 1 from the hardware.
. IF the hardware indicates that the measurement has "Failed", then
' The manufacturer may base "Fail" on indications from the
' hardware itself and/or on reasonableness checks of the
' measurement from the hardware.
'
' For a standard AI block, the hardware alert reporting will
' be consolidated with the function block alert reporting

--```,``-`-`,,`,,`,`,,`---

547
' if the hardware failure is discovered as part of the

' operation triggered by the block schedule.
. T_VALUE = value part of LV_OUTPUT1
' set "Bad", "Not-from-Process", "Fail", and "Wound-up" bits
. ELSEIF the hardware indicates that the measurement is "Bad", then
' There may be reason to consider the measurement "Bad" BUT
' NOT "Failed". The most obvious cause would be a "Bad"
' INPUT1.
. T_VALUE = value part of OUTPUT1
. ELSEIF the mode just changed from O/S and early triggering was used,
. there may be no hardware value ready; then
. T_VALUE = value of OUTPUT1
. ENDIF
. ELSE
. IF the hardware indicates that the value is at its extreme high
. limit, then
. IF the hardware indicates that the value is at its extreme low
. limit, then
. IF the hardware does not supply auxiliary value 1 in 4 byte
. floating point and ESI form, then
. IF FAIL_OPT0, bit AH = set, then '"Fail" alerts reported
. IF SUPPRESS < 2, then 'No "Fail" alarms yet.
--```,``-`-`,,`,,`,`,,`---
. SUPPRESS = 1
. IF a failure in this auxiliary will inevitably lead to
. failures in the other auxiliary values, then
. SUPPRESS = 2
. IF T_LIM1_LO = NaN, then
. IF OLD_CLAMP1 = 1, then
. OLD_CLAMP1 = 0
. ELSE
. IF T_VALUE <= T_LIM1_LO, then
. T_VALUE = T_LIM1_LO
IF SUPPRESS < 1, then
. prepare the "OUTPUT1 Lo Limit" alert.
SUPPRESS = 1
. OLD_CLAMP1 = 1
. IF [(LIM1_DB <> NaN) AND (T_VALUE < (T_LIM1_LO +
. LIM1_DB))], then
. ELSE
. OLD_CLAMP1 = 0
. ENDIF
. IF T_LIM1_HI = NaN, then

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
548
. OLD_CLAMP1 = 0
. ELSE
. IF T_VALUE >= T_LIM1_HI, then
. T_VALUE = T_LIM1_HI
. prepare the "OUTPUT1 Hi Limit" alert.
. SUPPRESS = 1
. OLD_CLAMP1 = 2
. ELSEIF [(LIM1_DB <> NaN) AND (T_VALUE > (T_LIM1_HI -
. LIM1_DB))], then
. ELSE
. OLD_CLAMP1 = 0
. ENDIF
. SUPPRESS = 1
. IF FAIL_OPT0, bit BH = set, then
. T_STAT, bit 4 = reset
. IF the OUTPUT1 agent type = active, then
. IF OUTPUT1 agent type <> Null, then
. LV_OUTPUT1 = T_VALUE + T_STAT
'
' This is the end of the procedure for OUTPUT1.
'
FOR OUTPUT's 0 - 4
IF the output is supported, then
IF the output's agent is active, then
IF [(FORCE_INIT = 3) AND (OUTPUT = Bad)], then
Instruct the agent to not store the output
ENDLOOP
. Decrement FORCE_INIT
. ELSEIF FORCE_INIT = 2, then
. IF there are NO No-Com counters that have counts but have not
. counted out, then
. FORCE_INIT = 1
. ELSE 'FORCE_INIT = 1
. Follow the rules for decrementing FORCE_INIT; see page 25 of the
. paper "Function Block Structure".
. ENDIF

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
549
' *************************************************************
' *************************************************************
' ** **
' ** WAIT FOR THE END OF BLOCK TIME **
' ** **
' *************************************************************
' *************************************************************
--```,``-`-`,,`,,`,`,,`---
'
IF CX > MX, then
. All of the extra block time must be placed here.
'
' *************************************************************
' *************************************************************
' ** **
' ** WRITE TO DATA BASE WHILE PROTECTED **
' ** **
' *************************************************************
' *************************************************************
'
Send alerts to the User Layer Support Services
Request User Layer Support Services to block access to memory.
' write block variables
REQ_MODE = T_REQ_MODE
ACTUAL_MODE = T_ACTUAL_MODE
Update ALERT_SET0, ALERT_SET1, ALERT_UNACK0, and ALERT_UNACK1 as necessary.
INPUT0 = T_INPUT0
CUV = T_CUV
LV = T_LV
LV_SI_UNIT0 = T_LV_SI_UNIT0
LV_SI_UNIT1 = T_LV_SI_UNIT1
UUV = T_UUV
CV = T_CV
IF highest priority bit set in ACTUAL_MODE = Auto, then
. OUTPUT0 = LV_OUTPUT0
IF TIME_CRIT0, bit AH = set, then
. IF highest priority bit set in ACTUAL_MODE = Auto, then
. Increment the OUTPUT0 revision number
IF [(TIME_CRIT0, bit 5 = set) AND (OUTPUT1 Agent Type <> Null)], then
. IF TIME_CRIT0, bit AH = set, then
. EV = T_EV
IF TC = set, then
' write the variables associated with triggered calibration
. LO_CAL = T_LO_CAL
. HI_CAL = T_HI_CAL
. LO_ADJ = T_LO_ADJ
. HI_ADJ = T_HI_ADJ
. LO_TARG_ADJ = T_LO_TARG_ADJ
. HI_TARG_ADJ = T_HI_TARG_ADJ
. TRIGGER = T_TRIGGER

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
550
. IF TC = set, then
. IN0_LO = T_IN0_LO
. IN0_HI = T_IN0_HI
' Note: it is assumed that these two parameters are in ROM
' when TC is not supported.
. UUV_LO = T_UUV_LO
. UUV_HI = T_UUV_HI
'
' write the variables associated with the PV function
PV = T_PV
TARGET = T_TARGET
Request "Agent System" support of all OUTPUT agents.
Request USer Layer Support Services to again allow a public access to memory.
'
--```,``-`-`,,`,,`,`,,`---
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

551
Analog Output
SUMMARY:
Drives, and accepts measurements from, SO hardware. Selects Setpoint from
cascade inputs and delivers desired output signal to Manufacturer's Signal
Processing (MSP). Can optionally command "bypass" of normal MSP. Converts
response measurement to INPUT1. Can optionally provide up to three auxiliary
measurement as Outputs 1-3. Can optionally accept, through INPUT2, a discrete
status byte representing external measurements of limiting.

MAN MODE
IMAN MODE
BYPASS OPERATION
OPTIONAL INPUT2
SERVO SWITCH REGISTER
AUTOMATIC CALIBRATION
GO BAD AT END OF RANGE
FLOW INDICATION
CAVITATION
OTHER PARAMETERS
GENERAL DESCRIPTION
CHARACTERIZATION DESCRIPTION
Table 1 - Definition of Characterization Types
Table 2 - Definition of AO-Standard Auto-Format Variables
Figure 1 - AO System Diagram
Figure 2 - Illustration of Characterization Types
BASIC ALGORITHM:
- Select the current Setpoint.
- Reverse the Setpoint value if necessary, and deliver the value to
OUTPUT0 (the setpoint of the MSP).
- If the optional triggered calibration procedure is supported, the
procedure will operate on the appropriate signal by, and within, the
MSP.
- Optional ability to bypass normal MSP processing.
- Retrieve the response signal from the MSP, reverse it if necessary,
and store it as INPUT1.
- Optionally use INPUT2 as an external source of control windup
information.
- Make any applicable auxiliary measurements available as Outputs 1, 2,
and/or 3 in "extended international standard" (ESI) units.

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
552

- Inputs: 2 required, INPUT2 optional; agent types for Inputs 0 and 2
are optional
- Outputs: 1 required - hardware, SO type; 3 optional, optional agent
types.
- Bit Pointers: no - Output Limits: 0 = yes: 1-3 =
- Boolean Operator: no optional (if present).
- By-pass: optional - PV pointer: optional; analog; PV
- Cascade Structure: yes defaults to INPUT1. Target
- Hardware Pointers: yes defaults to SERVO_SP
Output 0 = SO - Setpoint Limits: yes
- Mode: not Rout (IMan and Man - Setpoint Ramp: no
optional).

- INPUT1's agent forced to Null and value supplied from hardware
selected by OUTPUT0 pointer.
- External value acquired via. INPUT2 and "OR"'ed with measured windup
conditions. INPUT2 can be put into override and set directly.
- Extensive data base in the MSP.
- The Output 1-3 agents can be optionally limited to Null or Immediate.
- Optional Output clamping for Output's 1-3.
MANUFACTURER BLOCK OPTIONS:

- TIME_CRIT0 - Time-critical manufacturer's Options #0.
= 16 bit binary string, read-only.
0) INPUT2 is supported.
1) INPUT0 and INPUT2 (if present) have active agents.
2) Bypass is supported.
3) SO Hardware can run independently of the AO block and
the hardware value may be writeable.
4) REPL_SP supported (see OPTIONS0, bit 1)
8) OUTPUTs 1-3 (if present) have active agents.
9) OUTPUTs 1-3 (if present) have limiting/clamping (note:
this bit must be reset if bits 5-7 are all reset).
AH) MSP has more than the minimum functionality.
Note: if this bit is reset, most BUT NOT ALL, parameters
labeled "MSP" are eliminated. See the "General
Description" section later in this paper.
BH) Triggered calibration is supported.
CH) PV Pointer is supported.
--```,``-`-`,,`,,`,`,,`---
DH) Servo switch register supported
EH) "Vapor Pressure" Auto-Format variable is supported.
FH) Extended variables present in this TO.
- N_TIME_CRITx - Non-time critical manufacturer's options #0 and #1.
= 16 bit binary string, read-only.
+ N_TIME_CRIT0 (required)
0) Auto-bypass supported.
1) Triggered calibration only works if CX > MX (Note: this bit
has no meaning if bit BH in TIME_CRIT0 is reset.)
2) User can request reaction to loss of Field Bus power.
(see bit EH in OPTIONS0)
3) set if OUTPUT1 = process fluid temperature (this bit has no
4) set if OUTPUT2 = process fluid inlet pressure (this bit has
no meaning if bit 6 in TIME_CRIT0 is reset).
5) set if OUTPUT3 = valve pressure drop (this bit has no
SP-50 User Layer Technical Report Analog Out Protocol

//^:^^
553

6) set if OUTPUT3 = (inlet - minimum pressure) (this bit has
no meaning if bit 7 in TIME_CRIT0 is reset).
Note: bits 5 and 6 can not both be set at the same time.
7&8) reserved.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
9) set if all Standard pseudocode checks and alerts are

implemented in the base algorithm and in all supported
options.
Bits AH - CH) reserved for future standards.
Bits DH - FH) manufacturer specific codes.
+ N_TIME_CRIT1 (required)
Bits 0-7: correspond to the 8 linearization types defined in
Table 1 . When a bit is set, the user can choose
to set the corresponding type code in OPTIONS_
INT0 - the "native" characterization of the valve
itself. If only one of these 8 bits are set, it
indicates that the MSP can only work with one type
of valve - the one indicated. If OPTIONS_INT0
does not correspond to a set bit, it will ignore,
BUT NOT OVERWRITE, OPTIONS_INT0.
Bits 8-FH: correspond to the 8 linearization types defined in
Table 1. When a bit is set, the user can choose
to set the corresponding type code in OPTIONS_
INT1- the desired characterization for the total
AO system. If only one of these 8 bits are set, it
indicates that the MSP can only work with one type
of valve - the one indicated. If OPTIONS_INT1
does not correspond to a set bit, it will ignore,
BUT NOT OVERWRITE, OPTIONS_INT1.
USER ALGORITHM OPTIONS:

- OPTIONS0 - User's options #0.
= 16 bit binary string, static data base, indirectly writeable.
= data set by user, used by AO and/or MSP sections.
= the statement is true if the assigned bit is set.
+ Algorithm operation:
0 = The relationship between the Setpoint and OUTPUT0 is
reversed.
1 = Replace the current Setpoint value with REPL_SP on fall
to Auto mode.
2 = Force Auto mode when no good SETPOINT available from
Cas and RCas mode.
3 = Energy is required to close the value.
+ Clamp options:
4 = 0 = OUTPUT1 limited to OUT1_LO.
5 = the same for the high limit of OUTPUT1.
+ Servo operation:
AH = Commanded Bypass prohibited.
BH = Auto-bypass prohibited.
Note: these two operations are independent; AH refers to the
Field Bus command to go to Bypass, BH refers to the
automatic invocation of Bypass upon a failure.
CH = MSP Servo Switch prohibited.
DH = Switch to Auto mode on Failure.
EH = User request that the driver go to the zero state when
the power normally provided on Field Bus itself fails.
--```,``-`-`,,`,,`,`,,`---
Note: this bit has no meaning if bit 2 in N_TIME_CRIT0

is reset.

554
FH = reserved.
- OPTIONS1 - User's options #1.

= 16 bit binary string, static data base, indirectly writeable.
= data set by user, used by AO section.
= two bits will be dedicated to each of the first eight alerts
in the alert register MSP_ALERT; bit 0 and 1 to the first alert,
2 and 3 to the second, etc. The meaning of the value of the 2
bits is as follows:
value = 00B = ignore the report - not even an alert.
01B = simply issue an alert.
10B = issue an alert and set both wound-up bits but
do not mark as failed.
11B = issue an alert, set both wound-up bits, set
failed status, and follow the option for mode
switching.
- OPTION_INT0 - User's options integer #0.
= 8 bit unsigned integer, static data base, indirectly writeable.
= native characterization type of valve - integer value.
This integer describes to the MSP the characterization that
is built into the valve - this is the valve characteristic that
would be obtained if the MSP simply transformed its setpoint
linearly to its power output.
= if the value in the low 7 bits is a characterization that can be
choosen, according to N_TIME_CRIT1, then the high bit will be
reset, ELSE it will be set. If the high bit is set, the MSP will
use a linear transformation on the Setpoint signal, thus the
total AO system will operate with the "natural" characterization
of the valve
= refer to Table 1 for definitions of, and Figure 2 for
illustrations of, these characterization curves.
0 = Quick opening.
1 = Modified quick opening.
--```,``-`-`,,`,,`,`,,`---
2 = Linear
3 = Modified linear.
4 = Modified parabolic.
5 = Equal Percentage (default)
6 = Hyperbolic.
7 = Manufacturer specific.
- OPTION_INT1 - User's options integer #1.
= 8 bit unsigned integer, static data base, indirectly writeable.
= desired characterization type of valve - integer value.
This integer describes to the MSP the characterization that
is desired of the valve - the MSP is instructed by this integer
to transform the setpoint value to its power output in such a
way as to produce this characteristic rather than the valve's
native characteristic (defined above).
= if the value in the low 7 bits is a characterization that can be
chosen, according to N_TIME_CRIT1, then the high bit will be
reset, ELSE it will be set. The high bit may also be set for
certain specific unsupported combinations of OPTION_INT0 and
OPTION_INT1. If the high bit is set, the MSP will use a linear
transformation on the Setpoint signal, thus the total AO system
will operate with the "natural" characterization of the valve as
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
defined in OPTION_INT0 above.
= same code numbers and default as given for OPTION_INT0.
AGENT TYPES:
The following agent types will be associated with the Input and Output words:
Notes: this block does not support measurement Revision Numbers, hence
no agents of that type will be supported.
"Active" agents will include Off-Field Bus types if, and only
if, the logical node supports that type.

555
INPUT0:
IF TIME_CRIT0, bit 1 = reset, then
Null, Immediate, Writeable, and block active.
physical I/O.
INPUT1: forced to Null.
INPUT2 (if supported):
Null, Immediate, Writeable
physical I/O.
OUTPUT0:
Null, Physical hardware (SO type).
--```,``-`-`,,`,,`,`,,`---
OUTPUT's 1-3
Null, Immediate
Null, Immediate, and all Active except physical I/O.
Refer to the pseudocode for the details of the operation of this algorithm.
- The normal mode logic is used to select the current mode.
- The normal cascade signal logic is used to select the current Setpoint
from INPUT0, CAS_TL, or RCAS_TL.
- If necessary, the Setpoint is reversed, then moved to OUTPUT0.
- If bypass is supported and requested, signal the MSP to use its bypass
operation.
- If triggered calibration is supported and triggered, command the MSP
to back-calculate the calibration bias.
- Implement the special reaction to failures.
- If the MSP section indicates a failure, set the IMan mode bit in
ACTUAL_MODE and execute the failure handshake. Clear IMan when the
failure is acknowledged and cleared.
- Retrieve the response measurement (already corrected for the
triggered calibration bias if necessary), reverse it if necessary, and
enter the value as INPUT1. Generate the INPUT1 status byte from MSP
information.
- Form the status bytes for Setpoint, CAS_TL, RCAS_TL, and INPUT0 from
the hardware indication of Good/Bad and windup. Boolean "OR" the
information from INPUT2 if supported.
- Move any auxiliary variables to OUTPUT's 1-3, implementing the
optional limiting/clamping.
- Execute the PV function processing if it is supported.
STATUS VALUE HANDLING:

- The stati of INPUT0, CAS_TL, RCAS_TL, and Setpoint will be handled
exactly as is done for standard cascade structures.
- Bits 1 (Bad) and 2 (Not-from-Process) in the status of INPUT1 will be
determined completely from the hardware. If the measurement is Good,
they both will be reset; if the reading is Bad, they both will be set.
Bits 6 and 7 will indicate that the value is at the end of its travel
(if that is possible to determine) as appropriate. Bit 5 (No-path-to-
Process) will always be set and bits 0, 3, and 4 will always be reset.
- INPUT2 may be marked Bad. If it is, it will NOT be used by the
algorithm. Bit 5 (No-path-to-Process) will always be set and bit 3
will always be reset. If the agent is inactive, bits 4, 6, and 7 will
always be reset. Bit 0 will be initialized to 0, then ignored.
- The status of OUTPUT0 will be the same as that of Setpoint except the
states of bits 6 and 7 may be exchanged because of the need to reverse
the value.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
556
- Bit 1 (Bad) may be set for any individual auxiliary measurements by

the hardware; the Good/Bad status will flow to their OUTPUTx. If Bad
is set, then bit 2 (Not-from-Process) will also be set. Bit 4 (Fail)
is set if the hardware indicates a failure and the appropriate bits of
FAIL-OPT0 are reset. Bit 5 (No- path-to-Process) will always be set.
Bits 6 and 7 will indicate that the value is at the end of its travel
as appropriate. Bits 0, 3, and 4 will be reset.
- Bits 1 (Bad) and 2 (Not-from-Process) are set in all status bytes (and
--```,``-`-`,,`,,`,`,,`---
in AUX_BAD, see page 12) unconditionally on transition to O/S but not

during O/S.
- Hardware Value
+ Physical node data base, parameter "I/O_VALUE".
+ Supported if bit 3 in TIME_CRIT0 is set.
+ Defined in the physical node as 16 bit integer.
+ Output command to hardware, provided as a fraction of the full
output range (all bits to the right of the radix point). By
definition, a value of 0.0 corresponds to -5% of the command
range and 1.0 corresponds to 105% of the command range.
+ A manufacturer may decide to limit this capability to three
or even only two states. See MSP_READ_ONLY for the details.
- I/O Parameters:
+ INPUT0 - normal analog cascade structure INPUT0.
= in percent of command range.
+ INPUT1 - analog value supplied from the hardware pointed to by
OUTPUT0's agent.
= writeable only in O/S mode.
+ INPUT2 - present if, and only if, TIME_CRIT0, bit 0 is set.
= 16 bit register, only bits 4 (failed), 6&7 (Windup) are
used. Ignored if bit 1 (Bad) is set.
+ OUTPUT0 - Output to the SO hardware.
= Setpoint, reversed if necessary.
= actual Setpoint of MSP
= read only.
+ OUTPUT1 - present if, and only if, bit 5 is set in TIME_CRIT0.
Note: if the process fluid temperature is one of the auxiliary
variables, it must be OUTPUT1.
Note: if the process fluid inlet pressure is one of the
auxiliary variables, it must be OUTPUT2.
Note: if the pressure drop between the inlet and the
outlet of the value is one of the auxiliary variables,
it must be OUTPUT3. If not, then, if the differential
pressure between the inlet and the minimum pressure
point of the valve is one of the auxiliary variables,
then it must be OUTPUT3.
Note: in the scheme to suppress multiple hardware failure alerts,
OUTPUT3 will be superior to outputs 1 and 2 while OUTPUT2
will be superior to OUTPUT1.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
557
Note: if bit 8 is reset in TIME_CRIT0, then none of the OUTPUT's

can support an active agent. Therefore, none of them need a
cyclic read buffer nor the local variable versions of the
OUTPUT value (see page 10 of the paper "Function Block
Structure").
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
If bit 8 is set in TIME_CRIT0, then those variables are
needed.
+ MIN_TC0 - "Minimum" image of TIME_CRIT_0 defined above.
= required.
= 16 bit binary string, static data base, indirectly
writeable.
= see the paper "Data Owner Structures", page 22, for a
description of the exactly analogous variable in the
physical node.
+ IN2_OVER - present if, and only if, TIME_CRIT0, bit 0 is set.
= 8 bit discrete
= bit 0 set to request the ability to override the value and
status of INPUT2. When bit 2 is set, the INPUT2 cyclic read
buffer will be ignored and the location will become
writeable. Note that direct writes may continue.
+ Bypass Operation Parameters:
= present if, and only if, TIME_CRIT0, bit 2 is set.
+ BYPASS_REQ - request to execute bypass instead of normal
control.
= 8 bit discrete
= bit 0 set to request Bypass action
= reset immediately if OPTIONS0, bit AH is set.
+ BYPASS_LO - low range value for bypass operation.
= 4 byte floating point, indirectly writeable, static
memory
+ BYPASS_HI - high range value for bypass operation.
= 4 byte floating point, indirectly writeable, static
memory
+ BYPASS_SI_UNIT0 and BYPASS_SI_UNIT1 = ESI unit for the
two bypass range values.
= ROM
+ VAPOR_PRESS - present if, and only if, TIME_CRIT0, bit EH is
set.
= an Auto-Format variable containing 20 - 4 byte floating
point numbers.
= ten pairs of numbers, each pair consisting of an absolute
temperatures (in deg. K) followed by the fluid vapor
pressure (in Paa), in that order
+ SETPOINT - the Setpoint of the AO block - required.
= 4 byte floating point, with status, dynamic data base.
@ START_BAD_LIMIT = number of cycles after FORCE_INIT goes to
zero before the mode will automatically
switch to Auto with no good SETPOINT from
Cas and RCas and bit 2 of OPTIONS0 set.
= required, unsigned 8 bit integer, defaults --```,``-`-`,,`,,`,`,,`---
to 0.
= static data base, indirectly writeable
@ REPL_SP - present if, and only if,TIME_CRIT0, bit 4 is set.
= the value transferred to the Setpoint when mode falls
to Auto.
= 4 byte floating point, no status, static data base.
@ CAS_TL
= the Cas transfer location.
@ RCAS_TL
= the RCas transfer location.

558

@ SERVO_SP
= the servo setpoint transformed to the AO block's
SETPOINT basis.
= at steady state and under normal operations, must
exactly equal INPUT1.
= If the AO function block SETPOINT is
1) adjusted for direct/reverse
2) characterized
3) calibration adjusted
4) limited
5) adjusted for gap
then SERVO_SP is the final result of that series of
operations brought back through
1) uncalibration
2) uncharacterized
3) unadjusted for direct/reverse
If this value is addressed by the PV function, the
value delivered to the PV function for alarm purposes
must be the value from the previous cycle. When the
block is finished executing, the value in SERVO_SP will
be from the just concluded cycle.
@ SP_DISPLAY_LO and SP_DISPLAY_HI = display range of Setpoint.
Note: this display range is also used for INPUT0 and
INPUT1. It, or the 100 compliment of it, is used
for OUTPUT0, depending on the state of bit 0 in
OPTIONS0.
+ OUTPUT1
is set.
--```,``-`-`,,`,,`,`,,`---
+ OUTPUT2
is set.
+ OUTPUT3
is set.
+ Parameters of the Setpoint limiting function.
+ Parameters of the Triggered Calibration procedure (if, and only
if, TIME_CRIT0, bit BH is set).
Note: the triggered calibration values will always be in terms of
INPUT1.
+ Parameters of the Standard PV function (if, and only if,
TIME_CRIT0, bit CH is set).
+ Parameters of the MSP section.
Note: none of these parameters are in the static data base.
All are addressed using the tag name of the AO block.
All bit descriptons apply to the bit = set state. The
converse applies if the bit = reset.
@ Parameters showing state and configuration.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~"
* MSP_READ_ONLY - MSP Read-only register:

559
= ROM in the MSP, required.

Bit 0 - Hold action.
The driver will maintain power when asked to
"hold".
Bit 1 - Zero action.
The driver will maintain power when asked to
"go to zero".
Bit 2 - PO power fail action.
When the power for the Physical Output (PO)
fails, the drive will go to the Zero state.
Note: "power" may well be high pressure air
or hydraulic fluid.
Bit 3 - Field Bus power fail action.
When the power normally available on Field
Bus itself fails, the drive will go to the
Zero state.
Note: the basis for the status of this bit
may be a physical jumper that can be
changed by the user. Nevertheless,
it appears to be a ROM value to the
Field Bus.
Bit 4 - Keylock (LO mode) is supported by
hardware (i.e., it has a key!)
Bit 5 - The hardware value (I/O_VALUE) is
discrete. It must be set to all zero's to
go to the Zero state; all one's to go to the
non-Zero state. (If this bit is reset, the
value is either analog or tristate.)
Bit 6 - The hardware value (I/O_VALUE) is
tristate; one can select all zero's or all
one's as above or can set any other value
for "stop and hold it where it is". (If
this bit is reset, the value is either
analog or two-state.)
Note: bits 5 and 6 CAN NOT BOTH be set at the
same time.
--```,``-`-`,,`,,`,`,,`---
Bit 7 - Auto-Calibration is supported.

Bits 8 & 9 - AO-Standard Auto-Format variables
Data Class - Descriptor.
00 = Pneumatic
01 = Hydraulic
10 = Electric
11 = Other
Bits AH & BH - AO-Standard Auto-Format variables
Data Class - Extent.
00 = Base
01 = Extended
10 = Full
11 = Other
Bits CH - DH = reserved.
Bits EH - FH = manufacturer specific.
* MSP_DEVICE_STAT - MSP Device Status Register:
= dynamic memory, read only - data passing from MSP
to AO
= present if, and only if, TIME_CRIT0, bit AH is
set.
= stati of "switches" that are binary detectors of
the indicated states. Totally independent of any
configured scalar limits. Some detectors may be
in parallel with other sensors.
Note: if a bit indicates the state of a switch that
is not available, it is to be left reset.
Bits 0&1 - Physical Output State
00 = Normal
01 = Hold - the physical output is
trying to prevent motion.
10 = Zero - the physical output is

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
560
trying to move to the

extreme safe position.
11 = (invalid)
Note: states 01 and 10 setMSP_ALERT, bit CH
Bit 2 - Open switch state
Note: this refers to a possible measurement
switch on the driven machine that
indicates that the machine is in its
"open" state.
Note: sets AO block anti-windup high.
Bit 3 - Closed switch state
Note: similar to Bit 2 but "closed".
Note: sets AO block anti-windup low.
Bit 4 - Override switch state
Note: this refers to a switch that can
detect a command to "override" the
normal commands to the servo. This
switch is not intended to detect a
failure of the AO system itself.
This switch forces IMan mode.
Note: sets MSP_ALERT, bit AH.
Bit 5 - Keylock switch state
Note: this is the standard LO Keylock!
If LO mode is set by a command from
Field Bus, this bit IS NOT set.
Note: sets MSP_ALERT, bit EH.
Bit 6 - Power Fail switch state
Note: this refers to the determination of a
loss of power by a binary measurement,
not as a result of the "low power"
limit.
Note: sets MSP_ALERT, bit 4.
Bit 7 - Bypass state
Note: this refers to a switch that can
detect a command to "bypass" the
servo. This is intended to be
exactly the same as a Field Bus
command to "Bypass".
Note: sets MSP_ALERT, bit DH.
* MSP_SERVO_SWITCH - MSP Servo Switch Register:
- required
= dynamic memory, can write only while in Man mode.
= Data passing from maintenance person to MSP.
= Bits 1-3 will be reset at every block execution if
the block is not in Man mode. They will be taken
as commands by the MSP section in Man mode.
Note: if a bit indicates the state of a command that
is not supported, it is to be left reset.
--```,``-`-`,,`,,`,`,,`---
Bit 0 - this register not active.

Bits 1-3 reset every cycle if not in Man mode.
Bit 1 - Force Close (may automatically
time out and reset).
Bit 2 - Force Open (may automatically time
out and reset).
Bit 3 - Force Neutral (meaningful only if
the device has a "neutral" state).
Bit 4 - Automatic characterization on.
See later description section for a
description of this function.
Meaningful only if MSP_READ_ONLY, bit
7 is set.
Bits 5 & 6 - Reserved.
Bit 7 - Manufacturer specific.
* MSP_SERVO_STAT - MSP Servo Status Register:
to AO
= required

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
561
Note: if a bit indicates a piece of information

that is not available, it is to be left reset.
Note: this parameter is specifically designed to be
used by a hand held communicator that is
displaying maintenance information to a
technician.
Bit 0 - Automatic characterization in progress
See later description section for a
description of this function. Meaningful
only if MSP_READ_ONLY, bit 7 is set.
Bit 1 - Bypass.
This indicates that the MSP section is
operating in the Bypass condition. It may
be due to a request from Field Bus or it
may be due to a hardware switch signal,
i.e., MSP_ALERT, bit DH.
Bit 2 - Override.
This indicates that there is some kind of
override of the servo such that it can not
respond to the signal from the AO block -
but NOT DUE to a failure.
Set if, and only if, MSP_ALERT, bit AH
is set.
Bit 3 - Overload/Low oil level.
This refers to a overload of the (electric)
servo itself or low hydraulic fluid level
in a hydraulic system.
Set if MSP_ALERT, bits 5 or 6 are set.
Bit 4 - Fail.
This refers to a detected failure of the
servo itself.
Set if MSP_ALERT, bits 0, 1, or 2 are set.
Bit 5 - Power Fail
This refers to the physical output (PO)
power - see MSP_READ_ONLY, bit 2 above.
Note: this refers to a measurement of the
power that is below the low power
alert limit or is reported by the
switch driving MSP_ALERT, bits 3 or
4.
Bit 6 - Saturated high.
The servo is saturated high but not at its
extreme high position.
Bit 7 - Saturated low.
The servo is saturated low but not at its
extreme low position.
If MSP_ALERT, bit 4 is set, the appropriate one
of the last 2 bits are set.
--```,``-`-`,,`,,`,`,,`---
@ Alert Registers:
* MSP_ALERT - MSP Alert Register:
to AO and detail behind device alerts.
= required
Bit 0 - Actuator failure.
Bit 1 - Response failure.
Bit 2 - External Processor Failure.
IF MSP_READ_ONLY, bits 8 and 9 = 00B, then
' a pneumatic valve
Bit 3 - Low air header pressure
Bit 4 - Low air-set pressure
Bits 5&6 - Manufacturer specific
Bit 7 - Servo Saturated
' a hydraulic valve
Bit 3 - Low oil header pressure.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
562
Bit 4 - Low regulated oil pressure.

Bit 5 - Low oil level.
Bit 6 - High oil temperature.
Bit 7 - Servo Saturated.
' an electric valve
Bit 3 - Low mains voltage.
Bit 4 - Low delivered voltage.
Bit 5 - High load.
Bit 6 - High winding temperature.
Bit 7 - Servo Saturated.
' a "other" valve
Bits 3-7 - reserved.
Bit 8 - Failure indicated by switch
Bit 9 - Failure indicated by INPUT1
Bit AH - Override.
Bit BH - Man mode.
Bit CH - Failsafe.
Bit DH - Auto-Bypass.
Bit EH - Keylock.
Bit FH - Manufacturer specific.
* MSP_DIAG_ALERT - MSP Valve Diagnostic Alert Register:
- present if, and only if, TIME_CRIT0, bit AH is
set.
to AO and detail behind disgnostic alerts.
= if the following bit is set, then the indicated
diagnostic measure is in violation of a limit:
Bit 0 - Travel odometer
Bit 1 - Reversal counter
Bit 2 - Time in cavitation
Bit 3 - Hysteresis
Bit 4 - Deadband
Bit 5 - Breakaway force.
Bit 6 - Diagnostic Auto-Format variable 4.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Bit 7 - Diagnostic Auto-Format variable 5.

Bits 8 - CH = reserved.
Bits DH - FH = manufacturer specific.
* AUX_ALERT - Auxiliary variable alert register:
- present if, and only if, TIME_CRIT0, bit AH is
set.
to AO and detail backing the auxiliary
measurement alerts.
= IF the following bit is set, then the measurement
is in violation of a configured limit:
--```,``-`-`,,`,,`,`,,`---
Bit 0 - Valve body temperature
Bit 1 - Packing temperature.
Bit 2 - Seal pressure.
Bit 3 - Seal temperature.
Bit 4 - Leak sensor.
Bit 5 - Cavitation sensor - calculated
(as a time delay)
Note: see the description of the
cavitation detection methods
later in this paper.
Bit 6 - Cavitation sensor - internal sound.
Bit 7 - Cavitation sensor - free air sound.
Bit 8 - Auto-Format variable 5.
Bit 9 - Auto-Format variable 6.
Bits AH - CH = reserved
Bits DH - FH = manufacturer specific.

563
@ Bad Detector Registers:

- present if, and only if, TIME_CRIT0, bit AH is set.
* AUX_BAD - Auxiliary variable bad detector register:
to AO and detail behind the "bad auxiliary
measurements" alert.
= IF the following bit is set, then the measurement
is not valid due to a measuring failure [if these
variables had a status byte, bit 1 (Bad) would be
set]:
Bit 0 - Valve body temperature
Bit 1 - Packing temperature.
--```,``-`-`,,`,,`,`,,`---
Bit 2 - Seal pressure.
Bit 3 - Seal temperature.
Bit 4 - Leak sensor.
Bit 5 - Cavitation sensor (calculation).
Bit 6 - Cavitation sensor - internal sound.
Bit 7 - Cavitation sensor - free air sound.
Bit 8 - Inlet pressure measurement.
Bit 9 - Minimum pressure measurement.
Bit AH - Outlet pressure measurement.
Bit BH - Process fluid temperature.
Bit CH - Process fluid density.
Bit DH - Process fluid flow.
Bit EH - reserved.
Bit FH - manufacturer specific.
+ I/O_AF (indices 0-3) - AO-Standard Auto-Format variables
- Present if, and only if, TIME_CRIT0, bit AH = set.
- Indices 0 and 1 = indirect writeable; indices 2 and 3 are
read-only.
- Indices 0 and 1 are assumed to be implemented in the
device's non-volatile memory.
- Indices 2 and 3 are assumed to be implemented in the
device's dynamic memory.
- In the data base of the field device - not in the Field Bus
static data base.
- Length of each depends on bits 8-BH in MSP_READ_ONLY
- Bits 8-BH define whole sets of parameters as supported or
not supported in these variables. If an individual
parameter is not supported in a set that is otherwise
supported, its value may be set to NaN.
- Stored in the hardware data base.
- The above 4 parameters are Auto-format variables. Since
they are completely defined, it is not necessary that they
actually contain any formatting data. Higher level devices
and hand held communicators can be built with the
information necessary to unformat these parameters. The
parameters are totally defined in Table 2.
MAN MODE:
Manual mode is not normally supported in an AO block. There are two options
that only function in Man mode: the Servo Switch Register and Triggered
Calibration (both described immediately next). If either function is supported,
then Man mode must be supported. Therefore, if bits BH and DH of TIME_CRIT0 are
both reset, the block will reset the Man mode permitted bit every cycle, else Man
mode will be supported but may be "not-permitted" by the user.
IMAN MODE:
IMan mode is not normally supported in an AO block. There are only two
conditions under which a manufacturer would include this functionality. First,
IMan will be set if 1) the MSP and/or hardware section of the AO system supports

//^:^^#^~^^"~~:~"~$$"~

564
an "Override" switch (see bit 4 in MSP_DEVICE_STAT and bit 2 in MSP_SERVO_STAT)

and 2) that switch is activated. Second, if the manufacturer supports any other
type of feedback into the hardware and/or MSP section of the system that can
indicate that the output has been forced to some independently determined value
(but not FAILSAFE).
BYPASS OPERATION:
The exact function of a "bypass" operation varies depending on the form of
the AO hardware. The Standard AO block optionally provides the data base support
for the operation, as an alternative to the normal control of the hardware output
signal:
- indicator of functional support - bit 2 of TIME_CRIT0.
- ability to prohibit requests for bypass - bit AH of OPTIONS0.
- indicator of ability to automatically start bypass upon certain MSP
failures - bit 0 of N_TIME_CRIT0.
- ability to prohibit auto-bypass - bit BH of OPTIONS0.
- hardware switch to request bypass - bit 7 of MSP_DEVICE_STAT.
- data base discrete to request bypass and indicate its current state -
BYPASS_REQ
- two static data base values to specify variables needed from the user
in order to execute bypass operations - BYPASS_LO and BYPASS_HI.
- manufacturer-fixed ESI units for the previous two variables -
BYPASS_SI_UNIT0 and 1.
Note that the normal mode indicators apply equally to either the normal or the
bypass operation; bypass is not a mode, it is an alternate control algorithm.
The meaning of "bypass" IS defined in the generic case of an instance of SO

hardware that only controls one output signal. "Bypass" will mean that a non-
normal response signal that is a measure of the SO hardware output signal itself
is to be used as the servo feedback.
Consider the specific case of a pneumatic valve positioner driving a spring

opposed pneumatic valve. This positioner will only have 1 output signal - the
"air to the valve actuator". In this case, "bypass" will mean that the
positioner will control the air pressure to the valve actuator instead of the
position of the closure member as is the normal case. The two data base
variables will be the air pressure, in units of Pag, to define the 0% and 100%
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
points on the OUTPUT0 range. Note that these two values can be inverted - the
low value may well be the larger number.
OPTIONAL INPUT2:
There are situations in which the AO system itself can not determine if the
machine being manipulated by the powered output is at its limits or not. In that
case, it is not possible to accurately determine the wind-up bits for the cascade
structure. This can be overcome by supporting INPUT2 in the AO block. This
input allows external discrete detectors of wound-up low and wound-up high to be
introduced using limit switches. It also allows an external indication of
failure to be introduced into the cascade information if it can be measured as a
discrete.
The first operation on the data in INPUT2 is to "OR" the values of bit 1 of
--```,``-`-`,,`,,`,`,,`---
each of the status bytes of bits 4, 6, and 7 in INPUT2 with the value in bit 1 of
INPUT2 itself. The result is placed in bit 1 of INPUT2's value.
Then, if bit 1 of INPUT2 is set, the value is IGNORED. Otherwise, the value
of bits 4, 6, and 7 are Boolean OR'ed with the stati reported by the MSP and the
result is set into the status of the Setpoint of the AO block.

565
SERVO SWITCH REGISTER:

The manufacturer may optionally include an ability to command Man mode to the
MSP section of the AO system, then allow a Field Bus device to write to the
"Servo Switch Register" that was defined above. By setting the appropriate
switch in that register, the maintenance person can command the servo to Close,
Open, or stay "neutral". In some device types, neutral may have no meaning and
that bit will simply be ignored. In addition, the maintenance person can command
the start of the "auto calibration" described next.
The support for this register is indicated by bit DH in TIME_CRIT0. If that

bit is set, the switch register is present in the data base. The user has the
option to prohibit the use of the register, even if it is present, by setting bit
CH in OPTIONS0.
If the option is supported and not prohibited, the maintenance person can set
Man mode in the normal way (writing to REQ_MODE), then issue commands to the
register by writing to MSP_SERVO_SWITCH.
--```,``-`-`,,`,,`,`,,`---
AUTOMATIC CALIBRATION:
An AO system that has a full function measurement of the response to the
output (sometimes the actual "stem position") may include a fixed relationship
between the measurement of the response and a value that directly corresponds to
the Setpoint. An alternative to this is to "learn" the relation between the
Setpoint and the response while the AO system is known to be working accurately.
The parameters of the AO block have been set up to support such a function
but the function itself is totally undefined. There is a bit that indicates that
Auto-Calibration is supported - MSP_READ_ONLY, bit 7. There is a bit to instruct
the MSP to begin the "Auto-Calibration" - MSP_SERVO_SWITCH, bit 3. There is a
bit to indicate that the function is in progress - MSP_SERVO_STAT, bit 0. It is
intended that the function be turned of by the same bit that turned it on. Any
implementation might also want to include a maximum timer for this function so
that it could not be left on accidentally but such a time is not included (or
needed?) in the data
base.
If the field device supports triggered calibration (bit BH in TIME_CRIT0),
then it will accept the calibration points in percent of range. The bias will be
applied by the MSP to the appropriate values, depending on the type of hardware.
Refer to the paper "Human Interface Considerations", page 19 for a description of
triggered calibration.
An AO system that supports both triggered calibration and bypass will be

required to support two different sets of triggered calibration data. When the
device is in bypass operation, the LO_CAL and HI_CAL values and the corresponding
bias terms that were used for normal operation will be stored and replaced with
values that were set during bypass operation. If such values do not exist, then
LO_CAL and HI_CAL will be set to NaN and no calibration will be performed while
in bypass operation.
GO BAD AT END OF RANGE:

It is assumed that OUTPUTS 1-3 have finite range limits defined by OUTx_LO
and OUTx_HI. When an OUTPUTx is supported and its value as obtained from the
hardware is at a range limit, it may be marked Bad at the option of the user.
The options for the low and high limits of each of OUTPUTs 1-3 are defined in
bits 4 - 9 of OPTIONS0.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
566
FLOW INDICATION:
It is expected that some manufacturers may decide to supply Field Bus
equipment that can measure fluid flow from data collected at a valve. This is
intended to be supported by using an AI function block in the Field device, not
as an auxiliary measurement on the AO block. The device would provide a physical
hardware connection point for a SI that would provide the necessary data to the
AI block.
CAVITATION:
A useful measurement of cavitation, or incipient cavitation, at a valve would
be of great interest. The Standard AO block does not establish any particular
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
method of measuring this parameter but it does provide three alternate methods of
describing a parameter that might be provided by a Field device. They are:
1) Calculation - the manufacturer would probably require that the
user enter data for the fluid and possibly other
data needed to calculate the cavitation condition.
Then, appropriate actual data measured at the valve
would be used to dynamically calculate a measure of
cavitation. It is assumed that this measurement can
be expressed in terms of a Cavitation Index where
cavitation would be expected to be absent while the
index is less than unity, to be incipient at unity,
and to increase in severity as the index increased
above unity.
The data describing the fluid is entered in the

optional Auto-Format variable VAPOR_PRESS. There is
no requirement that this data need be the actual
vapor pressure of the fluid; a manufacturer may
specify that it be somehow corrected, emperically
determined, etc. Also, a manufacturer may specify
that the entire set of parameters and function
herein call "cavitation" will be understood to be
"flashing".
If the calculation method requires the data provided

by VAPOR_PRESS but the data is not present (as
evidenced by the presence of NaN's), then the
"Cavitation Index" will be reported as 0.
2) Internal Sound - this description method is based on the assumption
that the manufacturer would mount a microphone-like
device in the valve. It is assumed that this device
would not be affected by free air noise. The units
of measure for this value will be sound pressure
level, in units of dBA.
3) Free Air Sound - this description method is based on the assumption
--```,``-`-`,,`,,`,`,,`---
that the manufacturer would mount a microphone-like
device in the valve. It is assumed that this device
would be isolated from the valve such that the
majority of the sound conducted to it would be that
carried by the free air. The units of measure for
this value will be sound pressure level, in units of
dBA.
It is anticipated that any of these measurements would have to be used on a

time-relative basis, as opposed to an absolute value. For example, a higher
level system might monitor and learn the characteristics of the measurement over
time under normal operating conditions. Then it could establish a limit for the
measurement and allow the Field device to alert abnormal behavior as evidenced by
violation of the limit.

567
OTHER PARAMETERS:
A number of other parameters have been identified as being needed by the AO
block to better perform some of its functions or as being measurements or derived
calculations that would be of use to the user. Unfortunately, these data have
not, or can not, be completely defined. Therefore, there is a high probability
that manufactures may wish to add parameters to those defined in this Standard.
Additional parameters can be added to the AO block's data base as extension

parameters (see the discussion of "extensions" in the paper "Data Owner Structure
- Logical Nodes", page 3). Note that these extensions would then normally be
considered a part of the data base of the AO block, would be expected to possibly
be part of the static data base, and thus should be "uploaded" and "downloaded".
An alternative would be to use the 3 I/O_AF parameters in the individual

hardware point's physical node data base. These would be the variables just
after the 4 defined in the Standard. They would obviously be part of the
physical device's data base and would not be considered for inclusion in the
static data. Higher level devices would know that they existed and could read
them. Since they would be Auto-format variables, and not AO-Standard, the higher
level device would know to decode them according to the normal Auto-Format rules.
In addition, the data could be entered as the Auto-Format variables that are
provided for each physical I/O TYPE. Again, they would naturally be considered
as part of the data base of the hardware, not of the AO block. They also would
have all of the benefits of the Auto-Format structure. In a physical device that
only had one SO hardware point, there would be no conflict with these parameters.
--```,``-`-`,,`,,`,`,,`---
However, if the physical device served more than one SO point, there would be a
conflict.
An Analog Output (AO) block is used to manipulate one physical variable that
is a scalar value. It is associated, via. its hardware pointer, with a set of
physical node hardware of the scalar output (SO) type. There is hardware and
software in the signal flow of a controlling device, as shown in Figure 1. The
physical variable manipulates a machine, typically a valve.
The output signal of the AO block is passed to the Scalar Output hardware: to
the SO connection. This connection may be "exposed", as in a simple digital-to-
pneumatic transducer, or it may be "hidden" within a single total device. If it
is exposed, the labeling rules given in the paper "Data Owner Structure -
Hardware" must be followed.
In Figure 1, the AO system is divided into "AO block", MSP, and "Hardware".
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
The MSP and the Hardware are both part of the "SO Hardware". It is the hardware
that controls the power to the control device, typically a valve.
The MSP lies between the fully Standardized AO block and the completely
undefined hardware. The MSP handles the unique characteristics of the hardware,
which is typically vendor specific. Consequently, the design of the AO block
assumes signal processing to also be vendor-specific but with its interface to
the AO block totally defined.
The only processing that the AO block does on the Setpoint is the optional
reversing. If triggered calibration is supported, the bias term calculated from
the linear calibration correction will be added to the appropriate value by the
MSP.
The Setpoint of the AO block will always be in percent of the controlled

range.
The AO block exchanges signals with the MSP through the OUTPUT0 connection, a
hardware pointer. It accesses the value used for INPUT1 through the same
hardware pointer. If the device supports auxiliary variables, they are included
as part of the OUTPUT0 connection. Physical devices that can support multiple

568
major SO signals would necessarily allow multiple AO blocks. The connection

between the signal processing and the AO block is bi-directional. The data flow
in the reverse direction is, for example, the auxiliary measurements, and/or
calibration of the signal processing, as discussed below.
The Standard AO block has been designed on the basis of a model of the MSP.
The model allows several levels of complexity for the MSP. Bit AH of TIME_CRIT0
specifically allows implementations with a minimal MSP section. When that is the
case, a number of defined parameters are not supported. However, there are a few
functions in the model that have to be performed by the minimal MSP when bit AH
is reset. First, there has to be a value available for INPUT1, the response
measurement. If there is no real response measurement, a version of the MSP
setpoint that includes the effect of any rate limiting, cutoff, and gap control
will be generated by the MSP - call it CR. The AO section will move CR into both
INPUT1 and SERVO_SP. (Note that, at equilibrium and under normal operation, this
value must be exactly the same as OUTPUT0.) In that case, the status of INPUT1
will be:
- bit 1 (Bad) will be RESET if the block's Output is not failed AND
there is no indication of failure.
- bit 2 (Not-from-Process) will be set if bit 1 is set or if the block
is in a mode of higher priority than Auto.
- bit 5 (No-path-to-Process) will always be set.
- bits 6 & 7 will be used to indicate that the value is limited by the
devices travel range.
- all other bits will be reset.
Second, the block may still be designed to support Triggered Calibration. If

so, the triggered calibration procedure must be accomplished by the minimal MSP
logic; it must operate on the value of OUTPUT0. It is important that, at
equilibrium, the value of INPUT1 be the exact value of the Setpoint, not slightly
different due to the bias.
Finally, a value must be generated for SERVO_SP. If there is no limit or gap

action, this is simply the value of OUTPUT0 for the previous cycle.
The manufacturer may choose to add sensing switches to the SO hardware that
can detect a command to "override" the servo. In that case, the manufacturer
will determine the exact action but, in any event, the AO block will be forced to
IMan mode.
The manufacturer may also choose to add sensing switches to the SO hardware
that can detect the "open" and "closed" positions of the driven machine. This
data could be used in the operation of the servo and in setting the wound-up
status bits in the status byte of OUTPUT0.
The manufacturer may choose to design the Field device in such a way that the
hardware and the communication logic can continue to operate despite the fact
that the logic engine that executes the function blocks has failed. Given such a
--```,``-`-`,,`,,`,`,,`---
design, the manufacturer may set bit 3 in the TIME_CRIT0 options bit string to
indicate to a higher level device that it may be able to write the value of the
output directly to the hardware in an emergency. When that functionality is
provided, the location in which to store the desired output value will be in the
physical node parameter "I/O_VALUE". The parameter will be a 16 bit unsigned
integer; the value will be taken as a fraction of the instrument's full range
(i.e., a fraction of the -5% to 105% range).
Some control devices in which the hardware actually measures auxiliary

variables exist in industry today . A simple provision for those variables is
included in the design of the Standard SO hardware and in the AO block. The
variables will always be expressed in ESI units.
The AO block is modeled as transferring the auxiliary values from the

hardware directly to Outputs 1, 2, and/or 3. It is required that these Output
values be in ESI units and 4 byte floating point data format. They are available
for reading by other entities on Field Bus.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
569
Outputs 1-3 have status bytes. Bit 1 (Bad) and bit 2 (Not-from- Process)
will be set if the hardware indicates that the value is not good or, at the
user's option, at the range limit. Bit 4 will indicate a hardware failure. Any
time the block is not in O/S mode, bit 5 (No-path-to-Process) will be set. Bits
6 & 7 will be used to indicate that the value is at the limit of its travel (or
is limited by the user-set limits). All other status bits will be reset. When
the block transitions to O/S mode, bits 1,2, and 5 will be set and all other bits
reset immediately after the transition. In subsequent cycles of O/S operation,
all values and status bytes will be left unaltered by the algorithm.
Note that the definitions of Outputs 1-3 assign the first (and second)
priority assignments of variables to specific Outputs. There is no requirement
that Output 1 be supported when Output2 is supported.
A manufacturer may decide to offer the ability to generate alarms on a

process value that exists as a floating point named parameter. If so, the
optional "PV Pointer" standard block function will be supported. When it is, the
user can configure the PV pointer to select any of the block variables defined
here that have a 4 byte floating point data type as the "PV". The variable
SERVO_SP is defined primarily for this service. When used as the TARGET against
a "PV" of INPUT1, the alert function is most effective. The block's alarm
processing will be done on the PV. When the PV pointer is not supported, the
parameters "PV" and "TARGET" must still be supported: PV will be identical to
INPUT1 but there will be no process alarms; the "target" pointer will default to
SERVO_SP but may be redefined.
CHARACTERIZATION DESCRIPTION:
Most analog controller algorithms work best in a loop of linear elements.
The measurement side of the loop can be linearized over wide ranges. The output
side cannot.
A typical example of this situation can be found in the ubiquitous flow loop
with a spring return pneumatic valve. The closure member position will follow
the output of the controller in a linear fashion if friction is negligible and
the pressure forces are balanced. The valve discharge coefficient, Cv, can be
made linear with closure member position, but the valve will not have a linear
effect on the process unless the pressure drop is constant, which is seldom true.
The pressure drop across the value almost always decreases as the valve opens.
Even so, there are a lot of useful flow control loops using these elements.
The range of stable control is determined by the match of Cv versus closure

member position to the characteristics of the process. The "equal percentage"
characterization was introduced to provide an approximate compensation for this
problem.
Obviously, a microprocessor can do a more flexible job of providing a

specific valve characteristic if it has the rules and data to do so. The value
of better characterization will depend on the process. In this context,
"characterization" refers to the attempt to linearize the gain of the total
process, not of the valve response. In fact, characterization usually severely
distorts the CV vs. AO block SETPOINT response.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
The standard characterizations are defined in Table 1: they are:
0 - Quick Opening
1 - Modified Quick Opening
2 - Linear
3 - Modified Linear
4 - Modified Parabolic
5 - Equal Percentage
6 - Hyperbolic
7 - Manufacturer Specific
Figure 2 illustrates the linear, modified linear, and equal percentage curves and
the definition points for the other curves.

--```,``-`-`,,`,,`,`,,`---

570
In the Standard AO block, the "native" characteristic of the valve can be

configured unless it is fixed in the AO block by the manufacturer. The MSP can
then modify its signal to alter the power to the valve in such a way that the
valve appears to be operating with the configured characteristic rather than the
native characteristic. From the perspective of the user, the user simply
configures the response that is appropriate for the application. A manufacturer
may prohibit certain possible characterization curves if the altered curve would
not perform satisfactorily.
In applying a change to a valve's characterization curve as explained above,

the MSP will have to be aware of two curves, the "native" and the "requested".
If the manufacturer has products with typical characteristic curves in both of
the Standard types, then the conversion between the types may be based on his
typical curves. If the manufacturer does not have typical curves for one or both
of the curves, the following guidelines should be followed in defining them:
0 - Quick Opening - pass through 85% of flow at 10% open; linear
between closed and 60% of flow; linear between 30% open
and 100% open.
1 - Modified Quick Opening - pass through the midpoint of the
defined limits; linear approach to closed and open.
2 - Linear - exact linear.
3 - Modified Linear - half way between linear and equal percentage
between closed and 30% open; crossover linear at 65% of
flow.
4 - Modified Parabolic - exactly half way between linear and equal
percentage.
5 - Equal Percentage - exact.
6 - Hyperbolic - pass through 20% of flow at 85% open; linear
between closed and 60% of travel; linear between 50% of
flow and 100% of flow.
7 - Manufacturer Specific
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

--```,``-`-`,,`,,`,`,,`---
Analog Out Protocol

571
AO Table 1, Definition of Characterization Types

The MSP of a Standard AO Function block may provide the capability to force a
valve to perform as if it had any one of several different inherent flow
characteristics. The user will select the desired characteristic from a set of
possible choices. This Table defines the meaning of the several choices that can
be allowed.
DEFINITIONS:
- From ISA S75.05:
Valve: A valve is a device used for the control of fluid flow. It
consists of a fluid retaining assembly, one or more ports
between end openings and a movable closure member which opens,
restricts or closes the port(s).
Closure Member: A movable part of the valve which is positioned in
the flow path to modify the rate of flow through
the valve.
Inherent Flow Characteristic: The relationship between the flow
rate through a valve and the travel of the closure member as
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
the closure member is moved from the closed position to rated

travel with constant pressure drop across the valve.
Installed Flow Characteristic: The relationship between the flow
rate through a valve and the travel of the closure member as
the closure member is moved from the closed position to rated
travel when the pressure drop across the valve varies as
influenced by the system in which the valve is installed.
- Closure member position is always stated in terms of a percent of
travel from the closed position to rated travel.
- The flow rate through a valve is always stated as a percent of the
--```,``-`-`,,`,,`,`,,`---
flow rate through the valve at the rated travel of the closure member
and with the same pressure drop.
- According to ISA S75.11, the permissible deviations between actual and
manufacturer-stated inherent flow characteristics varies from 15.8% at
10% of flow to 10% of flow at rated travel. The limits quoted in the
following definitions are intended to be absolute limits. Therefore,
a manufacturer should allow the variation in the measurement within
the following limits.
- Restrictions on the following characterizations do not apply to the
first nor last 5% of travel.
Code 0 = Quick Opening
From ISA S75.05:

An inherent flow characteristic in which there is a maximum
flow with minimum travel.
Additional Restrictions for this Standard:
The inherent flow, as a percent of maximum flow, must always
be greater than the travel, as a percent of total travel. In
addition, the inherent flow must be greater than 60% of maximum
flow at 10% of travel from closed.
Code 1 = Modified Quick Opening
Restriction of this Standard:

be greater than the travel, as a percent of total travel. In
addition, the inherent flow must be:
- less than 60% of maximum flow at 10% of travel.

572
- greater than 45% of maximum flow at 30% of travel.
Code 2 = Linear
From ISA S75.05:

An inherent flow characteristic which can be represented by a
straight line on a rectangular plot of flow coefficient (CV )
versus per cent rated travel. Therefore, equal increments of
travel provide equal increments of flow coefficient (CV ) at
constant pressure drop.

The inherent flow must be:
- Less than 65% of maximum flow at 50% of travel.
--```,``-`-`,,`,,`,`,,`---
- Greater than 35% of maximum flow at 50% of travel.
Code 3 = Modified Linear

be less than the travel, as a percent of total travel as
the closure member is moved from closed to a "transition point".
All positions of travel with a higher per cent of travel than the
transition point will produce an inherent flow, as a percent of
maximum flow, that is greater than the travel, as a percent of
total travel. In addition, at some point with per cent travel
below the transition point, the percent flow will be at least 10%
less than the per cent travel and/or at some point with per cent
travel above the transition point, the percent flow will be at
least 10% greater than the per cent travel.
Code 4 = Modified Parabolic
From ISA S75.05:

An inherent flow characteristic which provides fine throttling
action at low valve closure member travel and approximately a
linear characteristic for upper portions of valve travel. It is
approximately midway between linear and equal percentage.

The inherent flow must be:
Code 5 = Equal Percentage
From ISA S75.05:

The inherent flow characteristic which, for equal increments
of rated travel, will ideally give equal percentage changes of the
existing flow coefficient (CV ).

be less than the travel, as a percent of total travel. In

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
573
Code 6 = Hyperbolic

be less than the travel, as a percent of total travel. In
- less than 30% of maximum flow at 80% of travel.
Code 7 = Manufacturer Specific.
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
574
AO Table 2 Definition of AO Standard Auto-Format

Variables
The Standard AO Function block defines several Auto-Format variables that can
optionally be supported in the hardware data base. If these variables exist,
their names will be I/O_AF and they will have their defined index number. The
content of the variables is described by bits 8-BH in the MSP_READ_ONLY parameter
defined in this paper. This Table gives the definition of these parameters.
This table includes three columns under the title "Extent"; the columns are B
(Basic), E (Extended), and F (Full). These descriptions are consistent with the
definition of the bits in 8-BH in MSP_READ_ONLY. If an individual parameter has
an "x" under a particular "Extent" class, then that parameter will be included in
the Auto-Format variable if that Extent class is covered - i.e., its bit is set
in MSP_READ_ONLY, bits AH and BH.
Extent Data Size

Parameter Description B E F Type (Bytes)
I/O_AF, Index 0:
+ (Servo and power static data)
Servo saturation alert time delay, s x x x Float. Pt. 4
(See note 1)
Servo setpoint gap, % x x x Float. Pt. 4
Servo setpoint low limit, % x x Float. Pt. 4
Servo setpoint high limit, % x x Float. Pt. 4
Servo setpoint decreasing rate limit, %/s x Float. Pt. 4
Servo setpoint increasing rate limit, %/s x Float. Pt. 4
Servo setpoint low cutoff, % x Float. Pt. 4
Servo setpoint high cutoff, % x Float. Pt. 4
Servo setpoint cutoff hysteresis, % x Float. Pt. 4
+ IF Power Class = Pneumatic, then

Air set pressure low limit, Pag x x Float. Pt. 4
--```,``-`-`,,`,,`,`,,`---
Air header pressure low limit, Pag x Float. Pt. 4

Actuator volume at minimum stroke, m**3 x Float. Pt. 4
Actuator volume at maximum stroke, m**3 x Float. Pt. 4
Orifice coefficient for Open, C(v) x Float. Pt. 4
Orifice coefficient for Close, C(v) x Float. Pt. 4
+ IF Power Class = Hydraulic, then

Hydraulic fluid pressure low alert limit, Pag x x Float. Pt. 4
Hydraulic fluid header pres. low limit, Pag x Float. Pt. 4
Hydraulic fluid temperature high alert limit, K x Float. Pt. 4
Hydraulic fluid level low alert limit, % x Float. Pt. 4
Actuator stroke rate, %/s x Float. Pt. 4
+ IF Power Class = Electric, then

Motor winding temperature alert limit, K x x Float. Pt. 4
Motor load alert limit, % x x Float. Pt. 4
Open stroke time, s x Float. Pt. 4
Close stroke time, s x Float. Pt. 4
+ IF Power Class = Other, then //^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Undefined.
+ Total Bytes 60
I/O_AF, Index 1:
+ (Measurement static data)
Response correction time, s x Float. Pt. 4
(See note 2)
+ (Device description static data)

575
Maximum Hold state time, s x x Float. Pt. 4

Zero state rate limit, %/s x x Float. Pt. 4
(See note 3)
Power value at 100% of power, x x Float. Pt. 4
Pa if Pneumatic or Hydraulic,
A if Electric, undefined if Other.
Low Power alert setting, % x x Float. Pt. 4
Low Power failure setting, % x x Float. Pt. 4
+ (Auxiliary measurement static data)

Packing temperature alert limit, K x x x Float. Pt. 4
Body temperature alert limit, K x x Float. Pt. 4
Seal pressure alert limit, Pag x x Float. Pt. 4
(See note 4)
Seal temperature alert limit, K x x Float. Pt. 4
Leak sensor alert limit, % x Float. Pt. 4
(See note 5)
Cavitation alert limit -
calculated, % x x Float. Pt. 4
internal sound, dB x x x Float. Pt. 4
free air sound, dB x Float. Pt. 4
+ (Diagnostic measurement static data)

Travel odometer alert limit, % x x x Float. Pt. 4
(See note 6)
Reversal counter alert limit,
dimensionless x x x Float. Pt. 4
(See note 7)
Time in cavitation alert limit based on any
of the three cavitation methods, s x x x Float. Pt. 4
Time in "ball traveling" alert x Float. Pt. 4
limit, s (See note 8)
Time in temperature stress alert
limit, s (See note 9) x x Float. Pt. 4
Hysteresis alert limit, % x x Float. Pt. 4
Deadband alert limit, % x x Float. Pt. 4
Breakaway force (from seat)
alert limit, N x Float. Pt. 4
+ Total Bytes 88
I/O_AF, Index 2:
+ (Measurement dynamic data)
Raw response, % (RR in Appendix) x x x Float. Pt. 4
(See note 10)
+ (Servo and Power dynamic data)

Servo output 0, % x x x Float. Pt. 4
(See note 11)
Servo output 1, % x x x Float. Pt. 4
Setpoint after conversion x x x Float. Pt. 4
(See note 12)
+ (Device description dynamic data)

Hold state timer, s x x x Float. Pt. 4
(See note 13)
Power, % x x Float. Pt. 4
+ IF Power Class = Pneumatic, then

Air set pressure, Pag x x x Float. Pt. 4
Air Header Pressure, Pag x x Float. Pt. 4
Actuator pressure 0, Pag x x Float. Pt. 4
(See note 11)
Actuator pressure 1, Pag x Float. Pt. 4

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
576
+ IF Power Class = Hydraulic, then

Hydraulic fluid pressure, Pag x x x Float. Pt. 4
Hydraulic header pressure, Pag x x Float. Pt. 4
Hydraulic fluid temperature, K x x Float. Pt. 4
Hydraulic fluid level, % x x Float. Pt. 4
Actuator pressure 0, Pag x x Float. Pt. 4
(See note 11)
Actuator pressure 1, Pag x Float. Pt. 4
+ IF Power Class = Electric, then

Motor winding timperature, K x x Float. Pt. 4
Motor load, % x x Float. Pt. 4
Manufacturer's switch register x Binary 4
(See note 14)
+ IF Power Class = Other, then

Undefined.
+ Total Bytes 64
I/O_AF, Index 3:
+ (Diagnostic dynamic data)

Travel odometer, % x x x Float. Pt. 4
Reversal counter, c x x x Float. Pt. 4
Time in cavitation by any of three x x x Float. Pt. 4
methods, s
Time ball not fully open, s x x Float. Pt. 4
Time in temperature stress, s x x Float. Pt. 4
Hysteresis, % x x Float. Pt. 4
Deadband, % x x Float. Pt. 4
Breakaway force (from seat), N x x Float. Pt. 4
+ (Auxiliary measurement dynamic data)

Packing temperature, K x x x Float. Pt. 4
Body temperature, K x x Float. Pt. 4
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Seal pressure (secondary seal), Pag x x Float. Pt. 4
Seal temperature, K x x Float. Pt. 4
Leak sensor, % x Float. Pt. 4
Cavitation internal sound, dB x x x Float. Pt. 4
Process fluid temperature, K x x x Float. Pt. 4
Process fluid inlet pressure, Pag x x x Float. Pt. 4
Process fluid output pressure, Pag x x x Float. Pt. 4
Minimum process fluid pressure, Pag x x Float. Pt. 4
Cavitation free air sound, dB x Float. Pt. 4
Cavitation calculation, % x Float. Pt. 4
Process fluid density, x Float. Pt. 4
+ Total Bytes 84
Notes:
The ESI units are indicated as:
c - dimensionless counts
CV - valve opening
dB - sound pressure level in decibels
K - degrees Kelvin
m3 - volume
N - Newtons of force
Pag - gauge pressure, Pascals
Paa - absolute pressure, Pascals
s - seconds
% - percent
(1) The Servo saturation alert time delay is used to delay an alert
that the servo has been saturated in the same direction but it is
not at its position extreme.

--```,``-`-`,,`,,`,`,,`---

577
(2) Response correction time is the first order filter time to use to
filter the measured response before setting the value in INPUT1.
(3) Zero state rate limit is the rate at which OUTPUT0 can move as it
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
transitions to Zero due to a signal to go to the Zero state.
(4) The "Seal Pressure" is intended to be measured at a location such
that the pressure will be close to atmospheric when the seal system
is functioning correctly and will approach the process pressure when
there is a failure of the seal system.
(5) The leak sensor is intended to be a measurement such as a gas
detector that would detect the presence of process fluid outside
of the confines of the valve.
(6) The odometer measures the algebraic sum of the travel in percent.
Naturally, the sum of the "percents" will be a large number.
(7) The reversal counter is intended to count the total number of
changes in direction of movement of the power output of the
hardware. It is assumed that the manufacturer included a deadband
in the measurement of this value that will be approximately equal to
the hysteresis in the mechanical linkage of the valve.
(8) The "ball opening" timer is to measure the total time that a ball
valve in open/closed service is in transit between the two extremes
of closed and open.
(9) The "temperature stress" timer is the total time that the valve
spends above the temperature limit.
(10) Raw response is the measurement of the effect of the power output
before it is converted to the value shown in INPUT1. They differ by
the calibration correction and direct/reverse.
(11) A servo is assumed to have two outputs - called 0 and 1. If a
servo only has one output, it will be "0" by definition.
(12) The "Setpoint after conversion" is defined to be the value that the
MSP will pass to the servo but before limiting, cutoff, and gap
adjustments.
(13) The "Hold State" timer is to determine the maximum continuous amount
of time allowed in the state.
(14) The "Manufacturer's switch register" gives the states of a large
number of separate open/close switches that can sense the position
of the machine being driven by the output.

--```,``-`-`,,`,,`,`,,`---

578
Figure 1
ANALOG OUTPUT SYSTEM DIAGRAM

Keylock
RCAS_TL
MFG's H
CAS_TL Mode Select SIGNAL A
PROCESSING
(Software) R
INPUT0
Pointer D
Analog Select W
STANDARD AO Set Point
A
R
Analog
Algo.
OUTPUT0 E
INPUT1 (P) Processing (Z)
Input
F
Word 2 (X)
E
PV MSP
Bits Function Data
1 1,4,6,&7 Valve
0
Analog Analog Analog
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
OUTPUT1 OUTPUT2 OUTPUT3
Figure 42: Analog Output, Figure 1, Analog Output System Diagram
--```,``-`-`,,`,,`,`,,`---

579
Figure 2
ILLUSTRATION OF CHARACTERIZATION TYPES
100
90 Quick
Opening
80
Percent Inherent Flow
70
60
Modified Modified
Linear Parabolic
50 Quick
40
30
--```,``-`-`,,`,,`,`,,`---
Equal
20 Modified
Percentage
Linear
10 Hyperbolic
0
0 10 20 30 40 50 60 70 80 90 100
Percent Open
Figure 43: Analog Output, Figure 2, Illustration of Characterization Types
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

580
Analog Out -Pseudocode Protocol

ANALOG OUTPUT PSEUDOCODE AO Algo
A Standard "Analog Output" function block is required to have a specified

functional performance. The performance is described here by a set of
"pseudocode". There is no requirement that the actual logic used be consistent
with the pseudocode in any way; only that the externally visible performance of
the actual device APPEAR to be the same as would be achieved using the
pseudocode.
The Analog Output block has several optional functions. The following
pseudocode includes all of the options. If the options bit string indicates that
one or more of the options are not supported, then the associated sections of the
following pseudocode can be ignored if there is no affect on the remaining
supported functions.
The pseudocode presented below provides the total definition of the status
byte manipulation for all of the OUTPUT words and for INPUT1. The manipulation
of the mode and the status bytes of the transfer locations and the SETPOINT are
defined in "Status Logic", Attachment 1 to the paper "Function Block Structure",
and are not reproduced here.
Important aspects of the pseudocode, and absolute requirements for any

Standard implementation, are:
1) the hardware is not addressed when the block is in O/S mode.
2) the data base items that can be changed while in Auto mode are all
read from the public data base at one time as a coherent set.
3) the measurement results from the block's execution are all written
into the data base at one time, maintaining time-coherency.
4) any Field Bus access to the data base while the above data is being
read or written is blocked.
5) any Field Bus writes that occur while the block is processing but
the data base is not blocked will not be overwritten by the final
stores from the block.
6) all indicated data checking and alerts related to the base operation
and to the options that are supported are required to be implemented
in order to set bit 9 in the logical node's N_TIME_CRIT0
manufacturer's option bit string.
The manipulation of the two bit strings that report alarms and the 2 bit
strings that show unacknowledged alarms are not detailed in the pseudocode.
However, the bit strings are shown being written to the public data base at the
end of the procedure. All Standard implementations of the AO block will
ensure that these bit strings are updated coherently. Note that all alerts are
released to the User Layer Support Services immediately prior to the updating of
the bit strings.
This pseudocode assumes that all agents are processed according to the
description in the paper "Agents". It assumes that input values are present when
needed.
The pseudocode presented here includes certain validity checks on writeable

data that appear to duplicate the checks required in the Data Base Write Service
(DBWS). These checks must be included because the parameters in question can be
directly written from other blocks; such direct writes bypass the DBWS logic.
Alternately, if the DBWS did not include the checks, a human operator might not
be made aware of a faulty written value until up to 2 minutes after his write
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
command.
The pseudocode presented here uses the variable names defined in the
algorithm description paper. In addition, it uses the following notation:
MSP = the Manufacturer's Signal Processing section of the hardware.
T_VALUE = a temporary value without a status byte

--```,``-`-`,,`,,`,`,,`---

581
T_STAT = a temporary status byte

T_VALUE + T_STAT = the combination of the two pieces of data to
form a value plus its status byte.
LV_x where x is an INPUT = the "local variable" version of the
of OUTPUT word I/O word - see Figure 3 in the paper
"Function Block Structure".
T_x where x is a variable = a temporary value of the variable
defined in the algorithm retained until the mass update of
description the data base values.
When referring to the block's mode, all references to a single bit will
use the word "bit"; any reference to the "byte" signifies operation
on the full byte. For example, "REQ_MODE byte = Man" means all
eight bits in the requested mode are manipulated with only the Man
mode bit remaining set to 1 at the completion of the operation.
Alternately, "Set Man bit in ACTUAL_MODE" would simply set the
manual bit in the actual mode, leaving the other 7 bits unaltered.
The sections of the pseudocode are:

Start
Read Public Data Base Values
Cleanup After Reading
Calculate New Values Of Setpoint And Output0
Run The MSP
Process The Values Returned By The MSP
Calculate PV Pointer Values
Calculate OUTPUTs 1-3
Wait For The End Of Block Time
Write To Data Base While Protected
ALGORITHM PSEUDOCODE:
START
' Internal parameters available to this code:
' FORCE_INIT; refer to the paper "Function Block Structure", page 24.
' OLD_CLAMPx
' (only exists if bit 9 in TIME_CRIT_0 is set - output
' limiting/clamping is supported)
' x = 1-3 for OUTPUT1-3
' 0 = no old clamp
' 1 = old low clamp
' 2 = old hi clamp
' TRANSFER_VOID; refer to page 17 of the paper "Function Block
' Structure".
' SUPPRESS = control integer used to implement alert suppression
' as defined in the paper "Function Block Structure",
' page 23.
' 0 = no suppression
' 1 = suppress "Bad"
' 2 = suppress "Fail" and "Bad"
'
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
At the start of the normal block algorithm time:
BAD_CONFIG = reset ' a logic flag, set if bad block config.
FORCE_OS = reset ' a logic flag, set if must force O/S mode.
MM_SUPT = reset ' a logic flag, set if Man Mode is supported.
IF [(bit BH of TIME_CRIT0 = set) OR (bit DH of TIME_CRIT0 = set), then
. MM_SUPT = set
--```,``-`-`,,`,,`,`,,`---
' The IF tests to see if Man mode is supported. The calculation

' is done here once to gain efficiency.
SUPPRESS = 0
SUPPRESS = 1
TC = reset ' a logic flag, set if trig. cal. supported
IF {[TIME_CRIT0, bit BH = Set] AND NOT [(N_TIME_CRIT0, bit 1 = Set) AND
. (CX = MX)]}, then
. TC = Set
SP-50 User Layer Technical Report Counter

582
' The IF tests to see if triggered calibration is supported.

' The calculation is done here once to gain efficiency.
IF this logical node supports alert reporting, then
. Capture node time
' The node time should be captured at this point; this is the
' time that should be used for all alerts generated during this
' cycle of this block.
' *************************************************************
' *************************************************************
' ** **
' ** READ PUBLIC DATA BASE VALUES **
' ** **
' *************************************************************
' *************************************************************
'
Request User Layer Support Services to block public access to this tag's
. memory.
Unconditionally reset REQ_MODE bits IMan and ROut.
Unconditionally reset permitted mode bits IMan and ROut.
IF MM_SUPT = reset, then
. reset the Man mode bit in REQ_MODE
. reset the Man mode bit in the mode permitted byte.
IF REQ_MODE not permitted, then
. REQ_MODE byte = reset
IF [(no REQ_MODE bits are set) OR (two or more REQ_MODE bits are set)], then
. REQ_MODE byte = the mode of the lowest priority mode bit set in
. ACTUAL_MODE
. (no bits set if actual mode has no bits set).
IF no REQ_MODE bits are set, then
IF the O/S mode bit is set in REQ_MODE, then
' "No-path-to-Process", and "wound up".
' MSP variables are supported
. Set all bits in AUX_BAD.
. TRANSFER_VOID FOR THE CAS_TL = 2
. TRANSFER_VOID FOR THE RCAS_TL = 2
. FORCE_INIT = 3
ELSE
' if INPUT 2 is supported
. IF IN2_OVER = set, then
' if INPUT2 override is supported
. Signal Agent processing:
. If INPUT2's agent is of type "active", then
. do not use fetched value - act as a writeable agent.
. ELSE
. Cancel request to agent processing
'
' read user options
. T_OPTIONS0 = OPTIONS0 ' user option bit string #0
. T_OPTIONS1 = OPTIONS1 ' user option bit string #1
. IF OPTION_INT0 selected code is not supported, then
. Set the high bit of OPTION_INT0
. T_OPTION_INT0 = OPTION_INT0 ' user option integer #0
. IF OPTION_INT1 selected code is not supported, then
. Set the high bit of OPTION_INT1
. T_OPTION_INT1 = OPTION_INT1 ' user option integer #1
' read block variables
. T_REQ_MODE = REQ_MODE ' requested mode
. T_CAS_TL = CAS_TL ' Cas transfer location (and status)
. T_RCAS_TL = RCAS_TL ' RCas transfer location (and status)
. T_SETPOINT = SETPOINT ' the AO block SETPOINT

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
583
' read variables associated with the Setpoint Limits function:

. T_SP_LIM_LO = SP_LIM_LO ' low Setpoint limit
. T_SP_LIM_HI = SP_LIM_HI ' high Setpoint limit
. T_SP_DB = SP_DB ' Setpoint limit deadband
' if bypass is supported
. T_BYPASS_REQ = BYPASS_REQ ' the bypass request discrete
. T_BYPASS_LO = BYPASS_LO ' the low range of the bypass value
. T_BYPASS_HI = BYPASS_HI ' the high range of the bypass value
' read the variables associated with limiting
--```,``-`-`,,`,,`,`,,`---

' read block configuration that can be changed while mode <> O/S
. IF TIME_CRIT0, bit AH is set, then
' if the MSP variables exist
. T_I/O_AF0 = I/O_AF, index #0 ' the MSP servo/power static data
. T_I/O_AF1 = I/O_AF, index #1 ' miscellaneous MSP static data
. IF TC = set, then
' read the variables associated with triggered calibration
. T_LO_TARGET = LO_TARGET ' the low target cal. point
. T_HI_TARGET = HI_TARGET ' the high target cal. point
. T_TRIGGER = TRIGGER ' the trigger string
' Bit 0 - calibrate lower point, leave upper alone
' 1 - calibrate upper point, leave lower alone
' 2 - bias adjust based on the lower point
' 3 - bias adjust based on the upper point
'
' read the required variables associated with the PV function
. T_FREE_STATIC = FREE_STATIC ' free static variable
. T_FREE_DYN = FREE_DYN ' free dynamic variable
. T_TARGET_PARAM = TARGET_PARAM ' param. # of param. = target
. IF TIME_CRIT0, bit CH = set, then
' read the variables associated with the PV function that
' are present only if the function is supported.
. T_PV_PARAM = PV_PARAM ' param. # of param. = PV
. T_HIHI_ALARM = HIHI_ALARM ' hi-hi PV alarm point
. T_HI_RPT_ALARM = HI_RPT_ALARM ' high repeat alarm setting
. T_HI_ALARM = HI_ALARM ' high PV alarm point
. T_LO_ALARM = LO_ALARM ' low PV alarm setting
. T_LO_RPT_ALARM = LO_RPT_ALARM ' low repeat alarm setting
. T_LOLO_ALARM = LOLO_ALARM ' lo-lo PV alarm setting
. T_TARG_FILTER = TARG_FILTER ' target filter time constant
. T_DEV_ALARM = DEV_ALARM ' deviation alarm setting
. T_DEV_LOGICAL = DEV_LOGICAL ' deviation config. logical
. T_COMP_DB = COMP_DB ' comparator deadband
. IF TIME_CRIT0, bit DH is set, then
. IF OPTIONS0, bit CH = set, then
' force the servo "switches" to off if not permitted
. MSP_SERVO_SWITCH = all reset
. T_MSP_SERVO_SWITCH = MSP_SERVO_SWITCH
. Execute Run-time Agent Logic (see the paper "Agents").
. ENDIF
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@

584
' LV_x.
Request User Layer Support Services to permit public access to memory.
'
' LV_x.
'
' Certain main memory values are read-only to Field Bus (at least
' if the mode <> O/S) and did not have to be read in while
' memory access was blocked. They are:
' Manufacturer's Variables:
' TIME_CRIT0
' N_TIME_CRIT0
' N_TIME_CRIT1
' Variables associated with the PV function:
' * PV
' Variables associated with triggered calibration:
' * LO_CAL = the current low calibration point
' * HI_CAL = the current high calibration point
' Block data:
' * ACTUAL_MODE
' * SERVO_SP
' * OUTx_LO and OUTx_HI where x = 1-3
' MSP_READ_ONLY
' * MSP_DEVICE_STAT
' * MSP_SERVO_STAT
' * MSP_ALERT
' * MSP_DIAG_ALERT
' * AUX_ALERT
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
' * AUX_BAD
' * I/O_AF, indices 2 & 3
'
' The values with a "*" at the front will have new calculated
' values each cycle; their new values must be written during
' the mass write to maintain coherency. Note that there are 3
' mass writes - one during the initial read if the block
' changes to O/S mode (see page 3), one if there is a data
' problem (see next), and the other at the conclusion of the
' normal block calculations. They are mutually exclusive.
'
' There is one variable that is not related to any of the
' other variables in a time-coherency sense and can be read
' (by the MSP) as needed
' VAPOR_PRESS (an Auto-Format variable).
'
'
' *************************************************************
' *************************************************************
' ** **
' ** CLEANUP AFTER READING **
' ** **
' *************************************************************
' *************************************************************
'
. BREAK
IF FORCE_INIT = 3, then
. IF the agent type for INPUT0 is not supported, then
. BAD_CONFIG = set
. Unconditionally force the agent for INPUT1 to Null.
. IF [(TIME_CRIT0, bit 0 is set), then
. IF INPUT2 agent type not supported, then
. BAD_CONFIG = set
. IF the agent type for any supported OUTPUTx is not supported, then
. BAD_CONFIG = set

--```,``-`-`,,`,,`,`,,`---

585
. ELSEIF agent type for OUTPUT0 = Null, then

. FORCE_OS = set
. ELSEIF the pointer for OUTPUT0 > number of SO hardware points in the
. physical node, then
. BAD_CONFIG = set
. IF alert reporting is supported by this logical node, then
. Generate a "Bad Configuration" notification.
'Note: all alerts are held until the pseudocode indicates
' that alerts should be released to the Application
' Layer.
'Note: the use of the more detailed error codes is
' allowed and encouraged.
. IF [(BAD_CONFIG = set) OR (FORCE_OS = set)], then
. T_REQ_MODE byte = O/S
. ELSE
. Reset all agent count-out counters
. OLD_CLAMP1 = 0
. OLD_CLAMP2 = 0
. OLD_CLAMP3 = 0
. SUPPRESS = 1
. ENDIF
T_ACTUAL_MODE byte = T_REQ_MODE byte
'
. Pass any accumulated alerts to the User Layer Support Service.
. Request User Layer Support Services to block public access to this
. tag's memory.
. Update ALERT_SET0, ALERT_SET1, ALERT_UNACK0, and ALERT_UNACK1 as
. necessary.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
' "No-path-to-Process" and "Wound up".
. Set all bits in AUX_BAD.
. Request User Layer Support Services to permit public access to memory.
. TRANSFER_VOID for the CAS_TL = 2
. TRANSFER_VOID for the RCAS_TL = 2
. FORCE_INIT = 3
. BREAK
'
Execute the mode logic to set T_ACTUAL_MODE from T_REQ_MODE, the T_CAS_TL
. counter, the T_RCAS_TL counter, and LV_INPUT0's agent's counter. Refer
. to page 14 of the paper "Modes".
' See page 24 of the paper "Function Block Structure" for a
' description of the required processing of the block when
' FORCE_INIT >0.
'
' *************************************************************
' *************************************************************
' ** **
' ** CALCULATE NEW VALUES OF SETPOINT AND OUTPUT0 **
' ** **
' *************************************************************
' *************************************************************
'
Execute the Standard logic for calculating the new SETPOINT using the
' current, temporary values of REQ_Mode, SETPOINT, the RCas and Cas
' transfer locations, and INPUT0. This may not be the final version of
' T_SETPOINT if the block is being forced to initialize or is replaced.
IF the highest priority mode bit in T_ACTUAL_MODE = Auto, then
. IF the RCas OR Cas mode bit is also set in T_ACTUAL_MODE, then
--```,``-`-`,,`,,`,`,,`---

586
' this is the "fall back to Auto" case

. IF OPTIONS0, bit 2 = set, then
. REQ_MODE byte = Auto
' replacement setpoint on fall back is supported and
' permitted - first must do the limit checking, then
' use it.
. IF T_REPL_SP <> NaN, then
. IF T_REPL_SP < T_SP_LIM_LO, then
. T_REPT_SP = T_SP_LIM_LO
. IF T_REPL_SP > T_SP_LIM_HI, then
. T_REPT_SP = T_SP_LIM_HI
. T_SETPOINT value = T_REPL_SP
' Note that T_REPL_SP is NOT written to the
' data base at the end of this procedure.
. Reset bits 0 and 1 in SETPOINT status byte.
. Set bit 2 in SETPOINT status byte.
LV_OUTPUT0 = T_SETPOINT
IF OPTIONS0, bit 0 = set, then
. LV_OUTPUT0 = 100 - T_SETPOINT
T_FLAG = reset ' define a local flag - set if bypassed
. IF OPTIONS0, bit AH = reset, then
. IF T_BYPASS_REQ <> 0, then
' bypass is supported, permitted, and requested: do it
. T_FLAG = set
. IF MSP section has its Auto-bypass switch set, then
. IF OPTIONS0, bit BH = reset, then
' auto bypass is supported, permitted, and requested: do
' it
. T_FLAG = set
'
' *************************************************************
' *************************************************************
' ** **
' ** RUN THE MSP **
' ** **
' *************************************************************
' *************************************************************
'
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
MSP put into bypass operation if T_FLAG = set
IF [(block is in IMan mode) OR (FORCE_INIT = 3)], then
Hold MSP and force SETPOINT = INPUT1
Pass initialization up to the cascade transfer locations.
MSP_Setpoint = OUTPUT0
T_FLAG_FAIL = reset ' logic flag set if INPUT2 indicates a failure
T_FLAG_LO = reset ' logic flag set if INPUT2 indicates wound-up-low
T_FLAG_HI = reset ' logic flag set if INPUT2 indicates wound-up-high
IF TIME_CRIT0, bit 0 is set, then
. IF the agent for INPUT2 <> Null, then
. IF INPUT2, bit 1 = reset, then
. IF bit 4 of INPUT2 = set, then
. IF status of INPUT2, bit 4 = good, then
. T_FLAG_LO = set
. T_FLAG_HI = set
. T_FLAG_FAIL = set
. T_FLAG_LO = set
. T_FLAG_HI = set
WRITE_TRIG = reset ' logic flag to control writing of the TC trigger
WRITE_TC = reset ' logic flag to control writing of the TC data

--```,``-`-`,,`,,`,`,,`---

587
WRITE_ADJ = reset ' logic flag to control writing of the TC adjusts

IF TC = set, then
' This algorithm requires that:
' The values used in the triggered calibration function will
' always correspond to INPUT1.
'
' The MSP section may make the bias adjustment on its setpoint or
' on its response (or anywhere else it wants to) but with the
' requirement that the resulting INPUT1 and the AO block's SETPOINT
--```,``-`-`,,`,,`,`,,`---
' must be equal at equilibrium and under normal operation.

'
' This algorithm requires that:
' There be a correction "LO_ADJ" at INPUT1 = LO_CAL and
' "ADJ_HI" at INPUT1 = HI_CAL. The actual correction to a
' current value is obtained by linear interpolation or
' extrapolation based on the current position response.
'
' This algorithm also requires that:
' The actual values for the calibration points and the bias
' values be stored by the device in such a way that, when
' the direct/reverse action is changed, the calibration values
' retain their relationship to the MSP section and switch
' meaning in the view of the operator.
'
. T_LO_CAL = LO_CAL
. T_HI_CAL = HI_CAL
. IF T_TRIGGER has no bits set, then
. TC = reset
. ELSE ' one bit is set in T_TRIGGER
' Note: T_TRIGGER is not checked for more than 1 bit set
' because it can only be written indirectly - the
' DBWS can guard this parameter.
. WRITE_TRIG = set
. IF [(the actual mode <> Man) OR (FORCE_INIT > 0)], then
. TC = reset
. Generate a "Wrong mode for Triggered Calibration"
. notification.
. ELSE ' mode = Man
' Doing the low: must have sufficient span relative
' to the old high point.
. IF MSP reports that T_LO_TARGET is too close to T_HI_CAL,
. then
. BAD_CONFIG = set
. Generate an "Insufficient Triggered Calibration
. Range" notification.
' Doing the high: must have sufficient span relative
' to the old low point.
. IF MSP reports that T_HI_TARGET is too close to T_LO_CAL,
. then
. BAD_CONFIG = set
. Generate an "Insufficient Triggered Calibration
. Range" notification.
. IF [(MSP reports that triggered calibration can not be done
. because one or more signals needed to do the calculation
. have failed) OR (T_FLAG_FAIL = set)], then
. BAD_CONFIG = set
. Generate a "Bad Data - Can't Calibrate"
. notification.
. TC = reset

//^:^^#^~
588
' Doing calibration at the low calibration point.

. Request MSP to do triggered calibration, using the
. data base values read earlier. Must update
. T_LO_CAL and LO_ADJ. Note that the TARGET and
. CAL points are always in terms of INPUT1. The
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
. logic will have to apply direct/reverse

. adjustment if OPTIONS0, bit 0 is set.
' Apply the same change in bias to the
' high calibration bias.
. IF the MSP reports that the correction calculated is too
. large to be believeable, then
. then
. Generate an "Excessive Adjustment Triggered
. Calibration" notification.
. ELSEIF the MSP reports that the correction change
. calculated is too small to be meaningful, then
. node, then
. notification.
. ELSE ' OK - done.
. WRITE_TC = set
. ENDIF ' end of bits 0 or 2 section
' Doing calibration at the high calibation point.
. Request MSP to do triggered calibration, using the
. data base values read earlier. Must update
. T_HI_CAL and HI_ADJ. Note that the TARGET and
. CAL points are always in terms of INPUT1. The
. logic will have to apply direct/reverse
. adjustment if OPTIONS0, bit 0 is set.
' Apply the same change in bias to the low
--```,``-`-`,,`,,`,`,,`---
' calibration bias.

. IF the MSP reports that the correction calculated is too
. large to be believable, then
. Generate an "Excessive Adjustment Triggered
. Calibration" notification.
. ELSEIF the MSP reports that the correction change
. calculated is too small to be meaningful, then
. then
. notification.
. ELSE ' OK - done.
. WRITE_TC = set
. ENDIF ' end of bits 1 or 3 section.
. ENDIF ' end of triggered calibration adjustment.
. ENDIF 'end of Man mode section
. ENDIF ' end of "1 bit" section
. T_LO_TARG_ADJ = the adjustment at the current T_LO_TARGET value - the
. current T_LO_TARGET (in units of INPUT1) is used by the
. MSP to calculate the correction that would be applied,
. interpolating or extrapolating using T_LO_ADJ and
. T_LO_CAL with T_HI_ADJ and T_HI_CAL.
. Note that the AO block logic may have to apply
. direct/reverse logic to this if OPTIONS0, bit 0 is set.
. T_HI_TARG_ADJ = the corresponding value for the high calibration point.
. WRITE_ADJ = set
ELSEIF TIME_CRIT0, bit BH = set, then
' This is the CX = MX case. If TIME_CRIT0, bit BH is set, the
' adjustment can not be lost when CX is changed to equal MX but no
' new triggered calibrations will be serviced.

589
. IF [(FORCE_INIT = 3) OR (T_TRIGGER has any bits set)], then

. LO_TARGET = 0
. HI_TARGET = 0
' Note: these two parameter writes are allowed to violate
' the time coherent, blocked writes requirement.
. T_LO_TARG_ADJ = 0
. T_HI_TARG_ADJ = 0
. WRITE_ADJ = set
. WRITE_TRIG = set
. WRITE_TC = set
ENDIF
IF TC = SET, then
' Note: this selects the condition of:
' - triggered calibrations supported, AND
' - triggered calibration commanded, AND
' - mode = Man, AND
' - some work done by the MSP although not necessarily
' successfully.
. Command MSP to actively "hold" the current output for this cycle.
IF TC = reset, then
. IF mode = Man, then
. IF TIME_CRIT0, bit DH = set, then
. Run the MSP under the command of the switch register.
. ELSE
. Command the MSP to actively "hold" the current output.
. ELSE
. Run the MSP in the normal fashion
' Note: the MSP must be triggered and begin to slew the
' hardware output by the time specified in the paper
' "Data Owner Structure - Hardware, page 10.
' *************************************************************
' *************************************************************
' ** **
' ** PROCESS THE VALUES RETURNED BY THE MSP **
' ** **
' *************************************************************
' *************************************************************
'
Apply the direct/reverse logic as needed if OPTIONS0, bit 0 is set.
T_STAT = 00100000B
T_VALUE = the value of LV_INPUT1
' Note: If triggered calibration is supported, this value includes the
' calibration correction.
IF hardware does not supply the major value in 4 byte floating point and
. % range form, then
. Convert the response measurement to the correct basis.
IF OPTIONS0, bit 0 is set, then
. The response measurement = 100 - the response measurement
IF [(the MSP indicates that the output hardware has failed) OR (T_FLAG_FAIL
. = set)], then
. T_FLAG_FAIL = reset
. Set bits 4 (Fail), 5 (Not-from-the-process), and 6&7 (wound up) in the
. status of LV_OUTPUT0
. IF bit 8 in FAIL_OPT0 = set, then
. IF OPTIONS1, bits 1 & 0 <> 00B, then
. Set OUTPUT0 failure alarm
. Prepare the failure alert.
. SUPPRESS = 2
. IF bit 9 in FAIL_OPT0 = reset, then
. Set bit 4 in the status byte of SETPOINT
. Execute the failure handshake procedure for the Cas and RCas
. transfer locations (see Attachment 1 to the paper "Status
. Bytes").
ELSE

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
590
. Clear any existing "OUTPUT0 hardware failure" alarms.

IF [(The MSP indicates that the response measurement has failed, then
. Set bits 1 (Bad), 2 (Not-from-Process), 4 (Failed), and 6 & 7
. (wound up) in T_STAT
' Use the last good value.
. IF OPTIONS1, bits 3&2 <> 00B, then
. Set INPUT1 failure alarm
. Prepare the failure alert.
. SUPPRESS = 2
. Reset bit 4 in the status byte of INPUT1
' Note: if the device can not function without the response
' measurement, then OUTPUT0 should be marked as failed,
' executing all of the steps given above but at this
' point in the logic (to get alert suppression in the
' correct priority).
ELSE
. Clear any existing "INPUT1 hardware failure" alarms.
. T_VALUE = the response measurement from the MSP section.
. IF T_VALUE is at its HI limit, then
. IF T_VALUE is at its LO limit, then
LV_INPUT1 = T_VALUE + T_STAT
'
IF the MSP section reports that the block is in OVERRIDE, then
. Set the IMan mode bit in T_ACTUAL_MODE
. T_FLAG_LO = set
. T_FLAG_HI = set
. value of T_SETPOINT = value of LV_INPUT1
. LV_OUTPUT0 = direct/reverse action applied to T_SETPOINT
. Set bits 6&7 in the status of T_OUTPUT0 and pass the doubly wound up
. status to RCas and Cas transfer locations.
IF the MSP section reports that the block is in Keylock, then
. Set the LO mode bit in T_ACTUAL_MODE
. T_FLAG_LO = set
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
. T_FLAG_HI = set
. Set bit 3 in the status byte of LV_OUTPUT0
. Set bit 3 in the status byte of T_SETPOINT
. Set bits 6&7 in the status of T_OUTPUT0 and pass the LO mode and the
. doubly wound up status to the RCas and Cas transfer locations.
IF the MSP section reports that FAILSAFE was invoked, then
. T_FLAG_FAIL = set
. T_FLAG_LO = set
. T_FLAG_HI = set
. Set bits 6&7 in the status of T_OUTPUT0 and pass the doubly wound up
. status to RCas and Cas transfer locations.
'
IF alerts are supported by this logical node, then
. FOR bits AH - FH of MSP_ALERT
. IF bit indicates an alert condition, then
. set alarm bit
. issue failure alert
. SUPPRESS = 1
' These alerts match dedicated alerts - they can be
' turned off using the normal alert priorities.
. ELSE
. IF alarm existing, then
. clear alarm and issue "return" alert.

--```,``-`-`,,`,,`,`,,`---

591
. NEXT bit
. FOR bits 2-7 of MSP_ALERT
. IF bit indicates an alert condition, then
' Note: some field devices may choose to set one or both
' of the wound-up bits in OUTPUT0 and/or in INPUT1
' when one or more of these alerts occur. These
' bits should them be promulgated through the
' AO block. The originating alert condition is
' the one that should have the highest priority
' relative to SUPPRESS.
. set alarm bit
. issue failure alert
. SUPPRESS = 1
' These alerts are reported if the bit pairs in
' OPTIONS1 are <> 00B.
. ELSE
. IF alarm existing, then
. clear alarm and issue "return" alert.
. NEXT bit
Set T_FLAG_LO AND T_FLAG_HI for alerts set in bits 2-7 of MSP_ALERT for
. which the bit pairs in OPTIONS1 are 10B.
Set T_FLAG_FAIL, T_FLAG_LO, and T_FLAG_HI for alerts set in bits 2-7 of
. MSP_ALERT for which the bit pairs in OPTIONS1 are 11B.
'
IF T_FLAG_FAIL = set, then
. IF OPTIONS0, bit DH = set, then
. IF any T_ACTUAL_MODE bits are set that are lower in priority then
. Auto, then
. IF Auto mode is permitted, then
. Set the Auto mode bit in T_ACTUAL_MODE
. Reset the Cas and RCas mode bits in T_ACTUAL_MODE
. ELSEIF Man mode is permitted, then
. Set the Man mode bit in T_ACTUAL_MODE
. Reset the Cas and RCas mode bits in T_ACTUAL_MODE
. ENDIF
. IF this node supports alerts, then
. IF the mode was actually changed, then
. issue the appropriate alert (notification).
. SUPPRESS = 1
. Set Bits 4 (Fail) and 5 (No-path-to-Process) in the status of LV_OUTPUT0
. IF bit 4 in the status of LV_SETPOINT = reset, then
. set bit 4 in the status of LV_SETPOINT
. Execute the failure handshake procedure for the Cas and RCas
. transfer locations (see Attachment 1 to the paper "Status
. Bytes").
. IF this logical node supports alerts, then
. Generate a "Return" for any other alerts that have cleared.
ELSE
. IF this logical node supports alerts, then
. Clear any alarms that have returned to the normal state.
. IF [(T_SETPOINT, bit 4 = set) AND (T_SETPOINT, bit 5 = set), then
. Reset bits 4 (Fail) and 5 (No-path-to-Process) in the status of
. T_SETPOINT
' Note: the handshake arrived back from the block
' responsible for acknowledging it.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
ENDIF
IF there are any alerts in the following registers passed from the MSP
. section, the logic will generate the appropriate alert messages at this
. point (IF SUPPRESS < 1) but not pass them to the User Layer Support
. Services until so instructed:
. MSP_DIAG_ALERT
--```,``-`-`,,`,,`,`,,`---
. AUX_ALERT
. AUX_BAD
. In addition, it will "return" previously existing alerts if they have
. cleared.

592
Reset Bits 6 and 7 (the Wind-up bits) in the status of T_SETPOINT

IF MSP reports that the servo is wound up low, then
. T_FLAG_LO = set
IF MSP reports that the servo is wound up high, then
. T_FLAG_HI = set
IF T_FLAG_LO = set, then
. Set bit 6 (Wound-up LO) in the status bytes of LV_OUTPUT0 and
. T_SETPOINT.
ELSE
. Reset bit 6 (Wound-up LO) in the status bytes of LV_OUTPUT0 and
. T_SETPOINT.
IF T_FLAG_HI = set, then
. Set bit 7 (Wound-up HI) in the status bytes of LV_OUTPUT0 and
. T_SETPOINT.
ELSE
. Reset bit 7 (Wound-up HI) in the status bytes of LV_OUTPUT0 and
. T_SETPOINT.
Pass the status information for LV_SETPOINT back to the Cas and RCas
. transfer locations according to the standard cascade structure rules.
'
' *************************************************************
' *************************************************************
' ** **
' ** CALCULATE PV POINTER VALUES **
' ** **
' *************************************************************
' *************************************************************
'
IF TIME_CRIT0, bit CH = set, then
' device supports the PV Pointer
. Execute the PV Pointer pseudocode
' see the pseudocode attachment to the paper "Standard Block
' Functions".
'
' Suppress the reporting (but not the setting of) of the PV alarms
' if SUPPRESS > 0.
ELSE
. Move value pointed to by TARGET_PARAM into TARGET.
. IF the value has a status byte, then
. Use it.
. ELSE use a default status byte of 00100100B
. IF TARGET value = NaN,, then
. TARGET status = Bad.
. T_STAT = status of LV_INPUT1
. T_STAT = T_STAT AND 00000111B
'Reset all PV status bits except No-Com, Bad, and Not-from-Process
'Set HiHi and LoLo alarm bits simultaneously as a flag.
. T_PV = value of LV_INPUT1 + T_STAT
'
' *************************************************************
' *************************************************************
' ** **
' ** CALCULATE OUTPUTs 1-3 **
' ** **
' *************************************************************
' *************************************************************
'
Access hardware to get new values.
'
' The following procedure is detailed for OUTPUT1. The totally
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
' analogous procedure is to be followed for OUTPUT2 and OUTPUT3.

' The procedures are to be executed in the order:
' 1) OUTPUT3
' 2) OUTPUT2
' 3) OUTPUT1

--```,``-`-`,,`,,`,`,,`---

593
' so that alert suppression will be in the rank order specified in the
' algorithm definition.
'
' bit 5 = set means OUTPUT1 is supported
' if the process fluid temperature is an auxiliary value, then it
' must be here.
. T_STAT = 00100000B.
' Always set "No-path-to-process" in aux. Outputs
. T_VALUE = value of auxiliary value 1 from the hardware.
. IF the hardware indicates that the measurement has "Failed", then
' The manufacturer may base "Fail" on indications from the
' hardware itself and/or on reasonableness checks of the
' measurement from the hardware.
'
' For a standard AO block, the hardware alert reporting will
' be consolidated with the function block alert reporting
' if the hardware failure is discovered as part of the
' operation triggered by the block schedule (possibly reported
' by the MSP one cycle later).
. T_VALUE = value part of LV_OUTPUT1
' set "Bad", "Not-from-Process", "Fail", and "Wound-up" bits
. ELSEIF the hardware indicates that the measurement is "Bad", then
' There may be reason to consider the measurement "Bad" BUT
' NOT "Failed".
. T_VALUE = value part of OUTPUT1
. ELSEIF the mode just changed from O/S and early triggering was used,
. there may be no hardware value ready; then
. T_VALUE = value of OUTPUT1
. ENDIF
. ELSE
. IF the hardware indicates that the value is at its extreme high
. limit, then
. IF the hardware indicates that the value is at its extreme low
. limit, then
. IF the hardware does not supply auxiliary value 1 in 4 byte
. floating point and ESI form, then
. IF FAIL_OPT0, bit AH = set, then '"Fail" alerts reported
. IF SUPPRESS < 2, then 'No "Fail" alarms yet.
. SUPPRESS = 1
. IF a failure in this auxiliary will inevitably lead
. to failures in the other auxiliary values, then
. SUPPRESS = 2
. IF T_LIM1_LO = NaN, then
. OLD_CLAMP1 = 0
. ELSE
. IF T_VALUE <= T_LIM1_LO, then
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
. T_VALUE = T_LIM1_LO

--```,``-`-`,,`,,`,`,,`---

594

. prepare the "OUTPUT1 Lo Limit" alert.
. SUPPRESS = 1
. OLD_CLAMP1 = 1
. IF [(LIM1_DB <> NaN) AND (T_VALUE < (T_LIM1_LO +
. LIM1_DB))], then
. ELSE
. OLD_CLAMP1 = 0
. ENDIF
. IF T_LIM1_HI = NaN, then
. OLD_CLAMP1 = 0
. ELSE
. IF T_VALUE >= T_LIM1_HI, then
. T_VALUE = T_LIM1_HI
. prepare the "OUTPUT1 Hi Limit" alert.
. SUPPRESS = 1
. OLD_CLAMP1 = 2
. ELSEIF [(LIM1_DB <> NaN) AND (T_VALUE > (T_LIM1_HI -
. LIM1_DB))], then
. ELSE
. OLD_CLAMP1 = 0
. ENDIF
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
--```,``-`-`,,`,,`,`,,`---

. SUPPRESS = 1
. IF FAIL_OPT0, bit BH = set, then
. T_STAT, bit 4 = reset
. IF the OUTPUT1 agent type = active, then
. IF OUTPUT1 agent type <> Null, then
. LV_OUTPUT1 = T_VALUE + T_STAT
'
' This is the end of the procedure for OUTPUT1.
'
FOR OUTPUT's 1 - 4
IF the output is supported, then
IF the output's agent is active, then
IF [(FORCE_INIT = 3) AND (OUTPUT = Bad)], then
Instruct the agent to not store the output
ENDLOOP

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
595

--```,``-`-`,,`,,`,`,,`---
. Any active output agents will delay scheduling the store of their
. output into the remote location.
. Decrement FORCE_INIT
. ELSEIF FORCE_INIT = 2, then
. IF there are NO No-Com counters that have counts but have not
. counted out, then
. FORCE_INIT = 1
. ELSE 'FORCE_INIT = 1
. IF NOT [(INPUT0 has an active agent) AND (OPTIONS0, bit 2 = set)
. AND (INPUT0 = "Bad")], then
. FORCE_INIT = 0
. ENDIF
'
' *************************************************************
' *************************************************************
' ** **
' ** WAIT FOR THE END OF BLOCK TIME **
' ** **
' *************************************************************
' *************************************************************
'
All spare block time must be placed here.
'
' *************************************************************
' *************************************************************
' ** **
' ** WRITE TO DATA BASE WHILE PROTECTED **
' ** **
' *************************************************************
' *************************************************************
'
Send any accumulated alerts to the User Layer Support Services
Request User Layer Support Services to block access to memory.
' write block variables
REQ_MODE = T_REQ_MODE
ACTUAL_MODE = T_ACTUAL_MODE
SETPOINT = T_SETPOINT
SERVO_SP = T_SERVO_SP
PV = T_PV
Update CAS_TL and RCAS_TL
' Note: if the effective mode = Cas, then the CAS_TL value and the
' first three bits of the status byte must not be overwritten.
' Likewise for the RCas location.
Update ALERT_SET0, ALERT_SET1, ALERT_UNACK0, and ALERT_UNACK1 as necessary.
Request Agent servicing of all supported agent values
MSP_DEVICE_STAT = T_MSP_DEVICE_STAT
MSP_SERVO_STAT = T_MSP_SERVO_STAT
MSP_ALERT = T_MSP_ALERT
. Set bit 5 (Not-from-Process) in LV_INPUT2's status
. Reset bits 3, 4, 6 & 7 in LV_INPUT2's status
IF TIME_CRIT0, bit 2 = set), then
. BYPASS_REQ = T_BYPASS_REQ
IF [(TIME_CRIT0, bit 5 = set), then
. OUT1_LO = T_OUT1_LO
. OUT1_HI = T_OUT1_HI
IF TIME_CRIT0, bit AH = set, then
. MSP_DIAG_ALERT = T_MSP_DIAG_ALERT
. AUX_ALERT = T_AUX_ALERT

596
. AUX_BAD = T_AUX_BAD
. I/O_AF, index 2 = T_I/O_AF, index 2
. I/O_AF, index 3 = T_I/O_AF, index 3
IF TIME_CRIT0, bit DH = set, then
. MSP_SERVO_SWITCH = T_MSP_SERVO_SWITCH AND MSP_SERVO_SWITCH_MASK
IF WRITE_ADJ = set, then
' just write the calculated calibration points - normal case
. ADJ_LO_TARG = T_ADJ_LO_TARG
. ADJ_HI_TARG = T_ADJ_HI_TARG
IF WRITE_TRIG = set, then
' just write the new trigger value
. TRIGGER = T_TRIGGER
IF WRITE_TC = set, then
' write the variables associated with a new triggered calibration
. LO_CAL = T_LO_CAL
. HI_CAL = T_HI_CAL
'
' write the variables associated with the PV function
PV = T_PV
TARGET = T_TARGET
Request User Layer Support Services to again allow public access to memory.
'
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
597
Counter
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Editor's Note: This function block description has been accepted by the
User Layer Subcommittee as a technical report paper but it has not yet been
edited. All of the functionality of the block has been defined but the details
of the parameter definitions and the pseudocode are yet to be done.
An addition to the algorithm definition came up after this paper was accepted -
we need to add two time accumulators: one to accumulate the time spent at the
maximum rate of the counter and one to accumulate the time spent at the minimum
rate of the counter.

UNIQUE BLOCK FEATURES
BIT POINTERS
EXPLANATION OF SNAPSHOT REGISTERS
BAD VALUE HANDLING IN ADDITION TO ALARM
DETAILS OF UNIQUE BLOCK FEATURES
Figure 1 - Counter Block
Figure 2 - Counter Data Flow
BASIC ALGORITHM:
- This algorithm can accumulate the counts from counter hardware or it
can count the leading edge transitions in a discrete value. It
features a 32 bit integer accumulator for the counts. It includes a
trip and pre-trip capability where the source of the trip count can be
controlled by the mode of the block. It calculates the filtered
instantaneous rate of the counter and it separately accumulates the
"last good value" of all readings that were marked "bad".
- See the attached figure "Counter Block".
- Two modes of operation (see "Counter Data Flow" drawing):
+ Counter Hardware Input (Type CT)(must be on physical node):
@ Counts always positive.
@ If the count value = NOT "Bad", Counted in a 32 bit integer
counter (Total); the counter simply rolls over if not
reset.
@ If the count value = "Bad", marked good and Counted in a
separate 32 bit integer counter (BTotal); the counter
simply rolls over if not reset.
@ Rate = rate based on filtered, converted count, with status
of original input value.
+ Discrete transitions:
@ Leading edge triggered; counted the same as above.
- For count up, Target Value = SP (continuously variable).
--```,``-`-`,,`,,`,`,,`---
- For count down, Preset = SP (only used at instant of reset).

- BTotal is always count up.
- The number of cycles with a bad counter or discrete input and a mode
of priority lower than Man are counted and the time of the first
event is stored.
- Pre-trip Output set if Total >= (SP - Pretrip_Value) for count up

598
(<= Pretrip_Value for count down).

- Trip Output set if Total >= (SP - Dribble) for count up (<= Dribble
for count down).
- Discrete data flow configured using "Bit pointers" that can connect
to bits in Input Word 2, 2 Output words, or 5 logical node registers:
16 bits each.
- "Reset" resets Total to zero for count up (Total to SP if count down)
and it resets BTotal to zero.
- No mode change causes reset.
- O/S, LO, and Man modes hold Total and BTotal despite continuing
inputs. Raw count register (in the hardware) continues to be reset
every block cycle so counts are totally lost.
- The rate will be calculated and stored in Output 0 in all modes
except O/S.
- Any time mode changes from one of Auto, Cas, or RCas to a mode of
higher priority than Auto AND Rate is > MRate (the rate below which
increments are not added to Total), an event notification will be
generated.
ALGORITHM OPTIONS:
- Accumulate = sense of accumulation into Total
= 0 if counts or positive analog value are to be
subtracted from Total (traditional counting "down")
= 1 if counts or positive analog value are to be added to
Total (traditional counting "up") (default = 1)
- Auto-Reset = set to automatically reset the counter when the target
--```,``-`-`,,`,,`,`,,`---
value (for counting up, 0 for counting down) is
reached.

- Modes: all ex. IMan, ROut - By-Pass: no
- Hardware Pointers: yes, none - Set Point Limits: yes
or 1: Input 1. - "PV Pointer": yes, default
- Bit Pointers: yes, 6 to Rate (analog)
- Cascade Structure: yes, but will - Output Limits: no
not support initialization - Boolean Operators: no
MODES:
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
- In Manual, counting of input stops but the hardware counter is reset

each block cycle. Outputs can be set. If the only mode bit set is
manual, then the Force Manual input value is reset and marked "good".
- In LO mode, the block will act as if it is in Man but the Output can
not be manipulated and LO will be set in targeted bits.
- LO state fed back by Bit 3 of the status bytes of any Output
discretes pointed to will cause an alarm but not IMan(LO(x)) mode.
The algorithm will not write the state of any Output discrete whose
status Bit 3 is set.
- A leading edge on the Force Manual input causes Man(x) compound mode.
When the Force Manual input has a falling edge, the Manual mode bit
will be reset only if another, lower priority, mode bit is set. A
continuous set or reset condition of the Force Manual input has no
effect on mode. On transition out of O/S mode, if the Force Manual
input is found set on the first execution, it will be considered to
be a leading edge.
- In Auto, outputs set by algorithm; target (preset) set by operator.
- In CAS, Input 0 pointer or Cas transfer location used for target
(preset).
- In RCAS, transfer location used for target (preset).

599

- Source of input is determined by the pointer for Input 1 and the bit
pointer for the "discrete to count". If one and only one of these
two pointers is not null, that is the source of the input.
Otherwise, a bad configuration notification will be sent and the mode
of the block will be set to O/S.
- Reset is leading edge driven and can be set by a Field Bus command
and a pointer in parallel.
- There will be a 16 bit counter that counts the number of resets - it
itself is never reset and not writeable.
- If "Auto-Reset" is set, the block will automatically reset when the
Total value reaches the SP (counting up, zero if counting down); it
will handle the "carry" of the totalizer correctly and automatically.
- The calculation of the rate includes the cycle time of the logical
node. A manufacturer may offer a more accurate method of
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
calculation that bases the calculation on the actual elapsed time
from one counter sampling to the next. The presence of the actual
time feature is indicated in the physical node data base.
- Record of bad value for the configured counter input:
+ Last good value of count (the value that is marked "Bad") is
set good and added to BTotal.
+ A 16 bit counter is incremented every cycle that finds a bad
value for the active Input if the mode is lower priority
than Man. The counter is not writeable from Field Bus.
+ A single time stamp register is provided. If the register is
zero when a bad value is found, the current system time is saved
into the time stamp register. The field device provides no
mechanism to re-zero the register but it is writeable.
BIT POINTERS:
Bit pointers are used for configuring the inputs to the "Force Manual",
"Reset", and "Discrete-to-count" functions and the connections from the Output to
Output words 1 & 2 or to the special logical
node registers.
The Force Manual, Reset, and Discrete-to-count functions are configured using
three copies of the bit pointer word. They are combined under one parameter
name; the word for the Force Manual input is reported first, then Reset.
The Output word bits are configured using three more copies of the bit
pointer word. Their configurations are also combined under one parameter name:
the word for Bit 0 is reported first.
EXPLANATION OF SNAPSHOT REGISTERS:

This block is equipped to provide either manual or automatic resetting of its
accumulated total. In order to accurately capture and make the data at the time
of resetting available to a higher level device, three special parameters are
provided. These are called the "snapshot" registers and their names are
generated by adding the prefix "S" to the name of the working value with which
they are associated. One of them is quite simple: the current value of BTotal
is transferred to SBTotal at every reset.
The other two parameters (STotal and SSP) are set equal to the current Total
and Setpoint (Total and SP) immediately prior to the reset. The exact
interpretation of these two values depends on whether the resetting is done
automatically or manually and whether the counter is counting up or down. The
following will consider these 4 cases.
Case 0: automatic reset, counting up:

Automatic resetting takes place whenever the Total is greater than
the SP of the block. However, the SP is dynamic. Thus, a higher-level
device needs to know the exact value of SP when the automatic reset

--```,``-`-`,,`,,`,`,,`---

600
occurred. This value is stored in the "snapshot" register SSP. This

register will retain the value until at least the next resetting of the
block. The exact value of the Total (presumably slightly larger than
SP) is not needed because the "carry" is included in the next Total.
Case #1: automatic reset, counting down:

Automatic resetting takes place whenever the Total is less than or
equal to zero. At that time, the current block SP will be added into
the Total register. A higher-level device needs to know the exact
value of SP. This instantaneous value is stored in SSP. This register
will retain the value until at least the next resetting of the block.
The exact value of the Total (presumably slightly negative) is not
needed because the "carry" is included in the next total.
Case #2: manual reset, counting up:

A manual reset will cause Total to be reset: there is no "carry".
Therefore, the value of Total must be captured for the higher-level
device but there has been no effect of a "target value". The value of
Total is moved into STotal. The STotal register will retain the value
until at least the next resetting of the block.
Case #3: manual reset, counting down:

A manual reset will cause Total to be set equal to SP: there is
no "carry". Therefore, the value of Total before the resetting must be
captured for the higher-level device; the value of Total is moved into
STotal. This register will retain the value until at least the next
resetting of the block. A higher-level device needs to know the exact
value of SP from which the count is decrementing. This instantaneous
value is stored in SSP. The "interrupted" Total was counting down from
some preset value; if that value was not already captured by the
higher-level device, it will be lost.
The Counter block will reject reset requests for 8 cycles after a reset. One
reason for this is to guarantee that the snapshot values are exposed to the Field
Bus for at least 8 cycles before they can be overwritten. Since a reset is an
event that is reported in the alert buffer, a higher-level device can respond to
the event and capture the snapshot values.
- Node Parameters:
+ Block calculation cycle time (seconds) = F
- User Set Parameters (all under the tuning attribute):
+ Conversion factors:
TC = Time Conversion (for example, {1/60} if rate is
counts per minute instead of counts per second)
(default = 1).
UC = Units Conversion (for example, {1/1000} to convert to
thousands of counts (default = 1).
+ Pretrip_Value (delta below target for count up, absolute
--```,``-`-`,,`,,`,`,,`---
for count down; always an integer) (default = 0).

+ Dribble_Value (delta below target for count up, absolute
for count down; always an integer) (default = 0).
+ MRate = Minimum filtered rate below which no count (in same
units as Rate) (default = negative infinity).
+ RRate = Minimum filtered rate below which Output 0 will be
set to 0 (in same units as Rate) (default = negative infinity).
+ DRate = Deadband for MRate and RRate (default = 0).
+ Td = first order filter time constant for the rate value
(minutes) (default = 0).
- External Parameters:
+ SP = Setpoint of the block
= SP(n)
+ SSP = snapshot value of SP(n) at time of reset
+ Input 0 = used as "Set Point" in algorithm in Cas mode
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":
= INPUT0(n)

601
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
+ Input 1 = Hardware Count value (incremental counts)
= INPUT1(n)
+ Input 2 = Discrete; addressed as IW2-0 through IW2-F
+ Output 0 = Rate = Filtered Raw Rate
= OUTPUT0(n)
Raw rate = Delta_Count * TC * UC / cycle time
Delta_Count = change in counts this cycle
+ Total = Accumulated total since last reset (if counting up;
{preset - accumulated total} if counting down) including
the carry from the last reset if the last reset was
automatic.
+ STotal = snapshot value of Total at the time of the last reset.
+ BTotal = Accumulation of the last good values during cycles in
which the count was marked bad.
+ SBTotal = snapshot value of BTotal at the time of the last reset
+ Bad_Input_Counter: counts cycles in which:
Input Value (i.e., Input 1 or the bit pointed to by the
"discrete to count" bit pointer) = Bad
AND
Mode lower priority than Man.
+ Reset_Counter = 16 bit counter
= incremented for every block reset
= can not be reset itself
+ Time_stamp = system time at first instance of an increment of
the Bad_Input_Counter after the Time_stamp location
was set to zero or the block reset.
- Internal Parameters (not accessible on Field Bus):
+ FRate = filtered Rate before RRate cut-off limit.
BAD VALUE HANDLING IN ADDITION TO ALARM:

- All standard NaN and status bit responses and setting except:
+ If Input 0 = NaN, the counter will continue to count if the mode
is lower priority than Man. The Trip and Pre-trip Outputs will
be set immediately.
+ If Input 0 = Bad, use the last good value.
+ IF the block is in Cas or RCas mode
AND IF counting up
AND IF the Total value is greater than (Current SP -
Dribble_Value)
AND IF the Total value is less than (the old SP -
Dribble_Value)
AND the Trip Output is not set
THEN Set "SPjump" Alarm and set the Trip and Pretrip
Outputs.
ELSEIF the Total value is greater than (Current SP -
Prealarm_Value)
Prealarm_Value)
AND the Pre-trip Output is not set
THEN Alarm and set the Pre-trip Output.
- Bad Input 1 while in a mode of lower priority than Man: hold
the Count and increment the Bad_Input_Counter every cycle. If
Time_Stamp is zero, load it with the system time. Change the
value to good and add it to BTotal.
If the input returns to good, restart counting but leave the

accumulated count in the Bad_Input_Counter and the accumulated
count in BTotal.
- Bad Reset, bad Force Manual, or bad Prefetched Output Word: use the
last good value of Force Manual; ignore the rest.

--```,``-`-`,,`,,`,`,,`---

602
DETAILS OF UNIQUE BLOCK FEATURES:

- Resetting is done after the new count is added to the registers.
- The Reset Pointer handling will include two unique provisions:
+ the pointer will only be sensitive to the leading edge of the
pointer value, not the state or the falling edge. Specifically,
the pointer will maintain a copy of the previous pointer value
in Field Bus inaccessible memory. Only when the old value is
reset and the new value is set will "Reset" be set.
+ the pointer will OR the "Reset" value from the immediately
previous statement with its own data base value. This will
allow an operator to command a Reset in parallel with an active
Reset pointer. For 8 cycles after resetting, the block will
ignore any command to reset. It will reset its data base value
and set its inaccessible copy on the eighth cycle.
- SSP = a "snapshot" register to save the SP in effect at the time of
reset.
- STotal = a "snapshot" register to save the value of Total current at
the time of reset.
- SBTotal = a "snapshot" register to save the value of BTotal current
at the time of reset.
- If Reset is Off AND Auto-Reset is set, THEN
+ IF the count up option is set AND IF Total >= SP THEN
SSP = SP(n)
STotal = Total
SBTotal = BTotal
@ Total = Total - SP
@ Increment Reset counter
@ Event put into node alert buffer
+ IF the count down option is set AND IF Total <= 0 THEN
SSP = SP(n)
STotal = Total
--```,``-`-`,,`,,`,`,,`---
SBTotal = BTotal
@ Total = Total + SP
@ Event put into node alert buffer.
- If Reset is "On" THEN
+ IF the count up option is selected, THEN
SSP = SP(n)
STotal = Total
SBTotal = BTotal
@ Total = 0
@ Increment Reset counter.
+ IF the count down option is selected, THEN
SSP = SP(n)
STotal = Total
SBTotal = BTotal
@ Total = SP
- The pre-trip discrete will be checked every cycle it is set and reset:
+ AFTER the Totalizer has been reset AND IF
+ If Total >= 0.5 * (SP - Pretrip_Value) for count up
If Total <= 0.5 * (STotal- Pretrip_Value) for count down
- The trip discrete will be reset:
+ AFTER the totalizer has been reset AND IF
+ If Total >= 0.5 * (SP - Dribble) for count up
If Total <= 0.5 * (STotal- Dribble) for count down

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
603
COUNTER BLOCK
Cas RCas
Mode
Output 0
Input 0
Output
Input Pointer Word 0
Word 0 Select
Analog
Analog Set Point (Rate)
(Set Point)
Hardware
Output
Counter
Input 1
Word 1
Output 1
Force Total E
(32 bit) F
--```,``-`-`,,`,,`,`,,`---
Manual
(Discrete) DW1-0
BTotal Thru
(32 bit) DW1-F
Input
Word 2 1
0
Input 2
F Algorithm Trip
Output 2
E (Discrete) E
IW2-0 Discrete F
Thru To Count DW2-0
IW2-f 0 Thru
Pretrip
1 Reset 1 DW2-F
(Discrete)
0 (Discrete) 1
2
0
Counting
(Discrete)
Figure 44: Counter Figure 1, Counter Block

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
604
COUNTER DATA FLOW

32 Bit Floating Registers
INPUTS 32 Bit Integer
Pt. Register
Raw Delta Rate Total BTotal

Counter
Filter
--```,``-`-`,,`,,`,`,,`---
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
OR Add Add
* Units
Conversion
Discrete Leading No
Edge
Bad Yes
Mark
* Time Value? Good
Conv.
* Cycle Yes
Time
LO Delta
Ct. No
Man. =
Up?
-Delta
Auto.
Cas. RCas
Figure 45: Counter, Figure 2, Counter Data Flow

605
Dynamic Compensation
Editor's Note: his function block description has been accepted by the
BASIC ALGORITHM:
- Dynamic compensation algorithm with two inputs, one Cascade output
+ One of two algorithms operates on Input #1: lead/lag or dead
time.
+ Compensated and limited Input #1 available as Output #1.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
+ Output #1 combined with Input 0 using one of two

options, multiplication or addition, to form Output 0.
+ Full CASCADE support through Input 0 and Output 0.
ALGORITHM OPTIONS:
- Lead/Lag option:
Compensated Input #1 = Input #1 after first order lead, lag, gain,
and bias.
- Dead-time option:
Compensated Input #1 = Input #1 with pure dead time, gain, and
bias.
- Multiply or add Output #1 to Input 0 to form Output 0.
- Absorb Input #1 bump in gain, bias, dynamic time, or Cascade.
STANDARD ANALOG BLOCK FEATURES:

- Cascade Structure: yes - By-pass: yes, Input 0 to Output 0
- Modes: all except LO - Output Target: yes (2)
- Set Point Limits: yes - Output Limits: yes (2)
- "PV Pointer": yes, default - Pointers to Hardware: no
to Output #1.

- When the use of Input #1 must be activated while the block is
controlling, an option is provided to use a back-calculated balancing
value that is then decayed out over time.
- Node Parameters:
+ F = Block calculation cycle time (seconds).
+ BIAS = Bias in both lead/lag and dead time algorithms.
+ GOOD = 1 bit discrete.

--```,``-`-`,,`,,`,`,,`---

606
= set if the last good value of Output #1 is to be used

when the new value of the compensated Input #1 is NaN or
"Bad".
+ K = Gain in both lead/lag and dead time algorithms.
+ TOL = minimum absolute value of Input #1 to use in
initialization with the multiply option (alarm when hit).
Note: TOL < 1.
+ T(1) = Time constant of first order lead in the lead/lag
algorithm (minutes).
= Dead time in the dead time algorithm (minutes).
Note: In the dead time algorithm: T(1) >= (F/60)
+ T(2) = Time constant of the lag term in the lead/lag
= Total time covered by the stack in the dead time
Note: In the dead time algorithm, T(1) <= T(2)
+ There are three situations in which Input #1 must be introduced
into the algorithm while Input 0 is flowing to Output 0.
Usually, this must be done without bumping Output 0:
@ returning from a NaN value in Input #1 and GOOD = set
@ returning from a "Bad" value in Input #1 and GOOD = set
@ returning from the "Bypass" condition
The integer BAL defines how this introduction balancing is to
be done.
BAL = balancing option for dynamic input
= 0 if Output 0 can bump
= 1 if balance by forcing initialization up the
cascade through Input 0
= 2 if balance via the dynamics of this block.
= 3 if balance by permanently altering BIAS
= 4 if balance by permanently altering GAIN
= 5 if use a temporary "shock-absorber" bias
= 6 if use a temporary "shock-absorber" gain
= 7 if disable Input #1 and set Out1(n-1)
to 0 or 1 depending on whether the
algorithm is addition or multiplication.
+ BAL_T = rate of decay (in minutes) for the shock-absorber
term.
+ Input 0 = used as "Set Point" in algorithm = SP(n)
+ Input #1 = used as input to dynamic function = In(n)
+ Output 0 = Output 0 of the block (after output limits)
= Out0(n-1)
+ Output #1 = Compensated Input #1 (after output limits)
= Out1(n-1)
+ Externally readable:
@ BAL_B = temporary bias term - decayed to 0 at rate BAL_T
= NaN if BAL <> 5
--```,``-`-`,,`,,`,`,,`---
@ BAL_G = temporary gain term - decayed to 1 at rate BAL_T
= NaN if BAL <> 6
@ OBL1(n-1) = "Output1-before-limits" at last execution
= compensated Input #1 before output limiting is
applied.
@ Y(n-1) = compensated In(n) before gain and bias
adjustment at last execution.
+ Not externally readable:
@ 21 item stack for dead time
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
@ BADSTACK = discrete
= set if a "NaN" value is in the stack.
@ In(n-1)
@ N = cycle skip counter (counts down from "S" to 0)
= output of the algorithm before output limiting
is applied.
@ S = cycle skip for dead time algorithm
= number of cycles between entries in the history stack
SP-50 User Layer Technical Report Math

607
= 3 * T(2) / F
OVERVIEW OF ALGORITHM OPERATION:

Detailed Lead\Lag equation:
Out1(n-1) = Compensated Input #1 plus Output #1 limits.
= Input #1 with lead/lag, gain, and bias plus limiting.
Basic Logic:
IF the block is operating normally, then:
Y(n) = a Y(n-1) + (1-b) * In(n)
- (a-b) * In(n-1)
where:
In(n) = input at present sampling period
In(n-1) = input at previous sampling period
Y(n) = compensated input #1 before gain/bias,
at present sampling period
Y(n-1) = compensated input #1 before gain/bias
at previous sampling period
K = the steady-state gain
T(1) = the time constant of the lead
T(2) = the time constant of the first order lag
t = actual block scan time period in minutes
a = e**( - t / T(2))
b = 1 - T(1)/T(2)
OBL1(n-1) = K * Y(n) + Bias
Out1(n-1) = OBL1(n-1) after limiting
Out0(n-1) = Out1(n-1) combined with SP
Initialization of the block, the handling of a NaN or Bad
Input #1, and the recovery and balancing of the dynamic
portion are handled using the above defined options and
parameters.
Detailed Dead-time option:
Out1(n-1) = Compensated Input #1 plus Output #1 limits.
= Input #1 with pure dead time, gain, and bias plus
limiting
Basic Algorithm: twenty one position stack with input skip.
Basic Logic:
N = cycle skip counter
S = number of cycles to skip between entries in the history
stack.
IF the block is operating normally, then:
Y(n) determined from the history stack based
on the configured dead time and linear
interpolation. THEN:
OBL1(n-1) = K * Y(n) + Bias
Out1(n-1) = OBL1(n-1) after limiting
Out0(n-1) = Out1(n-1) combined with SP
If N <= 0
add In(n) to the history stack
N = S
ELSE N = N - 1
Initialization of the block, the handling of a NaN or Bad
Input #1, and the recovery and balancing of the dynamic
portion are handled using the above defined options and
parameters.

+ For the Lead/Lag option:
A "Bad" or NaN value for In(n) will result in an
immediate "Bad" OBL1(n-1) . If GOOD is reset, Out1(n-1)
will immediately be set "Bad". If GOOD is set, the last
value of Out1(n-1) will be used until the problem clears.

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
608
+ For the dead-time option:

@ If Input #1 is "NaN" at any time, the algorithm will
react as defined above for the lead/lag option.
@ If Input #1 is "Bad" during a cycle in which the value is
not to be added to the stack, the "Bad" alarm will be set
but the operation of the block will not be affected.
@ If Input #1 is "Bad" during a cycle in which the value is
to be added to the stack, a "Bad" alarm will be issued and
"NaN" will be entered in the stack. The calculation of
Y(n) and Output 0 of the block will not be affected
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
(yet). The "Bad" alarm will hold until the "NaN" is

cleared from the stack. Note: the stack can be cleared
by putting the block into bypass or OS mode, then returning
it to normal operation.
@ If a "NaN" value is encountered in the interpolation of
Y(n) , THEN:
IF GOOD is reset:
Y(n) will be "NaN"; the Out1(n-1) value will be
the last good value but the status will show "Bad",
and the "Bad" condition will flow through the block
calculations. The mode of the block will not be
changed.
ELSE:
--```,``-`-`,,`,,`,`,,`---
Y(n) will be "NaN"; The last good value of
Out1(n-1) will be used; the status of Out1(n-1)
will show "Good". The mode of the block will not be
changed.
@ Upon recovery from "NaN" or "Bad" (regardless of the state
of GOOD), the stack will be completely initialized; the
method of initialization will depend on BAL.

609
Math
An addition to the algorithm definition came up after this paper was accepted:
1) another form of the equation
2) an option on equations 4 and 5 - allow the user to ask for a special
initialization method - set INPUT0 to 50% and initialize the constant a.
3) two trios of user option bits -
a) one trio is OR'ed with the NFP status bits in INPUT0-2
b) one trio is OR'ed with the Bad status bits in INPUT0-2
c) the OUTPUT is the AND of the results of steps (a) and (b), not the raw
values of the status.
BASIC ALGORITHM:
- General mathematics operator with up to three analog inputs.
- Supports initialization and antiwindup for some algorithm forms
ALGORITHM OPTIONS:
- Six separate forms of the algorithm:
+ Flow Compensation with square root:
Output = a + f * Input 0
where f = b * [(c + Input #1) / (d + Input #2)] ** 1/2
+ Flow Compensation - linear:
where f = b * [(c + Input #1) / (d + Input #2)]
+ Dual Range:
Output = a + b * f * Input 0 + b * (1-f) * Input #1
1) If Input 0 = Bad, f = 0
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
2) If Input #1 = Bad, f = 1
3) If Input 0 < c, f = 1
4) If Input 0 > d, f = 0
Between conditions 3 and 4, f = interpolated
+ Averaging:
Output = a + b * (Input 0 + c * Input #1 + d * Input #2) / f
where f = the number of good inputs
+ Addition:
Output = a + [b * Input 0] + f
where f = [c * Input #1] + [d * Input #2]
+ Multiply:
where f = b * Input #1 + c / (d + Input #2)
--```,``-`-`,,`,,`,`,,`---

610

- Modes: all except LO (not IMan - By-pass: yes
for some algo.'s) - "PV Pointer": yes, default
- Hardware Pointers: none to Output
- Bit Pointers: none - Output Limits: yes
- Cascade Structure: yes - Boolean Operator: no
- Set Point Limits: yes

- Selection of initializable parameters:
@ Algo 0 (Flow Comp-square root) - none
@ Algo 1 (Flow Comp-linear) - none
@ Algo 2 (Dual Range) - none
@ Algo 3 (Averaging) - All inputs the same, a, or b
@ Algo 4 (Addition) - Input 0, a, or b
@ Algo 5 (Multiply) - Input 0, a, or b
- The value of the coefficient that multiplies Input 0 is considered in
setting the ATW bits. If the coefficient is zero, the upper level
control scheme is considered to be wound up.
- There is an option to require extra time in IMan mode after the
read-back Output stops moving. This option will allow higher control
blocks to fully initialize before control resumes.
- A special intermediate status byte is calculated and stored as a data
base item. An 8 bit string can be input as Input #3 and combined
into the feedback status byte. The exact combination method is
controlled by a user configured option. These features will allow
parallel or alternate control paths to interact.
- If the algorithm equation initializes a coefficient, the initialized
value of that coefficient will be decayed to zero or unity.
- Node Parameters:
- User Set Parameters;
+ Algo = integer value indicating algorithm number
= 0 to 5, default = 0
+ a = intercept in all equations (under the tuning attribute)
+ b, c, d = equation constants (all under the tuning attribute)
+ Init_Code = code number for initializable factor:
= 0 is no initialization
= 1 if Input 0 or "all" Inputs
= 4 if coefficient a
= 5 if coefficient b
+ T(1) = decay rate for initializable factor
= units of repeats/minute (under the tuning attribute)
{see the defining equation above}
+ Two limits that are algorithm dependent (both under the tuning --```,``-`-`,,`,,`,`,,`---
attribute):
@ For Algos 0 and 1:
Coef_Lim_1 = High limit on coefficient f
Coef_Lim_2 = Low limit on coefficient f //^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
@ For Algo 3:
Coef_Lim_1 = Low limit on average of inputs for
initializing b
@ For Algo 4:
Coef_Lim_1 = Low limit on Input 0 for initializing b
@ For Algo 5:
Coef_Lim_1 = Low limit on the absolute value of:
(d + Input #2)
Coef_Lim_2 = Low limit on total denominators in
initializing Input 0 or b
SP-50 User Layer Technical Report PID

611
+ PAUSE = the minimum length of time that IMan should be retained

after the initialization value read back from the lower
block stops moving.
= cycles.
+ IACOPTION = configured option to control the combining of Input
#3 with the feedback status.
= 7 bit string
+ Input 0 = Input(0) = SP(n)
+ Input #1 = Input(1)
+ Input #3 = MATESTAT
+ Output = Output of the block (after output limits) = Out(n-1)
@ T(2) = T(1) after limiting for T(1) <= 60 / F
@ f = the coefficient shown in the algorithm definitions
@ IACSTATUS = a special intermediate status byte stored in
the data base of the block.
@ CPAUSE = counter for PAUSE time
@ OBL(n-1) = "Output-before-limits" at last execution
is applied.
--```,``-`-`,,`,,`,`,,`---
- The Antiwindup bits in the Cas or RCas transfer locations are reset
when:
+ The appropriate mode is set AND
+ The Output can be moved in response to the indicated direction.
+ Input 0 has a non-zero coefficient in the algorithm.
@ In Algorithm 2, Input 0 is being used even if f = 0
@ Coefficient "f" in Algorithms 0, 1, and 5, and coefficient
"b" in algos. 2, 3, and 4.
- The user sets the value PAUSE. The algorithm maintains the counter
CPAUSE.
+ At initialization, CPAUSE = 0
+ If the read back value of Output = Output(n-1), THEN
CPAUSE = CPAUSE + 1 ELSE CPAUSE = 0.
+ If CPAUSE > PAUSE, CPAUSE = PAUSE
+ If the current mode is IMan, IMan can not be reset if
CPAUSE < PAUSE.
- A special status byte, IACSTATUS, will be generated. It will:
+ Have all bits except Bit #2 (from Process) set if this block is
in O/S mode.
+ ELSE, it will be set equal to the status byte of the Output,
THEN
@ The ATW bits will both be set if IMan mode is set in
this block, AND
@ The ATW effect of the Output limits of this block will be
added.
- Input #3 will be expected to be Null or in the form of a status byte.
Typically, it will be IACSTATUS from a companion block. It will be
combined with the feedback and mode information within this block to
set the status byte in the Cas and RCas transfer locations and the
operation of this block. Its use will be controlled by the option
integer IACOPTION. The option number will be set in binary to
correspond to the following seven questions, where a positive answer
to one of the questions indicates that that bit is set in the binary
value of IACOPTION. The term "Other block" refers to the block from
which Input #3 was fetched. The term "operate" refers to the absence
of the "doubly wound up" state.
0) If the other block has a bad Output value, does this block

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
612
operate?
1) If the other block has a failed path below it, does this block
operate?
2) If the other block has no path to the process below it, does
this block operate?
3) If the other block's output can not go up, can this block's
Output go up?
4) If the other block's output can not go up, can this block's
Output go down?
5) If the other block's output can not go down, can this block's
Output go down?
6) If the other block's output can not go down, can this block's
Output go up?
- If the initializable parameter configured in algorithms 3, 4, or 5
is an equation coefficient, it will decay to zero (for a) or to unity
(for b) at rate T(1) where:
a(n+1) (n+1) = a(n) - a(n) * T(1) * F / 60
OR
b(n+1) = b(n) - (b(n) - 1) * T(1) * F / 60
where F = block cycle time (seconds)
T(1) <= 60 / F

- All standard NAN and status bit responses and setting except:
+ If algorithm 0 or 1 is in use and Inputs #1 and/or #2 are "bad",
then the algorithm will use the last good value of the bad
input(s).
+ If Input #3 has its "No-com." or "bad" status bit set, the last
good value will be used.
--```,``-`-`,,`,,`,`,,`---
- Before algorithm execution starts, all off-node fetches will have

been done and the values placed in the pointer data bases if the
block is not O/S.
- Set bits 3 and 5-7 (special cascade, no path, and ATW's) in the
status bytes of all of the block's values except Output.
- Set bit 2 (no process information) and bit 3 (special cascade)
in the status byte of the Output.
- If all three of the pointers for the Inputs are Null, set the O/S
bit in the mode byte of this block.
- If the pointer for the Output is any of the following, set the O/S
bit in the mode byte of this block:
+ Null + Momentary Writeable
+ Immediate + Required Writeable
+ Writeable + Block Point (Counted)
- If the O/S mode bit is set, clear the other mode bits and END
- Bring in the prefetched and on-node reads with their status bytes
- The CASCADE procedure will have determined the value of SP(n) and
its status byte.
- If bits 0 and/or 1 of the status byte of Input 0 are set (Input 0 =
can't communicate or "bad") or Input 0 pointer = Null, then set
Input 0 = NAN
- If bits 0 and/or 1 of each of Inputs 2 and 3 are set or their
pointer = Null, THEN:
IF algo = 0, set Input = its last good value
Else set Input = NAN
- If the LO mode bit is reset, THEN:
+ If the ROut mode bit is set, reset bit 3 (special cascade bit)
in the ROut transfer value status byte.
+ If the RCas mode bit is set, reset bit 3 in the RCas transfer

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
613
value status byte.

- If all of the following conditions are true, then reset bit 5 in all
CASCADE transfer value status bytes and in the SP status byte:
+ Bit 4 of the Output status byte (no path to process, failure)
is reset
+ Bit 5 of the Output status byte (no path to process) is reset
+ Algo not 0 or 1
--```,``-`-`,,`,,`,`,,`---
+ Algo not 2 with Init_code <> 1

- If bit 4 of the Output status byte (no path to process, failure) is
set, set Man mode bit in the mode word of this block.
- If Init_Code <> 1, 4, or 5, then Init_Code = 0
- Unconditionally reset the IMan bit
- If no mode bits are set, then set the Man mode bit
- If Algo = 2, then f = number of Inputs that have a value <> "NAN".
- Execute the IMan mode operation {see below}
- If mode bits are set for LO or Man modes, jump to that operation {see
below}
- If the only mode bit that is set is ROut, jump to that operation {see
below}
- T(2) = 60 / F
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
If T(1) < T(2) THEN T(2) = T(1)
- If Bypass is set, THEN:
OBL(n-1) = Input 0 and f = 0
IF bit 2 in the status byte of Input 0 is reset, the reset bit 2
- If Bypass is reset, THEN:
+ Execute the forward Calculation Procedure {see below}.
+ If Use_2 is set, THEN:
@ If bit 2 (not effected by the process) of the status word
of Input #1 is reset, THEN reset bit 2 in the status byte
of Output
@ If Input #1 has a writeable pointer, THEN reset bits 6
and 7 (ATW's) in the status byte of Input #1
+ If Use_3 is set, THEN:
@ If bit 2 (not effected by the process) of the status word
of Input #2 is reset, THEN reset bit 2 in the status byte
of Output
@ If Input #2 has a writeable pointer, THEN reset bits
6 and 7 (ATW's) in the status byte of Input #2
- Preliminary ATW operation:
Note: The wound-up-high ATW bit (ATW-h) is the converse of
the wound-up-low (ATW-l) bit, repeat the following
steps for ATW-l
+ Start by setting ATW-h equal to bit 6 (Wound up high) of the
status byte from the Output pointer
+ Set ATW-h if OBL(n-1) above or equal to high output limit
+ Change all following references from ATW-h to ATW-l if Bypass
is reset AND any of the following are true:
@ Algo = 0 and coefficient f is negative
@ Algo = 1 and (b * f) is negative
@ Algo = 2 and coefficient b is negative
@ Algo = 3 and coefficient b is negative
@ Algo = 4 and f is negative
+ Temporarily store ATW-h for use below
- Output:
IF Out(n-1) > high output limit, THEN:
Out(n-1) = lower of OBL(n) and Out(n-1)
IF OBL(n) > high output limit, then ATW-h = set
ELSE IF Out(n-1) < low output limit, THEN:
Out(n-1) = higher of OBL(n) and Out(n-1)
IF OBL(n) < low output limit, then ATW-l = set
ELSE:
Out(n-1) = OBL(n)

614
IF Out(n-1) > High Output Limit THEN:

Out(n-1) = High Output Limit
ATW-h = set
IF Out(n-1) < Low Output Limit THEN:
Out(n-1) = Low Output Limit
--```,``-`-`,,`,,`,`,,`---
ATW-l = set
END IF
END IF
- Post processing ATW operation:
+ Set ATW-h if SP above or equal to high SP limit
+ Enter ATW-h bit into RCas and Cas transfer location status
bytes and in the SP status byte.
+ If RCas is not the highest priority mode bit set, set both ATW
bits in the RCas transfer location status byte.
+ If Cas is not the highest priority mode bit set, set both ATW
bits in the Cas transfer location status byte.
- END
INITIALIZATION (IMan) MODE:

- IMan can be caused by any one or combination of the following
conditions. They are numbered for purposes of the following
description of the operation.
IF there is an active output pointer and:
1) If bits 0 and/or 1 of the status byte of Out(n-1) are set
(Output can't communicate or "bad"), or if Out(n-1) = NAN
2) IF both ATW's are set in the status byte of the output pointer
3) IF the Output pointer value is not equal to Out(n-1)
4) IF in transition from O/S mode to any mode except LO, Man,
or ROut
- IF no conditions set, return to the Algorithm logic above.
- If Algo = 0 or 1, RETURN
- If Init_Code = 0, RETURN
- IF (1), (2), or (3), THEN set IMan mode bit but do not reset any
other mode bits
- Set ROut transfer location = Out(n-1)
- IF not (1) THEN: OBL(n-1) = Out(n-1)
- Execute the Back-Calculation Procedure (see below)
- RCas and Cas transfer value locations = SP(n)
- IF only (4), THEN RETURN to the Algorithm operation above
ELSE END.
BACK-CALCULATION PROCEDURE:
- The following are routines to outline the procedure to use to
initialize the initializable parameters given an Output. There
are three procedures, one for each of the three algorithms that
support initialization.
- If Algo = 2
IF Init_Code = 1 THEN:
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
SP(n) = 0
ELSE If b = 0 THEN:
SP(n) = (Out(n-1) - a) / b
END IF
IF Init_Code = 4, THEN:
IF f = 0 THEN a = SP(n)
ELSE Temp = 0
IF Input(1) = good, then Temp = Input(1)
IF Input(2) = good, then Temp = Temp + Input(2)
a = Out(n-1) - b * Temp / f
END IF
If f = 0 then b = 1 ELSE:
Temp = 0

615

If Temp < coef_Lim_1 THEN Temp = coef_Lim_1
b = f * (Out(n-1) - a) / Temp
END IF
- ELSE If Algo = 3
f = c * Input(2) + d * Input(3)
If b = 0 THEN SP(n) = 0 ELSE
SP(n) = (Out(n-1) - a -f) / b
a = Out(n-1) - f - b * Input(1)
Temp = Input(1)
If Temp < coef_Lim_1 THEN Temp = coef_Lim_1
b = (Out(n-1) - a - f) / Temp
END IF
- ELSE If Algo = 4
f = d + Input(3)
IF f < Coef_Lim_1 THEN f = Coef_Lim_1
f = c / f
f = f + (b * Input(2) )
Temp = f
IF Temp < Coef_Lim_2 THEN Temp = Coef_Lim_2
Input(1) = (Out(n-1) - a) / Temp
END IF
f = f + (b * Input(2)
a = Out(n-1) - f * Input(1)
Temp = Input(1) * Input(2)
IF Temp < Coef_Lim_2 THEN Temp = Coef_Lim_2
b = (Out(n-1) - a - f * Input(1) ) / Temp
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
f = f + b * Input(2)
END IF
END IF
END IF
RETURN
FORWARD CALCULATION PROCEDURE:

- The following are simple routines to outline the procedure to use
to calculate the Output given the Inputs. There are the four
procedures for the four algorithms.
- Define 2 temporary variables:
+ USE_2 = 0 (indicates that Input #1 is used if set)
+ USE_3 = 0 (indicates that Input #2 is used if set)
- IF Algo = 0
f = b * [(c + Input(2) ) / (d + Input(3) )] ** 1/2
IF Divide by zero, THEN f = Coef_Lim_1
IF f > Coef_Lim_1 THEN f = Coef_Lim_1
IF f < Coef_Lim_2 THEN f = Coef_Lim_2
Out(n-1) = a + f * Input(1)
If b <> 0 and Input 0 <> 0 and Input 0 <> NAN THEN:
Use_2 = 1
Use_3 = 1
If (c + Input(2) ) = 0 or NAN, THEN:
Use_3 = 0
ELSE If Algo = 1
IF Input(1) = bad, THEN f = 0
ELSE IF Input(2) = bad, THEN f = 1
ELSE IF Input(1) < c THEN f = 1
ELSE IF Input(1) > d THEN f = 0
ELSE f = (Input(1) - c) / (d - c)

--```,``-`-`,,`,,`,`,,`---

616
--```,``-`-`,,`,,`,`,,`---
END IF
IF f > 1 THEN f = 1
IF f < 0 THEN f = 0
Out(n2) = a + b * f * Input(1) + b * (1 - f) * Input(2)
If b <> 0 THEN:
Use_2 = 1
Use_3 = 1
ELSE If Algo = 2
Temp = 0
Out(n-1) = a + Temp / f
IF Init_Code = 4 THEN decay a to 0 at first order rate T(1)
If b <> 0 THEN:
Use_2 = 1
Use_3 = 1
ELSE If Algo = 3
f= c * Input(2) + d * Input(3)
Out(n-1) = a + b * Input(1) + f
IF Init_Code = 4 THEN decay a to 0 at rate T(1)
IF Init_Code = 5 THEN decay b to 1 at rate T(1)
IF c <> 0 then Use_2 = 1
IF d <> 0 then Use_3 = 1
ELSE If Algo = 4
IF (d + Input(3) ) < Coef_Lim_1 THEN:
Temp = Coef_Lim_1
ELSE Temp = d + Input(3)
END IF
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
IF Init_Code = 4 THEN decay a to 0 at first order rate T(1)
IF Init_Code = 5 THEN decay b to 1 at first order rate T(1)
f = b * Input(2) + c / Temp
Output = a + f * Input(1)
IF (b * Input(1) ) <> 0 or NAN, Use_2 = 1
IF (c * Input(1) ) <> 0 or NAN, Use_3 = 1
END IF
RETURN
MANUAL (Man) AND LOCKED OUTPUT (LO) MODES:

- If Output has an active pointer, THEN:
Out(n-1) = last good value of Output
- Set ROut transfer location = OBL(n-1) = Out(n-1)
- Execute the Back-Calculation Procedure {see above}
- END
REMOTE OUTPUT (ROut) MODE:

- Out(n-1) = value in ROut transfer location
- Set bits 0-2 of the Output transfer location status byte equal to
bits 0-2 of the ROut transfer location status byte.
- Move both ATW's from the output status byte to the ROut transfer
location status byte
- OBL(n-1) = Out(n-1)
- Execute the Back-Calculation Procedure {see above}
- RCas and Cas transfer locations = SP(n)
- END

617
PID Control
Editor's Note: This function block description has been accepted by

the User Layer Subcommittee as a technical report paper but it has not yet been
0edited. All of the functionality of the block has been defined but the details
This algorithm was one of the first ones done and has not been editorially
updated recently. This description needs many small corrections. The only large
change is the addition of a completely different PID equation form as an option -
an absolute PD form. This has been accepted by the committee but not edited into
this paper.
BASIC ALGORITHM:
- PID controller with:
+ No cross-product term (Classical or non-interactive algorithm;
in ISA SP51.1, PID equation on p11, a = infinity [required to
be >1] and b = 0 [required: 0 <= b << 1.])
+ Non-linear gain on all terms
+ If gain = 0, then ID equation operates with a gain of unity
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
+ Initialization
+ Anti-windup protection based on discrete indicators
+ Derivative based on [PV(n) -PV(n-1) ]
+ Integral and Derivative action "skips cycles" if the revision
number on Input #1 doesn't change. Skips are counted and
the time is adjusted.
+ Set to doubly wound up if Input #1 is not from the process.
+ Rate limiting (with alpha set to 16)
+ Tracking option where Output tracks feedback
+ Option to automatically recover from a "Bad" PV.
ALGORITHM OPTIONS:
--```,``-`-`,,`,,`,`,,`---
- ACT = Direct/Reverse action
= Set for Reverse (default)
- PROP = Proportional Term basis
= 0 if [PV(n) -PV(n-1) ] (default)
= 1 if [PV(n) -SP(n) ]
- SPTRK = Set point track (move Input #1 into SP)
= integer
= 0 if No
= 1 if Yes if not in RCas, Cas, or Auto mode. (default)
= 2 if Yes if not in ROut, RCas, Cas, or Auto mode.
- BADIN = Option for action on "Bad" Input #1
= 0 if set doubly wound up
= 1 if set block to Man mode

618

- Modes: all except plain LO - By-Pass: no
- Hardware Pointers: none - "PV Pointer": yes, default
- Bit Pointers: none to Input #1
- Cascade Structure: yes - Output Limits: yes
- Set Point Limits: yes - Boolean Operator: no

- "NAN" and/or "Bad" status for Inputs #0 or 1 are prevented from going
through the algorithm to the Output.
- A rising edge on the Force Tracking input causes Man(x) compound
mode. When the Force Tracking input has a falling edge, the Manual
mode bit will be reset only if another, lower priority, mode bit is
set. The continuous set or reset condition of the Force Tracking
input has no effect on mode. Thus, any Field Bus device (including
the operator's console) can change the block mode while the Force
Tracking input is set or reset.
On transition out of O/S mode, if the Force Tracking input is found

set on the first execution, it will be considered to be a rising
edge.
- The algorithm has a state of "suspended automation" that is not

forward calculating but is not IMan either. This state is called
"doubly wound up". Set point tracking will not be forced because
IMan is not set; the output will not change because the algorithm is
told that it can neither raise nor lower the output; a primary will
be forced into initialization (IMan mode) if there is an upward
initialization path. This state is caused by an Input #1 that is not
from the process or by a "bad" status condition on the Input #1 with
the BADIN option reset (do not set the block to Man mode upon a "Bad"
PV). It is indicated by both of the ATW bits being set in the SP
status but IMan mode not set.
--```,``-`-`,,`,,`,`,,`---
- Node Parameters:
+ Gain constant (in units of % Change in Output per % error) = K
+ Non-linear gain constant (in units of 1 / % error) = KNL
+ Integral time (in units of repeats/minute) = T1
+ Derivative time constant (in units of minutes) = T2
+ Input 0 = used as "Set Point" in algorithm = SP(n)
+ Input #1 = used as the "Process Variable" in algorithm = PV(n)
+ Input #2 = configured feedback value = FB
+ Input #3 = force tracking (set = force)
@ Error(n-1) = PV(n-1) - SP(n-1)
@ PV(n-1) = PV at last execution
@ PV(n-2) = PV at second last execution
@ Derivative Term(n-1) {defining equation below}
is applied.
@ SK = Count of the number of cycle skips caused by revision
number not changing.
@ INIT = Logical - set indicates that the algorithm is in the
first execution after O/S mode.
SP-50 User Layer Technical Report Property Conversion

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
619
@ MUSTI = Logical - set indicates that the algorithm must

execute SP tracking and initialization with
the first good PV that is from the process.

+ Input #1 status = "Bad" (Bit #1 set):
@ If "BADIN" not set:
Mark the algorithm as doubly wound up.
Do not count skip cycles.
Do not change any mode bits.
Do not initialize the algorithm.
Do not set "Bad" status for the output value.
Hold everything but continue to write the Output.
@ If "BADIN" is set:
Set Manual Mode and stay there even if good PV returns
(i.e., reset all bits in the mode byte with lower
priority than manual).
Do not set "Bad" status for the output value.
+ Input #1 not effected by any process information (Bit #2 reset):
Alarm condition and show the algorithm as doubly woundup.
+ Input #2 (Feedback) status = "Bad" (Bit #1 set):
If Force Tracking Bit not set, ignore
If value is NAN, set Man mode and reset lower priority mode
bits
If value is Bad, use last good value; use new value next time
if good.
+ Input #3 (Force Tracking Bit) status = "Bad" (Bit #1 set):
Use last good value, use new value next time if good.
- In addition to the standard rules, the following actions are taken:
+ If after applying the standard rules, the new SP value = NAN, go
to Man (ignoring the permission bit and the BADIN option) with
NAN left in the SP value and all lower priority mode bits
cleared. Do not set Bad for the output value.
--```,``-`-`,,`,,`,`,,`---
+ If after applying the standard rules, the new SP value = Bad,

mark the old SP value "Bad". Initialize the RCas and Cas
transfer locations to the (old) SP value and status (now bad)
but with both ATW bits set. Use the (old) SP value in the
algorithm, ignoring the Bad status.
+ Output 0 status = "no path to process - failure" (Bit #4 set):
Set this block's mode to IMan (leave lower priority mode
bits set).
+ Output 0 status = "no path to process" (Bit #5 set):
Set this block's mode to IMan (leave lower priority mode
bits set).
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
block is not O/S.
- If the pointer for Input #1 is one of the following, set the O/S
+ Null
+ Immediate

620
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
- If O/S mode bit set, clear other mode bits and END
- Bring in the on-node reads with their status bytes
- The CASCADE procedure will determine the value of SP(n) and its
status byte.
- If bits 0 and/or 1 of the status byte of Input 0 are set (SP =
can't communicate or "bad"), THEN:
If Input 0 <> NAN and the only mode bit set is Auto THEN:
Input 0 = its last good value
ELSE Input 0 = NAN
- If bits 0 or 1 of the Input #1 status byte are set (PV = can't
communicate or is "bad") THEN Input #1 = NAN
- If any of the 3 Inputs have a value of "NAN", THEN set the Man mode
bit and clear all lower priority bits in the mode byte. When doing
Input #2, ignore it if its pointer is Null.
- If bits 0 or 1 of the status byte of Input #2 are set (Feedback =
can't communicate or "bad") and the pointer for Input #2 <> Null, set
the value of Input #2 to its last good value.
- If the LO mode bit is reset and the Force Manual bit is not both good
and set, THEN:
value status byte.
- If bit 4 of the Output status byte (no path to process, failure)
is reset and if bit 5 of the Output status byte (no path to process)
is reset, then reset bit 5 in all CASCADE transfer value status bytes
and in the SP status byte.
- Execute the Force Manual logic {see definition below}
below}
below}
- Reset bit 2 (not effected by the process) in the Output status byte
- Reset bits 6 and 7 (ATW's) in the status byte of Input #1 if the
pointer for Input #1 is a writeable pointer.
steps for ATW-l
+ Change all following references from ATW-h to ATW-l if block
has reverse action
- If direct action: OBL(n) = OBL(n-1) + Delta Output
- If reverse action: OBL(n) = OBL(n-1) - Delta Output
- Delta Output = Gain * [Proportional Term + Integral Term +
Derivative Term(n) ]
- Gain = K * [1 + KNL * |Error(n) |]
- If Gain = 0, then:
Delta Output = Integral Term + Derivative Term(n)
- Error(n) = PV(n) - SP(n)
- Proportional Term = [PV(n) - PV(n-1) ]
or, optionally = [Error(n) - Error(n-1) ]
- Integral Term = [F * T1 / 60 ] * [Error(n) ]

--```,``-`-`,,`,,`,`,,`---

621
+ If ATW-h set and Integral Term > 0, then Integral Term = 0

+ If ATW-l set and Integral Term < 0, then Integral Term = 0
+ If bit 2 of the Input #1 status byte set (value not effected
by process information), then Integral Term = 0
- Derivative Term(n) = [T2 / (F + RL)] *
[PV(n) - 2 * (PV(n-1) ) + PV(n-2) ] +
[RL / (F + RL)] * Derivative Term(n-1)
- RL = Rate Limiting = T2 / 16
- OBL(n) = OBL(n-1) + Delta Output
- Update Variables:
Note: this is the point where (n) becomes (n-1)
+ PV(n-2) = PV(n-1)
+ PV(n-1) = PV(n)
+ Derivative Term(n-1) = Derivative Term(n)
+ Error(n-1) = Error(n)
+ OBL(n-1) = OBL(n)
- Output:
ELSE:
Out(n-1) = OBL(n)
ATW-h = set
ATW-l = set
END IF
END IF
+ Set ATW-h if SP above or equal to high SP limit
--```,``-`-`,,`,,`,`,,`---
- END

1) If there is an active output pointer and IF bits 0 or 1 of the
status byte of Out(n-1) are set (Output can't communicate or
"bad"), or if Out(n-1) = NAN
2) IF there is an active output pointer, AND IF both ATW's are
set in the status byte of the output pointer
3) IF there is an active output pointer, AND IF the Output
pointer value is not equal to Out(n-1)
4) IF there is an active output pointer, AND IF the status
byte of the output pointer has bit 5 set (no output to process)
5) IF force tracking is on (see below)
or ROut
7) First pass after recovering from a bad value (i.e., a NAN) or
status (either can't communication or "bad") for Input 0
(SP), Input #1 (PV), or Output.
- IF (6) AND the force manual bit is "bad" THEN reset the force manual
bit.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
622
- IF (6) AND the force tracking bit is "bad" THEN reset the force
tracking bit.
- IF (5) and not (1), (2), (3), or (4), THEN:
@ Set Out(n-1) = FB
@ If the pointer for Input #2 is a writeable pointer, then reset
bits 6 and 7 (ATW's) of the status byte of Input #2.
- IF (1), (2), (3), (4), or (5), THEN set IMan mode bit but do not
reset any other mode bits
- Set Derivative Term(n-1) = 0
- Set PV(n-2) = PV(n-1) = PV(n)
- IF SP tracking option is set, THEN SP(n) = PV(n)
- Set Error(n-1) = PV(n) - SP(n)
- IF only (6) and/or (7), THEN RETURN to the Algorithm operation above,
ELSE END.
FORCE TRACKING:
- If the Force Tracking pointer is not Null and the Feedback pointer
is not Null, THEN:
IF the Force Tracking bit is good and set
OR IF the Force Tracking bit is bad but the last good value was
set
THEN
Force IMan to be executed this cycle.
Set initialization condition (5) {see above}
END IF
RETURN
FORCE MANUAL:
- If the Force Manual pointer is not Null, THEN:
IF the Force Manual bit is good and set
THEN Man mode bit = set (leave all other bits alone)
Man mode operation will be executed this cycle if IMan not
set
END IF
RETURN
Note: When the Force Manual bit is reset, the manual mode bit
will be reset if and only if a lower priority bit is set in
the mode byte. The resetting will be done by the data base
write service. If the force manual bit goes bad, Man mode
will stay. It can be changed by the operator in that case.
If later the force manual bit becomes set and good again, it
will again force manual mode.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

- Set PV(n-2) = PV(n-1) = PV(n)
- If SP tracking option is set, then SP(n) = PV(n)
- END

--```,``-`-`,,`,,`,`,,`---

623

- OBL(n-1) = Out(n-1)
- Set PV(n-2) = PV(n-1) = PV(n)
- If SP tracking option during ROut is set, then SP(n) = PV(n)
- END
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
624
Property Conversion
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\


BASIS FOR BLOCK DEFINITION
ALGORITHM OPTIONS
STANDARD BLOCK FEATURES
MODES
EXPLANATION OF VOLUME COMPENSATION
EXPLANATION OF THE DISCRETE "2Phase"
EXPLANATION OF THE PARAMETER STRING "Vector"
EXPLANATION OF "BAD" HANDLING
EXPLANATION OF ROut HANDLING
Table 1 - Algorithm Codes
Figure 1 - Property Block
BASIC ALGORITHM:
- This algorithm is defined as an "Alternate block" - the algorithm
rules are not defined. The data structure is designed to support an
algorithm that calculates a physical property of a material or fluid
(Output 0) and the ratio of that property to the same property at a
standard condition (Output 1). One input to the algorithm is
intended to be introduced through the Setpoint (it could, for
example, be the fluid gravity at base conditions; the conversion for
o API is supported). Inputs 1 and 2 would introduce the actual
temperature and pressure if needed.
- Refer to the attached drawing "Property Block".
- An option identifies the SP as either the property at a defined base
temperature/pressure or at the actual temperature and pressure. Two
coefficients in one of two equation forms are available to convert
the property to the units required by the algorithm. The result is
shown in the drawing as Qin .
- The base conditions are identified by two data base entries.
- The actual temperature is introduced as Input 1. Two coefficients in
a fixed conversion equation are available to convert the temperature
to the units of degrees Kelvin (shown as "T" in the drawing).
- The actual pressure is introduced as Input 2. Two coefficients in a
fixed conversion equation are available to convert the pressure to
the units of Pascals (shown as "P" in the drawing).
- The block contains an algorithm for converting Qin to/from the base
conditions and the actual conditions. The conversion method is not
defined by the Field Bus standard but a partial list of code numbers
is defined with many code numbers left available for "free" use. The
resulting value for the physical property is shown in the drawing as

--```,``-`-`,,`,,`,`,,`---

625
Qout .
- Qout can be converted to different units using two coefficients and
one of two equation forms. The resulting value is Output 0. This is
the value that can be changed by the operator in Man mode.
- The ratio of Qin /Qout or, optionally, Qout /Qin , is identified
in the drawing as "f" and is moved into Output 1.
- A data structure is included to support a discrete that indicates
incipient phase change.
BASIS FOR BLOCK DEFINITION:

A recognized need for the block is to generate the volume correction factor
that is frequently needed for the Totalizer block. In a fluid flow totalizing
application, a counter input represents volume at flowing conditions. This
Property block would convert the known density of the fluid at base conditions to
the density at the temperature and pressure of the flowing stream. The ratio of
--```,``-`-`,,`,,`,`,,`---
the densities is used by the Totalizer block to convert the indicated volume to
volume at base conditions.
Alternately, the density at flowing conditions might be used directly for

flow compensation in a MATH block.
The design of the block was made more generic with the intention of
converting a wide range of physical properties from one state condition to
another. It is probable that the resulting general form will have many diverse
uses. The following description will be in terms of the general property
conversion application
ALGORITHM OPTIONS:
- SP_Base = discrete.
= Reset if SP is at the measured conditions.
= Set if SP is at "base" conditions.
= may be a read-only value.
- SP_EQ = discrete
= Reset if Qin equation 0 is to be used:
Qin = ai0 * (SP + bi0 )
= Set if Qin equation 1 is to be used:
Qin = ai0 / (SP + bi0 )
- Qout_EQ = discrete
= Reset if Qin equation 0 is to be used:
Output0 = (Qout / ao0 ) - bo0 )
= Set if Qin equation 1 is to be used:
Output0 = (ao0 / Qout ) - bo0
- F_Base = discrete
= Reset if f = Qin /Qout .
= Set if f = Qout /Qin .
- ROut_Val = discrete
= Reset if ROut transfer value = Qout
= Set if ROut transfer value = Output 1
- Bias_Type = discrete
= Reset if ROut bias is additive.
= Set if ROut bias is multiplicative.
- Incip = enumeration
= 0 if 2Phase is not supported (Tol_T and Tol_P not needed)
= 1 if 2Phase is to be set for incipient vapor phase
= 2 if 2Phase is to be set for incipient liquid phase
= 3 if 2Phase is to be set for incipient solid phase
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~"

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#
626

- Modes: all ex. IMan, LO - Set Point Limits: yes
- Hardware Pointers: no - "PV Pointer": yes, default
- Bit Pointers: no to Output 0 (analog).
- Cascade Structure: yes but will - Output Limits: yes, 2 sets.
- By-pass: yes, to Output 0
MODES:
- In Manual, SP and Output 0 can be adjusted by Field Bus writes. The
block will calculate Output 1 from SP and Output 0 (SP will be
converted to Qin and Output 0 will be back-converted to Qout ,
then f will be calculated based on the F_BASE option and moved into
Output 1).
- In Auto, Outputs set by algorithm. The SP will be adjustable by
Field Bus writes unless SP_Need is reset. In that case, the SP is
set by the algorithm.
- In Cas, Input 0 pointer or Cas transfer location used for SP.
- In RCas, transfer location used for SP.
- In ROut:
+ The value in the ROut transfer location is optionally set to
match either Qout or Output 1. The algorithm calculates the
other Output from Input 0 (convert Input 0 to Qin using the
SP_EQ equation) and the ROut transfer location value.
+ a calibration factor will be generated:
@ Calculate the difference between Qout and the value that
would have been calculated by the block algorithm.
@ Optionally defined as additive or multiplicative to the
block's result.
@ Filter the bias value using a first order filter to
minimize the effect of poor data time coherency and the
operation of the block for a few cycles after the higher
level device fails. Note: no filter is to be used on the
first execution after transfer to ROut mode.
@ Apply the calibration factor to the block algorithm result
when the block mode is changed from ROut to Auto, Cas, or
RCas.
@ After leaving ROut mode, the term will be decayed to 0 (if
additive, 1 if multiplicative) at a first order decay rate
specified by a data base time constant.
@ The term will be reset (to 0 or 1) if the block mode is
changed to Manual or O/S.

- The rules for calculating the Outputs, given Inputs 1 and 2 and the
SP, are not specified.
- Record of bad values for any of SP, Input 1, or Input 2:
+ A 16 bit counter is incremented once in any cycle that finds a
"Bad" value but not Null pointer for Input 1 and/or Input 2
and/or a "Bad" but needed SP if the mode is lower in priority
zero when a "Bad" value as defined above is found, the current
system time is saved into the time stamp register. The field
device provides no mechanism to rezero the register but it is
writeable.

--```,``-`-`,,`,,`,`,,`---

627
EXPLANATION OF VOLUME COMPENSATION:

The measurement of volume flow rates sometimes requires correction of the
measured volume at the process conditions to volume at a standard base condition.
This correction must usually be done for each increment of volume using the then-
current stream state conditions at the volume measuring device. The Totalizer
block is designed to allow this correction but requires that the volume
correction factor be input. The following will describe how the Property block
will be used to supply the volume correction factor for an example application.
There are only a few methods of correcting volume to standard conditions that
are formalized in International Standards. The following Standards appear to
have agreed on the correction factors for liquid petroleum fractions:
API Standard 2540, First Edition, Aug, 1980
IP 200
ASTM D1250
ANSI/ASTM D1250
ISO TC/28 SC3
The petroleum fractions they have defined are:
Generalized Crude Oils
Gasoline (50 <= o API <= 85)
Jet Fuels (37 <= o API <= 50)
Fuel Oils (0 <= o API <= 37)
Lubricating Oils
Individual and Special Applications
The volume corrections of the first 5 fractions requires the density of the
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
fraction at the base temperature. The last requires "alpha", the thermal
expansion coefficient at the base temperature where:
alpha = 1 dV
--```,``-`-`,,`,,`,`,,`---
V dT
The engineering units of alpha will be 1/Kelvin degrees in the Property
block.
The following Standards define the correction factors for certain gases and
super-critical fluids:
TBD
In a direct implementation of API Standard 2540 for Gasoline, the algorithm

would be configured in the following way assuming it was desirable to display
units of o API and o F:
- The density of the gasoline in o API at 60 o F would be entered as
the SP. The block would normally be in Auto mode. (SP_Need = set;
SP_Base = Set.)
- The mode permissives for Cas, RCas, and ROut would be reset so that
those modes could not be entered.
- The correct form of the SP equation would be chosen to convert SP to
specific gravity:
SP_EQ = Set (equation 1).
ai = 141.5
bi = 131.5
- The temperature of the gasoline at the meter in o F would be
configured into Input 1.
- The correct coefficient for the Input 1 equation converts Input 1 to
o K.
ai1 = 0.5556
bi1 = 460.
- The pressure is not needed so the algorithm would have reset P_Need.
- The algorithm would calculate the specific gravity at actual
conditions, Qout .
- The correct form of the Qout equation converts Qout to o API;
the result will be available as Output 0.
Qout_EQ = Set (equation 1).
ao0 = 141.5
bo0 = 131.5
- The F_BASE option would be Reset so that Output 1 = f = Qin /Qout
- Output 1 would be fetched by the Totalizer block and used to correct
the pulses from the turbine meter measuring the flow of the gasoline.

628
EXPLANATION OF THE DISCRETE "2Phase":

A manufacturer may offer an enhancement to the basic algorithm that provides
an indication of the presence of a second phase in a fluid. For example, an
indication that steam quality is about to drop below 100%. This information may
be reasonable to calculate for some applications of this data set. The indicator
will be called "2Phase".
One option that may be appropriate for this function is the selection of
whether 2Phase is to indicate incipient vapor, liquid, or solid. This selection
is done with the parameter Incip.
It is anticipated that this function may, at times, need to impart a

directional bias in its calculations to gain conservatism for the indicator.
This bias will be introduced as if the uncertainty were totally due to the
uncertainty in the pressure and temperature measurements. Therefore, two
tolerance values (Tol_T and Tol_P) are defined.
Given the direction option Incip, the fluid definition (ACN), a primary
property (Setpoint), and the actual temperature and pressure (Inputs 1 and 2),
the algorithm is to calculate 2Phase. In its calculations, it is to bias the
pressure and temperature measurements with Tol_P and Tol_T so that 2Phase will be
set "early" as the 2 phase region is approached from the current single phase
region. Again consider a steam example: while the operating conditions indicate
superheated steam is present, the Tol_P would be added to the actual pressure and
the Tol_T would be subtracted from the actual temperature to cause 2Phase to be
set "early" as the temperature dropped or the pressure increased.
EXPLANATION OF THE PARAMETER STRING "Vector":

It is anticipated that each implementation of this algorithm will use
internal, private equation forms and coefficients. These algorithm coefficients,
coded parameters, etc may all be organized into a data set that is defined by the
manufacturer and made known to the user. Given the definition of the data set,
the user might be able to productively use a method of loading a "blind" data set
to the algorithm. Such a method is provided for this algorithm.
The parameter "Vector" is a set of 32 bit floating point numbers. The number
--```,``-`-`,,`,,`,`,,`---
of variables in the set is defined by N_Vector. The value of N_Vector will be an

integer that can not be larger than 32. The order and definition of the
variables can be defined by the manufacturer for the user. When a variable is
written to Vector, it is expected to be the defined set in the defined order.
EXPLANATION OF "BAD" HANDLING:

This block is designed based on the functional requirements for the volume
correction factor as used by the Totalizer block. In a situation in which the
two blocks are calculating an accurate measure of the total flow of a stream, it
is not appropriate to simply stop the Totalizer when a temperature or density
measurement becomes "Bad". Rather, appropriate alarms will be set and the last
good value of the measurement will continue to be used. It is expected that the
physical properties of the flowing fluid will not change rapidly at the same time
that a "Bad" measurement happens. The operator response to the alarms might be
to stop the flow so that the bad measurement can be fixed.
A "Bad" but not NaN value in any of the Property block's inputs will flow
through the block. If it is used to calculate an output, that Output will be
marked "Bad". This is the standard procedure for most Field Bus blocks. The
Property block will count the number of cycles during which a "Bad" value was
used by the block's algorithm.
The Totalizer block will ignore a "Bad" indicator on the volume correction
factor; it will use the value (which will be based on the last good value) if it

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
629
--```,``-`-`,,`,,`,`,,`---
is not NaN. If it is NaN, the Totalizer block will change the value to 1.0 and
"Bad" and use that.
A second design basis for the Property block was the use of Output 0 by the
Math block for flow compensation. In that configuration, the Math block will
also ignore a "Bad" indicator on the Output 0 value it gets from the Property
block; it will use the value (which will be based on the last good value) if it
is not NaN. If it is NaN, its action will be different from the Totalizer block:
it will allow the NaN to flow through to the Output. This difference is due to
the fact that there is no "safe" default for the physical property used by the
Math block similar to the "safe" default of 1.0 for the ratio used by the
Totalizer.
EXPLANATION OF ROut HANDLING:

There may be applications in which a higher level device is able to calculate
a more accurate Output value but the calculation procedure must be backed up by a
field device that does not have as accurate a procedure or does not have access
to other state measurements. In such a situation, the higher level device would
move the highly accurate value into the Rout transfer location. For maximum
accuracy, the ROut value must be the value that is actually used by the consumer
block, either Output 0 or Output 1. The alternate value can be calculated by the
Property block despite the fact that the data for the calculation are not exactly
time coherent.
When the higher level device fails, the minimum immediate impact can be
achieved if the block retains a bias term that was generated while the higher
level device calculations could be compared to the results of the less accurate
Property block algorithm. Since the decay time can be set to a very large value,
the value can be retained for the "rest of the batch". Resetting the mode to
manual will clear the value.
+ ACN = Algorithm Code Number = Integer value 0-255:
See Table 1 for the defined, reserved, and free code
numbers.
+ AName = 20 character visible ASCII string.
= algorithm description. For example: API 2540 (1980)
may be read-only.
+ ANumber = 20 character visible ASCII string.
= supported values of ACN. For example: 2-7
may be read-only.
+ Coef = Coefficient = real value:
= alpha if ACN = 7.
= manufacturer defined for ACN <> 7.
+ BaseT = the base temperature in degrees Kelvin.
Note: This variable can be read-only.
+ Tol_T = the uncerrtainty in the measured temperature
= units of Input 1 (i.e., will be multiplied by ai1 ).
+ BaseP = the base pressure in Pascals absolute.
Note: This variable can be read-only.
+ Tol_P = the uncertainty in the measured pressure
= units of Input 2 (i.e., will be multiplied by ai2 ).
+ OPTION = Bit string of length 16
Bit 0 = SP_BASE (see "Algorithm Options" above).
Bit 1 = SP_EQ (see "Algorithm Options" above).
Bit 2 = Qout_EQ (see "Algorithm Options" above).
Bit 3 = F_BASE (see "Algorithm Options" above).
Bit 4 = ROut_Val (see "Algorithm Options" above).
Bit 5 = BIAS_Type (see "Algorithm Options" above).
Bits 6&7 = Incip
Bits 8&9 = free
Bits A-F are read-only:
Bit A = free

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
630
Bit B = Reserved
Bit C = Pressure not needed (and hence Tol_P not
needed).
Bit D = Coef not needed
Bit E = ROut Bias not supported (and hence Tol_T and
Tol_P not needed).
Bit F = Vector not supported (and hence N_Vector not
present).
+ No_OPTION = Bit string of length 16
@ A set bit in No_OPTION, bits 0 thru 9, indicates that the
corresponding bit in OPTION is read-only.
@ Bit A = free
@ Bit B = Reserved
@ Bit C set = Setpoint is read-only
@ Bit D set = BaseT is read-only
@ Bit E set = BaseP is read-only
@ Bit F set = ACN is read-only
+ The conversion constants shown in the drawing:
ai0 bi0
ai1 bi1
ai2 bi2
ao0 bo0
+ The filter time constants for calculating the bias term for
ROut (Tc ) and for decaying the term after leaving ROut mode
(Td ). Both time constants are expressed in minutes.
+ Vector = The "blind" set of algorithm variables defined by the
manufacturer and optionally provided to the user.
+ N_Vector = non-negative integer
= number of 32 bit floating point values in Vector
= <= 32
= 0 if Vector is not supported
+ Input 0 = Input to Cascade structure for SP
= property value at the conditions defined by the
options and base conditions or Inputs 1 and 2.
+ Input 1 = Fluid temperature in working units.
+ Input 2 = Fluid pressure in working units.
+ Output 0 = Property value at the conditions defined by the
options and base condition or Inputs 1 and 2.
+ Output 1 = the ratio of the properties as defined by the
F_Base option.
--```,``-`-`,,`,,`,`,,`---
+ 2Phase = discrete
= set if second phase is incipient
+ Bias = real variable
= the calculated, filtered value representing the
difference between the ROut value and the equivalent
product for the block algorithm.
= ROut value - Algorithm value
Input Value (i.e., SP and/or Input 1 or 2) = "Bad"
AND
Mode = lower priority than Man
the Bad_Input_Counter after the time_stamp location
was set to zero or the block transitioned from O/S
mode.

- All standard NAN and status bit responses and setting.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
631
Properties Conversion, TABLE 1 Algorithm Codes

0 = no correction (default value).
--```,``-`-`,,`,,`,`,,`---
Factors 1 - 39 are to be used for density/density ratio

type algorithms for liquids.
1 = density/density ratio for pure water.
2 = density/density ratio for generalized crude oil.
3 = density/density ratio for gasoline.
4 = density/density ratio for jet fuel.
5 = density/density ratio for fuel oil.
6 = density/density ratio for lubricating oil.
7 = density/density ratio for "individual and
specialized applications" as defined by API, et.al.
8 = density/density ratio for LNG.
9 = density/density ratio for LPG.
10-19 = Reserved.
20-39 = free.
Factors 40 - 79 are to be used for density/density ratio type

algorithms for gases and super-critical fluids.
40 = density/density ratio for dry air.
41 = density/density ratio for natural gas.
42 = density/density ratio for hydrogen.
43 = density/density ratio for methane.
44 = density/density ratio for ethane.
45 = density/density ratio for ethylene.
46 = density/density ratio for propane.
47 = density/density ratio for propylene.
48 = density/density ratio for n-butane.
49 = density/density ratio for isobutane.
50 = density/density ratio for n-butylene.
51 = density/density ratio for isobutylene.
52-59 = Reserved.
60-79 = free.
Factors 80 - 99 are to be used for enthalpy/enthalpy

ratio type algorithms.
81 = enthalpy of water.
82 = enthalpy of steam.
83-89 = Reserved
90-99 = free
Factors 100 - 119 are to be used for viscosity/viscosity

ratio type algorithms.
100 = Viscosity/Viscosity ratio of lubricating oils.
101-109 = Reserved.
110-119 = free.
Factors 120 - 139 are to be used for viscosity/viscosity

index type algorithms.
120 = Viscosity/Viscosity Index of lubricating oils.
121-129 = Reserved.
130-139 = free.
Factors 140 - 199 Reserved.

Factors 200 - 255 free.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

632
PROPERTY BLOCK
Cas RCas
Mode
Input 0
Pointer ROut
Input Select Set Point
Word 0
Property
(Set Point) 0) Q in =ai0 (SP+bi0)
Or
1) Q in = ai0 /(SP+bi0)
--```,``-`-`,,`,,`,`,,`---
Input 2
Input
Output 0
Word 1
2Phase Output
Algorithm (Discrete) Word 0
Actual
Temperature T = ai1 *
(Input 1+ bi1)
Output 0 =
0) (Q out/ao0) -bo0
P= ai2 * Or
Input 1
Output 1
Input (Input 2 + bi2) 1) (ao0/Q out) - bo0
Word 2 Output
Word 1
f = Output 1=
Actual Qin/Qout or Qout/Qin
Pressure
Figure 46: Properties Conversion, Figure 1, Property Block
SP-50 User Layer Technical Report Signal Capture

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
633
Signal Capture
Editor's Note: This function block description has been accepted by the User
Layer Subcommittee as a technical report paper but it has not yet been edited.
All of the functionality of the block has been defined but the details of the
parameter definitions and the pseudocode are yet to be done.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
BASIC ALGORITHM:
- A string of analog samples of Input #1 are captured into a table that
can be read over the Field Bus.
- The total table length will be equal to the maximum single Field Bus
--```,``-`-`,,`,,`,`,,`---
message length.
- The Set Point is a discrete to start the capture. The block is
sensitive to the rise, not the state, of this value.
- The first entry in the table will be a time stamp for the first table
sample.
- The second entry will be the number of samples after the time stamp.
- The third entry will be a logical that, when set, indicates that the
table was not cleared at the time of the time stamp.
- The rest of the table will be sample values. The values will be
inserted from the time stamp end toward the far end.
- The values will be 32 bit floating point numbers and set to NAN if
Input #1 is NAN or Bad.
- When the table fills, the Output will be set. The Output could be
used to trigger another Capture block.
ALGORITHM OPTIONS:
- CIRC = Discrete: set if data capture can be triggered without the
previous data being cleared.
- DS = Discrete: set indicates that the start of the capture should be
delayed after the SP rises (see below).
STANDARD BLOCK FUNCTIONS:

- Modes: not IMan nor ROut - Set Point Limits: none
- Hardware Pointers: none - PV Pointer: Input #1
- Bit Pointers: none - Output Limits: none
- Cascade Structure: yes - Boolean Operators: none
- By-pass: yes

634
USAGE NOTES:
- One of these blocks can be used alone as a triggered capture and
hold.
- One of these blocks can be used alone as essentially a circular list.
Input Word 0 would point to its own Output and CIRC would be set.
When the table filled, the Output would be set. That would start a
new cycle resulting in a new time stamp and the restart of the sample
counter. Since the restart was immediate, the table would not be
cleared; the logical would be set so users would know that the values
ahead of the counter were left from the previous cycle.
- One of these blocks can be used as an event monitor. The block would
be running as a circular list; it will freeze a configured amount of
time after the event is detected by Input #2.
- Two or more of these blocks could to used as a set - each triggering
the next when they fill. The filling of the table is recorded in the
event buffer. A master device would monitor the events and, when one
is reported, read the table's contents and set CLEAR.
- Node Parameters:
+ F = seconds = Block calculation cycle time
+ CS = Integer
= Skip cycles between samples (must be in Man to change)
+ FMTD = seconds = Force Manual Time Delay
= delay time between the setting of Input #2 and the
transition to Man.
+ Input 0 = SP
= discrete to signal start of capture (rise driven).
+ Input #1 = SAMPLE(n) = sample source
+ Input #2 = FORCE
= discrete to signal "force manual" (rise driven).
+ Output = OUTPUT(n-1) = set when the last value is captured
+ CLEAR = Bit = Set when table to be/has been cleared
+ CAP = Bit = Set when SP has been triggered
+ FORCE = Bit = Set when force manual has been triggered
+ CNT = Skip counter
+ FMCNT = Force manual counter
+ INDEX = Index into table
Modes:
- LO State fed back by Bit 3 of the status of the Output when the block
is not in LO mode will cause an alarm but not LO Mode. If the block
is not in LO mode, the algorithm will not write the state of the
Output until Bit 3 is reset.
- The block can be set to LO mode. In that mode, the block will act as
if it is in Man but the Output can not be manipulated.
- In Manual, the contents of the table are held. The Output can be
manipulated.
- Transition from O/S, LO, or Man to Auto, Cas, or RCas sets CLEAR
- Auto mode immediately sets the SP and triggers the data capture
- In Cas or RCas mode, the rising edge of the SP triggers the data
capture.

--```,``-`-`,,`,,`,`,,`---

//^:^^
635
Table Clearing:
- The table is cleared to NAN's, the time, count, and logical are all
set to zero's, and the Output is reset when the algorithm finds
CLEAR set.
Set Point:
- The Set Point will include several unique provisions:
+ The algorithm will only be sensitive to the rising edge of the
SP, not the state or the falling edge. If the block is
capturing, capture will not stop if the SP value becomes reset.
+ The block is designed to be able to work in a set. To do that,
the block must provide for two special factors. Given two
blocks in the same node, one of them is located at a lower block
location. When that one triggers its mate, the trigger is
received in the same node cycle. That trigger should be delayed
one cycle but the trigger from the block at the higher location
should not be delayed. Secondly, if the skip cycle is being
used, there would be no skip between the last sample of one
block and the first sample of the next block.
The block will include one option to correct for both of these
factors. If the "Delay Start" option is set, the following
corrections will be applied to the SP value by the algorithm.
The corrections will be inserted in the fetched Input Word 0
value. First, a one-cycle delay will be inserted in the Input
Word 0 value if it is fetched from bit 0 of the Output Word 0 of
a block in the same node AND at a lower block location. Second,
and independent of the location of the other block, the value
will be further delayed by the number of skip cycles (CS)
defined in the data base. Neither of these delays will be
provided to a SP written into the block's data base from the
Field Bus nor when written into a transfer location.
+ A similar situation is encountered when the Input 0 pointer is

configured to the block's own Output. Correction must be made
for the skip cycle. The input pointer will provide this
correction automatically with this configuration.
- The Force Manual Pointer will:
+ be sensitive only to the rising edge of the signal; once it has
triggered the following action, its state is ignored until the
block is taken out of Man mode.
+ Upon a rise in this pointer's value, the block will go to
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Auto mode and start to capture values unless:

1) FMTD = 0 OR
2) the block is already capturing
+ It will start a timer with the value in FMTD unless FMTD = 0.
+ When the timer expires or if FMTD = 0, the block mode will be
set to Man but the Output will not be set. An event will be
reported.
+ If the buffer fills before the timer expires, the block will
start a new cycle immediately, the mode will not change, the
Output will not be set, the table will not be cleared, and no
event will be reported.
Communication Usage Aids:

- There will be two sets of parameters that will be read at high
frequency by "master" devices. They are:
+ The block calculation cycle time (seconds) (F), the skip
frequency (CS), and the number of samples in the table.
+ The total table.
These two sets of parameters should be set up to aid that frequent
reading.

--```,``-`-`,,`,,`,`,,`---

636

+ If Input #1 has a value of NAN or its status byte shows a Bad
status, then the stored value is NAN and the block continues
running.
+ If Input 0 or #2 is Bad, the Last Good Value is used.
+ Ignore the status of the fetched Output except for Bit 3 (LO).
If this bit is set while this block is not in LO mode, then
force an Alarm and do not write the Output until Bit 3 resets.
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
637
Signal Characterizer
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
BASIC ALGORITHM:
- Output is a non-linear function of the Input as determined by a
table lookup and linear interpolation. The table can include up to
10 breakpoints (i.e., 11 sets of x/y values).
- Will add the low set point limit and the corresponding output limit
to the set of 11 points if possible
- Will add the high set point limit and the corresponding output limit
to the set of 11 (or 12) points if possible (hence, a 13-point curve
is possible)
- Passes anti-windup information and initialization if possible.
ALGORITHM OPTIONS: none

- Cascade Structure: yes - By-pass: yes, Input to Output
- Modes: all except LO - Output Target: yes
- Set Point Limits: yes - Output Limits: yes
- "PV Pointer": yes, default - Pointers to hardware: no
to Output

- Initialization done if possible - determined based on the shape of
the x-y curve.
+ 11 pairs of Input and Output values.
Point # In Out
x In(x) Out(x) | o o
------- ------ ------- | o
0 In(0) Out(0) Out | o
1 In(1) Out(1) | o
. . . | o o o
. . . | o o
10 In(10) Out(10) o---------------------------------
In
SP-50 User Layer Technical Report Signal Characterizer

--```,``-`-`,,`,,`,`,,`---

638
+ Input = used as Input into In/Out curve ("x" axis)

Input(n)
+ Output = Output of the block (after output limits)
= Output before limits from the "y" axis
= Out(n-1)
@ Cant_Init = Discrete indicating that initialization is not
possible (set = can not initialize)
@ Can_Extend = integer indicating that:
0 = no extension
1 = Low Set Point limit added
2 = High Set Point limit added
3 = Both Set Point limits added
is applied.

- Value of In(x) must be > Value of In(x-1)
- If any value of [Out(x) - Out(x-1) ] is zero or switches sign from
the previous change, the algorithm will not do initialization nor
anti-windup protection.
- If the above tests are successful, the 11 point table will be
expanded to 12 or 13 points by adding one or both of the pairs of Set
Point and Output limits if they properly extrapolate the curve. The
following description uses subscripts that imply that the extensions
were not possible.
- In forward operation, the Output is calculated from the Input as:
+ If Input < In(0) , then Output = Out(0) )
+ If Input > In(10) , then Output = Out(10)
+ If Input is within range, then
Output = Out(x) + [Input #1 - In(x) ] *
[Out(x+1) - Out(x) ]/[In(x+1) - In(x) ]
where x is chosen such that In(x) and In(x+1) bracket
Input #1.
- If initialization is possible and timely, Input is calculated from
the output.
If Output < any Out(x) , then Input = In(x) corresponding to
the minimum Out(x)
If Output > any Out(x) , then Input = In(x) corresponding to
the maximum Out(x)
If Output in range, then Input #1 = result of linear
interpolation between the
bracketing points
- If initialization is not possible, bit 5 (no path to the process) in
the CASCADE status bytes will be set.

- All standard NaN and status bit responses and setting.
- Bits 4 and 5 (path to process failed and no path to process) passed
directly from the Output to the Input except that bit 5 is set if
the algorithm can not initialize. Bits 6 and 7 (ATW's) are fully
supported in the Input if initialization is possible. If not, only
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
the mode of the block and the Set Point limits are reflected in the
ATW's set for the Input.
--```,``-`-`,,`,,`,`,,`---

639
Note: any of the 22 data items can be changed at any time.
block is not O/S.
- Bring in the pre-fetched and on-node reads with their status bytes
- The CASCADE procedure will have determined the value of SP(n) and
its status byte.
- If bits 0 and/or 1 of the Input #1 status byte are set (SP = can't
communicate or is "bad"), and/or if the value of Input #1 = NaN,
THEN set the Man mode bit in the mode word of this block and clear
all lower priority bits in the mode byte.
- If the LO mode bit is reset, THEN:
value status byte.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
- Execute the Data Base Validity Check - see below
- If all of the following conditions are true, then reset bit 5 in all
CASCADE transfer value status bytes and in the SP status byte:
+ Bit 4 of the Output status byte (no path to process, failure)
is reset
+ Bit 5 of the Output status byte (no path to process) is reset
+ Cant_Init = 0
below}
below}
--```,``-`-`,,`,,`,`,,`---
- If bit 2 of Input #1 (not effected by the process) is reset, then

reset bit 2 of the Output status byte.
- If By-pass is set, then OBL(n-1) = Input #1
- If By-pass not set, then Execute the Forward Calculation Procedure
{see below}
steps for ATW-l
+ Change all following references from ATW-h to ATW-l if
Out_Decrease = 10
- Output:

640

ELSE:
Out(n-1) = OBL(n)
ATW-h = set
ATW-l = set
END IF
END IF
+ Set ATW-h if SP(n) above or equal to high SP limit
+ If Cant_Init = set, then reset ATW-h
- END
D@Subtitle = ATA BASE VALIDITY CHECK:

- The following procedure is only intended to be a worst case existence
proof and to convey the functional concept needed here. Note,
however, the absence of equalities in the comparison in the checking
loop.
Set In_Increase = 0
Set Out_Increase = 0
Set Out_Decrease = 0
Set Min_Out = Out(0)
Set In_Min_Out = 0
Set Max_Out = Out(0)
Set In_Max_Out = 0
For i = 1 to 10
If In(i) > In(i-1) then INCR In_Increase
If Out(i) > Out(i-1) then INCR Out_Increase
If Out(i) < Out(i-1) then INCR Out_Decrease
If Out(i) < Min_Out then Min_Out = Out(i) : In_Min_Out = i
If Out(i) > Max_Out then Max_Out = Out(i) : In_Max_Out = i
Next i
If In_Increase <> 10 THEN:
set node alarm
By_Pass = 1
END IF
If Out_Increase = 10 or If Out_Decrease = 10 THEN:
Cant_Init = 0
Note: at this point, the extra two sets of points represented
by the Set Point Limits and the Output Limits will be
checked. Either or both will be added to the curve if
they extrapolate the curve without causing a sign
change in the first derivative of the curve. Note that
Out_Increase indicates whether the low limits pair
together or whether the low set point limit pairs with
the high output limit. This Algorithm description
assumes that this section of procedure will adjust the
parameters set in the immediately above procedure.
ELSE Cant_Init = 1
END IF
IF Output pointer not active, set Cant_Init
END IF
RETURN

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
641

- If there is an active Output pointer AND:
1) If bits 0 or 1 of the status byte of Out(n-1) are set (Output
can't communicate or "bad"), or if Out(n-1) = NaN
or ROut
5) First pass after recovering from a bad value or status (either
can't communication or "bad") for Input #1 (SP).
other mode bits.
- Execute the Back Calculation Procedure
- IF only (4) and/or (5), THEN RETURN to the Algorithm operation above,
--```,``-`-`,,`,,`,`,,`---
BACK-CALCULATION PROCEDURE:
- The following is a simple routine, using variables calculated in the
Data Base Validity Check procedure, to outline the procedure to use
to initialize the SP given an Output.
IF Cant_Init is reset THEN:
IF Out(n-1) <= Min_Out then SP(n) = In(In_Min_Out)
IF Out(n-1) >= Max_Out then SP(n) = In(In_Max_Out)
ELSE do simple linear interpolation to find SP(n) for
the current value of OBL(n-1)
END IF
END IF
RETURN
FORWARD CALCULATION PROCEDURE:

- The following is a simple routine that outlines the procedure to use
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
to calculate the Output given the current value of Input #1.
If Input #1 < In(0) THEN OBL(n-1) = Out(0)
If Input #1 > In(11) THEN OBL(n-1) = Out(11)
ELSE do linear interpolation between the bracketing points to find
OBL(n-1) from Input #1
END IF

- Call the Back Calculation Procedure
- END


642
- OBL(n-1) = Out(n-1)
- Call the Back Calculation Procedure
- END

- Bits 4 and 5 (path to process failed and no path to process) passed
directly from the Output to the Input except that bit 5 is set if
the algorithm can not initialize. Bits 6 and 7 (ATW's) are set in
the Input based on:
IF initialization is possible, THEN
Start with the corresponding bits of the Output
Adjust for Output limits
Adjust for the slope of the curve
Adjust for the mode of the block
Adjust for the Set Point limits
ELSE
Start with the ATW bits reset.
Adjust for the mode of the block
Adjust for the Set Point limits
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*
643
Signal Selector
BASIC ALGORITHM:
- Select high, low, middle, or first good of up to three inputs.
- Input #3 to force the selection to a particular one of the three
or to exclude any of the three.
- Pass initialization and ATW to any/all of first three inputs.
ALGORITHM OPTIONS:
- Select algorithm version
- Force the Output = last good value and "good" if no good inputs.

- Modes: all except LO - Output Target: yes
- Set Point Limits: no - Output Limits: yes
to Output

- Can support initialization of all three inputs.
- Inputs #1 and/or 2 must use "Writeable" or "Required Writeable"
pointers to support initialization and antiwindup.
+ ALGO = algorithm code
0 = select low good input
1 = select high good input
2 = select first good input
4 = select middle of 3 good inputs or high of 2 good inputs
5 = select middle of 3 good inputs or low of 2 good inputs
6 = select middle of 3 good inputs or average of 2 good
inputs
7 = select middle of 3 good inputs or first good of 2
Note: in all cases, Output = good input if only one
input is good.
+ GOOD = discrete
= if set, leave the last good Output value (marked "good")
SP-50 User Layer Technical Report Selector

--```,``-`-`,,`,,`,`,,`---

644
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
if all Inputs are "bad"
+ B(x) = Bias term for integral limiting for each input
where x = |1, 2, and 3|
+ Input 0 = Input(0) = SP(n)
+ Input #3 = FORCE
= 7-Bit string
= Force selection bit string
7 bits - bit 0 set if Input 0 forced to be selected
1 set if Input #1 forced to be selected
2 set if Input #2 forced to be selected
3 set = block in manual
Note: More than one Input forced to be selected implies that
the ALGO rules will be followed on the forced Inputs.
Bits 1, 2, and 3 all set simultaneously will result in
the same action as if bits 1, 2, and 3 were all reset.
4 set if Input 0 forced to not be selected
5 set if Input #1 forced to not be selected
6 set if Input #2 forced to not be selected
Note: Bits 4, 5, and 6 all set will force the Output to the
last good value and either "Bad" or NOT "Bad"
--```,``-`-`,,`,,`,`,,`---
depending on the GOOD option.
@ Selection status nibble:
4 bits - all bits reset = the algorithm is running but
all inputs are "bad", "NaN",
or forced to be "not selected"
bit 0 set if Input 0 selected
1 set if Input #1 selected
2 set if Input #2 selected
3 set if Mode = ROut, Man, IMan, or O/S
= output of the block before output limiting
is applied.
@ B(n-1) = Bias term for the selected value at last
execution

- Inputs 0-2 "Bad":
+ Details in algorithm definition above
+ In general:
"Bad" and "NaN" inputs can be totally avoided.
Middle of three degrades according to algorithm choice
Output = "bad" only if all three Inputs are Null,
"bad", NaN or forced to "not selected" but,
optionally, the last good Output can be left.
In Bypass, if Input 0 is "Bad" or "NaN", the last Output value
is retained and left NOT "Bad" if GOOD = set, ELSE set "Bad".
- Input #3 "Bad":
+ Status bytes of all 7 bits OR'ed together into one status byte
+ IF "Bad", then its last good value is used. In addition, the
Output value is marked "Bad" if the GOOD option is reset.
- Bit 2 of the Output (from process) is set equal to the corresponding
bit of the selected Input.
- Status Bits 4 and 5 (Path to process failed and no path to process)
are passed directly from the Output to all Inputs. However, Bit 5 is
set in Inputs that do not have a type of pointer that can pass
initialization.
- Bits 6 and 7 (antiwindup bits, the "ATW" bits) of the Output are

645
corrected for Output limits and the mode of the block, then passed to
the Set Point and all three of the Inputs. All unselected Inputs
that are more than their bias term away from the selected Input or
the Inputs being averaged will also have one of their two bits
automatically set: the ATW that can prevent the unselected Input
from going further away from the selected value(s) is the one that is
set. Inputs not selected because they are "Bad" or "NaN" will have
both of their ATW bits set.
block is not O/S.
- Set Selector Status nibble = 1
- If all three of the pointers for the Inputs are Null, set the O/S
bit in the mode byte of this block.
- Bring in the prefetched and on-node reads with their status bytes
- The CASCADE procedure will determine the value of SP(n) and its
status byte.
- For each of the three Inputs, set NaN in their value if bit 0 (can't
communicate) and/or bit 1 (bad value) is set and/or their pointer
is Null.
--```,``-`-`,,`,,`,`,,`---
- If the LO mode bit is reset and bit 0 in the Force Selector is reset,
THEN:
value status byte.
- If bit 4 of the Output status byte (no path to process, failure)
is reset and if bit 5 of the Output status byte (no path to process)
is reset, then reset bit 5 in all CASCADE transfer value status bytes
and in the SP status byte.
- If bit 0 in the Force Selector nibble is set, set the Man mode bit
below}
below}
- Select Input:
Ignore any inputs with a "NULL" pointer
OBL(n) = the value of the selected input = OBL(n-1)
Note: Bit 2 of the selected input status byte (not effected
by the process) must be carried with the OBL(n) value
and set in bit 2 of the output. Bit 2 should be set
in the initialization of OBL(n) here so it will be
set if the initial value carries through to the output.
B(n) = the bias term for the input = B(n-1)

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
646
Then:
IF Bypass is turned on, THEN:
OBL(n) = Input #1
B(n) = B(1)
ELSE IF Force selection is indicated for only one input AND
that input is good, THEN:
OBL(n) = it
B(n) = its bias
--```,``-`-`,,`,,`,`,,`---
ELSE IF Force selection is indicated for more than one input

AND any are good, THEN:
IF all three are forced and good and algorithm is
middle of three, THEN:
select the middle one
OBL(n) = it
B(n) = its bias
ELSE IF at least two are both forced and good and
the algorithm is high select, THEN:
Select the high one
OBL(n) = it
B(n) = its bias
ELSE IF at least two are both forced and good and
the algorithm is low select, THEN:
select the low one
OBL(n) = it
B(n) = its bias
ELSE IF any are both forced and good, THEN:
select the first good one
OBL(n) = it
B(n) = its bias
END IF
ELSE IF Force selection is on (if you get here, it indicates
there are nothing but "bad" inputs)
THEN:
OBL(n) = "bad".
ELSE IF No Force selection bit is set, THEN:
IF Algorithm = high select and there is a good input,
THEN:
select the highest good input
OBL(n) = it
B(n) = its bias
ELSE If Algorithm = low select and there is a good
input, THEN:
select the lowest good input
OBL(n) = it
B(n) = its bias
ELSE If Algorithm = middle of three and there are three
good inputs, THEN:
select the middle one
OBL(n) = it
B(n) = its bias
ELSE If there is at least one good input, THEN:
select the first (i.e., Input #1, then #2 ..) good
input
OBL(n) = it
B(n) = its bias
END IF
END IF
- Set Selection Input number in the Selection Status nibble with the
first bit reset; leave all zero's if the output is bad or defaulted
to OBL(n-1)
- IF the Selection Input number = 2 or 3, THEN:
If the Selected Input has a writeable pointer, THEN:
Reset bits 6 and 7 (ATW's) in the status byte of the
selected Input.
- Output:

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
647

ELSE:
Out(n-1) = OBL(n)
ATW-h = set
ATW-l = set
END IF
END IF
- ATW operation:
steps for ATW-l
+ Determine wind-up direction for unselected good inputs:
The direction of movement that would cause the unselected
input to be further away from the selected input than it is
already.
+ For those that are winding-up high:
@ Start by setting ATW-h equal to bit 6 (Wound up high) of
the status byte from the Output pointer
--```,``-`-`,,`,,`,`,,`---
Note: The following four statements imply that Input
#1's ATW-h is to be placed in all of RCas, Cas,
and SP status bytes.
@ Set ATW-h if OBL(n) above or equal to high output limit
@ Put ATW-h in the ATW bit of the selected input's status
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
byte.
@ For each non-selected good input (x):
limit = OBL(n) + B(n) + B(x)
IF ATW-h = set OR IF Input(x) > limit, THEN set high
ATW of the status byte of Input(x)
@ For any "bad" inputs, set both ATW bits of their status
byte.
- If RCas is not the highest priority mode bit set, set both ATW bits
in the RCas transfer location status byte.
- If Cas is not the highest priority mode bit set, set both ATW bits
in the Cas transfer location status byte.
- END

- IF there is an active output pointer AND:
1) If bits 0 or 1 of the status byte of Out(n-1) are set (Output
can't communicate or "bad"), or if Out(n-1) = NaN
or ROut
other mode bits
- If not (1) THEN: OBL(n-1) = Out(n-1)
- RCas and Cas transfer value locations = OBL(n-1)
- If Input #2 has a Writeable or a Required Writeable pointer, then
Input #2 = OBL(n-1)
Input #3 = OBL(n-1)
- B(n) = 0

648
--```,``-`-`,,`,,`,`,,`---
- IF only (4), THEN RETURN to the Algorithm operation above

- Set bit 0 of the Selection Status nibble
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
- END

- If the Output has an active pointer, THEN:
Out(n-1) = the last good value of the Output
- RCas and Cas transfer value locations = Out(n-1)
Input #2 = Out(n-1)
Input #3 = Out(n-1)
- B(n) = 0
- END

- RCas and Cas transfer value locations = OBL(n-1) = Out(n-1)
Input #2 = Out(n-1)
Input #3 = Out(n-1)
- B(n) = 0
- END

649
Splitter
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

BASIC ALGORITHM:
- Signal splitter algorithm with one input, two output cascade
structure. Input 0 provided with:
+ anti-windup protection
+ initialization if possible
+ initialization value from Input #1 if present, else from Outputs
ALGORITHM OPTIONS:
- Output 0 = a * Input 0 + b
Output #1 = c * Input 0 + d
+ where:
@ x decays to Vx at a rate set by tx
where x = |a, b, c, and d|
+ and:
@ a, b, c, and d are read-only values
@ Vx are user set where x = |a, b, c, and d|
@ a zero value for tx indicates that Vx is to be used as
the fixed value of x where x = |a, b, c, and d|.
@ if Output 0 pointer not active, then ta = tb = 0
@ if both ta and tb > 0 then tb = 0
@ if Output #1 pointer not active, then tc = td = 0
@ if both tc and td > 0 then td = 0
@ a negative value for tx is changed to zero where x = |a,
b, c, and d|.

- Modes: all ex. LO and ROut - Output Target: yes (2)
- Set Point Limits: yes - Output Limits: yes (2)
to Input 0

- Can have two Outputs, both in cascade structures below Input 0
(the object of the algorithm).
- Discrete input can force IMan mode.
- Can accept an input value that is the value to use for
initialization.
SP-50 User Layer Technical Report Splitter

--```,``-`-`,,`,,`,`,,`---

650
- Usage Notes:
Two examples of the use of this algorithm:
+ To split the signal from one control block for two valves to
achieve split-range control of the valves. For example, if
valve "A" is to go from full open to full closed as the control
signal goes from 0 to 50%, then valve "B" goes from full closed
to full open as the control signal goes from 50% to 100% (valve
A staying closed), the splitter algorithm values would be:
@ Given that Valve "A" is on Output 0 and Valve "B" is on
Output #1 and that the engineering units are percent of
scale, then:
Va = -2.
Vb = +100.
Vc = 2.
Vd = -100.
Both sets of Output limits might be -5 and +105%
ta = tc = at least four times the reset time of the
controller.
t b = td = 0
Note: the coefficients a and c are chosen for adjustment during
--```,``-`-`,,`,,`,`,,`---
initialization in order to give the least variation in

gain during the decay (balancing) time.
+ To allow one primary control block to simultaneously manipulate
two secondary control blocks, both in the cascade structure.
An example would be two distillation columns taking feed from
one feed drum. The feed drum might have a single level
controller that should cascade to both of the tower feed flow
rate controllers. The splitter algorithm values might be:
@ Given that the engineering units are percent of scale,
then:
Va = 1.
Vb = 0.
Vc = 1.
Vd = 0.
Both sets of Output limits might be -5 and +105%
t a = tc = 0
tb = td = at least four times the reset time of the
primary controller
Note: the coefficients b and d are chosen for adjustment during
initialization in order to give the least variation in
gain during the decay (balancing) time.
- Node Parameters:
+ Va and Vc - in units of (EU of output / EU of input)
+ Vb and Vd - in units of EU of output
+ ta, tb, tc, and td - in units of minutes
+ TOL = minimum value of a, c, or Input #1 to use in
initialization calculation (alarm if hit).
+ Input 0 = used as "Set Point" in algorithm
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
= SPn
+ Input #1 = used as initialization value if the block is in
initialization and if Input #1 pointer not null.
= In1n
+ Input #2 = 1 Bit discrete to force initialization
= In2n
+ Output 0 = Output 0 of the block (after output limits)
= Out0(n-1)
+ Output #1 = Output #1 of the block (after output limits)
= Out1(n-1)

651
@ a, b, c, and d
= output 0 of the algorithm before output limiting
was applied.
= output #1 of the algorithm before output
limiting was applied.

- CASE 0: Input #2 pointer Null
Output 0 pointer not active
Output #1 pointer not active
+ No Cascade initialization (nor IMan mode) can occur
+ Set x to Vx where x = |a, b, c, and d|
+ Forward calculation only:
Output 0 = a * Input 0 + b
+ IF the pointer for Input #1 is not Null, then the SP is
initialized to the value of Input #1 during block
initialization ELSE the last value of SP is used.
- CASE 1: Input #2 pointer NOT Null
+ Neither Output can force initialization but Input #2 can.
+ IF algorithm in initialization, THEN
Use Input #1 value to initialize SP if Input #1 pointer
not Null, ELSE use last good value of SP.
+ Forward calculation:
- CASE 2: Output 0 pointer active.
Output #1 pointer not active.
+ Output #1 can not force initialization
+ Decay x to Vx depending on tx > 0 where x = |a, b|
+ Set x to Vx where x = |c and d|
+ IF algorithm not in initialization, THEN
ELSE
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Set x to Vx where x = |a, b, c, and d|
IF Input #1 pointer not Null, then SP = Input #1 AND
IF ta > 0 then calculate a (using SP = TOL if SP < TOL)
IF tb > 0 then calculate b
ELSE SP = (Output 0 - b)/a (using a = TOL if a < TOL)
ENDIF
Output #1 = c * SP + d
ENDIF
- CASE 3: Output 0 pointer not active.
Output #1 pointer active.
+ Same as CASE 2 except exchange (Output #1, c, and d) for

(Output 0, a, and b) in the description.
+ Decay Vx depending on tx > 0 where x = |a, b, c, and d|
+ IF (Output 0 AND Output #1 not both forcing initialization) AND
the algorithm not initializing, THEN
Forward calculate either Output that is not forcing
initialization
Calculate one of the equation coefficients for either Output
that is forcing initialization if that Output has a
tx > 0
ELSE

--```,``-`-`,,`,,`,`,,`---

652
x = Vx where x = |a, b, c, and d|

IF ta > 0 THEN
a = (Output 0 - b)/SP (IF SP < TOL, SP = TOL)
IF tb > 0 THEN b = Output 0 - a * SP
IF tc > 0 THEN
c = (Output #1 - d)/SP (IF SP < TOL, SP = TOL)
IF td > 0 THEN d = Output #1 - c * SP
ELSE
SP0 = (Output 0 - b)/a (IF a < TOL, a = TOL)
SP1 = (Output #1 - d)/c (IF c < TOL, c = TOL)
SP = (SP0 + SP1 ) / 2
The rest is the same as immediately above.
ENDIF
ENDIF

- Status bits 4, 5, 6 and 7 (path to process failed, no path to
process, and the two anti-windup bits) are set on the basis that
either of the two Outputs can provide a control path, both are not
required.
- CASE 0: Input #2 pointer Null
+ No Cascade initialization (nor IMan mode) can occur; forward
calculation only.
+ The tx are ignored.
+ Reset Bit 4 (path to process failed) of Input 0's status byte
+ Bit 5 (no path to process) will be set in the status byte of
Input 0.
+ IF the pointer for Input #1 is not Null, then the SP is
initialized to the value of Input #1 during block
initialization ELSE the last value of SP is used.
+ The antiwindup bits of Input #1 will be set based on:
@ start with the ATW bits of each Output reset
@ adjust ATW bits of Output 0 for its Output limits
and the sign of a. Set both bits if Output 0's pointer
is Null.
@ adjust ATW bits of Output #1 for its Output limits
and the sign of c. Set both bits if Output #1's pointer
is Null.
@ AND the two pairs of adjusted ATW's together.
@ adjust result for the mode of the block, and the
set point limits.
- CASE 1: Input #2 pointer NOT Null
+ Neither Output 0 nor Output #1 can force initialization
+ The tx are ignored.
+ Reset Bit 4 (path to process failed) of Input 0's status byte
+ IF (|a| < TOL OR Output 0's pointer is Null)
AND (|c| < TOL OR Output #1's pointer is Null)
THEN Set Bit 5 (no path to process) of Input 0's status byte.
ELSE Reset it.
Determine Input 0 ATW bits as in CASE 0.
+ IF algorithm in initialization, THEN
Use Input #1 value to initialize SP if Input #1 pointer
not Null, ELSE use last good value of SP.
Set ATW bits of Input 0.
+ Calculate Output 0 = a * Input 0 + b
+ Calculate Output #1 = c * Input 0 + d

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
653
Output #1 pointer not active.

+ Output #1 can not force initialization
+ Decay x to Vx depending on tx > 0 where x = |a, b|
+ Set x to Vx where x = |c and d|
+ Set Bits 4 and 5 (path to process failed and no path to process)
of Input 0's status byte = bits 4 and 5 in Output 0's status
byte except set bit 5 (no path to process) if |a| <= TOL.
Calculate Output 0 = a * Input 0 + b
Calculate Output #1 = c * Input 0 + d
Determine Input 0 ATW bits from ATW bits of Output 0, its
Output limits, the sign of a, the mode of the block, and
the set point limits.
ELSE
a = Va
b = Vb
IF ta > 0 then calculate a (using SP = TOL if SP < TOL)
IF tb > 0 then calculate b
ELSE SP = (Output 0 - b)/a (using a = TOL if a < TOL)
ENDIF
--```,``-`-`,,`,,`,`,,`---
Output #1 = c * SP + d
ENDIF
- CASE 3: Output 0 pointer not active.
+ Same as CASE 2 except exchange (Output #1, c, and d) for
(Output 0, a, and b) in the description.
+ Decay Vx depending on tx > 0 where x = |a, b, c, and d|
+ Set Bits 4 and 5 (path to process failed and no path to process)
of Input 0's status byte based on:
@ XOR corresponding bits in Output 0's status byte with 11B
@ XOR corresponding bits in Output #1's status byte with 11B
@ OR the two results from above, then XOR with 11B.
@ Set bit 5 if |a| < TOL AND |b| < TOL.
+ IF (Output 0 AND Output #1 not both forcing initialization) AND
the algorithm not initializing, THEN
Forward calculate either Output that is not forcing
initialization
Calculate one of the equation coefficients for either Output
that is forcing initialization if that Output has a
tx > 0
Determine Input 0 ATW bits:
@ adjust ATW bits of Output 0 for its Output limits
and the sign of a.
@ adjust ATW bits of Output #1 for its Output limits
and the sign of c.
@ AND the two pairs of adjusted ATW's together.
@ adjust result for the mode of the block, and the
set point limits.
ELSE
x = Vx where x = |a, b, c, and d|
IF ta > 0 THEN
a = (Output 0 - b)/SP (IF SP < TOL, SP = TOL)
IF tb > 0 THEN b = Output 0 - a * SP
IF tc > 0 THEN
c = (Output #1 - d)/SP (IF SP < TOL, SP = TOL)
IF td > 0 THEN d = Output #1 - c * SP
ELSE
SP0 = (Output 0 - b)/a (IF a < TOL, a = TOL)
SP1 = (Output #1 - d)/c (IF c < TOL, c = TOL)
SP = (SP0 + SP1 ) / 2
The rest is the same as immediately above.
ENDIF
ENDIF

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
654
Timer

BOOLEAN OPERATOR
BIT POINTERS
EXPLANATION OF THE TIMER CONFIGURATION
EXPLANATION OF THE TIMER TRIGGER
EXPLANATION OF THE TIMER LOGIC
DISCRETE CASCADE
SUMMARY OF ALGORITHM OPERATION
OVERVIEW OF OTHER STATUS BYTES
DATA BASE DETAILS
Figure 1 - Timer Algorithm
Figure 2 - Timer Logic
BASIC ALGORITHM:
--```,``-`-`,,`,,`,`,,`---
- This algorithm provides four timers, two discrete inputs, two
discrete outputs, and a cascaded analog input that can be used to
calculate the timer setpoints. The timers operate independently;
their setpoints can be independent or based on the one block
setpoint. Bit pointers and Boolean operators are provided to allow
simple discrete manipulations. The timers are triggered by the rise
in the state of any of a configured subset of their inputs.
- See attached figure "Timer Algorithm".
- Two 16 bit Input Words and two 16 bit Output Words are provided.
- Analog Input 0 (in a cascade structure) is the base timer set point.
- Eight Boolean Operators are available.
- Four generic timers, each driving defined logic (see "Timer 0
Logic").
- The data flow is configured using "Bit pointers" that can connect
to bits in Input Words, Boolean Operators, Output, Output Words,
and Logical Node Words.
- Each Timer is triggered by a rising edge of any discrete in a
configured subset of the 16 inputs to all four timers. A timer
resets if all of the triggering inputs fall before the time expires.
- Timer Logic sets Output (16 bits).
- Supports all status byte information and will pass discrete cascade
information upward through input bits under certain conditions.

- Modes: all except ROut - By-pass: no
(Man resets all timers, - Set Point Limits: yes
changes to Auto) Low Limit >= 0
- Hardware Pointers: none - PV Pointer: yes, default to
SP-50 User Layer Technical Report Timer

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
655
- Bit Pointers: yes Timer 0, Remainder

- Cascade Structure: yes - Output Limits: no
- Boolean Operators: yes: 8
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
ALGORITHM OPTIONS:
none.

- Block can be involved in seven cascades at once:
+ Analog cascade into Setpoint: no connection to outputs.
+ Up to 6 discrete cascades can flow through Input/Output words.
BOOLEAN OPERATOR:
The Timer Block will include eight Boolean operators that can be used to
operate on discretes before they are fetched by the Timer Input bit pointers.
For example, two input discretes may have to be "OR"ed together before the timer.
Note that the Boolean inputs can come from the bits of Input Words 1 or 2 or from
the outputs of previous Boolean operators and reflect fresh values. In addition,
they can come from any bits of Output or either Output Word but, if they do, the
value may reflect the value as of the previous cycle or a value written by
another block.
The 24 configuration words are reported under one parameter; the three words
defining operator 0 are reported first and the operator definition word is
reported first in each set of three.
All eight Boolean Operators will be executed, in order starting with Operator
0, before any of the timers or their input bit pointers are executed.
BIT POINTERS:
Bit pointers are used for configuring:
1) the 16 connections to the 4 timers (In0 - In3 in the "Timer 0
Logic" drawing).
2) the connections from Output (16 bits) to Output words or to the
Logical Node Words.
The bit pointer configuration words are grouped in the two sets described
above (16 in each of set). Each set is identified by 1 parameter name. The bit
pointer configuration word for bit 0 will be reported first.
--```,``-`-`,,`,,`,`,,`---
EXPLANATION OF THE TIMER CONFIGURATION:
The data base values for each timer (in addition to the bit pointer
configuration) are:
1) The values a and b where the timer initial value = a * SP + b
2) The remaining time on the timer (Remainder)
Note that the value of the block Setpoint that is used in (1) above is the value
during the cycle in which the timer starts.
EXPLANATION OF THE TIMER TRIGGER:

Each of the four timers will have a "Timer Trigger Word", 16 bits each. Each
timer is modeled as having a second 16 bit word called the "Timer Monitor Word".
The trigger word will be configured to identify which of the 16 timer inputs are
to act as triggers for the timer. Any bit pattern is acceptable where each bit
is associated with an input: a set bit indicates that the timer is to start
timing when that input rises.

656
The block will monitor the states of the timer inputs whose trigger bits are
set. If, in any cycle, one or more of the bits is found NEWLY set, the timer
will start. (A bit will never be considered to be newly set on the first cycle
after a transition from O/S, LO, LO(x), or Man mode). When the timer starts, the
Timer Monitor word will be generated by setting only those bits that correspond
to the timer inputs that:
1) correspond to set bits in the Timer Trigger word
AND
2) are NEWLY set this cycle
In the cycles that follow the starting of the timer, the Timer Input discretes
that correspond to set bits in the Timer Monitor word will be monitored and the
trigger word will be ignored. If any of them reset, their corresponding bit in
the Monitor word will be reset. If all of the bits in the Monitor word become
reset, or if the timer times out, the timer will reset.
The order of the execution of the timers is particularly important. The four
input bit pointers for timer 0 will be executed, then timer 0 will execute using
the then-current states of all 16 timer inputs. The four Output pointers for
timer 0 WILL NOT be executed at this point. Next, the four input bit pointers
for timer 1 will be executed, then timer 1 will execute using the then-current
states of all 16 timer inputs. This is followed by timer 2, then 3. When timer
3 is done, the 16 Output bit pointers will be executed, all at the same time.
When a timer resets, the monitor word will be reset and the triggering inputs
will again be monitored.
EXPLANATION OF THE TIMER LOGIC:

The Timer logic is designed to facilitate the use of this block in discrete
cascades. The timer logic will primarily operate on the first three input
signals, interrupting their new values depending on the timer state. However,
the logic will not force compliance with the requirement that discrete cascade
values must have one, and only one, bit set at a time: the logic only makes it
easy to remain in compliance with that requirement. The discrete cascade flows
from bits in the Input (or Output) Words through the block to the Output Words.
The discrete cascades are independent of the block mode (as long as the block is
not in O/S or LO).
The ladder diagram shown in the sub-drawing "Timer Logic" of the drawing
"Timer 0 Logic" is typical for all four timers. This logic allows the previous
output (labeled "Old Out x") to be held while the timer is running. When the
timer resets, the "new" input passes through the timer contacts.
Input 3 is always passed directly from the In 3 to Output 3 and is also

available as a possible trigger.
- User Set Parameters;
+ Configuration of 8 Boolean Operators.
+ Configuration of 16 timer logic input bit pointers.
+ Configuration of 16 Output bit pointers.
+ a_0 - a_3 = coefficients of the block Setpoint in the equations
to calculate timer Setpoints.
+ b_0 - b_3 = biases in the equations to calculate the timer
Setpoints.
+ Input 0 = Input0(n) = Analog input basic timer setpoint.
--```,``-`-`,,`,,`,`,,`---
+ Input 1 = Input1(n) = up to 16 bit word

+ Output 0 = Out0(n-1) = 16 bit string (automatic write mask)
+ Externally Readable:

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
657
- SP(n-1) = current timer setpoint base

- Output = Out(n-1) = 16 bit string of timer logic output
- Set_0 - Set_3 = timer Setpoints
Note: if the timer is not counting, Set_x would be the
timer's Setpoint as calculated from the block
Setpoint. If the timer is counting, Set_x is the
timer's Setpoint that was used when the timer
started.
- Remainder_0 = Remain0(n-1) = time left on timer 0 (sec.)
+ Not Externally Readable:
- INIT = logical - set indicates that the algorithm is in the
first execution after O/S mode.
- FMAN = logical - set indicates that the algorithm is in the
first execution after Man, LO, or LO(x)
mode.
- Previous cycle Boolean Operator Inputs
- Previous cycle Timer Inputs
--```,``-`-`,,`,,`,`,,`---
DISCRETE CASCADE:
The Timer block will pass status bytes "down" the discrete data flow path,
i.e., from I/O bits through the Boolean Operators, through the Timers, to Output
and on to the Output words no matter how convoluted the path. However, the Timer
block is limited in its ability to pass information "up" a discrete cascade. The
block will consider each of the 16 data paths through the timers, one at a time.
If the Output bit pointer points to an Output Word bit and the input bit pointer
points to an I/O Word bit, then the information will be passed upward directly
and unaltered. The timer contacts will not be considered as an impediment to the
information flow for any of the bits (i.e., when the "Old Out x" value is going
to the timer Output because the timer is running, the wind-up bits WILL NOT be
set).
SUMMARY OF ALGORITHM OPERATION:

- Three Input words and two Output words fetched if necessary
- In RCas mode, the Set Point is obtained from the RCas transfer
location.
- In Cascade mode, the Set Point can get its value from the Cascade
transfer location or from Input 0.
- In Auto mode, the Operator or higher level device sets the Set
Point.
- Man mode is automatically set back to Auto but the timers are
initialized.
- LO(x) mode will be set by the block if ALL Output Word bits that are
pointed to by bit pointers from Output have bit 3 (Special) set in
their status bytes. The LO status will be fed back by Bit 3 to all
of the Input and Output words pointed to by timer input bit pointers.
- LO status fed back by Bit 3 of the status of an Output bit when the
block is not in LO mode based on the previous rule will cause an
alarm but not LO Mode. The algorithm will not write the state or
status bit 3 of that Output bit until Bit 3 of its status byte is
reset.
- The block can be set to LO mode. In that mode, the block will
reset its timers (as it does in Man mode) and freeze its Outputs.
The Output Words will still be written every cycle with the masks
defined by the configured pointers and with bit 3 set in their status
byte.
- Cascade information is passed up the analog cascade (i.e., through
the Setpoint), just as in other analog blocks except that there are
no limiting conditions from Output values. The analog "Output" will
be considered to be not wound up, not failed, and a path to the
process will be assumed to exist. The effects of the timer block's

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
658
mode and setpoint limits will then be added and the result passed up
the cascade.
- The Boolean operators are executed in order, Boolean operator #0
first, and the results of Operator 0 are available to the inputs of
Operator #1, etc..
- The Timers are executed in order, Timer #0 first, and the results in
the Output of timer x are available to the inputs of timer x+1. None
of the bit pointers for storing the values from Output to Output
Words will be executed until all timers are done.
- The bit pointers for Output are executed.
- Block alarms generated.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
- The PV Pointer function is executed if present.
- Output Words stored after execution with algorithm-set masks.
Mask bits set only for bits targeted by pointers.

- All standard status bit responses and setting.
OVERVIEW OF OTHER STATUS BYTES:

The following are the responses to unexpected conditions in the
algorithm's data.
bit 2: (Override)
No direct effect but the bits flow through (OR'ed together if
the bit affected the result of the logic).
bit 3: (Special)
If any of the Output Word bits that are pointed to by the
Output bit pointers has LO set, then those bits can not be
manipulated. If all Timer Output bit pointers point to discretes
with bit 3 set, the whole block will be placed in LO(x) mode.
bit 4: (Failed)
The bits flow upward in the discrete cascade.
bit 5: (No-path)
The bits flow upward in the discrete cascade.
bits 6 and 7: (ATW bits)
The bits flow upward in the discrete cascade. The timer will
--```,``-`-`,,`,,`,`,,`---
be consider a temporary constraint: a timer that is counting

and thus preventing an Input from moving an Output will NOT
cause an ATW bit to be set.
DATA BASE DETAILS:

- I/O Words can be pointed to any on-block, on-node, or off-node
parameters (Tag.Parameter) except floating point data types. They
will return up to 16 bits (the low order bits if the value is more
than 16 bits long).
- "Bit Pointers" are used to define the source or destination of
individual bits in the block. The Boolean Operator and Timer input
bit pointers can point to any on-block bit or to bits in the special
local logical node registers. Output bit pointers are used to form
the connections from Output to the Output Words; they can point to
any bits in the two on-block Output words or to the special local
logical node registers. These bit pointers include the option to
invert the state of the discrete that is transferred.
- The four discrete I/O words are standard Field Bus string parameters
with status bytes for each bit. The Setpoint and Output are named
parameters with standard Field Bus status bytes for each bit.

659
TIMER ALGORITHM
Cas
RCas
Mode
Input 0
Pointer Output
Input
Select Word 0
Word 0
Output 0
Set Point OW0-0 E
Thru F
Input OW0-F
Word 1 Analog
(Set Point Timer 0 0
Input 2
F Logic 1 X
E 2 1
X Boolean 3 0
Op'trs. X Timer 1 4
IW1-0 X Logic 5
Thru 0
1 6
Output 1
0 IW1-F #1 7 E
Timer 2 8 F
Input * Logic 9 OW1-0
Word 2 * A Thru
X
B OW1-F
Input 2
F
Timer 3 C
E #7 1
Logic D 0
IW2-0 E X
Thru F
IW2-F X
1
--```,``-`-`,,`,,`,`,,`---
Figure 47: Timer, Timer Algorithm

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
660
TIMER 0 LOGIC
0
1
In 0 Timer 0 2 In0 Timer0
In 1 Logic 3 Output
In 2 0
In 3 Old
Out0 Timer0
In1 Timer0
Output
Old 1
Timer Configuration Out1 Timer0
Timer Initial Value where:
Value = a x SP +b
In2 Timer0
a and b = reals
Output
Remaining Time (real)
2
Four Input Bit Pointers Old
Out2 Timer0
Four Output Bit Pointers
In3
Output
3
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Figure 48: Timer, Timer 0 Logic
SP-50 User Layer Technical Report Totalizer

--```,``-`-`,,`,,`,`,,`---

661
Totalizer
An addition to the algorithm definition came up after this paper was accepted -
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
we need to add two time accumulators: one to accumulate the time spent at the
maximum rate of the hardware counter and one to accumulate the time spent at the
minimum rate.

ALGORITHM OPTIONS
MODES
BIT POINTERS
EXPLANATION OF COUNTER CROSSCHECK
EXPLANATION OF SNAPSHOT REGISTERS
Case 0: automatic reset, accumulating up
Case #1: automatic reset, accumulating down
Case #2: manual reset, accumulating up
Case #3: manual reset, accumulating down
DETAILS OF UNIQUE BLOCK FEATURES
Figure 1 - Totalizer Block
Figure 2 - Totalizer Data Flow
BASIC ALGORITHM:
- This algorithm can accumulate the counts from counter hardware or it
can accumulate a total from a (flow) rate. It features a 64 bit
floating point accumulator for the total. It includes a trip and
pre-trip capability where the source of the trip count can be
controlled by the mode of the block. It calculates the filtered
instantaneous rate of the counter and it separately accumulates, in a
32 bit floating point value, the "last good value" of all readings
that were marked "bad".
- See the attached figure "Totalizer Block"
- Two modes of operation (see "Totalizer Data Flow" drawing):
+ Counter Hardware Input (Type CT)(must be on physical node):
@ The "planned" flow direction is indicated by a data base
option.
@ Count handled as a negative number if the flow direction
can be sensed and is opposite to plan.
@ Count converted to a 64 bit floating point analog value
using four correction factors:
- Rate factor
- Proving factor
- Units Conversion

--```,``-`-`,,`,,`,`,,`---

662
- Volume factor (Input 4)

@ If the input count was NOT "Bad", the incremental value is
integrated in a 64 bit floating point register (Total).
@ If the input count was "Bad", the incremental value is
changed to "Good" and integrated in a 32 bit floating
point register (BTotal).
@ Rate = rate based on filtered, converted count, with
the status of the original input value.
+ Analog value:
@ The input is converted to a 64 bit floating point analog
value using four correction factors:
- Block cycle time in seconds
- Timing Conversion
- Units conversion
- Volume factor (Input 4)
@ If the input rate was NOT "Bad", the incremental value is
integrated in a 64 bit floating point register (Total).
--```,``-`-`,,`,,`,`,,`---
@ If the input rate was "Bad", the incremental value is
changed to "Good" and integrated in a 32 bit floating
point register (BTotal).
@ Rate = Input Value scaled, corrected, and filtered, with
the status of the original input value.
- For Totalizing up, Target Value = SP (continuously variable). The
value is in engineering units (the units of Total).
- For Totalizing down, Preset = SP (only used at instant of reset).
The value is in engineering units (the units of Total).
- BTotal is always accumulated up.
- Pre-trip Output set if Total >= (SP - Pretrip_Value) for Totalizing up
(<= Pretrip_Value for Totalizing down).
- Trip Output set if Total >= (SP - Dribble) for Totalizing up (<=
Dribble for Totalizing down).
- Discrete data flow configured using "Bit pointers" that can connect
to bits in 2 Output words or 5 logical node registers: 16 bits each.
- Reset resets Total register to zero for count up (to SP if count
down) and it resets BTotal to zero.
- No mode change causes reset.
- O/S, LO, and Man modes hold Total and BTotal despite continuing
inputs. Raw count register (in the hardware) continues to be reset
every block cycle so counts are totally lost.
- The rate will be calculated and stored in Output 0 whenever the mode
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
is not O/S.
- The number of cycles with a bad count input and a mode of priority
lower than Man are counted and the time of the first event is stored.
- Input 3 can point to the "Total" register in a counter, tank gauge,
or second totalizer block. If the two registers differ by more than
a user-set deviation limit, an alarm will be generated. Two alarms
will be provided so that the alarm can show direction.
- Any time mode changes from one of Auto, Cas, or RCas to a mode of
higher priority than Auto AND Rate is > MRate (the rate below which
increments are not added to Total), an event notification will be
generated.
ALGORITHM OPTIONS:
- Accumulate = sense of accumulation into Total
= 0 if counts in planned direction or positive analog
value are to be subtracted from Total (traditional
counting "down")
= 1 if counts in planned direction or positive analog
value are to be added to Total (traditional counting
"up")
(default = 1)
- Auto-Reset = set to automatically reset the Total when the target
value (for accumulating up, 0 for accumulating down) is
reached.

663

- Modes: all ex. IMan, ROut - By-Pass: no
- Hardware Pointers: yes, none - Set Point Limits: yes
or 1: Input 1. - "PV Pointer": yes, default
- Bit Pointers: yes, 5 to Rate (analog)
- Cascade Structure: yes, but will - Output Limits: no
MODES:
- In Manual, accumulating of input stops but the hardware counter is
reset each block cycle. Outputs can be set. If the only mode bit
set is manual, then the Force Manual input value is reset and marked
"good".
- In LO mode, the block will act as if it is in Man but the Output can
not be manipulated and LO will be set in targeted bits.
- LO state fed back by Bit 3 of the status bytes of any Output
discretes pointed to will cause an alarm but not IMan(LO(x)) mode.
The algorithm will not write the state of any Output discrete whose
status Bit 3 is set.
- A leading edge on the Force Manual input causes Man(x) compound mode.
When the Force Manual input has a falling edge, the Manual mode bit
will be reset only if another, lower priority, mode bit is set. A
continuous set or reset condition of the Force Manual input has no
effect on mode. On transition out of O/S mode, if the Force Manual
input is found set on the first execution, it will be considered to
be a leading edge.
- In Auto, outputs set by algorithm; target (preset) set by operator.
- In CAS, Input 0 pointer or Cas transfer location used for target
(preset).
- In RCAS, transfer location used for target (preset).

- The block data values for the rate factor and the forward and reverse
--```,``-`-`,,`,,`,`,,`---
proving factors will be stored in the block's data base. However, if
the block points to a counter that is physically associated with a
particular meter, then that counter input may have three data values
associated with it in the Physical node's data base:
HRF - Hardware Rate Factor
HFPF - Hardware Forward Proving Factor
HRPF - Hardware Reverse Proving Factor
The three values will be in non-volatile memory. The value of HRF
will be changeable only with the manufacturer's special commands on
Field Bus while HFPF and HRPF are intended to be changed by the user.
If the hardware factors exist, they will be moved into the

corresponding values (RF, FPF, and RPF) in the Totalizer's static
data base every cycle. The static data base revision number will be
incremented only if the static data base value is actually changed.
- Reset is leading edge driven and can be set by a Field Bus command
and a pointer in parallel.
- Source of input is determined by the pointers for Inputs 1 and 2. If
one AND only one of the pointers is not null, that is the source of
the input. Otherwise, a bad configuration notification will be sent
and the mode of the block will be set to O/S.
- If the block is configured with more than 5 off logical node
pointers, it will force O/S mode and send a bad configuration
notification.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
- There will be a 16 bit counter that counts the number of resets - it

itself is never reset and not writeable.
- If "Auto-Reset" is set, the block will automatically reset when the
Total value reaches the SP (accumulating up, zero if accumulating
down); it will handle the "carry" of the totalizer correctly and
automatically.

664
- The calculation of the rate includes the cycle time of the logical
node. A manufacturer may offer a more accurate method of
calculation that bases the calculation on the actual elapsed time
from one counter sampling to the next. The presence of the actual
time feature is indicated in the physical node data base.
- Record of bad value for the configured totalizer Input:
+ Last good value of count (the value that is marked "Bad") is
set good and converted to Total's basis but added to BTotal.
+ A 16 bit counter is incremented every cycle that finds a bad
value for the active Input if the mode is lower priority
zero when a bad Input value is found, the current system time is
saved into the time stamp register. The field device provides
--```,``-`-`,,`,,`,`,,`---
no mechanism to rezero the register O/S mode but it is writeable
BIT POINTERS:
Bit pointers are used for configuring the inputs to the "Force Manual" and
"Reset" functions and the connections from the Output to Output words 1 & 2 or to
the special logical node registers.
The Force Manual function and the Reset function are configured using two
copies of the bit pointer word. They are combined under one parameter name; the
word for Force Manual is reported first.
The Output word is configured using three more copies of the bit pointer
word. Their configurations are also combined under one parameter name: the word
for Bit 0 is reported first.
EXPLANATION OF COUNTER CROSSCHECK:

It is anticipated that the totalizer block will sometimes be used to count
the pulses from meters that are in "custody transfer" service. This service is
one in which material is being metered for purposes of measuring sale quantity,
often with tax implications. It is anticipated that a comparison might be done
between the total in one Totalizer block and a total from another Totalizer block
or from a Tank Gauge block.
This block includes an option to support such a comparison. Input 3 will be

used to point to the Total register of another block. The Total pointed to will
be compared to the Total in this block. An alarm will be set if the two totals
differ by more than a user-set limit.
EXPLANATION OF SNAPSHOT REGISTERS:

This block is equipped to provide either manual or automatic resetting of its
accumulated total. In order to accurately capture and make the data at the time
of resetting available to a higher level device, three special parameters are
provided. These are called the "snapshot" registers and their names are
generated by adding the prefix "S" to the name of the working value with which
they are associated. One of them is quite simple: the current value of BTotal is
transferred to SBTotal at every reset.
The other two parameters (STotal and SSP) are set equal to the current Total
and Setpoint (Total and SP) immediately prior to the reset. The exact
interpretation of these two values depends on whether the resetting is done
automatically or manually and whether the Totalizer is accumulating up or down.
The following will consider these 4 cases.
Case 0: automatic reset, accumulating up:

Automatic resetting takes place whenever the Total is greater than
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~

665
the SP of the block. However, the SP is dynamic. Thus, a higher-level

device needs to know the exact value of SP when the automatic reset
occurred. This value is stored in the "snapshot" register SSP. This
block. The exact value of the Total (presumably slightly larger than
SP) is not needed because the "carry" is included in the next total.
Case #1: automatic reset, accumulating down:

Automatic resetting takes place whenever the Total is less than or
equal to zero. At that time, the current block SP will be added into
the Total register. A higher-level device needs to know the exact
value of SP that was used. This instantaneous value is stored in SSP.
This register will retain the value until at least the next resetting
of the block. The exact value of the Total (presumably slightly
negative) is not needed because the "carry" is included in the next
total.
Case #2: manual reset, accumulating up:

A manual reset will cause the Total register to be reset: there
--```,``-`-`,,`,,`,`,,`---
is no "carry". Therefore, the value of Total before the reset must be
captured for the higher-level device but there has been no effect of a
"target value". The value of Total is moved into STotal. The STotal
block.
Case #3: manual reset, accumulating down:

A manual reset will cause the value in the Setpoint to be set into
the Total. Therefore, the value of Total before the reset must be
captured for the higher-level device; the value of Total is moved into
STotal. Also, a higher-level device needs to know the exact value of
SP from which the count is decrementing. This instantaneous value is
stored in SSP. This register will retain the value until at least the
next resetting of the block. The "interrupted" Total was accumulating
down from some preset value; if that value was not already captured
out of STotal by the higher-level device, it will be lost.
The Totalizer block will reject reset requests for 8 cycles after a reset.
One reason for this is to guarantee that the snapshot values are exposed to the
Field Bus for at least 8 cycles before they can be overwritten. Since a reset is
an event that is reported in the alert buffer, a higher-level device can respond
to the event and capture the snapshot values.
- Node Parameters:
+ Plan_Dir = Discrete
= planned direction of flow through the meter
= 0 if plan = forward
= 1 if plan = reversed
Note: the forward and reverse directions relate to the
flow direction indicated on the meter body itself.
+ Conversion factors:
RF = Rate factor (for example, x gallons per count).
(default = 1)
Note: may be overwritten by HRF (from counter
hardware/physical node) every cycle
FPF = Forward Proving Factor (for example, 1.015).
(default = 1)

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
666
Note: may be overwritten by HFPF (from counter

RPF = Reverse Proving Factor (for example, 1.015).
(default = 1)
Note: may be overwritten by HRPF (from counter
TC = Time Conversion (for example, {1/[60 * 60]} if rate
is gal/hr.). (default = 1)
UC = Units Conversion (for example, {1/42} to convert to
barrels. (default = 1)
Total = Count * MF * SF * Input 4.
or Total = Analog Value * Cycle time (sec.) * RF * SF *
Input 4.
+ Pretrip_Value (delta below target for Totalizing up, absolute
for Totalizing down; always in engineering units).
+ Dribble_Value (delta below target for Totalizing up, absolute
for Totalizing down; always in engineering units).
+ MRate = Minimum filtered rate below which no Totalizing (in same
units as Rate)
+ RRate = Minimum filtered rate below which Output 0 will be
set to 0 (in same units as Rate)
+ DRate = Deadband for MRate and RRate.
+ In the "crosscheck" mode, an alarm will be generated if
the two Total's differ by more than CHECK.
+ Td = first order filter time constant for the rate value
(minutes)
+ SP = Setpoint of the block
= SP(n)
+ SSP = snapshot value of SP(n) at time of reset
+ Input 0 = used as "Set Point" in algorithm in Cas mode
= INPUT0(n)
+ Input 1 = Counter value (incremental counts)
= INPUT1(n)
+ Dir = indicator of the direction of flow: set = opposite to the
planned direction given in Plan_Dir
Note: an alarm will be generated while Dir = Set
+ Input 2 = Analog value to Totalize
= INPUT2(n)
+ Input 3 = Checktotal = 64 bit floating point variable
= INPUT3(n)
+ Input 4 = Volume Correction Factor
= INPUT4(n)
+ Output 0 = Rate = Filtered Raw Rate
= OUTPUT0(n)
For counter operation:
Raw rate = Delta_Count * RF * xPF * TC * UC *
INPUT4(n) / cycle time
where:
Delta_Count = change in counts this cycle
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
xPF = FPF or RPF as appropriate for actual
direction at this instant.
For analog operation:
Raw rate = Input 1 * UC * INPUT4(n)
+ Total = Accumulated total since last reset (if accumulating up;
{preset - accumulated total} if accumulating down)
including the carry value if the last reset was done
automatically.
+ STotal = snapshot value of Total at time of reset
+ BTotal = Accumulation of the "last good values" during cycles
in which the count or rate was marked bad.
+ SBTotal = snapshot value of BTotal at the time of the last reset

Input Value (i.e., Input 1 or 2) = Bad
AND
Mode lower priority than Man.

--```,``-`-`,,`,,`,`,,`---

667
+ Reset_Counter = 16 bit counter

= incremented for every block reset
= can not be reset itself
the Bad_Input_Counter after the Time_stamp location
was set to zero or the block reset.
- Internal Parameters (not accessible on Field Bus):
+ FRate = filtered Rate before RRate cut-off limit.

+ If Input 0 = NaN, the Total will continue to accumulate if the
mode is lower priority than Man. The Trip and Pre-trip Outputs
will be set immediately.
+ If Input 0 = "Bad", use the last good value.
+ IF the block is in Cas or RCas mode
AND IF accumulating up
AND IF the Total value is greater than (Current SP -
Dribble_Value)
Dribble_Value)
AND the Trip Output is not set
THEN Set "SP jump" Alarm and set the Trip and Pretrip
Outputs.
ELSEIF the Total value is greater than (Current SP -
Prealarm_Value)
Prealarm_Value)
AND the Pre-trip Output is not set
THEN Alarm and set the Pre-trip Output.
+ Bad Input 1 or 2 while in a mode of lower priority than Man:
hold the Total and increment the Bad_Input_Counter every cycle.
If Time_Stamp is zero, load it with the system time. Change the
value to good and add it to BTotal.
If the input returns to good, restart accumulating but leave the

accumulated count in the Bad_Input_Counter and the accumulated
total in BTotal.
+ Input 4 = NaN:
--```,``-`-`,,`,,`,`,,`---
set Input 4 = 1.0 and "Bad".

+ Bad Input 4 or Force Manual: use the last good value and
do not propagate the Bad.
+ Bad Input 3, Reset, or Prefetched Output Word: ignore.
- Block alarm if Total's exponent reaches maximum value.

- Resetting is done after the new accumulation is added to the
registers.
- The Reset Pointer handling will include two unique provisions:
+ the pointer will only be sensitive to the leading edge of the
pointer value, not the state or the falling edge. Specifically,
the pointer will maintain a copy of the previous pointer value
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
in Field Bus inaccessible memory. Only when the old value is

reset and the new value is set will "Reset" be set.
+ the pointer will OR the "Reset" value from the immediately
previous statement with its own data base value. This will
allow an operator to command a Reset in parallel with an active
Reset pointer. For 8 cycles after resetting, the block will
ignore any commands to reset. It will reset its data base value
and set its inaccessible copy on the eighth cycle.
- SSP = a "snapshot" register to save the SP in effect at the time of
reset.
- STotal = a "snapshot" register to save the value of Total current at

668
the time of reset.

- SBTotal = a "snapshot" register to save the value of BTotal current
at the time of reset.
- If Reset is Off AND Auto-Reset is set, THEN
+ IF the Totalizing up option is set AND IF Total >= SP THEN
SSP = SP(n)
STotal = Total
SBTotal = BTotal
@ Total = Total - SP
@ Event put into node alert buffer
--```,``-`-`,,`,,`,`,,`---
+ IF the Totalizing down option is set AND IF Total <= 0 THEN
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
SSP = SP(n)
STotal = Total
SBTotal = BTotal
@ Total = Total + SP
- If Reset is "On" THEN
+ IF the Totalizing up option is selected, THEN
SSP = SP(n)
STotal = Total
SBTotal = BTotal
@ Total = 0
+ IF the Totalizing down option is selected, THEN
SSP = SP(n)
STotal = Total
SBTotal = BTotal
@ Total = SP
- The pre-trip discrete will be checked every cycle it is set and reset:
+ If Total >= 0.5 * (SP - Pretrip_Value) for count up
If Total <= 0.5 * (STotal- Pretrip_Value) for count down
- The trip discrete will be reset:
+ If Total >= 0.5 * (SP - Dribble) for count up
If Total <= 0.5 * (STotal- Dribble) for count down

669
TOTALIZER BLOCK
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Cas RCas
Mode
Output 0
Input 0
Output
Input
Input 0
Pointer Word 0
Word 0
Select
Analog
Analog Set Point (Rate)
(Set Point)
Hardware
Counter
Input 1
Output
Word 1
Force Manual Total
Output 1
(Discrete) (32 bit) E
F
BTotal
Input 2
Input DW1-0
(32 bit)
Word 2 Thru
DW1-F
1
Analog Algorithm Trip 0
To Totalizer (Discrete)
Input Output
Output 2
Word 3 0 E
Input 3
Pretrip F
1
(Discrete) DW2-0
Check Total 2 Thru
Input Counting DW2-F
Word 4 (Discrete) 1
Reset 0
Input 4
(Discrete)
Factor
Figure 49: Totalizer Block

--```,``-`-`,,`,,`,`,,`---

670
TOTALIZER DATA FLOW

64 Bit Floating
INPUTS 32 Bit Floating Pt. Registers Pt. Register
Rate BTotal Total

Raw Delta
Counts:
Filter Conv.
Add &
Rate
Factor Add
No
Volume
Factor Mark Yes Bad
Proving
Good Value
Factor
?
Units
OR Conversion Yes
--```,``-`-`,,`,,`,`,,`---
Ct. Delta
Up =
Time Conv. - Delta
Factor ? No
Analog
Volume
Cycle Factor
Time
Units
Conversion
LO
Man. Time Conv.
Factor
Cycle
Time
Auto. Cas. RCas
Figure 50: Totalizer Data Flow

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
671
Discrete
Device Control
SUMMARY:
The fundamental control block for discrete applications; is primarily
intended to control motors, valves, conveyors, elevators, etc. The block accepts
a discrete SETPOINT, it acquires up to three feedback signals from the equipment,
and manipulates up to three OUTPUT bits that are assumed to be connected to the
equipment. It provides the logic, mode control, and timers required to control
the equipment.

FUNDAMENTAL NOTATION
EXPLANATION OF TIMER FUNCTIONS
BIT POINTERS
BOOLEAN OPERATOR
BASIC ALGORITHM:
- Control block for on/off/reverse type devices. Up to three discrete
outputs, each with a corresponding feedback input. Target state set
by a three-bit setpoint.
- See the attached figure "Device Block".
- Refer to Appendix paper: "Explanation of Device Control".
- Two 16 bit input words and three 16 bit output words.
- Control and feedback alarm function for operation of discrete devices.
+ Basic 3-state operation (on/off/reverse, open/close/stop).
+ Subsets to all control/feedback combinations less than 3x3.
+ Support for a "Human Interface" block.
+ Algorithm inputs a set point, an input from a human interface, and
up to three device feedback signals then outputs to the human
interface and to a three-bit Output Word.
+ Data flow configured using "bit pointers" that can connect to bits
in:
@ 2 Input words - 16 bits each.
@ 3 Output words - 16 bits each.
@ 5 Local logical node registers - 16 bits each.
SP-50 User Layer Technical Report Device Control

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
672
+ Last power command retention in "feedback" for extended

enumerations.
+ Two input timers:
@ Valve "crack timer".
@ Device "travel timer".
+ Two output timers:
@ Restart time delay.
@ Reversing delay.
+ Alarm if feedback not reasonable at end of crack timer.
+ Alarm if feedback <> commanded position at end of travel timer.
+ Alarm (a unique alarm) if feedback becomes <> commanded position
after travel timer has expired.
+ 3 Block output words with automatic masked write.
ALGORITHM OPTIONS:
+ HIF = logical: set = Human Interface Block in use.
+ LIMIT = logical: set = "limit" type feedback in use for feedback
bits 0 and 2. An example of limit type
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
feedback is the limit switches on a motor
operated valve.
reset = "state" type feedback in use for all 3
feedback bits. An example of state type
feedback is a motor contactor feedback for
"On".
+ OUTTRK = logical: set = Setpoint tracks Output in IMan mode.
reset = Setpoint left unchanged in IMan mode.

- Modes: all except ROut - Set Point Limits: no
- Hardware Pointer: none - PV Pointer: yes, default to Feedback
- Bit Pointers: yes - Output Limits: no
- Cascade Structure: yes - Boolean Operators: yes, 3
- By-pass: yes

- Support for a Human Interface block.
- Unmeasured or "bad" Feedback signals replaced by known
information from Output.
- "Bad" Output read-back signals replaced by known Feedback signals.
- Command "history" in part of the Feedback value.
FUNDAMENTAL NOTATION:
In this block, the logical meaning of the discrete bit states is defined. In
the Feedback, bit 0 will always refer to "Open" or "On". The condition will be
true when the bit is set. Bit 1 will always refer to "Off" or "Stopped" and the
feedback will be taken to indicate that state when the bit is set. Bit 2 will
always refer to "Reverse" or "Closed".
The bits will have the same meaning in the Set Point and Output words except
that they represent the command to go to that state.

--```,``-`-`,,`,,`,`,,`---

673
EXPLANATION OF TIMER FUNCTIONS:
- Restart Time Delay:

Some devices can not be restarted immediately after being stopped.
This constraint is frequently due to heat buildup or, in the case
of compressors, the need for the discharge pressure to bleed down
to make starting easier. The restart timer determines how long
the device must be "Off" before it can be turned "On" (in either
direction) again.
For motor control, a recent start-up may be a greater contributor

to the required delay time than recent running. Therefore, the
restart timer is defined as a simple process model in which a
start-up event contributes "heat", and each second of running
contributes "heat" while "heat" is dissipated over time.
- Delay Reversing:
Some motors that can be electrically reversed require that the
motor have coasted to a low speed before power can be applied in
the reverse direction. If the motor were to be restarted in the
same direction, there would be no limit or a much smaller limit.
The delay reversing timer only applies when the control is
three-state (On/Off/Reversed) and the device block set point
requests a reversal of direction.
- Travel timer:
Many devices take a significant amount of time to respond to a
command to change state. It is necessary that the human operator
be able to command a state change and then be able to rely on the
control system to generate an alarm if the device does not arrive
at the other state in a reasonable amount of time. The clearest
example of this need is a motor operated valve.
The "reasonable" amount of time is the time set in the "travel

timer". The block initializes the travel timer when a command is
output. The block will not generate an alarm concerning the
mismatch of the commanded state and the feedback state until the
travel timer has expired.
- Crack timer:
The crack timer is closely related to the travel timer. The
travel timer suppresses the alarm until the device has had time to
arrive at the commanded state. It does not consider the fact that
the device may have a feedback that indicates that the device has
never left its original state. For example, a large motor
operated valve may have a feedback signal that shows if the valve
is open and another that shows that it is closed. When the
command is given to open, it can be obvious in 15 or 20 seconds
that there is a problem when the feedback that shows that the
valve is closed does not go away. One does not have to wait the
full travel time (perhaps 6 minutes) to recognize a problem.
The crack timer is initialized when the command is output; when

the time is up, an alarm will be generated if the feedback of the
original state has not cleared and the feedback has gone into the
"traveling" state.
BIT POINTERS:
Three input bit pointers are provided for the Cas set point definition. If
the first pointer points to the Cas transfer location, then the Cas transfer
location will be used as the source of the Set Point in Cas mode.

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
674
The configuration words for the three pointers consist of three copies of the
detail word (pointer). The three words are combined under one parameter for
addressing purposes. The word for bit 0 of the set point is reported first.
Three words are reported even if only the first is used so that the length of the
parameter will be constant.
The Feedback word is configured using three more copies of the detail word
(pointer). They are combined under one parameter name: the word for Bit 0 is
reported first.
The Output word is configured using three more copies of the detail word
(pointer). These bit pointers can only point to the on-block Output words or to
the 5 special node registers. Their configurations are also combined under one
parameter name: the word for Bit 0 is reported first.
BOOLEAN OPERATOR:
The device block will include three Boolean operators that can be used to
operate on input discretes before they are fetched by the algorithm bit pointers.
For example, two discretes may have to be "OR"ed together before use as the
feedback signal of "ON". Note that the Boolean inputs can come from the
Setpoint, Feedback, and Output parameters but, if they do, the values will
reflect the value as of the previous cycle.
The nine configuration words are reported under one parameter; the three
words defining operator 0 are reported first and the operator definition word is
- Node Parameters:
+ Restart Time Delay:
@ K1 = Contribution per start-up event
@ K2 = Contribution per second of running
@ T1 = Decay time constant (seconds)
+ Delay Reversing:
@ T2 = time between stop and "On" in the reverse direction
(seconds) (can go from "On" to "Rev.-On" or "Rev.-On"
to "On" only if T2 = 0).
+ Crack timer:
@ T3 = time limit for device to leave its prior state
+ Travel timer:
@ T4 = time limit for device to travel to its new state.
Note: T3 is used in the travel timer when LIMIT = set AND the
new command sets Bit 1 (Off/Stop) (i.e., when using limit
type feedback and the new command was the no-power
command).
+ Input #1 = Input1(n) = up to 16 bit word
+ Feedback = FB = 5 bit enumeration of device state. Bits 3 and
4 are used to expand the functionality of the
Feedback enumerations.
+ Output = Out(n-1) = 3 bit string command to the device
Note: bypass automatically goes to bits 0-2 of Out0(n-1) .
+ Output #1 = Out1(n-1) = 16 bit string (automatic write mask)
Note: if a Human Interface block is used, it must be
connected to Output #2.
+ OLD_OUT = 3 bit string

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
675
= Last Output value commanded by this block.

- Two Input words and three Output words fetched if necessary.
- Boolean operators executed.
- Output formed from read-back bits.
- Low three bits of Feedback updated.
- Alarms and timers tended.
- If Output word #2 is attached to a Human Interface block and it has
a command, then set the LO mode bit and get the commanded set point
from it (see the "Human Interface" block for a definition of the
word and its functions).
- If the Human Interface is not in use or has no command, then reset
the LO mode bit and determine the new Set Point:
+ In RCas mode, the Set Point is obtained from the RCas transfer
location.
+ In Cascade mode, the Set Point can be configured as any three
on-block bits or it can be configured to get its value from the
Cascade transfer location.
+ In Auto mode, the Operator or higher level device sets the Set
Point.
- The ATW status will restrict setpoint action. Any of the three
output bits can be limited in either direction. In addition, since
only one bit can be set at a time, many wound-up states are implied.
For example:
+ If bits 0 and 2 are ATW-l, then bit 1 is ATW-h and the converse.
+ If bits 0 and 2 are ATW-h, then bit 1 is ATW-l and the converse.
- Compare the new Set Point with the Output, and generate a new Output
if a new command is required. If the stati of the Output bits will
not allow the command (ATW-h or ATW-l blocking) then set an alarm but
do not process the new set point.
- If there was a new command, then the input timers are reset and
Output is copied into OLD_OUT. This variable will be used to
manipulate bits 3 and 4 in Feedback.
- Output Words automatically form write masks and mask write their
new values if any bit in the mask allows writing. Output Word #2
will automatically prevent writing to bits 0-3 if it is connected to
a HI/F.

- All standard Boolean operator status handling.
- "Bad" value from Human Interface: reset LO mode bit.
- Bad Output: Use information from Feedback to determine the bit
value.

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
676
DEVICE BLOCK
Cas RCas
2 1 0 7 6 5 2 1 0
3 Set
Input Point
Word 0 Pointers
Boolean
Op'trs. Output
Mode Select
Word 0
0
Output 0
E
F
#1 X
DW0-0
X 2 1 0 X Thru
#2 DWo-F
X 1
0
Input 4 Output
Word 0 Feedback Output
Output 1
3 0 Word 1
Input 0
F Algorithm
--```,``-`-`,,`,,`,`,,`---
2 1 E
E X F
IW0-0 1 2 DW1-0
Thru
0 Thru
IW0-F
DW1-F
1 1
0 0
Bits Bits Output
Output 2
Word 2
Input 1
E Input 4-7 0-3 E

F Word 1 F
X DW2-0
Thru
IW1-0 DW2-F
1 Thru X Human Interface
0 IW1-F 1
0
Figure 51: Device Block

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
677
Discrete Input Function Blocks
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
parameter definitions are yet to be done.

EXPLANATION OF NORMAL BLOCK OPERATION
Multiple tag names
Debounce
Latching
OPERATING MODES
--```,``-`-`,,`,,`,`,,`---
FAILURE MODES AND ACTIONS

INTERNAL PARAMETERS
BASIC ALGORITHM:
- Interfaces a string of discrete input I/O points from field input
hardware to the Field Bus.
- Provides tag names for fields of contiguous bits and allows the option
of tags for individual bits.
- Up to n + 1 tag names per block with n = to the number of bits in the
input field.
- The hardware pointer points to a specific input register. Parameters
select the starting bit location within the register and the number of
bits in the field.
- Number of manufacturer's options which are assumed to be implemented
for the functional description. Options supported are indicated in
parameter Time_Crit0.
- All input data is read in parallel assuring no time skew across bits.
The physical hardware may sample multiple parallel input registers at
one time to offer no skew across multiple groups of bits and registers
which are accessed by multiple function blocks but this is not
required or guaranteed.
- Parameters such as debounce and latch duration apply to all bits in
the defined field.
- The status of the tag value is the same for all bits ( i..e. the same
status word will be reported for the tag name representing the entire
input field as for the tag names representing individual bits in the
field.
- An inversion mask is provided to enable inversion of specific bits in
the field.
- The Raw Input value is readable for the whole field.
SP-50 User Layer Technical Report Discrete Input

678

- Modes: O/S , AUTO, MANual - Set point Limits: no
- Hardware pointers : 1 - Set Point Ramp : no
- Bit Pointers: no - Output Limits : no
- Cascade Structure: no - Bypass : no
- PV Pointer : No

- Discrete input from a non-field bus environment
- A tag name for the block plus an optional tag name for each of the
bits in the input field.
--```,``-`-`,,`,,`,`,,`---
Discrete points will be structured in registers with up to sixteen(16) bits
within a register. The hardware pointer points to a specific register in the
physical device. Parameters identify the starting bit in the register and the
width of the field (number of bits). Fields may not cross register boundaries.
The starting bit pointer will be an integer index starting with zero. All
parameters which mimic the width of the input field will be bitstrings of length
n, where n is the field width and the data will be right justified. Parameters
such as debounce, latch duration, raw value, inversion mask and failout value
apply to the structure of the HW input register, not to the final right justified
output value.
NOTE : The term 'register' is used in the PLC context as a 16 bit data
storage location. The actual 'register' may be a physical device
input,a memory location, a communications buffer location or any
other accessible location which can be uniquely identified by the
'HW' pointer.
EXPLANATION OF NORMAL BLOCK OPERATION:

The Discrete Input Block provides a Fieldbus input interface for single bit
on/off information from field sensors such as limit switches, pressure switches,
relays, contactors which represent the state of a field device or event
occurrence by the opening or closing of a sensing circuit. The width of the
input field may be from one to sixteen (16) bits. The input field width may be
fixed by the manufacturer to correspond to the physical inputs provided or the
manufacturer may allow the user to configure the field width represented by this
function block allowing any subset of the input register to be used. There is no
prohibition to having other input function blocks address the same input register
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
as long as no input bits are multiply defined and no fields overlap at the
register level.
Multiple tag names:

To simplify single bit access to bits in a multi-bit field, the
manufacturer may allow the use of an "alias tag name" for each bit in
the field. Bit2 of Time_crit0 is set if this feature is provided. This
allows the user access to individual bits with their "alias" tag names.
All parameters of the group as a whole are common to all bits, but
addressing by "alias tag name" will return the value of that bit only.

679
A common status byte is returned for normal tag access or single bit
'alias' access. This multiple address scheme is to facilitate the use
of single bit data by other function blocks and users which do not have
masking and single bit extraction and manipulation functions.
Debounce:
The Discrete Input function block provides for the parallel input
of one (1) to sixteen (16) bits of binary data from the physical
hardware. Each bit of data is 'debounced'. The manufacturer may
provide hardware debounce by external RC network external to the block,
or provide debounce by digital processing. The manufacturer may make
the debounce period fixed or variable by the user. The debounce
parameter in the data base is represented as an unsigned sixteen bit
integer word with the value in milliseconds. The actual hardware may
not support millisecond resolution. If the debounce parameter is user
adjustable bit0 of Time_Crit0 will be set. If the debounce is not user
adjustable, a read of the debounce parameter will show the fixed
debounce time.
Latching:
Since the data access rates on the Fieldbus may be slower than the
occurrence rates of some discrete events, an optional latching service
may be provided. If bit 1 of Time_crit0 is set, the latching function is
provided. Any change of state of the inputs is retained in the output
word for the specified time period. Otherwise the processed value is
allowed to transition freely to follow the changes in the raw input
value at the block execution rate.
After this processing the input value may be inverted according to the
invert parameter . The invert parameter is a bitstring of length n with the
corresponding bit set if the bit in the raw value is to be inverted in
Output0.
OPERATING MODES:
The normal operating mode of the discrete input function block is the AUTo
mode. The processed value is available in Output0.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
In the O/S ( out of service) mode the block does not perform any input
processing. The Output0 status is set to BAD and the value is set to zero.
In the MANual mode, the block performs no input processing. The operator may
manually insert a value into Output0 value. The Output0 status has the following
status bits set:
- Not from process
- No path to process
FAILURE MODES AND ACTIONS:

Upon any type of failure which may be sensed by input circuitry, node
electronics or any other test mechanisms provided in the node by the
manufacturer, the block will test bit3 of Time_crit0. If the bit is set(1), the
block will transfer the failout value to Output0. If bit3 is reset (0), Output0
is held at the last good value. Output0 status has the following bit set:
- Fail

--```,``-`-`,,`,,`,`,,`---

680
INTERNAL PARAMETERS:
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Field Width .(n).............Unsigned_Octet(1-16)

Start_bit....................Unsigned_Octet (1-16)
Raw input value..............Bitstring (n)
Latch duration (msec)........Unsigned_Integer16 (0-65738)
Invert flags (set to invert).Bitstring (n)
Debounce (msec)..............Unsigned_Integer16 (0-65738)
Failout value................Bitstring (n)
Input 'Hardware' pointer.....Unsigned_Integer16
Time_Crit0...................Bitstring(16)
Bit0....................Supports user set debounce time
Bit1....................Supports latching
Bit2....................Supports n+1 tags
Bit3....................Supports Failobey action
--```,``-`-`,,`,,`,`,,`---

681
--```,``-`-`,,`,,`,`,,`---
Discrete Output
parameter definitions are yet to be done.

EXPLANATION OF NORMAL BLOCK FUNCTION
OPERATING MODES
FAILURE MODES AND ACTIONS
INTERNAL PARAMETERS
MANUFACTURER OPTIONS
BASIC ALGORITHM:
- Interfaces a discrete setpoint value to a physical discrete output
device in the field.
- Discrete field width may be single bits or multiple bits up to 16
bits.
- Provides one tag name for the entire output field and the
manufacturer's and user's options for up to 16 individual bit tag
names.
- Provides for a number of manufacturer's options which are assumed to
be implemented for the functional description.
- The hardware pointer points to a specific output register in the
physical device, the starting bit location and the number of bits in
the field.
- Parameters such as output type ( maintained, pulsed, pulse duration )
are applicable to all bits of the field.
- All outputs in a field occur in parallel to create no time skew in the
output between bits.
- Status and mode are common to the block and the same values are used
whether the block is accessed by individual bit tag name or by the
block tag name.
- The output may be set for direct or reverse action using the
Direct/Reverse parameter bitstring.
- The output checkback function provides a positive check that the
requested output actually occurred and will present an alarm if the
output did not occur. The scope of this checkback, it's
implementation and the extent of alarms and diagnostic messages are a
manufacturer's option.
- The detection of a failure or malfunction in the output or physical
device will cause the device to transition to a user definable
physical state to the best of its ability. This Failure output state
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
may be user defined as all outputs off or to output and hold the value
defined in the Failout parameter.
SP-50 User Layer Technical Report Discrete Output

682

Modes: O/S, AUTO, CAS, LO Setpoint Limits: NO
Hardware Pointers : 1 Setpoint Ramp : NO
Bit Pointers : NO Output Limits: NO
Cascade structure: No Bypass : NO

- A tag name for the entire block and optional tag names for individual
bits in the field.
- Output function may be blocked by LO mode.
- Outputs may be maintained or pulsed.
Discrete points are structured in parallel registers of up to sixteen bit
width. The function block may be defined with any field width from one to
sixteen bits. To allow the use of these output functions with other field bus
equipment which does not have bit extraction and manipulation facilities, the
manufacturer may optionally allow the assignment of tag names to individual bits
in the overall field . The block may be addressed by the overall block tag name
in which case setpoint inputs must be of a field width to match the overall
field. Fields may be defined with any width and any starting bit location within
the register and will represent contiguous bits, but fields may not cross
register boundaries unless specifically and optionally allowed by the hardware
manufacturer and the structure of the physical device. The manufacturer may
--```,``-`-`,,`,,`,`,,`---
produce devices with field widths and structures assigned at the factory or may
allow the user to configure the hardware pointer and field widths , etc in the
field. The width of the field is defined by the Field Width parameter. All
other related parameters and data locations such as setpoint, CAS input, D/R
action, Failsafe output, etc. are automatically of the same width and structure.
Parameters such as mode, status, output duration are single values which apply to
the entire block as well as single bits. (I.E. all outputs use a common output
duration parameter.)
EXPLANATION OF NORMAL BLOCK FUNCTION:

The discrete Output function block translates discrete values received over
the Fieldbus into the actuation of a physical output to drive an external device.
The physical device may be any type of output which can be driven to one of two
defined discrete output states. The input value is a setpoint written to one of
the two transfer locations ( SP, CAS) by a fieldbus control device. The Discrete
Output block has no input fetch capability. The setpoint is a bitstring whose
width corresponds to the field width. The setpoint value may be inverted ( D/R
parameter) before output to provide direct or reverse action. The output may be
one of three types. All outputs are of the same type as set by the Output Type
parameter.
Output type 0 (the default type) is a simple maintained output whose value
follows the setpoint. The output action may be inverted using the D/R parameter.
Output type 1 is a single pulse output of duration specified in the output

duration parameter. In order to create another pulse output the setpoint must
transition off then on again. If the D/R parameter is not set, the pulse is
output when the setpoint bit transitions from low to high. If the D/R parameter
is set (for reverse action) , the output pulse occurs when the setpoint
transitions from high to low.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
683
Output type 2 provides a single pulse output of duration specified in the

output duration parameter. If the setpoint transitions off and back high DURING
the output pulse the pulse duration is EXTENDED by another duration period.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Repeated setpoint transitions are capable of extending the output pulse

indefinitely in units of the defined duration. Provision of type 1 and 2 outputs
is a manufacturer's option.
For operational, testing , maintenance and safety reasons, the Discrete

Output block uses the LO (locked Output/Local Override) mode bit to prohibit
outputs from occurring. If the LO mode bit is set for the block, no further
outputs will be initiated. Maintained outputs will be held in their current
state and no further transitions will be allowed. Pulse outputs in progress will
be completed normally and no further outputs will be initiated.
OPERATING MODES:
The normal operating mode of the discrete output function block is the
CAScade mode. Setpoints are written into the CAS transfer location from other
controllers on the Fieldbus. The local input location may be used by a local HIF
block in the AUTO mode. ROUT is not supported. Block modes supported are:
O/S - Out of Service - all outputs are de-energize - No control
functions occur
AUTO- Field output setpoint is taken from local input location.

--```,``-`-`,,`,,`,`,,`---
CAS - Field output setpoint is taken from CAS transfer location.
LO - LOcked Output - Set by a HIF node. LOcked output prevents

prevents any further execution of control outputs. Pulse
outputs in progress are completed normally and then future
transitions will be blocked. Maintained outputs are held
and any further transitions are blocked.
FAILURE MODES AND ACTIONS:

The Discrete output block may optionally contain output function check
circuitry. The use of this feature is controlled by the Checkback parameter. If
this parameter is set, checking is active and a failure of the requested output
to transition on command is considered an output failure and will be reported as
a level one alert. Under these conditions the block will remain in the CAS mode
and will set the following bits in the status word:
- Fail
- No path to process
- Not from process
- Wound up high
- Wound up low
In the event of a communications failure ( i.e. no periodic setpoint writes

to the CAS transfer location) the block will remain in the CAS mode, report a
level 2 alert, and set the following status bits:
- No comm
and will test the Failsafe Output parameter. If Bit 0 of Time_crit0 is reset
(0), maintained outputs will hold their last state and pulsed outputs will
complete normally. This is the default response and is required in all
implementations.
If the block supports the optional FailSafe output feature Bit 0 of

Time_crit0 is set (1). The output(s) will be set to match the Failsafe_Output
parameter. If the corresponding bit in FailSafe_Output is set(1), the CURRENT
output state will be held. Pulsed outputs will be completed normally. If the
corresponding bit in FailSafe_Output is reset (0), the output will be de-
energized. When communications are restored, the output block will manipulate
outputs to match the requested setpoint.

684
The FailSafe_Output action may also be triggered by the logical node failsafe
function which will override all other commands. If the function block supports
the failsafe functionality, the failsafe trigger is a function of the logical or
physical node hardware and triggers all function blocks on the node.
INTERNAL PARAMETERS:
Hardware pointer......Unsigned_Integer
Field width (n).......Unsigned Octet(1-16) - defines the number of
bits in the output field.
Start_bit.............Unsigned Octet (1-16) - defines the starting
bit in the output register.
Dir/Rev action........Bitstring (n) - controls inversion of input for
direct or reverse action. Set (1) = reverse
action.
FailSafe Output.......Bitstring (n) - controls the failure mode output
actions of the corresponding bit outputs.
Output type...........Unsigned Octet (0-2) - controls the output
actions of all points in the block.
Output duration.......Unsigned_Integer( 0-65768) - duration of pulsed
outputs in milliseconds. The device may or may
not support millisecond resolution, but the
duration is expressed in this manner.
Time_crit0 ...........Bitstring (16)
Bit0 - If set (1), the block follows the FailSafe action
specified in the FailSafe output parameter.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Bit1 - If set, the device supports pulsed outputs.
Bit2 - If set, the device supports "alias" tags.
Bit3 - If this flag is set(1), the device will perform output
checking. If reset(0) the checkback function is
disabled.
--```,``-`-`,,`,,`,`,,`---
Bit4 - Field width is user configurable.

Bit5 - Hardware pointer, field width and start bit are user
configurable.
MANUFACTURER OPTIONS:
The manufacturer is given a number of options in implementing the
functionality described. The minimum set of required functions involves basic
field bus operation, mode, status and alert functions for a function block
providing one tag name and one physical output which is a type 0 output. The
hardware pointer and parameters are fixed and the only user adjustable parameters
are tag name and direct or reverse action.
The manufacturer may produce units with fixed numbers of outputs, typically
2,4,8 or 16 or allow the user to configure the output field width. Additional
options the manufacturer may offer are type 2 and/or type 3 pulsed outputs,
output checkback function, and the Failsafe output option.

685
Discrete Register

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
BIT POINTERS
BOOLEAN OPERATOR
EXPLANATION OF NORMAL BLOCK OPERATION
EXPLANATION OF TIMER FUNCTIONS
- Pulse Timer
- Debounce Timer
EXPLANATION OF DATA FLOW
EXPLANATION OF FAILSAFE OPERATION
EXPLANATION OF LOCKED OUTPUT
EXPLANATION OF LATCHED INPUT
COMPOSITE PARAMETERS
Figure 1 - Discrete Register Block
Figure 2 - Discrete Point
Figure 3 - Discrete Value Flow
BASIC ALGORITHM:
- Discrete hardware driver block to handle up to 16 mixed I/O points.
Provides individual tag names and alarm function for each point
along with simple Boolean operators.
- See attached figure "Discrete Register Block".
- One Input hardware pointer and three 16 bit Output Words.
- Input hardware pointer identifies one 16 bit discrete I/O hardware
register. Mask to ignore selected bits in the hardware.
- Input and Output discretes mixed in the one register.
- Input bits brought to Output Word 0.
- Output bits taken from Output Word 0.
- 17 tag names in one block - one for the whole block and 1 for
each of the 16 bits in Output Word 0.
- Writes to Output 0 can immediately go directly lthrough to the
hardware or can be written to hardware during this block's execution
time (as chosen by the manufacturer).
- 8 Boolean operators in the block.
- Two extra output words in the block (Output Words #1 and 2).
- Bit pointers provided for each bit in the Output Words.
- Functions provided (by input bit) in hardware-to-Output 0:
+ Optional self-power for inputs.
+ Debounce of input (on/off, one adjustable time per register).
+ Optional latching
+ Raw Input value (after debounce and latch) readable.
+ Input direct/reverse.
SP-50 User Layer Technical Report Discrete Register

--```,``-`-`,,`,,`,`,,`---

686
+ Input override.
+ Bit pointer (overrides value from hardware)
+ Alarm on either Output state and/or transition.
+ Delay off on alarm (time set by bit).
- Functions provided (by output bit) in Output 0-to-hardware:
+ Bit pointer (overrides value in Output Word 0).
+ Alarm on either input state and/or transition.
+ Delay off on alarm (time set by bit).
+ Output direct/reverse.
+ Optionally reset ouytput if "bad", else hold last value.
+ Locked Output by bit.
+ Output pulse timer (on/off, one pulse time per register).
+ Optionally respond to failsafe command.
+ Selection of failure state (hold or no-power).
+ Raw Output value readable.
+ Optional feedback check of Output circuit.
- Functions provided (by bit) in Output Words #1 and #2:
+ Bit pointers.

- Modes: O/S, LO, and Auto - Set Point Limits: no
- Pointers to Hardware: 1 input - "PV Pointer": yes, default
- Bit Pointers: yes to Output
- Cascade Structure: no - Output Limits: no
--```,``-`-`,,`,,`,`,,`---
- By-pass: no - Boolean Operator: yes, 8

- A tag name for the block PLUS 1 tag name for each of the 16 bits in
Output Word 0. All tag names at the same hierarchical level.
Discrete points will be structured in registers with up to 16 individual
points in one register. The "subidentifier" designator will identify the
discrete point within the register; it will be an index number starting with zero
(see p3 of "Data Owner Structure - Hardware".
The data base for Output Word 0 is represented as a two-dimensional array.

The 16 rows of the array represent each of the 16 discrete points. The columns of
the array represent each of the data base items. The tag name for each point can
be left "Null" or it can be addressed using the block's tag name. Then, the data
items on any one of the 16 rows of the matrix will be addressed using the (non-
Null) tag name of the discrete desired. The data items in any column of the
matrix will be addressed using the tag name of the block. The full list of data
items for each point (i.e., each row) is given below.
BIT POINTERS:
Sixteen bit pointers are provided for each Output Word. The configuration
for the 16 pointers for one word consists of 16 copies of the bit pointer
definition word. The 16 configuration words are combined under one parameter for
addressing purposes. The pointer configuration word for bit 0 is reported first.
All 16 words are reported even if some are not used so that the length of the
parameter will be constant.
The block rules will:

1) form the new input bits in "Output" and Output Word 0 from the
hardware.
2) execute the Boolean operators.
3) execute the bit pointers for Output Word 0.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
687
4) execute the bit pointers for Output Word #1.

5) execute the bit pointers for Output Word #2.
6) output the output bits in Output word 0 if necessary.
7) execute the alarm functions for each bit in Output Word 0
These procedures are ordered so that the Output bit pointers can point to the
results of the Boolean operators defined below and receive fresh values. Also,
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
the Boolean operators can be defined to operate on input bits in Output word 0,
then a pointer for a bit in Output Word 0 can pick up the result from the Boolean
operator and get the bit into the Output word before the alarm operation.
BOOLEAN OPERATOR:
The Discrete Register Block will include eight Boolean operators that can be
used to operate on discretes before they are fetched by the Output Word bit
pointers. For example, two input discretes may have to be "OR"ed together before
the alarm function. Note that the Boolean inputs can come from the input bits of
Output Word 0 and reflect fresh values. In addition, they can come from any bits
of any Output Word but, if they do, the value may reflect the value as of the
previous cycle or a value written by another block.
The 24 configuration words are reported under one parameter; the three words
defining operator 0 are reported first and the operator definition word is
EXPLANATION OF NORMAL BLOCK OPERATION:

The Discrete Register Block is designed to provide several fundamental
functions with a minimum of configuration. It can also implement simple
combinational and response logic for both control and alarm functions.
The simplest function of the block is to transfer the discrete I/O values
to/from the physical hardware. It is anticipated that the 16 discrete points
will be a mix of inputs and outputs. Some of the points will be used by device
and logic blocks and will not need individual tag names nor alarm functions.
Some of the inputs will probably be process alarms that need a tag name per
point and the alarm function. Each of the points in Output Word 0 can have its
own tag name. Since the input discretes are placed in order in Output Word 0,
the points that need alarms are found there by default, ready for alarming.
There may well be simple Boolean operations that need to be performed on the
discrete inputs ahead of the alarm function. For example, a user may want an
alarm on the Boolean "OR" of two discrete inputs. This is accomplished by using
a Boolean operator and placing the result into one bit of Output Word 0,
overwriting one of the original bits. Note that the original bits can still be
accessed in "Output".
There may also be a need for simple combinational logic for control. For
example, one may want an input to immediately set an output IF a control flag is
set. This can be done with one Boolean operator right in the Discrete Register
Block.

--```,``-`-`,,`,,`,`,,`---

688
EXPLANATION OF TIMER FUNCTIONS:
Pulse Timer:
Each of the Outputs is supplied with an optional pulse timer but
the time is set once for all points in the block. This function is
intended for control circuits that latch once driven. For example, the
standard three-wire motor control circuit only needs a pulse signal to
turn off. The pulse must be sustained only long enough for the motor
control relay to drop out. Note that some self-latching circuits are
implemented with an intermittent duty relay that will over-heat if left
on for an extended time.
The pulse timer will be started by a rising edge of the output

value. It will turn off the output if:
1) the input resets, OR
2) the timer times out
Debounce Timer:
The field device that is supplying the input signal may not open
and close "cleanly". It may bounce several times, particularly on
closing. The debounce timer, usually an analog filter with a time
constant of perhaps 10 to 50 milliseconds or a delay-on discrete timer,
is intended to indicate a change in state only after the bouncing is
settled. If the change of state of the input is to be accurately time
stamped, it may be necessary to reduce the debounce time to achieve the
necessary time resolution, even if that results in a bounce (and hence
more complexity in any logic block using the input).
Field Bus will assume that there is some debounce built into the
input circuit. Then, an additional debounce time for each point will
be optional but the time of the additional debounce will be set for the
whole register (block).
The "additional" debounce timer will be started when the input is

passed by the "base" debounce circuit. It will pass the "set" value
when the debounce timer times out. If the input value resets before
the timer expires, the timer will reset.
EXPLANATION OF DATA FLOW:

The attached figure, "Discrete Point", illustrates the data flow in a fully
implemented discrete point. If the point is configured as an output point, the
portions shown with dotted lines in the lower left are not used. If the point is
configured as an input point, only the bottom two lines are used. The right half
of the figure depicts the functions that the Field Bus Standard models as being
in the hardware while the functions on the left are modeled as being in the
block. Any implementation that yields the same functional result is
satisfactory. In addition, the output value can be physically output any time in
the cycle between the time that a control block or Field Bus writes to the
location shown in the upper left as "logical value" and the end of the block time
for the discrete register block.
The figure uses a heavy dash-dot line to show the boundary between the block
and the hardware. The information that must be transferred across that boundary
is shown using the notation given below for each variable.
--```,``-`-`,,`,,`,`,,`---
The values of the "Raw Output" and the "Raw Input" are provided primarily for
maintenance considerations and for the situation where the raw input is being
checked before releasing an input override.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
689
The figure also shows the physical connections and their labels. It is the
intent of the Field Bus Standard that the physical labels on the connections will
be consistent with the "Power" and "Return" designations as shown. It is
intended that "Form 'C'" Outputs would be beyond the physical connections shown
or would add a third connection to the two shown.
The attached figure, "Discrete Value Flow", shows the data flow out of the
"Logical Value" of a discrete input, through the register I/O words of a control
block, through the bit pointer, into the control block's algorithm, out through
another bit pointer and Output register to the "Logical Value" of a discrete
output point.
EXPLANATION OF FAILSAFE OPERATION:

The logical node contains a discrete value that controls the assertion of
"failsafe". When that discrete is set, all outputs in the logical node that are
configured to obey the failsafe command will go to their configured "failsafe
value". In the Discrete Register block, there are two static data base logical
values per individual output bit that configure the failsafe operation.
The logical "FAILOBEY" indicates, when set, that the output for that bit will
obey the failsafe command. A second logical, "FAILOUT" indicates, when set, that
the output for that bit will be depowered when failsafe is set, else the output
value will be forced to hold.
The drawing "Discrete Point" indicates the location of the failsafe logic in
the output path. It is on the physical side of the direct/reverse logic;
therefore, the no-power state is literal rather than logical. Second, it is after
the Locked Output logic. The reason for that will be explained below. Finally,
it precedes the Pulse Timer logic. In a situation involving a pulsed output, if
the failsafe state is no-power, the output will be turned off immediately upon
the failsafe command because the pulse timer drops the output when the input
drops. If the failsafe state is hold and the output has just turned on, the
pulse timer may be timing and the output may be on. When the pulse time is up,
the timer will turn off the power even though the failsafe option was to "hold".
If FAILOBEY is set, the output logical value has no effect on the physical
output.
EXPLANATION OF LOCKED OUTPUT:

The Locked Output function can be applied to any of the 16 individual
--```,``-`-`,,`,,`,`,,`---
discretes or to all of them as a set. The block will show LO mode only if the LO
state is set for the block (i.e., LO is turned on for the full set). The LO state
shown in bit 3 of the status byte of the Output bits will be the "OR" of the LO
mode of the block and the LO state of that bit. Consider the following scenario:
1) bit n is marked LO, then 2) the block is marked LO, then 3) the block is taken
out of LO. Following those three steps, bit n will still have bit 3 of its
status byte set.
If any point is in "Locked Output", the value can not be commanded to change.
Note that the pulse timer is positioned after the Locked Output. Thus, if the
Output is locked while a pulse is on, it will time out and change the Output.
However, the Output will then be off and locked. The "failure" power option is
also after the locked output. However, the failure option is considered to be a
"higher level of override" then LO. Note that, since the options for failure are
1) hold or 2) no power, a circuit can still not be unexpectedly powered.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
690
EXPLANATION OF LATCHED INPUT:

The Field Bus Model of the discrete inputs assumes that the hardware
functions operate independently of the Discrete Register block cycle time. The
resolution of the pulse timer and the debounce timer are assumed to be much
shorter than the block cycle time. Given a relatively long block cycle time, it
is entirely possible that an input signal may have come and gone between one
cycle time. The classic example of this is a simple push-button switch. Its
signal may only last for a half a second but a Field Bus block operating once per
second may need to know that the button was pressed.
The optional input latch is provided to guarantee that a signal that was
allowed through the debounce timer will be observed by the block logic.
Specifically, the latch logic will operate if "LATCH" is set. It will latch the
first change of state that occurs after the latch is read by the block each
cycle. Once that changed state is seen by the discrete register block, the then-
current output of the debounce circuit will be accepted. If it, in turn,
represents yet another state change, then the latch will hold that change for the
next block cycle. Note that multiple changes of state may be missed by this
design. However, a single but short duration change that is allowed through the
debounce circuit will be guaranteed to be seen by the Discrete Point block.
- Note: the parameters in the following table are given names for the
purpose of this definition. This block has a large number of
static, single bit configuration parameters. For efficiency,
these parameters will be composited into words for access over
Field Bus. A later section, "Composite Parameters", defines
how many of the named parameters will be combined into three
composite parameters addressed on Field Bus.
+ Data for the whole block:
@ Tag Name
@ Tag Descriptor
@ ASK = Alarm Sort Key
@ MASK = 16 bit string: set bits correspond to bits in the
hardware register that are connected to this block.
@ ACDC = Enumeration: AC/DC/etc. supported by all points in
the block
@ CURRENT = Integer: Current capacity of all output
points in register, in milliamps
(0 = varies by point)
@ DB = Integer: "extra" debounce time over the basic time,
in milliseconds
@ FB = Discrete: Set if points support feedback checking,
optional by bit, when in Output mode
@ FBANY = Discrete: Set if output points support feedback
checking by register.
@ FBALL = Discrete: Feedback checking by register: set = on
@ GRD = Discrete: Set if points can be optionally by
point tested for shorts to ground.
@ GRDANY = Discrete: Set if points can be optionally tested
for a short to ground (all points in the
register).
@ GRDALL = Discrete: Ground test by register: set = on
@ IO = Discrete: Set if points can be mixed Input and Output
@ PULSE = Integer: Pulse time for all points in the register,
in milliseconds
@ VOLTS = Enumeration: Voltage level of I/O supported by all
points in the block.
+ Data for each point in Output Word 0:

@ Tag Name

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
--```,``-`-`,,`,,`,`,,`---
691
@ Tag Descriptor
@ ASK = Alarm Sort Key
@ OUT = Integer: Set if point is an Output point (reset if
outputs not supported)
@ Output Data (static):
* PTR = bit pointer (mapped to the same memory location
as is used for the composite
parameter)
* OUTDR = Bit: Set if logical value to be reversed
* REBAD = Bit: Set if block is to reset and output
a "Bad" output bit. The "reset" state
is after OUTDR.
* OUTLO = Bit: Set if locked output
* PULSE = Bit: Set if pulsed output
* CHECK = Bit: Set if feedback check
* FAILOBEY = Bit: Obey logical node failsafe command
if set.
* FAILOUT = Bit: Failure state option, reset if hold,
set if no-power upon failsafe.
@ Output Data (dynamic):
* OUTLV = Bit: Logical value
* OUTLVS = Byte: Logical value status
* OUTRV = Bit: Raw output value
@ Input Data (static):
* SELFP = Bit: Set if Field Bus device is to provide
the sense power to the circuit.
* DEB = Bit: Set if additional debounce time needed
* LATCH = Bit: Set if hardware input to be latched
for the block.
* INDR = Bit: Set if raw input value to be reversed
* INOVR = Bit: Set if input value in override
* INOVRV = Bit: State of override
* PTR = bit pointer (mapped to the same memory location
as is used for the composite
parameter)
@ Input Data (dynamic):
* INRV = Bit: Raw value
* INLV = Bit: Logical value
* INLVS = Byte: Logical value status
* LVHW = Bit: Logical value from hardware (part of
"Output"
@ Alarm Data (static):
* ALMDELAY = Integer: delay off timer on alarm state,
in seconds.
* As for all blocks, there will be a defined set of
alarm conditions. The static data base will include a
priority and an option bit for each alarm. The option
bit is set if the unacknowledge bit for the alarm is
to be cleared when the alarm condition clears. The
alarm conditions will include:
1) Fail feedback check
2) Short to ground
3) Short circuit
4) Open circuit
5) Dirty contact
6) State transition
7) State = set
8) State = reset
@ Alarm Data (dynamic):
* The dynamic data base will include two bits for each
alarm. They are the "alarm set" bit and the
"unacknowledged" bit.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
692

Any output bit that is marked "Bad" will not be output. If "REBAD" is set,
the bad value will cause the output to be de-powered (but the "bad" value will
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
still be shown in the logical value). If "REBAD" is reset, the previous output
will not be changed.

- The input values at the hardware level will be captured during the
start of the logical node cycle. They will be captured before the
beginning of the block time for the first block in the logical node.
- The input values can be processed as far through the functional
process shown in the figure "Discrete Point" during that time as is
desired by the manufacturer but they can not be placed into Output
Word 0.
- By the end of the block time of the discrete register block that
points to the hardware register, the logical values in Output 0 of
the discrete register block will be current.
- If any input point is in override (INOVR set), the override state
from static memory (INOVRV) will be inserted in Output 0.
- The value of the status byte for each input bit will be set
according to the following rules:
TBD
- Execute the Boolean operations in order, completing the fetching

and the calculation of operator 0 first, then #1, etc. in order.
- Execute the bit pointers for Output Word 0, doing bit 0 first, then
the rest of the bits in order.
- Execute the bit pointers for Output Word #1, doing bit 0 first, then
- Execute the bit pointers for Output Word #2, doing bit 0 first, then
- Pass all bits that correspond to output discretes through the
direct/reverse logic, then check for a "Bad" value or the LO state
and pass the result to the hardware. This operation may have
already been done independent of block execution for some of the
bits.
- The feedback states for each of the Output bits will be checked and
an alarm generated if necessary. The manufacturer will ensure that
--```,``-`-`,,`,,`,`,,`---
the processing provides for the time delay necessary for the
feedback to correctly represent any recent outputs.
- If the logical node does not process writes to the Output logical
values directly through to the physical outputs, then they will be
processed during the block time of the discrete register block.
- The value of the status byte for each Output bit will be set
according to the following rules:
TBD
- The pulse timer will only operate during the "On" portion of the
Output. When the "Raw" Value is "Set", the physical output will be
turned "On" (powered) and the timer will be started. When the timer
expires, the physical output will turn off but the logical value
will remain "On" (i.e., set if OUTDR = reset).
- The logical value of each bit will be compared to the alarm states
and the appropriate alarms generated. Once an alarm state exists,
the delay off timer will prevent resetting of the alarm state for
the desired amount of time.

693
COMPOSITE PARAMETERS:
- Composite Block Configuration (CBC) (1 byte - static data):
Bit 0 = FB = Discrete: Set if points support feedback checking,
optional by bit, when in Output mode
Bit 1 = FBANY = Discrete: Set if output points support feedback
checking by register.
Bit 2 = FBALL = Discrete: Feedback checking by register: set = on
Bit 3 = GRD = Discrete: Set if points can be optionally by
point tested for shorts to ground.
Bit 4 = GRDANY = Discrete: Set if points can be optionally tested
for a short to ground (all points in
the register).
Bit 5 = GRDALL = Discrete: Ground test by register: set = on
Bit 6 = IO = Discrete: Set if points can be mixed Input and Output
Bit 7 = free
- Composite Block Enumeration (CBE) (1 word - static data):
Bits 0 - 5 = ACDC = Enumeration: AC/DC/etc. supported by all
Bits 6 - B = VOLTS = Enumeration: Voltage level of I/O
supported by all points in
the block.
Bits C - F = free
- Composite Point Configuration (CPC) (1 byte - static data):
Bit 0 = OUT = Integer: Set if point is an Output point (reset if
outputs not supported)
Then, if OUT = Set (an output point):
Bit 1 = OUTDR = Bit: Set if logical value to be reversed
Bit 2 = REBAD = Bit: Set if output reset on "Bad"
Bit 3 = OUTLO = Bit: Set if locked output
Bit 4 = PULSE = Bit: Set if pulsed output
Bit 5 = CHECK = Bit: Inhibit feedback check
Bit 6 = FAILOBEY = Bit: Obey Failsafe if set.
Bit 7 = FAILOUT = Bit: Failure state option, set if hold,
reset if no-power
If OUT = Reset (an Input point):
Bit 1 = SELFP = Bit: Set if provide sense power.
Bit 2 = DEB = Bit: Set if additional debounce time needed
Bit 3 = LATCH = Bit: Set if input to be latched.
Bit 4 = INDR = Bit: Set if raw input value to be
reversed
Bit 5 = INOVR = Bit: Set if input value in override
Bit 6 = INOVRV = Bit: State of override
Bit 7 = free
--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
694
DISCRETE REGISTER BLOCK
Discrete I/O Output

Hardware Output Word 0
Input 0
Output 0
E E
Discrete F F
Points
Algorithm
DW0-0
1 Thru 1
0 DWo-F 0
Output
Output 1
Word 1 E
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Boolean
F
Op'trs.
DW1-0
0 Thru
DW1-F
#1 X 1
0
#2 X
Output
Output 2
X Word 2 E
DW2-0 F
Thru
DW2-F
--```,``-`-`,,`,,`,`,,`---
1
0
Figure 52: Discrete Register, Figure 1, Discrete Register Block

695
DISCRETE POINT
Block Hardware
FAILOUT S Failure Raw Self
OUTDR FAILOBEY S Power Output Power
PULSE S Control Value
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Supply
Physical Connection
--```,``-`-`,,`,,`,`,,`---
D/R Reset Locked Pulse Output

If Output Timer Circuit
Bad
OUTLO
If Out Self
"Power"
REBAD OUTRV V Power
& In
Bit SELFP S vs. Out
In x
OUT S Control
Output
Bit
Pointer DEB S x
"Return"
Logical
Value Check Check
(Output On/Off
System Compare
Word 0)
Alarm
INBOVRV If In LATCH S
* Input Raw
Latch Debounce Input
D/R Input
Circuit
Override Value
INOVR INDR INRV
Delay Alarm Alarm
Off Check State
V
Key Human Access
ALMDELAY S = Option State
Alarm Condition
V=Value
Figure 53: Discrete Register, Figure 2, Discrete Point

696
DISCRETE VALUE FLOW
Logical OUTPUT
Logical
Value
Value
VS VS
INPUT
V V@
User Point
User point - Input Bit Pointer
Transfer
Register
* Row * Input
16 Bit 16 Bit Bit D/ Pointer
Pointe Transfe Point' R Pointer Value
Value Override
r
V l
C C Z Z
C V0 C Z V
V0 Z *V
User Point - Algorithm
User Point
User Point -Output Bit Pointer Transfer
Register
Bit 16 bit 16 Bit

Pointer D/R
Pointer Transfer Pointer
Value Value
VB S C C
VS
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
S C C
V@
Key (Bus Access):
C= Configuration VS = Value n / Status Byte
S = Option state * = PID Track and Device Feedback Only
V= Value n /no status byte @ = conditional
Figure 54: Discrete Register, Figure 3 Discrete Value Flow
SP-50 User Layer Technical Report Logic

--```,``-`-`,,`,,`,`,,`---

697
Human Interface
The sections of this paper are:

BASIC ALGORITHM
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

BLOCK PARAMETERS
Figure 1 - Local HI/F Block
BASIC ALGORITHM:
- This block defines a data base structure to support a simple human
interface (HI/F) that might be permanently mounted in a field
location. Specific instances of the HI/F might display a PV, serve
as a pump On/Off/Auto switch, or display the SP, PV, Output, and Mode
of a PID controller.
- See the attached figure "Local HI/F Block".
- The HI/F block could allow the human to set all or part of a "Status"
variable that describes the status of the display and the operation
that the human needs to perform.
- The block data base will support up to 5 data values. These values
may be fetched from Field Bus or written to the block from Field Bus.
The values are displayed on the hardware of the "Local Human
Interface" device. A value may be changed by the human and used by
the associated control block. The data base includes support for
the direct interpretation of the mode required to allow such changes.
If the operator changes any values, then an entry is generated in the
event buffer so that a higher level device can maintain a complete
operator change journal.
- The block data base includes support for an implementation in which
the local human indicates which set of values he wishes to view out
of a number of sets.
- The block data base is designed to operate with the "force tracking"
and the "feedback" options of the standard PID algorithm.
- The HI/F block will also allow the human to set a discrete command
that is specially structured to interact with the Device Block but
can also be used by other discrete blocks.

- Modes: O/S and Auto - By-pass: no
- Hardware Pointers: one - Set Point Limits: none
Input Required - PV Pointer: no
- Bit Pointers: none - Output Limits: none
- Cascade Structure: no - Boolean Operators: none
SP-50 User Layer Technical Report Human Interface

--```,``-`-`,,`,,`,`,,`---

698
BLOCK PARAMETERS:
- Block Capability (1 byte: required)
- Hardware Pointer (1 byte: required)
- Hardware Status (1 value byte and a status byte for bit 4: required)
- Values + status bytes (optional, up to 5)
- Value Description Words (2 words required for each value supported)
- Display Set (1 word: optional)
- Feedback + status byte (optional, used with "Output")
- Discrete Command + status byte (1 byte: optional)
- Definition of Enumeration Sets (6 words: required)
- 5 Enumeration Strings (all optional)
Block Capability:
Since this block has so many optional features, this byte allows
a higher level device to determine its capabilities easily.
Bits 0-2: integer indicating the number of "Values" supported
Bit 3: set if any "Values" can have active pointers
Bit 4: set if any "Values" can be allowed to be changed
Bit 5: set if "Display Sets" are supported
Bit 6: set if "Feedback" is supported
Bit 7: set if "Discrete Command" is supported
Hardware Pointer:
--```,``-`-`,,`,,`,`,,`---
A single logical node might support multiple sets of HI/F

hardware, each connectable to one HI/F block. Each set in a node
will be numbered sequentially starting with 0. The hardware
pointer is simply an integer that defines the hardware set
connected to this block.
The block will have one hardware pointer. If the node only
supports one set of HI/F hardware, the value of the hardware
pointer may be fixed at 0.
Hardware Status:
The HI/F hardware may allow the human to manipulate the current
value of the "Hardware Status". For a simple display device,
this value may be fixed. The bit meanings are:
Bit 0: Pointers active? (0 = no, 1 = yes)
This status applies to field devices that allow their
display and active Field Bus pointers to be turned off,
either locally or remotely. If the display has no
active pointers, then this bit is reset. If the device
allows remote control of the display, then this bit
could be set as well as read on Field Bus. Remote
control of this bit would allow a high level device to
turn off local displays to speed up Field Bus
communications.
Bit 1: Display Update Rate = fast? (0 = no, 1 = yes)
Note: by definition, a display that has only one
display rate is "slow".
If the device allows remote control of the display, then
this bit could be manipulated as well as read on Field
Bus. Remote control of this bit would allow a high
level device to slow down local displays to speed up
Field Bus communications.
Bit 2: Force "Good" status for discrete command? (0 = no,
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
1 = yes)
This bit is a command to the HI/F block to allow a
"good" status byte on the discrete command byte: it
normally is forced to a "No-Com" status. The discrete
control block that is fetching the command byte and
configured to use it as the HI/F input can be configured
to ignore it when it has a No-Com status. Therefore,

699
this bit is essentially an on/off switch for the

discrete command.
Bit 3: Discrete Command Format: (0 = 3 position,
1 = 4 position)
The discrete control block can operate in one of two
formats. The 3-position format is based on a local HI/F
having control switch positions of Off/On/Auto or the
equivalent. The 4-position format is based on control
switch positions of Reverse/Off/On/Auto or the
equivalent. This bit indicates which format is in use
for purposes of controlling the HI/F display.
Bit 4: Force Tracking of the Feedback? (0 = no, 1 = yes)
If the human is allowed to interact with a PID algorithm
through the force tracking/feedback method, this bit is
the one connected to the force tracking input to the
PID. The status byte for this bit will have:
1) a "No-Com" status unless Bit 5 (see next) is
set.
2) a "doubly wound up" status if the value of this
--```,``-`-`,,`,,`,`,,`---
bit can not be manipulated from the Field Bus.

Bit 5: Force "Good" status for bit 4? (o = no, 1 = yes)
This bit is a command to the HI/F block to force bit 4
"good": it normally is forced to a "No-Com" status.
The PID block that is fetching bit 4 and configured to
use it as the force tracking bit can be configured to
ignore it if it has a "No-Com" status. Thus, this bit
is essentially an on/off switch for the force tracking
option.
Bits 6 & 7: free (default to zero)
Values:
The block may support up to 5 data values. Each data value that
is supported will have an "Output Pointer". The pointer may be
allowed to be configured to be an active pointer that will fetch
a value from the field bus. The pointer may be allowed to be, or
may be limited to being, a writeable pointer that receives a value
from the Field Bus.
Five key parameters will have first priority for the 5 value
locations. Those parameters and their primary locations are:
Value 0 -- Input 0
1 -- Input #1
2 -- Output 0
3 -- Mode
4 -- Eng. Units
Each value will have two "Value Description" words:

Word 0: Numbers:
Bit 0: Value data type variability: 0 = Type is Fixed
1 = Type is Variable
Bits 1-4: Value Data Type. The type codes are:
0 - 15 TBD
Bit 5: Display type variability:
0 = Type is Fixed
1 = Type is Variable
Bits 6-9: Display type:
0 = Variable 8 = Mode
1 = Real 9 = 2-Position Discrete
2 = Integer 10 = 3-Position Discrete
3 = Scientific 11 = 4-Position Discrete
4 = ASCII 12 = Enum. 0
5 = Decimal Equivalent 13 = Enum. #1
6 = Hex. Equivalent 14 = Free
7 = Binary Equivalent 15 = Free
Bits A - C: Positions Left of Point
0-6 = Number of positions to display left of point.
7 = Variable as determined by the HI/F.
Bits D - F: Positions After Point

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
700
0-6 = Number of Positions to display right of point.

7 = Variable as determined by the HI/F.
Word 1: Manipulation
Bits 0 - 2: Value Manipulation Allowed (integer
value: 0-7)
0 = can not change
1 = change under mode control
2 = change freely
3 = Output to Feedback
4-7 = Free
Bits 3 - 5: Mode Control: (integer value: 0-7)
If the Value Manipulation Allowed above is 1, then
the "Mode Control" parameter is used to indicate
the mode that the control block must be in to allow
the HI/F block to accept inputs from the human at
its interface.
This parameter operates on the assumption that

Value 3 is the mode of the control block. That
mode byte is inspected to find the highest priority
bit set. The position of the highest priority bit
is compared to this integer; if it matches, then
this HI/F block can change the value associated
with this value description word.
Bits 6 - 15: Free
Note: if the HI/F provides the ability for the human to
change one or more Values, then it must support an
--```,``-`-`,,`,,`,`,,`---
event buffer in the node and insert an event every
time a Value is changed.
Every time that a new value is placed in a "value"

location, an event will be recorded. If the "value"
locations are changed by a jogging mechanism, then an
event should only be generated after jogging has
stopped for 4 seconds.
Display set (1 word):
Bits 0 - 7 (an integer value 0 - 255)
A particular instance of a HI/F might support an input from
the human that would indicate which of several display sets
he wishes to view. This integer would convey the selected
set's index number to a higher level device that supports the
multiplexing of the data to the HI/F. If this option is
implemented, then enumeration set 5 (see below) might be
implemented to provide descriptors for the display sets.
Bits 8 - F (an integer value 0 - 255)
The maximum number of display set enumerations supported.
Feedback:
Value 2 can be allowed to have a value manipulation code of 3:
Analog Output to Feedback. When that code is used (once maximum
per HI/F block) and that value is selected to be manipulated, the
current value is placed into the Feedback variable and adjusted
according to the command of the operator. The HI/F block will not
set Bit 4 in the Hardware Status word to a "Good" status until it
has a valid number in the Feedback value.
It is expected that a PID algorithm will be configured with (1)

its Feedback pointer configured to the Feedback value of the HI/F
Block and (2) its "Force Manual" pointer configured to Bit 4 in
the Hardware Status byte of the same HI/F Block. The "Force
Manual" pointer can return a set bit with or without a "No-Com"
status. The PID algorithm can be configured to ignore the HI/F if
the No-Com status is set. Otherwise, it will set its Output equal
to the Feedback value.
Discrete Command:
Refer to the Appendix paper "Explanation of the Device Block", p10
for a detailed explanation of the interaction of the HI/F and
Device blocks.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
701
The block may support one 8-bit value called the "Discrete
Command". This value is specifically designed to support the
Device Block. The interpretations of the low-order nibble in this
value are:
- 3-Position Format:
This format is intended for the simplest of all HI/F
devices, a simple 3-position switch (On/Off/Auto). This
format is invoked by the reset state of Bit 3. Bit 3 is,
in turn, copied from Bit 3 in the hardware state word.
The three legal positions will be interpreted as:

+ On/Open (Bit 0 set, bits 1, 2, and 3 reset):
The Device block is set to LO(x) mode and the block
output is set to turn the device On or to Open it.
The value x represents the mode that the block was
--```,``-`-`,,`,,`,`,,`---
in before the HI/F took control: Auto or any mode
with a lower priority.
+ Off/Closed (Bit 1 and 2 set, bits 0 and 3 reset)
output is set to turn the device Off or Close it.
+ Auto (all of bits 0-3 reset):
On transition to Auto at the HI/F block, the mode
of the Discrete block is no longer forced to LO(x).
Usually, the block mode will change to mode (x).
The Setpoint will be at its last state. Since
there will be no transition in the Setpoint, the
Output of the Device block will not change when
the HI/F block is switched to mode (x). However,
if (x) <> Auto, then the Cas or RCas primary may
change the Setpoint.
- 4-Position Format:
This format is intended for a simple 4-position switch
(On/Off/Reverse?Auto). It is invoked by the set state of
Bit 3. Note that the Device Block, with which the HI/F
block will usually be linked, has a special provision to
interpret this format as a 3-position format if
appropriate.
+ On (Bits 0 and 3 set, bits 1 and 2 reset):
output is set to turn the device On.
+ Off (Bits 1 and 3 set, bits 2 and 3 reset):
output is set to turn the device Off.
+ Reverse (Bits 2 and 3 set, bits 0 and 1 reset):
output is set to turn the device On in the reverse
direction.
+ Auto (Bit 3 set, bits 0, 1, and 2 reset):
Same as the 3-Position Format.
- Write-Back Data:
The associated discrete block may write back to the
discrete command of the HI/F block to indicate its current
status. This information is placed in the high nibble of
the discrete command. Its representation is:
+ Bit 4 Set = Can't command On/Open.
+ Bit 5 Set = Can't command Off/Stop.
+ Bit 6 Set = For 3-Position Format: Can't command the
signal that is represented by the middle
position on the 3-position switch.
For 4-Position Format: Can't command
Reverse/Close.
+ Bit 7 Set = Device block in IMan, LO, or LO(Man) mode.
Definition of Enumeration Sets (7 - 16 bit integers)
The block will optionally support up to 5 sets of enumerations for
use in displaying the values. These seven integers will be fixed
by the manufacturer of the device to indicate the maximum number

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
702
of enumerations and their maximum length for each set. The

integers will be arranged in the following order:
Integer 0: Number of Enumerations in Set 0
1: Number of characters in each enumeration of set 0
2: Number of Enumerations in Set 1
3: Number of characters in each enumeration of set 1
4: Number of characters in each enumeration of mode
set (a zero indicates that mode enumerations are
not supported)
5: Number of characters in each enumeration of
discrete set (a zero indicates that discrete
set enumerations are not supported)
6: Number of characters in each enumeration of
display set (a zero indicates that display
set enumerations are not supported)
Note: for all integers that describe the number of characters in
an enumeration, a value of 1 will indicate that the
enumerations exist but they can not be changed from the
field bus.
Enumeration Sets 0 and 1:
These two sets of enumerations supply the characters that will
be used to display the values that have a "Display Type" of 12 or
13. The contents of the two strings may optionally be changeable
from the Field Bus.
Mode Enumeration:
The block will optionally support eight ASCII strings that
will supply the enumerations for the eight primary mode names.
The values may optionally be changeable from the Field Bus.
Discrete Enumeration:
The block will optionally support four ASCII strings that will
supply the enumerations for the four bits in the low nibble of the
Discrete Command. The values may optionally be changeable from
the Field Bus. For example, the four ASCII strings might be
On, Off, Reverse, and Auto.
It is assumed that the Write-Back data will be supported by a

symbology fixed by the specific HI/F.
Display Set Enumeration:
The block will optionally support a set of ASCII strings that will
supply the enumerations for the display sets supported. The
integer in the variable "Display Set Limit" will define the number
of strings allowed. This set can only be implemented if the
HI/F supports display sets and even then is optional.
Status Bytes of all Block Values:
Many of the variables in the data base of the HI/F block will
have status bytes set by the HI/F. The following table defines
the bits of those status bytes:
Bit 4 of
Hardware Discrete
Bit Descriptor Status Values Feedback Command
0 No-Com See Desc. 0 0 0
1 Bad 0 0 0 0
2 Override 1 1 1 1
3 Special 0 1 1 0
4 Failed 0 0 0 0
5 No-path 1 1 1 1
6 ATW-h See Desc. 0 1 1
7 ATW-l See Desc. 0 1 1
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

--```,``-`-`,,`,,`,`,,`---

703
LOCAL HI/F BLOCK
Local HI/F Block

Local HI/F Hardware
Value 0 Output 0
Display Value
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Select Value Change Value 1 Output 1
Jog Value
Jog Mode
Value 2 Output 2
Discrete command:
Set Command Value 3 Output 3
Display feedback
Set Hardware Status Value 4 Output 4
Feedback X Output 5
(no pointer)
Discrete X Output 6
C d (no pointer)
Hardware X Output 7
St t (no pointer
Figure 55: Human Interface, Figure 1, Local HI/F Block
--```,``-`-`,,`,,`,`,,`---

704
Logic
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
--```,``-`-`,,`,,`,`,,`---

BIT POINTERS
EXPLANATION OF LOGIC EVALUATION
DATA BASE DETAILS
Figure 1 - Logic Algorithm
Figure 2 - SPx Logic - Version 0 - Independent
Figure 3 - SPx Logic - Version 1 - On/Off/Rev.
Figure 4 - Logic Block - Instruction Definition Word
Figure 5 - Logic Block - Detail Words
Figure 6 - Logic Icons - Basic Shape
BASIC ALGORITHM:
- This algorithm provides step logic evaluation which may be
represented in either Boolean logic or ladder logic format.
- See attached figure "Logic Algorithm".
- Two 16 bit Input Words and three 16 bit Output Words.
- Standard cascade structure for handling a Setpoint whose bits can
then be accessed by the program.
- A set of logic steps that defines how to set 8 bits in the "Output"
word and define the movement of the 8 bits in Output to Output Words.
- The logic evaluation can use one of two built-in logic procedures to
manipulate the Setpoint bits while moving them to the Output: one is
oriented toward simple bit by bit override while the other is
oriented toward the requirements of the 3-bit discrete Setpoint.
These two procedures provide full support for discrete cascades and
all status byte information.
- Data flow configured using "Bit pointers" that can connect to bits in
+ 2 Input words - 16 bits each
+ 3 Output words - 16 bits each
+ 5 local logical node registers - 16 bits each

- Modes: all except ROut - By-pass: yes, Setpoint to
(Man resets, Output, Bits 5-7
changes to Auto) - Setpoint Limits: no
- Hardware Pointers: none - PV Pointer: yes, default to
- Bit Pointers: yes Output, Bits 5-7
- Setpoint Ramping: no - Boolean Operators: no

705
ALGORITHM OPTIONS:
- OUTTRK = logical: set = Setpoint tracks Output in IMan/LO mode.
- RIMAN = logical: set = program runs when the block is in IMan mode.
- RLO = logical: set = program runs when the block is in any LO mode.
but the Output Word Bits in LO can not change.

- Logic defined through specification of step instructions which may be
used to support Boolean logic or ladder logic implementation.
Override capability is provided for each external logic input.
BIT POINTERS:
1) the inputs to form the Cas setpoint.
2) the connections to the logic instructions.
3) the connections from the 8 bits of the Output word to their
destinations.
Three input bit pointers are provided for the Cas setpoint definition. If the
first pointer points to the Cas transfer location, then the Cas transfer location
--```,``-`-`,,`,,`,`,,`---
will be used in Cas mode. The configuration for the three pointers consists of
three copies of the bit pointer configuration word. The three words are combined
under one parameter, using the auto-formatting procedure, for addressing
purposes. The word for bit 0 of the setpoint is reported first.
The configuration of the logic instructions, which defines all of the rest of
the bit pointers in this algorithm, is given in detail below.
EXPLANATION OF LOGIC EVALUATION:

The evaluation of the instruction steps supported by this block may be
represented in a Boolean logic or ladder diagram format.
Since this algorithm is designed to support both the Boolean and Ladder
presentation, it is necessary to clarify the notation that will be used in this
paper. The word "instruction" will be used to refer to each of the logic steps
used to calculate the final result of the algorithm. In the ladder diagram, each
of the individual operators on each rung is an instruction. A vertical line in
the ladder diagram (other than the power and ground rails) is an instruction. In
addition, there will be three types of instructions that will be represented by
"boxes" in the ladder representation. In a Boolean representation, each
individual "box" or drawing icon can be one or more instructions. The word
"string" will be used to refer to all of the logic that lies between fetched
values and a particular intermediate value. In a ladder diagram, one string lies
to the left of a single coil and 2 or more strings connect to the left side of a
vertical line.
The program is modeled and described to operate as if it uses a "stack".

Each entry in the stack contains a binary value and its status byte. Each
instruction removes a defined or configured number of values from the stack, does
its calculation, and, based on its definition, may return 0 to 3 values to the
stack.
The 7 classes of instructions are:

1) a stack "PUSH" (or entry to the stack). This corresponds to the
start of a Boolean logic string or to the first instruction to the
right of the power rail in a ladder diagram.
2) a Boolean "AND". This removes one value from the stack, AND's it

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
706
with a fetched value, and pushes the result onto the stack. A
compound AND with more than 2 inputs is supported.
3) a Boolean "OR". This removes two values from the stack, OR's them,
and pushes the result onto the stack. A compound OR with more than
2 inputs is supported.
4) a Boolean "XOR". The 2-input XOR removes two values from the
stack, XOR's them, and pushes the result onto the stack.
5) a "VOTE" instruction. This compound instruction removes three or
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
more values from the stack and compares the number of inputs that
are set with configured high and low limits. If the number of set
inputs is within the limits, it sets the result and pushes it onto
the stack. Outside of the limits, it resets the result and pushes
it onto the stack.
6) two versions of "SPx" logic - the logic for each is defined below.
Each version removes a configured number of values from the stack
and executes its logic. It places three values back on the stack.
No instructions other than terminators can follow the SPx step.
7) a "TERM" or terminator. This corresponds to the end of a Boolean
logic string or to the coil in a ladder diagram. In this function
block, the terminator will always reference and define the next
available bit in the 8 bit string called "Output" unless it follows
a SPx operation. In that case, the first TERM after the SPx will
define bit 5 in Output.
The two SPx instructions are designed to facilitate the use of this block in
discrete cascades. The two versions are called SPx-0 and SPx-1. The first is
intended to provide simple control over the Setpoint bits while providing the
ability to pass cascade information from the Output back to the Setpoint. The
other is specifically intended for use in passing the 3-bit Setpoint or Output of
a device block. Note that the 3-bit value has the requirement that one, and only
one, of the three bits be set at any time. The SPx-1 logic enforces that rule.
The SPx-0 logic is defined in the ladder diagram shown in the drawing "SPx
LOGIC - Version 0 - Independent". This logic allows the program logic to
override the state of any or all of the Setpoint bits and force either a Set or
Reset condition. The following provides additional explanation to accompany the
drawing:
1) SP0, SP1, and SP2 are the three bits in the Setpoint
2) S, s-1, and s-2 are the three bits pushed to the stack by the SPx
logic. The value s is the top-most value in the stack. The 1 to
3 TERM instructions that follow the SPx instruction move the values
to bits 5, 6, and 7 in Output and define the bit pointers for those
bits. The "s" output will always correspond to Bit 5 in Output.
3) The lower 6 coils represent six status bits in the three Setpoint
status bytes: the wound up high and the wound up low bits in each of
the bytes.
4) The SPx-0 function uses 6 input values.
SPx0: if set, then override SP0 to Reset.
SPx1: if set, and SPx0 is Reset, then override SP0 to Set.
5) Out Bit Status: a shorthand reference. Consider the first such
rung: <> WUH, Bit 0.
The coil determines the WUH status in the status byte of bit
0 in the Setpoint. The Out Bit Status on that same rung is
the WUH status in the bit pointed to by the first pointer for
Output, bit 5. Each of the other rungs has a corresponding
definition.
The SPx-1 logic is shown in the ladder diagram in the drawing "SPx LOGIC -
Version 1 - On/Off/Rev.". This logic ensures that the Output always has one and
only one bit set. It allows the SPx bit pointers to force a device to retain its
present state or to turn off but it does not allow the logic to turn a device
"On" in either direction. That must be done from the associated Device Block.
The logic instructions shown in the drawing are the following:

--```,``-`-`,,`,,`,`,,`---

707
1) SP0, SP1, SP2, and all but the top 2 coils are as defined above.
2) Temp1 and Temp2 are temporary variables to facilitate the
expression of the ladder. They need not be stored (or even exist)
and can not be referenced by any other block instructions.
3) Old Bit 0: Bit 0 of the Setpoint corresponds to Bit 5 of Output.
That bit has a pointer. (If it has 2 pointers, this reference is to
the first of the 2.) It points to a particular bit in an Output
Word. Old Bit 0 is the value of that bit (it is automatically the
value that was obtained on the prefetch of the Output Word because
it has not yet been updated for this cycle).
4) Old Bit 2: similar to Old Bit 0.
5) SPx0: if set, then prevent transition to "On"
--```,``-`-`,,`,,`,`,,`---
SPx1: if set, then force the "Off" state.

SPx2: if set and IF SPx1 is reset, then the "On" or "Reverse" state
will be locked in if it is currently existing.
SPx3: if set, then prevent transition to "Reverse".
6) Out Bit Status: same as above.
The rules of the block result in the SPx logic automatically operating only
on bits 5, 6, and 7 of Output. In addition, there can only be zero or one
instance of SPx in a program. Only TERM instructions can follow the SPx logic
and no more than 3 of them. If fewer than 3 TERM instructions follow the SPx
logic, the s-2 (and possibly s-1) values are left on the stack. If s-2 is left
on the stack, "Old Bit 2" is considered reset. Since no pointers will be formed
for their "Out Bit Status" calculation, they will be considered to be not failed,
not in LO, but with the No-path status set. If there is no pointer for what
would have been Output bit 6, it will be considered to be not wound up. For what
would have been bit 7, it will be considered to be doubly wound up.
User Set Parameters:

+ LENGTH = integer = maximum length of the ladder representation
of the logic expressed in terms of horizontal
rows of logic.
+ Instruction Set = 128 byte (max.) string including the auto-
formatting procedure header.
+ Setpoint_Config = 3 bit pointers for Setpoint.
= 6 byte string plus the auto-formatting
procedure header.
External Parameters:
+ Input #1 = Input1(n) = up to 16 bit word
+ Output = Out(n-1) = 8 bit string of logic output
Note: bypass automatically goes to bits 5-7 of Out(n-1) .
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Stored Internal Parameters:

Vote_Min = an integer that defines the minimum number of
inputs to a Vote block for which its output will
be set.
= initialized to 1 at the beginning of each block's
cycle.
Vote_Max = an integer that defines the maximum number of
inputs to a Vote block for which its output will
be set.
= initialized to 1 at the beginning of each block's
cycle.

708
A parameter containing the states and stati of all entries

to the stack and to the bits of Output (includes the auto-
formatting procedure header).

Init._Status = set if present execution is first one after
leaving O/S, IMan, LO, or Man Mode.
Instruction_Count = integer (see p 18).
Stack_Count = 0 to LENGTH
= number of entries in the stack (see p 14).
Stack_Counter_Limit = 0 to LENGTH = maximum limit on
Stack_Count.
Num_Inputs = integer = total number of inputs (see p 14).
Num_Pointers = number of configured pointers (see p 14).
Num_Set = integer = number of inputs that are set (see p 18).
Num_Set&Bad = integer = number of inputs that are both set
and marked "Bad".
Num_Reset&Bad = integer = number of inputs that are both
reset and marked "Bad".
Num_Set&Process = integer = number of inputs that are both
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
set and from the process.

Num_Reset&Process = integer = number of inputs that are both
reset and from the process.
SPx_Done = logical
= initialized to reset.
= indicator that an SPx instruction has been
encountered (see p 11)

- Two Input words and three Output words fetched if necessary
- The "Bad Input" alarm will be set based on all bits input to the
logic and Setpoint (both input and output words), not on all bits in
the input and output words themselves.
- In RCas mode, the Setpoint is obtained from the RCas transfer
location.
- In Cascade mode, the Setpoint can be configured as any three
- In Auto mode, the Operator or higher level device sets the Setpoint.
- Man mode is automatically set back to Auto but the algorithm
initializes (i.e., Init._Status is set).
- LO on all bits to be written, even if not written this time because
of the Write-On-Change option, causes the whole block to go to LO
mode (However, this option can be inhibited: see "Suppress LO" in
the instruction definition word).
- If the SPx-1 feature is used, then the block will be placed into LO
mode if:
--```,``-`-`,,`,,`,`,,`---
1) one of the three destination bits in the Output words has

an LO status and has a value of 1 ("On").
OR
2) two of the 3 destination bits in the Output words have an LO
status.
OR
3) one of the destination bits in the Output words has an LO
status and both of the other bits have a No-path status.
If the SPx-0 feature is used, then the block will be placed into LO
mode if all three bits are in the LO state.
- IF SPx-1 is used, then IMan is set if two of the Setpoint bits that
are configured to pass through the logic can not do so because the
configured Output bits are doubly-wound-up. IF SPx-0 is used, then
all three of the Setpoint bits must to doubly-wound-up to cause the
IMan mode.
- IF bypass, then Setpoint is passed to bits 5-7 of Output; the program
is then executed but those 3 bits can not be overwritten.
- Results of logic instructions drive the bits in Output.

709
- All instructions in the program except the output pointers on the

TERM instructions will be solved in order. Specifically, all
pointers that move Output bits to Output Words will be executed later
but pointers that connect unlatching TERMs to latching TERMs will be
executed. The program instructions will be formed according to the
commands defined below.
- The Output pointers will be executed to move the states and stati of
the bits in the parameter Output to the designated targets in
Output Words after all other instructions are executed.
- Output Words are stored after execution with algorithm-set masks.
Mask bits are set only for bits targeted by pointers, or optionally,
only when the value changes (see "Write-Only-On-Change" option in the
Instruction Definition word).

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
- All standard status bit responses and setting, especially:

+ Bad Inputs to logic:
All bad states flow through the logic if the state of the
data bit was significant to the result of the logic step.
The significance will be determined the same as is defined
for the Boolean Operator (see the paper "Standard Block
Functions") and as defined below. However, bad stati can
optionally be ignored or overwritten: see "Detail Word
(Pointer)".
--```,``-`-`,,`,,`,`,,`---
+ Bad Output:
Bad value on prefetch handled the same as Inputs. Bad values
after solution are stored as Bad unless configured to a
location that does not have a status byte, then not stored.
This rule also can be overridden - see "Detail Word
(Pointer)".

The following are the normal responses to unexpected conditions in the
control scheme. However, the pointers that are used extensively in this
algorithm allow all of these actions to be inhibited: see "Pointer Options" in
the Instruction Definition word and "Detail Word (Pointer)".
bit 2: (Override)
No direct effect but the bits are available to the logic and flow
through. The method of calculating the status of the result will
be determined the same as is defined for the Boolean Operator (see
the paper "Standard Block Functions") and as defined below.
bit 3: (Special) - see LO rules above.
bit 4: (Failed)
If an SPx function is being used and an Output Word bit that is
pointed to by the first Output bit pointer for bits 5, 6, or 7 has
Failed, then the Setpoint bit in the position corresponding to the
Output bit pointer will be marked Failed. If an Output bit
pointer is null, its corresponding Setpoint bit will not be marked
failed. The standard handshake using bit 5 will be done on a
bit-by-bit basis. If SPx-1 is being used, all bits in the
Setpoint will be marked "Failed" if at least 1 bit is "Failed" and
all of the other bits are either "Failed" or have a "No-Path"
status.
bit 5: (No-path)
If an SPx function is being used and an Output Word bit that is
pointed to by the first Output bit pointer for bits 5, 6, or 7 has
its No-Path status set, then the Setpoint bit in the position
corresponding to the Output bit pointer will be marked No-Path.
If an SPx function is being used, the logic for back-calculating
the ATW bits for the Setpoint is defined in the SPx definitions.

710
Otherwise, the ATW bits are reset in the Setpoint and inputs.
DATA BASE DETAILS:

- The Setpoint and the Setpoint transfer locations, the Output, and the
five I/O words are standard Field Bus string parameters with status
bytes for most bits.
- I/O Words can be pointed to any on-block, on-node, or off-node

parameters (Tag.Parameter) except floating point data types. They
will return up to 16 bits (the low order bits if the value is more
than 16 bits long).
- "Bit Pointers" are used to define the source or destination of

individual bits within the block. The input bit pointers can point
to any on-block bit or to bits in the special local logical node
registers. Input bit pointers are used for forming the Cas setpoint
and the connections to the logic instructions. Output bit pointers
are used to form the connections from the bits in Output to their
destinations in Output words. In most cases, they can point to any
of the three on-block Output words or to the special local logical
node registers. Most of these bit pointers include the option to
invert the state of the discrete that is transferred.
In the special case of the unlatching TERM, its bit pointers can only
point to latching TERMs and can not invert the state.
- Three input bit pointers are provided for the Cas setpoint
definition. If the first pointer points to any of the 3 value bits
in the Cas transfer location, then the Cas transfer location will be
used as the source of the setpoint in Cas mode. Otherwise, the three
pointers can be pointed to any on-block named parameters including,
of course, the Input and Output words. Note that the first bit can
not be obtained from the Cas Transfer Location and the second and/or
third bits obtained from a different variable. The pointers include
the ability to select one bit from the low 16 bits in the named
parameter.
- The block logic instructions are designed so that they may be

represented in either a Boolean or ladder logic format in a
configuration device. In order to meet that objective, the
configuration must follow the following restrictions:
1) only the provided instructions can be used.
2) no more than one instance of the SPx logic can be used. A
configuration alarm will be set and the block placed in O/S
mode if Output bit 5 has already been defined when the SPx
logic is run.
3) the logic must be limited to the size annd stack restriction to
be defined below.
A higher-level device can represent the logic instructions using any

method desired. The logic instructions themselves may be displayed.
Alternately, the traditional Boolean and ladder logic drawing
techniques may be used. If the Boolean technique is used, the
following constraints have been placed on the diagram by the above
rules:
1) no lines in the Boolean drawing may cross.
2) no intermediate calculated value may be used in more that one
succeeding instruction.
In a similar fashion, the above rules have placed the following
constraints on ladder logic diagrams:
1) instruction strings can be combined together but they can not
continue independently after combination. For example, the
logic driving Temp1 in the drawing "SPx Logic - Version 1 -
ON/Off/Rev." is not valid for configured logic.

--```,``-`-`,,`,,`,`,,`---

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
711
In order to assure interchangeability, all Standard implementations

of this block will follow the following solution order:
1) the output of the first Boolean instruction must be followed to
the next block in the string. Although the concept of a stack
for intermediate values need not be implemented, the
limitations of the stack implementation on the solution order
must be simulated.
2) the left-most instruction on the top rung of the ladder must be
translated first, then horizontally across the rung until a
coil is encountered. If a vertical line or box is encountered
before a coil, the merging horizontal string must be below the
original string. The merging string is defined starting with
the power rail (PUSH optionally followed by other
instructions), then joined by the vertical line or box to the
intermediate value calculated earlier on the upper horizontal
line.
- Each instruction in the program starts with a 16 bit word called the
Instruction Definition word. It is diagrammed in the drawing labeled
"Logic Block - Instruction Definition Word". The three high order
bits provide for a simple parsing of the program. They identify "not
configured" instructions (one word) or the number of words comprising
the total instruction (a value between 1 and 6). The structure of
the low-order 12 bits of the definition word is in one of two forms
as shown and as differentiated by the state of bit CH.
Most of the instructions use at least one detail word in addition

to the definition word. That detail word is usually a "pointer".
The pointer is detailed at the bottom of the drawing "Logic Block -
Detail Words". Although the format is detailed here, it is
identically the same as a standard bit pointer word. Note that bit
pointers include several independent options:
1) invert the value
2) force the value to "good" and a value of 0, 1, or the previous
value.
3) change a "Bad" value to "Good" and reset it, set it, or keep
the previous value.
When the pointer is used, additional options, not available for
--```,``-`-`,,`,,`,`,,`---
normal bit pointers, are selected using bits in the definition word.
These additional options provided by the Instruction Definition word
for input pointers are:
@ Recognize the No-Com status as bad (meaningless if the next
option clears bad)
@ Clear a Bad status of the bit.
@ Clear an Override (i.e., not-from-process) status for the
bit.
@ Set an Override status for the bit.
These optionns operate oon the fetched bit, not on the source bit.
The Instruction Definition word provides for additional manipulation

of the input value using the "Input State" value. Using this option,
the value of the input can be configured to be set only on a rising
edge, falling edge, or a transition of the fetched value.
The additional options for output pointers are:

@ Suppress the propagation of a LO status backward to the
logic (has no meaning for Pointer #1).
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
@ Suppress the propagation of the failure and No-path

information backward to the logic (has no meaning for
pointer #1).
@ Write the value only when it changes.
@ Increment the value of the target instead of setting the
value. The value to be incremented is the set of bits
consisting of the target bit AND ALL MORE SIGNIFICANT
BITS in the targeted Output word. The value is incremented
only if the value of the bit in Output is set and written.

712
The VOTE instruction uses the detail word to allow the user to
configure extra information for the instruction's operation. The
operation of this detail word will be explained below.
--```,``-`-`,,`,,`,`,,`---
One type of termination instruction supports two detail words; one of

them being defined as a setpoint for a timer associated with the
delay on TERM and the delay off TERM. Its format is shown at the top
of the detail drawing (a simple unsigned 16 bit integer!).
- The instructions for the logic are all stored in a single parameter
that can be up to 128 bytes long. The parameter will have the
auto-formatting structure. Thus, the first 4 bytes will be a header.
The fifth byte will be the Instruction Definition Word of the first
instruction.
- The following description of the program instructions will refer to

the attached diagram "Logic Icons - Basic Shape". This drawing is
offered as a proof of existence of a method of representing both the
Boolean and ladder logic icons for the program instructions. Any
method of representation can, of course, be used by the actual
higher-level devices. In that diagram, there are several drawing
conventions that must be defined. First, the letter "B" is shown in
6 of the icons. This represents the input value as obtained by the
instruction's input pointer(s).
All of the icons for both Boolean and ladder drawings contain arrows
with the letter "s". In all cases in which the arrow flows into the
icon, s is the value found on the top of the stack. In all cases in
which the arrow flows out of the icon, s is to be placed on the
stack. Six icons show an input arrow labeled "s-1": this
represents the second value on the stack being used as an input. In
a similar fashion, "s-1" and "s-2" on output arrows represent the
second and third value on the stack (s-2 is the "deepest" of the
three values in the stack, i.e., s-1 is pushed to the stack before
s). It is assumed that all of the s's and their arrows would be
removed from the final diagrams.
Three of the Boolean icons and one of the ladder icons have jagged
lines in their drawings. These lines indicate that that drawing may
be a portion of an icon: it may be joined with another portion
depending on the previous or next instruction in the program.
The following paragraphs detail each of the 7 classes of

instructions:
+ PUSH
The PUSH instruction uses a single bit pointer to fetch a bit
(with its status byte) and load it onto the stack. The
inversion of the value, if specified in the bit pointer, is
assumed to be shown on the Ladder drawing as a slash across
the "contacts". The Boolean drawing might show it as the
inversion of the input arrow: a circle at the point of the
arrow.
The PUSH instruction will check SPx_Done. If it is set, the

configuration error notification will be set and the block
will be set to O/S mode.
The basic diagram of the Boolean icon for the PUSH emphasizes
the idea that the PUSH is normally followed by another
instruction whose icon merges with that of the PUSH. If the
previous instruction was a PUSH, the symbol is located under
the previous one.
If there was a previous instruction on this string but it was

not a PUSH, the result from that previous instruction is
located above the "B" shown.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
713
The "B" flows into the left side of the next instruction's
icon, replacing the "s" shown. The SPx icon already shows
the "B".
The Ladder icon for the PUSH is always as shown.
The PUSH instruction will almost always be the first

instruction in the program and can never be the last
instruction. It must always have one, and only one, detail
word (pointer). Hence, bits C-FH in the Instruction
Definition word must = 0100B.
+ AND
The AND instruction uses a single bit pointer to fetch a bit
(with its status byte), "AND" it with the value on the top of
the stack, and place the result onto the stack. More details
on the exact calculation of the status byte will be given
below.
The AND instruction will check SPx_Done. If it is set, the

The basic diagram of the Boolean icon for the AND is shown.
If the previous instruction was an AND, the top of the block
is opened and joined with the bottom of the previous icon
portion. If the next instruction is not an AND, the bottom
of the block is closed, the exit arrow moved up to the right
side, and the block labeled as an "AND".
--```,``-`-`,,`,,`,`,,`---
The Ladder icon for the AND is always as shown. Notice that
this icon and the icon for the PUSH differ only in that the
PUSH originates at the power rail.
The AND instruction must always have one, and only one,
detail word (pointer). Hence, bits C-FH in the Instruction
Definition word must = 0100B.
+ OR
The OR instruction does not have a bit pointer; it simply
OR's together the top two value on the stack and puts the
result back onto the stack. More details on the exact
calculation of the status byte will be given below.
The OR instruction will check SPx_Done. If it is set, the

The Ladder representation for an OR is always a vertical line

that joins a lower instruction string to the next higher
instruction string and terminates the lower string. If there
are n OR instructions in series, the vertical line will join
n+1 horizontal lines of instructions and result in one value
being placed back onto the stack. The final ladder
representation would be a single vertical line with a
vertical length equal to n times the vertical spacing between
strings.
The Boolean icon representation for the OR is built up

depending on the previous and succeeding instructions as
follows:
1) If the previous instruction was not an OR, the icon
for the OR inputs the last two intermediate strings.
2) if the previous instruction was an OR instruction,
the previous icon is extended upward to accept one
more unterminated string. The s input then

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
714
represents the value passing upward from the previous

instruction.
3) If the next instruction is not an OR, the exit arrow
is moved to the right side, the top is closed, and
the block is labeled "OR".
An OR block in a Boolean drawing with one or more fetched

input bits will require several program instructions.
Fetched inputs must be:
1) below the previous logic string in the drawing
AND
2) "PUSHed" onto the stack before they can be used by
the OR.
For example, assume a logic string has produced an

intermediate value "s" where s is now the top value
on the stack. If s must be OR'ed with a fetched bit,
the bit will be "PUSHed" onto the stack (pushing the
intermediate value down to "s-1"). Then the OR is
executed, using the top two values on the stack.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Note: The OR instruction might have been designed to

optionally include one pointer that would define the
source of the input shown as "s" on the basic shape.
This option would only have been useful for values
fetched, as opposed to values that needed
preprocessing. Also, in order to maintain consistency
with traditional ladder diagramming, it would have been
illegal for an OR instruction preceded by an OR
--```,``-`-`,,`,,`,`,,`---
instruction. The added complexity was not considered
worthwhile.
+ XOR
The XOR instruction always has two, and only two, inputs. It
is represented in both the Boolean and the ladder drawings by
a two-input box as is shown. The output of the XOR will be
set if one, and only one, of the inputs is set.
The XOR instruction will check SPx_Done. If it is set, the

Note: a 2 input XOR can be represented in a ladder diagram as

a PUSH, AND, PUSH, AND, and an OR. Its "correct"
representation would be a PUSH, PUSH, XOR. If ladder
source code uses the first description, the equivalent
Boolean diagram will be generated with that same
notation; it will NOT recognize it as an XOR.
+ VOTE
The VOTE instruction is drawn essentially identical to the OR
except that it is represented on the Ladder diagram by a
block or box, instead of a single vertical line. The ladder
representation of "n" VOTE instructions in series would be a
single vertical box with a vertical length slightly greater
than "n" times the vertical spacing between strings. The
value of "n" can not be less than 3.
The VOTE instruction will check SPx_Done. If it is set, the

The configuration will determine the values of the minimum

and maximum number of inputs that can be set while the output
is set. Those numbers can be entered as part of any VOTE
configuration by including a detail word. That detail word
will contain the maximum value in the high 8 bits and the

715
minimum value in the low 8 bits. The values will remain

through the rest of the current cycle for this function block
unless changed by another Detail Word (VOTE).
The exact method of calculation of the VOTE will be defined

below.
+ SPx
The SPx functions use 4 or 6 inputs. The inputs can be on
the stack when the instruction is encountered and/or they can
be specified by pointers attached to the SPx instruction. It
is not necessary that all of the inputs of the SPx function
be supplied: they will be considered "reset" if not
supplied.
Note: The inputs for the SPx functions might have been
designed to have the inputs all placed on the stack
with PUSH instructions. Then a SPx instruction that
had no pointers of its own could use the stack values.
However, each PUSH instruction would have used two
instruction words while a pointer attached to the SPx
instruction itself only uses one word. Since many
inputs are not calculated values, it is much more
efficient to use the SPx pointers.
The SPx instruction will check SPx_Done. If it is set, the

will be set to O/S mode. If it is reset, it will set it.
Which inputs are obtained from the stack versus which inputs
--```,``-`-`,,`,,`,`,,`---
are obtained from the pointers and in what order will be
determined by convention, not by configuration. The
following discussion will define the convention. The
discussion will use the following three variables:
Let Num_Pointers = number of configured pointers
= (number of instruction words shown
in bits DH-FH of the Instruction
Definition Word) - 1.
Let Num_Inputs = number of SPx inputs
= 6 if SPx-0
= 4 if SPx-1
Let Stack_Count = number of entries on the stack
If any inputs are on the stack, it will be assumed that SPx0

was placed on the stack first, then SPx1, etc. up to
"Stack_Count" inputs. Then, the pointers will be used in
order to obtain the remaining inputs (assuming that
Stack_Count plus Num_Pointers is less than, or equal to,
Num_Inputs).
If Stack_Count plus Num_Pointers is less than Num_Inputs, the

higher numbered SPx inputs (i.e., SPx6, then SPx5, then SPx4,
etc.) will be considered "reset". If Stack_Count plus
Num_Pointers is greater than Num_Inputs, a configuration
error notification will be set and the block mode set to O/S.
As an example, assume SPx-1 is encountered (has 4 inputs)

while Stack_Count = 2 and 1 pointer is configured. Then:
SPx0 = s-1
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
SPx1 = s
SPx2 = Pointer value
SPx3 = reset
The TERM instructions define the terminations of the strings

or rows of logic, in order from bit 0 of OUTPUT to bit 7 of
OUTPUT. However, the SPx instruction will check the index
for the bit number as follows:

716
1) if the index is less than 5, set it to 5

2) if the index is greater than 5, then set a
configuration error notification and O/S mode.
The Ladder icon for SPx is always as shown if Num_Pointers =

Num_Inputs. If Num_Pointers < Num_Inputs, the inputs
starting with SPx0 will be supplied by stack values that have
been defined by earlier instructions. The icon will be a
vertical box that joints up to 4 (or 6) horizontal rows of
strings together and supplies "power" under logic control to
up to three rows leaving the box on the right.
The diagram of the Boolean icon for the SPx function is also
shown as if Num_Pointers = Num_Inputs. If Num_Pointers <
Num_Inputs, then:
1) if some of the inputs are to be obtained from the
stack, the algorithm will use the above relationship
to identify the input values obtained from the stack.
2) if some of the inputs are not specified, the
algorithm will consider them reset - their
representation on the diagram is not specified.
The only instructions that can follow the SPx function are
TERM instructions and they must have a type value of 0 to 2
(TERM, Delay On TERM, Delay Off TERM). If there are three
TERM instructions following the SPx, then all three of the
--```,``-`-`,,`,,`,`,,`---
logic strings from the SPx function box can be completed. If
there are less than three, then the lower rows from the SPx
box (i.e., bit 7 or bits 6 and 7 of OUTPUT) are deleted.
+ TERM
The TERM instruction has bit CH in its Instruction Definition
word set. It can include zero, one or two detail words. It
represents the moving of the top value (with its status byte)
from the stack into the next available bit in Output and the
writing of the value to the appropriate bits in the Output
Words.
Note that these pointers write their values; the pointers in

all of the other instructions read their values. The
pointers for a TERM instruction can only point to bits in
Output Words or Logical node words. In the special case of
the Unlatching TERM, they can only point to a Latching TERM.
The basic diagrams of the icons for TERM are shown. In the
Boolean drawing, it is simply the last block in the logic
string. In the ladder, it is the "coil". In general,
there can be zero, one, or two pointers that leave the
Boolean or ladder diagram to place the results into the
bits of Output Words 0-2.
The TERM instruction is responsible for checking to be sure

that, in most cases, no values are left on the stack after
it executes. This check will be defined in the next section
of this paper.
The TERM instruction has five types. The individual type is

defined by the Termination Type as defined in bits 0-3 of the
Instruction Definition word. They are:
TERM
a simple termination.
There can be 0 to 2 pointers to Output words but

the number must be consistent with the number
defined in bits D-FH in the Instruction
Definition word.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
717
Delay-On-TERM
Has a detail word that defines the time (in
milliseconds) for which the change to "On" in the
value of the bit is to be delayed. If the input
changes to "Off" before the time expires, the
counter will reset and the output will never turn
"On". The timer is reset if Init._Status is set.
The first detail word must be present. It

indicates the time to be used by the instruction.
The second detail word (a pointer) is optional
but the number of words must be consistent with
the number defined in bits D-FH in the
Instruction Definition word.
Delay-Off-TERM
Has one detail word that defines the time (in
milliseconds) for which the change to "Off" in
the value of the bit is to be delayed. If the
input changes to "On" before the time expires,
the output value will never change to Off and the
timer will be reset. The timer is reset if
Init._Status is set.
--```,``-`-`,,`,,`,`,,`---
The first detail word must be present. It

indicates the time to be used by the instruction.
The second detail word (a pointer) is optional
but the number of words must be consistent with
the number defined in bits D-FH in the
Instruction Definition word.
Latching TERM
When the value is set, it will remain set until
reset by an unlatch command from another
termination. Both the latching and the
unlatching will be rising edge triggered. Both
the latch and unlatching signals are initialized
to the reset state if "Init._Status" is set.
Then the new states are calculated. If the input
value is still on when an unlatch signal is
received, the output will go to reset and will
remain reset until the input value changes to
reset, then changes to set again. If the unlatch
signal is on when the input signal transitions to
set, the output will transition to set. It will
stay set, independent of its input, until the
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
unlatch signal resets, then sets again.
A latching TERM will use the unlatch signal that

exists at the time that the latch TERM
calculates, not a value calculated in an
unlatching TERM later in the instructions.
There can be 0 to 2 pointers to Output words but

the number must be consistent with the number of
words defined in bits D-FH in the Instruction
Definition word.
Unlatching TERM
When the value is set, it will cause a Latch type
termination to unlatch. The particular latch
type termination(s) is defined by the pointer(s).
The pointer(s) for this type of TERM can only
point to an on-block Latching type TERM
(identified as bits in OUTPUT). In addition, the
value of the unlatching TERM can not be inverted;

718
it is always "On" or "powered" to unlatch.
There can be 1 or 2 pointers to Latching coils

but the number must be consistent with the number
of words defined in bits D-FH in the Instruction
Definition word.
After all instructions are done, Init._Status is reset.
- There will be two size constraints imposed in addition to the limit

of 62 words of instructions. These two limits are intended to
constrain the configuration so that a human interface can include
generic ladder and Boolean displays for the block. The ladder
equivalent of the configuration is limited to 8 logic instructions
plus the coil in width and a configured number of logic strings in
length (defined as "LENGTH" above).
The program limits and the details of several of the instructions

will be described based on an implementation model. There is no
requirement that that particular design be used. It is presented
here only as a means of defining the functionality and to offer an
existence proof for a solution. Any specific implementation in a
Standard Function Block must yield the same functionality.
The model of the program implementation uses a first-in, last-out

push down stack that is "LENGTH" deep. Each level of the stack
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
contains the following information:

1) a single bit value
2) a status byte for that bit
3) a counter that will be called the "Instruction_Count". This
value can not be accessed over Field Bus.
There are eight other separate integers that are not addressable on
the Field Bus. They are defined only for purposes of defining the
calculation method:
1) Stack_Count = 0 to LENGTH = number of entries in the stack.
= initialized = 0
2) Stack_Counter_Limit = 0 to LENGTH = maximum limit on
Stack_Counter.
= initialized = LENGTH
3) Num_Inputs = integer = total number of inputs.
= initialized = 0
4) Num_Set = integer = number of inputs that are set.
= initialized = 0
5) Num_Set&Bad = integer = number of inputs that are both set and
--```,``-`-`,,`,,`,`,,`---
marked "Bad".
= initialized = 0
6) Num_Reset&Bad = integer = number of inputs that are both reset
and marked "Bad".
= initialized = 0
7) Num_Set&Process = integer = number of inputs that are both set
and from the process.
= initialized = 0
8) Num_Reset&Process = integer = number of inputs that are both
reset and from the process.
= initialized = 0
The Stack_Count and the Stack_Counter_Limit are initialized at the

beginning of the program execution each cycle.
No instruction can cause the Stack_Count to be larger than the

Stack_Counter_Limit. No instruction can cause the Instruction_Count
to be larger than 8. If either limit is exceeded in the program
execution, the "Configuration Error" notification will be set and the
block set to O/S mode.

719
The PUSH instruction does not need to use variables 3 to 8 above.

The PUSH instruction pushes the stack down by 1. It enters the value
obtained from the location identified by the pointer and also enters
the status of that value. The entry in the stack will have
Instruction_Count = 1. The PUSH instruction will increment the
Stack_Count by 1.
When the algorithm finds an AND instruction not preceded by an AND,

it initializes integers 3 through 8 above. Each AND in a series of
AND instructions then increments those counters as appropriate. An
individual AND instruction leaves the stack depth unaffected. It
will remove a value from the stack, perform its operation, and return
the result to the stack. It will increment by 1 the
Instruction_Count that it finds in the input stack value and store it
back on the stack.
After each AND in a series of AND instructions has been completed,

the following calculations will be done to calculate the status byte
of the last value on the stack:
Status Bits = all reset
IF value Set, THEN
IF Num_Set&Bad > 0 THEN Set Bit 1 of the Status byte.
IF Num_Set&Process = 0 THEN Set Bit 2 of the Status byte.
ELSE
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
IF Num_Reset&Bad = Num_Inputs - Num_Set THEN Set Bit 1 of

the Status byte.
IF Num_Reset&Process = 0 THEN Set Bit 2 of the Status byte.
--```,``-`-`,,`,,`,`,,`---
When the algorithm finds an OR instruction not preceded by an OR, it

initializes integers 3 through 8 above. Each OR in a series of OR
instructions then increments the counters as appropriate. An
individual OR instruction pops a net of 1 value off of the stack. It
will decrement the Stack_Count by one and decrement the
Stack_Counter_Limit by one. The Instruction_Count for the entry that
is made onto the stack will be the larger of the two
Instruction_Counts that accompanied the input values.
When the last OR in a series of OR instructions has been completed,

the following calculations will be done to calculate the status byte
of the last value on the stack:
IF value Set, THEN
IF Num_Set&Bad = Num_Set THEN Set Bit 1 of the Status byte.
IF Num_Set&Process = 0 THEN Set Bit 2 of the Status byte.
ELSE
IF Num_Reset&Bad > 0 THEN Set Bit 1 of the Status byte.
IF Num_Reset&Process = 0 THEN Set Bit 2 of the Status byte.
The XOR instruction does not need to use variables 3 to 8 above. The
XOR instruction pops the stack by a net of 1. It removes the top two
values from the stack. Its result is set if, and only if, one of the
two values is set. The instruction places the result on the stack.
The Instruction_Count for the entry that is made onto the stack will
be based on the larger of the two Instruction_Counts that accompanied
the input values. That value will be incremented by 1 and placed on
the stack as the Instruction_Count for the new stack entry. The
instruction will decrement the Stack_Count by one and decrement the
Stack_Counter_Limit by one.
When the algorithm finds a VOTE instruction not preceded by a VOTE,

it initializes integers 3 through 8 above. Each VOTE in a series of
VOTE instructions then increments the counters as appropriate. An
individual VOTE instruction pops a net of 1 value off of the stack.
It will decrement the Stack_Count by one and decrement the
Stack_Counter_Limit by one. The Instruction_Count for the entry that
is made onto the stack will be the larger of the two

720
Instruction_Counts that accompanied the input values. The value

entered on the stack will be meaningless and will be overwritten by
the value calculated below.
When the last VOTE in a series of VOTE instructions has been

completed, the following calculations will be done to calculate the
value and status byte of the last entry on the stack:
Value = Reset
IF (Num_Set >= Vote_Min AND Num_Set =< Vote_Max) THEN
Value = 1
IF Value Set THEN
IF (Num_Set - Num_Set&Bad) < Vote_Min THEN
Set Bit 1 of the Status byte.
IF (Num_Reset&Bad + Num_Set) > Vote_Max THEN
IF Num_Set&Process = 0 THEN
--```,``-`-`,,`,,`,`,,`---
ELSE
IF Num_Set > Vote_Max THEN
IF (Num_Set - Num_Set&Bad) < Vote_Max THEN
IF Num_Set&Process < Vote_Max THEN
ELSE
IF (Num_Set + Num_Reset&Bad) > Vote_Min THEN
IF Num_Reset&Process = 0 THEN
ENDIF
ENDIF
The Instruction_Count will be based on the larger of the two
Instruction_Counts that accompanied the last 2 input values.
That value will be incremented by 1 and placed on the stack
as the Instruction_Count for the new stack entry.
The icon for the SPx instruction is complex and would consume a full
6 rows if shown in standard ladder notation. Therefore, it will be
assumed that the ladder display uses a condensed icon that only
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
consumes the three rows needed for the outputs. To allow display
room for this type of compression, the SPx block is assumed to be 3
times as wide as other icons.
The SPx instruction will remove Stack_Count values from the stack
and push 3 values to the stack. Then:
1) Inspect the Instruction_Count values of the Stack_Count values
on the stack to find the maximum Instruction_Count. The value
must be 5 or less. If not, set a configuration error
notification and set the mode to O/S.
2) IF Stack_Count_Limit < (3 - Stack_Count) THEN
set a configuration error notification
set the block to O/S mode.
ELSE
Set Stack_Count_Limit = Stack_Count_Limit - (3
- Stack_Count).
Set Stack_Count = 3
Set the Instruction_Count = 8 for each of the entries
onto the stack.
The TERM instruction will check SPx_Done and it will check the number
of instructions left on the stack. The handling is dependent on the
type of TERM instruction as follows:
IF SPx_Done is reset THEN
IF Stack_Count <> 1 THEN
Set the configuration error notification.
Set the block to O/S mode.
ELSE

721
Set Stack_Count = 0.
Decrement Stack_Count_Limit by 1.
ELSE IF Latching or Unlatching TERM THEN
ELSE IF (Stack_Count is < 1 OR Stack_Count > 3) THEN
ELSE
Decrement the Stack_Count by 1.
- The results of the individual instructions are not intended to be

individually addressed by control structures on Field Bus. Their
states and stati are only of use to human interface devices.
Therefore, a single addressable parameter is defined that will pack
the states and stati for the results of each instruction step into
one parameter. This parameter will be stored using the
auto-formatting structure.
Every value pushed onto the stack by each step or the value set in
a bit of Output by a TERM instruction is packed into
consecutive bits of 3 consecutive words. The bit for each step is
reset if the corresponding item is in its normal (Off or False)
state. The state bit for the first instruction will be in bit 0 of
the first word, then in order through bit FH of the first word, then
bit 0 of the second word, etc,
There is a status byte for each step. The format of the individual
status bytes are Field Bus standard. The status bytes that accompany
each of the above bits are packed into the succeeding bytes of the
same parameter. This is the parameter that a Human Interface will
access to obtain the information necessary to draw the power flow in
the ladder diagram.
The status byte of the first instruction is reported first, (in the
11th byte of the parameter) followed by the second status byte, etc.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^

--```,``-`-`,,`,,`,`,,`---

722
LOGIC ALGORITHM
RCas
7 6 5 2 1 0
Cas 3 Set
Point
2 1 0 Pointer Output
Mode Select Word 0
Output 0
E
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Input Set Point F

Word 0
X OW0-0
Input 0
F Thru
SP2 SP1 SP0
E OW0-F
IW1-0 1
X X X
Thru 0
IW1-F 0
1 Step Instructions Output E
1 Word 1 F
0
0 2
1 3
2 OW1-0
4
--```,``-`-`,,`,,`,`,,`---
Input 3
Output 1
5 Thru 1
Word 1 . OW1-F 0
. 6
Input 1
F
E . 7 X
. Output
IW2-0
Output 1
.1E E
Thru Word 2
X1F F
IW2-F X
OW1-0
1
0 Thru
OW1-F
1
0
Figure 56: Logic, Figure 1, Logic Algorithm

723
SPx LOGIC
Version 0 - Independent
SP0 SPx0
S
SPx1
SP1 SPx2
SPx2 S-1
SP2 SPx4
S-2
SPx5
Out bit
Status
SPx0
WUH
Out bit Bit 0
SPx1 SPx0 Status WUL
Out bit Bit 0
SPx2
Status WUH
SPx2 Out bit Bit 1
SPx3 Status WUL
Out bit Bit 1
SPx4
Status WUH
SPx5 SPx4 Bit 2
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
WUL
Bit 2
Out bit
Status
Figure 57: Logic, Figure 2, SPx Logic, Version 0 - Independent
--```,``-`-`,,`,,`,`,,`---

724
SPx LOGIC
Version 1 - On/Off/Rev.
SP0 SP1 SP2 SPx0 SPx1
Temp
1
SPx2 Old Bit 0 Old Bit 0
SP0 SP1 SP2 SPx3 SPx1

Temp
2
SPx2 Old Bit 2 Old Bit 2
Temp 1 Temp 2
S
Temp 2 Temp 2
S-2
S S-2
S-1
SPx0 SPx1 Out bit WUH

Status Bit 0
Out bit
SPx2 Status WUL
Bit 0
Out bit
SPx2 Status
WUH
Bit 1
SPx1 Out bit
SPx0
Status WUL
Bit 1
SPx3
Out bit
SPx1 Status
SPx3 WUH
Bit 2
SPx2 Out bit
Status WUL
Bit 2
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Figure 58: Logic, Figure 3, SPx Logic, Version 1 - On/Off/Rev.

--```,``-`-`,,`,,`,`,,`---

725
LOGIC BLOCK - INSTRUCTION DEFINITION WORD
Operation
F E D C B A 9 8 7 6 5 4 3 2 1 0
Description
Value =0 PUSH
1 AND
Value Description
2 DR
000 Not Configured
3 OR
001
4 VOTE
to Number of
5 SPx-0
110 Instruction Words.
6 SPx-1
7-F Reserved
Element 10-1F Free
0 B A 9 8 7 6 5 4 3 2 1 0
Input State
Pointer Input Operation Description
Option State Value =0 Input State
1 Rising State
Termination 2 Falling State
3 Transition
1 B A 9 8 7 6 5 4 3 2 1 0 4&5 Reserved
6&7 Free
7-F Reserved
Pointer Pointer Termin.
0 #1 Type Termin. Type
Options Option
Description
Free
Description Value =0 TERM
1 Delay On TERM.
Bit States Inputs Outputs 2 Delay Off TERM.
Low bit set Set Bad If No-com Suppress LO 3 Latching TERM.
--```,``-`-`,,`,,`,`,,`---
Next bit set Clear Bad state Sep. Fail/No-Path 4 Unlatching TERM.
Next bit set Clear Override Write Only On Change 5 END
High bit set Set Override Increment Target 6&7 Reserved
A-F Free
Figure 59: Logic, Figure 4, Logic Block - Instruction Definition Word

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
726
LOGIC BLOCK - DETAIL WORD
Detail Word (Timer)
F E D C B A 9 8 7 6 5 4 3 2 1 0
Detail Word (VOTE) 16 Bit Integer Timer Set

Point
A B D C B A 9 8 7 6 5 4 3 2 1 0
8 bit Integer -Min. #Set

8 Bit Integer - Max # Set
Detail Word (Pointer)

F E D C B A 9 8 7 6 5 4 3 2 1 0
2 Bits Force-
00 = Null
01 = Force to 0 2 Bits: If Bad- 7 Bits: Parameter
10 = Force to 1 00 =Null 4 Bits: Bit Number
11 =Keep Old 01 = Use 0 1 Bit:
--```,``-`-`,,`,,`,`,,`---
10 = Use 1 0 = use Direct Value
11= Keep Old 1= Invert Value
Figure 60: Logic, Figure 5, Logic Block - Detail Words

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
727
LOGIC ICONS - BASIC SHAPE
Code Boolean Ladder
PUSH B S
S B
S S
AND
B
S
OR S-1 S S
S-1
S S
S-1 S-1 XOR S

XOR XOR S
S
S-1 S
S-1 S
VOTE S
S
B0
B0 S
SPx-x S-1 SPx-x S
S-2 Bn S-1
SPx-0, Bn S-2
SPx-1
S
TERM S On On
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Figure 61: Logic, Figure 6, Logic Icons - Basic Shape

--```,``-`-`,,`,,`,`,,`---

728
Program Control
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

BIT POINTERS
PROGRAM DEFINITION
AUTOMATIC OUTPUT LOGIC
Table 1 - FLAG DEFINITIONS
Table 2 - TARGET OPERANDS
Table 3 - SOURCE OPERANDS
Table 4 - COMMANDS
Table 5 - TOKENIZED CODE DETAIL
BASIC ALGORITHM:
- This algorithm provides a structure in which a 32 line program can
implement a simple procedure that can not (efficiently) be done in
the standard blocks. The block will provide a standard cascade
structure for handling a Setpoint whose bits can then be accessed by
the program logic. The block can also be configured to use one of
two logic procedures to manipulate the Setpoint bits while moving
them to the Output: one is oriented toward the requirements of the
3-bit discrete Setpoint and the other is oriented toward simple bit by
bit override.
- See attached figure "Program Algorithm".
- Two 16 bit Input Words and three 16 bit Output Words.
- Internal Registers A-D (16 bits wide) and Reg. Output (3 bits wide)
- 32 instruction "program"
- 6 bit pointer fetches plus the 3 Setpoint bits are used for "SPx
Logic" to drive the Output word.
- The 3 bits in the Output are stored in Output Words based on bit
pointers.
- Supports discrete cascades and all status byte information.

- Modes: all except ROut and Man - Set Point Limits: no
- Hardware Pointer: none - PV Pointer: yes, default
- Bit Pointers: yes to Output 0, Bits 0-2
- By-pass: yes, Setpoint to - Boolean Operators: no
Output
SP-50 User Layer Technical Report Program

--```,``-`-`,,`,,`,`,,`---

729
ALGORITHM OPTIONS:
- OUTTRK = logical: set = Setpoint tracks Output in IMan mode.
- RIMAN = logical: set = Program runs when the block is in IMan mode.
- RLO = logical: set = Program runs when the block is in any LO mode.
- SPx_OPT = logical: set = On/Off/Reverse logic in the "SPx Logic".
reset = Independent logic in the "SPx Logic".

- Based on unique "Program".
BIT POINTERS:
1) the inputs to form the Cas set point.
2) the inputs to the "SPx Logic".
3) the connections from the coils to their destinations.
Three input bit pointers are provided for the Cas set point definition. If
the first pointer points to the Cas transfer location, then the Cas transfer
location will be used in Cas mode. The configuration for the three pointers
consists of three copies of the bit pointer configuration word. The three words
are combined under one parameter for addressing purposes. The word for bit 0 of
the set point is reported first. Three words are reported even if only the first
is used so that the length of the parameter will be constant.
Six bit pointers are provided to define the source of the information for the
automatic sub-logic used to determine the three bits in Output. The configuration
for the pointers consists of six copies of the bit pointer configuration word.
The six words are combined under one parameter for addressing purposes. The word
for F1 is reported first, then F2, G1, G2, H1, and then H2. Six words are
reported even if only four are used so that the length of the parameter will be
constant.
Three more bit pointers are provided to define the destinations of the three
Output bits. The destinations can only be specific bits in Output Words 0-2 or
in the Logical Node Output Words 0-4. The configuration for the three pointers
consists of three copies of the bit pointer configuration word. The three words
are combined under one parameter for addressing purposes. The word for bit 0 of
the Output is reported first. Three words are always reported so that the length
of the parameter will be constant.
PROGRAM DEFINITION:
The program can consist of up to 3210 lines of object code. Each line is
automatically identified with its index number from line 0. Each line has the
general form:
{Command} {Target Operand} {Source Operand}
--```,``-`-`,,`,,`,`,,`---
The system that executes the object code will maintain 12 flags. The flags are
manipulated by certain of the commands and can be interrogated by other commands.
The attached Table 1 defines the 12 Flags that will be maintained by the
program system.
The attached Table 2 defines the target operands and groups them into 6 sets
for use in Table 4.
The attached Table 3 defines the source operands and groups them into 7 sets
for use in Table 4.
The attached Table 4 defines the 26 commands.

//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
730
The tokenized program constitutes a block of static configuration information

that is exactly 128 bytes long - the maximum size of a single Field Bus
communication. Each source line equals one 32 bit object record composed of 4
fields. The entire program is addressed using one parameter. The source to
token translations are given in Table 5.
AUTOMATIC OUTPUT LOGIC

Whenever this block is used to handle a Setpoint or Output that is associated
with a Device Block, there will be certain common logic that will be needed.
This logic is partially built into the generation of the Output word so that it
will not have to be programmed. This logic is executed when the option SPx_OPT
is set. The alternative is a set of SPx logic that is intended to provide simple
override control over the cascaded Setpoint.
The SPx Logic is defined as part of the Ladder Block. The Program block will
use exactly the same logic with the same bit pointers defined to fetch the inputs
for the SPx Logic. The output of the SPx logic will define the parameter Output
that is part of this block.
+ Configuration of 2 Input word and 3 Output word pointers.
+ Configuration of the source of the Cas Set Point.
+ "Program object code".
+ Configuration of the SPx elements (6 logic elements).
+ Configuration of Output pointers (3).
+ Input 0 = Input0(n) = up to 16 bit word.
+ Input #1 = Input1(n) = up to 16 bit word.
+ Registers A - D = REGA - REGD = 16 bit registers.
+ Register Output = OUTPUT = 3 bit Register.
+ Output 0 = Out0(n-1) = 16 bit string (automatic write mask).
+ Output #1 = Out1(n-1) = 16 bit string (automatic write mask).
+ Output #2 = Out2(n-1) = 16 bit string (automatic write mask).
+ ISTAT = Initialization Status = 1 bit = set if block in
initialization pass.
--```,``-`-`,,`,,`,`,,`---
- Two Input words and three Output words fetched if necessary.
- Determine the new Set Point:
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
+ In RCas mode, the Set Point is obtained from the RCas transfer
location.
+ In Cascade mode, the Set Point can be configured as any three
+ In Auto mode, the Operator or higher level device sets the Set
Point.
- IF bypass, then Setpoint passed to Output; skip the program and
SPx logic.
- Program Executed.
- Setpoint and the values fetched with the 4 (or 6) SPx bit pointers
(F1, F2, G1, G2, H1, and H2) are passed to the SPx logic chosen by
SPx_OPT. The result back is "OUT"
- The values in OUT are passed to the block and logical node Output
Words.
- Output Words automatically form write masks and mask write their
new values if any bit in the mask allows writing. However, if the
program writes a Mask to an Output Word, it will be used unchanged.

731


The following are the responses to unexpected conditions in the control
scheme.
bit 2: (Override)
No direct effect but the bits are available to the logic.
bit 3: (Special)
SPx_Opt reset:
If all of the Output Word bits that are pointed to by the
Output bit pointers have LO set, then the entire block will
go into IMan(LO(x)) mode. If all Output bit pointers are
null, LO will not be set.
SPx_Opt set:
--```,``-`-`,,`,,`,`,,`---
If two of the three Output Word bits that are pointed to by

the Output bit pointers have LO set, then the entire block
will go into IMan(LO(x)) mode. Any of the three pointers
that are null will be counted as having their LO set but if
two or all three are null, LO will not be set.
bit 4: (Failed)
If an Output Word bit that is pointed to by an Output bit pointer
has Failed, then the Setpoint bit in the position corresponding to
the Output bit pointer will be marked Failed. If an Output bit
pointer is null, its corresponding Setpoint bit will not be marked
failed. The standard handshake using bit 5 will be done on a
bit-by-bit basis.
THEN, if SPx_Opt is set AND two or three of the Setpoint bits are
marked failed, all three will be marked failed.
bit 5: (No-path)
If an Output Word bit that is pointed to by an Output bit pointer
has its No-Path status set, then the Setpoint bit in the position
corresponding to the Output bit pointer will be marked No-Path.
If an Output bit pointer is null, its corresponding Setpoint bit
will not be marked No-Path.
THEN, if SPx_Opt is set AND two or three of the Setpoint bits are
marked No-Path, all three will be marked No-Path.
The logic for back-calculating the ATW bits is defined in the SPx
definitions.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

732
Program Table 1, Flag Definitions

FLAG DEFINITIONS
Flags:
0F = bit 0 flag
This flag is set if the last operation on Register A resulted in
the corresponding bit in Register A being set.
Note: 0F detects a No-Com in a status byte or an ROut mode.
1F = bit 1 flag
Note: 1F detects a Bad Value in a status byte or an RCas mode.
2F = bit 2 flag
Note: 2F detects a Not-from-Process in a status byte or a Cas mode
3F = bit 3 flag
Note: 3F detects a Special bit in a status byte or an Auto mode.
4F = bit 4+ flag
--```,``-`-`,,`,,`,`,,`---
all of bits 4 through F reset.
Note: 4F detects a situation in which the mode is Auto or lower
in priority or Cascade path fully open.
5F = bit 5+ flag
all of bits 5 through F reset.
Note: 5F detects a situation in which the mode is Man or lower
in priority
6F = bit 6 flag
Note: 6F detects an IMan mode or a set ATW-l status.
7F = bit 7 flag
Note: 7F detects an O/S mode or a set ATW-h status.
GF = greater than flag
The last test command occurred while the target was greater than
the Source.
LF = less than flag
The last test command occurred while the target was less than the
Source.
SF = single flag
The last operation resulted in one bit set in the target operand.
Note: this can be used to detect pure modes.
ZF = zero flag
1) The last operation resulted in a completely reset target
operand.
2) The last test command resulted in an equality compare.
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\

733
Program Table 2, Target Operands

Table 2
TARGET OPERANDS
The Target Operand Value can be:
Set Name Operand Description Code Definition of x
Full Target Set:

Register x RGx x = |A, B, C, D|
Output Word x OWx x = |0 - 2|
Logical Node Word x LNx x = |0 - 4|
08 + Register x, Rxy x = |A, B, C, D|
Bit y Status byte y = |0 - F|
08 + Output Word x, Oxy x = |0, 1|
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
08 + Logical Node Word x, Lxy x = |0, 1|
Short Target Set:

Immediate:
Immediate Value xyH x = |0 - F|
y = |0 - F|
Line Number Forward:

A Program Line Number Fxy x = |0, 1|
y = |0 - F|
xy > current line
number
Line Number Backward:

A Program Line Number Bxy x = |0, 1|
y = |0 - F|
xy < current line
number
Alert Code:
An Alert Code Axy x = 2
y = |0 - F|
top

--```,``-`-`,,`,,`,`,,`---

734
Program Table 3, Source Operands

Table 3
SOURCE OPERANDS
The Source Operand Value can be:
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Source
Set Name Operand Description Code Definition of x
Full Source Set:
Input Word x IWx x = |0, 1|
Logical Node Word x LNx x = |0 - 4|
Output Mask x OMx x = |0 - 2|
Defined Value Dxy x = |0 - 1|
y = |0 - F|
08 + Immediate Value xyH x = |0 - F|
y = |0 - F|
08 + Mode MOD
013 + Setpoint STP
013 + Output OUT
015 + Initialization Status IST
08 + Register x, Rxy x = |A, B, C, D|
08 + Input Word x, Ixy x = |0, 1|
08 + Output Word x, Oxy x = |0, 1|
08 + Logical Node Word x, Lxy x = |1 - 4|
--```,``-`-`,,`,,`,`,,`---
08 + Setpoint Bit y SPy y = |0 - 2|
Status byte
08 + Output bit y Status byte OTy y = |0 - 2|
Short Target Set:
Define Value:
Defined Value Dxy x = |0, 1|
y = |0 - F|
Flags:
Flags FLx x = |0-7, G,
L, S, or Z|
Immediate:
08 + Immediate Value xyH x = |0 - F|
y = |0 - F|
Select Mask:
Mask Value xyH x = |0 - F|
y = |0 - F|
Switch Value:
Original Position Number xyH x = |0 - 2|
y = |0 - 2|
xy <> 21
Example position number: 01H
The value in Bit 2 was in Bit 0, the value in Bit 1 was
in Bit 1 (hence, by default, the value in Bit 0 was in Bit 2)
top

735
Program Table 4, Commands

Table 4
COMMANDS
The Command will be a 3-Character Mnemonic. The full object line

syntax is: {Command} {Target Operand}, {Source Operand}
The Defined Commands are:
Command
Mnemonic Command Description Target Set Source Set
DEF Define a value - define 8 bit Target Immed. Immed.
--```,``-`-`,,`,,`,`,,`---
Value concatenated with the 8 bit
Source Value as a 16 bit value. Label
it with this program line number.
No flags changed.
MOV Move the Source Value to the Target. Full Full
Flags SF and ZF updated.*
AND Boolean AND the Source Value into the Short Full
//^:^^#^~^^"~~:~"~$$"~$^"#:*~^~~^*@:"#~~^:^~~":^*#^^@\\
Target Value
BOR Boolean OR the Source Value into the Short Full
Target Value
XOR Boolean XOR the Source Value into the Short Full
Target Value
TST Nondestructive compare the Source and Full Full
the Target Values and set the aF flags. *
LPU Loop unconditionally to the given Line any
backward line number, suspend the program Back
for this cycle, and start there next cycle.
No flags changed.
LPS Loop if Flag set to the given backward Line Flag
line number, suspend the program for Back
this cycle, and start there next cycle.
No flags changed.
LPR Loop if Flag reset to the given backward Line Flag
line number, suspend the program for Back
this cycle, and start there next cycle.
No flags changed.
JPU Jump unconditionally to the given Line any
forward line number. Forw.
No flags changed.
JPS Jump if Flag set to the given Line Flag
No flags changed.
JPR Jump if Flag reset to the given Line Flag
No flags changed.
SHL Shift Target Left, padding with reset Short Immed.
bits, dropping off of the left end. (Max = E)
SHR Shift Target Right, padding with reset Short Immed.
bits, dropping off of the right end. (Max = E)
S0L Scan Source for the first reset bit Short Full
starting on the left; put the count
in Target.
S0R Scan Source for the first reset bit Short Full
starting on the right; put the count
in Target.

736

S1L Scan Source for the first set bit starting Short Full
on the left; put the count in Target.
S1R Scan Source for the first set bit starting Short Full
on the right; put the count in Target.
CMP Shift the value in Target right so as to Short Full
squeze out all bits corresponding to bits
set in Source. Fill left with reset bits.
RSL Reset all bits below (i.e., to the right) Short Full
of the highest priority bit set; put the
number of the position (a hex value of
0 - F) of the remaining bit in Target.
RSR Reset all bits above (i.e., to the left) Short Full
of the lowest priority bit set; put the
number of the position (a hex value of
0 - F) of the remaining bit in Target.
ALT Set/Reset alert code Alert 00h = Reset
No flage changed.

ISA - TR50.02 Part 9-2000 Fieldbus Standard For Use in Industrial Control Systems User Layer Technical Report

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

ISA - TR50.02 Part 9-2000 Fieldbus Standard For Use in Industrial Control Systems User Layer Technical Report

Uploaded by

Copyright:

Available Formats

TECHNICAL REPORT

ISATR50.02, Part 92000

Fieldbus Standard for Use in

Approved 01 January 2000

Copyright The Instrumentation, Systems, and Automation Society

and current SP50.4 member Cullen Langford for his

Copyright The Instrumentation, Systems, and Automation Society

ISA-TR50.02, Part 9-2000, Fieldbus Standard for Use in

Copyright 2000 by the Instrument Society of America. All

ISA 67 Alexander Drive P. O. Box 12277

Copyright The Instrumentation, Systems, and Automation Society

Copyright The Instrumentation, Systems, and Automation Society

CAUTION ISA ADHERES TO THE POLICY OF THE AMERICAN

EVEN IF ISA IS UNAWARE OF ANY PATENT COVERING THIS

HOWEVER, ISA ASKS THAT ANYONE REVIEWING THIS STANDARD WHO

Copyright The Instrumentation, Systems, and Automation Society

ADDITIONALLY, THE USE OF THIS STANDARD MAY INVOLVE

The following people served as members of ISA Subcommittee

The following people served as members of ISA Committee SP50:

R. Caro, Chairman Automation Research Corporation

Copyright The Instrumentation, Systems, and Automation Society

G. Beusch Absolute Control Inc.

Copyright The Instrumentation, Systems, and Automation Society

L. Natiello Merck and Company Inc.

M. Zielinski FisherRosemount Systems, Inc.

Copyright The Instrumentation, Systems, and Automation Society

J. Whetstone National Institute of Standards &

Copyright The Instrumentation, Systems, and Automation Society

SP50 USER LAYER GUIDE SHEET..........................................................................................................17

USER LAYER STRUCTURE .....................................................................................................................21

Attach. 2 Logic .....................................................................................................................................259

Copyright The Instrumentation, Systems, and Automation Society

Dynamic Compensation ........................................................................................................................605

Copyright The Instrumentation, Systems, and Automation Society

Copyright The Instrumentation, Systems, and Automation Society

Figure 53: Discrete Register, Figure 2, Discrete Point...................................................................................695

Copyright The Instrumentation, Systems, and Automation Society

This paper includes the following sections:

In 1986, the MAP (Manufacturing Application Protocol) Steering Committee of

SP-50 User Layer Technical Report Preface

Copyright The Instrumentation, Systems, and Automation Society

Process Control ISA SP72

FIELD BUS REQUIREMENTS:

Many of the requirements were expressed in terms of process control

o User Layer Subcommittee -- to define the user needs.

SP-50 User Layer Technical Report Preface

Copyright The Instrumentation, Systems, and Automation Society

SP-50 User Layer Technical Report Preface

Copyright The Instrumentation, Systems, and Automation Society

OSI-ISO Model Field Bus Model

Format used in Network

5 Session Name/address translation Access security

4 Transport Provides transparent, re-

3 Network Provides message routing For data

1 Physical Handless the transmission Physical

Figure 1: Preface, Figure 1, Protocol Models

SP-50 User Layer Technical Report Preface

Copyright The Instrumentation, Systems, and Automation Society

Function Block 0 Function Block 0

SP-50 User Layer Technical Report Preface

Copyright The Instrumentation, Systems, and Automation Society

USER LAYER DEFINITION:

2. A document abstracting the User Layer Machine into a set of equivalent