FOUNDATION Fieldbus Technical Overview

7/31/2019 FOUNDATION Fieldbus Technical Overview

1/43

TechnicalOverviewFOUNDATION fieldbus

Freedom to Choose. Power to Integrate.

Compliments of:

FD-043 Rev 3.0


2/43


3/43 1996 (Rev.1998, 2003) Fieldbus Foundation, Austin, Texas. All rights reserved.

FOUNDATION Fieldbus Technical OverviewFD-043 Revision 3.0

This overview has been prepared to aid understanding of the technical aspects of F OUNDATIONfieldbus.

The booklet begins with a brief summary of fieldbus benefits followed by the goals, principlesand organization of the not-for-profit Fieldbus Foundation.

The main portion of the booklet is devoted to the definition and explanation of key technicalconcepts inherent in F OUNDATION fieldbus technology.

I sincerely hope this information proves useful to you. Please contact the Fieldbus Foundationif you need additional information about this exciting new technology.

David A. GlanzerDirector of Technology Development

For additional information please contact:

Fieldbus Foundation9005 Mountain Ridge Drive

Bowie Bldg., Suite 190 Austin, TX 78759-5316

USA

Voice: (512) 794-8890Fax: (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 FieldbusFoundation hereby disclaims all warranties of any kind, express or implied, including any warranty of merchantability or fitness fora particular purpose, for this document. In no event will the Fieldbus Foundation be responsible for any loss or damage arisingout of or resulting from any defect, error or omission in this document or from anyone s use of or reliance on this document.

Preface



1.0 WHAT IS F OUNDATION FIELDBUS? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

1.1 H1 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

1.1.1 More Data Available . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

1.1.2 Expanded View of the Process and Instruments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21.1.3 Reduction in System Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21.1.4 Wiring Savings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

1.2 HSE Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31.2.1 High Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

1.2.2 Subsystem Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

1.2.3 Function Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

1.2.4 Control Backbone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31.2.5 Standard Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

2.0 WHO IS THE FIELDBUS FOUNDATION? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

2.1 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

2.1.1 Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

2.1.2 Board of Directors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42.1.3 President . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

2.1.4 End User Advisory Council . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

2.1.5 End User Councils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

2.1.6 Quality Director . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52.1.7 Executive Committee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

2.1.8 Technical Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

2.1.9 Marketing Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52.1.10 Member Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

3.0 F OUNDATION FIELDBUS TECHNOLOGY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

3.1 User Application Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

3.1.1 Resource Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

3.1.2 Function Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63.1.3 Transducer Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

3.1.3.1 Supporting Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

3.1.4 Fieldbus Device Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

3.2 Function Block Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

3.2.1 Application Clock Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

3.2.2 Device Address Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103.2.3 Find Tag Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

3.3 Device Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113.3.1 Device Description Tokenizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

3.3.2 Device Description Services (DDS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

3.3.3 Device Description Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

3.3.4 Capability Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

Table of Contents



3.4 H1 Communication Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

3.4.1 The Data Link Layer (DLL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

3.4.1.1 Device Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

3.4.1.2 Scheduled Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .153.4.1.3 Unscheduled Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

3.4.1.4 Link Active Scheduler Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

3.4.1.4.1 CD Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163.4.1.4.2 Live List Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

3.4.1.4.3 Data Link Time Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

3.4.1.4.4 Token Passing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

3.4.1.4.5 LAS Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173.4.2 System Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

3.4.3 Fieldbus Access Sublayer (FAS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

3.4.3.1 Client/Server VCR Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173.4.3.2 Report Distribution VCR Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .183.4.3.3 Publisher/Server VCR Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18

3.4.3.4 Summary of VCR Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18

3.4.4 Fieldbus Message Specification (FMS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18

3.4.4.1 Virtual Field Device (VFD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .193.4.4.2 FMS Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

3.4.4.2.1 Context Management Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

3.4.4.2.2 Object Dictionary Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

3.4.4.2.3 Variable Access Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

3.4.4.2.4 Event Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .193.4.4.2.5 Upload/Download Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

3.4.4.2.6 Program Invocation Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

3.4.4.3 Message Formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203.4.4.4 Protocol Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

3.5 Physical Layer (31.25 kbit/s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .213.5.1 31.25 kbit/s Fieldbus Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22

3.5.2 31.25 kbit/s Fieldbus Wiring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

3.6 HSE Communication Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

3.6.1 HSE Device Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

3.6.1.1 HSE Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

3.6.1.2 Linking Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243.6.1.3 Gateway Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

3.6.1.4 Host Device (OPC DA Server) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

3.6.2 Ethernet Presence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

3.6.3 Field Device Access (FDA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .253.6.4 HSE System Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

3.6.5 HSE Network Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

Table of Contents


6/43

3.7 Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

3.7.1 Need for Host-Level Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

3.7.2. Media Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

3.7.3 Complete Network Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .263.7.4 Device Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

3.7.5 LAN Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28

4.0 SYSTEM CONFIGURATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29

4.1 System Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29

4.2 Device Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.0 FIELD TEST SYSTEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30

5.1 Test Instrumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30

5.2 Installation, Startup, and Operation Benefits Observed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31

6.0 FEATURES SUMMARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32

7.0 REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36

8.0 DOCUMENT LIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36

9.0 ACRONYM TABLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37

10.0 TERMINOLOGY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37

1996 (Rev.1998, 2003) Fieldbus Foundation, Austin, Texas. All rights reserved.

Table of Contents


7/43

P

L

*LinkingDevice Plant/Factory

Workstations

I/O PLC PLC

H1 HSE*

Data Service

MIS/ERP/HMI/

Data Services

Business Enterpriseand

Plant ApplicationPackages

H1 and NSE

Planningand

InstallationOperation Maintenance Evolution

Reduced number of wires and marshaling panels

Reduced number of power supplies and cabinetsReduced size of equipment rooms

More information available for operations

Increased uptime due to less equipment, better selfdiagnostics, and remote diagnostics

Increased accuracy of measurementsEasier evolution due to standardized function blocksIncreased sophistication and flexibility of instrumentation

Remote configuration of devices

Reduced number of intrinsic safety barriersReduced number of input/output converters

Figure 3

Figure 1

Figure 2 Figure 3

1.0 WHAT IS F OUNDATION TM FIELDBUS?

FOUNDATION TM fieldbus is an open, integrated totalarchitecture for information integration.

FOUNDATION fieldbus is an all-digital, serial, two-waycommunication system. H1 (31.25 kbit/s) intercon-nects field equipment such as sensors, actuatorsand I/O. HSE (100 Mbit/s) (High Speed Ethernet)provides integration of high speed controllers (suchas PLCs), H1 subsystems (via a linking device), dataservers and workstations. F OUNDATION fieldbus is theonly protocol with the built-in capability to distributethe control application across the network (Figure 1).

Management Information Systems (MIS), EnterpriseResource Planning (ERP), and Human MachineInterface (HMI) packages access the fieldbusinformation via the data services (Figure 2).

The H1 fieldbus retains and optimizes the desirablefeatures of the 4-20 milliampere (mA) analog systemsuch as:

single loop integrity a standardized physical interface to the wire

bus-powered devices on a single wire pair

intrinsic safety options

In addition, F OUNDATION fieldbus enables:

increased capabilities due to full digitalcommunications

reduced wiring and wire terminations due tomultiple devices on one wire

increased selection of suppliers due tointeroperability

reduced loading on control room equipmentdue to distribution of control and input/outputfunctions to field devices

connection to the HSE backbone for largersystems

1.1 H1 Benefits

Significant benefits are achieved in the controlsystem life-cycle through the application of H1fieldbus technology (Figure 3).


1

Introduction


8/43

Traditional 4-20 mA WiringOne I.S. Barrier, One Wire

forEach Device

Fieldbus Wiring

One I.S. Barrier, One Wirefor

Many Devices

Controller

Control SystemNetwork

H1

4-20 mA

Input/OutputSubsystem

I.S. I.S. I.S.

I.S.

LinkingDevice

HSE

Traditional 4-20 mAOne VariableOne Direction

FieldbusMultiple Variables

Both Directions

Controller


H1


LinkingDevice

HSE

TraditionalControl and I/O

requires extra equipmnet

Fieldbus

Control and I/O infield instruments.

Controller


H1

4-20 mA


PID

PID

AI

AI AO

AO

LinkingDevice

HSE

1.1.1 More Data AvailableThe fieldbus allows multiple variables from eachdevice to be brought into the control system forarchival, trend analysis, process optimizationstudies, report generation, predictive maintenanceand asset management. The high resolution anddistortion-free characteristics of digital communica-tions enables improved control capability which canincrease product yields (Figure 4).

1.1.2 Expanded View of the Process andInstrumentsThe self-test and communication capabilities ofmicroprocessor-based fieldbus devices helpreduce downtime and improve plant safety.

Upon detection of abnormal conditions or the needfor preventive maintenance, plant operations andmaintenance personnel can be notified. This allowscorrective action to be initiated quickly and safely(Figure 5).

1.1.3 Reduction in System HardwareFOUNDATION fieldbus uses standard FunctionBlocks to implement the control strategy. FunctionBlocks are standardized automation functions.Many control system functions such as analoginput (AI), analog output (AO) and Proportional/ Integral/Derivative (PID) control may be performedby the field device through the use of FunctionBlocks (Figure 6).

The consistent, block-oriented design of functionblocks allows distribution of functions in fielddevices from different manufacturers in anintegrated and seamless manner, thus reducingrisk of system failure.

Distribution of control into the field devices canreduce the amount of I/O and control equipmentneeded, including card files, cabinets, and powersupplies.

Traditional 4-20 mAView Stops at I/O Subsystem Fieldbus

View Extends into Instrument

Controller


H1

Remote Input/OutputSubsystem

LinkingDevice

HSE

Figure 5

Figure 6


Figure 4

Figure 7

2

Introduction


9/43

1.1.4 Wiring SavingsThe H1 fieldbus allows many devices to connect toa single wire pair. This results in less wire, fewerintrinsic safety barriers, and fewer marshalingcabinets (Figure 7).

1.2 HSE Benefits

In addition to the same life cycle benefits as H1,HSE provides the control backbone that integratesall of the systems in the plant.

1.2.1 High PerformanceFOUNDATION fieldbus enables asset managementfunctions such as diagnostics, calibration, identifica-tion and other maintenance management operations

to mine massive information from field devices inreal-time. Asset management allows users to moveto proactive maintenance which allocates resourcesto where they are really needed. Users employingfieldbus-based field devices and permanentlyconnected online asset management softwareneed HSE performance.

1.2.2 Subsystem Interoperability Plants are comprised of a number of subsystems.With HSE, subsystems for burner management,gas chromatographs, paper web scanners, shut-down systems, compressor controls tank farms,etc., integrate easily because of the open protocol.Users can mix and match subsystems for basiccontrol, emergency shutdown, paper quality control,advanced control and compressor control, etc.,from different suppliers. Utilizing HSE, informationcan be accessed without custom programming.Users can select decimal subsystems to keep costlow, while at the same time reducing the configura-tion effort.

Data integrity, diagnostics and redundancy manage-ment are part of HSE and work seamlessly between

devices from different manufacturers.1.2.3 Function Blocks

The same F OUNDATION TM function blocks that areused in H1 devices are used in HSE devices.FOUNDATION TM fieldbus eliminates the need forproprietary programming languages. The samecontrol strategy programming language can beused throughout the entire system.

The status associated with function block parametersis generated by field instruments based on failedsensors, stuck valves, etc., and is used for loop shut-downs, windup protection and bumpless transfer.

1.2.4 Control BackboneHSE provides peer-to-peer communication capabili-ty. Devices communicate with each other directlywithout having to go through a central computer.This makes it possible to realize powerful, advancedcontrol strategies involving variables throughout theplant without the risk of a central computer failure,further reducing risk. HSE can also bridge informa-tion between devices on different H1 networks atdifferent ends of the plant. Thus, control can spanbetween process cells and a plant area.

HSE replaces enterprise, control and remote-I/Onetworking levels, thus flattening the enterprisepyramid.

The Linking Device (LD) brings data from one ormore H1 fieldbus networks directly onto theHSE backbone.

1.2.5 Standard EthernetStandard cable is used for HSE devices; nospecial tools or skills are required. Installationis simple and fast. HSE uses standard Ethernet

network equipment such as switches.

Standard Commercial Off-The-Shelf (COTS)Ethernet components are made in extremelyhigh volume. Cable, interface cards and othernetworking hardware are extremely low cost com-pared to proprietary networks. Ethernet optionsfor media include twisted pair, fiber optics andwireless. Networking hardware is available inboth commercial and industrial grades frommany suppliers.


3

Introduction


10/43

2.0 WHO IS THE FIELDBUS FOUNDATION?

Driven by their customers needs, process controland manufacturing automation companies formed

the Fieldbus Foundation to complete developmentof a single, open, international, and interoperablefieldbus.

The Fieldbus Foundation is an independent, not-for-profit organization based on the following principles:

Fieldbus technology is an enabling technology;not a differentiating technology.

Fieldbus technology is open and available to allparties.

Fieldbus technology is based on the work of theInternational Electrotechnical Commission (IEC)and ISA (the international society formeasurement and control).

Fieldbus Foundation members support and workwith the international and national standardscommittees.

2.1 OrganizationThe Fieldbus Foundation is organized as in Figure 8.

2.1.1 MembersThe Fieldbus Foundation has over 185 membercompanies. These companies supply approximately90% of the world s instrumentation and controlproducts.

2.1.2 Board of DirectorsThe foundation is managed under the direction ofthe Board of Directors (BOD). The BOD is electedby the voting members.

2.1.3 PresidentThe President reports to the Board of Directors,manages the day-to-day activities of the FieldbusFoundation, and provides direction for the Executive,Technical, Marketing, and Member Support functions.

2.1.4 End User Advisory CouncilThe End User Advisory Council (EUAC) reportsdirectly to the Foundation President and providesinput from End Users on a worldwide basis, focus-ing on technical, marketing and other appropriate

issues. It provides a formal mechanism for directend user issues into the Technical SteeringCommittee and Board of Directory.

2.1.5 End User CouncilsThe End User Councils (EUC) are comprised ofusers of fieldbus equipment. There are EUCs inNorth America, Europe, Latin America and

Asia-Pacific. The purpose of the EUC is to review


4

Organization

Figure 8


11/43

the activities of the foundation and provide input tohelp ensure the specifications meet the needs of themarketplace now and in the future, and to promotethe further adoption of the technology.

2.1.6 Quality DirectorThe Quality Director provides overall management ofthe foundation s quality assurance systems.

2.1.7 Executive CommitteeThe Executive Committee advises the Presidentconcerning the strategic and overall operationalissues of the foundation.

2.1.8 Technical TeamsThe Technical Teams are responsible for the techni-

cal work of the foundation. The technical work isgrouped into programs such as Specifications,Software, and Interoperability Testing. A ProgramManager is responsible for each technical program.

2.1.9 Marketing TeamsThe Marketing Teams are responsible for promotingFOUNDATION fieldbus and for planning and directingthe foundation s products and services.

2.1.10 Member SupportMember Support is responsible for coordination anddelivery 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 fieldtests, product catalogs, Device Description software,and device registrations.

3.0 F OUNDATION TM FIELDBUS TECHNOLOGY

FF-581 System Architecture*

*Note: References to specific documents are notedas follows: Document number and name.

FOUNDATION fieldbus H1 technology consists of:1) the Physical Layer, 2) the CommunicationStack, and 3) the User Application Layer.The Open Systems Interconnect (OSI) layered

communication model is used to model thesecomponents (Figure 9).

The Physical Layer is OSI layer 1. The Data LinkLayer (DLL) is OSI layer 2. The Fieldbus MessageSpecification (FMS) is OSI layer 7. The Communi-cation Stack is comprised of layers 2 and 7 in theOSI model.

The fieldbus does not use OSI layers 3, 4, 5 and 6.The Fieldbus Access Sublayer (FAS) maps the FMSonto the DLL.

g

g


5

Technology

OSI Model*Fieldbus Model

TRANSPORT LAYER

SESSION LAYER

PRESENTATION LAYER

APPLICATION LAYER

PHYSICAL LAYER

DATA LINK LAYER

NETWORK LAYER

PHYSICAL LAYER

DATA LINK LAYER

FIELDBUS ACCESSSUBLAYER

FIELDBUS MESSAGESPECIFICATION

1

2

3

4

5

6

7

USERAPPLICATION

PHYSICAL LAYER

COMMUNICATIONSTACK

USERAPPLICATION

* The user application is not defined by the OSI Model

Figure 9Figure 9

Preamble StartDelimiter

EndDelimiter

11*** 18-273

DLL PDU**

4 to 2551

FASPCI*

FMS PDU**

FMSPCI*

USER Encoded Data

0 to 2514

Frame CheckSequence

5 - 15 5 to 256

FAS PDU**DLLPCI*

2

USER Data

PHYSICAL LAYER

DATA LINK LAYER



Fieldbus* Protocol Control Information

** Protocol Data Unit*** There may be more than 1 octet of preamble if

repeaters are used.

USERAPPLICATION

Figure 10Figure 10


12/43

The User Application is not defined by the OSI model.The Fieldbus Foundation has specified a User Applicationmodel, significantly differentiating it from other models.

Each layer in the communication system is responsiblefor a portion of the message that is transmitted on thefieldbus.

Figures 10 references the approximate number of eightbit octets used for each layer to transfer the user data.

3.1 User Application Blocksg FF-890 Function Block Application Process -

Part 1g FF-891 Function Block Application Process -




Part 5g FF-902 Transducer Block Application Process -

Part 1g FF-903 Transducer Block Application Process -

Part 2g TN-003 Profile & Profile Revision

The Fieldbus Foundation has defined a standard

User Application Layer based on Blocks. Blocksare representations of different types of applicationfunctions (Figure 11). The types of blocks used in aUser Application are described in Figure 12.

Devices are configured using Resource Blocks andTransducer Blocks. The control strategy is builtusing Function Blocks.

3.1.1 Resource BlockThe Resource Block describes characteristics of thefieldbus device such as the device name, manufac-turer, and serial number. There is only one ResourceBlock in a device.

3.1.2 Function BlockFunction Blocks (FB) provide the control systembehavior. The input and output parameters ofFunction Blocks can be linked over the fieldbus.The execution of each Function Block is preciselyscheduled. There can be many function blocks ina single User Application.

The Fieldbus Foundation has defined sets ofstandard Function Blocks. Ten standard FunctionBlocks for basic control are defined by theg FF-891 Function Block Application Process Part 2 specification. These blocks are listed below.

Function Block Name Symbol Analog Input AI Analog Output AOBias/Gain BGControl Selector CS

Discrete Input DIDiscrete Output DOManual Loader MLProportional/Derivative PDProportional/Integral/Derivative PIDRatio RA


6

Technology

Figure 31

PHYSICAL LAYER

DATA LINK LAYER



USERAPPLICATION

PHYSICAL LAYER

COMMUNICATIONSTACK

USERAPPLICATION

ResourceBlock

TransducerBlock

FunctionBlock

Fieldbus

PHYSICAL LAYER

COMMUNICATIONSTACK

Blocks

Figure 32Figure 12Figure 11



Technology

The following eleven standard function blocks aredefined by the g FF-892 Function Block

Application Process Part 3.

Function Block Name SymbolDevice Control DCOutput Splitter OSSignal Characterizer SCLead Lag LLDeadtime DTIntegrator (Totalizer) ITSetpoint Ramp Generator SPGInput Selector IS

Arithmetic ARTimer TMR

Analog Alarm AAL

The following four standard function blocks aredefined by the g FF-893 Function Block

Application Process Part 4.

Function Block Name SymbolMultiple Analog Input MAIMultiple Analog Output MAOMultiple Discrete Input MDIMultiple Discrete Output MDO

The Flexible Function Block is defined by theg FF-894 Function Block Application Process Part 5. A flexible Function Block (FFB) is a userdefined block. The FFB allows a manufacturer oruser to define block parameters and algorithms tosuit an application that interoperates with standardfunction blocks and host systems (Figure 13).

Function blocks can be built into fieldbus devices asneeded to achieve the desired device functionality.

For example, a simple temperature transmitter maycontain an AI function block. A control valve mightcontain a PID function block as well as the expected

AO block. Thus, a complete control loop can be built

using only a simple transmitter and a control valve(Figure 14).

3.1.3 Transducer Blocksg FF-902 Transducer Block Application Process

Part 1g FF-903 Transducer Block Application Process

Part 2

Like the Resource Block, the Transducer Blocks areused to configure devices.

Transducer Blocks decouple Function Blocks fromthe local input/output functions required to readsensors and command output hardware. Theycontain information such as calibration date andsensor type.

3.1.3.1 Supporting ObjectsThe following additional objects are defined in theUser Application:

Link Objects define the links between FunctionBlock inputs and outputs internal to the device andacross the fieldbus network.

Trend Objects allow local trending of function blockparameters for access by hosts or other devices.

Alert Objects allow reporting of alarms and eventson the fieldbus.

Multi-Variable Container (MVC) Object serves toencapsulate multiple Function Block parametersin order to optimize communications for Publishing-Subscriber and Report Distribution transactions. Ithas a user-configured list to define the requiredparameters, whose data values are referenced in a

variable list.

View Objects are predefined groupings of blockparameter sets that can be displayed by thehuman/machine interface. The function blockspecification defines four views for each type ofblock. Figure 15 shows an example of how commonFunction Block variables map into the views. Onlya partial listing of the block parameters is shown inthe example.

MAI

OUT

1-8

AI OUT

DI OUT_D

MAO

I N

1-8

AOCAS_IN

DOIN_D

IN_0

I N

1-8

IN_DIEC

61131Application

Flexible FunctionBlock

OUT

1-8

OUT_D

OUT

Figure 13

7


14/43

Technology

ResourceBlock

FunctionBlock 2

TransducerBlock 2

TrendObject ViewLists

Function Block Application

FunctionBlock 1

TransducerBlock 1

ViewLists

Links

Alerts

Sensor1

Sensor2

MVC

Figure 16

Data Trend Alarms

DiagnosticsDetail Display

AI PID, AO

Fieldbus

Display Sets

SP X XPV X XSP HI LIMIT XCAS IN XGAIN X

View_1OperationDynamic

View_2Operation

StaticView_3

All DynamicView_4

Other StaticXYZ Block

AI

Static

Dynamic

Figure 34

Figure 15

PhysicalLayer

UserApplication

Virtual

Field Device

Object Descriptions

Index0

201202

210

250

Directory

Resource Block

Transducer Block

Link Objects

Trend Objects

OD Header

500 Function Block

Function Block600

1000

2000

View Object

View Object

400

Fieldbus

Function BlockApplication

ResourceBlock

FunctionBlock 2TransducerBlock 2

TrendObject ViewLists

FunctionBlock 1

TransducerBlock 1

ViewLists

Links

Alerts

Stack

Figure 37Figure 18

OD HEADER0

FUNCTION BLOCKS

TRANSDUCER BLOCKS

DIRECTORY

LINK OBJECTS

TREND OBJECTS

RESOURCE BLOCK

ALERT OBJECTS

VIEW OBJECTS

Figure 36Figure 17


8

VIEW_1 - Operation Dynamic- Information required by a plantoperator to run the process.

VIEW_2 - Operation Static -Information which may need tobe read once and then dis-played along with the dynamicdata.

VIEW_3 - All Dynamic -Information which is changingand may need to be referencedin a detailed display.

VIEW_4 - Other Static -Configuration and maintenanceinformation.

AO 110AI 110

PID 110

H1 Fieldbus

Example of a complete control loop usingFunction Blocks located in fieldbus devices.

Device 1 Device 2

LinkingDevice

HSE Fieldbus

Host

Figure 14


15/43

3.1.4 Fieldbus Device DefinitionThe fieldbus device definition is intended for remoteI/O devices having many function blocks from whichdata shall be communicated

The function of a fieldbus device is determined bythe arrangement and interconnection of blocks(Figure 16).

The device functions are made visible to the fieldbuscommunication system through the User Application

Virtual Field Device (VFD) discussed in Section 3.4.3.1.

The header of the User Application object dictionarypoints to a Directory which is always the first entry inthe function block application. The Directory providesthe starting indexes of all of the other entries used inthe Function Block application (Figure 17). The VFDobject descriptions and their associated data areaccessed remotely over the fieldbus network using

Virtual Communication Relationships (VCRs).

g TN-003 Profile and Profile Revision

Each block has a Profile (i.e. a code) that indicatesthe type of block (e.g. the standard PID block iscode 0108 in hexadecimal). Based on this codea host can tell if a block is a standard block, anenhanced block or a manufacturer custom block.The engineering tool can now build a controlstrategy completely independent of the device youwill eventually use. The process engineer can buildthe control strategy and then let the instrumentengineers assign the blocks to devices later.

For example, in the basic PID control template thestandard 0108 FF PID block is used. When theblock is later assigned to a device the engineeringtool confirms with the Capability File of the devicethat 0108 standard PID is supported. This meansyou can drag and drop the same block into a

transmitter, positioner or central controller withouthaving to change to another block because alldevices support the standard blocks. It also meansthat if you put in another device in the future that

supports 0108, you can do so without having tochange the block.

The graphical F OUNDATION function block diagramprogramming language is used to configurecontrol strategies.

3.2 Function Block Scheduling

A schedule building tool is used to generate func-tion block and Link Active Scheduler (LAS) sched-ules. As an example, assume that the schedule

building tool has built the following schedules forthe loop previously described in Figure 14.

The schedules contain the start time offset from thebeginning of the absolute link schedule start time. The absolute link schedule start time is known byall devices on the fieldbus (Figure 19).

A macrocycle is a single iteration of a schedulewithin a device. The following figure shows therelationships between the absolute link schedulestart time, LAS macrocycle, device macrocycles,and the start time offsets.


9

Technology

Offset from Absolute LinkSchedule Start Time

Scheduled Al Function Block Extension 0Scheduled Communications of Al 20Scheduled PID Function Block Execution 30Scheduled AO Function Block Execution 50

Figure 19

UnscheduledCommunication

Permitted

LASMacrocycle

Macrocycle Macrocycle

Device 1Macrocycle

Device 2Macrocycle

DL Offset = 30 forPID execution.

DL Offset = 0 forAI execution.

DL Offset = 20 forAI Communication.

Absolute Link Schedule Start Time.

The start of individual macrocycles is defined as an offsetfrom the absolute link schedule start time.

DL Offset = 50 forAO execution.

PID AO

AI AI

SequenceRepeats

0 20 40 60 80 100 120 20 40 60 80 100 120

PID AO

Figure 20


16/43


17/43

3.3 Device Descriptions

A device is supplied with three device support files:two Device Description Files and one Capability

File. A critical characteristic required of fieldbusdevices is interoperability. To achieve interoperabili-ty, Device Description (DD) technology is used inaddition to standard function block parameter andbehavior definitions. DDs are platform and operatingsystem independent.

The DD provides an extended description of eachobject in the Virtual Field Device (VFD) as shown inFigure 21.

The DD provides information needed for a controlsystem or host to understand the meaning of thedata in the VFD including the human interface forfunctions such as calibration and diagnostics.Thus, the DD can be thought of as a driver forthe device.

The DDs are similar to the drivers that your personalcomputer (PC) uses to operate different printers andother devices that are connected to the PC. Anycontrol system or host can operate with the device

if it has the device's DD.

3.3.1 Device Description Tokenizerg FD-900 Device Description Language

Specificationg FD-100 DDL Tokenizer User s Manual

The DD is written in a standardized programminglanguage known as Device Description Language(DDL). A PC-based tool called the Tokenizer converts DD source input files into DD output filesby replacing key words and standard strings in thesource file with fixed tokens . The Fieldbus

Foundation (FF) provides DDs for all standardResource, Function and Transducer Blocks. Devicesuppliers build a DD by importing the StandardDDs. Suppliers may also add supplier specificfeatures such as calibration and diagnosticprocedures to their devices.


11

Technology

Virtual Field Device

ObjectDescription

of Data

Pointer toDevice Description

of Data

Label of the parameterEngineering units

How many decimal points to displayHelp text

Parameter relationshipsCalibration and diagnostic menus

Data DD

Extended DescriptionsAssociated with the Data

Figure 41Figure 21



Device Descriptions for registered field devices canbe found on the Fieldbus Foundation s website athttp://www.fieldbus.org.

3.3.2 Device Description Services (DDS)g FD-110 DDS User s Guide

On the host side, library functions called DeviceDescription Services (DDS) are used to read thedevice descriptions (Figure 22).

Note that DDS reads descriptions, not operationalvalues. The operational values are read from thefieldbus device over the fieldbus using FMScommunication services.

New devices are added to the fieldbus by simplyconnecting the device to the fieldbus wire andproviding the control system or host with theDD for the new device (Figure 23).

DDS technology allows operation of devices fromdifferent suppliers on the same fieldbus with onlyone version of the host human interface program.

3.3.3 Device Description Hierarchy The Fieldbus Foundation has defined a hierarchyof Device Descriptions (DD) to make it easier tobuild devices and perform system configuration.The hierarchy is shown in Figure 24.

The first level in the hierarchy is referred to asUniversal Parameters. Universal Parameters consistof common attributes such as Tag, Revision, Mode,etc. All blocks must include the UniversalParameters.

The next level in the hierarchy is Function BlockParameters. At this level, parameters are defined forthe standard Function Blocks. Parameters for thestandard Resource Block are also defined at thislevel.

The third level is called Transducer BlockParameters. At this level, parameters are defined forthe standard Transducer Blocks. In some cases, thetransducer block specification may add parametersto the standard Resource Block.

12

Technology

HostApplication

Device DescriptionServices Library

Standard DDsplus optional

Incremental DDs

Data are read fromthe device over thefieldbus.

Number of digitsof precision.

Engineering Unit

Label

25.50

Measured_Value

%

Descriptions areread from the DD.

Figure 22


19/43

The Fieldbus Foundation has written the DeviceDescriptions for the first three layers of thehierarchy. These are the standard FieldbusFoundation DDs.

The fourth level of the hierarchy is calledManufacturer Specific Parameters. At this level,each manufacturer is free to add additionalparameters to the Function Block Parameters andTransducer Block Parameters.

3.3.4 Capability Filesg FF-103 Common File Format

The Capability File tells the host what resources thedevice has in terms of function blocks and VCRsetc. This allows the host to configure for the deviceeven if not connected to it. The host can ensure thatonly functions supported by the device are allocatedto it, and that other resources are not exceeded.


13

Technology

DeviceDescriptions

Fieldbus

Device fromSupplier A

Device fromSupplier Z

DDServicesInside

Figure 45

Definedby

Fieldbus FoundationSpecification

Definedby

Manufacturer

Figure 46

UniversalParameters

FunctionBlock

Parameters

ManufacturerSpecific

Parameters

FunctionBlocks

TransducerBlocks

ResourceBlock

AI PIDAI PIDRESOURCE

TransducerBlock

ParametersTEMP FLOW

Figure 23 Figure 24


20/43

3.4 H1 Communication Stack The following sections will describe the operation ofthe layers in the Communication Stack (Figure 25).

3.4.1 The Data Link Layer (DLL)g FF-806 Data Link Protocol Specification

Bridge Operation Addendumg FF-821 Data Link Layer Services

Subset Specificationg FF-822 Data Link Layer Protocol

Subset Specification

IEC/TS 61158-3:1999 Digital data communicationsfor measurement and control Field bus for use inindustrial control systems Part 3: Data link ser-vice definition

IEC/TS 61158-4:1999 Digital data communicationsfor measurement and control Field bus for use inindustrial control systems Part 4: Data link proto-col specification

Layer 2, the Data Link Layer (DLL), controlstransmission of messages onto the fieldbus. TheDLL manages access to the fieldbus through adeterministic centralized bus scheduler calledthe Link Active Scheduler (LAS).

The DLL is a subset of the approved IEC standard.

14

Technology


PHYSICAL LAYER

DATA LINK LAYER



USERAPPLICATION

PHYSICAL LAYER

COMMUNICATIONSTACK

USERAPPLICATION

Figure 25


21/43

3.4.1.1 Device TypesTwo types of devices are defined in the DLLspecification:

Basic Device Link Master

Link Master devices are capable of becoming theLink Active Scheduler (LAS). Basic Devices do nothave the capability to become the LAS (Figure 26).

3.4.1.2 Scheduled CommunicationThe Link Active Scheduler (LAS) has a list oftransmit times for all data buffers in all devices thatneed to be cyclically transmitted.

When it is time for a device to send a buffer, theLAS issues a Compel Data (CD) message to thedevice.

Upon receipt of the CD, the device broadcasts orpublishes the data in the buffer to all devices onthe fieldbus. Any device configured to receive thedata is called a subscriber (Figure 27).

Scheduled data transfers are typically used for theregular, cyclic transfer of control loop data betweendevices on the fieldbus.

Technology


15

Technology

Figure 26

Figure 27


22/43

Technology

3.4.1.3 Unscheduled Communication All of the devices on the fieldbus are given achance to send unscheduled messages betweentransmissions of scheduled messages.

The LAS grants permission to a device to use thefieldbus by issuing a pass token (PT) message tothe device. When the device receives the PT, it isallowed to send messages until it has finished oruntil the delegated token hold time has expired,whichever is the shorter time (Figure 28).

3.4.1.4 Link Active Scheduler OperationThe following sections describe the overalloperation of the Link Active Scheduler (LAS). Thealgorithm used by the LAS is shown in Figure 29.

3.4.1.4.1 CD ScheduleThe CD Schedule contains a list of activitiesthat are scheduled to occur on a cyclic basis. Atprecisely the scheduled time, the LAS sends aCompel Data (CD) message to a specific databuffer in a fieldbus device. The device immediatelybroadcasts or publishes a message to all deviceson the fieldbus. This is the highest priority activityperformed by the LAS. The remaining operationsare performed between scheduled transfers.

3.4.1.4.2 Live List MaintenanceThe list of all devices that are properly respondingto the Pass Token (PT) is called the Live List.

New devices may be added to the fieldbus at anytime. The LAS periodically sends Probe Node (PN)messages to the addresses not in the Live List. If adevice is present at the address and receives the PN,it immediately returns a Probe Response (PR) mes-sage. If the device answers with a PR, the LAS addsthe device to the Live List and confirms its additionby sending the device a Node Activation message.

The LAS is required to probe at least one addressafter it has completed a cycle of sending PTs to alldevices in the Live List.

The device will remain in the Live List as long as itresponds properly to the PTs sent from the LAS.The LAS will remove a device from the Live List ifthe device does not either use the token or immedi-ately return it to the LAS after three successive tries.

Whenever a device is added or removed from theLive List, the LAS broadcasts changes to the LiveList to all devices. This allows each Link Masterdevice to maintain a current copy of the Live List.


16

Technology

Link Active Scheduler Algorithm

Isthere time to do

somethingbefore next

CD?

No

IssuePN, TD, or PT

Waituntil it is time to

issue the CD

Sendidle messageswhile waiting.

IssueCD

YesCD = Compel DataPN = Probe NodeTD = Time Distribution

PT = Pass Token

Figure 24Figure 29

LAS

Message

LAS = Link Active SchedulerPT = Pass Token

Data

Fieldbusxyz

PT (x)

Data

Device x

Live List

Unscheduled Data Transfers

The message in the queue is transmitted on the fieldbus whenthe LAS issues the pass token message to device x. Themessage can be sent to a single destination or to multipledestinations (multicast).

Figure 23

Figure 28


23/43

3.4.1.4.3 Data Link Time SynchronizationThe LAS periodically broadcasts a Time Distribution(TD) message on the fieldbus so that all deviceshave exactly the same data link time. This is impor-tant because scheduled communications on thefieldbus and scheduled function block executionsin the User Application are based on informationobtained from these messages.

3.4.1.4.4 Token PassingThe LAS sends a Pass Token (PT) message to alldevices in the Live List. The device is allowed totransmit unscheduled messages when it receivesthe PT.

3.4.1.4.5 LAS Redundancy

A fieldbus may have multiple Link Masters. If thecurrent LAS fails, one of the Link Masters willbecome the LAS and the operation of thefieldbus will continue. The fieldbus is designedto fail operational.

3.4.2 System Managementg FF-800 System Management Specification

Function Blocks must execute at precisely definedintervals and in the proper sequence for correctcontrol system operation.

System management synchronizes execution of theFunction Blocks to a common time clock shared byall devices.

System management also handles other importantsystem features such as publication of the time ofday to all devices, including automatic switchoverto a redundant time publisher and searching forparameter names or tags on the fieldbus.Fieldbus devices do not use jumpers or switchesto configure addresses. Instead, device addressesare set by configuration tools using SystemManagement services.

All of the configuration information needed by SystemManagement such as the Function Block schedule isdescribed by object descriptions in the Network andSystem Management Virtual Field Device (VFD). This

VFD provides access to the System ManagementInformation Base (SMIB), and also to the NetworkManagement Information Base (NMIB).

3.4.3 Fieldbus Access Sublayer (FAS)

FF-875 Fieldbus Access SublayerSpecification

The FAS uses the scheduled and unscheduledfeatures of the Data Link Layer to provide a servicefor the Fieldbus Message Specification (FMS). Thetypes of FAS services are described by VirtualCommunication Relationships (VCR).

The VCR is like the speed dial feature on yourmemory telephone. There are many digits to dialfor an international call such as international accesscode, country code, city code, exchange code and,finally, the specific telephone number.

This information only needs to be entered once andthen a speed dial number is assigned.

After setup, only the speed dial number needs to beentered for the dialing to occur. Likewise, afterconfiguration, only the VCR number is needed tocommunicate with another fieldbus device.

Just as there are different types of telephone callssuch as person to person, collect, or conferencecalls, there are different types of VCRs.

3.4.3.1 Client/Server VCR TypeThe Client/Server VCR Type is used for queued,unscheduled, user initiated, one to one, commu-nication between devices on the fieldbus.

Queued means that messages are sent andreceived in the order submitted for transmission,according to their priority, without overwritingprevious messages.

When a device receives a Pass Token (PT) from theLAS, it may send a request message to anotherdevice on the fieldbus. The requester is called theClient and the device that received the request iscalled the Server. The Server sends the responsewhen it receives a PT from the LAS.

The Client/Server VCR Type is used for operatorinitiated requests such as setpoint changes, tuningparameter access and change, alarm acknowledge,and device upload and download.

g


17

Technology


24/43

3.4.3.2 Report Distribution VCR TypeThe Report Distribution VCR Type is used forqueued, unscheduled, user initiated, and one-to-many communications.

When a device with an event or a trend reportreceives a PT from the LAS, it sends its messageto a group address defined for its VCR. Devicesthat are configured to listen for that VCR willreceive the report.

The Report Distribution VCR Type is typically usedby fieldbus devices to send alarm notifications tothe operator consoles.

3.4.3.3 Publisher/Subscriber VCR TypeThe Publisher/Subscriber VCR Type is used forbuffered, one-to-many communications.

Buffered means that only the latest version of thedata is maintained within the network. New datacompletely overwrites previous data.

When a device receives the Compel Data (CD), thedevice will Publish or broadcast its message to alldevices on the fieldbus. Devices that wish to receivethe Published message are called Subscribers.

The CD may be scheduled in the LAS, or it may be

sent by Subscribers on an unscheduled basis. Anattribute of the VCR indicates which method is used.

The Publisher/Subscriber VCR Type is used by thefield devices for cyclic, scheduled, publishing ofUser Application function block input and outputssuch as Process Variable (PV) and Primary Output

(OUT) on the fieldbus.

3.4.3.4 Summary of VCR Types(Figure 30)

3.4.4 Fieldbus Message Specification (FMS)g FF-870 Fieldbus Message Specification

Fieldbus Message Specification (FMS) servicesallow user applications to send messages to eachother across the fieldbus using a standard set ofmessage formats. FMS describes the communica-tion services, message formats, and protocolbehavior needed to build messages for the User

Application (Figure 31).

Data that is communicated over the fieldbus isdescribed by an object description. Objectdescriptions are collected together in a structurecalled an Object Dictionary (OD), (Figure 32).


18

Technology

FIELDBUS

CommunicationServices

UserApplication

FieldbusDevice

UserApplication

FieldbusDevice

FMS FMS

FAS FASDLLPHY

DLLPHY

Object Dictionary

Object Description 1Object Description 2

Object Description n

Index 1Index 0

Index 2

Index n

Figure 32

Figure 31

Used forOperator Messages

DATA LINK LAYER SERVICES

Used forPublishing Data

FIELDBUS ACCESS SUBLAYER SERVICES

Used forEvent Notification

andTrend ReportsSetpoint changes

Mode changesTuning changesUpload/DownloadAlarm ManagementAccess display viewsRemote diagnostics

Send process alarmsto operator consoles.

Send trend reportsto data historians.

Send transmitter PVto PID control block

and operator console.

Client/ServerVCR Type

Report DistributionVCR Type

Publisher/SubscriberVCR Type

Figure 30


25/43

The object description is identified by its index inthe OD. Index 0, called the object dictionary header,provides a description of the dictionary itself, anddefines the first index for the object descriptions of

the User Application. The User Application objectdescriptions can start at any index above 255.

Index 255 and below define standard data typessuch as boolean, integer, float, bitstring, and datastructures that are used to build all other objectdescriptions.

3.4.4.1 Virtual Field Device (VFD) A Virtual Field Device (VFD) is used to remotelyview local device data described in the objectdictionary. A typical device will have at least two

VFDs (Figure 33).

Network Management (see g FF-801 NetworkManagement Specification ) is part of the Network andSystem Management Application. It provides for theconfiguration of the communication stack. The VirtualField Device (VFD) used for Network Managementis also used for System Management. This VFD pro-vides access to the Network Management InformationBase (NMIB) and to the System ManagementInformation Base (SMIB). NMIB data includes VirtualCommunication Relationships (VCR), dynamic vari-ables, statistics, and Link Active Scheduler (LAS)

schedules (if the device is a Link Master). SMIB dataincludes device tag and address information, andschedules for function block execution.

System Management is described further in the User Application section.

3.4.4.2 Communication ServicesFMS communication services provide a standardizedway for user applications such as function blocks tocommunicate over the fieldbus. Specific FMS com-munication services are defined for each object type.

All of the FMS services can only use the Client/Server VCR Type except as noted.

3.4.4.2 FMS ServicesDetailed descriptions for each service are providedin the g FF-870 Fieldbus Message Specification.

3.4.4.2.1 Context Management ServicesThe following FMS services are used to establishand release Virtual Communications Relationships(VCR) with, and determine the status of a VFD.

Initiate Establish communications Abort Release communicationsReject Reject improper serviceStatus Read a device statusUnsolicitedStatus Send unsolicited statusIdentify Read vendor, type and version

3.4.4.2.2 Object Dictionary ServicesThe following FMS services allow the User

Application to access and change the ObjectDescriptions (OD) in a VFD.

GetOD Read an object dictionary(OD)InitiatePutOD Start an OD LoadPutOD Load an OD into a deviceTerminatePutOD Stop an OD Load

3.4.4.2.3 Variable Access ServicesThe following FMS services allow the user applicationto access and change variables associated with anobject description.

Read Read a variableWrite Write a variableInformationReport Send Data*DefineVariableList Define a Variable ListDeleteVariableList Delete a Variable List

*Can use Publisher/Subscriber or Report Distribution VCR Types.

3.4.4.2.4 Event Services

The following FMS services allow the user applica-tion to report events and manage event processing.

EventNotification Report anevent*

AcknowledgeEventNotification Acknowledgean event

AlterEventConditionMonitoring Disable / Enable event

* Can use Report Distribution VCR Type


19

Technology

Figure 28

Fieldbus Device

FIELDBUS

FMS

FAS

DLL

PHY

NetworkManagementApplication

NetworkManagement

VFD

FunctionBlock

Application

UserApplication

VFD

SystemManagementApplication

SystemManagement

VFD

ObjectDescriptions

ObjectData

ObjectDescriptions

Object

Data

ObjectDescriptions

ObjectData

Figure 33


26/43

3.4.4.2.5 Upload/Download ServicesIt is often necessary to remotely upload or down-load data and programs over the fieldbus, especiallyfor more complex devices such as programmablelogic controllers.

To allow uploads and downloads using the FMSservices, a Domain is used. A Domain representsa memory space in a device.

The following FMS services allow the User Application to upload and download a Domain in aremote device.

RequestDomainUpload Request UploadInitiateUploadSequence Open Upload

UploadSegment Read Data from DeviceTerminateUploadSequence Stop UploadRequestDomainDownload Request DownloadInitiateDownloadSequence Open DownloadDownloadSegment Send Data to DeviceTerminateDownloadSequence Stop DownloadGenericInitiateDownloadSequence Open DownloadGenericDownloadSegment Send Data to DeviceGenericTerminateDownload Sequence Stop Download

3.4.4.2.6 Program Invocation ServicesThe Program Invocation (PI) allows the executionof 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 thedownload service and then remotely operate theprogram by issuing PI service requests. The state

diagram for the PI is shown as an example of FMSprotocol behavior later in this document.

CreateProgramInvocation Create a programobject

DeleteProgramInvocation Delete a programobject

Start Start a programStop Stop a programResume Resume program

executionReset Reset the programKill Remove the

program

3.4.4.3 Message Formattingg ASN.1 Tutorial and Reference Steedman

The exact formatting of FMS messages is definedby a formal syntax description language called

Abstract Syntax Notation 1 (ASN.1).

ASN.1 was developed by the International Telegraphand Telephone Consultative Committee (CCITT)in the early 1980s as a part of the CCITT mail

standardization activities.

See Figure 34 for a partial example of ASN.1definition for the FMS Read service.

20


Technology

ASN.1 Definition of a Read_Request

Read_Request::= SEQUENCE {Access-specif ication CHOICE {

index [0] IMPLICIT Index,variable-name [1] IMPLICIT Name,variable-list-name [2] IMPLICIT Name,},

sub-index [3] IMPLICIT Subindex OPTIONAL}

Figure 29

UserApplication

FMSFASDLLPHY

Figure 34


27/43

The previous example states that the items Access-specification and sub-index occur in SEQUENCE in themessage.

The Access-specification is a CHOICE of usingeither an index or a name to access a variable.

The sub-index is OPTIONAL. It is used only toselect an individual element of an array or recordvariable.

The numbers in the brackets are the actual encod-ing numbers that are used to identify the fields in anencoded message.

3.4.4.4 Protocol BehaviorCertain types of objects have special behavioralrules that are described by the FMS specification.For example, the simplified behavior of a ProgramInvocation object is shown in Figure 35.

A remote device can control the state of theprogram in another device on the fieldbus. Forexample, the remote device would use the CreateProgram Invocation FMS service to change theprogram state from Non-existent to Idle.The Start FMS service would be used to changethe state from Idle to Running and so on.

3.5 H1 Physical Layer (31.25 kbit/s)ISA S50.02-1992 ISA Physical Layer StandardIEC 61158-2:2000 (ed. 2.0), Fieldbus standard

for use in industrial control systems Part 2:Physical Layer specification and service definition

FF-816 31.25 kbit/s Physical Layer ProfileSpecification

The Physical Layer is defined by approvedstandards from the International ElectrotechnicalCommission (IEC) and ISA (the international societyfor measurement and control).

The Physical Layer receives messages from thecommunication stack and converts the messagesinto physical signals on the fieldbus transmission

medium and vice-versa.

Conversion tasks include adding and removingpreambles, start delimiters, and end delimiters(Figure 36).

g

g

g


21

Technology

Non-existent

Idle

Running

Stopped

Unrunnable

DELETE

KILL

CREATE

START

STOP RESUME

RESET

UserApplication

FMSFASDLLPHY

Behavior Rules for the ProgramInvocation Object.

Figure 30Figure 35

1 11 1

V o

l t a g e

Time

FieldbusMessages

Figure 11

Fieldbus Media(Wire)

PHYSICAL LAYER

COMMUNICATIONSTACK

USERAPPLICATION Example of voltage mode signaling

Figure 36


28/43

Fieldbus signals are encoded using the well-knownManchester Biphase-L technique. The signal iscalled synchronous serial because the clockinformation is embedded in the serial data stream.

Data is combined with the clock signal to create thefieldbus signal as shown in the figure below. Thereceiver of the fieldbus signal interprets a positivetransition in the middle of a bit time as a logical 0and a negative transition as a logical 1 (Figure 12).

Special characters are defined for the preamble,start delimiter, and end delimiter (Figure 38).

The preamble is used by the receiver to synchronizeits 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- signalsdo not transition in the middle of a bit time. Thereceiver uses the start delimiter to find the begin-ning of a fieldbus message. After it finds the start

delimiter, the receiver accepts data until the enddelimiter is received.

3.5.1 31.25 kbit/s Fieldbus SignalingThe transmitting device delivers 10 mA at31.25 kbit/s into a 50 ohm equivalent load to createa 1.0 volt peak-to-peak voltage modulated on topof the direct current (DC) supply voltage.

The DC supply voltage can range from 9 to 32 volts.However, for Intrinsically Safe (I.S.) applications, theallowed power supply voltage depends on thebarrier rating (Figure 39).


22

Technology

+

-

1

0

DATA

CLOCK

MANCHESTERBIPHASE-LENCODING

1 Bit Time

0 01 1 0

Figure 12

PREAMBLE

STARTDELIMITER

ENDDELIMITER

CLOCK

+0-

0 11 0 01

+0

N+ 0N- N-1

1

N+ 0

+0-

N+ N-1 N+ N- 1 0 1

-

1

0

1

0

Figure 13

Figure 38Figure 37


29/43

31.25 kbit/s devices can be powered directly fromthe fieldbus and can operate on wiring previouslyused for 4-20 mA devices.

The 31.25 kbit/s fieldbus also supports I.S.fieldbuses with bus powered devices. To accom-plish this, an I.S. barrier is placed between thepower supply in the safe area and the I.S. devicein the hazardous area.

To address Intrinsic Safety applications, theFieldbus Foundation supports using either thetraditional Entity model or the newer FieldbusIntrinsically Safe Concept (FISCO). The mixing of theEntity model with the FISCO approach in the prepa-ration of a system design is not recommended.

3.5.2 31.25 kbit/s Fieldbus Wiringg 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

The 31.25 kbit/s fieldbus allows stubs or spurs (Figure 40).

The length of the fieldbus is determined by thecommunication rate, cable type, wire size, buspower option, and I.S. option.

Figure 41 gives a summary of examples of optionsavailable in the Physical Layer standard.


23

Technology

* A terminator is installed at each end of the main trunk cable.

** Single device per spur -- The spur length must be reduced by 30metres for each additional device on a spur.

*** The number of devices possible on the fieldbus will varydepending on factors such as the power consumption of eachdevice, the type of cable used, use of repeaters, etc. Consult thePhysical Layer Standard for details.

Devices *** Spur Length**

25-32 1 metre19-24 30 metres15-18 60 metres13-14 90 metres

1-12 120 metres

Trunk*

Spurs

Control RoomEquipment

JunctionBox

Cable Length = Trunk Length + All Spur LengthsMaximum Length = 1900 metres with Type A Cable

Figure 15

D e v

i c e

C u r r e n

t

V o

l t a g e

Time

Power9 to 32 Volts

0.75 to 1.0 V p-p

100 OhmPowerSupply

100 Ohm

+

0Receiving Transmitting

Fieldbus Device

Fieldbus Network

Fieldbus Signal

TerminatorC is sized to

pass 31.25 kbit/s.

15 to 20 mA p-p

C C

Signaling waveforms for the 31.25 kbit/s Fieldbus

Note: As an option, one of the terminatorsmay be center-tapped and grounded toprevent voltage buildup on the fieldbus.

Figure 14Figure 39 Figure 40

Characteristics Data Rate

31.25 kbit/s 31.25 kbit/s 31.25 kbit/sType Voltage Voltage VoltageTopology Bus/tree Bus/tree Bus/treeBus Power none DC DCClassification Intrinsically

Safe

Number of Devices* 2-32 2-6 2-12

Cable Length 1900 m 1900 m 1900 mSpur Length 120 m 120 m 120 m

Figure 41

* The number of devices possible on a fieldbus link depends onfactors such as the power consumption of each device, the typeof cable used, use of repeaters, etc. Consult the Physical LayerStandard for details. The number of network addresses available foreach link is 240.


30/43

3.6 HSE Communication Stack

g FF-581 System Architectureg FF-586 Ethernet Presence

g FF-588 Field Device Access (FDA) Agentg FF-589 HSE System Managementg FF-803 HSE Network Management

Most Ethernet-based protocols are not fully openbecause part of the stack is proprietary. The lackof higher-level standards has prevented easy inte-gration of other subsystems of the plant. The HSEstandard includes the application and user layers,thereby making it a completely open protocol.

3.6.1 HSE Device TypesThere are four basic HSE device categories, but manyare typically combined into a single device: linkingdevice, Ethernet device, host device, and gatewaydevice. A Linking Device (LD) connects H1 networksto the HSE network. An Ethernet Device (ED) mayexecute function blocks and may have some conven-tional I/O. A Gateway Device (GD) interfaces othernetwork protocols such as Modbus, DeviceNet orProfibus. A Host Device (HD) is an operator work-station or an OPC server.

3.6.1.1 HSE DeviceHSE devices are Foundation fieldbus devices thatcontain an FDA Agent, an HSE SystemManagement Kernel (SMK), and an HSE NetworkManagement Agent (NMA) Virtual Field Device(VFD).

The HSE field device is an HSE device that is theHSE counterpart to the H1 field device. Instead ofan H1 communications stack, it has an HSEcommunications stack.

3.6.1.2 Linking DeviceThe linking device is an HSE device that connectsthe HSE to one or more H1 links. It provides gate-way services that map FDA SM and FMS messagesto their H1 counterparts.

3.6.1.3. Gateway Deviceg FF-893 Function Block Application Process -

Part 4

The I/O gateway is an HSE device that is similar tothe linking device, but it connects the HSE to one ormore I/O devices or buses.

The MIO blocks are ideal to gateway remote-I/Oprotocols such as Modbus and Profibus-DP thatcontain mainly process input and output information

into the fieldbus environment.

3.6.1.4. Host Device (OPC DA server)Non-HSE devices capable of communicating withHSE devices. Examples include configurators andoperator workstations.

3.6.2. Ethernet PresenceThe HSE Presence in a HSE device provides ser-vices for Ethernet Stack initialization, general-pur-pose communication over the Ethernet media, timesynchronization, and HSE Presence management.The HSE Presence is an addition to the FieldbusFoundation H1 system and network managementmodel. The HSE Presence does not replacethis model, but rather adds services for HSEPresence management.

This specification is intended to encompass all thephysical media and signaling rates described inIEEE Std 802.3 and IEEE Std 802.3u. Management


24

High Speed Ethernet

List of Required Internet Protocols TABLE A Internet RFC

768 User Datagram Protocol (UDP)791 Internet Protocol (IP)792 Internet Control Message Protocol (ICMP)793 Transmission Control Protocol (TCP) Optional)826 Ethernet Address Resolution Protocol (ARP)1112 Internet Group Management Protocol (IGMP)1122 Requirements for Internet Hosts

Communication Layers1155 Structure and Identification of Management

Information1157 Simple Network Management Protocol (SNMP)1213 Management Information Base-II1533 DHCP Options and BOOTP Vendor Extensions1541 Dynamic Host Configuration Protocol1643 Definitions of Managed Objects for the

Ethernet-like Interface Types2030 Simple Network Time Protocol

H1 HSE

H1 and HSE Benefits


31/43

of the HSE Presence is employing SNMP augment-ed to support Fieldbus Foundation unique EthernetStack parameters.

The universal set of protocols which may be includ-ed in a given implementation of HSE Presence isidentified in Table A.

3.6.3 Field Device Access (FDA)The FDA Agent has the following objectives: Convey System Management (SM) services overUDP and Fieldbus Message Specification (FMS)services over UDP/TCP. This allows HSE and H1 fielddevices, conventional I/O devices, and non-FF I/Odevices to be connected to the HSE through a linkingor a gateway device.

Republish H1 data from linking devices that do notsupport H1 bridging. This allows linking devices to beconstructed from multiple standalone H1 interfacesinstead of using an H1 bridge. Send and receive LAN redundancy messages tosupport redundancy of HSE interfaces in devices.

The FDA Agent allows control systems to operateover the HSE and/or through Linking Devices and itenables remote applications to access field devices ofany type across UDP/TCP using a common interface.

3.6.4 HSE System ManagementSystem management is the activity that integratesdevices on an HSE network into a coherent communi-cation system.

The following functions are supported: Each device has a unique, permanent identity anda system-specific configured name. Devices maintain version control information. Devices respond to requests to locate objects,including the device itself. Time is distributed to all devices on the network. Function block schedules are used to start functionblocks. Devices are added and removed from the networkwithout affecting other devices on the network.

3.6.5 HSE Network ManagementHSE Network Management permits HSE host sys-tems to conduct management operations over theHSE network with their associated devices with anHSE interface.

The following capabilities are provided by networkmanagement: Configuring the H1 Bridge, which performs dataforwarding and republishing between H1 interfaces Loading the HSE Session List or single entries inthis list. An HSE Session Endpoint represents a logicalcommunication channel between two or more HSEdevices. Loading the HSE VCR List or single entries in thislist. An HSE VCR is a communication relationshipused for accessing VFDs across the HSE. Performance Monitoring through the collection ofstatistics for Session Endpoints, HSE VCRs, and theH1 Bridge. Fault Detection Monitoring.

3.7 Redundancy

g FF-593 High Speed Ethernet Redundancy

For use in factory and process automation, Ethernethas to be made industrial strength. F OUNDATIONfieldbus HSE is based on Ethernet and is used atthe host-level of the control system. The host-levelnetwork ties the whole system together linking thevarious subsystems to the host. Thus, the visibility ofhundreds and perhaps thousands of loops dependson the host-level network as does any intra-area

control loops. A complete failure could result in heavylosses. High availability for the host-level network istherefore paramount. HSE is the only open, Ethernet-based protocol to address the need for round-the-clock availability of network and devices. Becausedevice and port redundancy requires interoperabilitybeyond Ethernet and IP, other Ethernet solutions donot support it. HSE is the first standard protocol tooffer functionality to select which device in a redun-dant pair and which one of redundant ports that atransmitting device should address. Exchange ofredundancy management information is part of thestandard protocol.

HSE is built on standard Ethernet, originally a technol-ogy for the office environment. However, industrialgrade hardware is available and HSE has a numberof functions built in to insure fault tolerance. Themodern form of Ethernet uses UTP (UnshieldedTwisted Pair) wiring using a hub-based star topologyin which there is only one device per wire segment.


25

High Speed Ethernet


32/43

Therefore, devices can be disconnected and connect-ed without disrupting other devices and any wire faultonly affects a single device (i.e., the impact of a faultis reduced somewhat).

A shared hub is a multiple port repeater that joinsseveral segments into a single network. A switchedhub is a multiple port bridge that joins several net-works together. Fiber optic media can be employedto increase tolerance towards electrical noise andground potential differences further increasing therobustness of the system. Industrial grade hubs withredundant power supplies, wide temperature ranges,rugged enclosures, etc., are available for use in atough plant environment.

3.7.1 Need for Host-Level Redundancy

The shutdown of a plant is extremely disruptiveand downtime means heavy losses. At the host-level the network and devices are shared betweenmany loops, making these parts very critical to theoperation of the plant. If the host-level network isnot functioning the operators would be unable tomonitor and supervise the plant and, therefore,many loops would have to be shut down. Thehost-level network is also used for intra-area controlloops that would have to be shut down. Unlike thefield-level where high availability is achieved bydistributing functionality thereby isolating faults toa small sector, at the rather centralized host-levelredundancy is instead used to achieve highavailability. Any Ethernet network can use mediaredundancy to achieve some measure of increasedavailability, but HSE also supports complete deviceand networking redundancy.

3.7.2 Media Redundancy Any Ethernet device even with just a single port canhave simple media redundancy using some form ofport splitter . Splitters are implemented in differentways but all work in the same basic fashion. A single port is split in two, connecting devicestogether in a circle providing alternate communica-tion paths. If communication in one direction is notpossible, communication is routed the other way(i.e., the network is self-healing ). The switchovertime is very short. Recovery time is much fasterthan the traditional spanning tree algorithm, andthus operations will continue without any loss ofdata. A splitter may either be a transceiver handlinga single port requiring one at every node, or may beimplemented between hubs in a ring topology.

Media redundancy works only on the physical layerand is therefore independent of protocol used.

Some solutions require a central redundancy

management device that may be an Achilles heel,whereas other solutions have the redundancymanagement built into the hubs. Very often themedia redundancy ring is implemented using fiberoptics. The ring is not a standard Ethernet topologyand the special splitting hubs and transceiversusually use standard media but employ proprietarymechanisms to manage the switchover. Therefore,all the splitters in the ring have to come from thesame manufacturer.

Simple media redundancy may be sufficient forsome applications, but not all. For example, someapplications combine media redundancy withfully duplicated networks and linking devices.

3.7.3 Complete Network Redundancy The HSE protocol goes further than simple mediaredundancy. Special integrity-checking diagnosticsand redundancy management part of the HSE pro-tocol in each device enables use of two completelyindependent networks, redundant communicationports, and also redundant device pairs. All redun-dant Ethernet device pairs and the workstations areconnected to both Ethernet buses. When a singleunit has two ports these are named A and B.The switchover is totally bumpless and transparent.The redundancy scheme leaves several deviceoptions open (Figure 45), but they are all compatiblewith each other, e.g.:

Redundant device pair where primary andsecondary have one port each

Redundant device pair where primary andsecondary have two ports each

Single device that has two ports

All parts of the network have redundancy, including

the hubs (i.e. two independent networks ensuringthat communication can continue even if onenetwork fails). This means that the network cansustain multiple faults but still continue to function.Thus the networking is extremely reliable, minimiz-ing loss of data and unnecessary shutdowns.

The philosophy of the HSE redundancy is one ofoperational transparency and diagnostic visibility .


26

High Speed Ethernet


33/43

This means that the control application sees eitherthe primary or the secondary Ethernet devicedepending on which one is active, whereas thesystem diagnostics sees both. Thus, the diagnostics

insures that even the inactive devices are fullyfunctional and ready to take over at any moment.

A wide diagnostic coverage is an integral part ofthe HSE protocol going far beyond mere hardwareduplication. Every HSE device, including the host orany redundancy manager , independently keepstrack of the status of the networks and all thedevices on it. Because HSE is not only Ethernetmedia but also has a standard application layer,devices from different manufacturers periodicallyexchange their view of the netw

FOUNDATION Fieldbus Technical Overview

Documents

Transcript of FOUNDATION Fieldbus Technical Overview