Dramatic Fault Graphics on SCADA Screens - Thoughts?

I was replacing a VFD today, and when I powered down the MCC bucket, the SCADA went into alarm (as I would expect it to). I acknowledged the alarm and glanced at the screen. Some movement caught my eye, and I looked closer at the animated graphics... then laughed. Instead of the usual "red" faulted condition, the integrator added some animated flames to the graphic. I thought that was pretty dramatic just for a powered-down VFD. But it did catch my eye. So I'm trying to decide if it was a good idea, or not so much. I'm also curious which SCADA package they're using. I know they just had an upgrade recently. Anybody recognize the flaming graphic? What do you think about using a flaming component to signal a faulted state?

Not a fan of that. An inexperienced operator might assume it was a legitimate fire, and call 911.

There are many places for a dry sense of humor in the automation world but I strongly believe that HMIs for critical processes are not such a place.

I can't really tell what HMI package but the graphics look like one of the graphic add-ons that are common to a few packages, like Wonderware Intouch classic. Most still look like they were drawn in MSPaint on an old 386.

I have used some funny graphics, fortunately the customers were ok with them.
One was on a soup manufacturing plant, during idle times a "CHAD" would pop up out of the vessels with a caption "WHAT NO SOUP", another was on some production packaging lines, the level entries would display animated graphics depending on the level entry, i.e. Cleaners was a man standing on a hosepipe with a large bubble behind him in the pipe while looking at the nozzle wondering why no water, Engineers was an engineer knocking 7 bells out of a gearbox with a hammer, production was a tortoise, ambling along.
You have guessed it, mickey taking of the different trades.

Yeah, I also find this graphic inappropriate.
Don't say there is a fire when there is no fire, no matter that it is just a joke.

The only slightly humorous that I do is that in case there are no alarms, I show a smiley face where the alarm banner would be.

I would be interested in knowing what variable/tag the fire graphic is tied to. Is it possible that the animated fire graphic was intended to actually indicate a probable fire?? Is there a thermocouple input somewhere that pegs at max when the VFD or "MCC bucket" is powered down? If so, then IMO that's what should be fixed.

The fire is definitely a bit over the top, I would personally remove it and leave the red on the MCC section.

EDIT: If there's not an actual status bit tied to the fire graphic like busarider mentioned.

Skull and Bones / Jolly Roger could be put there for a faulted device. But simple red is more appropriate.

usually under "help" menu and then "about" selection will tell you the software manufacturer and version.

Jim3846 said:

usually under "help" menu and then "about" selection will tell you the software manufacturer and version.

Click to expand...

I wasn't there to work on the SCADA, so I stayed on task and focused on the installation. I thought about it on the way home.

It has an InTouch look to me.

As far as the burning graphic meaning something special, all of my municipal water and waste-water customers only use VFD relay outputs to get feedback from the VFDs. None are network connected, so they don't know *what* the fault is, only that the drive is faulted. Most of them just get "Running" and "Faulted" from the relay outputs (a very few will also add "OK to Run"). The best way to configure the fault is: Closed is "not in fault". That way, if the fuses are blown for the VFD, or if the power is off, it shows up in the SCADA as a fault. Some integrators just use N/C terminals, and program the relay output for "Fault". This method doesn't account for main power issues, like blown fuses, or a 'blown-up' drive. N/O relay output terminals, and "Not Faulted", or "Inverse Fault" for the RO settings is the better choice. Most of you guys know this, but some less-experienced programmers might be reading this, as well.

I don't mind dramatic graphics but they're hardly necessary and I probably wouldn't go that far myself.

I agree that fire is poorly suited unless the application is actually detecting an overheat condition.

Nova5 suggested Skull and Bones, but these days with ransomware being a thing that might have poor connotations as well.

You know.... I *get* the desire to add fancy animations to the screen. Part of me likes the flames. But the 'adult' in me realizes that it is misleading and could cause confusion with the unexperienced operator. I think thumbs are down on this.

I'll be programming screens soon with "overtemperature' and 'overpressure' alarms. I might play with it a little to see what I can come up with... taking in consideration that customer had a factory fire that destroyed their facility about 11 yrs ago (probably am not going to use the flames).

Looking at picture, I find this design very ineffective. I have good vision and I have problems understanding what is situation on that screen and I'm 30cm from screen. That numerical data does not help anything if operator does not know what is L,LL,H,HH, and SP. I think that if you can't understand what is happening in plant, buy looking at screen from at least 5m distance, your design is not good.

The flame is bad enough, but why hasn't anybody pointed out that the two backwash pumps aren't connected to the pipes?

I don't use flames, instead I use glowing orange cut-outs for my cure ovens. If a flame goes out on any of them, the cut-out turns grey, and a banner pops up to explain the reason for the failure. Our operators found it easier then looking at a bunch of red and green dots. Maintenance still has to look at the red and green indicators, but they are really the only ones who need to understand the interlocks and fault codes.