Slashdot Mirror
BP Gulf of Mexico Rig Lacked Alarm Systems
DMandPenfold writes "BP's monitoring IT systems on the failed Deepwater Horizon oil rig relied too heavily on engineers following complex data for long periods of time, instead of providing automatic warning alerts. That is a key verdict of the Oil Spill Commission, the authority tasked by President Barack Obama to investigate the Gulf of Mexico disaster."
http://www.nytimes.com/2010/06/21/us/21blowout.html?_r=1&pagewanted=all
'Failure of management' and regulators given blame for disaster
http://www.chron.com/disp/story.mpl/business/7367856.html
How British oil giant BP used all the political muscle money can buy to fend off regulators and influence investigations into corporate neglect.
http://www.newsweek.com/2010/05/07/slick-operator.html
This wasn't a technical failure - it was a failure brought out by greed and corruption. The blow-out was only the symptom, and addressing the symptom isn't going to prevent similar incidents from happening again.
We've seen this before - the mortgage disaster and bank bailouts, the savings and loan disaster, etc.
Start by fixing campaign financing - private donations only, strict annual limit per capita, no 3rd party involvement, etc.
-- Barbara
Indeed. Alarm suppression is a complex thing to set up in many cases. I personally work in the business and know how much thought goes into the alarm handling of the plants operating in Norwegian waters.
One example of a "simple" suppression case is that if Controller A goes down, you do not need to tell the operator that ALL signals on this controller is in "bad quality" or out of bounds. What you need to tell them is that the controller is down, and which systems are affected (which they will see on their displays as valves change color or somesuch. Our system uses white asterisks and white color to indicate that something is 'dead')
More complex cases are things like not throwing alarms for low flow rates in pipes where the valves are closed, or not throw electric alarms on equipment set to maintenance mode.
Regardless of all this, there should be an alarm system that has priorities.
Pri 1 alarms are such that they require IMMEDIATE attention. Such as a dangerous triple-high alarm (HHH or 3H) of a tank, pressure or temperature or a controller going down.
Pri 2 would be alarms that could develop into Pri 1 if not handled within a few minutes (H/HH) alarms etc.
Pri 3 would be what we call "pre-alarms". Things that could cause process upset or issues down the line. Like a low flow of coolant even though the temperature of the equipment being cooled hasnt started raising yet. Or a low level in a fuel tank.
Pri 4 we usually assign as maintenance issues. Like two redundant sensors having more than 0.5% deviation between them (But not enough to cause a real alarm). Things that should be looked at but within a day or so.
Being able to filter alarms like this helps immensely during an emergency. This is an old system with a limited number of 'alarm groups' and 'priority levels' but it still works fairly well. Operators can see what happens even with several hundred alarms going off at the same time. On our simulator we did a fun test where we tripped 70% of the plant (about 18000 distinct 'tags' or io points went into Bad quality and several thousand in alarm). :)
The operators were able to stop the cascade failure and no pipe burst in the simulator
Shit -will- hit the fan. It is always nice to be able to filter it so that only the important shit actually hits the wall :p