DISEÑO DE LAS ALARMAS DE UNA CENTRAL

diseño alarmas de un central
En el estudio de la gestión de alarmas, se han centrado multitud de empresas y organizaciones, y se han escrito muchos trabajos y estándares. Este artículo intenta aportar un punto de vista práctico con un ejemplo de “LA CONFIGURACIÓN DE LAS ALARMAS EN UN PROYECTO INDUSTRIAL”.

1. SEÑALES, EVENTO Y ALARMAS
2. LIBRO DE ALARMAS
3. ARQUITECTURA DE CONTROL
4. ESTAMPACIÓN DE TIEMPO
5. GESTIÓN DE LAS ALARMAS


--------------------------------------------


1. SEÑALES, EVENTO Y ALARMAS


Antes de empezar, hay que diferenciar entre “1º señales”, “2º eventos” y “3º alarmas”.


Son tres entidades diferentes que deben estar listadas e identificadas de forma independiente.

1º “Las señales” son las variables que nos permitirán supervisar y controlar la central. Estas variables pueden ser, analógicas (variables que pueden adquirir un rango de valores) o digitales (variables que sólo aceptan dos estados 0 o 1). Las señales también se pueden clasificar cómo: cableadas, comunicadas o internas (con internas queremos decir que son generadas por el propio controlador).

2º “Los eventos”, algunas de las señales (antes mencionadas) se registrarán como eventos.

Por ejemplo, durante la secuencia de arranque de un sistema, podrían arrancar varias bombas o cerrar y abrir algunas válvulas. Estas operaciones, se podrían considerar como eventos. Estos eventos serán registrados, en la página “secuencia de eventos”.


Lo habitual es que todos los eventos sean provocados por la activación o desactivación de una o varias señales. Pero, no todas las señales se consideran de interés como para tener que almacenarlas como eventos.


La secuencia de eventos se puede agrupar en una pantalla independiente del SCADA. Esta pantalla, nos mostraría todos los eventos, indicando el momento exacto en el que suceden, como se muestra en el siguiente dibujo (la pantalla de eventos se ordena según hora y fecha de inicio).

Si se presenta una situación anómala, la secuencia de eventos nos podría ayudar a determinar que ha sucedido. Pero para poder discernir el problema, se necesita tener definido y configurado el sistema de eventos correctamente.


3º “Las alarmas”. Por lo general todas las alarmas se suelen registrar como eventos (por lo que también, se podrán ver en la pantalla de secuencia de eventos) pero no todos los eventos generan alarma.

Las alarmas, además de ser registradas en la página de eventos, se registrarán en otra página específica sólo para alarmas.

Cuando una alarma se activa, normalmente se produce un sonido que alertará al operador.
En el ejemplo que se muestra en el siguiente dibujo, para apagar el sonido habrá que silenciarlo pulsando sobre la bocina. Además en la parte inferior de la pantalla hay un pequeño banner, donde se visualizan continuamente, las tres últimas alarmas.

Nota resumen: Todas las alarmas generan eventos. No todos los eventos son alarma. No todas las señales generan eventos. Para poder configurar: las señales, los eventos y las alarmas correctamente en cualquier proyecto, antes se deberían identificar y definir y listar cada señal, evento y alarma.

2. LIBRO DE ALARMAS

No se puede mejorar los que no está claramente definido en ningún sitio, por lo que, para poder optimizar las alarmas, debemos partir de un listado (que llamaremos libro de alarmas).

Un libro de alarmas no es un listado de señales (en el SCADA, “las señales” y “las alarmas” son dos entidades diferentes con su código y descripción independiente).

En dicho libro entre otras cosas se debería anotar:

- Fecha de modificación. Este listado nunca estará cerrado, las alarmas de una central es un elemento vivo que periódicamente requiere ser revisado y mejorado. Por lo que es conveniente, disponer de un procedimiento para tener un control de cambios de dicho documento.

- Categoría. Las alarmas, se suelen dividir por categorías para poder asignarles distinto nivel de importancia. En este ejemplo, se han definido las siguientes 4 categorías:

   o Alarmas de categoría 1. En este grupo, se podrían agrupar, todas las alarmas que van a indicar una situación de peligro, disparos eléctricos o paradas de emergencia de los sistemas principales de la planta.
   o Alarmas categoría 2. En este grupo, se podrían agrupar, a las alarmas que provocan una parada controlada de la central.
   o Alarmas categoría 3. En este grupo, se podrían agrupar, todas las alarmas que requieren intervención, pero no afectan a la disponibilidad inmediata ni a la seguridad de la central.

   o Alarmas categoría 4. Estas alarmas, señalizarán una situación anómala que no requiere de intervención inmediata.

