Diagnóstico y alarmas: cuando el sistema explica qué le pasa

Señalizar no es explicar

En una instalación convencional, cuando algo falla, lo que suele haber es una lámpara que se enciende. O un contacto que se abre. O un térmico que se dispara. El sistema dice que algo pasó, pero no dice qué.

Eso es señalizar. Es útil, pero es limitado. El técnico que llega tiene que reconstruir la historia: seguir el circuito, medir, comprobar contactos, descartar posibilidades. La lámpara indicó que había un problema, pero no cuál.

Un sistema con diagnóstico hace otra cosa. No solo dice que algo falló: dice qué falló, en qué parte del proceso, en qué momento y, muchas veces, qué condición no se cumplió. La diferencia entre una lámpara y un diagnóstico es la diferencia entre saber que hay un problema y saber cuál es.

Y esa diferencia no se resuelve con más lámparas. Se resuelve con lógica.

Qué es un evento

Un evento es cualquier cosa que el sistema detecta que ocurrió. Una bomba que arrancó. Una válvula que se abrió. Una presión que cambió. Un sensor que entregó un valor. Un pulsador que se presionó. Una protección que se disparó.

El sistema no interpreta los eventos cuando ocurren: los detecta. La interpretación viene después, cuando los compara con lo que se esperaba. Pero el evento, en sí, es solo el registro de que algo pasó.

Eso es importante porque cambia la forma de pensar el diagnóstico. El sistema no está esperando a que algo salga mal. Está observando todo el tiempo. Y cada observación es un evento.

La comparación con parámetros

Un evento, por sí solo, no dice nada. Para que tenga sentido, hay que compararlo con algo. Con una consigna, con un rango esperado, con una tabla de valores.

Si la presión es 4 bar y la consigna es 4 bar, el evento está dentro de parámetros. Si la presión es 3 bar y la consigna es 4 bar, el evento está fuera de parámetros. Si la presión es 3 bar y la consigna es 3 bar, otra vez, está dentro.

La comparación es lo que convierte un evento en información. Sin comparación, el sistema solo sabe que algo pasó. Con comparación, sabe si eso que pasó es normal o no.

Y la comparación no es solo contra una consigna. Puede ser contra un rango, contra un histórico, contra una tabla de valores admisibles, contra el comportamiento de otro equipo similar. El criterio depende del proceso.

El registro: lo que pasa, pase o no

Acá está la parte que suele pasarse por alto: el sistema registra todo. No solo lo que sale mal. También lo que sale bien.

Si la presión está dentro de parámetros, se registra. Si la bomba arrancó y alcanzó régimen, se registra. Si el variador respondió a la orden, se registra. Todo el tiempo. Pase lo que pase.

Eso es lo que hacen los históricos de funcionamiento de muchos equipos. No son listas de fallas: son registros continuos de lo que ocurrió. Y son la base para entender el comportamiento del sistema.

El registro tiene dos usos. Uno es inmediato: saber qué pasó hace un rato. Otro es acumulativo: entender cómo se comporta el sistema a lo largo del tiempo. Cuántas veces arrancó una bomba. Cuánto tardó en alcanzar régimen. Cuántas veces se disparó una protección. Cuánto tiempo estuvo en servicio.

Sin registro, el diagnóstico es adivinanza. Con registro, el diagnóstico es lectura.

Cuando el evento sale de parámetros

Ahí aparece la alarma. Cuando la comparación detecta que un evento salió de los parámetros esperados, el sistema no solo lo registra: además avisa.

La alarma no reemplaza al registro. Lo complementa. El registro deja constancia de que algo pasó. La alarma exige que alguien haga algo al respecto.

Por eso una alarma útil es una alarma que exige una decisión. Si el evento sale de parámetros y no hay nada que hacer, entonces no es una alarma: es un registro que, por algún motivo, decidimos mostrar. Y eso conviene revisarlo, porque el ruido tiene un costo.

Qué es una alarma y qué no

No todo lo que el sistema muestra es una alarma. Conviene distinguir cuatro cosas:

• Estado. Lo que el sistema está haciendo en este momento. Bomba en servicio, sistema en espera, modo automático, modo manual.
• Registro. Lo que el sistema dejó constancia de que ocurrió. Un arranque, una parada, un cambio de modo, un valor dentro de rango.
• Aviso. Algo que conviene saber, pero que no impide el funcionamiento. Una presión cercana al límite, un filtro que empieza a saturarse, un mantenimiento próximo.
• Alarma. Un evento que salió de parámetros y requiere atención. Una falla de fase, una protección disparada, una variable fuera de rango.

