the foundation - fieldbus, incfieldbus inc. has been involved with foundation fieldbus and its...

THE

FOUNDATION fieldbus

PRIMER

Prepared

byfieldbus inc.

Revision 1.1Released June 24, 2001

2001 Fieldbus Inc. All rights Reserved

fi

Prolog

Fieldbus Inc. has been involved with FOUNDATION fieldbus and its precedenttechnologies since 1993. Since 1996 we have worked with clients worldwide indeveloping, and registering as interoperable, FOUNDATION fieldbus devices. FieldbusInc. is a total solution supplier, capable of providing all required software, hardware,tools, engineering and project management to assure fast, economical developmentprograms.

As a result of years of experience, and discussions with many fine clients, we haveprepared this introductory manual to help those new to the field gain a basicunderstanding of fieldbus. We sincerely hope our readers find this primer useful, and wewish you success in mastering this revolutionary new technology.

Fieldbus Inc.9390 Research BoulevardSuite I-350Austin, Texas 78759

Tel: 512 794-1011Fax: 512 794-3904www.fieldbusinc.com

CONTENTS

THE FOUNDATION FIELDBUS PRIMER........................................................................................... 1

PREFACE................................................................................................................................................... 1INTRODUCTION ............................................................................................................................................ 1BACKGROUND ............................................................................................................................................. 2

FIELDBUS OVERVIEW ............................................................................................................................. 3

Physical Layer ........................................................................................................................................ 4Communications Capability.................................................................................................................... 6Function Block Application .................................................................................................................... 7

A SYSTEMS PERSPECTIVE............................................................................................................................ 9Continuous Control Process ................................................................................................................. 10

a) Temperature Device Failure ......................................................................................................................12b) Flow Device Failure ..................................................................................................................................13c) Maintenance Concepts ..............................................................................................................................14

Discrete Control Example..................................................................................................................... 15DEVICE DESCRIPTIONS............................................................................................................................... 17

a) DD Example..............................................................................................................................................17b) Menus and Methods ..................................................................................................................................18c) Device Programs .......................................................................................................................................18

Configuration........................................................................................................................................ 18VIEWPOINT FROM THE CONSOLE................................................................................................................ 20

d) Access Privileges.......................................................................................................................................20e) Trends........................................................................................................................................................20f) Views ........................................................................................................................................................20g) Alarms, Alerts and Events .........................................................................................................................21h) Mode .........................................................................................................................................................23

COMMUNICATIONS..................................................................................................................................... 24HIGH SPEED ETHERNET (HSE) .................................................................................................................. 27

a) What HSE Does ........................................................................................................................................27b) H1/HSE Interconnections..........................................................................................................................28c) Basic Details of the HSE Specification .....................................................................................................29d) Redundancy...............................................................................................................................................30e) HSE Summary...........................................................................................................................................31

CONCLUSION ............................................................................................................................................. 31

APPENDIX I ............................................................................................................................................... 33

EXCERPTS FROM THE IEC/ISA 1987 DRAFT REPORT.................................................................... 33

2001 Fieldbus Inc. All rights Reserved

2001 Fieldbus Inc. All rights Reserved 1

THE FOUNDATION fieldbus PRIMER

PREFACE

This primer is written for plant operators,engineers and managers who have at least aworking understanding of process control andplant operations, and are looking for anintroduction to the basic principles ofFOUNDATION™ fieldbus. The focus will be onwhat the technology does and how such fieldbussystems behave, using examples to illustrateoverall concepts.

IntroductionThere are many digital communicationtechnologies being promoted as the futurereplacement for the venerable 4–20 mA analogstandard, and most are self-described as fieldbus.With the exception of FOUNDATION™ fieldbus,virtually all of these technologies were developedfor non-process environments such as automotivemanufacturing, building automation, or discreteparts manufacturing, and later adapted to processcontrol. Generally, they are well suited to theapplications for which they were originallydeveloped. Some of these technologies are open,some are proprietary. Most are a combination,having some open aspects but requiring the useof proprietary hardware or software components.All but FOUNDATION require a proprietaryapplication to provide a complete controlsolution.

Every communication technology provides amethod for transmitting data between variousdevices and a host, and some providecommunications directly between devices. Thevarious schemes differ in how well they areoptimized for moving data quickly, theirsuitability for real-time control, the cost ofhardware implementations, their networkingcapability for branches, spurs and long distances,and for how power is distributed.

Comparisons among “fieldbus technologies”typically reduces to comparisons of data rates,message length, number of devices on a segment,

etc. These are all important communicationsissues and each technology represents aparticular set of trade-offs which adapt it to itsoriginal application, and each is rooted in thetechnology that was available or in vogue at thetime of its development.

Using a strategy exactly opposite ofFOUNDATION fieldbus, these variouscommunications technologies minimizedependence on local intelligence in deference tominimum device cost, and maximize reliance ona centralized control architecture. Measurementinstruments in such structures communicate to acentral computing system at the request of thatcentral system. A proprietary controlapplication, running on the central systemprocesses the field data and distributes controlsignals to other devices back in the field.Regardless of how open the communicationscheme may be, the control application is alwaysproprietary.

The key distinctions between these technologiesand FOUNDATION fieldbus are;

♦ FOUNDATION fieldbus provides an openspecification for both communications andthe control application.

♦ FOUNDATION fieldbus distributes controlfunctionality across the bus, makingmaximum use of local intelligence toimprove performance and reduce totalsystem cost.

♦ Devices are required to be interoperable,providing the user with tools to implement acontrol system with products from multiplemanufacturers without custom programming.

With FOUNDATION fieldbus, the network is thecontrol system. The major goals of this primerare to illustrate how this new architecturebehaves, what it means to users, and what itrequires of control equipment manufacturers.


BackgroundThe technology of Fieldbus1 began to evolve inAugust of 1984 when the InternationalElectrotechnical Commission (IEC) and TheInternational Society for Measurement andControl (ISA)2 met to initiate work on a newinternational standard. Their objectives andrequirements were presented in a Draft Reportissued three years later,3 in September of 1987.The report presented functional guidelines whichwould be refined, tested and committed to aspecification over the following decade.

The primary stated objective of the ‘87 reportwas, in part, “…to specify a digital, serial,communications link between primaryautomation devices deployed in amanufacturing/process area (the field) andhigher-level automation/control devices locatedin a production control area (the control room)”.The committees producing the draft were staffedabout equally with end users and suppliers. Thereport dealt predominantly with physical layerissues and [control] application requirements, thetwo features most obvious to users.

Two areas of [physical] application wereidentified and labeled as H1 and H2. The H1application area was intended as a digitalreplacement for the 4 to 20 mA analog standardin widespread use in the fluid process industries,later called process automation. The H2application area was intended to extend the H1concept to systems having a different set ofrequirements including high speed discretecontrol and data collection applications, latercalled manufacturing automation. The objectivewas to develop one standard with the flexibilityto satisfy the needs of both application areas,though with different physical layers and datarates.

The H1 requirements included the need to powerfield devices from a single unshielded, twistedwire pair, which would also be used for

1 We shall use Fieldbus with a capital “F” as shorthandfor FOUNDATION™ fieldbus.2 In 1994 the Instrument Society of America changedits name to, The International Society for Measurementand Control, but retained use of the abbreviation, ISA.3 Instrument Society of America Standards andPractices 50 Functional Guidelines, Sept 9, 1987,ISA-SP50-1987-17-G. See Appendix I.

communication, and to be able to meet lowpower, intrinsically safe standards already in use.Other major requirements included bus lengthsup to 1,900 meters (1.18 miles) withoutrepeaters, unlimited spurs, and operation inelectrically noisy environments. It wasdemonstrated that a Manchester encoded signalat 31.25 kbits per second fulfilled allrequirements.

Contrary to the usual view, the H2 applicationrequirements were in some ways less demanding.For example, separate wires for power and signalwere acceptable, the required distances were aslittle as 500 meters (0.31 miles), complex spurtopographies were unnecessary, and higherquality, Ethernet cabling was the acceptedpractice. On the other hand, the data rates agreedto for the H2 were 1 and 2-1/2 Mbits per sec,significantly higher than for H1. A commonlyaccepted model for process automation was thatH2 would serve as a home run connection withnumerous H1 segments attached along the way.The expectation was that manufacturingautomation would rely exclusively on H2.

The final specification4 for H1 was published inAugust of 1996. Subsequent development ofproducts and the application of H1 networks inprocess control is accelerating as anticipated.

Testing of the H2 specification was suspended inMarch of 1998 when the Fieldbus Foundationshifted its goal for the high speed network to 100Mbit/sec Ethernet, also called high speedEthernet (HSE). The H1/H2 architecturalconcepts remain the same, with H2 beingdisplaced by HSE. The primary advantages ofHSE are:

♦ Higher speed♦ Low cost, off-the-shelf hardware♦ Smoother integration with management

information systems

The HSE final specification, FF-044-1.0-1, waspublished in April 2000, including everything butredundancy. The preliminary specification forredundancy has been released, but requiresvalidation, which is currently scheduled to occurin three phases.

4 Part 1, FF 890 and Part 2, FF-891


Fieldbus Overview

The focus of the IEC/ISA committees was clearlyon how to solve application requirements. Whatthe physical layer needed to do and theenvironment in which it had to perform wasspelled out in some detail. The expectations ofthe control and monitoring systems wereidentified. Requirements such as the need to “hotwire” devices on an operating bus segment andthe need for prioritized access privileges todevice parameters on the network werespecifically cited.

Furthermore, the customary ability in the analogworld of being able to replace a device from onemanufacturer with a similar device from anothermanufacturer without loss of functionality, andwithout requiring special engineering, was anexpectation of Fieldbus. Why should a newertechnology offer less capability than the olderone it was displacing? Multi-manufacturerinteroperability was a natural expectation.

Specifying a complete, well designed controlapplication, the so-called user layer, held equalpriority with specifying the communicationscheme, whose only real purpose was to supportthe control application anyway.

The Fieldbus specifications that emerged can berelated to the International StandardsOrganization (ISO) Open System Interconnect(OSI) model, as shown in Figure 1. It is not

necessary to understand the ISO model tounderstand Fieldbus, but the comparison may beuseful to some readers.

The OSI model represents all communicationfunctions as a set of seven layers, as shown onthe left side of the figure. It does not address anyapplication that may need to usecommunications, shown here as it often is as“Layer 8”.

Fieldbus is essentially a local area network.Therefore, much of layers 3 through 6 are notrequired. Those elements that are needed, werecompressed into what is called the fieldbusaccess sublayer, plus some additional entitiessuch as system management and networkmanagement. As the diagram shows, this,combined with the application and data linklayers, forms the communications aspect ofFieldbus.

The layer not defined by OSI, and sometimesalso called the user layer, is defined in Fieldbusas the Function Block Application.

The entire functionality represented by thesethree segments; physical layer, communicationstack, and function block application, must residein every active device on a Fieldbus network. Inaddition, in field devices, the tightly specified