- Código. Todas las alarmas deben de tener un nombre único que la diferencia del resto. Este código debe estar estandarizado para toda la central y debe ayudar a poder identificarlas.

- Descripción. Establecer una descripción adecuada de cada alarma, es una de las tareas más laboriosas y difíciles. Realmente una descripción adecuada de cada alarma, será la herramienta más útil que pueda ayudar a un operador a afrontar una situación de emergencia. El primer paso, para establecer una adecuada descripción, es conocer el número máximo de caracteres (en minúsculas o en mayúsculas). Por ejemplo, se podría poner la descripción en mayúsculas para alarmas categoría 1 y 2. Esto ayudaría a identificarlas, rápidamente.

- Sistema al que pertenece la alarma.

- Información adicional sobre la señal que provoca dicha alarma. Por ejemplo, el valor que provoca la activación de dicha alarma.

- Acción. Por último, en el libro de alarmas se debe indicar, que acción debería realizar el operador en caso de activación de dicha alarma. Si la alarma no conlleva ninguna acción asociada, quizás deberíamos plantearnos si es realmente necesaria. Uno de los grandes problemas más extendido en las centrales industriales es disponer de un número excesivo de alarmas sin ninguna acción asociada.

Ejemplo de libro de alarmas:


3. ARQUITECTURA DE CONTROL


Para poder tener un buen sistema de alarmas el punto de partida es contar con una arquitectura de control adecuada. Hay cientos de posibilidades. Vamos a poner un ejemplo de como una señal acaba generando una alarma que se mostrará en la pantalla del operador.

- Un detector de bajo caudal (switch de caudal) envía la señal a un PLC.

- El PLC, está supervisando el valor de caudal si este valor se mantiene en cero durante más de 15 segundos el PLC generará la señal comunicada que leerá al servidor principal de la central y será registrada como alarma.

- El servidor principal de la central es un ordenador que registra los datos de interés que circulan por los PLCs. Este servidor cederá parte de estos datos a los ordenadores que hacen de SCADA.

- Los ordenadores que hacen de SCADA son los ordenadores que están viendo los operadores.

En este ejemplo, la señal ha viajado por varios equipos hasta mostrarse en la pantalla del operador: Instrumento --> PLC --> Servidor --> SCADA.


En paralelo a esto suele haber otro ordenador, servidor que ejerce de historizador. Este ordenador registra los eventos registrados en el servidor principal y los valores de las señales analógicas en cada momento. Esto permitirá hacer gráficas o análisis de los eventos sucedidos en cualquier periodo de tiempo.


4. ESTAMPACIÓN DE TIEMPO

Uno de los principales problemas, para poder interpretar adecuadamente las alarmas, es saber con exactitud cuando han sucedido.

Para ello previamente, se deben sincronizar los equipos con la misma referencia temporal. Por ejemplo se pude instalar de un servidor de tiempo GPS y sincronizar los equipos a través de la una red Ethernet TCP/IP, IRG-B...

Una vez los equipos saben que hora es, hay varias opciones de generar la estampación del tiempo.

   1º Hacer la estampación en la tarjeta de entradas.
   2º Hacer la estampación en el PLC.

   3º Hacer la estampación en el servidor.



1º Hacer la estampación en la tarjeta de entradas:



Hay tarjetas especiales capaces de realizar la estampación de tiempo, conocidas como tarjetas SOE (Secuence Of Events). Esto quiere decir que cuando la señal cambia de valor, la propia tarjeta registra el nuevo valor y cuando ha sucedido. Dicha información, será transmitida de la tarjeta al PLC y del PLC al servidor.



Hasta ahora, esta ha sido la forma más precisa de registrar adecuadamente el valor de tiempo (pero estas tarjetas son el triple de caras que las tarjetas normales). En muchos proyectos durante la fase de ingeniería, para las señales de disparo eléctricas se requería instalar tarjetas SOE. Esto permite conocer con precisión la secuencia de disparo de las protecciones eléctricas en caso de fallo, principalmente para poder discernir que elemento actuó primero.



2º- La segunda opción, es realizar la estampación en el PLC:



Los PLC modernos, tienen una pila reservada para registrar eventos. Cuando una señal cambia de estado, si se ha programado un evento asociado, el PLC puede memorizar el nuevo valor con la hora en la que ha sucedido.



El problema es que el PLC realizará esta anotación, cuando le toque dentro de su secuencia de ciclo (mientras que las tarjetas SOE, registran la señal prácticamente al momento, sin esperar a lea todo el programa del PLC).

