SCADA Screen Colors

E

Thread Starter

Eric J. Feight

I am looking for any articles or research data or a set of standards (like any really exist or adhered to this industry) that I can use to help me stop my customer from forcing me to develop a hideously ugly set of control and monitoring screens for a project I’m currently working on. Most of the operators are used to an old DOS based system. Black background, white text, etc. We had an initial screen design review that did not go well from a screen and object color stand point. What they came up with was ugly to say the least. I know once they get used to a more modern color scheme, they will be happier with it in the long run. I also feel that new operators who have more computer experience will find “Windows-ish” looking screens more comfortable. Is there anything out there that I can use to help make my point?
 
There are some color recommendations but basically most choices are free.
Best is to limit the number of colors in order to avoid confusions, especially as depending on hardware, driver specifications and settings, colors can be displayed differently. Also for images with a black background, single pixel wide vertical lines can appear different compared horizontal lines depending on the used hardware. With a light gray background such effects are less visible.
 
R

Rajesh Mehta

Dear Eric,

I appreciate your concern for making the mimics look as impressive as possible.

Most automation companies have their own set of standard rules for this. However, I am not aware of any international standard.

Some of the points you can keep in mind while desgning the displays:

the background should be dark: as a lighter background is very harsh on the eyes and the operator station is meant to be watched continuously be an operator.

keep the colors dull: whether background or foreground.

keep the no. of colors to be max. 8: more variations are neither easy on eyes nor look good.

color priorities: red for emergency, green for ok and all.

static colors: the static pictures if drawn in 3d and all look very impressive when you are selling but believe me I am yet to find a plant with such flashy pictures. Its always good to keep the background picture simple (2D and grey scales). The operator knows it already and he really is interested in the information.

I am sure it is only a general blah blah from my own experience. You might be doing all these things already but just in case there might be some people who would be benefitted by our experience.

May be it will be a good idea that you pick up one of the old projects and show them to your client telling him it is your standard. We did the same thing in one of he projects but telling him that we will change the background if he did not like it. It was a chance we took and it paid off at the end.

With Best Regards
Rajesh Mehta
 
G

Greg Goodman

> I am looking for any articles or research data or a set of standards (like
> any really exist or adhered to this industry) that I can use to help me
> stop my customer from forcing me to develop a hideously ugly set of
> control and monitoring screens for a project I'm currently working on.

For what it's worth, there was a thread on HMI color choices last fall:

http://www.control.com/control_com/968056082/968419643/index_htmlhttp://www.control.com/control_com/968056082/968422776/index_html
I'll add another 2 cents:

- it is your responsibility to tell your client the truth, as you see it, in no uncertain terms

- it is *not* your responsibility to make the client believe you or agree with you

- it *is* your responsibility to give the client what he wants, once he/she's been given all the facts; if the client really wants ugly screens, then give them ugly screens

- if it's really important to you that the client admit that you're right, develop two sets of screens; one set that matches their spec, and
a second set that looks like you think they should. install them both, with navigation buttons to switch back and forth. the operators will decide which ones they like and if you're right, everyone will know it. (everyone won't necessarily appreciate it, but there you go.)

if you're looking for a solid understanding of the principles of good user interface design, then i highly recommend donald norman's "The
Design of Everyday Things".

