Monday, August 25, 2014

Are we updating the right standards?

Recently an article titled "Prevent Tank Farm Overfill Hazards" by WL Mostia from SIS-TECH Solutions was published on ControlGlobal. In this article Mostia briefly describe some of the spectacular overfill events, which have happened during the past 10 years, such as Buncefield in 2005 and Catanõ in 2009, and then continue to describe the regulatory changes, that has been implemented sinces these events, such as the recent 4th edition of API 2350 in 2012.

However, what really court my interest was the subtitle of the article by Mostia "Catastrophic Incidents Have Led to Useful Rules for Systems That Help Avoid Them". Especially since Mostia in the article describes how Buncefield had both a level gauge and an automatic high level shutdown, and at Catanô the tank monitoring application was not operational at the time of the event. To me this sounds a lot like maintenance failure was the course of these two events. Do we have a standard - prescriptive or not - for instrumentation system maintenance and testing?

To be honest, I don't know is such a standard exist. However, I would consider the failure to maintain the instrumentation at Buncefield a management failure. So do we need a management standard? Of course not, but we do need companies with better management control of their operations including the integrity of these.

It actually reminds my of a visit to a major US  Gulf of Mexico refinery more than 10 years ago. As the bus with 25 professors - mostly US - drove onto the site our host and guide reminded us that this refinery was run and maintained by engineers. This implied, that everything may not look pretty, but that they had control with the integrity of every tank, piece of process equipment, piece of pipe and other equipment on the site.

I thing that to create a step change in process safety we don't need more and/or better prescriptive standards, such as opdated API 2350's, but we do need more focus from both management and other employees on the potential consequences of something not working properly or being out of service.

Thursday, August 07, 2014

Process Operators - an overlooked resource for process improvements?

When I was working as a computer control engineer at a major Canadian oil company early in my professional life, I was fortunate to work with a process operator, who knew the process extremely well. Recently I read piece by A. Sofronas in Hydrocarbon Processing title "Random deck vibration with beats", in which he describe how process operators alerted the engineers to a an intermittent problem with a deck on which four centrifuges were mounted. Once in a while deck would shake every few seconds with a beat sound. This occurred for a few seconds and then stopped. Then it did not happen again for weeks or months. Without the eyes and ears of the field operators a problem such as this, would have gone unnoticed until equipment damage was observed. Mr. Sofronas story reminded me of the close collaboration I had with one particularly one operator.

At the major Canadian oil company operators were allowed to created their own displays on the DCS.  The mentioned operator had created two displays with a large number of DCS process values on each display. One display the reaction area and one display was for the purification area. Each process values was shown a vertical bar with a marker for the setpoint if any. The operator used these two displays to determined the state of the plant, when his shift started and to decided on adjustments to move a more optimal plant state. The bars were scaled so at the optimum operation they all had more or less the same height. Unfortunately as a control engineer I did at the time not see the opportunity to turns these displays into a tool for all operators to improve plant operations. I guess I was to focused on the displays, which my colleague and I had created to see the opportunity.

However, I did have excellent collaboration with the mentioned operator on the development of computer control structures for the the purification area. On his day shifts we would discuss how computer control could help operations and improve performance. Then I would design the necessary control strategies, and he would test them when he went on night shift. After such a night I would have charts on my desk showing how the strategy performed, and were he believe adjustments were called for. After a couple of itterations he would then test the strategies during day time, so final tuning could be performed, and the new strategy documented on a DCS display from which it could also be operated. All our strategies were designed, so they could be activated both from the instrumentation console and from the computer console. The fact that a respected operator had been involved int he development and testing made for easy acceptance of the strategies by the other operators.

I came away from this experience thinking, that operator involvement often is an overlooked ressource, when consultants or head office staff implement new control strategies at our plants. Usually they don't have the time to get to know the operators and gain their confidence. This leads to missed opportunities. What do you think? What are your experience with operator involvement in control projects?

Later the mentioned company went on to created a constraint based optimization of the whole purification area. A key to the success of this control project was the involvement of the operators in the creation of the displays needed to operate the strategy. In fact the operators was so pleased with the optimization, that they left the strategy on overnight after just two days of testing.