Por otro lado, los PLCs han evolucionado exponencialmente y los ciclos de lectura cada vez son más rápidos. Actualmente el ciclo de los PLC es tan rápido que resulta difícil justificar si realmente las tarjetas SOE siguen siendo prácticas.

3º- La tercera opción es realizar la estampación en el servidor. El servidor cuando registre el dato puede anotar el momento en el que ha sucedido. En este caso además de depender del ciclo del PLC se sumará el ciclo del servidor (esta filosofía, no sería la más adecuada para interpretar una secuencia de disparos en las protecciones eléctricas).

5. GESTIÓN DE LAS ALARMAS

Una vez se ha configura una correcta sincronización horaria de equipos y una estampación adecuada de cada señal. El servidor cederá este dato al SCADA.

En nuestro ejemplo, en el SCADA, sonará una sirena y se verá el registro de la alarma en la parte inferior de la pantalla, como en el siguiente ejemplo:
En cualquier momento el operador, puede acceder a la pantalla que agrupa todas las alarmas.
En nuestro ejemplo, las alarmas no reconocidas se mostrarían parpadeando. El operador hará doble click encima para reconocer cada alarma, cuando lo considere oportuno.

Si la señal que ha provocado la alarma, permanece activa, la alarma se visualizará en rojo claro (en la parte de la derecha se indica, la fecha y hora cuando se generó dicha alarma).

Si la señal que provoca la alarma se ha desactivado, la alarma se mostrará en rojo oscuro (en este caso, en la parte de la derecha además de indicar, la fecha y hora cuando se generó dicha alarma, se indicará la fecha y hora fin en la que la señal que provoca la alarma se ha desactivado). En este caso decimos que esta alarma ya no está activa.

Las alarmas que no están activas y que ya han sido reconocidas por el operador, desaparecerán automáticamente de esta pantalla general de alarmas. El propósito de esta pantalla, es que la información mostrada, sea la mínima necesaria que se considera relevante para la gestión adecuada de la central. No obstante en la pantalla de eventos se podrá seguir viendo todas las alarmas que se han producido.

Nota: Esto ha sido sólo un ejemplo, de cómo se decidió gestionar y mostrar las alarmas del SCADA en un proyecto concreto.

Actualmente en las centrales industriales, se están instalando nuevas herramientas, aplicaciones y programas capaces de hacer todo lo que podamos imaginar. Sin embargo, muchas de estas herramientas no parecen estar utilizándose de la forma más adecuada.

Uno ejemplo de esto, son los sistemas de gestión de alarmas de las centrales industriales, sistemas que cada vez son más potentes, pero sin una ingeniería adecuada cada vez serán más ineficaces.

A continuación, se indican algunos enlaces de interés, que quizás nos puedan ayudar a adquirir un poquito más de sabiduría sobre este tema, y así poder afrontar mejor un proyecto similar:

https://www.linkedin.com/pulse/el-problema-de-las-alarmas-en-la-industria-víctor-daniel-parra-mateo/

https://www.linkedin.com/pulse/primeros-pasos-en-la-gestión-de-alarmas-midiendo-el-del-parra-mateo/

https://www.linkedin.com/pulse/mejorando-los-kpis-de-alarmas-forma-rápida-y-sencilla-parra-mateo/

https://www.linkedin.com/pulse/errores-que-hacen-fracasar-los-proyectos-de-mejora-del-parra-mateo/




Si tiene algo que corregir o añadir agradecería que me mandara sus comentarios a:
InstrumentacionHoy@gmail.com
Julio César Fernández Losa 21/03/2020

5 comentarios:

  1. Gracias otra vez por otro interesante articulo .Sigue asi

    ResponderEliminar
  2. Antes las alarmas me acuerdo que las ibas creando una a una, por lo que siempre tenias bajo control el alarmero, ya que creabas normalmente lo que necesitabas, ni mas ni menos.
    Hoy en dia un problema bastante grande suelen ser los creadores de programas en bruto por modulos, como SGStudio de Schneider o el DCS7 de Siemens, que te crean (si no tienes cuidado) a bulto un monton de alarmas por cada entrada analogica y digital, por cada modulo de motor, de valvula etc...con lo que de primeras te quedas con un alarmero que parece un arbol de Navidad...he tenido que resolver este problema en varias plantas y la verdad que es muy laborioso identificar y filtrar todo lo que se crea de esta manera.

    ResponderEliminar
    Respuestas
    1. Gracias por tu aporte, el sistema de alarmas es un indicados claro de la salud y de lo eficiente que es una instalción

      Eliminar