POST 3 · ISA 18.2 SERIES

Building the Foundation: Alarm Philosophy and Rationalization

An Automated NSW Smart Solutions Guide

Publish Date: 07/30/26

Most alarm system problems don’t start with bad hardware or bad tuning, they start with a document that was never written. Facilities will spend real budget on sensors, programming, and graphics, and skip the one deliverable that decides whether any of it actually works, the alarm philosophy. It’s easy to see why it gets skipped, it doesn’t show up on a screen and it’s not on anyone’s punch list. But every decision covered in the next two posts only holds together if it traces back to a documented, agreed-upon set of rules. That document is the alarm philosophy, and the process of applying it alarm by alarm is called rationalization.

What an Alarm Philosophy Actually Is

The alarm philosophy is the governing set of rules that everything downstream has to follow. Without it, every engineer who touches the system makes their own judgment call about what should alarm, how urgent it is, and what color it should flash. Those decisions pile up into the inconsistent, over-alarmed systems most facilities are stuck with today.

 

Required vs. Recommended Content

The standard splits philosophy content into requirements (SHALL) and recommendations (SHOULD). Both matter, but if you’re starting from nothing, the required list is your minimum viable document.

 

The Elements Worth Getting Right

Not every section of the philosophy carries equal weight. A few decisions here shape everything that follows:

• Purpose and scope. Define which systems and areas the philosophy actually governs, and where its authority ends.
• Classification and priority scheme. Settle the structure early. Revisiting it after rationalization has started means redoing completed work.
• Rationalization methodology. Document how the process itself runs, not just its outputs.
• Performance targets. Set measurable goals up front so later audits have something to compare against.
• Change management tie-in. State plainly that alarm changes only happen through the documented process. That one line prevents most long-term drift.

Why Order Matters

Writing a philosophy after the system is already built, to retroactively justify what’s already there, just documents the existing mess instead of fixing it. The philosophy has to come first, even if that means pausing other work to get it done.

Rationalization: Applying the Rules

Rationalization is the process of taking every alarm and running it through the philosophy to decide whether it should exist, what should trigger it, how urgent it is, and how it should be classified. Needless to say, it’s tedious work. It’s also the step that does the most to reduce nuisance alarms, because it forces a documented answer to a question most systems never ask: does this alarm actually require the operator to do something?

For more information on what constitutes an alarm vs an alert, check out post 2 of this series: ISA 18.2 – 2 – What is an Alarm

 

The Justification Test

Every alarm has to survive one question: does this require a specific, timely operator response to avoid a consequence? If the answer is no, it isn’t an alarm. It might still be useful as a log entry or a status indicator on a graphic, but it doesn’t belong in the alarm system. This is where most legacy systems lose 30 to 50 percent of their configured alarms once rationalization is actually applied.

 

Setpoint Determination

Setpoints aren’t picked by feel. The standard ties them to the amount of time an operator realistically has to respond before the consequence occurs. If a process deviation takes 20 minutes to become a real problem, the setpoint should trigger with enough margin for detection, diagnosis, and response, not right at the edge of failure. This is also where deadband and delay settings get their first pass, though the detailed mechanics of that belong to the design stage covered in the next post.

The Master Alarm Database

Every rationalized alarm gets a permanent record: its tag, setpoint, priority, classification, justification, and consequence of inaction. This database becomes the reference point for design, training, and every future audit. If a setpoint gets questioned two years from now, the answer should already be written down, not reconstructed from memory.

Handling Rejected Alarms

Rejection doesn’t mean deletion and silence. Document why the alarm was rejected and what happened to it instead, meaning whether it was removed entirely, converted to an event log entry, or folded into an existing alarm. That record matters for the next time someone proposes bringing it back.

 

A philosophy without rationalization is just a document collecting dust. Rationalization without a philosophy is a group of people separately guessing at what’s right. You need both, and you need them in that order. 

Is Your System Hitting Its Targets? 

If you are designing a system with tight control requirements or working to bring an existing system into spec, contact us. We will help you get there.

www.automatednsw.com | support@automatednsw.com

UP NEXT  We cover alarm priority, basic alarm design, and HMI. The technical decisions that turn a rationalized alarm list into a working system.