Function block(s) in a fieldbus device performs the different functions required in a process control operation. A fieldbus device may contain one
Function block
Function block
Function block Transducer block
Transducer block
Resource block
FIGURE 7.13 Blocks in user layer.
Foundation Fieldbus 131
or more function blocks. In process control systems, operational require-ments normally vary—depending on the particular process and the end-product quality. Thus, the Fieldbus Foundation has designed a standard function block as normally applicable in process industries. In addi-tion, some other function blocks have been recommended. Most impor-tantly, with the help of models and parameters existing in the function block, the design engineer can configure, maintain, and customize the applications.
The system architecture document of Foundation Fieldbus says One of these models, the function block model, has been specified within the architecture to support low level functions found in man-ufacturing and process control. Function blocks model elementary field device functions, such as analog input functions and propor-tional integral derivative (PID) functions. The function block model has been supplemented by the transducer block model to decouple function blocks from sensor and actuator specifics. Additional mod-els, such as the “exchange block” model, are defined for remote input/
output and programmable devices.
The function block model provides a common structure for defin-ing function block inputs, outputs, algorithms and control parameters and combining them into an Application Process that can be imple-mented within a single device. This structure simplifies the identi-fication and standardization of characteristics that are common to function blocks.
A function block has input, output, and contained parameters. Data gen-erated in a block is available at its output and acts as the input to another
HSE
Linking device H1 fieldbus
PID 110 AO 110 Device 1 Device 2
AI 110
FIGURE 7.14 Control loop using function blocks. (From SMAR. Fieldbus Tutorial—A Foundation Fieldbus Technology Overview. USA, pp. 1–29. Avail-able at http://www.smar.com/PDFs/catalogues/FBTUTCE.pdf.)
block. Thus an AI block’s output acts as the input to the PID block. Its output is the input to the AO block, whose output may be fed to the PID block for process control purpose.
Function blocks are classified as (a) a standard block as specified by Fieldbus Foundation (b), an enhanced block for including additional parameters, and (c) an open block or vendor-specific block meeting the needs of specific process requirements.
Figure 7.14 shows a control loop that uses function blocks in fieldbus devices.
TABLE 7.10
Different Function Blocks
Part 2 Blocks Major in Control and Measurement
AI Analog Input Block
DI Discrete Input Block
ML Manual Loader Block
BG Bias/Gain Station Block
CS Control Selector Block
PD P, PD Controller Block
PID PID, PI, I Controller Block
RA Ratio Station Block
AO Analog Output Block
DO Discrete Output Block
Part 3 Blocks Enhanced Blocks
DC Device Control Block
OS Output Splitter Block
SC Signal Characterizer Block
LL Lead Lag Block
DT Dead Time Block
IT Integrator (Totalizer) Block
(More blocks are under development) Part 4 Blocks Multiple I/O Blocks
MAI Multiple Discrete Input Block
MDI Multiple Analog Input Block
MAO Multiple Discrete Output Block
MDO Multiple Analog Output Block
Part 5 Blocks IEC61131 Blocks
(Under development)
Source: From Yokogawa Electric Corporation. Fieldbus Book—A Tutorial, Technical Information TI 38K02A01-01E, pp. 1–33, 2000.
Foundation Fieldbus 133
7.9.3.1 Function Block Library
Table 7.10 shows a comprehensive list of the library of function blocks as defined by the Fieldbus Foundation. The 10 basic function blocks shown in Part 2 are the fundamental ones supported and required in process control and measurement. Thus, the parameters of such blocks must be known to all systems. Part 3 blocks are used for advanced measurements, while Part 4 blocks provide I/O interface to the outside world.
Attributes of a function block, such as data type, its name, minimum values, and maximum values, wherever applicable are contained in the DD (device description) block. For every function block, there is a DD—be it basic, extended, or custom-type function block. The basic and extended function blocks are documented by the Fieldbus Foundation in their respective function block specification.
7.9.3.2 Function Block Scheduling
Figure 7.15 shows the scheduling of function blocks. A schedule building tool is used to generate the proper time schedules for operations of both LAS and different function blocks. The schedules that have been built on the control loop operation are shown in Figure 7.14. The schedule building
The start of individual macrocycles is defined as an offset from the absolute link schedule start time.
Absolute link schedule start time
Device 1
FIGURE 7.15 (See color insert.) Scheduling of function blocks. (From SMAR.
Fieldbus Tutorial—A Foundation Fieldbus Technology Overview. USA, pp. 1–29.
Available at http://www.smar.com/PDFs/catalogues/FBTUTCE.pdf.)
tool contains start time offsets of the different function blocks from the
“absolute link schedule start time.”
A “macrocycle” is defined as a single iteration of a schedule within a device. There can be device macrocycle or LAS macrocycle. Table 7.11 shows typical time offsets of AI, AO, and PID blocks from the absolute link schedule start time.
The AI block is executed at offset 0. At offset 20, LAS issues a CD to the AI function block buffer residing in the transmitter and then data in the buffer is published on the fieldbus. At offset 30, PID function block is executed, followed by execution AO function block at offset 50.
The different offsets represent the exact time at which a particular func-tion is to start its operafunc-tion with respect to absolute link schedule start time. The beginning of the macrocycle represents a common and unified start time for all concerned function block connected to the link and for the LAS link-wide schedule. Different function block execution and their corresponding data transfers on the bus are thus synchronized in time.
It is apparent from Figure 7.15 that from offset 20 to offset 30, the bus cannot be used for sending unscheduled messages. This is so because dur-ing this time, AI publishes (communicates) data on the bus. AI obtained this data during its execution from offset 0 to offset 20.
7.9.3.3 Application Clock Distribution
Foundation Fieldbus supports an application clock distribution function.
It is usually set and adjusted to local time of the day or to some Universal Coordinated Time. System management contains a time publisher that periodically sends an application clock synchronization schedule mes-sage to all connected fieldbus devices. The data link scheduling time is sampled and sent along with the application clock message. This allows the receiving devices to adjust their local application time. In between the
TABLE 7.11
Schedules of Different Function Blocks
Schedule of Different Blocks Offset Values
AI execution 0
AI communication 20
PID execution 30
AO communication 50
Source: Yokogawa Electric Corporation. Fieldbus Book—A Tutorial, Technical Information TI 38K02A01-01E, pp. 1–33, 2000.
Foundation Fieldbus 135
synchronization time message, the application clock time is independently maintained in each device based on their internal clocks.
Application clock synchronization allows the fieldbus devices to time stamp data throughout the fieldbus network. If a backup application clock publisher is maintained in the network, the same would become active when the currently active time publisher should fail.
7.9.3.4 Macrocycle and Elementary Cycle
In process industries, continuous control of process variables is a basic requirement for maintaining the proper health of the system. A precise cyclic update of process variables is what is needed to ensure the above.
Such demands and requirements from process variables are more or less fixed for a given plant. Also occasional and sporadic events (acyclic) such as alarm reporting and set point changes also need to be accommodated in the overall control scheme of things. LAS takes the overall responsi-bility of such cyclic and acyclic communications in macrocycles. A mac-rocycle is divided into elementary cycles, which consist of time needed for cyclic and acyclic communications. This is shown in Figure 7.16. It shows a system consisting of two devices requiring cyclic updates. An elementary cycle consists of cyclic and acyclic tasks. Scheduling of peri-odic tasks (cyclic) is so done that some time is assigned in the elementary cycle to address the need of aperiodic tasks (acyclic), should the need arises.
7.9.3.5 Device Address Assignment
For a device to work properly on a fieldbus, two requirements must be met: the device must have a unique network address and a physical device tag. Network address assignments are done by the configuration tool using system management services.
Assignments of network address follow these steps:
• Unconfigured (new to the network) devices join the network at one of the four special default addresses.
Macro cycle
FIGURE 7.16 Macrocycle and elementary cycles.
• A configuration tool chooses a used permanent address and assigns the same to the device using system management services.
• The same configuration tool will then assign a physical device tag to the device using system management services.
• The above procedure is followed for all new devices that want to have their entry into the network.
• These newly entered network devices store their physical device tag and node address in nonvolatile memory. This procedure ensures the devices retain their separate identifications even in case of power failure or system shutdown.
7.9.3.6 Tag Service
A device or a variable can be traced with the help of tag service. System management supports such a service. When a “find tag query” is broadcast to all the connected field devices, each of them starts searching its VFD for the requested tag and returns back all the required information. In case the tag is found (it includes network address, VFD number, VCR index, and OD index), the complete path is known and the host or maintenance device can then access data from the tag.
7.9.4 tranSducer block
A transducer block models sensors and actuators and connects function blocks to local input/output functions. Transducer blocks isolate the func-tion blocks from the hardware details of a given device. Sensor outputs are accepted by transducer blocks and then write to actuators. Traditional sensors such as pressure and temperature transmitters can be mapped into a transducer block. It is connected to a function block through the channel parameter of the function block.
While a particular function block carries out the function that is assigned to it, a transducer block is dependent on the kind of measurement. That is, for temperature, pressure, or flow measurements, it employs differing mea-surement principles; however, in all the cases, it provides an analog value.
A transducer block performs various functions such as digitizing, scaling, and filtering, which are needed to convert the sensor output to a value that can be accepted by the function block.
Generally there is one transducer block per device channel. Multiplexers allow multiple channels for a single transducer block. The different blocks, viz., resource, transducer, and function blocks, and their interconnections are shown in Figure 7.17.
Foundation Fieldbus 137
7.9.5 Support objectS
Some additional objects are defined in the user application: link object, trend object, alert object, multivariable container (MVC) object, and view object. Link objects define the links between various function block inputs and outputs internal to the device and across the fieldbus network.
Trend objects are used for local trending of function block parameters for host accessing or other devices. Alert objects allow alarm reporting and events on the fieldbus. MVC objects serve to encapsulate multiple function block parameters to optimize communications for report distribution and publisher–subscriber transactions. View objects refer to some predefined groupings of block parameter sets that can be displayed by HMI.
Function block application
Sensor 1 Transducer
block 1 Function
block 1
Resource block
Alerts View
lists
Links MVC
Sensor 2 Transducer
block 2 Function
block 2
Viewlists Trend
object
FIGURE 7.17 Different blocks and object representation in user layer. (From Glanzer D. A. Technical Overview, Foundation Fieldbus, FD-043, Rev 3.0, 1996 (Rev. 1998, 2003). Fieldbus Foundation, Austin, TX. Available at www.fieldbus.
org/images/stories/technology/developmentresources/development_resources/docu ments/techoverview.pdf.)