Proprietary Application

Data Link LayerPhysical Layer

7

6

5

4

3

2

1

8

Data Link LayerPhysical Layer

Application Layer

Application Layer (FMS)

ProcessControl

Application

(Open)Function Block

Application

(Open) Physical Layer

(Open)Communication

Stack

Presentation Layer

Session Layer

Transport Layer

Network Layer

ISO OSIModel

FieldbusConceptually

FieldbusSpecifications

LayerIndex

Fieldbus AccessSub-Layer (FAS)

Figure 1. Relationship Between Fieldbus and OSI Model.


function block application must interface withthe unique technology of the device. This isachieved through transducer blocks. A schematicof a simple network illustrates these concepts inFigure 2, below.

A synopsis of the physical layer, communicationsstack, and function block application follows.

Physical Layer

Early Fieldbus committee work resulted ininternational approval of a physical layer

standard in 1992. The specification is availableeither as IEC 1158-2: 1993, or as ISA-S50.02-1992. Only the H1 physical layer will bereviewed here. The Fieldbus Foundationpublishes its FF-816, FOUNDATION™Specification 31.25 kbits Physical Layer Profile,which defines the requirements for H1 busses.Also published is FF-830, 31.25 kbits PhysicalLayer Conformance Test Specification, whichdefines the physical layer requirements thatdevices must pass to be registered asinteroperable. These documents are all ofimportance to device developers.

The Fieldbus Foundation publishes twoApplication Guides which are relevant to thephysical layer; Wiring and Installation 31.25kbits, Voltage Mode, Wire Medium, and 31.25kbits Intrinsically Safe Systems. These should beof interest to developers and end users alike. Thephysical layer specifications define themechanical and electrical requirements fortransmitting signals between Fieldbus devices.

The relatively low H1 data rate of 31.25 kbitswas intentionally selected to minimizeconstraints on the cabling system.5 The result isthat existing twisted wire pairs used in 4-20 mAinstallations can, in many cases, be used forFieldbus signals. Higher quality, lowercapacitance wiring is specified if maximumdistances are required.

H1 allows for fairly liberal topologies, asillustrated In Figure 3. Spurs are allowed and thebranch points may occur anywhere along thetrunk, without restriction.

The number of devices possible on a singlesegment depends on factors such as the powerconsumption of each device, the type of cableused, whether the devices must be intrinsicallysafe (IS), and whether they are bus powered.

5 31.25 kbits is also easily obtained by dividingdown from a 1 MHz oscillator.

Figure 2. System Schematic.

Transducer Blockand Actuator

Function BlockApplication

Physical Layer

CommunicationStack

Sensor andTransducer BlockFunction Block

Application

Physical Layer

CommunicationStack

Function Block andHost Application

Physical Layer

CommunicationStack

2001 Fieldbus Inc. All

The maximum number of devices is often listedas six if bus powered and IS, 12 if non-IS, and 32if neither bus powered nor IS. These limits arebased on assumed power requirements andsupplies, but are not specified.

The total cable length including spurs is 1900meters (6234 ft). Up to four repeaters arepermitted, which extends the cable length tonearly five miles. The network must also have aterminator at each of the two most distant ends.

A Fieldbus network requires a special fieldbuspower supply. The standard voltage level is thefamiliar 24 volts6 dc. A current capability of 100mA to 120 mA is appropriate for a typical H1bus segment, and can meet IS requirements.

A unique requirement of the power supply is thatit must offer low source impedance at dc, buthigh impedance at the signaling frequency, asillustrated in Figure 4.

The signal is Manchester encoded and anidealized signal wave form is illustrated inFigure 5. Some of the characteristics ofManchester encoding are that the signalfrequency is used to synchronize the data clocksbetween communicating devices. Also, a logicalzero or one is indicated by whether the signal isfalling or rising at the center of a “bit time”.

A bus powered Fieldbus device will typicallydraw between 10 mA and 20 mA of current forsteady-state operation. During signaling, it will“toggle” the current draw above and below the

6 The specification requires devices to operate

Figure 4. Power Supply SourceImpedance.

3k Ω

31.25kHz

Figure 3. Example H1 Fieldbus Technology.

FieldbusI/O

Point-to-Point

Daisy ChainBus with Spurs

rights Reserved 5

on voltages from 9 VDC to 32 VDC.


steady state value by 0.25 to 0.33 mA. Againstthe 3000 ohm source impedance of the powersupply, this results in a 0.75 to 1.0 peak-to-peakvoltage signal on the bus.

Low source impedance of the power supply at dcand low frequencies, allows devices to be addedor removed from the bus with a minimal affecton steady state bus voltage. Fieldbus devices arerequired to operate on voltage levels from 9 V to32 V.

The relatively low frequency, high signal levels,and low dc impedance, make possible the use oflow-cost twisted wire pairs for power distributionand reliable communications. The suitability ofthe technology for in-plant use was tested prior tothe acceptance of the physical layer standard.The primary test beds were an Exxon refinery inLinden, New Jersey and a BP refinery inSudbury, England. For additional information onthe Fieldbus physical layer, refer to thereferences listed in the beginning of this section.

Communications CapabilityThe requirements of the communications schemefor multiple devices on a common cable ornetwork depend on the system requirements thatthe network must satisfy. Process automationpresents a variety of sometimes contradictoryrequirements.For example, data required for real time controlmust be transmitted on a precisely periodic timeschedule to provide satisfactory dynamic control

of plant processes. There is no merit inconfirming a transmission since, in a dynamicsystem, a data point only has relevance at aparticular instant in time. Re-transmitting an outof date value serves no purpose. Devicesperforming control must rely on valid periodicdata, yet be able to cope with an occasionalmissing or faulty value.

In contrast, the occurrence of alarm conditionsshould be communicated at the earliestpossibility, independent of periodic timeintervals. Furthermore, if an alarm message iscorrupted or lost, it is essential that the samemessage be re-transmitted, and methods ofconfirmation and acknowledgement are required.

As illustrated in Figure 6, there is also thequestion of who should communicate withwhom? Some messages must be sent to multiple

receivers, or broadcast. In other cases, only twodevices may be involved, peer-to-peer.

In Fieldbus, the device that is located in thecontrol room is typically called a host. It needscapabilities that are usually not required of otherdevices on the network. These include the abilityto configure and set-up a network, and mayinclude the ability to control communications.

Figure 5. Ideal Signal Wave Form.

1 bit32µs

0 1 0 0

Time

Volta

ge

0

?

?

?

Figure 6. Communication Paths.


All communications in Fieldbus are controlled bya single device called the link master. The linkmaster contains a function called a Link ActiveScheduler, or LAS. Most host devices will havean LAS. How the LAS controls networkcommunications is discussed in later sections.

There are several classes of field devicesincluding; basic, link master, linking device andgateway. A basic device is capable of all thebasic communications required of a field device.The relationship between a host and a basicdevice is that the host is a client, the basic deviceis a server. A client makes requests/demands, aserver obliges.

If LAS capability is added to a basic device, itbecomes a link master (LM) device. This doesnot give it all the capabilities of a host, but itdoes permit it to control communications.Fieldbus permits multiple, redundant linkmasters. The LAS device having the lowest busaddress is automatically in control.

A Linking Device (LD) is used to connect an H1segment to an HSE segment. More likely, an LDwill be able to connect several H1 segments toHSE. The primary functions of the LD are toinsert or remove Fieldbus messages into or fromEthernet messages, and to provide a routingfunction among the various segments anddevices. This will be discussed further in a latersection.

A gateway device is used to connect Fieldbus tosome other, non-fieldbus communicationsprotocol, such as Modbus. Gateways will not bediscussed further.

The Fieldbus communications technologyprovides scheduled communications for precise,periodic transmission of data used in control, andnon-scheduled communications for “earliestopportunity” transmission of other data.Messages need not be routed through the host,but can pass directly from the device producingthe data to the device that requires the data.Message confirmation may be required, but onlywhere it is appropriate. In either case, messagescontain an internal error checking mechanism so

that an error will be detected by the receivingdevice.7

Behavior of the communication mechanisms willbe more fully explained by examples in latersections. It is important to understand that theFieldbus protocol was designed in cooperationwith the control application, so the requirementsof each are matched by design. The controlapplication is discussed next.

Function Block ApplicationIn process control the prevailing model fordescribing a control system is the function blockdiagram. Because of its relative ease of use andworldwide acceptance, this became the model forthe Fieldbus user layer, which is a standardizedapplication running on a standardizedcommunications protocol.

Control systems require various interfaces totheir environment, as illustrated in a most generalsense in Figure 7. Inputs consist of variousmeasured parameters such as; pressure,temperature, switch position, shaft speed,discrete array patterns, etc. Outputs may be; shaftpositions or velocity, switch closures or othermodulation variables generally used to controlsome of the inputs.

In the usual case, some type of human/machineinterface (HMI) is required at some level of the

operation. The control system itself is modeledas an interconnected set of functions, or functionblocks, as illustrated by the cascade control looprepresented in Figure 8.

7 A cyclic redundancy algorithm is used whichyields an undetected error rate of less than oneerror in 21 years of continuous operation.

Figure 7. General Model of aControl System.

ControlSystem

Inputs Outputs

H M I


Fieldbus function blocks are softwareencapsulations designed so that each perform aspecified set of operations on one or more inputs,and generate one or more outputs. Blocks residein the various devices on a Fieldbus network toimplement the control strategy. Blocks areevaluated, or executed, on a periodic basis undercontrol of the (physical) device in which theyreside. Communication among blocks takes placethrough linkages that are established by aconfiguration procedure, before startup or duringoperation. Custom programming or special filegeneration is not required to configure theselinkages.

Some blocks, such as a PID controller, may belocated almost anywhere on the network. Otherblocks perform functions that are associated with

specific items of equipment.

For example, an Analog In (AI) block accepts adigitized representation of a particular analogparameter, the measured variable, and performsspecified operations on the data. The primaryoperations include checking engineering units,filtering, optionally extracting square root,checking for alarm conditions and range checks.Every transmitter measuring an analog variablemust have at least one AI block to bring theprocess value into the network. In a similar way,every control valve must have an Analog Out(AO) block to produce a digitized representationof the desired valve stem position, and to movethe value out of the network (and into the valvepositioner).

Other functions, such as a PID controller, mayreside in any device on the network including thevalve, the transmitter, or the host. At this timethere are 21 function blocks in the finalspecification and 12 more are at the preliminaryspecification stage. These are defined by;

♦ Part 1, FF-890 Revision 1.4♦ Part 2, FF-891 Revision 1.4♦ Part 3, FF-892 Revision 1.4

The current revisions are final specifications (FS)for Parts 1, 2, and 3, and were released in Juneof 1999.

Table 1 lists the first ten blocks (Part 2) andbriefly describes their primary purpose.Additions to the standard blocks are possible asusers of the technology define new requirements.Custom function blocks are permissible with theuse of specified files called Device Descriptions,which will be discussed in a later section.

