Closing the loop on layer of protection analysis alarms
The refineryās fluidized catalytic cracker was engaged in a startup and the schedule was tight. While it was a net steam producer, as waste heat from reacting and regenerating catalyst was recovered in downstream units, it became a consumer during startup to keep turbines online until the process was underway. But steam availability was going to be impacted in a few hours when a neighboring unit undertook a ādrum swingā to steam the last volatile hydrocarbons from a full coke drum. The heat was on, so to speak, for the novice operator to get the reactor up to the desired temperature for the introduction of feedstock. An uninterrupted heat-up with the seldom used startup heater was essential.
What wasnāt obvious to the less experienced operator was the precise nature of the heaterās burner management system (BMS) and the measurements that participated in a trip. Like most BMSs, fuel gas pressure at the burner provided a safeguard against flame instability and a high-pressure trip was configuredābut in this case was a differential pressure, since the heater connected directly to the air flowing into the fluidized catalyst bed. Feeling the pressure to get the process underway before becoming starved for steam, the board man was pushing the heater hard, until it suddenly tripped. The question was, shouldnāt there have been a pre-alarm?
A brief investigation revealed there was a pre-alarm configured, but for some reason it had been suppressed for months. The normal suppression timeout of two shifts wasn't in force for this measurement; it wasnāt meaningful during months or years of normal production, and automation that might have normally ensured it was back in force wasnāt applied to the suppression parameter. In this case, a startup was delayed, which may have meant many thousands of dollars in lost opportunity. What about alarms that are even more impactful?
That an instrument accurately responds to a changing process condition (e.g., differential pressure) and invokes an alarm at a meaningful setpoint requires not only that the device is properly and routinely calibrated. How often do we coast through routine calibrations without specifically noting that any and all configured alarms are invoked? When an alarm is claimed as a safeguard in a layer of protection analysis (LOPA), the risk mitigation depends on a minimum of three (potentially unreliable) aspects: first, that the measurement is good (accurate, stable, timely, etc.). Second, that the alarm is enabled and annunciates at the proper setpoint with the assigned priority (which also confirms that bus and/or network subsystems are healthy). And third, that the operator can respond to the alarm (i.e. isnāt distracted or detained, and doesnāt dismiss it because it rings in all the time), and undertakes actions that will mitigate the risk. Like a three-legged stool, if any leg is wobbly or broken, youāve got nowhere safe to park your assets.
āLOPA listedā alarms have emerged in greater numbers as risk tolerance has decreased along with historic credits for innate mitigation (e.g., a safety relief valve or rupture disk). A once-in-10-year consequence that was tolerable a decade agoāsay, a financial hit of $100,000āis now something requiring action, and the old mitigations arenāt enough to cover it. Controls, alarms and interlocks that previously warranted no special management have been called upon to bridge some of the gaps. So now, the operate & maintain forces face an onslaught of new testing and validation, while corporate leaders will tolerate little that might negatively impact the bottom line (i.e., adding people). The business is showered with the promises of AI, big data, digitalization, etc., but no one mentions the tedious slog required to prove the automation system will keep the scary process within its bounds.
The magic of AI or a well-tuned digital twin might have been clever enough to forewarn the novice operator that he was careening too close to the edge, where the process has never been. But data for startups and shutdowns is meager for a well-functioning continuous plant, and often the troubles of one startup arenāt repeated (or remembered) in the next. Similar to alarm rationalization, validation and enforcement of LOPA-listed alarm limits for various operating states has become yet another laborious but necessary undertaking.