Wednesday, May 23, 2018

IAM Search

FOUNDATION Fieldbus function blocks

Data handled within FF systems are organized into modules known as function blocks. Sometimes these blocks serve merely to catalogue data, while in other instances the blocks execute specific algorithms useful for process measurement and control. These “blocks” are not physical entities, but rather abstract software objects – they exist only as bits of data and instructions in computer memory. However, the blocks are represented on a computer screen as rectangular objects with input ports on the left-hand side and output ports on the right-hand side. The construction of a working control system comprised of FF devices consists of linking the outputs of certain function blocks with the inputs of other function blocks via configuration software and computer-based tools. This usually takes the form of using a computer to draw connecting lines between the output and input ports of different function blocks.

Analog function blocks versus digital function blocks

Function-block programming in general strongly resembles the design philosophy of legacy analog-based computer systems, where specific functions (addition, subtraction, multiplication, ratio, time-integration, limiting, and others) were encapsulated in discrete operational amplifier circuits, and whole systems were built by connecting function blocks together in whatever patterns were desired to achieve a design goal. Here with Fieldbus programming, the function blocks are virtual (bits and data structures in digital memory) rather than real analog circuits, and the connections between blocks are merely pointer assignments in digital memory rather than actual “patch cable” connections between circuit boards.

An example contrasting analog circuit design with Fieldbus function-block design appears here, both systems selecting the greatest temperature signal to be the output. The system on the left-hand side receives analog voltage signals from three temperature sensors, using a network of operational amplifiers, diodes, and resistors to select the greatest voltage signal to be the output. The system on the right-hand side uses three Fieldbus transmitters to sense temperature, selecting the greatest temperature by means of an algorithm executing in a Fieldbus device (it could be one of the FF transmitters, or even another device on the segment):

 

 

FOUNDATION Fieldbus abstracts the notion of discrete circuit modules performing compartmentalized tasks to software algorithms, “connecting” these algorithms together by a set of communication assignments whereby function blocks broadcast their output data to the network and the receiving blocks “listen” for the broadcasts at the right times.

 

Function block location

There is usually some freedom in where various function blocks may be located in a FF segment. Take for instance the example of a flow control loop, where a flow transmitter feeds measured flow data into a PID control function block, which then drives a control valve to whatever position necessary to regulate flow. The actual physical device layout might look something like this:

 

 

The function block connections necessary for this control scheme to work are shown in the next diagram, coupling the AI (analog input) block located in the transmitter to a PID control block to an AO (analog output) block located in the valve positioner:

 

 

All function block inputs are on the left-hand sides of the blocks, and all outputs are on the right-hand sides. In this function block program, data from the analog input (AI) block flows into the PID block. After calculating the proper output value, the PID block sends data to the analog output (AO) block where the final control element (e.g. valve, variable-speed motor) is adjusted. The AO block in turn sends a “back calculation” signal to the PID block to let it know the final control element has successfully reached the state commanded by the PID block’s output. This is important for the elimination of reset windup in the event the final control element fails to respond to the PID block’s output signal.

It should be obvious that the analog input (AI) block must reside in the transmitter, simply because only the transmitter is able to measure the process fluid flow rate. Likewise, it should be obvious that the analog output (AO) block must reside in the control valve positioner, simply because the valve is the only device capable of manipulating (exerting influence over) anything. However, given the lack of a separate controller device, the person configuring the Fieldbus loop may choose to locate the PID block in either the transmitter or the control valve positioner. So long as both FF devices possess PID function block capability, either location is possible for the PID function block.

The following illustrations show the two possible locations of the PID function block:


 
The only factor favoring one location over another for the PID function block is the number of communication broadcasts (“Compel Data” token distributions and replies) necessary per macrocycle. Note the lines connecting function blocks between the two instruments in the previous diagrams (lines crossing from one blue bubble to another). Each of these lines represents a VCR (Virtual Communication Relationship) – an instance during each macrocycle where data must be transmitted over the network segment from one device to another. With the PID function block located in the flow transmitter, two lines connected the flow transmitter’s PID block to the valve positioner’s AO block. With the PID function block located in the valve positioner, only one line connected the flow transmitter’s AI block to the valve positioner’s PID block. Thus, locating the PID function block in the valve positioner means only one CD message/reply is necessary per macrocycle, making the network communication more efficient.

