Evolution of the operator console

K

Thread Starter

Kevin Totherow

I am writing a section in a control handbook on the evolution of the operator interface. I have lots of experience in early DCS and have migrated a couple of plants from pneumatic bench board controls to DCS. I don't have a lot of early PLC HMI experience. Do any of you have opinions on evolution of the operator interface and the changing role of the operator? Any opinion of who's doing what right or wrong? Where is the HMI evolving to now?

Any opinions welcome.

 
B

Bruce Durdle

Re the changing role of the operator - check a book by James Reason, "Human
Error". ISBN 0-521-31419-4. Lots of provocative stuff like "Is it possible to over-automate a process?" (Yes - the more we automate the routine stuff, the less feel for the plant the operator has when the unusual incidents come along.) Regardless of what the bean counters think, there is still a problem at 3 am, and it is no use just saying "Don't do it again".

There is a need to keep the stimulus level of the operator right - too much
unnecessary stuff and we overload them - too little and they go to sleep. We automate the routine stuff which the operator can handle easily, but expect them to react instantly to the 1 in 1000 year type of evcent that causes a major disaster. I worked on a plant where the senior shift operator on a plant start-up had never previously been involved with a plant start in about 6 years of working there - the plant was very reliable and his shift managed to miss out.

And then there is the problem that we remove the problem of human error from the operator who at least is on the job, has some incentive to get it right, some idea of how the plant actually works after 3 or 4 years of keeping it going, but transfer it to a software jockey who is sitting in a nice clean office before the plant is even built, thinks "steam" is the white stuff that comes out of a kettle spout, and if it all goes BANG you can just press "Reset" and it will all come right again ...
 
K

Kevin Totherow

Thanks Bruce - I will find that book.

I found similar things when a senior control room operator was assigned to lend assistance on an expansion and control upgrade at a ClO2 plant. The plant was seven or eight years-old and the operator had never actually seen it. Outside man actually looks at stuff - senior man sits in the control room.

I wonder if PDA control to get the operator walking around will help or hurt?

Kevin


> Re the changing role of the operator - check a book by James Reason, "Human
> Error". ISBN 0-521-31419-4. Lots of provocative stuff like "Is it possible to over-automate a process?" (Yes - the more we automate the routine stuff, the less feel for the plant the operator has when the unusual incidents come along.) Regardless of what the bean counters think, there is still a problem at 3 am, and it is no use just saying "Don't do it again".
>
> There is a need to keep the stimulus level of the operator right - too much
> unnecessary stuff and we overload them - too little and they go to sleep. We automate the routine stuff which the operator can handle easily, but expect them to react instantly to the 1 in 1000 year type of evcent that causes a major disaster. I worked on a plant where the senior shift operator on a plant start-up had never previously been involved with a plant start in about 6 years of working there - the plant was very reliable and his shift managed to miss out.
>
> And then there is the problem that we remove the problem of human error from the operator who at least is on the job, has some incentive to get it right, some idea of how the plant actually works after 3 or 4 years of keeping it going, but transfer it to a software jockey who is sitting in a nice clean office before the plant is even built, thinks "steam" is the white stuff that comes out of a kettle spout, and if it all goes BANG you can just press "Reset" and it will all come right again ...
>
 
D

David Campain

I have to agree with Bruce Durdle's comments on the problem of the disconnect that current common HMI designs cause between the operator and the process. I was an operator for 8 years and learn't how to program the system to combat boredom and fix some of the "features" of the HMI and PLC logic. The HMI's that I have seen have many "features" that managers and programmers think are cool but may not be of much help in improving the operators performance. Companies invest $millions in these systems without any serious investment in studying the operators interaction with the system and the root causes of operator errors and how they could be reduced with thoughtful design. Integrators and vendors
should be spending far more money on human factors design before they spend a penny more on adding more "features". Even managers that are
not technically literate have wasted enough time dealing with new "features" on their PC's that they are not as impressed with bloatware as they would have been 10 years ago. They would appreciate a sales pitch that showed that a vendor was adressing the effects of poor HMI
design.

I have plenty more comments but am busy moving house to go work for an integrator where I will be working on HMI's. Hopefully I can improve
the art.

Dave Campain
 
J

John G. Boland

Hi, List,

"In the Age of the Smart Machine: The Future of Work and Power", by Dr. Shoshana Zuboff, is another thought provoking book on this topic. Written in 1988, it predates today's refined HMIs, yet addresses the underlying issues, which somehow have remained.

The book is out of print, but I recently found a used copy on Amazon.com.

Best,

John G. Boland, president
VisiBit Corporation
www.visibit.com
One Parker Square Suite 408
2525 Kell Boulevard
Wichita Falls, Texas 76308
940.322.9922
940.723.1478 fax
 
K

Kevin Totherow

Dave,

Thanks for the comments. I concur. I bet that you can really help the integrator build a more effective HMI - I just hope you can find clients that care.
 
Top