I have been fortunate to spend a large amount of time working in control rooms across different industries and in several countries. But, I have frequently seen and heard many of the operators talking about the same challenge; the difficulty in understanding the incoming alarm messages almost always seems to be an issue. 

With my own eyes I have seen operators receiving an incoming alarm and not understand its meaning, let alone what to do after the alarm was described in the detail. Theses operators would revert to the manuals, ask other operators for their opinion, or call the process engineers.

As an industry, we have come along way to go in terms of considering when alarms should be activated, and by whom. But when it comes to the content of the message, there is still little content available; there must be a better way to write messages so that our operators can comprehend and react faster, right?

Alarm messages come in many forms, and with ISA18.2 we have split these messages into multiple components -- such as Tag Comment (24 characters), Purpose, Consequence, Time-to-respond, Guidance, etc. 

Below are a few simple tips that can make meaningful improvements in writing alarm information (Including the Tag Comment)

1. Relevant to the operator

One of the most critical components towards writing a good alarm message is to think from an operator’s perspective.

• What do they need to know?

• What information or knowledge do they have available?

2. Concise

Operators are normally busy. But when things go wrong and the alarm rate increases it is important that we have stripped out any trivial information so that our operators can focus their attention on what matters.

So we must only feed operators with information that they actually need to achieve their goals; nothing more, nothing less.

3. Consistent

Messages should be consistent and based on standard, agreed-upon terminology and abbreviations that are known and used by operators.

For example there are many ways to say that a tank is reaching its maximum limit such as:

1. Tank 1 is approaching HH limit

2. Tank 1 is reaching its HH limit

3. T1 approaching HH

Each of the messages above is explaining the same key point, but they are all conducting it in a different manner.

In all facilities you will have many alarms that are explaining the same key challenge, by utilizing the same words, structure and abbreviations you can significantly increase the operator’s comprehension speed for the incoming alarms.

4. Outcomes focused

Once I have finished one of our HAZOP style alarm workshops most attendees have normally heard me say the following 1,000 times.

From an alarm message perspective the first component is key -- “Every alarm should result in an operator action”; so when we are writing our alarm messages we should be focused on telling the operator what the problem is and then trying to guide towards the appropriate action to be taken.

5. Easily readable

Alarm messages should be presented in a manner that is clear, well structured, quick and simple to read. We do not want the operator to lose valuable seconds due to poor language used in the message.

6. Duplication of content

Depending on the automation platform, when an alarm is displayed to an operator it typically includes the following information: Date/Time stamp, Tag name, Severity, and the alarm message (Topic of this post).

If the system is ISA18.2 compliant, the operator can then drill down to access other information such as guidance, time to respond, etc.

When writing our alarm message we should ensure to not duplicate other information that is already being provided to the operators.

For example on some HMI systems the operator will always be shown the tagname, so in that case we should ensure to not include the tagname in the message to ensure that we are not duplicating the same information.

7. Operator language/terminology

Operators are amazing employees who know their facility in extreme detail; but they know their facility from an operations perspective.

The core goal of alarm systems is to support the operator; therefore it is critical that alarms are written in a manner that matches the operator’s language, training and mental model.

As engineers and managers, we are too focused on achieving the alarm metrics that are set in the ISA18.2 standards without thinking about the content of our alarm messages. Too often people believe that a simple alarm message is not important. but for an operator, achieving a small improvement in an alarm message translates to a significant impact on his daily work.

When creating a new alarm message or reviewing existing alarms, I always try to review our message based on the above list, and as a result I have found that the improved messages are always appreciated by the operation teams.

Did you enjoy this article? Follow us on LinkedIn.. Or please CONTACT US.