Is there a standard for HMI alarm/fault messages?

d-man

Member
D
Join Date
Jun 2012
Location
Michiagn
Posts
2
Is there are standard for what an alarm or fault message must say? More specifically, what details must be supplied in a fault message? For example, if I have the PLC advance a cylinder and the device does not reach the end of the stroke and the prox does not detect that the cylinder in the advanced position, is the message "Cylinder Fault" a good enough message?

I am looking for standards from any authority that offers guidance on HMI messages for fault/alarms of industrial automation equipment.
 
No, "Cylinder Fault" is not a good enough message.

I would prefer something like "Cylinder #1 - Not at Advanced Position" or something like that. You're probably going to have multiple cylinder faults or something like that so the more specific you can make them the better it will be for everyone.
 
Provide as much information as possible within the character limitations of the display device. "Cylinder extend fault" provides more information than "Cylinder fault". "Cylinder failure to reach full extension" provides even more. "#1 Conveyor diverter cylinder failure to reach full extension" is even better.
The more information you can display, the easier for the operator or maintenance technician to correct the problem.
 
Just "Cylinder Fault" is pretty cryptic, doing something like "Cylinder X Position Fault" would at least give them a better idea of the issue.

As far as standards go, if you google "ISA 18.2 standard for Alarm Management" it has some information that may be relevant for you.
 
Anyone have an industry standard reference ? NFPA79, ANSI, ISA? Anything.

I have a supplier that is providing very vague fault/alarm messages. They are claiming that our controls spec did not specify the details of what a fault message should have. I argue that the messages do not direct anyone to the specific device that caused the fault.
 
"Cylinder Fault" is almost definitely not a good enough message. It MIGHT be okay if there is only one cylinder, and it can only fail in one way. Otherwise, you need more information.

Someone with a basic knowledge of the machine/system should be able to walk up to the HMI, read the alarm text, and figure out exactly what is wrong. Ideally, they should be able to know what to do to fix the machine as well.

Steve Bailey's "#1 Conveyor diverter cylinder failure to reach full extension" is pretty useful. Having the ability on the HMI to display additional information, such as likely causes would be even better.
 
I agree with Steve (and others here) on providing as much information as possible... BUT you are sometimes (often) limited by the alarm viewer window on your HMI as to the number of characters you can display. In that case, be as specific as you can within the limits of your system. We have overcome this limitation at times by generating multiple alarms, to specifically point out what and where the fault is: e.g. "Cylinder Fault" "Cylinder #1" "Cylinder Extension Fault". More work for the programmer, but sometimes it is the only way to get specific. YMMV, but you have to work within the limits of your particular system.
 
Be precise.
Be consistent.
Use terminology that operators approve.
Use those terms throughout the system from CAD drawings, to PLC comments.

Sometimes you can't use operator terminology when it too vague, vulgar or misleading. In those cases try to get a sensible consensus and educate the whole team.

Pick a format in advance that works well for the whole application. For example:
"Cylinder #1 Failed to Extend" or "Failed to Extend Cylinder #1" or "Extend Fail: Cylinder #1"

Often the first and last word of a line of text when viewed or sorted in a list form is important. Do you need to be able to sort or quickly identify alarms by machine station, failure mode, device type, etc. Thinking through some of that can help you arrive at a completed system that is more effective than a haphazard or inconsistent approach.

I have found that there is a limit to how many words an operator can remember when he calls to tell you about an alarm. For some operators, that limit is 2. Getting too wordy can be detrimental. Put the extra word in the alarm details page where available along with some text describing what to look for to fix it.
 
OkiePC said:
Be precise.
Be consistent.
Use terminology that operators approve.
Use those terms throughout the system from CAD drawings, to PLC comments.

Sometimes you can't use operator terminology when it too vague, vulgar or misleading. In those cases try to get a sensible consensus and educate the whole team.

Pick a format in advance that works well for the whole application. For example:
"Cylinder #1 Failed to Extend" or "Failed to Extend Cylinder #1" or "Extend Fail: Cylinder #1"

Often the first and last word of a line of text when viewed or sorted in a list form is important. Do you need to be able to sort or quickly identify alarms by machine station, failure mode, device type, etc. Thinking through some of that can help you arrive at a completed system that is more effective than a haphazard or inconsistent approach.

I have found that there is a limit to how many words an operator can remember when he calls to tell you about an alarm. For some operators, that limit is 2. Getting too wordy can be detrimental. Put the extra word in the alarm details page where available along with some text describing what to look for to fix it.
Click to expand...

I give the Operators an alarm number right at the beginning of the message. If they remember nothing else, give me that number and I can find the alarm.
 
d-man said:
Anyone have an industry standard reference ? NFPA79, ANSI, ISA? Anything.

I have a supplier that is providing very vague fault/alarm messages. They are claiming that our controls spec did not specify the details of what a fault message should have. I argue that the messages do not direct anyone to the specific device that caused the fault.
Click to expand...

As others said, depending on the hardware being used you might have to live with some compromises on the alarms. Generally speaking, you aren't going to find any standard on alarm text that is broadly accepted.

If you haven't provided any spec to the supplier, how were they suppose to know? This happens all the time unfortunately, customer wants something, but doesn't provide a specification, or the spec is out-of-date, or it's to general so the supplier gives you what they think is appropriate for the price you paid.

In this situation, a good supplier should see your concern and work with you to work out a solution. However if there were no clear expectations set other than "the system will provide alarms as required", they certainly can claim to have meet that requirement.
 
Dravik said:
I give the Operators an alarm number right at the beginning of the message. If they remember nothing else, give me that number and I can find the alarm.
Click to expand...

Ideally the alarm message will present enough information, so the operator doesn't have to consult you.

You don't work 24 hours a day / 7 days a week.

Don't encourage people to have to contact you for heavens sake!
 
janner_10 said:
Ideally the alarm message will present enough information, so the operator doesn't have to consult you.

You don't work 24 hours a day / 7 days a week.

Don't encourage people to have to contact you for heavens sake!
Click to expand...

Heh, An example error message that I got called on last night.

"Alarm_Bits\104 4/17/2017 4:32:31 PM In Alarm: Melt 5 Pressure High"

Trust me, I'm glad I have the \104 in there, because I STILL get calls. Not sure how to make that one more obvious :D
 

Similar Topics

J
IFix Standard HMI PAK 900 I/O Ver 4.5
Hi Experts; Any friends know where from i download the DEMO IFIX Ver 4.5? Regards
Replies
0
Views
1,752
jcp
J
Mandel314159
Safety Standard For Grippers in Robotics
After some interesting conversation regarding the safety of emergency stops, I saw some posts talking about the safety standard conversation...
2
Replies
24
Views
601
Mandel314159
Mandel314159
C
Programming AB Servo with standard PLC vs PLC w/motion option
I have programmed servos from a handful of variety of manufacturers and series. Each time I used a PLC without motion functions. I have not worked...
Replies
9
Views
728
Peter Nachtwey
Peter Nachtwey
0
A1000 and EPIC David standard speed mismatch
Hello, I'm am engineer for a plastic manufacturer. We swapped out a oem motor with one of equivalent nameplate stats made by marathon on our roll...
Replies
3
Views
484
0nezer0
0
P
Standard servo jitter
I am trying to implement a sfift-by-wire on a vehicle and for that I am using a standard servo motor...
Replies
0
Views
321
pankaj_k
P
Back
Top Bottom