for a large collection of online resources (including another pitch for Norman's book), try:

http://www.sum-it.nl/enguilin.html
there are also a number of GUI design guidelines published online by various companies and individuals. here are two. a web search for "gui
design principles" will turn up many more:

http://www.weinschenk.com/guidelinesdemo/default.htmlhttp://www.siue.edu/~wnelson/courses/resources/GUIDesign.html
you may also want to check out the ACM's Human-Computer Interaction SIG:

http://www.hcibib.org/hci-sites/
they may be the best bet if you're looking for authoritative opinions / authentic research to bolster your argument.

regards,
Greg Goodman
Chiron Consulting
 
D

Dave Kuipers

Concerning your response:
> Some of the points you can keep in mind while desgning the displays:
>
> the background should be dark: as a lighter background is very harsh on the eyes and the operator station is meant to be watched continuously be an operator.

I built an HMI for a reactor system with approx. 500 displays. They all utilized a black background except for faceplates. A human-factors study performed early in process did not consider background color, however a final review by hf recommended a gray background (darker gray) due to increased eyestrain from the high contrast of the objects on the displays on the black background over long periods of continuous monitoring. Of course, we weren't allowed to change the displays at the end of the project.
I have since built many HMIs with gray backgrounds. You can increase contrast on objects by placing the object in a button object or other object with a black center. This works particularly well in breaker and valve symbols.

To "sell" a better interface design, you are going to have to present an alternative on a representative screen or set of screens. They most likely don't have a concept of the capabilities available with Windows applications. Change is a difficult process, but usually when shown better opportunities ideas will expand to embrace it. Good luck.
 
B

Bruce Durdle

One point to think about is the effect of the background against which the screen is to be viuewed. One set of guidelines that I have seen recommends that the average luminance of the screen should be similar to that of the wall etc that the screen is viewed against. If the background is either much darker or much brighter on average, tyhe pupil of the eye has to adjust when the eye moves off the screen 0- and I am susre that no operator keeps his or her eyes glued solidly on the scren through an 8- or 12-hour shift.

Accordingly, I prefer a neutral shade that is on the dark side if the screen is viewed against a dark area, a bit lighter if the screen is seen
against a well-lit wall.

And remember that "impressive" graphics may make the MD and other big-wigs feel impressed, but it is the poor old operator who has to live with the
result - if at all possible, they sjhould have the final say in the format that you adopt.

Bruce.
 
G

Glass, Philip

I don't believe there are any GUI standards developed specifically for process control.

Many organizations and companies do have standards for GUI screens. The most common is Microsoft. If you asked Microsoft engineers to design a Wastewater control GUI, you'd probably see realistic 2-dimensional graphics on a
battleship gray background (RGB 192,192,192). All of the operator-input symbols would be displayed on top of 3-d pushbuttons. You'd have drop-down
menus and navigation would be via a MS Explorer type navigation bar (back, forward, home, favorites, etc.).

You have to consider a number of factors before deciding on a standard. For example, if the main control computer is located in a room and the operators work outside the room, staring through a window to see the main process screen, you want big, bright, high-contrast graphics. If the operators sit in front of the computer all day and monitor the process, you might want some dull colors with a lower contrast that are easier on the eyes. If the GUI doubles as a showcase for City Hall to justify expenditures on the plant, you'll want splashy graphics (they don't know what it is or what it does but it sure is pretty). If you have an enormous process control system, you might not even use graphics at all. You might only use text display screens.

If the client has already decided, I don't know why you would use anything else. Ugly or not, they've done the hard part and told you what to use. If you think you can do better, wait until the job's done and show them nicer graphics. Maybe you'll get a change order.

Regardless of the standard you use, the key to making it work is consistency. If flashing-yellow ALWAYS represents alarm state, the operator
will know that an alarm exists from 50 ft. away. The other key is to keep it simple. You don't want to have different colors for all different alarm states based on their priority. Nobody wants to memorize 30 different color schemes and what they represent.

Bill Cosby has a simple rule about comedy. If he doesn't think it's funny, he doesn't expect his audience to think it's funny. If you wouldn't want to use your GUI every day for years, don't expect the operators to get too excited.

Hope this helps,

Phil
 
P
I do not know if anything is out there, but you have to remember who you are working for and who is paying for the project. It sounds to me that your customer just wants something basic. Live with it. Maybe you can be profitable on this project. If they want more bells and whistles, then charge them for it. If your customer wanted bells and whistles they would have asked for it. Maybe they do not want their employees playing video games with their equipment. If their operators are more computer savvy then why are they operators? The answer is they are not, most of them can't even speak English these days. All the menial labor low paying jobs are taken up
by hard working foreigners with us lazy Americans believing that we are entitled to high paying jobs playing video games. You are lucky to have
such an easy project. Have fun with it.
 
