HMI Specifications

[mhowasso 5]

Hi, Is there an HMI specification that anyone uses that specifies the colors, objects, screen layout, etc., etc. that they would share. Thanks,

[Crossbow 295]

I've found most customers do not document their HMI requirements well. When I walked into a plant and they handed me their PLC spec, it detailed brand and processor, as well as their required modules for inputs and outputs. So all my input modules had to be the same type, same for outputs, same for analogs, etc. But when asked about their HMI requirements, they had nothing. No vendor, no size, no number of colors, amount of memory, required features, nothing. Not even a document saying what their standards were for color scheme.

[RafaelMankilla 0]

Are you looking for an HMI? Are you trying to reverse engineer an HMI program? Here are some HMI's you can look at if you were shopping it has a training manual that includes all the specs you are asking for. rafaelmankilla http://www.lcdtouchscreen.org

[Digita7Voic3 0]

Here are some standards I have developed and followed in my short humble career: 1. ALWAYS USE THE GRID 2. Color Scheme for Devices (Valves/Motors/etc): Gray - Off Green - On Red or Yellow (Ask customer for preference) - Faulted/Fail Tip: Stay away from using Red for indicating that something is off or closed.. red should mean something is wrong. Gets operator's attention. 3. Try to keep navigation simple and intuitive. Make it so that they only can go to a certain screen on way. Except for Home and Alarms screens Navigation. Try to keep these 2 buttons readily accessible in the same location throughout your application. If they get lost or need to address alarms they will know where to go, no matter what screen they are on. 4. Try to separate a system overview, system details and system setpoints. Some operators don't have any business in the setpoint screens, they just need enough buttons to run the process (give them what they need and nothing else). 5. Establish a User Security Schema. Example: View Only, Operators, Maintenance, Managers, and Super Users (Admins). 6. Try not to overpopulate screens with objects. 7. If this is going to run in a touch screen interface, design it from the BEGINNING to function in a touch screen environment. (Large Buttons, adequate space between clickable objects) 8. Input range validation on inputs values. Make sure you only give them a valid operating range on setpoints and other numeric inputs. (However, this should not replace PLC code, just another layer of protection and notification) 9. Keep a standard layout on all your pop ups and button positions. Try to keep the close button always in one spot, the order of the buttons on Hand / Off / Auto controls, etc. 10. Have good contrast in your color scheme. Make it easy to read and be aware of glare problems for outdoor installations. 11. LISTEN to the Operators and Managers. They are going to use the thing every day! Not you! If they don't like something, change it! Usually its something that wont go against your layout or color standards. This is always a win win, trust me. If its something significant, go over the suggestion with his/her supervisor. By the way, these are just some of the ones I go by.. I cant think of anything else at the moment... Hope it Helps! I am interested on hearing other peoples suggestions.

[PLCMentor.com 60]

Nice List! We do go back and forth between red for off/closed and grey. People joke about the stoplight mentality, but it is something that is natural to just about anyone. If we use red for off/closed then we usually flash any alarm. I will say that some SCADA/HMIs do not flash well so grey for off is preferable. We also use yellow for intermediate or ramping for drives. I will add to number 7 on touch screen design that all motor/valve/sequence activations should be two touch. In other words to start a motor you would touch the motor on the screen to bring up a popup that will have start/stop buttons. In systems (mostly older) that do not allow for popups, touching the motor will take the operator to a special start stop screen. The big no no is to put the motor on the screen with start/stop pushbuttons next to it for control. Invariably someone comes through for show and tell day and points to the screen a little too emphatically and starts the motor. Usually more of a demonstration than they wanted. It also is usually the plant manager or someone from upper management showing a client around. Not a great sales tool. Having an overview screen with little or no controls is a plus. Generally the specification would allow touching specific individual processes on that screen to "zoom" into the actual control screen. The security levels listed are good. Their definition needs to tie into the PLC control definitions also. Generally operator control gives normal processing control of the system. Supervisor control gives override, mode change and approval capability. Maintenance gives the ability to change equipment and process modes. That ties into the PLC definitions of Automatic, Manual and Maintenance controls of the equipment. Automatic is fully sequenced according to the process description. Manual allows the control of individual equipment with all permissives, and Maintenance allows control of individual equipment with permissives overridden (except safety). But now I have rambled on to plc definitions... Hard to put a spec into a forum, but Digita's points were a good overview.

[BobB 58]

IEC standards list red as off or safe. I have a job at the moment where the electrical consultant has specified white as run or on, red as fault, white for in auto, red for in manual. Then in the next breath for ATS units he has green for open, red for closed, amber for alarm/faulkt, red for lockout. Then the next gasp for the battery chargers green for AC on, red for AC off amber for faults. Try and work that lot out! He is an idiot - however. I often have motorised valves ti indicate. I normally use a blue background - keep getting told grey is not a colour, The valves have a white outline so when the valve is in no mans land the valve is blue with a white outline. When open green with a white outline and closed is red with a white outline. seems to work well.

[Sleepy Wombat 27]

If you have done work in a power station.. RED is ON - energised - ie danger amd GREEN is OFF -SAFE... Although in some applications (water treatment) I would have green for open, red for closed and blue for transition (ie not open or closed) and yellow for a fault. This scheme is also followed with pumps.

[Mark- 17]

What 'Sleepy Wombat' said is true for many power plants here. In paper mills, petro chemical plants, factories with rotating high energy kilns, ovens used for chemical burn off, etc. many times red is used when the state is dangerous. For example, if the fuel valve is open that is dangerous even if the state is OK. Green is safe even if not the desired state. Which tends to lead to red is open/running, green is closed/stopped. In many marine applications a 'dark panel' approach is used. Dull colors are used when something is OK. So, when in operation if all conditions are as expected/normal a quick glance at a panel all the colors will be dull. If it was a light panel all the lights would be off. Bright things (red, a lamp on) are an indication of trouble. Edited 25 Nov 2011 by Mark-

[OkiePC 14]

I think the list is very good too. One thing we do to get around the red vs. green argument is to use purple for alarms. Usually a flashing purple or fuschia color or a toggling of two shades of pinkish purple does a nice job of highlighting faulted devices or alarms. This almost never will overlap or contradict a company's existing color standards (or lack thereof). Another practice to add to the list: The following addresses the Importance of "dead" or white space on a page: During page navigation, the new page should not have an active object in the same location as the button from which the navigation took place. You don't want the operator to double tap the page navigation button and have the page change between taps and some inadvertent action to take place because the new page has a control object in that spot. I try to make menu navigation happen with a standardized menu bar so that the button for the active page becomes unavailable (grayed out) when you are on that page. This button bar typically resides at the bottom of all pages and its mere existence, being one of the first objects designed in the HMI application, keeps the designer from using that space for control objects. I normally put alarm messages at the top line of the display on my "master slide" on all pages. And, I try to make it so that touching the alarm banner navigates to the alarm history or active alarms page. Edited 25 Nov 2011 by OkiePC

[Digita7Voic3 0]

OKiePC is very right regarding placement of navigation controls. I have seen other integrators do this and really gets on my nerves. lol This is an example of the HMIs I create: http://forums.mrplc.com/index.php?showtopic=22018 Minimal to no control in the main overview screen. Navigation in the top, alarms in the bottom. Sometimes I can merge the alarm summary and navigation in the top if I need the space. I also tend to add: Automatic log off. 'None' user is Read Only (can not make any changes at all, just navigation). Pop ups for device controls (motors/valves/etc). Historical Trending & Events and Alarming Logging. Tell me what you guys think. -Julio Velasco