We also have a history of treating operators as less important to the operation of the plant as the engineers and managers, when, in fact the operator of a process plant is much more like a pilot of an aircraft. They are responsible for the safe operation of the plant, and the optimization of the plant, and they should not be burdened, as so many of them are, with busy-work because some top manager noticed that they weren't busy when he entered the control room. Really, good operators earn their salary during those thirty seconds of terror when the plant is in upset, just like pilots do when something goes wrong with the plane.
If we just were able to look at operators in this way, and make improving their HMIs and training critical, we could reduce accidents and save lives.
We now know that operator response to abnormal situations is highly dependent on how the information is presented to them. The BP accident shows clearly that fact. If the operators had been able to easily see both the flow in and the flow out of the raffinate splitter tower, it is highly likely that they would have intervened long before they did.
We understand this but we have not been able to build this into the routine engineering dogma of control systems and safety systems.
We have seen the output of the ASM consortium. We have seen the EEMUA guidelines. And we continue to overload operators with too many inputs, too many distractions, and too many jobs to do.
Properly, the only parts of a process that an operator should be seeing are the ones that aren't working properly, or that the operator is engaged in optimizing. Yet many HMIs are designed with lots of motion, pretty colors and three dimensional effects– because it is cool and has lots of marketing sizzle.
Many HMIs are designed and installed with minimal input from the operators, because the operators are very often considered non-professional labor– to be told where to go, and what to do by engineers and managers.
I encourage you to consider that operators are highly skilled technical professionals, whether they are trained engineers or not. This is the intent of the ISA's Certified Automation Professional designation– automation isn't an engineering discipline. Automation is a multidisciplinary profession that includes engineers, operators, scientists, and technicians.
The operator needs to be in charge of the process he or she is operating… and we need to provide the tools to really be in charge.
Operators cannot handle hundreds of alarms every minute and be in charge of the process.
Many people have real problems with IEC61508, IEC61511 and ANSI/ISA84.01-2004. We're educated to be project-oriented. We propose projects, we get projects approved, funds are dedicated to those projects, and we do the project and then it is over. And so, with process safety projects, process optimization projects, and alarm management projects, we have first success, then gradual decay after the project people turn the "project" over to the operations staff.
But safety, alarm management, security and operator training are not amenable to project-oriented engineering thinking.
They are inherently processes, and they are best managed as continuous processes, and there are very few of us who instinctively think in those terms.
But if we are to meet the intent of the safety standards, and more than that, we are to begin to operate on the basis that all these topics form an inter-related and interdependent interconnected system, we are going to have to think instinctively in process terms rather than project terms.
Since the money comes from highest management, it doesn't matter fundamentally if we can change our thinking about alarm management, optimization, safety and security projects and begin thinking of them as issues that require continuous process control and process optimization themselves.
If we cannot communicate the importance of this paradigm shift to higher management, nothing will change, and people will continue to die.
Physical security is another interrelated issue. How many fewer people would have died at BP if the operators had been able to detect the drivers of the diesel pickup truck as they moved into the danger zone, and stopped them? No one will ever know. But in emergency situations it is critical to have firm control of the perimeter and to know where all of your people and your assets are. Knowing where a fire truck or a staff member with first aid or CPR training is, and being able to vector them to the area of most need can make the difference between deaths and survival. And where better to have the information than in the control room, as part of the operators' gestalt?
As I said, cyber security issues must be considered in any safety implementation in any process plant, just as safety issues must be considered when administering IT security issues. I talked earlier about a hack of a safety system. That particular safety system hack was accomplished as part of a penetration test by Wurldtech as requested by the safety system manufacturer. Is your safety system secure, or just safe? Was it engineered in a vacuum, or was it designed in cooperation and understanding of all the interacting factors in your plant? Do the operators live, breathe and eat safety and security? Does your management? Are these core values for your company, and if not, why aren't they?
We are about to lose the last generation that knows how to operate our plants manually. We are about to lose a terrific amount of institutional knowledge and we are hard pressed to replace that institutional knowledge that we are losing– and that lack of training has been shown to contribute materially to accidents like the BP Texas City accident. And if we do not provide operators the highest level of training, we will surely see people die.
Would you want to fly from here to Shanghai with a pilot with 10 years' experience, or with a pilot whose experience is 90 days in a simulator? How about running your plant?