16.4. FF FUNCTION BLOCKS |
1181 |
16.4.6Function block modes
All FF function blocks must support multiple modes of operation, describing how the block should execute its intended function. Several di erent 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 fixed at a value determined by the technician, with a “Good” status value attached
•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 function block. With FF, each block may be 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 when performing routine maintenance on an FF device (e.g. checking the calibration of an FF transmitter).
It is worth noting an important distinction here between Manual mode and OOS (Out Of Service) mode. In both cases, the function block’s output becomes fixed at some value, but a major di erence between these two modes is their associated statuses. In Manual mode, the output value is fixed and the status is “Good,” allowing all function blocks downstream to remain operational. In OOS mode, the output value is fixed and the status is “Bad,” causing all downstream function blocks to react as they would when receiving any “Bad” signal status (usually by shedding to Manual mode themselves). Placing a function block in Manual mode is useful when performing tests on the control strategy because it allows the technician or engineer to simulate values that might come from transmitters and other “upstream” devices in the loop. All function blocks receiving a signal from a block in Manual mode will continue to operate as they are designed. However, placing a function block in OOS mode is quite di erent in that all function blocks receiving that signal will act as though there is a serious problem rather than acting normally.
1182 |
CHAPTER 16. FOUNDATION FIELDBUS INSTRUMENTATION |
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 di erent 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.
16.5H1 FF device configuration and commissioning
Fieldbus devices require far more attention in their initial setup and commissioning than their analog counterparts. Unlike an analog transmitter, for example, where the only “configuration” settings are its zero and span calibration adjustments, a FF transmitter has a substantial number of parameters describing its behavior. Some of these parameters must be set by the end-user, while others are configured automatically by the host system during the start-up process, which we generally refer to as commissioning.
16.5. H1 FF DEVICE CONFIGURATION AND COMMISSIONING |
1183 |
16.5.1Configuration files
In order for a FF device to work together with a host system (which may be manufactured by a di erent company), the device must have its capabilities explicitly described so the host system “knows what to do with it.” This is analogous to the need for driver files when interfacing a personal computer with a new peripheral device such as a printer, scanner, or modem.
A standardized language exists for digital instrumentation called the Device Description Language, or DDL. All FF instrument manufacturers are required to document their devices’ capabilities in this standard-format language, which is then compiled by a computer into a set of files known as the Device Description (DD) files for that instrument. DDL itself is a text-based language, much like C or Java, written by a human programmer. The DD files are generated from the DDL source file by a computer, output in a form intended for another computer’s read-only access. For FF instruments, the DD files end in the filename extensions .sym and .ffo, and may be obtained freely from the manufacturer or from the Fieldbus Foundation19 website (http://www.fieldbus.org). The .ffo DD file is in a binary format readable only by a computer with the appropriate “DD services” software active. The .sym DD file is ASCII-encoded, making it viewable by a human by using a text editor program (although you should not attempt to edit the contents of a .sym file).
Other device-specific files maintained by the host system of a FF segment are the Capability and Value files, both referred to as Common Format Files, or .cff files. These are also text-readable (ASCII encoded) digital files describing device capability and specific configuration values for the device, respectively. The Capability file for a FF device is typically downloaded from either the manufacturer’s or the Fieldbus Foundation website along with the two DD files, as a three-file set (filename extensions being .cff, .sym, and .ffo, respectively). The Value file is generated by the host system during the device’s configuration, storing the specific configuration values for that specific device and system tag number. The data stored in a Value file may be used to duplicate the exact configuration of a failed FF device, ensuring the new device replacing it will contain all the same parameters.
19One of the tasks of the Fieldbus Foundation is to maintain approved listings of FF devices in current manufacture. The concept is that whenever a manufacturer introduces a new FF device, it must be approved by the Fieldbus Foundation in order to receive the Fieldbus “badge” (a logo with a stylized letter “F”). Approved devices are cataloged by the Fieldbus Foundation, complete with their DD file sets. This process of approval is necessary for operational compatibility (called interoperability) between FF devices of di erent manufacture. Without some form of centralized standardization and approval, di erent manufacturers would invariably produce devices mutually incompatible with each other.
1184 |
CHAPTER 16. FOUNDATION FIELDBUS INSTRUMENTATION |
A screenshot of a .cff Capability file opened in a text editor program appears here, showing the first few lines of code describing the capabilities of a Yokogawa model DYF vortex flowmeter:
As with “driver” files needed to make a personal computer peripheral device function, it is important to have the correct versions of the Capability and DD files installed on the host system computer before attempting to commission the device. It is permissible to have Capability and DD files installed that are newer than the physical device, but not vice-versa (a newer physical device than the Capability and DD files). This requirement of proper configuration file management is a new task for the instrument technician and engineer to manage in their jobs. With every new FF device installed in a control system, the proper configuration files must be obtained, installed, and archived for safe keeping in the event of data loss (a “crash”) in the host system.