HSE will support all H1 function blocks. Inaddition, an extended set of blocks specificallyfor HSE applications is in development.

Figure 8. Function BlockDiagram of Cascade Loop.

Flow SP

ExternalProcess

AI PID AO AI

PID

Temp SP

TemperatureTransmitter

TemperatureController

Flow Transmitter,Controller, and Valve


Block Symbol Primary FunctionsAI Analog In: Accepts digitized representation of an external analog signal from external

hardware. Performs scaling, filtering, and provides high and low alarm function.AO Analog Out: Provides digitized representation of an analog signal to external hardware.

Includes scaling, range and rate of change limits, and provides several fault-state (fail-safe) options.

DI Discrete In: Accepts 8-bit unsigned input value from external hardware. Providesfiltering, optional inversion, and discrete alarms.

DO Discrete Out: Passes 8-bit unsigned output value to external hardware. Providesoptional inversion, mode shedding and fault-state (fail-safe).

PID Proportional, Integral, Derivative Controller: Provides filtering, set point limits andrate limits, feedforward support, output limits, error alarms, mode shedding, and anti-wind-up capability, but the PID algorithm is manufacturer specific.

PD Proportional + Derivative Controller: Provides filtering, set point limits and rate limits,feedforward support, output limits, error alarms, mode shedding, and manual bias, butthe PD algorithm is manufacturer specific.

ML Manual Loader: Accepts digitized representation of an analog signal from an AI blockor a computer. Provides high and low output limit function and an output to otherblocks. Conceptually, a controller with a human for the control algorithm.

BG Bias/Gain Station: A simple calculation block with output limits, that connect to otherblocks.

CS Control Selector: Selects among highest, lowest, or average of two or three inputs(from other blocks). Provides balanceless transfer of signals.

RA Ratio Station; Accepts signals from two AI blocks (or other source) and computes, asits output, the correct set point to be used by a controller block for the purpose ofcontrolling a ratio of the input parameters.

Table 1. Abbreviated Description of First Ten Fieldbus Function Blocks.

Fieldbus specifications call for a resource blockin each device. The purpose of the resourceblock is to retain information about the deviceitself. Required information includes:manufacturer ID, type of device and revisionlevel, memory size, free memory space, availablecomputational time, declaration of availablefeatures, and the state of the device, i.e.,initializing, on-line, standby, failure, etc. Thesedata must be stored in non-volatile memory. Amanufacturer may choose to add value byproviding additional data such as materials ofconstruction, calibration and repair records, andother useful information.

Though the user will have access to thisinformation, some of it may only be used byconfiguration tools or other utilities residing onthe host. However, the existence of this data in astandardized form provides a rich data base for

supporting various plant maintenance, inventory,and other operational programs.

The function block behavior described in Table 1indicates the purpose of each block, but there area number of essential behaviors not easilydescribed in a table. Examples in the followingsection will be used to better reveal thesecharacteristics and their significance.

A Systems PerspectiveTo this point we have described Fieldbus asconsisting of three primary components; thephysical layer, a communications stack, and thefunction block application. Without an overallperspective, it becomes increasingly tedious todiscuss further the many important details ofthese components. Fieldbus networks are controlsystems, so it is useful to look at Fieldbus in thecontext of a system. In this section we willdiscuss one continuous and one discrete control


application as a means of illustrating the mostimportant capabilities. A later section willelaborate on the major, specific functions andfeatures.

Continuous Control ProcessA common process application, and one whichillustrates many control system requirements, is asimple steam heater. The example we will use isa heat exchanger where steam is flowing througha coiled tube in an enclosed vessel. A processfluid is being pumped through the vessel and theobjective is to heatthis fluid to a precisetemperature. This isillustrated in theequipment schematicin the lower half ofFigure 9. In the upperhalf of Figure 9, ablock diagramdepicts the controlstrategy for thesystem.

Referring to theblock diagram, thesteam flowmeasurement isbrought into thenetwork by theAnalog In (AI) blockon the left. Thisvalue is linked to aPID block, which isthe flow controller.The flow controller isreceiving its SetPoint (SP) fromelsewhere (for now).The output of the flow PID is linked to anAnalog Out (AO) block which will manipulate anexternal physical variable, in this case the valve.

The valve will be manipulated as necessary toadjust steam flow to make it agree with the flowSP. Heat liberated by the steam in the tube coilwill raise the temperature of the process fluid.The fluid temperature measurement is broughtinto the network by the AI block on the right ofthe diagram. This value is linked to another PIDblock, which is the temperature controller. Thetemperature PID compares the measured processtemperature with the temperature SP and adjustssteam flow to achieve or hold the process

temperature at this SP. The output of thetemperature PID is used as the flow SP and islinked to the flow PID.

To summarize, the purpose of the flow controlloop is to maintain steam flow at a specifiedvalue regardless of variations in steam pressure.The purpose of the temperature control loop is toadjust the steam loop SP as needed to maintainthe specified process temperature regardless ofvariations in process flow or process inlettemperature.

This is a well known cascade control strategyused frequently in process control. Theequipment schematic illustrates the majorhardware components of the system and alsoshows a host console on the far left. This consoleis located where a human operator can observethe behavior of the system and make inputcommands such as setting the desired processtemperature and controller tuning parameters.The console may be several hundred feet fromthe process and is typically out of the plantenvironment. The schematic also shows the flowand temperature transmitters, valve, and console,all connected on a single bus.

Figure 9. Schematic and Block Diagram of System.

AI AIExternalProcess

PID AO

PID

Temp SP

Flow SP

Steam Flow

ProcessFluid


In traditional centralized systems, the flow andtemperature measurements would be transmittedto the host where the control strategy is executed.The desired valve corrections are thentransmitted back to the field. This is aFOUNDATION fieldbus installation so the controlstrategy shown in the block diagram will bedistributed across the network. In Fieldbus, thenetwork is the control system. The functions ofthe AI and AO blocks must reside in thetransmitters and valve, because this is where thenetwork meets the external world. We are free tolocate the remaining functions where it is mostadvantageous.

The AI block on the left is located in the flowtransmitter, the second AI block is located in thetemperature transmitter. The AO block is locatedin the valve. All other blocks required to achievethe control strategy may be located anywhere onthe network; in the host, the transmitters, thevalve, or an ancillary device not shown. In thisexample both PID blocks will be located in thevalve, we shall see why in a moment.

With Fieldbus, all devices on a network have acommon sense of time. Execution of functionblocks takes place on a precise schedule so thatthe blocks operate in a planned sequence, anddata is transmitted just in time for use. Thissynchronization eliminates the need for anti-aliasing filters between function blocks, whichwould otherwise reduce bandwidth by orders ofmagnitude (or, if filters are not employed, wouldresult in serious aliasing problems).

As mentioned earlier, communication betweendevices on the bus is controlled by one device onthe network through a mechanism called the LinkActive Scheduler, or LAS. The device whichcontains the LAS is called the Link Master.Usually this is the host device. The Fieldbusspecification also provides for redundant LinkMasters. In an application such as the example, itwould not be unreasonable to include aredundant LAS in the valve, or in a fieldmounted auxiliary device. This would permitcontinued operation of the control system in theevent that the host failed or became temporarilydisconnected. During such an event, the only losswould be the operator’s view of the process.

To more completely describe interaction betweencommunications and function block execution, atiming diagram is presented in Figure 10. A listof the function blocks is shown on the verticalleft axis. The horizontal axis is time. Executionof the function blocks is illustrated by a smallrectangular icon. The thick, dotted vertical linesrepresent instances when scheduled data arebeing transmitted on the bus.

To explain the sequence we will start with theexecution of the AI block in the flow transmitter.The LAS has the function block executionschedule and causes the flow data to bepublished on the bus just after fresh databecomes available. Any device needing the flowdata will have been configured to subscribe asthe data appears. In this case, the host may ormay not subscribe for various reasons. The valvewill need to subscribe because the flow PIDrequires the information.

After the flow data is published, the functionblock schedule (which resides in the device) willcall for the flow PID to execute. The result of thePID calculation is passed immediately to the AOblock, which is also in the valve, and at that timethe AO block will be scheduled to execute.Execution of the AO block will result in anupdate of the signal to the valve Positioner(servo), outside the bus.

For this example, the entire flow controlsequence is repeated every 200 milliseconds, orfive times per second. Each execution of the flowcontrol loop requires only one transmission ofdata on the bus, and no deadtime is accumulatedwhile data is passed from buffer to buffer insome remote, centralized host system.

Execution of the temperature AI block is shownon the third row of the diagram. In this example,it has been scheduled to execute prior to the flowAI block. The temperature process value (PV)has been scheduled to publish at about the sametime as the flow AI block executes. Since blockexecution occurs entirely within a device, there isno conflict with these events occurringsimultaneously. As before, devices that are usersof the data will have been configured tosubscribe. Again in this example it is the valve,or more precisely, the PID block in the valvepositioner.


The temperature PID will be scheduled toexecute and will then immediately pass its outputvalue to the flow PID to serve as its new flow SP.As shown, this occurs just prior to the flow databeing published. The flow PID will thus have themost current SP information possible.

Since thermal lags in the system maketemperature a more slowly changing variable, wehave elected to execute the temperature sequenceonly every 600 milliseconds, or every 1.67second. This is the slowest scheduled sequenceon this bus segment, so this is called themacrocycle. The schedules in this example areillustrative only. Fieldbus function blocks andpublisher/subscriber communications areconfigured to meet the dynamic requirements ofthe application.

The scheduled communications shown inFigure 10 occur at specific times in themacrocycle. In this example, only a few percentof the total available bus bandwidth is scheduled.In heavily loaded configurations, as much as 20percent of the bus time may be scheduled forcontrol communications. The remaining,unscheduled, time is used for networkmaintenance and other non-control requirements.

Examples are; operator commands such as setpoint changes, checks for new or missingdevices, and reports for alarms, which will bediscussed in next section.

a) Temperature Device FailureEarlier we mentioned that a redundant LAScould keep the system in operation in the eventsome conditions associated with field devicefailures.

Suppose that the thermocouple in this transmitterfailed. Ignoring the fact that this is a smartinstrument and could have redundant sensors, letus assume that it has a singe temperature probe.Obviously the transmitter can no longer publishcorrect process temperature values.

Parameters that are passed between functionblocks are called linked parameters. Every linkedparameter in Fieldbus contains a value, in thiscase temperature, and a status. Status indicatesthe quality of the value, which is either GOOD,UNCERTAIN, or BAD. Status also contains sub-status information giving added detail as to thegeneral status condition.

Figure 10. Timing Diagram for Cascade Example.

Publish FlowPublish Temp

Unscheduled Unscheduled

200 ms

Flow AI

Flow PID

Temp AI

Temp PID

Valve AO

Block Execution for: Flow LoopTemp Loop

ScheduledInternal TransferInternalTransfer

200 ms 200 ms 200 ms

600 ms


