Introduction to Alarms

Alarm management is a fundamental part of industrial automation, as it allows monitoring and responding to critical events in systems controlled by the PLC.

What is an alarm?

An alarm is a signal that indicates an abnormal condition or an event that requires attention in a system.

Importance of alarms

Alarms are crucial for ensuring the safety, efficiency, and reliability of industrial processes. They allow operators to identify and resolve problems quickly, minimizing downtime and avoiding equipment damage.

Types of alarms

There are different types of alarms, such as process alarms, safety alarms, and hardware alarms, each with its own priority and scope. All these alarms are grouped and managed depending on the type of event or LEVEL of severity, which facilitates the appropriate response by operations personnel.

Alarm levels

The following table defines the alarm levels used by the framework.

Alarm	Level	Acronym	Description	Reset
No alarm	0	-	No alarm	-
Information	1	`a1i`	Information alarm	Automatic
Warning	2	`a2w`	Warning alarm	Manual or automatic
Error	3	`a3e`	Error alarm	Manual
Emergency	4	`a4f`**	Emergency alarm	Manual

Where are alarms managed in the program?

When I started programming PLCs, I was taught that all alarms were managed from a single place in the program, usually inside an FC called Alarms (1), if you were a bit daring you used an FB (2).

Alarms were stored inside a global DB called, for example, DB_Alarms (3). In the best case they were stored as boolean variables, in the worst case they were stored as bits inside a byte or word (4).

The reset was global — a single reset bit in the best case, or in the worst case the reset input directly (5). When the reset bit or input went to 1, all alarms were reset at once. There were two variants: either the reset happened at the beginning of the block or at the end (6).

Each network managed one alarm (in the best case).

I saw this way of managing alarms in many projects and many companies, 20 years ago and still today.

END

Let’s analyze the story

(1, 2, 3) Coupling: Grouping all alarms in a single program block is a Bad Practice because it creates coupling in the program hierarchy, making maintenance and scalability difficult.
(4) Granularity: Storing alarms as bits inside a byte or word reduces alarm granularity, making it harder to identify and resolve specific problems.
(5) Integrity: The reset signal must be processed and you should avoid connecting the digital input directly, because it can get stuck. Furthermore, the digital input itself should be diagnosed to detect its own failure. The reset must be a pulse generated by the program.
(6) Unexpected movements: Perhaps the most dangerous part of this story — a global reset can cause unexpected movements in actuators since all alarms are reset simultaneously and unconditionally, which can create hazardous situations for people and equipment.

Our approach

To avoid coupling and improve alarm granularity, alarms are managed within each object container, so each container is responsible for its own alarms, making identification and resolution of specific problems easier.

Alarms are structured within the object container as follows:

_objectContainer
└─ alarm
   ├─ level # USINT
   │
   ├─ a1i # STRUCT
   │  ├─ triggered # UINT
   │  ├─ id # UINT
   │  ├─ map # Array[n] of INT
   │  ├─ a00_name # BOOL
   │  ├─ a01_name # BOOL
   │  ├─ ...
   │  └─ aNN_name # BOOL
   │
   ├─ a2w # STRUCT
   │  ├─ triggered # UINT
   │  ├─ id # UINT
   │  ├─ map # Array[n] of INT
   │  ├─ a00_name # BOOL
   │  ├─ a01_name # BOOL
   │  ├─ ...
   │  └─ aNN_name # BOOL
   │
   ├─ a3e # STRUCT
   │  ├─ triggered # UINT
   │  ├─ id # UINT
   │  ├─ map # Array[n] of INT
   │  ├─ a00_name # BOOL
   │  ├─ a01_name # BOOL
   │  ├─ ...
   │  └─ aNN_name # BOOL
   │
   └─ a4f # STRUCT
      ├─ triggered # UINT
      ├─ id # UINT
      ├─ map # Array[n] of INT
      ├─ a00_name # BOOL
      ├─ a01_name # BOOL
      ├─ ...
      └─ aNN_name # BOOL

The a1i and a4f structures are optional depending on the needs of the object container. What matters is that each object container has its own alarm structure, which improves modularity and maintainability.