Confundir estas cuatro cosas es un problema frecuente. Cuando todo se trata como alarma, el operador se acostumbra a ignorarlas. Cuando nada se trata como alarma, el sistema no avisa cuando debería. La diferencia no es de gravedad: es de función.

Alarmas que nadie mira

Hay alarmas que se disparan y no generan ninguna consecuencia. El sistema avisa, pero nadie hace nada. Y eso no es un problema del operador: es un problema de diseño.

Una alarma que se dispara sin que haya nada que hacer al respecto no es una alarma. Es ruido. Y el ruido tiene un costo: cuando el sistema avisa de algo que no importa, el operador aprende a ignorar los avisos. Y cuando aparece uno que sí importa, ya no lo ve.

El criterio es simple: si el operador no puede hacer nada con esa alarma, no debería estar. Si el sistema la genera, pero no hay acción posible, entonces es un registro, no una alarma. Y los registros van a otro lado, no a la pantalla principal.

Una alarma útil es una alarma que exige una decisión. Si no exige nada, no es una alarma.

El diagnóstico como parte del diseño

Hay una idea muy extendida de que el diagnóstico se agrega al final. Primero se hace funcionar el sistema, después se le ponen alarmas. Eso es un error.

El diagnóstico no es un agregado: es parte de la lógica. Cuando se diseña una secuencia, se está decidiendo qué tiene que pasar. Cuando se diseña el diagnóstico, se está decidiendo qué registrar, qué comparar y qué hacer cuando algo sale de parámetros. Son dos caras de la misma decisión.

Un sistema que se diseña sin pensar en el diagnóstico es un sistema que, cuando falla, no puede explicar por qué. Y eso obliga al técnico a reconstruir la historia desde cero, con las herramientas que tenga a mano.

Un sistema que se diseña con diagnóstico incorporado es un sistema que, cuando falla, dice qué falló. Y eso cambia por completo la forma de mantenerlo.

El diagnóstico no se programa al final. Se piensa desde el principio, junto con la lógica.

Qué conviene diagnosticar y qué no

No todo necesita diagnóstico. Diagnosticar de más es tan problemático como diagnosticar de menos.

Conviene diagnosticar lo que puede fallar y lo que, si falla, requiere una acción. Un sensor que puede desconectarse. Una fase que puede faltar. Un actuador que puede no responder. Una variable que puede salirse de rango. Una secuencia que puede no completarse.

No conviene diagnosticar lo que no puede fallar, o lo que, si falla, no cambia nada. Un contacto auxiliar que siempre está cerrado. Un valor que nunca cambia. Una condición que ya está cubierta por otra alarma.

El criterio no es la cantidad de alarmas, sino la utilidad de cada una. Un sistema con pocas alarmas bien pensadas es más útil que un sistema con muchas alarmas que nadie usa.

Y hay algo más: el diagnóstico no es solo para fallas. También sirve para entender el comportamiento normal del sistema. Y eso es exactamente el registro: la información que ayuda a mantener la instalación aunque no haya ninguna falla.

El reloj: sin tiempo no hay historia

Hay un detalle que decide buena parte de la utilidad del registro: el reloj de tiempo real. Si el sistema registra eventos, necesita saber cuándo ocurrieron. Y no todos los PLC tienen reloj integrado.

Algunos equipos lo traen de fábrica. Otros no. Y cuando no lo traen, el sistema lleva una cuenta de tiempo mientras está energizado, pero pierde la referencia al reiniciarse. El registro queda sin fecha confiable, o con una fecha que hay que reconstruir.

Cuando el PLC no tiene reloj, hay formas de resolverlo: sincronizarlo desde una HMI, desde una PC, desde un servidor de tiempo en la red, o manualmente al arrancar. El PLC no sabe qué hora es, pero puede recibir la hora de otro equipo que sí lo sepa.

Es un detalle de diseño, no una limitación del equipo. Pero conviene tenerlo presente cuando la instalación va a registrar eventos. Un evento sin marca de tiempo dice qué pasó, pero no cuándo. Y eso hace que el diagnóstico sea mucho más pobre: no se pueden correlacionar eventos, no se pueden ver tendencias, no se puede saber si un problema ocurre siempre en las mismas condiciones.

Prioridades y jerarquías

No todas las alarmas son iguales. Algunas detienen el sistema. Otras solo informan. Otras requieren una acción inmediata. Otras pueden esperar.

Si el sistema trata todas las alarmas con la misma urgencia, el operador no puede distinguir lo importante de lo accesorio. Y en una situación crítica, eso es exactamente lo que no se necesita.