In this example, the value picked up by thetemperature controller will carry a status ofBAD, sub-status: Sensor Failure. Localintelligence will cause the temperature controllerto transition to Manual (MAN) mode. The outputwill remain at its last value and will be passed tothe flow controller. Normally, the steam loopcould then be controlled by manual adjustmentsto the temperature controller. Optionally, theBAD status indication can be propagated to theFlow controller causing it’s mode to go fromCascade (CAS) to Automatic (AUTO). It willthen continue to hold steam flow and willbecome receptive to operator applied Set Pointchanges.

Meanwhile, the AI block in the temperaturetransmitter will generate an Event Notification asa result of a Block Alarm. The Event Notificationis a message which contains the device tagnumber, the fact that there was a sensor failure,time-stamped to within 1/32 of a millisecond asto when the failure was detected, and otherrelevant information. This message will bebroadcast at the earliest opportunity short ofinterfering with the transmission of data used forcontrol. The message will be periodically re-sentuntil receipt is confirmed by the appropriateauthority. The same mechanism is used forprocess alarms and other “events”.

These actions all occur under the control of localintelligence, without the need for higher levels ofintervention. The host does not poll the devicefor alarm information. The message preparationand control mode changes are all done locally, asdefined in the Foundation Fieldbus Specification.

We have, in this example, illustrated someaspects of the power of distributed, parallelprocessors performing local functions andpassing high level information to the centralsystem.

b) Flow Device FailureAs a brief variation of the example, assume thatit is the flow device that fails. In this case theflow controller will get a flow value with thestatus of BAD; sub status, Sensor Failure. Itsmode will immediately go from Cascade (CAS)to Manual (MAN).

Information of this mode change is immediatelypropagated back to the temperature controllerwhich will then transition to the mode of IMAN.This is a manual mode in which the controller iscontinually looking downstream and initializingitself to be ready for resuming control whenconditions warrant.

What is different from the previous example isthat the flow controller now does not have theinformation needed to control flow. It willremain in MAN and allow (only) manual controlfrom an operator console. The temperaturecontroller, being in IMAN, will keep its outputaligned with the flow SP as part of its initializingprocedure. When the status of the flow valueagain becomes Good, the system will resumecontrol without bumps or discontinuities.

As an option, The BAD status may bepropagated forward to the AO block in the valve.If this option is selected, the AO block will holdthe last value for a pre-configured period of timeand then initiate fault-state (similar to fail-safe).Depending on the user’s selection, it will movethe valve open, closed, or hold last position. Allfailures automatically generate and transmit atime-stamped Event Notification, as was donepreviously in the temperature transmitterexample.

The example chosen for this discussion isrelatively simple. Alternative designs for thissystem could have employed transmitters withredundant sensors, and/or redundant transmitters,calculation functions, feedforward, modelpredictive and multi-variable controls and evenredundant controllers and valves. The sameprinciples would apply.

Two key points should be made regarding thepreceding discussion. In more complex controlstrategies involving; ratio controls, override withcontrol selectors,

♦ The behavior described is completelydefined in the Fieldbus User LayerApplication, which is an open specification.No other digital bus solution has an open,defined, User Layer specification.


♦ The behavior described is mandatory andcan be trusted to exist whether the devicesand host are supplied by one manufactureror several. Every Foundation registereddevice must support the behavior described,and must interoperate with any otherregistered device, and must have passed anautomated (interoperability) test to provethat it will.

The preceding examples do not provide acomprehensive explanation of all specifiedbehavior, but are intended to illustrate thegeneral level of the specifications.

c) Maintenance ConceptsWe will continue the failed transmitter exampleand discuss the maintenance activities that mightfollow such an occurrence. Using the temperaturetransmitter as an example; the device will beremoved from the process and transferred to amaintenance area, and a replacement will besupplied from inventory.

In the maintenance shop, the problem transmitterwill be connected to a test bus segment (separatefrom the process segment) and diagnosed.

Disposition of the instrument may be;

♦ Return to the factory♦ Dispose of the instrument♦ Repair device and move to inventory

If it is repaired and returned to inventory, or if areplacement device is purchased for inventory,the device may be momentarily or continuouslyconnected to another bus segment, separate fromthe process and maintenance segments.

The three host computers associated with theprocess, maintenance and inventory fieldbussegments are connected on a plant backbone,shown as an HSE segment in Figure 11. It is nowpossible for an enterprise management computer(not shown), to continuously track every devicein the plant, and to determine the currentcondition or usage of each device. Also, ifmaintenance is performed on the failedtransmitter, that information may be stored in thedevice and remain with it, but will be availableover the bus to a plant-wide maintenanceprogram.

The resource block in the User layer applicationof every Fieldbus device contains a manufacturer

ID, device type, device revision, DD revision andspecial features.

By specification, this data must be in a formatwhich is accessible and readable by any Fieldbusconformant interface device. The samemaintenance and inventory tracking system isthus equally applicable, without customprogramming, to all Fieldbus devicesindependent of manufacturer.

Figure 11. Device Tracking.

Process

Maintenance

Stores

H1

H1

H1

HSE


Discrete Control ExampleThis next example is presented not only toillustrate a discrete application, but to introduceseveral additional features of Fieldbus. Theapplication is a container filling operation wherebottles on a conveyor are sequentially parked at afilling tube, a valve is opened and closed to fillthe bottle, and then the conveyor is incrementedforward to position the next bottle for filling.Figure 12 schematically illustrates the process.

Numerical values will be used to better illustratethe nature of the problem, and the power of thesolution. We will assume that the bottles are tobe filled with 64 ounces of fluid and that the fillrate is nominally 32 oz/sec. Obviously, theaverage fill time is approximately two secondsplus the time required to increment the conveyor.

The control strategy is implemented in the threeblocks shown in Figure 13. The flow meter has atotalizing feature and uses a standard Analog In(AI) block. The on/off valve uses a standardDiscrete Out (DO) block to operate the valve,

and a unique Discrete Control (DC) block toprovide control.

Control of continuous processes depends oncontinuously changing control actions which are,in turn, based on precisely periodic calculations.

These are time dependant control applications.The synchronized, periodic communicationsunder the direction of the LAS were designed forthis requirement.

Discrete processes, on the other hand, tend to beevent driven. The required time to stop filling acontainer occurs when the desired amount offluid has been added. The LAS can notsynchronize the execution of a function blockwith an event that may occur at any instantthroughout the macrocycle−but Fieldbusprovides other tools that can.

If we were to execute the blocks in Figure 13exclusively on a time-based schedule, as wasdone in the steam heater example (recall Figures9 and 10), all three blocks would executeperiodically and in sequence at some configuredfrequency. In the heater example the flow loopexecuted five times per second, or every 200milliseconds. In the bottle filling application witha two second fill time, this gives a resolution ofonly one part in ten, or an error band of ±10%.

While we haven’t stated an accuracyrequirement, we will assume that ±10% isn’tsatisfactory. Increasing the execution rate(shortening the macrocycle) will improveaccuracy in direct proportion. At some point,however, the execution rate will be limited by thehardware, and probably before adequate control(in this example) is achieved.

Fieldbus actually defines three ways to schedulefunction block execution, only one is preciselyby the clock. A second method is that a blockmay execute in response to the execution of aconnected block, and the third method ismanufacturer specific. We will use all three.

Figure 12. Discrete Process.

Meter withTotalizer

On/OffValve

H1Bus

64 ozBottles

Sudz SudzSudz

Conveyer

Figure 13. Control Strategy.

AI DC DO

Resides inFlow Meter

Reside inOn/Off Valve

StandardBlock

ManufacturerSpecific Block

StandardBlock


The flow meter will run on a time schedule,periodically publishing under control of the LASevery 200 milliseconds. At the start of a fill cyclethe DC will record the start time. The DC willthen receive periodic values of total flow overthe bus, from the meter. For every new data pointthe DC will forecast (calculate) a future time, tx,when the bottle is projected to be full. Figure 14illustrates a series of measurements over one fillcycle.

The DC will continuously compare the currenttime to the current forecast of tx., and send achange state signal to the DO when tx is reached.The DO will immediately execute in response,causing the valve to close. With this technique aresolution of less than one millisecond is easilyachieved, which contributes to an error of lessthan ±0.05%.

Once the valve is closed, the next total flow datapoint will tell the DC exactly how much fluidwent into the bottle. Any error will be used tocreate a compensation factor for latency in valveclosure and other lags, and will be included inthe calculation of tx for the next fill cycle. Theoverall accuracy is determined by the consistencyof the latency period, and the accuracy of thetotal flow meter.

The DC is executing on a manufacturer specificschedule which, in this case, is to calculate txupon receiving each new total flow value and toinitiate action via an interrupt when current timeequals tx. The DC does not use the bus forsending information because its output goesdirectly to the DO block located in the samedevice. It does, however, subscribe to the totalflow value, which is being published by the flowmeter every 200 milliseconds.

There are three key points in this example. First,the valve can be actuated at any point in time, itsexecution is decoupled from the LASmacrocycle. Second, the valve communicateswith other devices on the network, such as theflow meter, using standard function blocks, andunder control of the LAS. Third, all standardFieldbus behaviors for mode, status and alarmsare observed. Any unique parameters needed byan operator to use the manufacturer specific DCblock will be accessible by hosts via DeviceDescription technology discussed in thefollowing section.

There are some additional overhead tasks. Forexample, after a small delay following closingthe valve, the DC will send a switch signal to asecond DO (not shown) which will be used toincrement the conveyor line and get a new bottlein position. Once the new bottle is in position,the conveyor will provide a switch closure whichwill be read into the DC through a DI block (alsonot shown) to start the next fill cycle.

By making use of local intelligence, i.e., atotalizer in the flow meter and a discretecontroller in the valve, the control system avoidsthe traditional requirement of very high data ratescommunicating with a centralized computer toachieve high speed, discrete control. Four suchbottle filling stations could be handled on one H1Fieldbus segment, and many segments can bemanaged by a simple PC based operator station.

Figure 14. Control Algorithm.

64

Time 200 ms t x

TotalFlow(oz)


Device DescriptionsFrom the earlier discussions on function blocks,mode, alarms, etc., it may appear that if thefunctionality of Fieldbus products is so tightlyspecified that distinctions among differentmanufacturer’s products could be severelyrestricted. It could seem that futureimprovements and innovations might simply belocked out because the Fieldbus specificationscould not comprehend all possible variations andfuture developments.

That is not an unreasonable first expectation; andit would be correct, were it not for the use ofDevice Description technology. The fieldbusspecifications provide for a formal, C-likeprogramming language called DeviceDescription Language (DDL). Using DDL, adevice developer will prepare a DeviceDescription (DD) for all parameters and otherfunctions in the device.

The device’s DD is readable and interpreted by aFieldbus specified utility called DD Services.The DD contains information necessary to allowa host using DD Services to communicate withany special parameters or features that amanufacture may choose to incorporate.

