The ANSI/ISA S50.2 fieldbus standard recognizes eight different fieldbus technologies, but only Foundation fieldbus (FF) incorporates the entire S50.2 standard including the inclusion of function blocks that are specifically designed for deploying control strategies into field-devices – a capability the SP50 committee strongly supported.
Dick Caro, a past chairman of the ISA SP50 fieldbus committee, believes that about 80% of today’s process control loops are candidates for taking advantage of FF function blocks to achieve control in the field (CIF) and restore the once-popular ‘best practice’ known as single-loop integrity.
Single-loop integrity (sometimes referred to as single-control strategy integrity) is a simple concept – design control loops so that if any of the loops devices fail only that loop is affected. The overwhelming benefit of a single-loop integrity design philosophy is that loss of one control loop (or strategy) rarely results in a complete or even partial unit shutdown of the process. When CIF is strategically deployed to include field-devices and the process automation system (PAS), a field-centric control architecture is created that produces a simpler, more reliable, less costly implementation.
A robust implementation of CIF begins with Fieldbus Foundations’ specification that defines standard, flexible, and safety system function blocks (See Figure 1).
Each FF function block is an encapsulation of inputs, outputs, parameters, variables, and processing algorithms appropriate to achieve a defined functionality.
The standard and safety system function blocks are each pre-configured and include the number and type of inputs, outputs, parameters, and variables and algorithm.
Two types of flexible function blocks are defined, free form and pre-configured.
As the name implies, free form blocks are fully user configurable.
Pre-configured flexible function blocks, such as multiple analog input, are similar to standard function blocks in as much as each has a defined number and type of inputs and outputs. The blocks flexibility is achieved by allowing the user to configure the blocks embedded algorithm.
Once created, all flexible function blocks are instantiated and connected to standard and/or other flexible function blocks to form a robust, deployable control solution. (See “Instantiation Basics” sidebar below.)
The question on many minds about now is, “If FF devices already support the CIF concept the S50 committee members felt so strongly about, why are we just beginning to hear about CIF’s use?”
Pioneering Has Ended
Actually, there are a significant number of CIF deployments, but a mere handful of end-users have openly shared their achievements.
Recently joining CIF pioneers from Bowater’s Kraft paper mill in Gatineau, Quebec, Canada; and International Specialty Products BDO plant in Lima, Ohio; is the Shanghai SECCO Petrochemical facility in the Shanghai Chemical Industrial Park located in the Shanghai Province of China.
Following a quantified examination of the risks and benefits SECCO determined that CIF provided significant benefits over the more traditional PAS implementation practices typically associated with DCS implementations. Among the benefits SECCO identified was that CIF reduced the impact on production of a control strategy failure; reduced fieldbus network communications; reduced PAS controller loading thus reducing the number of PAS controllers required; reduced system investment and startup costs; and provided the necessary device and process health information to implement effective predictive maintenance practices.
What makes the SECCO decision to adopt a field-centric architecture significant is that SECCO has about 47,000 control loops deployed, about a third of which reside in field devices. SECCO’s commitment to a field-centric architecture sends a clear indication that pioneering efforts have ended and that CIF is now a mainstream solution.
What’s also noteworthy is that as the number of CIF deployments has increased so too has the innovation and sophistication of these deployments.
The name of each standard function block is generally sufficient to understand the blocks functionality (e.g., Analog input, Integrator, PID control, Ratio control, Timer, etc.).
While several function blocks clearly indicate “control” capabilities, such as Discrete control, PID control, etc. Other blocks provide control strategy enhancements, such as Bias and gain, Lead/lag, and Setpoint ramp generator, while others support placing both simple and complex calculations in field devices. When appropriately combined, the standard function blocks offer users a rich set of control strategy development tools.
Using standard function blocks to develop a control strategy is as easy as selecting the appropriate blocks and then connecting inputs and outputs together. For example, Figure 2 below illustrates that to create a simple PID Control solution requires using three function blocks – analog input, PID control, and analog output.
Enhancing a control loop is equally as easy. For example, adding feedforward to a control loop requires another analog input block for the feedforward value and then connecting the blocks output to the PID control block’s FF_VAL connection.
Similarly, modifying figure 2 to form a cascade control strategy requires adding an analog input block, a PID control block, and the appropriate connection of the inputs and outputs.
Frequently there’s concern that anything “standard” equates to basic or rudimentary but that’s not the case with FF’s standard function blocks, each includes a rich set of features and capabilities.
For example, switching a cascade control strategy in/out of cascade mode without upsetting the process requires automatic tracking of setpoint and output values based on each loops mode – Manual, Auto, Cascade (sometimes referred to as Remote Setpoint). This is commonly referred to as a bumpless transfer and it’s just one example of the rich set of capabilities included in the processing algorithm that’s encapsulated in each FF PID control function block.
Of course it’s impossible to describe, or even think of every control strategy that could be assembled using FF’s standard function blocks, but a few that come to mind include:
- Single loop feedback (PID) control.
- Feedforward added to PID control.
- Two and three-element cascade PID control.
- Ratio control.
- Control requiring bias and gain and/or lead/lag such as often required in combustion control applications.
- Loops requiring manual loader stations.
- Loops requiring manual or automatic selection of different process variables, such as temperature or pH sensors.
- Loops that need the final control element set to a fixed value based on the status of a discrete input.
Every process control application relies on operators having access to a variety of real-time calculated values such as material balance and total flow.
One of the most common process calculations is determining a vessels liquid level using pressure measurements – a measurement principal commonly referred to as hydrostatic tank gauging (HTG).
HTG uses the principle that the difference between two pressures is equal to the height of the liquid multiplied by the specific gravity of the fluid. Because it’s such a commonly required measurement, a pre-configured HTG compensated level calculation is included as one of the nine selectable functions available in FF’s arithmetic function block; other’s are:
- Average of inputs
- BTU flow
- Flow compensation approximate
- Flow compensation linear
- Flow compensation square root
- Fourth order polynomial
- Multiply and divide
- Sum of inputs
Another commonly used process calculation is totalizing the flow, mass, or volume of a liquid over time.
Figure 3 below illustrates how FF’s arithmetic and integrator function blocks are combined to produce an integrated mass flow value using uncompensated flow, temperature, and pressure measurements as inputs.
These few examples represent a mere fraction of the ways standard FF function blocks are facilitating a return to the best practice of single-loop and single-strategy integrity – but it doesn’t end there.
Shortly after Fieldbus Foundation released its standard function block specifications users began requesting additional function blocks. To avoid the problems associated with identifying, developing, testing, and maintaining a potentially massive library of function blocks, the Fieldbus Foundation programming gurus, working in cooperation with end-users, determined that the best long-term solution was to create what eventually became FF’s flexible function blocks.
Beyond Committee Dreams
FF flexible function blocks are similar to standard function blocks, except that the blocks developer (programmer) defines its actual function, the order and definition of its parameters, and the content and execution time of the blocks algorithm.
Flexible function blocks are well suited to create analog and discrete control applications, provide an excellent means of performing complex calculations, and they can be used in conjunction with both standard and other flexible function blocks to form sophisticated field-deployable application solutions.
One fairly simple example of a flexible function block application uses three discrete level switches as inputs to start and stop two pumps in order to control the level in a sump (See Figure 4 below).
In this “snap control” example, the requirements include alternating the use of pumps YD1 and YD2 to extend pump life. ZS3 turns the pumps off, ZS2 turns one of the pumps on and if the level ever reaches the ZS1 trip point, both pumps are turned on.
Traditionally the logic for snap control would be located in a PAS controller, but if an application requires three or four snap control deployments and those deployments can be placed in to existing field-devices, the solution will be more reliable, cost nothing to implement, and frees up valuable PAS controller processing time.
Like standard function blocks, flexible function blocks are not confined to just performing control tasks, they can also be used for complex calculations.
Two flexible function block applications implemented by a major oil company involved implementing two widely used oil field measurements – de Leeuw wet gas correction (See Figure 5) and the production gas estimator for continuous well monitoring (See Figure 6).
Each measurement makes use of the equation for compensated volumetric flow defined in the ISO 5167 standard, thus that particular function block has been instantiated – that is, created once and used over and over.
The de Leeuw wet gas flow correction makes use of a correlation algorithm that compensates for over-readings resulting from metering multiphase gases.
The algorithm for production gas estimation applies to natural producing, gas-lifted, ESP-lifted, and pumped-oil wells and helps reduce the number of well tests required, instantaneously identifies well production changes, supports the creation of well lift performance curves, and facilitates continuous production optimization.
Like the standard function block examples presented earlier, these are but a few examples of control and calculation solutions being implemented using FF’s flexible function blocks.
Available on the Fieldbus Foundation’s Web site are additional flexible function block control solutions described in Function Block Capabilities in Hybrid/Batch Applications. Included in this collection of innovative application descriptions – some complete with implementation solutions – are:
- Multivariable matrix control
- Variable-speed drive control
- Four discrete valve control
- Extended PID with AutoTuner
- Fermentation Zymolysis control
- Distillation startup and shutdown
- Integration path for a legacy system and multiple field HART® interface
- Process cooling water system
- Cleanroom makeup air unit
- Packaged batch distillation control
A less obvious application solution facilitated by FF’s flexible function block is the ability to use OPC (OLE for process control) to help integrate legacy systems connected to different fieldbus protocols.
Another example described in some detail in the Function Block Capabilities in Hybrid/Batch Applications document titled Integration path for a legacy system and multiple field HART interface uses a commonly encountered two-tank storage level application to illustrate how FF’s flexible function blocks can help integrate legacy systems.
The example anticipates that control problems may include a mixture of fieldbus protocols and conventional 4-20mA instrumentation, the example makes use of hard and soft gateways, OPC, HSE, and H1 devices.
A Modbus/RTU is integrated using an HSE "hard" gateway device and Profibus-DP is integrated using a "soft" gateway based on OPC servers for Fieldbus and Profibus in conjunction with an OPC bridge.
To ensure communication integrity, a FF flexible function block hosts watchdog logic for both FF and Profibus communication protocols. The watchdog logic continuously validates the integrity of the OPC link, initiating a pre-defined “safe” action in case of defined communication faults.
Though all of the above examples may not be appropriate for all process control applications, each illustrates the capabilities that FOUNDATION fieldbus function blocks are able to deliver.
In the beginning, the justification to install FOUNDATION fieldbus was predicated on savings from simplified design, installation, and commissioning – still legitimate justifications. However, as the SP50 committee predicted, FF’s ability to host control-in-the-field also restores the much sought single-loop integrity philosophy thus creating a more reliable, less complex control system implementation.
While no one really knows how much CIF is actually implemented, three things are known; 1) FOUNDATION fieldbus is installed in most of the top companies in every processing industry all over the world; 2) top companies became and remain top companies because they make full use of their technology investments; and 3) FOUNDATION fieldbus is now mainstream.
Instantiation allows users to create an instance of one particular function, such as a level control strategy, give it a generic name (e.g., LIC-xx1), and then use instantiation tools to produce more refined, deployable versions that include variables such as tag (e.g., LIC-101, LIC-201, etc.), descriptions, I/O channels, etc.
|About the Author|