Introducción a las alarmas

La gestión de alarmas es una parte fundamental en la automatización industrial, ya que permite monitorizar y responder a eventos críticos en los sistemas controlados por el PLC.

¿Qué es una alarma?

Una alarma es una señal que indica una condición anormal o un evento que requiere atención en un sistema.

Importancia de las alarmas

Las alarmas son cruciales para garantizar la seguridad, eficiencia y confiabilidad de los procesos industriales. Permiten a los operadores identificar y resolver problemas rápidamente, minimizando el tiempo de inactividad y evitando daños a los equipos.

Tipos de alarmas

Existen diferentes tipos de alarmas, como alarmas de proceso, alarmas de seguridad y alarmas del hardware, etc., cada una con su propia prioridad y alcance. Todas estás alarmas se agrupan y gestionan dependiendo del tipo de evento o NIVEL de severidad, lo que facilita la respuesta adecuada por parte del personal de operación.

Niveles de alarmas

En la siguiente tabla se establecen los niveles de alarmas con los que trabaja el framework.

Alarma	Nivel	Acrónomo	Descripción	Rearme
Sin alarma	0	-	Sin alarma	-
Información	1	`a1i`	Alarma de información	Automático
Advertencia	2	`a2w`	Alarma de advertencia	Manual o automático
Error	3	`a3e`	Alarma de error	Manual
Emergencia	4	`a4f`**	Alarma de emergencia	Manual

¿En qué parte del programa se gestionan las alarmas?

Cuando empecé a programar PLCs, me enseñaron que todas las alarmas se gestionaban desde un único lugar del programa, normalmente dentro de un FC llamado Alarms (1), si eras un poco ‘osado’ usabas una FB (2).

Las alarmas eran almacenadas dentro de un DB global llamado por ejemplo DB_Alarms (3) en el mejor de los casos se alamcenaban como variables boolenanas, en el peor de los casos se almacenaban como bits dentro de un byte o word (4).

El rearme era global, un bit de rearme en el mejor de los casos, en el peor de los casos la entrada del rearme directamente (5). Cuando el bit de rearme o la entrada se ponían a 1, todas las alarmas se rearmaban a la vez, había dos variantes, o se rearmaba al principio del bloque o al final (6).

Cada segmento gestionaba una alarma (en el mejor de los casos).

Vi esta forma de gestionar las alarmas en muchos proyectos y en muchas empresas, esto lo vi hace 20 años y lo sigo viendo hoy en día.

FIN

Analicemos la historia

(1, 2, 3) Acoplamiento: Agrupar todas las alarmas en un único bloque del programa es una Mala Práctica debido a que genera acoplamiento en la jerarquí del programa, lo que dificulta el mantenimiento y la escalabilidad del sistema.
(4) Granularidad: Almacenar las alarmas como bits dentro de un byte o word reduce la granularidad de las alarmas, lo que dificulta la identificación y resolución de problemas específicos.
(5) Integridad: La señal de rearme debe ser tratada y evitar poner la entrada digital directamente porque puede quedarse bloqueada, es más la entrada digital debe ser diagnosticada para evitar su propio fallo. El rearme debe ser un pulso generado por el programa.
(6) Movimientos intempestivos: Quizás lo más peligroso de esta historia, un rearme global puede generar movimientos intempestivos en los actuadores ya que todas las alarmas se rearman a la vez y de manera incondicional, lo que puede provocar situaciones de riesgo para las personas y para los equipos.

Nuestro enfoque

Para evitar el acoplamiento y mejorar la granularidad de las alarmas, éstas se gestionan en cada contenedor de objetos, así cada contenedor es responsable de sus propias alarmas, lo que facilita la identificación y resolución de problemas específicos.

Las alarmas se estructuran dentro del contenedor de objetos de la siguiente manera:

_objectContanier
└─ 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

Las estructuras a1i y a4f son opcionales dependiendo de las necesidades del contenedor de objetos, lo importante es que cada contenedor de objetos tenga su propia estructura de alarmas, lo que mejora la modularidad y la mantenibilidad del sistema.