a) DD ExampleAs an example, valve manufacturers find it usefulto accumulate the total distance a valve stem hastraveled against it’s packing seal. Fieldbus has nospecified parameters that even relate to thissubject. However, each manufacturer uses thistype of information in its own proprietary wayand if a manufacturer wishes to make somespecial parameter available to users, it can beaccomplished by defining it in the Device DD.

To use a simple illustration, suppose a valvesupplier names a parameter WIDX (Wear Index),and wants users to be able to access its value.The Fieldbus protocol supports a “Tag-Dot-Parameter” search service, where Tag is a device(or block) identifier and Parameter is the nameof the parameter in question. This service, inconjunction with the DD technology, will allow auser to type in FCV423.WIDX, for Flow Controlvalve No. 423, and get a display of the value ofthe parameter, WIDX, with engineering units anddisplayed to whatever number of decimal placesthe DD specifies.

As illustrated in Figure 15, the parameter requestis made at a host console. The Fieldbuscommunication services automatically locate thedevice and parameter, and read the value. Thehost uses DD Services to interpret the meaning ofthe parameter from the DD file for that device. It

is not necessary for the user to know the busaddress of the device, only the tag number andparameter name. Custom programming is notrequired of the host system to facilitate access tothe new, non-standard parameter. Otherprograms in the host can use the same accesscalls to exploit this feature in any way that thehost designers perceive as useful.

It is easy to design-in other useful capabilities bythe use of DDs. Valve suppliers are interested intotal run time, travel distance, number ofreversals, number of starts, number of trips, and

WIDX= 37.52 km

Type: FCV423.WIDX

DD

The parameter value is read over the bus

The parameter meaning is contained in the DD

The DD isinterpreted byDD Servicesin the Host

Figure 15. Custom Parameter Search.


statistical analysis of these measurements.Transmitter suppliers consider multiple sensors,and performance enhancing filters, and allsuppliers are interested in improved diagnosticcapabilities. Each supplier is free to develop suchfeatures, and yet remain interoperable becausewith DD technology, these manufacturer specificparameters are as easily accessed as are standardparameters.

The DD for manufacturer specific parameters,like the example WIDX, are merely extensions ofthe standard DD and are otherwise handled in thesame way as standard parameters.

To be Fieldbus conformant, a host system must,directly or indirectly, incorporate DD Services(or an equivalent technology). In addition, everyregistered field device must have a registeredDD. Each device’s DD is supplied to the hostsystem. Device DD libraries are available fromthe Foundation on CD-ROM and on-line, andindividual DDs are provided by the devicesupplier.

b) Menus and MethodsAnother (optional) feature of DD technology isthe ability to incorporate small programs within aDD. An example application would be to providean interactive dialog session which guides anoperator or technician through the calibrationprocedure for the device. Such programs arecalled methods. A device’s DD may contain oneor more methods, each of which is initiated froma menu. An operator simply selects the desiredmethod from the menu and initiates it, specialprogramming is not required.

c) Device ProgramsTwo additional capabilities which are specifiedby Fieldbus, though optional, are programdownload and program invocation. Thedownload capability provides a mechanismwherein field devices may receive an upgrade tothe device firmware remotely over the bus. Thismay be useful for version upgrades or otherchanges in functionality. Program invocation

services permit a host to control the execution ofa program within the device itself. This can meeta variety of needs, but the primary application isto perform complex internal diagnostics.

ConfigurationThe procedure for putting an individual device inthe desired state for use is called deviceconfiguration, or by some manufacturers,commissioning. It includes setting all defaultparameter values such as alarm limits, mode,filter values, controller tuning parameters, setpoints, and more. The procedure for setting upthe communication connections between multipledevices on a bus segment is called busconfiguration, or commissioning. This includesproviding each device with the data needed toestablish the required links between functionblocks, setting the communication schedules, andmore.

Devices may be configured on-line with thedevices on a live bus segment, using an on-lineconfiguration tool. On-line configuratorscommunicate with individual devices over thebus, reading information about the device’saddress, what function blocks the device has, theaddresses of its function blocks, function blockexecution time, and literally hundreds of otherparameters, all required to make systems such asthe examples described earlier, work asdescribed. The configurator will also use DDs toobtain the information needed for non-standardparameters.

There are also off-line configurators that performthe same function, but without a live bus. Theindividual device information is read by theconfigurator from special files designed toprovide the exact same information as would beobtained from the device itself. In order thatdevices from multiple manufacturers can beconfigured with a single configuration tool,Foundation Fieldbus specification FF-103defines the format and design of these files,which are called the Common File Format (CFF).


On-line configuration is performed with anon-line configurator using the actual devices andthe DDs for those devices. Off-line configurationis performed with an off-line configurator and theDDs and CFFs for the devices. If configuration isdone off-line, the configuration must at somepoint be loaded into the devices. This could be

done during system integration, or deviceinstallation.

Host consoles generally provide one or bothmethods of configuration. There are alsoPC-based configuration tools available fromvarious suppliers.

FIELDBUS DEVICE CONFIGURATIONMODEL # LoneStarInst DP35426TAG No FT550INSTRUMENT ID LSI 7584936228FB ID N02 AA08 DA01DD ID LSI12-45LOC REBOILER 01DESC STEAM FLOW 1CONFIG ID REBOIL01_HEAT_ FLOW

CONFIGURATION RECORDLAST CONFIGURED: 00/11/18 LAST CALIBRATED: 00/07/12NEXT SCHEDULED: 01/07/12

Feed

FT

FC

LT

¹P PC

QC

QA

FT

PC

FT

DP CS

QA550

496 496 496

338LT

LFC439

LCT322 LC

FT339

QC550

550

ProcessMonitoring

and Operation

Configuration and Maintenance of Fieldbus and Devices

D/P Transmitterby manufacturer “C”

Control Valveby manufacturer “D”

Operator’s Consoleby manufacturer “B”

Maintenance Consoleby manufacturer “A”

Implementing the Control Strategy over the Fieldbus

FIELDBUS DEVICE

CONFIGURATION

MODEL # LoneStarInst

DP35426TAG No. FT550

INSTRUMENT ID LSI

7584936228

FB ID N0. 2 AA08 DA01

DD ID LSI12-45

LOC REBOILER 01

DESC STEAM FLOW 1

CONFIG ID

REBOIL01_HEAT_ FLOW

CONFIGURATION RECORD

LAST CONFIGURED: 98/02/18

LAST CALIBRATED: 98/07/12

NEXT SCHEDULED: 99/07/12

FTFC

LT

¹PPC

Q

C

Q

A

FT

PC

FT

DP CS

QA55

0

49

6

49

6

49

6338LT

LF C439

LCT322 LC

FT339

Q

C550

550

Feed

Figure 16. System Illustrating Multiple Aspects of Interoperability.


Viewpoint from the ConsoleFigure 16 shows several important characteristicsof a Fieldbus control system. It illustrates amaintenance console from manufacturer “A”which displays data from the transmitter ofmanufacturer “C”. This is data permanentlystored in the resource block of the transmitterand is readily accessible by any conformant hostdevice.

The Process Monitor from manufacturer “B”shows a display of the operating unit. Processvalues, alarms, and other data are all dynamicallyincluded on this display. The data are obtainedover the bus from devices of manufacturers “C”,“D”, and others (not shown).

Constantly changing, dynamic data may beacquired as individual points, or more efficientlyas data blocks. Relatively constant, static datamay be acquired only when a change hasoccurred. Fieldbus communications are designedto efficiently provide the currently requireddisplay data with a minimum of bus traffic. Thefollowing sub-sections on Trends and Views, anda later section on communications, will elaborateon how this is achieved.

Figure 16 illustrates three essential aspects ofinteroperability. 1) Devices from differentmanufacturers must communicate with eachother. This is accomplished with a standardcommunications protocol and enforced withconformance testing, 2) Manufacturer specific(custom) parameters must be accessible bydevices from other manufacturers. This isaccomplished with DD technology, as shown inthe previous example. 3) The control strategy isopen, and implemented among multiple deviceson the network. This is accomplished with anopen, published specification for the functionblock application, enforced with interoperabilitytesting, and illustrated in the previous examplesof continuous and batch control.

d) Access PrivilegesEach Fieldbus function block contains aparameter called GRANT_DENY. This is a bitstring parameter which is set by the user of theFieldbus system. Host devices are programmedto interpret this bit string so that specificconsoles have or do not have access to variousparameters within the given block. This provides

a flexible method for end users to control the useof various consoles on the system.

e) TrendsFieldbus provides several features whichfacilitate systems such as shown in Figure 16.One of these is called Trend. A trend provides ashort term historical record of parameter valuessampled at some multiple of the block executionrate. The trend is stored within the field deviceand may be efficiently accessed by host consolesor temporary maintenance tools. Trends may alsobe automatically reported using a ReportDistribution8 when a new set of data is collected.A total of the last 16 values and the associatedstatus are maintained by the trend. The time ofthe last sample is also maintained.

Trends are configured by the user and anyfunction block input or output parameter may betrended. This includes analog and discreteparameters and bit strings. Trends provide anefficient way to update the display screens onsystem consoles such as shown in Figure 16.

f) ViewsAnother method of efficiently providing updateinformation to console screens is through the useof views. While trends transmit recent historicaldata on selected individual parameters, viewstransmit the current information for groups ofparameters. Four specific parameters groupshave been defined in the Foundationspecifications for the first four views, other viewsmay be defined by users.

Views 1 and 3 contain all the dynamicparameters in a function block. Dynamicparameters are defined as those whose value isdetermined by the execution of the block. Thedynamic parameters of an AI block, for example,include; the process variable (PV), the blockoutput (OUT), a parameter that describes blockerrors, an alarm summary parameter, and aparameter giving the actual target, permitted andnormal modes9 of the block. There are a total of12 dynamic parameters in an AI block.Views 2 and 4 contain all the static parameters ina function block. Static parameters are generallyconfigured or written to the device over the bus 8 Report Distribution is one of threecommunication relationships used in Fieldbusand is discussed in a later section.9 Mode is discussed later in section; e) Mode.


and normally change infrequently. Examples ofstatic parameters include process alarm limits,scaling data, option selections, filter values,controller tuning parameters, etc.. There are atotal of 24 static parameters in an AI block.

All four defined views contain a parameter calledStatic Revision (ST_REV). The value of thisparameter is incremented if, and only if, anystatic parameter is changed.

Views are not automatically transmitted, butmust be read (using standard services) by thedevice wanting the information. It is thus up tothe designer of the display screens to decide howmuch and how often views need to be read tosupport the desired displays. The mechanism justdescribed relieves the host of unnecessarilyreading hundreds of static parameters on atypical bus segment, without missing changeswhen they do occur.

A change in the static revision parameter also iscalled an “event”, which is treated the same as analarm as described in the following section.

