What's the status of Foundation fieldbus specification for Safety Instrumented Functions (FF-SIF)? A few weeks ago, Masoneilan's (www.dressermasoneilan.com) Rick Castaneda posed the question on the FF LinkedIn group. The status is: Good luck finding any product, either in reality or even on suppliers' "roadmaps." Mike O'Neill of Stahl (www.rstahl.com) offered an explanation: "Seems to be that users are quite happy with separate emergency shutdown (ESD) packages." Maybe it was the juxtaposition of "happy users" and "ESD packages" that struck a nerve for me. Where I sit, it isn't happiness with the status quo at all, but the sheer volume and velocity of SIF applications.
According to my neighbors in the petroleum refining business, there is no joy in SIS-ville. To start with, a safety instrumented system (SIS) is, ideally, a piece of automation that never does anything; that is, if the plant runs safely and in control, there's never a demand on the SIS. It's a "layer of protection" that your layer of protection analysis (LOPA) team or consultant has determined needs to be there. But invoking it means a measurement related to the safe operation of the plant has been exceeded, and the plant is coming down immediately. That's not really a happy day for anyone.
In the analysis that follows an unplanned trip, it's common that the instruments and controls are "guilty until proven innocent." And even after proving the trip wasn't spurious, the controls guys will have to defend why the regulatory controls allowed the plant to get to a dangerous state.
Logic solved by SIS logic solvers is often relatively simple. The core task is to detect an unsafe condition and slam valves shut (or open). But while the controls challenges are vanilla, the swamp of logic surrounding voting transmitters, bypasses and testing can be daunting.
Often the engineers presently tasked with implementing SIS were the ones doing esoteric and elegant multivariable-predictive control and optimizers a decade ago. When you give one of these folks a controls-light and administration-heavy project like the hydrocracker burner management system, their stress is likely to increase. Not that they will execute said SIS jobs with less diligence and professionalism; it's just unlikely they'll find those jobs self-actualizating.
For some of us, the travails of implementing an SIS in a "brownfield" site (i.e., most of them) can have a stifling effect on job satisfaction. The controls professional can struggle to find avenues to "delight his customer." Installing a burner management system (BMS) on process-fired heaters—furnaces that have operated for decades without any interlocks—is met with unhappiness by the operations department. At times, it seems like its main priority is learning how to bypass the SIS before it trips the unit.
Then there's the engineering contractor and systems integrator. Do you suppose they'd rather err on the side of "so sorry, more spurious trips," or risk the legal harpies seeking them out to gnaw at their bones and professional credentials? Add to this the Baker Commission effect—all BP's refining competitors are thinking "we have to keep up or we'll be next." In the ensuing proliferation of SIS projects, the controls engineer's job rapidly becomes 95% administrative and 5% "practicing his trade."
"Happiness" isn't likely to set in until the SIS jobs are finished and behind us—and "doing nothing" with 100% availability.
Given this consuming task of commissioning the future plant, where hazards are thoroughly vetted, analyzed and corralled with SIS when warranted, do you suppose many are thinking about the next best innovation in SIS? Who has the time or energy for that? If FF-SIF is languishing on the drawing board somewhere, it isn't that users are content with their solutions. They're just too consumed with the battle to consider a "non-conventional" path.
And why shouldn't our supplier community be content to deliver yesterday's solutions?