To illustrate the difference this re-location of the PID block makes, we will examine the function block diagram and macrocycle timing schedule on a simple pressure control FF loop, hosted on an Emerson DeltaV distributed control system. The first composite screenshot shows the function block diagram and schedule with the PID function block located in the transmitter (PT 501):

 

Note the two scheduled communication events (CD tokens and responses) necessary in the macrocycle schedule to enable communication between pressure transmitter PT 501’s PID function block and valve positioner PV 501’s analog output function block. The total (minimum) macrocycle time for this control loop is 330 milliseconds1.

Now let’s examine the same PID pressure control system with the PID function block moved to the valve. Here you see the function block diagram followed immediately by the updated macrocycle schedule:

 

Note that the macrocycle time is 30 milliseconds than before (300 milliseconds total as opposed to 330 milliseconds), since there is one less scheduled communications event happening. This represents a time reduction of almost 10% compared to the previous example, simply by assigning one function block to a different device on the segment.

 

Standard function blocks

The FF standard specifies many different function blocks for the construction of control algorithms. Ten of them are considered “basic” FF function blocks:

AI – Analog Input

AO – Analog Output

B – Bias

CS – Control Selector

DI – Discrete Input

DO – Discrete Output

ML – Manual Loader

PD – Proportional/Derivative control

PID – Proportional/Integral/Derivative control

RA – Ratio

 

Nineteen more “Advanced” function blocks are incorporated in the FF standard:

Pulse Input

Complex Analog Output

Complex Discrete Output

Step Output PID

Device Control

Setpoint Ramp

Splitter

Input Selector

Signal Characterizer

Dead Time

Calculate

Lead/Lag

Arithmetic

Integrator

Timer

Analog Alarm

Discrete Alarm

Analog Human Interface

Discrete Human Interface

 

Five more function blocks are specified as well:

Multiple Analog Input

Multiple Analog Output

Multiple Digital Input

Multiple Digital Output

Flexible Function Block

 

The primary benefit of standardization is that the end-user may choose FF instruments manufactured by any standard-compliant vendor, and those function blocks should behave the same as the equivalent function blocks within any other manufacturer’s model of FF device. There are, of course, examples where manufacturers have equipped their FF devices with “extended” capability function blocks going beyond the Fieldbus Foundation standard, and the user must beware of this.

 

Device-specific function blocks

In addition to the function blocks necessary to construct control schemes, all FF instruments contain one Resource block and usually one or more Transducer blocks describing details specific to that instrument. The following screenshot shows all function blocks within a Rosemount model 3095MV Fieldbus transmitter:

 

The Resource block appears first in this list, followed by three transducer blocks, then followed by the palette of general function blocks for use in constructing control algorithms. Information contained in the Resource block of an FF instrument includes the following:

  •  Identifier (the 32-byte code unique to every FF device)
  • Type of device
  • Device revision level
  • Memory total and available (free) capacity
  • Computation time
  • Available features listing
  • Current device state (Initializing, Standby, On-line, Failed, etc.)

Transducer blocks provide a means of organizing data relevant to the actual sensing inputs, outputs, calculated variables, and graphic displays of a FF device. There need not be a one-to-one correspondence between the number of transducer blocks in an FF device and the number of  physical I/O channels it has. For example, in the Rosemount 3095MV multivariable transmitter, transducer block 1100 handles all physical measurement inputs (pressure and temperature sensors) while transducer block 1200 is reserved for inferred mass flow (based on calculations performed on the raw sensor measurements) and transducer block 1300 handles data for the liquid crystal display (LCD).

 

Status propagation

As mentioned earlier, function block programming bears a strong resemblance to analog function block circuit design, where specific tasks are divided up into discrete elements, those elements connected together to form a larger system with more complex functionality. One of the important distinctions between the old-style analog function block circuit design and FF function block programming is the data content of the lines connecting blocks together. In the analog world, each connecting line (wire) carries exactly one piece of information: a single variable represented in analog form by a voltage signal. In the world of Fieldbus, each connecting line carries not only the variable’s numerical value, but also a status and in some cases an engineering unit (a unit of measurement).

The inclusion of status along with data is a powerful concept, with roots in scientific practice. Scientists, as a rule, do their best to report the degree of confidence associated with the data they publish from experiments. Data is important, of course, but so is the degree of certainty with which that data was obtained. Obviously, data gathered with instruments of low quality (high uncertainty) will have different significance than data gathered with instruments of high precision and impeccable accuracy (low uncertainty). Any scientist wishing to base their theoretical work on a set of scientific data published by another scientist will have a measure of that data’s significance – a very valuable detail.