g) Alarms, Alerts and EventsAnyone familiar with process controlapplications will recognize the term processalarm. These represent limits on the processvariable (PV) which, if exceeded, require that ahuman operator be alerted to the situation. TheAI, DI and PID blocks in Fieldbus all haveprocess alarms. There are other conditions thatcan occur in a control system which should alsoresult in alerting a human operator. In Fieldbus,these conditions are called either alarms orevents; both of which are referred to as alerts.Regardless of the cause, alerts are all handled ina standardized way, though there are differencesin some of the details.

Referring to Figure 17, the bottom of the diagramshows the three causes for the generation ofalerts. They are block errors, process alarms, andstatic revisions. These alarm/event conditions allhave a common set of data, as shown in the nextblock up in the diagram. For example, all will betime stamped at the time the alert is first

detected. All will contain information about thestate of the alarm condition, and theacknowledgment status.

A program running within the function blockapplication, called the Alert Notifier, examinesthe alarm and event parameters and, if an alertstate exists, builds a more complete set of dataincluding address information, manufacturer typeand several other details. This is stored in a dataset called the alert object. The Alert Notifier alsobuilds a report message, called the eventnotification message. Event notifications arebroadcast on the bus at the earliest opportunityshort of interfering with the requirements forcontrol communications.

AlertObject Alert Notifier Adds

Block Index Mfg, Type Alarm Type Etc.

BlockError

ProcessAlarm

StaticRev

Alarm/Event Acknowledgement Status Alarm State Time Stamp Value

Bus

Alerts

Figure 17. Alert Handling Mechanism.


The alert notifier alleviates the need for higherlevel devices to poll each field control device todetermine if an alert condition exists. It alsorelieves the function block from the overhead ofevent notification processing, so that executionschedules are not affected when an alert occurs.

An event notification is a comprehensivemessage describing the cause of the alert, a timestamp of when the alert was first detected, anindication of priority, a listing of block index,manufacturer type and other details.

In the case of multiple active alerts, the highestpriority will be broadcast first. In the case ofequal priority, notifications will be sent in orderof age.

An alert results when either an alarm state isentered, or when it is left. An event notification issent to the Host in both cases. The alert notifierrequires confirmation from an interface devicethat the event notifications has actually beenreceived. The complete sequence for a normalprocess alarm is illustrated in Figure 18.

The example in Figure 18 starts with an initialcondition of no alarm being active. Step 2indicates the process has entered an alarm state.Steps 3, 4 and 5 have been described in theprevious paragraphs. At step 5, after the eventnotification has been sent, the alert notifier waitsfor confirmation that a host has received themessage. If confirmation is not received after aperiod corresponding to the value in theparameter CONFIRM_TIME, the message willbe sent again.

The alert notifier will continue re-sending on thisschedule until confirmation is received. Step 9indicates that the process condition has returnedto normal, or at least within the alarm limits. Thisresults in a repetition of the notificationprocedure, and another requirement forconfirmation.

Step 15 introduces a requirement not previouslymentioned; acknowledgment by a humanoperator. Although this is shown as the last stepin the sequence, it can occur any at time theoperator becomes aware of the alarm. Mostlikely, soon after step 6. All confirmations andthe acknowledgment must occur to get back tothe Alarm Clear state.

The example sequence in Figure 18 assumes thatwhile the alarm is active, priorities do notchange, the block does not go to the O/S mode,and the alarm is not disabled. For acomprehensive description of the alert processingstate machine, refer to Part 1, Section 4.6 of thespecifications.

For all function blocks having process alarms,there is a parameter that provides an alarmsummary. This contains the current alert status,plus an indication of which alarms have or have

Conditionsnormal

PV exceeds limits

Alert notifier buildsmessage & sends

Alarm confirmedby host application

Time passes...

PV returnsto normal

Alert notifier buildsmessage & sends

Alarm clear confirmedby host application

Alarm acknowledgedby human operator

Alarm clear,reported & ack

Alarm active,unreported

Alarm active,message sent

Alarm active& reported

Alarm clear,unreported

Alarm clear,message sent

Alarm clear, reported, not ack

Alarm clear,reported & ack

1

3

4

5

6

7

8

9

10

11

12

13

14

15

16

2

ALERT STATEACTIVITY

Figure 18. Alarm Handling.


not been reported; acknowledged, and/ordisabled (and a method of disabling). It isupdated upon every execution of the block. Asecond parameter sets an option to determinewhether event notifications will be automaticallyacknowledged or require operator action.

There are multiple levels of process alarms. If thePV exceeds any of these, the correspondingalarm parameter, will become active. Included inthat parameter is the value that exceeded thealarm limit. There is also a correspondingparameter that will contain a user assignedpriority from 0 to 15. A priority of eight orhigher is regarded as critical. Priority less thaneight is advisory. If the priority is zero, the alarmis suppressed. If the priority is one, the alarm willbe set, but a report (event notification) will notbe generated.

In the previous section we discussed thecommunication and content of Views and howstatic parameters, which seldom change, may beautomatically transmitted only when a changehas occurred. A Static Revision is called anevent, and is indicated by the UPDATE_EVTparameter. Included in the parameter is a valuethat represents the current revision level. Thismakes it easy for a Host application to detect achange and provide automatic acknowledgment.An event is also an alert, and is processed likeany other alert, see Figure 17. The event has afixed priority of two.

After process alarms and events, the third sourceof alerts arises from function block behavior. If acondition develops that could interfere with theproper execution of a function block, it mostlikely warrants attention from a human operator.In Fieldbus, there are 16 possible block errors.These include such conditions as; configurationerrors, memory failures, link errors, etc. Blockalarms also have a fixed priority of two. Includedin the block alarm parameter is a value thatindicates which block error is the cause of thealarm.

The occurrence of block errors and thesubsequent generation of an alert does notautomatically interrupt control or otherwise

intervene in loop behavior. The purpose of analert is generally to warn an operator so thatappropriate action can be taken. It is possible,however, that the event that caused a block errorcould itself disrupt control.

This will certainly lead to an event notification asdescribed above. Depending on the problem, it isalso likely that the mode of the affected blockand others will transition to manual or out-of-service. But this is a result of the mode machine,not the alert handling procedure. Alerts do notdirectly affect block execution or systembehavior. To review the specifications, seeFunction Block Part 1, Section 4.4.3.6 .

h) ModeAll function blocks have a mode parameter,which determines which inputs the block willoperate on, and which outputs the block willgenerate from its internal algorithm. All blocksmust support Out of Service (O/S) and, to beuseful, at least one additional mode. Figure 19gives a table of modes required of the most basicfive Fieldbus function blocks.

In the O/S mode, the block is executing but it isnot calculating an output. The last column inFigure 19 describes how the output of eachfunction block is generated, depending on theblock’s mode. Local Override (LO) is a modecaused by conditions within the device.Specifically, a fault-state condition or aninterlock condition. In LO, the block iscalculating an output based on information otherthan the input value. Initialize Manual (IMan) isa manual mode used to initialize a block’s outputvalue during a transition to a control condition.

The appearance of the Cas mode for the DO andAO blocks may surprise readers new to Fieldbus.These are both output blocks and the perspectiveis that they are controlling a final controlelement, such as a valve. The valve position isviewed as a local process variable (PV), and thedesired value for that PV is indicated by a setpoint (SP). The DO and AO blocks areconsequently treated as the secondary orsubordinate controller in a cascade controlstructure, thus the normal mode is Cas.


The FOUNDATION fieldbus specificationdescribes four mode categories; target, actual,

permitted and normal. The target mode is thedesired mode, typically Cas for an output blockand Cas or Auto for a control block. The targetmode may be set by a human operator or by anapplication. The actual mode is the one beingused by the block at any given moment. Forexample, the target mode of the temperature PIDcontroller in the cascade control example (seeFigure 9) would be Auto. When the upstream(temperature) transmitter failed, the PV signalcarried a status of bad, which caused thecontroller to transition to Man. However thetarget mode would remained Auto, and when thefault condition clears, the controller willtransition back to Auto.

Permitted modes are those that can be used astarget modes. For example, the AO blocksupports five modes. Because of a specificapplication requirement, a user may wish toprevent use of, for example, the Auto mode forthis block. Accordingly, the user can configurethe block to permit only RCas, Cas, OS and Manas target modes.

Normal is the mode that should be expected innormal operation. It is defined and read by aninterface device for operator information, but is

not used by the blockalgorithm.

After calibration at thefactory, the target mode of ablock must be O/S forshipping. Target mode is anon-volatile parameter soupon power-up the targetmode will always be what itwas at power-down. Afterbeing configured for anapplication, the target modeshould be set to whatever isappropriate for theapplication. On subsequentpower-up, the target modewill remain unlessspecifically changed by anoperator or an application.Figure 19 also indicates theusual target modes for thefive basic blocks.

Communications Most of the fieldbus behavior and characteristicswhich we have been discussing are provided bythe Function Block Application. However, forthe application to perform as specified, it musthave the support of a set of communicationservices which are specified in: FF-801, FF-822,FF-870, FF-875, and FF-880. These, as is thecase for the Function Block Application, areopen specifications maintained and published bythe Fieldbus Foundation. The most fundamentalfeatures of the communication stack will bedescribed here.

Communication between function blocks forcontrol purposes was described earlier as beingjust in time (for function block consumption).Control is not the only communicationrequirement. The Link Active Scheduler (LAS) isresponsible for controlling all communications.The governing mechanism to achieve this controlis called a delegated token. To communicate onthe bus, a device must have received a specialmessage called a token.

Figure 19. Function Block Mode chart.

Mode DI DO AI AO PID Output is Generated By:

Indicates required modeIndicates usual target mode

or

O/SLast calculated value withstatus of bad

LODO & AO: fault state or external event, PID: tracking

IMan Internal initialization

Directly written by humanMan

Auto Algorithm processing input(s)

RCas Algorithm processing input(s)

ROutOutput directly written bya supervisory computer

Cas Algorithm processing input(s)


Token passing is a widely used method forcontrolling communications on a bus. In somedesigns the token circulates from device todevice, in other cases it may shuttle between amaster and various slaves. Techniques fordetermining token hold time also vary, but tokenpassing protocols are often criticized for notbeing able to assure that transfers of time criticaldata occur when they should. For continuouscontrol, data transfers at precise points in timeare essential, a characteristic sometimes calleddeterminism.

The Fieldbus tokens do not grant unlimitedcommunication rights. Tokens delegate veryspecific instructions of either what is to becommunicated, or how long communication maytake place. In either case, the right of a device touse the network is defined and limited.

The LAS operates with three priorities. The firstis to assure that communication for controloccurs at precisely scheduled points in time; thiswas discussed in the steam heater example. Thesecond priority provides for bus maintenance.This consists primarily of periodicallydistributing time to devices on the network forsynchronization of device clocks, and ofdetermining what devices are presently on thenetwork (because devices can be dynamicallyadded or removed). The third priority is to allowdevices to communicate to each other forwhatever purpose may have arisen, sendingEvent Notifications, for example.