D
I must disagree with your argument that operators can't be computer savvy. Most of the operators at our plant have personal computers, and I would imagine that many are comfortable navigating around a GUI environment. Being computer
literate does not guarantee a better paying job. In fact our operators (union environment) make much more per year than most "computer savvy" people. I'm not talking about programmers and such, but CAD technicians, secretaries, etc.

Furthermore, your argument that most operators barely speak English actually supports the development of a more attractive graphical interface. A DOS-looking, mostly text based interface is much less likely to be understood
than a clean interface with graphics that indicate functional areas and equipment.

And while I agree with your statement that it is the customer that pays the bills, and therefore calls the shots, I believe that there are times when the customer may think they know what they want, but in reality they don't know what the really need. It is the job of the vendor to ensure that the customer gets what he _needs_, not what they think they need.

Dean Reimer
 
R

Ranjan Acharya

If my memory serves me correctly, the NFPA have some screen colour recommendations. You will have to check their standards database to be
sure. They can be reached on-line at http://www.nfpa.org/.

Good luck.
 
C

Chiron Consulting

> I believe that there are times when the customer may think
> they know what they want, but in reality they don't know what
> they really need. It is the job of the vendor to ensure that the
> customer gets what he _needs_, not what they think they need.

Dean,

I agree with your arguments about quality interface design, and I agree that often, what customers think they want is not what they really need. But I disagree with your assessment of the roles of customer and vendor. Customers are not children and vendors are not their parents. We have no power to "ensure" that they do the right thing. Our job is to provide education, guidance, and expertise. We give the customers the opportunity to get it right. But ultimately, customers are adults responsible for their own choices.

If a vendor provides his best recommendation, and the customer insists on making a choice the vendor thinks is a bad one, then the vendor's only
ethical choices are to provide what the customer asks for (along with a written record of his/her reservations), or bow out of the contract and
let someone else serve the client.

Regards,
Greg Goodman
Chiron Consulting
 
J

Joe Jansen/ENGR/HQ/KEMET/US

stop my customer from forcing me to develop

If that is how you feel about it, decline the project. I am sure that the people with the money to pay your salary will be happy to go to someone with a better attitude.
 
Wow... I have to strongly disagree with that last sentence. It is the job of the vendor to ensure that the customer gets what they pay for. If they
are paying for a solution, you are obligated to provide it. You are not obligated to square their solution because you can... and give them the
squared solution. I *once*, some years ago, gave the customer what they needed. Alas, what they needed was something like 3 months of addition work because another sub had not met the job specifications. In then end, everything worked... and I was never paid for any of the additional work. Most of us I suppose learn that lesson the same way... I hope on the first try <g>. I no longer confuse what I can do with what I must do.

Paul T
 
D
Okay, I stand corrected. Perhaps I wrote that last sentence and pressed "send" a little hastily. Everyone who has responded so far is correct. The customer is not a child who needs to be told what to do. However, I have worked both sides of the fence, as an OEM and a customer. As a customer, I am aware that the vendor knows more about his product/work than I do, or I'd probably be doing it myself. I *count* on the vendor to question my assumptions and standards, with respect to his body of knowledge, to ensure that I am not paying for
something I don't really need.

In my experience as an OEM, I would often question the requests of customers for certain additions or equipment that contributed nothing to the functionality of the machine. Unfortunately, as a lowly engineer, I had little influence in that regard, and essentially zero contact with the customer.

Dean Reimer
Westroc Inc.

Paul wrote:
>Wow... I have to strongly disagree with that last sentence. It is the job
of the vendor to ensure that the customer gets what they pay for. ...<
 
The HMI programmer should also be considerate of the type of lighting in the HMI viewing area. If the HMI is in a production facility, the lighting may be Mercury Vapor and/or High-Pressure Sodium and/or flourescent. The type of lighting can change the colors on the screen dramatically, making the HMI dificult to read.
 
Good luck getting them to hire you again once they've dictated every point of a project and are unhappy in the end! I would never hire someone who says nothing but "yes sir" to everything I suggest....
 
Top