Antes de la adopción de sistemas de control distribuido (DCSs) y otras interfaces hombre-máquina automatizadas (HMis), las indicaciones de las operaciones y alarmas en las plantas de proceso eran básicas, poco explicativas y estaban restringidas debido a limitaciones de espacio y tecnología. En su mayoría, las interfaces de procesos consistían en un panel o mímico instalado en la Sala de Control al que llegaban señales desde el área de procesos (a través de cables o tuberías) y encendían unas pequeñas lámparas o bombillos para generar la indicación de una condición determinada.
Cada punto de alarma debía ser cableado individualmente desde el sensor de campo; por lo que, diseñar, operar o hacer un cambio en un sistema con tan pocas facilidades era sumamente engorroso, implicaba un alto costo y el riesgo de dañar otras alarmas o indicaciones del proceso. ¡Cualquier persona lo pensaba dos veces antes de incluir o modificar una alarma!
Luego, con la implementación de los sistemas automatizados (que permiten realizar cambios y adiciones por software) el número de alarmas que pueden ser configuradas en un sistema se incrementó hasta el punto de ser virtualmente ilimitado. Es decir, el proceso pasó
de cablear, conectar puntos eléctricos, instalar tuberías, modificar de tableros y muchas horas de trabajo, a abrir un programa e ingresar el nuevo valor de la alarma.
Actualmente, las tendencias tecnológicas de globalización e interconexión de sistemas van dirigidas, incluso, a usar la nube para mantenernos informados. Este modelo, accesible y sencillo de usar, proporciona sin dudas una oportunidad de mejorar los sistemas de alarmas, pero también puede hacer que la gestión de alarmas sea una tarea desafiante. Muchas cosas pueden salir mal si no ponemos la debida atención en el proceso de seleccionar, implementar y mantener las alarmas de nuestros sistemas de control y seguridad. Solo para tener una idea, veamos algunos ejemplos:
a) Usar las alarmas que por defecto traen configurados los sistemas de control para cada canal de I/O, puede generar una gran cantidad de notificaciones innecesarias en las consolas de operación, causando confusión y posibles errores operacionales.
b) Utilizar valores genéricos para facilitar el proceso, digamos 90% del rango para alarma de alta, sin tomar en cuenta las condiciones específicas de cada variable, puede dejar una cantidad importante de alarmas inútiles o alarmas de condiciones sobre las cuales el operador no puede hacer nada al respecto; bien sea porque no tiene tiempo suficiente para actuar o no tiene las herramientas necesarias para cambiar la situación.
c) No tomar en cuenta el ajuste de los valores de las alarmas, en los procesos de manejo del cambio.
En resumen, hoy en día es tan fácil configurar una alarma que nos exponemos a crear un sistema sobresaturado de información que, en muchos casos, se desvía de su función; en lugar de ser una ayuda para el operador, termina siendo un factor de contribución de accidentes con consecuencias de importancia.
Existe una necesidad de volver a lo esencial y mantener los sistemas tan simples como sea posible, para lo cual las normativas ISA/ANSI 18.2 e IEC 62682 han realizado esfuerzos importantes. En ese sentido, quisiéramos recordarles varios básicos que nos permitan mantener la simplicidad de los sistemas.
En primer lugar, recordemos que una alarma es un medio audible y/o visible para indicar al operador el mal funcionamiento de un equipo, una desviación del proceso o cualquier condición anormal que requiera una respuesta. Esto significa que una alarma es más que un mensaje o un evento, ya que indica una condición que exige una acción rápida del operador. Cada alarma debe estar asociada a un escenario peligroso (causa – consecuencia); requerir una acción específica y brindar tiempo suficiente al operador para ejecutar la acción correspondiente. Idealmente, cada alarma debe indicar su prioridad, posible causa raíz y un procedimiento de respuesta recomendado; así el operador podrá actuar rápida y eficazmente.
La próxima vez que esté en el proceso de crear una alarma, le recomendamos que intente verificar si la misma cumple con todas las características que menciónanos a continuación:
- Relevante: Debe tener un valor operativo.
- Única: No debe estar duplicada por otra alarma.
- Oportuna: La activación de la alarma no debe ocurrir mucho antes de que la respuesta del operador sea necesaria, o demasiado tarde para poder responder a la alarma.
- Priorizada: Se debe indicar la importancia de que el operador responda a la alarma.
- Comprensible: Debe tener un mensaje claro y fácil de entender.
- Funcional: Debe identificar el problema que ha ocurrido.
- Indicativa: Debe mostrar la acción que debe ejecutar el operador.
- Precisa: Debe llamar la atención sobre las condiciones más importantes.
La observancia de estos aspectos básicos le permitirá generar alarmas que realmente soporten las actividades del operador y, en consecuencia, crear mejores sistemas de alarmas.
Recuerde, “manténgalo simple”.
«La simplicidad es la máxima sofisticación.»
Leonardo Da Vinci, polímata florentino del renacimiento
Anakarelys Díaz
FSEng TÜV SÜD TP18051528
Romel Rodríguez
Functional Safety Expert TÜV SÜD TP18010990 | ISA84/IEC 61511 Expert | FSEng TÜV Rheinland 575/07 | PHA Leader