John Rezabek is a process control specialist for ISP Corp., Lima, Ohio. Email him at [email protected]So I was checking my corporate email remotely using a browser interface and happened upon a message I wanted to remember to open on Monday morning. I thought I'd right-click and "mark it as unread," but didn't notice that, unlike the Lotus Notes standard interface, there was another option I was clicking (bifocals were in my shirt pocket) called "mark all unread." Suddenly I had a couple thousand unread messages, dating back many months. Oops.
Sometimes we need not look too far to find the "fool" referred to in the expression "make it foolproof." Of course, if you make it foolproof, they'll make a better fool. That bit of cynicism (or realism) is attributed to an anonymous software engineer, probably the person tasked with creating all those "are you really, really sure?" dialog boxes that pop up when, for example, you click "delete."
Similarly, we are professional agents in the chain of delivering the value of present-day technology to our end users, such as our process operators, and we can sometimes feel both bewildered and harassed by all the new ways they find to break our creations. But because we're working with highly hazardous processes and substances, and the consequences are so severe, it's become one of our duties to think through the consequences of every errant mouse click.
When we design for digital integration of field devices through fieldbus, there are some innate features that are part of the specification that we get without clicking anything. We need to understand them, so we can direct the configuration mindfully.
Read Also: Software Integration: No KISS for Digital Integration
Let's start with fault behavior. Control valve fail position is part of the engineer's strategy for ensuring the process heads toward a safe state when an instrument fails or instrument air goes away. That's supposed to be foolproof. But what about loss of communication? With Foundation fieldbus (FF), "it depends." If the design is using control in the field, those loops will continue executing even if communication with the host goes down, provided the segment still has power and something is functioning as the Link Active Scheduler (LAS).
That can be a comfort or cause you some trepidation, depending on the process. We had a couple controllers lock up one day while I was sitting there viewing them in the engineering interface. I saw lots of red Xs and no information whatsoever for a large number of loops on the operator console. One was a loop that controlled acid concentration going to a fixed-bed hydrogenation reactor with many millions of dollars of relatively soft catalyst. Had the valve failed shut on communication loss, the ensuing increase in viscosity might have crushed that expensive catalyst. I remember walking briskly out to the unit to alert the operations supervisor to my concerns, but he said all was well. Apparently, the valve assumed its designed failure state and saved the catalyst. "Hold Last" is the default behavior for most fieldbus valve positioners on communications loss.
"Hold last position" may be a good choice for process robustness, but what if it causes some concerns for safety? A failed loop is usually an "initiating event" in a process hazards analysis (PHA or HAZOP), and so the rule says you can't take credit for any safeguards provided by that same loop. If it gives some added comfort, the standard analog output (AO) block in FF provides some parameters for fault behavior. With the proper configuration, any FF control valve can be set up to go to a preconfigured position on loss of communication. One parameter sets the time in seconds that the function block will wait for communications to resume, and another sets the value in percent that the positioner will aim at to open or close the valve.
If this sounds complicated, don't forget we had the same considerations for many conventional I/O cards, which have a configurable behavior for power-up and communications loss. You can email me your specific concerns, and hopefully I'll spot them among all those "unread" messages I now have.