The basic algorithm used by the LAS is shown inFigure 20. The logic shown is an implementationof the priorities described above. The LAS sendstokens with one of three basic instructions whichare: Compel Data (CD), Probe Node (PN) andPass Token (PT). The LAS also broadcasts alimited set of messages, such as TimeDistribution (TD), which do not authorize thereceiver to respond. When it is time for controldata to be sent, the LAS will send a CD to theappropriate device and to the specific block andbuffer within that block. This instruction requiresimmediate publication of the data and permits noother response. This is a very short, timebounded message.

During bus maintenance the LAS will broadcasta TD, which is concurrently read by all devices.Each device, under its own local control, willcompare its internal clock reading with the new

time value. For H1 devices, clocks will be resetto maintain accuracy within 1 millisecond.(A good design feature will also cause the deviceto make a small hardware adjustment whichimproves accuracy on every reset occurrence. )

The Fieldbus specification provides a maximumof 256 addresses on an individual bus segment.Sixteen of these are restricted to special functionssuch as group addressing, and will not be

considered here. Four more are for temporarydevices, such as “hand held” maintenance tools.Another four are reserved as default addresses,discussed further below. This leaves 232addresses available for field devices. The actualnumber required is normally much less, and thenumber to be used in a given application isconfigurable.

When a device is configured for use on thenetwork, it will be assigned an address which isretained in non-volatile memory (NVM).Hardwired addressing is not permitted.The LAS maintains a list, called the live list, ofall active devices on the network. It does this bysequentially sending a PN to every valid(configured), unused address on the network.When a newly attached device receives a PN, it

Figure 20. Algorithm for LAS.

Wait untilit

is time toissue the

CD

Issue TD or PN

Issue PT

Isthere

time to dosomething before

next CD?

Ismaintenanceup-to-date

?

Yes

Yes

No

No


is required to return a short, defined messagecalled a Probe Response (PR). The LAS willthen initiate an identification sequence todetermine the device ID, Tag number, and otherinformation about the new device.

If the new device has not been configured withan address, it will use its own intelligence toselect one of the default addresses mentionedabove. The LAS will probe the default addressesand proceed with the same identificationsequence when a device is found. If the newdevice has been configured with an address thatduplicates an address already in use, it will notget a PN, since that address is for a devicealready on the live list. At some point, however,it will receive a Pass Token (PT) intended for theoriginal addressee. The new device will detect amiss-match of certain other information in the PTand will re-assign itself to a default address. Thisis one reason why hard wired device addressesare not permitted.

Each device on the live list will periodicallyreceive a PT. If the device does not return aresponse to the LAS, the device will be removedfrom the live list after three failed attempts. TheLAS will then broadcast a Live List Update to beread and used by any redundant LAS devices onthe network.

The LAS uses the CD, TD, and PN to causespecific actions to occur under control of theLAS itself. In sending a PT to a device, it isgiving the device an opportunity to communicatemessages under control of the device itself. Withthe PT comes a value called the maximum holdtime. So, although the LAS delegates control ofwhat the device may communicate, it retainscontrol of how long the device can use the bus.The LAS thus maintains determinism, and canassure that the precise schedule required forcontrol data is maintained.

Upon receiving the PT, a device may use asmuch or as little of its maximum hold time as itneeds, but not more. If it has no need, it willreturn the PT immediately and the LAS can usethe time for something else. If the device needsmore time, it will return the PT at the end of themaximum hold time with a request for more time.The LAS can grant additional PTs to the device,based on a time usage algorithm not discussedhere.

Devices use the bus time granted by a PT toreport alarms and other Event Notifications,exchange Read/Write messages with humans,communicate diagnostic information and answerrequests from operators or other devices. Whilethe PT grants the device control of what tocommunicate, the LAS can influence what thedevice chooses by providing a priority within thePT. For example, to indicate that alarms are to bereported before answering an operator’s requestfor the device model number.

The communications between fieldbus devicesall fall into three classifications. The methodused in transmitting data for control purposes iscalled Publisher/Subscriber. In this model, thedata to be sent is buffered, meaning the mostcurrent data will be transmitted and any olderdata is overwritten. Data required for controlmust be transmitted at precise intervals and sotransmission is scheduled. There is norequirement (or opportunity) for the receiver toconfirm that data is correctly received. If a datapoint is missed, the value is immediately staleand the system will need to rely on the previousvalue until a future value is transmitted. Finally,the data is broadcast on the network from asingle source to any device needing the data,one-to-many.

The second category was illustrated in the earlierexample of a thermocouple failure where a blockalarm was generated. This is called a ReportDistribution and provides somewhat differentfeatures. The data to be sent is queued rather thanbuffered. This means that if a series of values ormessages are created, none are discarded. Theywill each be sent in turn as time is available. It isimportant that such messages to be transmittedwith urgency. This is best accomplished bysending them at the earliest opportunity after theoccurrence of the underlying event, rather thanon a scheduled basis. It is also important that themessage is correctly received. This is assured byrequiring that the appropriate recipient confirmreceipt by sending a return confirmationmessage. Otherwise, the original transmissionwill be periodically re-transmitted. Reports areinitiated by the sender and are transmitted as aone-to-many message similarly toPublisher/Subscriber.

The third classification of communications isillustrated by an operator at a host devicechanging the value of a parameter in a field


device, such as a set point or tuning parameter.This model is called Client/Server. The values ormessages are queued, so each will be transmittedin its turn. They are transmitted in theunscheduled time during a macrocycle.Re-transmission by the sending device will berepeated until a confirmation message is receivedfrom the recipient. This exchange is between onespecific device and another, thus it is a one-to-one communication relationship.

The three communication relationships aresummarized in Figure 21. Regardless of thecommunication type, all transmitted messagescontain a 16-bit frame control field similar to acyclic redundancy check. For continuous H1communications this results in a theoretical errorrate of less than one undetected error in 21years.

CommunicationRelationship

Publisher/Subscriber ReportDistribution

Client/Server

Characteristics Buffered,network initiated,scheduled,unconfirmed,one-to-many.

Queued,user initiated,unscheduled,confirmed,one-to-many.

Queued,user initiated,unscheduled,confirmed,one-to-one.

Example Uses Continuous, real-timecontrol.

Process alarms,block alarms,trends, and otherevents.

Operator access such as set pointand tuning changes, alarmmanagement, access displayviews, remote diagnostics.

Figure 21. Characteristics and Example Uses of Communication Relationships.

High Speed Ethernet (HSE)The preceding descriptions and examples havefocussed on the characteristics of H1 Fieldbusbehavior. As explained in the Backgroundsection at the beginning of this Primer, a higherspeed physical layer specification was alwaysintended for selected process applications and forfactory (discrete parts) automation. The originalhigh speed solution, called H2, was to consist ofthe identical protocol and function blockapplication running on different media at either1 Mbit or 2.5 Mbit per second.

In March of 1998, the Foundation Board ofDirectors re-directed the high speed solution, andterminated further work on H2. The newapproach would be based on Ethernet and was toutilize, as much as possible, commerciallyavailable, off-the-shelf technology.

The new solution is called HSE, for High SpeedEthernet, and is designed to integrate multipleprotocols, including multiple H1 Foundationfieldbus segments as well as foreign protocols.The connectivity capabilities of HSE aredescribed in the following section.

a) What HSE DoesThe network in Figure 22 shows a Host Systemoperating on an HSE bus segment labeledSegment A. It is shown communicating throughan Ethernet switch to two H1 segments, a secondHSE segment, and to a segment running a foreignprotocol such as Modbus.

Any of the devices connected to the switch mayattempt communication to any other device and itis the function of the switch to provide thecorrect routing and to negotiate transmissionwithout collisions.

The connecting mechanism between HSE and H1segments is called a Linking Device (LD). Atypical LD will serve multiple H1 segments,though for simplicity only one segment per LD isshown in Figure 22. The connection betweenHSE and a foreign protocol is through an I/Ogateway. The capabilities of the network shownare as follows.

A ⇔=B and A ⇔=C The HSE host interacts witha standard H1 device through a Linking Device.In this situation the HSE host is able to


configure, diagnose, and publish and subscribedata to or from the H1 device.

A ⇔ D The HSE host interacts with an HSEdevice. In this situation the HSE host is able toconfigure, diagnose, and publish and subscribedata to or from the HSE device.

B ⇔ C In this situation, the interaction isbetween two H1 devices on two distinct H1 bussegments. The segments are connected to theEthernet with Linking Devices. Communicationsbetween devices on Segments B and C arefunctionally equivalent to communicationsbetween two H1 devices on the same bussegment.A ⇔ E This connection defines the relationshipbetween a foreign device and the Foundationfieldbus application environment. Theconnection is made with a device called an I/Ogateway. As defined in the HSE specifications,the foreign device is seen as a publisher to anHSE resident subscriber. Host Device A can treatthe data stream from the I/O gateway in the samemanner as it treats the data streams from deviceson segments A, B and C.

E ⇔ B This is a situation where a foreigndevice wishes to subscribe to an H1 residentdevice or vice versa. The foreign device may beanother network, a device connected viatelecommunications services, or a directlyconnected end-system.

b) H1/HSE InterconnectionsEthernet specifies a physical layer and a data linklayer only. By adopting Ethernet, the HSEsolution has the entire range of standard, off-the-shelf hardware components available for networkimplementations. However, to be useful, higherlevel protocol layers must be added. StandardInformation Technology (IT) and internetapplications almost universally utilize TransportControl Protocol and Internet Protocol (TCP/IP),in addition to the Ethernet data link. More will besaid about the protocol in the following section.

Messages sent on an Ethernet are bounded by aseries of data fields called a frame. Thecombination of a message and frame is called anEthernet packet. Typically, a similarly encodedTCP/IP packet will be inserted in the messagefield of the Ethernet packet. The basicconstruction is shown in Figure 23.

H1Segment

B

H1Segment C

I/O Gateway

HSESegment D

ForeignSegment E

LD

LD

Sw itch HSESegment

A

Figure 22. HSE/H1 Network.


Fieldbus uses a similar data structure wheremessages are bounded by addressing and otherdata items. That which corresponds to a packet inEthernet, is called a Protocol Data Unit (PDU) inFieldbus.

Now consider a communication between two H1devices over an intervening HSE segment, asillustrated by B ⇔ C in Figure 22. The easiestmethod might be for the LD, upon receiving acommunication from an H1 device, to simplyinsert the entire H1 PDU into the message part ofthe TCP/IP packet. Then the LD on thedestination H1 segment, upon receiving theEthernet packet, would merely strip away theEthernet frame and send the H1 PDU on to thereceiving H1 bus segment. This technique iscalled tunneling, and is commonly used in mixedprotocol networks.

The solution developed for HSE is somewhatmore complex, and is dramatically more efficientthan tunneling. As illustrated in Figure 24, mostof the Fieldbus PDU is inserted into the datafield of a TCP/IP message field. However the

Fieldbus address is encoded as a unique TCP/IPaddress. The entire TCP/IP packet is theninserted into the message field of the Ethernetpacket.