By the same token, data “published” by a FF device is only as good as the health of that device. A FF transmitter exhibiting noisy or wildly fluctuating measurements might very well be nearing complete failure, and therefore its published data should be treated with skepticism. Since FF devices are “smart” (meaning, among other things, they have self-diagnostic capability), they have the ability to flag their own data as “Bad” if an internal fault is detected. The data still gets published and sent to other FF function blocks, but the status sent along with that data warns all downstream blocks of its uncertainty.

The three major status conditions associated with every FF signal passed between function blocks are:

  • Good
  • Bad
  • Uncertain

Sub-status states also exist to further delineate the nature of the uncertainty. “Sensor Failure” is an example of a sub-status value, describing the reason for a “Bad” status value. In computer science, there is a saying that “Garbage In equals Garbage Out,” sometimes abbreviated as GIGO. No algorithm, no matter how advanced, can guarantee and output of good data from an input of bad data. This principle finds application in FF function block programming, as the blocks are programmed to switch mode when “Bad” or “Uncertain” input statuses are detected.

Furthermore, status values are propagated from the originating block all the way down through the last function block in the chain, reflecting the effect of an input signal’s uncertainty on all consequent function outputs. For example, an analog input (AI) block sending a “Bad” status signal to the process variable input of a PID control block will have its “Bad” status propagated to the output of the PID block as well. Any function blocks receiving the PID block’s output signal will likewise sense the “Bad” status and further propagate that status to their output signal(s).

 

Function block modes

All FF function blocks must support multiple modes of operation, describing how the block should execute its intended function. Several different function block modes are commonly found for FF function blocks, though not all FF function blocks support all of these modes:

OOS (Out Of Service) – All function blocks are required to support this mode, where the block freezes its output at the last calculated value and attaches a “Bad” status value

Man (Manual) – the output of the block is determined by human control

Auto (Automatic) – the function block processes information normally

Cas (Cascade) – the function block processes information normally

Iman (Initialization Manual) – the output of the block is fixed at its last calculated value, due to the output signal path being incomplete

LO (Local Override) – the output of the block is fixed at its last calculated value, due to a detected fault condition within the device

RCas (Remote Cascade) – the function block processes information normally based on a setpoint sent from a remote source to the block’s RCas In input

ROut (Remote Output) – the function block passes data to its output sent from a remote source to the block’s ROut In input

Instrumentation technicians and professionals are already familiar with the concept of a controller having “Automatic,” “Manual,” and even “Cascade” operating modes, but Fieldbus function block programming extends this general concept to each and every block. With FF, each block maybe independently set into “Automatic” or “Manual” mode, which is a useful tool for testing FF  algorithms and troubleshooting complex FF control schemes. The “Out of Service” mode, for instance, is commonly set by an instrument technician as he or she performs routine maintenance on an FF device (e.g. checking the calibration of an FF transmitter).

In addition to these operating modes for FF function blocks (not all of which are supported by all FF blocks), FF function blocks also have four mode categories describing valid modes for the block to be in under various conditions:

  • Target
  • Actual
  • Permitted
  • Normal

A block’s “Target” mode is the mode it strives to be in if possible. The “Actual” mode is the mode the block is in at the present time. “Permitted” modes list all the different modes which may be used as “target” modes. “Normal” is a category describing to an operator interface what a block’s normal operation mode should be, but the block itself does not heed this setting.

1This is not an unreasonable loop execution time for a pressure control system, especially if it is a gas process. Liquid pressure control is notoriously fast, and may experience trouble with a loop dead time of almost one-third of a second. For historical comparison, this execution time is on par with that of the original Honeywell TDC 2000 distributed control system, a hardware platform that has controlled many thousands of loops in oil refineries, pulp mills, chemical processing plants, and other industrial facilities worldwide. The practicality of a digital control loop with one-third second response is therefore proven by decades of practical application.

 

Click here to go to the next page, H1 FOUNDATION Fieldbus Device Configuration and Commissioning

Click here to go back to the previous page, H1 FOUNDATION Fieldbus Data Link Layer

Go Back to Lessons in Instrumentation Table of Contents

Comments (0)Add Comment

Write comment

security code
Write the displayed characters


busy

Promotions

  • ...more

Disclaimer

Important: All images are copyrighted to their respective owners. All content cited is derived from their respective sources.

Contact us for information and your inquiries. IAMechatronics is open to link exchanges.

IAMechatronics Login