Function block fundamentals: The case for bigger libraries created, tested and vetted by vendors
Juanita asked her DCS systems engineer what seemed to be simple request: a rolling average of the last hour or so of analyzer results, so she could better direct her operations crews to make process adjustments. The analyzer produced a new update every three minutes, so how hard could it be to sum up the last 20 results and divide by 20?
Carlos, her systems engineer, began by poking around the pre-built function blocks in the plant’s DCS engineering and configuration tool. Function blocks can be broadly thought of as functions in the mathematical sense: inputs are acted on by a function and produce a result (output), which could be as simple as “multiply x by y” or as complex as “compute an output based on the error between setpoint and process variable using proportional, integral and derivative terms, subject to mode, constraints, status and rate of change.”
Function blocks are a recognized language under IEC-61131-3 for control system configuration, although said standard is hardly prescriptive in how they are configured, compiled or executed. Since our everyday DCS really isn’t distributed (a central controller executes numerous control loops, indication loops, and logic/sequences in one central microprocessor), it’s extremely useful to have the function block language to invoke and interconnect oft-repeated tasks like scaling and linearizing an analog input (AI), solving PID, or connecting a PID block to a physical analog output (AO).
Function blocks can become numerous and Carlos’ DCS had a library of more than 40 in the version they were running, but there wasn’t any for a rolling average like Juanita wanted. The engineering tool did include a blank function block, with a configurable number of inputs and outputs, into which structured text could be inserted. Structured text is another programming language recognized under IEC 61131-3, and it allowed Carlos to enter a series of commands he thought would suffice to add up the last 20 results and divide by 20. Pretty simple, right?
Well, the first challenge was initialization. If the function block hadn’t collected the previous 20 samples at the time it was downloaded or updated, what should its output be? And how to detect whether a download had just occurred? Then Carlos noted his 20x1 array quickly filled up with the same value. It was executing every few seconds and the value of interest only changed once every three minutes. He needed to add more code to detect “a new value is available,” so he created another variable—the sum of a number of GC results—and triggered an update when that value changed from the one stored the last time the block executed.
Carlos had to add more code to detect “bad quality” values and skip them. This was turning into dozens of lines of IF-THEN-ELSE and DO-WHILE statements and code—if Carlos ever got moved or promoted, would his successor be able to understand his logic well enough to maintain or improve it? He went back and added commentary to explain what he was aiming to accomplish at each step.
After a few cycles of trial and error, Carlos thought he had a rolling average that was useful for Juanita’s reports. Broadly speaking this was open-loop control, as operators might make some setpoint changes or change additive rates when the rolling average crossed certain thresholds. But if it was ever to be useful in an automated scheme, additional testing and vetting was probably warranted.
To a programmer or IT professional, this may seem like it’s all in a day’s work. But for a process industry application, Carlos hopes such needs are rare. The more he can deploy standard function blocks that have been created, canned, tested and vetted by his DCS vendor, the less he need stress about unforeseen “features” of any customization. Often the bigger challenge is not getting custom code to do what we want—it’s ensuring it doesn’t do what we don’t want. Delivering the rudimentary functionality necessary to produce saleable product supersedes innovation or jazzed up customized features.
All these nuances of the DCS configuration occur “under the hood” and are invisible to the ultimate end user, Juanita and her reports—until it malfunctions. To have a tested and proven repertoire of function blocks is indispensable to Carlos and all process control professionals.