Because of the HSE encoding scheme, networkshaving multiple LDs can locate and transfermessages to the correct destination much morequickly, with far less extraneous bus traffic, thanwould occur with tunneling. Perhaps even moreimportant, every H1 device (and every HSEdevice for that matter) has a unique TCP/IPaddress and can be directly accessed overstandard IT and internet networks.

Scheduled communication between H1 devices isstill controlled by the associated H1 Linkmasters,so determinism and other H1 characteristics aremaintained across the network. The message sizein an Ethernet packet is variable, but is limited toa specified maximum to prevent one device fromholding the bus hostage.

c) Basic Details of the HSE SpecificationThe HSE specification relies, wherever possible,on previously existing specifications. Use ofexisting Ethernet technology makes availablereliable, low cost hardware for HSEimplementations. The specifications for thisphysical layer, and the Ethernet data link layerare maintained by the Institute of Electrical andElectronic Engineers (IEEE).

Also used are established internet protocolswhich are maintained by the Internet ArchitectureBoard, and are widely taught in digitalcommunications curricula. These include:

♦ TCP Transport Control Protocol♦ UDP Unit Datagram Protocol♦ IP Internet Protocol

Existing Fieldbus specifications, which havebeen widely tested in H1 applications and arealready maintained by the Fieldbus Foundation,were used where applicable. These include:

♦ FMS Fieldbus Message Specification♦ SM System Management♦ FBAP Function Block Application Process

Finally, where necessary, new specificationswere developed and tested to provide a complete

EthernetPacket

TCP/IPPacket

Message

Message

Frame

Figure 23. Typical Internet Packet.

EthernetPacket

TCP/IPPacket

FieldbusPDU

Message

Message

Message

Address encoding

Figure 24. Nested Messages in HSE.


high speed communications and control solution.The new technology includes:

♦ FDA Field Device Access (Agent)♦ HSE SM System Management for HSE

The various components of the HSE solution canbe described in terms of the OSI model, as shown

in Figure 25. It can be seen that Layers 1 and 2are standard Ethernet. Layers 3 and 4 are coveredby the TCP/IP suite of protocols. Layers 5 and 6are not used.

The FDA Agent allows System Management(SM) and Fieldbus Message Specification (FMS)services used by the H1 devices to be conveyedover the Ethernet using standard Unit DatagramProtocol (UDP) and Transport Control Protocol(TCP). This allows HSE devices to communicateto H1 devices that are connected via a LinkingDevice.

The FDA Agent is also used by the localFunction Block Application Process (FBAP) in aHSE device. Thus, the FDA Agent enablesremote applications to access HSE devicesand/or H1 devices through a common interface.

The HSE SM kernel ensures that system levelfunctions in each device are coordinated. Thesefunctions include system time, addition andremoval of devices from the network, andfunction block scheduling.

System Management assures that the clocks ofHSE devices, including LDs, are synchronized.

Normally, each Linking Device will serve as theprimary LAS for all H1 segements connected tothat LD, thus all H1 device clocks will besynchronized with system time. Local time isused to time stamp events so that event messagesfrom devices may be correlated across thesystem. Local time is also used to schedule theexecution of the local function blocks.

d) RedundancyHSE provides for various levels of redundancyup to and including complete device and mediaredundancy. HSE fault tolerance is achieved byoperational transparency i.e., the redundancyoperations are not visible to the HSEapplications. This is necessary because HSEapplications are required to coexist with standardInformation Technology (IT) applications.

The HSE LAN Redundancy Entity (LRE)coordinates the redundancy function. Each HSEdevice periodically transmits a diagnosticmessage representing its view of the network tothe other HSE devices on both Ethernetinterfaces. Each device uses the diagnosticmessages to maintain a Network Status Table(NST), which is used for fault detection andtransmission port selection. There is no central“Redundancy Manager”. Instead, each devicedetermines its behavior in response to faults itdetects.

Data L ink Layer

7

6

5

4

3

2

1

8

TCP/IPand UDP

FDA, FMS and SM

(Open)Function Block

Appl ication

Ethernet IEEE

802.3u

Presentation Layer

Transport Layer

ISO OSIModel

HSESpecifcations

LayerIndex

Fieldbus Foundation

Internet ArchitectureBoard

IEEE

Open Specificationsmaintained by:

Network Layer

Physical Layer

Proprietary

Appl ication Layer

Session Layer

Figure 25. OSI Model and HSE Protocols.


e) HSE SummaryHSE is designed to integrate multiple protocols,including multiple H1 Fieldbus segments andforeign protocols, as illustrated in the network inFigure 22.

A key addressing concept employed by HSE isthe use of the Internet Protocol (IP), rather thantunneling. HSE uses the Dynamic HostConfiguration Protocol (DHCP), InternetProtocol (IP), as well as System Managementfunctionality to assign addresses. Each devicewill receive an IP address from the DHCP server.H1 addresses are mapped to IP addresses by theLinking Device. When a device is accessed viathe HSE network, the IP address is used. LinkingDevices sort HSE packets and send theappropriate H1 messages to the H1 devices.

The key concept used by HSE in its redundancyspecification is that each device chooses the bestcommunication path. The status of the network isshared among all (HSE) devices. The sharednetwork status allows devices to independentlyselect ports for communication. The connectivitythrough all ports allows devices to avoid bad orbusy ports.

All devices periodically transmit diagnosticmessages. The messages contain the view of thenetwork health and status as seen by the device.The devices use the diagnostic messages to builda Network Status Table for port selection.Diagnostic messages include information such assequence numbers, device number, number ofports, port used for this message, status of allports, and current selected transmission port.

While the HSE name comes from High SpeedEthernet, the HSE specifications permit the useof 10 Mbit/sec Ethernet (also called 10 Base-T),100Mbit/sec Ethernet (also 100 Base-T or FastEthernet) 1Gbit/sec Ethernet (also called GigabitEthernet) or future standards including opticallinks. The networks may be either switched orun-switched. Despite this intended flexibility, theonly tested and demonstrated implementations,as of this writing, are Fast Ethernet usingswitched networks.

For furhter information on HSE, readers arereferred to the Foundation Fieldbus SystemArchitecture (H1+HSE) specification numberFF-581 FS 1.1.

ConclusionThe specifications that define Foundationfieldbus are owned and maintained by theFieldbus Foundation, and are promoted asFoundation fieldbus.

The solution distributes functionality across thenetwork and makes maximum use of intelligencein the individual field devices. It provides adeterministic protocol for real-time control. Itdefines a standardized, object-oriented, functionblock model for application software and aunique Device Description technology to achievemulti-manufacturer device and hostinteroperability without custom programming.

Foundation fieldbus represents an extensivecombination of technology and organizationalinfrastructure. It provides a tested, openspecification for interoperable devices which aredesigned to support diagnostics, monitoring andcontrol in mission critical applications. But thetechnology goes well beyond writtenspecifications. It includes multiple sources fordevelopment and configuration tools,communication stacks and applications software.There are automated test systems anddocumented test procedures for testing stackconformance and device interoperability

The Fieldbus Foundation provides an establishedinfrastructure which supports the test programs,maintenance and improvements in thespecification, maintains and supplies keysoftware utilities, and provides an organizationwhere member companies can cooperate ontechnology development and exchange.

Industrial process and manufacturing automationapplications share many common requirements.Both can benefit from devices having multi-manufacturer interoperability, both need realtimescheduled and unscheduled bus access, they mustdeal with physical resource constraints, and bothneed increasing device autonomy. There is acommon need for monitoring and control systemswhere subsystems can report error andoperational health conditions, and performremote calibration, diagnostics and programexecution.

There is a need for a standardizedcommunication interface to the physicalresources of a device, that does not in turn


require that the physical resources themselves bestandardized. Similarly, there is a need for astandardized, modular application thataccommodates the addition of unforeseenfunctionality, without the need for special toolsand custom programming.

By meeting all of the above requirements,Foundation fieldbus has the potential fordramatic reductions in overall system cost. Thesesavings arise from the technology and thearchitecture of fieldbus itself, and from thecooperation among suppliers, system integratorand end users.


APPENDIX I

EXCERPTS FROM THE IEC/ISA 1987DRAFT REPORT

These excerpts from the draft report illustrate thecommittee’s focus, and provide an underlyingunderstanding of the direction that foundationfieldbus has followed.

Draft Report Excerpts“3.1.4. Communication Integrity - For safeoperation, the system should include errordetection. A value of 20 year mean time betweenundetected transmission errors would assurereliable operation in the typical plantenvironment....” [A discussion of noise sourcesand RFI/EMI issues was included.]

“3.1.5. Connection/Disconnection of Nodes -The bus should be capable of continuedoperation while a connected device (node) isbeing connected or disconnected…”

“3.2.6. Block Transfer - The protocol shouldprovide a mechanism to transfer large blocks ofdata without delaying the communication ofprocess data …”

“3.2.7. Redundancy - The following describesH2 applications only. The protocol shouldsupport full end to end redundancy of thefieldbus system as an option.…”

“3.2.12. Field Device Status Information - Thisfunction would add provision in thecommunication protocol and in the messagingcapability to include a condensed indication offield device status with its current data or in theresponse to an output command. The condensedindication should include levels of priority.…”

“3.2.13. Addressability - It should be possiblefor each device or each process variable frombeing addressed at the user level by a uniqueidentifier such as a tag name. For example, ahuman interface device could seek the location ofa specific field device by a unique tag name.”

“4.5. Commissioning Data - It is important tohave the correct device installed in each serviceduring construction. The work that is currently

done in loop checkout could be greatly simplifiedif each field device could contain the device’s tagname, serial number, range , etc. in readable ,non-volatile digital memory. As soon as thedevice is connected to the control system, thesystem could then interrogate the information toconfirm that communication is established withthe correct device with the correct operatingcharacteristics. The standard protocol shouldinclude provision for accessing this data.”

“4.9. Event Relative Time Stamping - Thecommunications protocol should allow fielddevices to time stamp events with a resolution ofat least 1 millisecond for the H1 applications ofthe fieldbus, [and] 0.1 milliseconds for the H2applications of the fieldbus.…”

“4.18. Access Security - The standard shouldprovide for access security. Multiple accesslevels and the ability to change the access rightsshould be provided.”

“4.21. Addition of Remote Control - There willbe an incentive to implement a conformanceclass that supports functions required toimplement automatic control in the transmitter,the valve positioner, or the junction box. Theprotocol should be able to support the requiredmodes, the time-out gates that may be needed,the anti-windup indicators, etc.”

“4.23. Maintenance Information Capture - Someimplementations of the fieldbus standard mayhave an incentive to include the capture ofcertain data associated with the field deviceitself. It is assumed that this function may onlyneed the inclusion of appropriated parameternames in the highest level of the protocol. Twoexamples of this type of function are detailedhere.” [The examples describe a maintenancerecord and a database to build an audit trail forall changes made to the device.]

the foundation - fieldbus, incfieldbus inc. has been involved with foundation fieldbus and its...

Documents