La jerarquía no es un detalle de presentación. Es parte del diseño. Una alarma crítica debe ser visible, audible, difícil de ignorar. Una alarma informativa puede esperar. Una alarma de mantenimiento puede registrarse sin interrumpir la operación.

Y la jerarquía también define qué pasa con el sistema. Algunas alarmas detienen el proceso. Otras solo bloquean una maniobra. Otras solo registran. Esa decisión se toma al diseñar, no al configurar la pantalla.

Un ejemplo: presión constante

Retomemos el sistema de presión constante del artículo anterior. Una bomba, un variador de frecuencia, un sensor de presión en la cañería, una consigna de 4 bar.

¿Qué eventos puede detectar el sistema? La presión actual. La velocidad del variador. El estado de la bomba. La señal del sensor. Cada uno de esos eventos se compara con lo que se espera. Y cada uno se registra, pase lo que pase.

Cuando alguno de esos eventos sale de parámetros, aparece la alarma. Y cada alarma le dice al técnico qué buscar:

• Sensor desconectado. La señal está fuera de rango. El sistema no puede regular. Se detiene y avisa.
• Variador no responde. La orden se dio, pero la velocidad no cambió. El sistema detecta la discrepancia y avisa.
• Presión no alcanzada. El sistema dio la orden máxima y la presión sigue baja. Puede haber una fuga, una bomba descebada o una obstrucción.
• Presión oscilante. El lazo no está estabilizando. Puede ser sintonización, puede ser una perturbación externa.
• Presión fuera de rango. La presión superó el máximo permitido. Puede haber un problema aguas abajo. El sistema detiene la bomba.

Ninguna de esas alarmas es un simple aviso. Cada una le dice al técnico qué buscar. Y eso es exactamente lo que diferencia un sistema que señaliza de un sistema que explica.

Diagnóstico y mantenimiento

El diagnóstico no solo sirve para reaccionar cuando algo falla. También cambia la forma de mantener la instalación.

Un sistema que registra cuántas veces arrancó una bomba, cuánto tiempo estuvo en servicio, cuántas veces se disparó una protección, permite anticipar el mantenimiento. No hace falta esperar a que algo falle: se puede intervenir antes.

Eso no es lo mismo que monitoreo remoto. El monitoreo remoto es la posibilidad de ver desde otro lado. El diagnóstico es la capacidad del sistema de entender su propio estado. Son dos cosas distintas, y ambas son parte del mismo recorrido.

El diagnóstico convierte el mantenimiento correctivo en mantenimiento preventivo. Y eso, a la larga, es más barato y más confiable que esperar a que algo se rompa.

Documentar eventos, alarmas y registros

Una alarma sin documentación es un mensaje sin contexto. El sistema avisa, pero nadie sabe qué hacer con ese aviso.

Documentar no es listar códigos. Es dejar escrito qué significa cada evento, qué parámetro se compara, qué acción requiere cada alarma y qué pasa si se ignora. Eso es lo que convierte el registro en una herramienta de diagnóstico.

Sin esa documentación, el operador tiene que adivinar. Con esa documentación, el operador sabe qué hacer. Y el técnico que llega después no tiene que reconstruir nada: lee el registro y entiende.

La documentación no es un trámite. Es parte del sistema. Un sistema que explica lo que le pasa, pero no deja escrito qué hacer al respecto, sigue siendo un sistema que depende de quien lo diseñó.

Resumiendo...

Un sistema no solo avisa cuando algo sale mal. Registra todo lo que pasa. La alarma es solo la parte del registro que requiere atención.

El mecanismo siempre es el mismo: un evento ocurre, se compara con parámetros, se registra, y si sale de lo esperado, además dispara una alarma. Sin evento no hay nada que comparar. Sin comparación no hay forma de saber si algo está bien o mal. Sin registro no hay historia. Y sin alarma, lo que sale de parámetros pasa desapercibido.

Eso no se agrega al final. Se diseña desde el principio, junto con la lógica. Y se documenta, para que el que venga después no tenga que adivinar.

Un sistema que explica lo que le pasa es un sistema que se deja mantener. Y eso, al final, es lo mismo que venimos diciendo desde el principio: automatizar no es programar. Es convertir conocimiento del proceso en comportamiento controlado. Y también en información útil.

El cluster de automatización y control

Reúne catorce artículos sobre automatización y control. Es un compendio de criterios de diseño: cada artículo aborda un tema y muestra qué decisiones hay que tomar, por qué se toman de una manera y no de otra, y qué consecuencias tiene cada elección.

El objetivo no es enseñar a usar una herramienta, sino entender qué se está resolviendo antes de elegir con qué resolverlo.