Download Technical Overview

Technical
Overview
FOUNDATION™ fieldbus
Compliments of:
FD-043 Rev 2.0
Preface
FOUNDATION Fieldbus Technical Overview
FD-043 Revision 2.0
This technical overview booklet has been prepared to aid understanding of the technical aspects
of FOUNDATION fieldbus.
The booklet begins with a brief overview of fieldbus benefits followed by the goals, principles
and organization of the not-for-profit Fieldbus Foundation.
The main portion of the booklet is devoted to the definition and explanation of key technical
concepts underpinning FOUNDATION fieldbus technology.
I sincerely hope this information proves useful to you. Please contact the Fieldbus Foundation
if you need additional information about this exciting new technology.
David A. Glanzer
Director of Technology Development
For additional information please contact:
Fieldbus Foundation
9390 Research Boulevard
Suite II-250
Austin, TX 78759
USA
Voice: 512 794 8890
Fax: 512 794 8893
Visit our World Wide Web Site:
http://www.fieldbus.org
DISCLAIMER OF WARRANTIES
This document is provided on an “as is” basis and may be subject to future additions, modifications, or corrections. The Fieldbus
Foundation hereby disclaims all warranties of any kind, express or implied, including any warranty of merchantability or fitness for
a particular purpose, for this document. In no event will the Fieldbus Foundation be responsible for any loss or damage arising
out of or resulting from any defect, error or omission in this document or from anyone’s use of or reliance on this document.
© 1996 (Rev.1998) Fieldbus Foundation, Austin, Texas. All rights reserved.
Table of Contents
1.0
WHAT IS FOUNDATION FIELDBUS? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
1.1 Fieldbus Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
1.1.1 More Data Available . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
1.1.2 Expanded View of the Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
1.1.3 Reduction in System Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
1.1.4 Wiring Savings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
2.0
WHAT IS THE FIELDBUS FOUNDATION? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
2.1 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
2.1.1 Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
2.1.2 Board of Directors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
2.1.3 President . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
2.1.4 End User Councils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
2.1.5 Quality Director . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
2.1.6 Executive Committee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
2.1.7 Technical Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
2.1.8 Marketing Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
2.1.9 Member Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
3.0
FOUNDATION FIELDBUS TECHNOLOGY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
3.1 Physical Layer (31.25 kbit/s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
3.1.1
31.25 kbit/s Fieldbus Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
3.1.2
31.25 kbit/s Fieldbus Wiring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
3.2 Communication Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
3.2.1 The Data Link Layer (DLL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
3.2.1.1
Device Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
3.2.1.2
Scheduled Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
3.2.1.3
Unscheduled Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
3.2.1.4
Link Active Scheduler Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
3.2.1.4.1 CD Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
3.2.1.4.2 Live List Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
3.2.1.4.3 Data Link Time Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
3.2.1.4.4 Token Passing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
3.2.1.4.5 LAS Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
3.2.2 Fieldbus Access Sublayer (FAS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
3.2.2.1
Client/Server VCR Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
3.2.2.2
Report Distribution VCR Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
3.2.2.3
Publisher/Subscriber VCR Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
3.2.2.4
Summary of VCR Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
3.2.3 Fieldbus Message Specification (FMS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
3.2.3.1
Virtual Field Device (VFD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
3.2.3.2
Communication Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
© 1996 (Rev.1998) Fieldbus Foundation, Austin, Texas. All rights reserved.
Table of Contents
3.2.3.2.1 Context Management Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
3.2.3.2.2 Object Dictionary Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
3.2.3.2.3 Variable Access Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
3.2.3.2.4 Event Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
3.2.3.2.5 Upload/Download Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
3.2.3.2.6 Program Invocation Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
3.2.3.3
Message Formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
3.2.3.4
Protocol Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
3.3 User Application -- Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
3.3.1 Resource Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
3.3.2 Function Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
3.3.3 Transducer Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
3.3.4 Fieldbus Device Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
3.4 System Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
3.4.1 Function Block Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
3.4.1.1
Application Clock Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
3.4.1.2
Device Address Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
3.4.1.3
Find Tag Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
3.5 Device Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
3.5.1 Device Description Tokenizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
3.5.2 Device Description Services (DDS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
3.5.3 Device Description Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
3.5.4 Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
4.0
SYSTEM CONFIGURATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
4.1 System Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
4.2 Device Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
5.0
FIELD TEST SYSTEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
5.1 Test Instrumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
5.2 Installation, Startup, and Operation Benefits Observed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
6.0
HIGH SPEED ETHERNET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
7.0
REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
8.0
DOCUMENT LIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
9.0
ACRONYM TABLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
© 1996 (Rev.1998) Fieldbus Foundation, Austin, Texas. All rights reserved.
Introduction
In addition, FOUNDATION fieldbus enables:
1.0 WHAT IS FOUNDATION FIELDBUS?
FOUNDATION fieldbus is an all digital, serial, two-way
communication system running at 31.25 kbit/s which
interconnects “field” equipment such as sensors, actuators and controllers. Fieldbus is a Local Area Network
(LAN) for instruments used in both process and manufacturing automation with built-in capability to distribute
the control application across the network (Figure 1).
• increased capabilities due to full digital
communications
The fieldbus environment is the base level group of
digital networks in the hierarchy of plant networks
(Figure 2).
• reduced loading on control room equipment
due to possible distribution of some control and
input/output functions to field devices
The fieldbus retains the desirable features of the 4-20
milliampere (mA) analog system such as:
• connection to a High Speed Ethernet backbone
for larger systems
• reduced wiring and wire terminations due to
multiple devices on one wire
• increased selection of suppliers due to
interoperability
1.1 Fieldbus Benefits
• a standardized physical interface to the wire
Significant benefits are achieved in the control
system life-cycle through the application of
fieldbus technology (Figure 3).
• bus-powered devices on a single wire pair
• intrinsic safety options
Fieldbus LAN
P
L
Automation
and
Display Systems
Plant/Factory
Figure 2
Figure
Figure
1 1
Planning
and
Installation
Operation
Maintenance
Evolution
Reduced number of wires and marshaling panels
Reduced number of intrinsic safety barriers
Reduced number of input/output converters
Reduced number of power supplies and cabinets
Reduced size of equipment rooms
Remote configuration of devices
More information available for operations
Increased accuracy of measurements
Easier evolution due to standardized function blocks
Increased sophistication and flexibility of instrumentation
Increased uptime due to less equipment, better self
diagnostics, and remote diagnostics
Figure
Figure
3 3
1
© 1996 (Rev.1998) Fieldbus Foundation, Austin, Texas. All rights reserved.
Introduction
Introduction
1.1.1 More Data Available
The fieldbus allows multiple variables from each
device to be brought into the control system for
archival, trend analysis, process optimization studies, and report generation. The high resolution and
distortion-free characteristics of digital communications enables improved control capability which can
increase product yields (Figure 4).
“Function Blocks” to implement the control strategy.
Function Blocks are standardized automation
functions. Many control system functions such as
analog input (AI), analog output (AO) and
Proportional/Integral/Derivative (PID) control may be
performed by the field device through the use of
Function Blocks (Figure 6).
The consistent, block-oriented design of function
blocks allows distribution of functions in field
devices from different manufacturers in an
integrated and seamless manner.
1.1.2 Expanded View of the Process
The self-test and communication capabilities of
microprocessor-based fieldbus devices helps
reduce downtime and improve plant safety.
Distribution of control into the field devices can
reduce the amount of I/O and control equipment
needed including card files, cabinets, and power
supplies.
Upon detection of abnormal conditions or the need
for preventive maintenance, plant operations and
maintenance personnel can be notified. This allows
corrective action to be initiated quickly and safely
(Figure 5).
1.1.4 Wiring Savings
The fieldbus allows many devices to connect to a
single wire pair. This results in less wire, fewer
intrinsic safety barriers, and fewer marshaling
cabinets (Figure 7).
1.1.3 Reduction in System Hardware
FOUNDATION fieldbus uses standard
Control System
Network
Control System
Network
Control System
Network
Controller
Controller
Controller
Controller
Input/Output
Subsystem
Control System
Network
Remote Input/Output
Subsystem
Fieldbus
Traditional 4-20 mA
One Variable
One Direction
Fieldbus
Traditional 4-20 mA
View Stops at I/O Subsystem
Fieldbus
Multiple Variables
Both Directions
Figure
5 5
Figure
Figure44
Figure
Control System
Network
Control System
Network
Input/Output
Subsystem
AI
Input/Output
Subsystem
Fieldbus
I.S.
AI
Traditional
PID
I.S.
I.S.
Fieldbus
I.S.
Fieldbus Wiring
4-20 mA
AO
One I.S. Barrier, One Wire
Traditional 4-20 mA Wiring
for
One I.S. Barrier, One Wire
Many Devices
for
Figure 7
Each Device
Fieldbus
Figure
6 6
Figure
Controller
Controller
AO
4-20 mA
Control System
Network
Control System
Network
Controller
Controller
PID
Fieldbus
View Extends into Instrument
Some control and I/O
can move to field
instruments.
Figure 7
2
© 1996 (Rev.1998) Fieldbus Foundation, Austin, Texas. All rights reserved.
Organization
2.1.2 Board of Directors
The foundation is managed under the direction of
the Board of Directors (BOD). The BOD is elected
by the voting members.
2.0 WHAT IS THE FIELDBUS FOUNDATION?
Driven by their customers’ needs, process control
and manufacturing automation companies formed
the Fieldbus Foundation to complete development
of a single, open, international, and interoperable
fieldbus.
2.1.3 President
The President reports to the Board of Directors,
manages the day-to-day activities of the Fieldbus
Foundation, and provides direction for the Executive,
Technical, Marketing, and Member Support functions.
The Fieldbus Foundation is an independent, not-forprofit organization based on the following principles:
• Fieldbus technology is an enabling technology;
not a differentiating technology.
2.1.4 End User Councils
The End User Councils (EUC) are comprised of
users of fieldbus equipment. There are EUCs in
North America, Europe, Latin America and
Asia-Pacific. The purpose of the EUC is to review
the activities of the foundation and provide input to
help ensure the specifications meet the needs of the
marketplace.
• Fieldbus technology is open and available to all
parties.
• Fieldbus technology is based on the work of the
International Electrotechnical Commission (IEC)
and ISA (the international society for
measurement and control).
2.1.5 Quality Director
The Quality Director provides overall management
of the foundation’s quality assurance systems.
• Fieldbus Foundation members support and work
in the standards committees.
2.1 Organization
2.1.6 Executive Committee
The Executive Committee advises the President concerning the strategic and overall operational issues
of the foundation.
The Fieldbus Foundation is organized as in Figure 8.
2.1.7 Technical Teams
The Technical Teams are responsible for the technical work of the foundation. The technical work is
grouped into programs such as Specifications,
Software, and Interoperability Testing. A Program
Manager is responsible for each technical program.
2.1.8 Marketing Teams
The Marketing Teams are responsible for promoting
FOUNDATION fieldbus and for planning and directing
the foundation’s products and services.
Figure 8
2.1.9 Member Support
Member Support is responsible for coordination and
delivery of the Foundation’s products and services.
Products and services include technical consulting
and training, newsletter printing and distribution,
memberships, coordination of trade shows and field
tests, product catalogs, Device Description software,
and device registrations.
2.1.1 Members
The Fieldbus Foundation has over 130 member
companies. These companies supply over 90% of
the world’s instrumentation and control products.
3
© 1996 (Rev.1998) Fieldbus Foundation, Austin, Texas. All rights reserved.
Technology
Each layer in the communication system is responsible for a portion of the message that is transmitted
on the fieldbus.
3.0 FOUNDATION FIELDBUS TECHNOLOGY
g FF-800 System Architecture Specification*
The numbers below show the approximate number
of eight bit “octets” used for each layer to transfer
the USER data (Figure 10).
*Note: References to specific documents are noted
as follows: g Document number and name.
FOUNDATION fieldbus technology consists of: 1) the
Physical Layer, 2) the Communication “Stack,” and
3) the User Application. The Open Systems
Interconnect (OSI) layered communication model is
used to model these components (Figure 9).
3.1 Physical Layer (31.25 kbit/s)
g ISA S50.02-1992 ISA Physical Layer Standard
g IEC 61158-2 (1993) International Physical
Layer Standard
g FF-816 31.25 kbit/s Physical Layer Profile
Specification
g FF-818 31.25 kbit/s Fiber Optic Physical Layer
Profile
The Physical Layer is OSI layer 1. The Data Link
Layer (DLL) is OSI layer 2. The Fieldbus Message
Specification (FMS) is OSI layer 7. The Communication Stack is comprised of layers 2 and 7 in the
OSI model.
The Physical Layer is defined by approved standards from the International Electrotechnical
Commission (IEC) and ISA (the international society
for measurement and control).
The fieldbus does not use OSI layers 3, 4, 5 and 6.
The Fieldbus Access Sublayer (FAS) maps the FMS
onto the DLL.
The User Application is not defined by the OSI
model. The Fieldbus Foundation has specified a
User Application model.
Fieldbus Model
OSI Model*
USER
APPLICATION
APPLICATION LAYER
PRESENTATION LAYER
The Physical Layer receives messages from the
communication stack and converts the messages
into physical signals on the fieldbus transmission
medium and vice-versa.
7
USER
APPLICATION
USER
APPLICATION
USER Data
FIELDBUS MESSAGE
SPECIFICATION
FIELDBUS MESSAGE
SPECIFICATION
FMS
PCI*
FIELDBUS ACCESS
SUBLAYER
FIELDBUS ACCESS
SUBLAYER
COMMUNICATION
“STACK”
5
TRANSPORT LAYER
4
NETWORK LAYER
3
DATA LINK LAYER
2
DATA LINK LAYER
PHYSICAL LAYER
1
PHYSICAL LAYER
0 to 251
FAS
PCI*
1
6
SESSION LAYER
USER Encoded Data
4
DLL
PCI*
DATA LINK LAYER
5 - 15
PHYSICAL LAYER
Preamble
1***
PHYSICAL LAYER
Fieldbus
* The user application is not defined by the OSI Model
Start
Delimiter
1
4 to 255
FAS PDU**
Frame Check
Sequence
5 to 256
2
DLL PDU**
8-273
End
Delimiter
1
* Protocol Control Information
** Protocol Data Unit
*** There may be more than 1 octet of preamble if
repeaters are used.
Figure 10
Figure
Figure9 9
FMS PDU**
Figure 10
4
© 1996 (Rev.1998) Fieldbus Foundation, Austin, Texas. All rights reserved.
Technology
Conversion tasks include adding and removing
preambles, start delimiters, and end delimiters
(Figure 11).
The preamble is used by the receiver to synchronize
its internal clock with the incoming fieldbus signal.
Special N+ and N- codes are in the start delimiter
and end delimiter. Note that the N+ and N- signals
do not transition in the middle of a bit time. The
receiver uses the start delimiter to find the beginning
of a fieldbus message. After it finds the start delimiter, the receiver accepts data until the end delimiter
is received.
Fieldbus signals are encoded using the well-known
Manchester Biphase-L technique. The signal is
called “synchronous serial” because the clock information is embedded in the serial data stream.
Data is combined with the clock signal to create the
fieldbus signal as shown in the figure below. The
receiver of the fieldbus signal interprets a positive
transition in the middle of a bit time as a logical “0”
and a negative transition as a logical “1” (Figure 12).
3.1.1 31.25 kbit/s Fieldbus Signaling
The transmitting device delivers ± 10 mA at
31.25 kbit/s into a 50 ohm equivalent load to create
a 1.0 volt peak-to-peak voltage modulated on top of
the direct current (DC) supply voltage.
Special characters are defined for the preamble,
start delimiter, and end delimiter (Figure 13).
USER
APPLICATION
Example of voltage mode signaling
Fieldbus
Messages
COMMUNICATION
“STACK”
1
1
1
Voltage
1
PHYSICAL LAYER
Fieldbus Media
(Wire)
Time
Figure1111
Figure
1 Bit Time
CLOCK
1
0
CLOCK
1
0
1
0
1
0
1
0
1
N+
N-
1
0
N-
N+
0
1
N+
N-
N+
N-
1
0
1
+
PREAMBLE
DATA
1
0
0
1
1
0
START
DELIMITER
0
+
MANCHESTER
BIPHASE-L
ENCODING
0
+
0
+
END
DELIMITER
-
0
-
Figure 13
FigureFigure
12 12
Figure 13
5
© 1996 (Rev.1998) Fieldbus Foundation, Austin, Texas. All rights reserved.
Technology
The DC supply voltage can range from 9 to 32 volts.
However, for I.S. applications, the allowed power
supply voltage depends on the barrier rating
(Figure 14).
3.1.2 31.25 kbit/s Fieldbus Wiring
g AG-140 31.25 kbit/s Wiring and Installation Guide
AG-163 31.25 kbit/s Intrinsically Safe Systems
Application Guide
AG-165 Fieldbus Installation and Planning Guide
31.25 kbit/s devices can be powered directly from
the fieldbus and operate on wiring previously used
for 4-20 mA devices.
The 31.25 kbit/s fieldbus allows stubs or “spurs”
(Figure 15).
The 31.25 kbit/s fieldbus also supports intrinsically
safe (I.S.) fieldbuses with bus powered devices. To
accomplish this, an I.S. barrier is placed between
the power supply in the safe area and the I.S.
device in the hazardous area.
The length of the fieldbus is determined by the
communication rate, cable type, wire size, bus
power option, and I.S. option.
Signaling waveforms for the 31.25 kbit/s Fieldbus
Control Room
Equipment
+
Trunk*
15 to 20 mA p-p
Junction
Box
Fieldbus Signal
Devices***
Spur Length**
25-32
19-24
15-18
13-14
1-12
1 metre
30 metres
60 metres
90 metres
120 metres
0
Receiving
Transmitting
100 Ohm
Spurs
0.75 to 1.0 V p-p
Voltage
Device Current
Fieldbus Device
Cable Length = Trunk Length + All Spur Lengths
Maximum Length = 1900 metres with “Type A” Cable
Power
9 to 32 Volts
100 Ohm
Power
Supply
* A terminator is installed at each end of the main trunk cable.
Time
C
Fieldbus Network
C
**
Single device per spur -- The spur length must be reduced by 30
metres for each additional device on a spur.
Terminator
C is sized to
pass 31.25 kbit/s.
***
The number of devices possible on the fieldbus will vary
depending on factors such as the power consumption of each
device, the type of cable used, use of repeaters, etc. Consult the
Physical Layer Standard for details.
Note: As an option, one of the terminators
may be center-tapped and grounded to
prevent voltage buildup on the fieldbus.
Figure
14
Figure
Figure 15
14
Figure 15
6
© 1996 (Rev.1998) Fieldbus Foundation, Austin, Texas. All rights reserved.
Technology
Figure 16 gives a summary of examples of options
available in the Physical Layer standard.
Layer 2, the Data Link Layer (DLL), controls transmission of messages onto the fieldbus. The DLL
manages access to the fieldbus through a deterministic centralized bus scheduler called the Link Active
Scheduler (LAS).
3.2 Communication Stack
The following sections will describe the operation of
the layers in the Communication Stack (Figure 17).
The DLL is a subset of the emerging IEC/ISA DLL
standard.
3.2.1 The Data Link Layer (DLL)
g FF-821 Data Link Layer Services
Subset Specification
g FF-822 Data Link Layer Protocol
Subset Specification
Characteristics
Type
Topology
Bus Power
Classification
Data Rate
31.25 kbit/s
Voltage
Bus/tree
none
Number of Devices* 2-32
Cable Length
1900 m
Spur Length
120 m
31.25 kbit/s
Voltage
Bus/tree
DC
Intrinsically
Safe
31.25 kbit/s
Voltage
Bus/tree
DC
2-6
1900 m
120 m
2-12
1900 m
120 m
USER
APPLICATION
USER
APPLICATION
FIELDBUS MESSAGE
SPECIFICATION
FIELDBUS ACCESS
SUBLAYER
COMMUNICATION
STACK
Figure 16
* The number of devices possible on a fieldbus link depends on
factors such as the power consumption of each device, the type
of cable used, use of repeaters, etc. Consult the Physical Layer
Standard for details. The number of network addresses available
for each link is 240.
DATA LINK LAYER
PHYSICAL LAYER
PHYSICAL LAYER
Figure
1719
Figure
7
© 1996 (Rev.1998) Fieldbus Foundation, Austin, Texas. All rights reserved.
Technology
3.2.1.1 Device Types
Two types of devices are defined in the DLL specification:
3.2.1.2 Scheduled Communication
The Link Active Scheduler (LAS) has a list of transmit times for all data buffers in all devices that need
to be cyclically transmitted.
• Basic Device
• Link Master
When it is time for a device to send a buffer, the
LAS issues a Compel Data (CD) message to the
device.
Link Master devices are capable of becoming the
Link Active Scheduler (LAS). Basic devices do not
have the capability to become the LAS (Figure 18).
Upon receipt of the CD, the device broadcasts or
“publishes” the data in the buffer to all devices on
the fieldbus. Any device configured to receive the
data is called a “subscriber” (Figure 19).
Scheduled data transfers are typically used for the
regular, cyclic transfer of control loop data between
devices on the fieldbus.
Scheduled Data Transfers
The message in the data buffer is broadcast to all devices on the
fieldbus when the LAS issues the compel data to the publisher.
The subscribers listen to the message broadcast.
LAS = Link Active Scheduler
CD = Compel Data
Schedule
Fieldbus
LAS
a
b
c
CD (a)
LAS
BASIC
DEVICE
LINK MASTER
DEVICE
BASIC
DEVICE
BASIC
DEVICE
LINK MASTER
DEVICE
Fieldbus
Message
BASIC
DEVICE
Data a
Figure 20
Figure 18
Publisher
Data a
Subscriber
Figure 19
8
© 1996 (Rev.1998) Fieldbus Foundation, Austin, Texas. All rights reserved.
Data a
Subscriber
Technology
3.2.1.4.2 Live List Maintenance
The list of all devices that are properly responding
to the Pass Token (PT) is called the “Live List.”
3.2.1.3 Unscheduled Communication
All of the devices on the fieldbus are given a chance
to send “unscheduled” messages between transmissions of scheduled messages.
New devices may be added to the fieldbus at any
time. The LAS periodically sends Probe Node (PN)
messages to the addresses not in the Live List. If a
device is present at the address and receives the PN,
it immediately returns a Probe Response (PR) message. If the device answers with a PR, the LAS adds
the device to the Live List and confirms its addition
by sending the device a Node Activation message.
The LAS grants permission to a device to use the
fieldbus by issuing a pass token (PT) message to
the device. When the device receives the PT, it is
allowed to send messages until it has finished or
until the “maximum token hold time” has expired,
whichever is the shorter time (Figure 20).
3.2.1.4 Link Active Scheduler Operation
The following sections describe the overall operation of the Link Active Scheduler (LAS). The algorithm used by the LAS is shown in Figure 21.
The LAS is required to probe at least one address
after it has completed a cycle of sending PTs to all
devices in the Live List.
3.2.1.4.1 CD Schedule
The CD Schedule contains a list of activities that
are scheduled to occur on a cyclic basis. At precisely the scheduled time, the LAS sends a Compel
Data (CD) message to a specific data buffer in a
fieldbus device. The device immediately broadcasts
or “publishes” a message to all devices on the fieldbus. This is the highest priority activity performed
by the LAS. The remaining operations are performed between scheduled transfers.
The device will remain in the Live List as long as it
responds properly to the PTs sent from the LAS.
The LAS will remove a device from the Live List if
the device does not either use the token or immediately return it to the LAS after three successive tries.
Whenever a device is added or removed from the
Live List, the LAS broadcasts changes to the Live
List to all devices. This allows each device to maintain a current copy of the Live List.
Link Active Scheduler Algorithm
Unscheduled Data Transfers
The message in the queue is transmitted on the fieldbus when
the LAS issues the pass token message to device x. The
message can be sent to a single destination or to multiple
destinations (multicast).
Live List
PT (x)
LAS
x
y
z
Is
there time to do
something
before next
CD?
LAS = Link Active Scheduler
PT = Pass Token
Fieldbus
No
Wait
until it is time to
issue the CD
Send
idle messages
while waiting.
Message
CD = Compel Data
PN = Probe Node
TD = Time Distribution
PT = Pass Token
Yes
Data
Data
Issue
PN, TD, or PT
Device x
Figure 23
Figure 20
Issue
CD
Figure
2124
Figure
9
© 1996 (Rev.1998) Fieldbus Foundation, Austin, Texas. All rights reserved.
Technology
3.2.1.4.3 Data Link Time Synchronization
The LAS periodically broadcasts a Time Distribution
(TD) message on the fieldbus so that all devices
have exactly the same data link time. This is important because scheduled communications on the
fieldbus and scheduled function block executions in
the User Application are based on information
obtained from these messages.
3.2.2.1 Client/Server VCR Type
The Client/Server VCR Type is used for queued,
unscheduled, user initiated, one to one, communication between devices on the fieldbus.
Queued means that messages are sent and
received in the order submitted for transmission,
according to their priority, without overwriting
previous messages.
3.2.1.4.4 Token Passing
The LAS sends a Pass Token (PT) message to all
devices in the Live List. The device is allowed to
transmit unscheduled messages when it receives
the PT.
When a device receives a Pass Token (PT) from the
LAS, it may send a request message to another
device on the fieldbus. The requester is called the
“Client” and the device that received the request is
called the “Server.” The Server sends the response
when it receives a PT from the LAS.
3.2.1.4.5 LAS Redundancy
A fieldbus may have multiple Link Masters. If the
current LAS fails, one of the Link Masters will
become the LAS and the operation of the fieldbus
will continue. The fieldbus is designed to “fail operational.”
The Client/Server VCR Type is used for operator
initiated requests such as setpoint changes, tuning
parameter access and change, alarm acknowledge,
and device upload and download.
3.2.2.2 Report Distribution VCR Type
The Report Distribution VCR Type is used for
queued, unscheduled, user initiated, one to many
communications.
3.2.2 Fieldbus Access Sublayer (FAS)
g FF-875 Fieldbus Access Sublayer
Specification
The FAS uses the scheduled and unscheduled features of the Data Link Layer to provide a service for
the Fieldbus Message Specification (FMS). The
types of FAS services are described by Virtual
Communication Relationships (VCR).
When a device with an event or a trend report
receives a Pass Token (PT) from the LAS, it sends
its message to a “group address” defined for its
VCR. Devices that are configured to listen on that
VCR will receive the report.
The VCR is like the speed dial feature on your memory telephone. There are many digits to dial for an
international call such as international access code,
country code, city code, exchange code and finally
the specific telephone number.
The Report Distribution VCR Type is typically used
by fieldbus devices to send alarm notifications to
the operator consoles.
This information only needs to be entered once and
then a “speed dial number” is assigned.
After setup, only the speed dial number needs to be
entered for the dialing to occur. Likewise, after
configuration, only the VCR number is needed to
communicate with another fieldbus device.
Just as there are different types of telephone calls
such as person to person, collect, or conference
calls, there are different types of VCRs.
10
© 1996 (Rev.1998) Fieldbus Foundation, Austin, Texas. All rights reserved.
Technology
3.2.2.3 Publisher/Subscriber VCR Type
The Publisher/Subscriber VCR Type is used for
buffered, one to many communications.
FMS describes the communication services, message formats, and protocol behavior needed to
build messages for the User Application (Figure 23).
Data that is communicated over the fieldbus is
described by an “object description.” Object
descriptions are collected together in a structure
called an “object dictionary” (OD), (Figure 24).
Buffered means that only the latest version of the
data is maintained within the network. New data
completely overwrites previous data.
When a device receives the Compel Data (CD), the
device will “Publish” or broadcast its message to all
devices on the fieldbus. Devices that wish to receive
the Published message are called “Subscribers.”
The object description is identified by its “index” in
the OD. Index 0, called the object dictionary header, provides a description of the dictionary itself, and
defines the first index for the object descriptions of
the User Application. The User Application object
descriptions can start at any index above 255.
The CD may be scheduled in the LAS, or it may be
sent by Subscribers on an unscheduled basis. An
attribute of the VCR indicates which method is used.
Index 255 and below define standard data types
such as boolean, integer, float, bitstring, and data
structures that are used to build all other object
descriptions.
The Publisher/Subscriber VCR Type is used by the
field devices for cyclic, scheduled, publishing of
User Application function block input and outputs
such as process variable (PV) and primary output
(OUT) on the fieldbus.
3.2.2.4 Summary of VCR Types
(Figure 22).
3.2.3 Fieldbus Message Specification (FMS)
g FF-870 Fieldbus Message Specification
Fieldbus
Device
Fieldbus Message Specification (FMS) services
allow user applications to send messages to each
other across the fieldbus using a standard set of
message formats.
User
Application
Fieldbus
Device
Communication
Services
FMS
FMS
FAS
FAS
DLL
DLL
FIELDBUS ACCESS SUBLAYER SERVICES
User
Application
PHY
PHY
FIELDBUS
Figure 23
Client/Server
VCR Type
Used for
Operator Messages
Setpoint changes
Mode changes
Tuning changes
Upload/Download
Alarm Management
Access display views
Remote diagnostics
Report Distribution
VCR Type
Publisher/Subscriber
VCR Type
Used for
Event Notification
and
Trend Reports
Used for
Publishing Data
Send process alarms
to operator consoles.
Object Dictionary
Send transmitter PV
to PID control block
and operator console.
Send trend reports
to data historians.
DATA LINK LAYER SERVICES
Index 0
Object Dictionary Header
Index 1
Object Description 1
Index 2
Object Description 2
Index n
Object Description n
Figure 27
Figure 25
Figure 24
Figure 22
11
© 1996 (Rev.1998) Fieldbus Foundation, Austin, Texas. All rights reserved.
Technology
3.2.3.1 Virtual Field Device (VFD)
A “Virtual Field Device” (VFD) is used to remotely
view local device data described in the object dictionary. A typical device will have at least two VFDs
(Figure 25).
Detailed descriptions for each service are provided
in the g FF-870 Fieldbus Message Specification.
3.2.3.2.1 Context Management Services
The following FMS services are used to establish
and release Virtual Communications Relationships
(VCR) with, and determine the status of a VFD.
Network Management (see g FF-801 Network
Management Specification) is part of the Network and
System Management Application. It provides for the
configuration of the communication stack. The Virtual
Field Device (VFD) used for Network Management is
also used for System Management. This VFD provides access to the Network Management Information
Base (NMIB) and to the System Management
Information Base (SMIB). NMIB data includes Virtual
Communication Relationships (VCR), dynamic variables, statistics, and Link Active Scheduler (LAS)
schedules (if the device is a Link Master). SMIB data
includes device tag and address information, and
schedules for function block execution.
Initiate
Abort
Reject
Status
UnsolicitedStatus
Identify
3.2.3.2.2 Object Dictionary Services
The following FMS services allow the User
Application to access and change the object
descriptions (OD) in a VFD.
GetOD
InitiatePutOD
PutOD
TerminatePutOD
System Management is described further in the User
Application section.
3.2.3.2 Communication Services
FMS communication services provide a standardized
way for user applications such as function blocks to
communicate over the fieldbus. Specific FMS communication services are defined for each object type.
Fieldbus Device
Network
Management
VFD
Object
Descriptions
Object
Data
System
Management
Application
System
Management
VFD
Function
Block
Application
*Can use Publisher/Subscriber or Report
Distribution VCR Types.
User
Application
VFD
Object
Descriptions
Object
Descriptions
Object
Data
Object
Data
Read an object dictionary(OD)
Start an OD Load
Load an OD into a device
Stop an OD Load
3.2.3.2.3 Variable Access Services
The following FMS services allow the user application
to access and change variables associated with an
object description.
Read
Read a variable
Write
Write a variable
InformationReport
Send Data*
DefineVariableList
Define a Variable List
DeleteVariableList
Delete a Variable List
All of the FMS services can only use the Client/Server
VCR Type except as noted.
Network
Management
Application
Establish communications
Release communications
Reject improper service
Read a device status
Send unsolicited status
Read vendor, type and version
3.2.3.2.4 Event Services
The following FMS services allow the user application to report events and manage event processing.
EventNotification
AcknowledgeEventNotification
FMS
FAS
AlterEventConditionMonitoring
DLL
PHY
FIELDBUS
Report an
event*
Acknowledge
an event
Disable /
Enable event *
* Can use Report Distribution VCR Type
Figure 28
Figure 25
12
© 1996 (Rev.1998) Fieldbus Foundation, Austin, Texas. All rights reserved.
Technology
3.2.3.2.5 Upload/Download Services
It is often necessary to remotely upload or download data and programs over the fieldbus, especially
for more complex devices such as programmable
logic controllers.
download service and then remotely operate the
program by issuing PI service requests.
The state diagram for the PI is shown as an example of FMS protocol behavior later in this document.
To allow uploads and downloads using the FMS
services, a “Domain” is used. A Domain represents
a memory space in a device.
CreateProgramInvocation
The following FMS services allow the User
Application to upload and download a Domain in a
remote device.
Start
Stop
Resume
RequestDomainUpload
InitiateUploadSequence
UploadSegment
Reset
Kill
TerminateUploadSequence
RequestDomainDownload
InitiateDownloadSequence
DownloadSegment
TerminateDownloadSequence
DeleteProgramInvocation
Request Upload
Open Upload
Read data from
device
Stop Upload
Request Download
Open Download
Send data to
device
Stop Download
Create a program
object
Delete a program
object
Start a program
Stop a program
Resume program
execution
Reset the program
Remove the
program
3.2.3.3 Message Formatting
g ASN.1 Tutorial and Reference -- Steedman
The exact formatting of FMS messages is defined
by a formal syntax description language called
Abstract Syntax Notation 1 (ASN.1).
ASN.1 was developed by the International Telegraph
and Telephone Consultative Committee (CCITT) in
the early 1980s as a part of the CCITT mail standardization activities.
3.2.3.2.6 Program Invocation Services
The “Program Invocation” (PI) allows the execution
of a program in one device to be controlled remotely.
A device could download a program into a Domain
(see previous section) of another device using the
See Figure 26 for a partial example of ASN.1 definition for the FMS Read service.
Read_Request::= SEQUENCE {
Access-specification CHOICE {
index
[0] IMPLICIT Index,
variable-name
[1] IMPLICIT Name,
variable-list-name
[2] IMPLICIT Name,
},
sub-index [3] IMPLICIT Subindex OPTIONAL
}
User
Application
ASN.1 Definition of a Read_Request
FMS
FAS
DLL
PHY
Figure 29
Figure 26
13
© 1996 (Rev.1998) Fieldbus Foundation, Austin, Texas. All rights reserved.
Technology
This example states that the items Access-specification and sub-index occur in SEQUENCE in the
message.
example, the remote device would use the Create
Program Invocation FMS service to change the
program state from Non-existent to Idle.
The Access-specification is a CHOICE of using
either an index or a name to access a variable.
The Start FMS service would be used to change
the state from Idle to Running and so on.
3.3 User Application -- Blocks
The sub-index is OPTIONAL. It is used only to
select an individual element of an array or record
variable.
g FF-890 Function Blocks -- Part 1
The Fieldbus Foundation has defined a standard
User Application based on “Blocks.” Blocks are
representations of different types of application
functions (Figure 28).
The numbers in the brackets are the actual encoding numbers that are used to identify the fields in an
encoded message.
3.2.3.4 Protocol Behavior
Certain types of objects have special behavioral
rules that are described by the FMS specification.
For example, the simplified behavior of a Program
Invocation object is shown in Figure 27.
The types of blocks used in a User Application are
described in Figure 29.
3.3.1 Resource Block
The Resource Block describes characteristics of the
fieldbus device such as the device name, manufacturer, and serial number. There is only one resource
block in a device.
A remote device can control the state of the
program in another device on the fieldbus. For
Nonexistent
CREATE
RESET
USER
APPLICATION
DELETE
FIELDBUS MESSAGE
SPECIFICATION
Idle
START
KILL
FIELDBUS ACCESS
SUBLAYER
Running
STOP
USER
APPLICATION
Unrunnable
RESUME
Stopped
COMMUNICATION
“STACK”
DATA LINK LAYER
User
Application
Behavior Rules for the Program
Invocation Object.
PHYSICAL LAYER
FMS
FAS
DLL
PHY
Figure 27
PHYSICAL LAYER
Figure
Figure 3128
Figure 30
Blocks
Resource
Block
Function
Block
Transducer
Block
COMMUNICATION
“STACK”
PHYSICAL LAYER
Fieldbus
Figure
29
Figure 32
14
© 1996 (Rev.1998) Fieldbus Foundation, Austin, Texas. All rights reserved.
Technology
Technology
3.3.2 Function Block
Function Blocks (FB) provide the control system
behavior. The input and output parameters of
Function Blocks can be linked over the fieldbus. The
execution of each Function Block is precisely
scheduled. There can be many function blocks in a
single User Application.
contain an AI function block. A control valve might
contain a PID function block as well as the expected
AO block.
The Fieldbus Foundation has defined sets of standard Function Blocks. Ten standard Function Blocks
for basic control are defined by the g FF-891
Function Blocks -- Part 2 specification. These
blocks are listed below.
3.3.3 Transducer Blocks
Transducer Blocks decouple Function Blocks from
the local input/output functions required to read
sensors and command output hardware. They contain information such as calibration date and sensor
type. There is usually one transducer block for each
input or output function block.
Function Block Name
Analog Input
Analog Output
Bias
Control Selector
Discrete Input
Discrete Output
Manual Loader
Proportional/Derivative
Proportional/Integral/Derivative
Ratio
Thus a complete control loop can be built using
only a simple transmitter and a control valve
(Figure 30).
Symbol
AI
AO
B
CS
DI
DO
ML
PD
PID
RA
The following additional objects are defined in the
User Application:
Link Objects define the links between Function
Block inputs and outputs internal to the device and
across the fieldbus network.
Trend Objects allow local trending of function block
parameters for access by hosts or other devices.
Nineteen additional standard Function Blocks for
advanced control are defined in the g FF-892
Function Blocks -- Part 3 specification.
Alert Objects allow reporting of alarms and events
on the fieldbus.
Function blocks can be built into fieldbus devices as
needed to achieve the desired device functionality.
For example, a simple temperature transmitter may
View Objects are predefined groupings of block
parameter sets that can be used by the human/
machine interface. The function block specification
defines four views for each type of block.
Example of a complete control loop using
Function Blocks located in fieldbus devices.
Fieldbus
Device 1
AI 110
Device 2
PID 110
AO 110
Figure 33
30
Figure
15
© 1996 (Rev.1998) Fieldbus Foundation, Austin, Texas. All rights reserved.
Technology
Technology
Figure 31 shows an example of how common
Function Block variables map into the views. Only a
partial listing of the block parameters is shown in
the example.
3.3.4 Fieldbus Device Definition
The function of a fieldbus device is determined by
the arrangement and interconnection of blocks
(Figure 32).
• VIEW_1 - Operation Dynamic - Information
required by a plant operator to run the process.
The device functions are made visible to the fieldbus communication system through the User
Application Virtual Field Device (VFD) discussed earlier.
• VIEW_2 - Operation Static - Information which
may need to be read once and then displayed along
with the dynamic data.
The header of the User Application object dictionary
points to a Directory which is always the first entry
in the function block application. The Directory provides the starting indexes of all of the other entries
used in the Function Block application (Figure 33).
• VIEW_3 - All Dynamic - Information which is
changing and may need to be referenced in a
detailed display.
• VIEW_4 - Other Static - Configuration and maintenance information.
Function Block Application
Dynamic
Static
Data
Trend
Resource
Block
AI
Alarms
PID, AO
Sensor
1
Fieldbus
Transducer
Block 1
Function
Block 1
AI
Links
Diagnostics
Detail Display
XYZ Block
SP
PV
SP HI LIMIT
CAS IN
GAIN
Display Sets
View_1
Operation
Dynamic
X
X
View_2
Operation
Static
X
View_3
All Dynamic
View_4
Other Static
X
X
X
View
Lists
Alerts
Sensor
2
Function
Block 2
Transducer
Block 2
X
Trend
Object
Figure 34
Figure
Figure
3235
Figure 31
0
OD HEADER
DIRECTORY
RESOURCE BLOCK
FUNCTION BLOCKS
TRANSDUCER BLOCKS
LINK OBJECTS
ALERT OBJECTS
TREND OBJECTS
VIEW OBJECTS
Figure 36
Figure
33
16
© 1996 (Rev.1998) Fieldbus Foundation, Austin, Texas. All rights reserved.
View
Lists
Technology
The VFD object descriptions and their associated
data are accessed remotely over the fieldbus network using Virtual Communication Relationships
(VCRs) as shown below (Figure 34).
3.4.1 Function Block Scheduling
A schedule building tool is used to generate function block and Link Active Scheduler (LAS) schedules. Assume that the schedule building tool has
built the following schedules for the loop previously
described in Figure 30.
3.4 System Management
g FF-800 System Management Specification
The schedules contain the start time offset from the
beginning of the “absolute link schedule start time.”
The absolute link schedule start time is known by all
devices on the fieldbus (Figure 35).
Function Blocks must execute at precisely defined
intervals and in the proper sequence for correct
control system operation.
System management synchronizes execution of the
Function Blocks and the communication of function
block parameters on the fieldbus.
A “macrocycle” is a single iteration of a schedule
within a device. The following figure shows the relationships between the absolute link schedule start
time, LAS macrocycle, device macrocycles, and the
start time offsets.
System management also handles other important
system features such as publication of the time of
day to all devices, including automatic switchover to
a redundant time publisher, automatic assignment
of device addresses, and searching for parameter
names or “tags” on the fieldbus.
Offset from Absolute Link
Schedule Start Time
Scheduled
Scheduled
Scheduled
Scheduled
All of the configuration information needed by
System Management such as the Function Block
schedule is described by object descriptions in the
Network and System Management Virtual Field
Device (VFD) in each device. This VFD provides
access to the System Management Information
Base (SMIB), and also to the Network Management
Information Base (NMIB).
Function Block
Application
Resource
Block
Transducer
Block 1
Function
Block 1
Links
View
Lists
Index
0
Al Function Block Extension
Communications of Al
PID Function Block Execution
AO Function Block Execution
Figure 35
OD Header
Directory
201
202
Resource Block
210
Transducer Block
250
Link Objects
400
Trend Objects
500
Function Block
600
Function Block
1000
View Object
2000
View Object
User
Application
Virtual
Field Device
Stack
Alerts
Function
Block 2
Transducer
Block 2
Trend
Object
View
Lists
Physical
Layer
Fieldbus
Object Descriptions
Figure
Figure
34 37
17
© 1996 (Rev.1998) Fieldbus Foundation, Austin, Texas. All rights reserved.
0
20
30
50
Technology
In Figure 36, System Management in the transmitter
will cause the AI function block to execute at offset 0.
At offset 20 the Link Active Scheduler (LAS) will
issue a Compel Data (CD) to the AI function block
buffer in the transmitter and data in the buffer will
be published on the fieldbus.
System Management has a time publisher which
periodically sends an application clock synchronization message to all fieldbus devices. The data link
scheduling time is sampled and sent with the application clock message so that the receiving devices
can adjust their local application time. Between
synchronization messages, application clock time is
independently maintained in each device based on
its own internal clock.
At offset 30 System Management in the valve will
cause the PID function block to execute followed by
execution of the AO function block at offset 50.
Application Clock synchronization allows the devices
to time stamp data throughout the fieldbus network.
If there are backup application clock publishers on
the fieldbus, a backup publisher will become active if
the currently active time publisher should fail.
The pattern exactly repeats itself assuring the
integrity of the control loop dynamics.
Note that during the function block execution, the
LAS is sending the Pass Token message to all
devices so that they can transmit their unscheduled
messages such as alarm notifications or operator
setpoint changes.
3.4.1.2 Device Address Assignment
Every fieldbus device must have a unique network
address and physical device tag for the fieldbus to
operate properly.
For this example, the only time that the fieldbus can
not be used for unscheduled messages is from offset 20 to offset 30 when the AI function block data
is being published on the fieldbus.
To avoid the need for address switches on the
instruments, assignment of network addresses can
be performed automatically by System Management.
3.4.1.1 Application Clock Distribution
The FOUNDATION Fieldbus supports an application
clock distribution function. The application clock is
usually set equal to the local time of day or to
Universal Coordinated Time.
The sequence for assigning a network address to a
new device is as follows:
• A physical device tag is assigned to a new device
via a configuration device. This can be done “offline” at a bench or “on-line” through special
default network addresses on the fieldbus.
The start of individual macrocycles is defined as an offset
from the absolute link schedule start time.
Absolute Link Schedule Start Time.
DL Offset = 0 for
AI execution.
Sequence
Repeats
Device 1
Macrocycle
DL Offset = 20 for
AI Communication.
AI
AI
LAS
Macrocycle
Unscheduled
Communication
Permitted
DL Offset = 30 for
PID execution.
DL Offset = 50 for
AO execution.
Device 2
Macrocycle
PID AO
0
20
40
60
PID AO
80
100
120
20
LAS Schedule
Duration
40
60
80
100
120
LAS Schedule
Duration
Figure 36
Figure 38
18
© 1996 (Rev.1998) Fieldbus Foundation, Austin, Texas. All rights reserved.
Technology
• Using default network addresses, System
Management asks the device for its physical
device tag. System Management uses the
physical device tag to look up the new network
address in a configuration table. System
Management then sends a special “set address”
message to the device which forces the device to
move to the new network address.
Device Description (DD) technology is used in
addition to standard function block parameter and
behavior definitions.
The DD provides an extended description of each
object in the Virtual Field Device (VFD) as shown in
Figure 37.
The DD provides information needed for a control
system or host to understand the meaning of the
data in the VFD including the human interface for
functions such as calibration and diagnostics. Thus
the DD can be thought of as a “driver” for the
device.
• The sequence is repeated for all devices that enter
the network at a default address.
3.4.1.3 Find Tag Service
For the convenience of host systems and portable
maintenance devices, System Management supports a
service for finding devices or variables by a tag search.
The DDs are similar to the drivers that your personal
computer (PC) uses to operate different printers and
other devices that are connected to the PC. Any
control system or host can operate with the device
if it has the device's DD.
The “find tag query” message is broadcast to all
fieldbus devices. Upon receipt of the message, each
device searches its Virtual Field Devices (VFD) for the
requested tag and returns complete path information
(if the tag is found) including the network address,
VFD number, virtual communication relationship
(VCR) index, and object dictionary (OD) index.
Once the path is known, the host or maintenance
device can access the data for the tag.
3.5.1 Device Description Tokenizer
g FD-900 Device Description Language
Specification
g FD-100 DDL Tokenizer User’s Manual
The DD is written in a standardized programming
language known as Device Description Language
(DDL). A PC-based tool called the “Tokenizer” converts DD source input files into DD output files by
replacing key words and standard strings in the
source file with fixed “tokens” as shown in Figure 38.
3.5 Device Descriptions
A critical characteristic required of fieldbus devices
is interoperability. To achieve interoperability,
Virtual Field Device
Object
Description
of Data
DDL Source File
VARIABLE ProcessVariable
{ LABEL "MEASURED_VALUE";
TYPE FLOAT
{ DISPLAY_FORMAT "3.1f";
MAX_VALUE 110.0;
MIN_VALUE 0.0; }
}
Pointer to
Device Description
of Data
Data
DD
Extended Descriptions
Associated with the Data
DD Output File
Label of the parameter
Engineering units
How many decimal points to display
Help text
Parameter relationships
Calibration and diagnostic menus
009 101
002 "MEASURED_VALUE"
001 010
061 "3.1f"
021 066 220 000 000
020 000 000 000 000
Tokenizer Tool
Figure 42
Figure
41 37
Figure
Figure 38
19
© 1996 (Rev.1998) Fieldbus Foundation, Austin, Texas. All rights reserved.
Technology
3.5.2 Device Description Services (DDS)
The Fieldbus Foundation (FF) provides DDs for all
standard Function Blocks and Transducer Blocks.
Device suppliers will typically prepare an “incremental” DD which references the Standard DDs.
Suppliers may also add supplier specific features
such as calibration and diagnostic procedures to
their devices. These features can also be described
in the incremental DD.
g FD-110 DDS User’s Guide
On the host side, library functions called Device
Description Services (DDS) are used to read the
device descriptions (Figure 40).
Note that DDS reads descriptions, not operational
values. The operational values are read from the
fieldbus device over the fieldbus using FMS communication services.
The Fieldbus Foundation makes the Standard DDs
available on a CD-ROM. The user can obtain the
incremental DD from the device supplier or from the
Fieldbus Foundation if the supplier has registered
their incremental DD with the Fieldbus Foundation
(Figure 39).
The incremental DDs can also be read directly from
the device over the fieldbus, if the device supports
the upload services and contains a Virtual Field
Device (VFD) for the DD.
Standard DDs
plus optional
Incremental DDs
Standard Device Descriptions
from the Fieldbus Foundation.
Descriptions are
read from the DD.
Label
TO HOST
SYSTEM
25.50 %
...
A
Incremental Device Descriptions
from Suppliers.
Number of digits
of precision.
Engineering Unit
Device Description
Services Library
Z
Figure 43
Host
Application
Data are read from
the device over the
fieldbus.
Figure
4440
Figure
Figure 39
20
© 1996 (Rev.1998) Fieldbus Foundation, Austin, Texas. All rights reserved.
Measured_Value
Technology
New devices are added to the fieldbus by simply
connecting the device to the fieldbus wire and providing the control system or host with the standard
and incremental (if any) DD for the new device
(Figure 41).
The third level is called Transducer Block
Parameters. At this level, parameters are defined
for the standard Transducer Blocks. In some cases,
the transducer block specification may add parameters to the standard Resource Block.
The Fieldbus Foundation has written the Device
Descriptions for the first three layers of the
hierarchy. These are the standard Fieldbus
Foundation DDs.
DDS technology allows operation of devices from
different suppliers on the same fieldbus with only
one version of the host human interface program.
3.5.3 Device Description Hierarchy
The Fieldbus Foundation has defined a hierarchy of
Device Descriptions (DD) to make it easier to build
devices and perform system configuration. The
hierarchy is shown in Figure 42.
The fourth level of the hierarchy is called
Manufacturer Specific Parameters. At this level,
each manufacturer is free to add additional
parameters to the Function Block Parameters and
Transducer Block Parameters. These new
parameters will be included in the “incremental”
DD discussed earlier.
The first level in the hierarchy is the Universal
Parameters. Universal Parameters consist of common attributes such as Tag, Revision, Mode, etc. All
blocks must include the Universal Parameters.
The next level in the hierarchy is the Function Block
Parameters. At this level, parameters are defined
for the standard Function Blocks. Parameters for
the standard Resource Block are also defined at this
level.
Universal
Parameters
Device from
Supplier A
DD
Services
Inside
Function
Block
Parameters
Device
Descriptions
AI
Transducer
Block
Parameters
Device from
Supplier Z
PID
AI
RESOURCE
TEMP
PID
FLOW
Manufacturer
Specific
Parameters
Fieldbus
Resource
Block
Figure 45
Figure 41
Defined
by
Fieldbus Foundation
Specification
Defined
by
Manufacturer
Transducer
Blocks
Function
Blocks
Figure
Figure42
46
21
© 1996 (Rev.1998) Fieldbus Foundation, Austin, Texas. All rights reserved.
System
3.5.4 Interoperability
g FD-210 Interoperability Tester User’s Guide
The first difference is in the physical wiring due to
the change from 4-20 mA analog point-to-point
wiring to a digital bus wiring where many devices
can be connected to one wire.
Each manufacturer will provide the Fieldbus
Foundation with an interoperability test report for
each device.
Each device on the fieldbus must have a unique
physical device tag and a corresponding network
address.
The test report identifies the Universal, Function
Block, Transducer Block, and Manufacturer Specific
Parameters in the device. An identifier called the
Manufacturer’s Identification is used to correlate the
device type and revision with its Device Description
and DD revision.
The second difference is the ability to distribute
some of the control and input/output (I/O) sub system functions from the control system to the fieldbus devices. This may reduce the number of rack
mounted controllers and remote mounted I/O equipment needed for the system design (Figure 43).
Any host using the Device Description Services
(DDS) interpreter will be able to interoperate with all
parameters that have been defined in the device by
reading the device’s DD.
4.2 Device Configuration
After the system design is completed and the
instruments have been selected, the device configuration is performed by connecting Function Block
inputs and outputs together in each device as
required by the control strategy (Figure 44).
4. SYSTEM CONFIGURATION
Fieldbus system configuration consists of two phases:
1) System Design and 2) Device Configuration.
After all of the function block connections and other
configuration items such as device names, loop
tags, and loop execution rate have been entered,
the configuration device generates information for
each fieldbus device.
4.1 System Design
The system design for fieldbus-based systems is
very similar to today’s Distributed Control Systems
(DCS) design with the following differences.
TRANSMITTER
FIELDBUS DEVICE
Control Room Console
VALVE
FIELDBUS DEVICE
PID
AI
OUT
OUT
IN
31.25 kbit/s Fieldbus #1
IN
31.25 kbit/s Fieldbus #2
Figure 47
Figure4448
Figure
Figure 43
22
© 1996 (Rev.1998) Fieldbus Foundation, Austin, Texas. All rights reserved.
AO
Field Test
A stand-alone loop can be configured if there is a
field device that is a Link Master. This will allow
continued operation of the loop without the configuration device or a central console (Figure 45).
5.1 Test Instrumentation
Fieldbus transmitter instrumentation installed on the
system included:
•
•
•
•
•
The system becomes operational after the field-bus
devices have received their configurations.
5. FIELD TEST SYSTEM
Benefits of fieldbus technology were directly
observed during field tests on real processes. This
section gives the results of one of the tests.
Fieldbus devices were installed on a condensate
recovery system in a utilities plant.
level on each tank and across both tanks
pressure on the flash tank
flow on the boiler feedwater system
total pump flow
recycle flow
The control valves were equipped with digital
positioners which were used to control the boiler
feedwater treatment and recycle flow.
The instruments were connected to one of two
fieldbuses connected to a distributed control system (DCS) located in the utilities control room. The
installation used a combination of existing twisted
pair wiring and new wiring. While not required by the
process, intrinsic safety barriers were demonstrated
on the system.
The recovery system receives the steam condensate returning to the utilities plant from the rest of
the site and returns this condensate into the water
treatment system (Figure 46).
The process consists of two tanks: a flash tank,
which is approximately 85 gallons and a condensate
tank of approximately 20 gallons. The flash tank is
mounted directly above the other tank.
Performance of the fieldbus was monitored by bus
analyzers.
The returning condensate flows into the flash tank,
where lowering of pressure may cause the condensate to flash to steam. The liquid condensate flows
down into the condensate tank from which it is
pumped forward into the boiler feedwater system.
The configuration device generates all of the information
needed to set up the fieldbus.
Condensate
from Header
Field Test System
Configuration
Device
PT-105
Systems
Engineer
PT
TT TT
TT LT
LIC
FT
FIC
FT
FIC
FT
TI
Network Setup
VCR Setup
Device Address List
Initial Values
LAS Schedule
Active/Standby LAS
LT-203
Device
Descriptions
Flash Tank
TT-104
Network Setup
VCR Setup
TAG Setup
Link Object Setup
Initial Values
Function Block Schedules
LT
Condensate
Tank
CV-202
LT-101
FT-201
CV-103
TT-104
FT-204
FT
Recirculation
Pump
FT-102
Link Master Device
Fieldbus
Basic Devices
Figure 50
Figure 46
Figure
Figure4945
23
© 1996 (Rev.1998) Fieldbus Foundation, Austin, Texas. All rights reserved.
To Water
Treatment
Field Test
Wiring was configured by connecting the fieldbus
devices to one of two terminal panels in a junction
box located by the process equipment. Two wire
pairs, one pair for each terminal panel, were used to
connect the fieldbuses to the control room.
Some applications might specify fewer devices per
wire pair than the test system. In that case, the
savings shown in the above table would be proportionately reduced according to the specific
wiring configuration.
The total condensate level of the system is
controlled by selecting a preferred setpoint on the
level PID, LIC-101, which is located in the level
transmitter. The level PID is used as the primary
loop cascaded to the flow PID, FIC-103, located in
the valve on the feedwater system.
During the checkout phase, a reduction in effort to
confirm the proper connection of the fieldbus
devices was observed. One person performed the
checkout by using the test tool connected to the
fieldbus. With conventional 4-20 mA wiring, two
people would have been required to check out each
wire and confirm operation of each transmitter.
The re-circulation of condensate, from the condensate tank to the flash tank, is controlled by an additional PID loop, FIC-202, located in the valve. The
control strategy for this cascade loop is totally
implemented in the transmitters and flow valve as
shown in Figure 47.
Each transmitter was interrogated and adjusted
remotely. Device parameters such as the high and
low range values were changed without having a
technician adjust a potentiometer in the field.
When a device was disconnected from the fieldbus,
the disconnection did not affect any other devices
remaining on the bus. When the device was reconnected, the system had no trouble re-establishing
communication with the device. Approximately two
person-days of labor (25%) were saved due to the
remote verification of wiring, remote device identification, and remote device configuration checkout.
5.2 Installation, Startup, and Operation
Benefits Observed
The wire runs, from fieldbus devices to the terminal
panel, averaged 28 metres of new wire for each
device, while two 185 metres of existing wire runs
were used from each of the terminal panels to the
control room.
The processing load on the DCS controller was
reduced because of the PID algorithms which were
executing in the fieldbus devices.
If standard 4-20 mA analog devices had been used,
ten new runs of 230 metres (28 metres from the
device to the terminal panel plus 185 metres to the
equipment room plus 17 metres to the DCS) would
have been required. Savings in installation costs
are summarized in the following table.
Wiring Technology
Wire Length
4-20 mA Analog
Digital Fieldbus
Savings with
Fieldbus
Savings in %
2300 metres
510 metres
1790 metres
Number of
Screw
Terminations
120
46
74
78%
62%
The reduction of interface cards (by 50%), equipment cabinet space (caused by a reduction in the
number of I/O interfaces), and the elimination of termination panels resulted in a 46% reduction in
equipment costs.
Figure 47
24
© 1996 (Rev.1998) Fieldbus Foundation, Austin, Texas. All rights reserved.
High Speed Ethernet
Since all of the 31.25 kbit/s FOUNDATION fieldbus messages are communicated on the HSE using standard
Ethernet protocols (e.g. TCP/IP, SNTP, SNMP, etc.),
commercial off-the-shelf HSE equipment such as
Switches and Routers are used to create larger networks (Figure 49). Of course all or part of the HSE
network can be made redundant to achieve the level
fault tolerance needed by the application.
6. HIGH SPEED ETHERNET
A Linking Device is used to interconnect 31.25 kbit/s
fieldbuses and make them accessible to a High
Speed Ethernet (HSE) backbone running at 100 Mbit/s
or 1Gbit/s (Figure 48). The I/O Subsystem Interface
shown in the figure allows other networks such as
DeviceNet® and Profibus® to be mapped into standard
FOUNDATION fieldbus function blocks. The I/O
Subsystem Interface can be connected to the 31.25
kbit/s fieldbus or HSE.
Automation
and
Display Devices
Automation
and
Display Systems
Figure 48
Figure 49
25
© 1996 (Rev.1998) Fieldbus Foundation, Austin, Texas. All rights reserved.
References
FD-100
FD-110
FD-200
FD-210
7. REFERENCES
1. Fieldbus Standard for Use in Industrial Control
Systems, Part 2: Physical Layer Specifications and
Service Definition, ISA S50.02-1992.
DDL Tokenizer User’s Manual
DDS User’s Guide
Conformance Tester User’s Guide
Interoperability Tester User’s Guide
8. ACRONYM TABLE
2. International Standard for Use in Industrial Control
Systems, Part 2: Physical Layer Specifications and
Service Definition, IEC 61158-2 (1993).
ASN.1
CCITT
3. Digital data communications for measurement and
control -- Fieldbus for use in industrial control systems,
Part 3: Data Link Service Definition and Part 4: Data
Link Protocol Specification, 61158 DIS, IEC
SC65C/WG6 - ISA SP50, 1994-1998.
CD
DC
DCS
DD
DDL
DDS
DLL
EUC
FAS
FB
FF
FMS
HSE
Gbit/s
IEC
I.S.
ISA
4. FOUNDATION Fieldbus Specifications, Revision 1.3,
Fieldbus Foundation, 1994-1998.
5. Benefits Observed During Field Trials Of An
Interoperable Fieldbus, Kurt A. Zech, Fieldbus
Foundation, Paper #94-504 -- ISA, 1994
6. Abstract Syntax Notation One (ASN.1) The Tutorial
and Reference, Douglas Steedman, Technology
Appraisals Ltd., 1993, ISBN 1 871802 06 7
8. DOCUMENT LIST
ISO
kbit/s
kHz
LAN
LAS
mA
Mbit/s
NMIB
The following documents are available from the
Fieldbus Foundation.
AG-140 31.25 kbit/s Wiring and Installation Guide
AG-163 31.25 kbit/s Intrinsically Safe Systems
Application Guide
AG-165 Fieldbus Installation and Planning Guide
FF-800 System Architecture Specification
FF-801 Network Management Specification
FF-816 31.25 kbit/s Physical Layer Profile
Specification
FF-818 31.25 kbit/s Fiber Optic Physical Layer
Profile
FF-821 Data Link Layer Services Subset Specification
FF-822 Data Link Layer Protocol Specification
FF-880 System Management Specification
FF-870 Fieldbus Message Specification
FF-875 Fieldbus Access Sublayer Specification
FF-890 Function Blocks -- Part 1
FF-891 Function Blocks -- Part 2
FF-891 Function Blocks -- Part 3
FF-900 Device Description Language Specification
FF-940 31.25 kbit/s Communication Profile
OD
OSI
PC
PDU
PHY
PID
PN
PT
SM
SMIB
SNMP
SNTP
TCP/IP
TD
VFD
VCR
Abstract Syntax Notation 1
International Telegraph and Telephone
Consultative Committee
Compel Data
Direct Current
Distributed Control System
Device Description
Device Description Language
Device Description Services
Data Link Layer
End User Council
Fieldbus Access Sublayer
Function Block
Fieldbus Foundation
Fieldbus Message Specification
High Speed Ethernet
Gigabits per second
International Electrotechnical Commission
Intrinsically Safe
The International Society of Measurement
and Control
International Organization of Standards
kilobits per second
kilohertz
Local Area Network
Link Active Scheduler
Milliampere
Megabits per second
Network Management Information
Database
Object Dictionary
Open Systems Interconnect
Personal Computer
Protocol Data Unit
Physical Layer
Proportional, Integral, Derivative
Probe Node
Pass Token
System Management
System Management Information Base
Simple Network Managemant Protocol
Simple Network Time Protocol
Transport Control Protocol/Internet Protocol
Time Distribution
Virtual Field Device
Virtual Communication Relationship
26
© 1996 (Rev.1998) Fieldbus Foundation, Austin, Texas. All rights reserved.