Cómo funciona la detección de anomalías dentro de Captia.ai
El módulo identifica desviaciones del comportamiento normal de una señal o de un activo. La frase importante de esa definición no es desviación, es comportamiento normal: el módulo no compara contra un valor que alguien escribió en una pantalla, compara contra el pasado del propio activo. Ese pasado existe porque Captia Connect adquiere las señales en el edge sobre los protocolos disponibles en la instalación (MQTT, OPC UA, Modbus TCP, Modbus RTU sobre RS-485, OpenWebNet, IEC 870-5-102, API REST, webhooks o ficheros CSV), las normaliza en series temporales y las envía a la plataforma con buffering local, de forma que una caída de red no abre un hueco que el modelo interpretaría más tarde como un evento.
Sobre ese histórico normalizado el módulo hace tres cosas. Primero construye una referencia de normalidad por señal y por activo, que no es una media plana sino un comportamiento esperado condicionado al momento: hora, día de la semana, turno, estado de máquina y régimen de operación cuando ese contexto está disponible en la plataforma. Segundo, mide cuánto se aparta la observación actual de esa referencia y produce una puntuación de desviación, continua, no un sí o un no. Tercero, decide qué desviaciones merecen convertirse en evento: puntuación por encima de un nivel, persistencia en el tiempo y, cuando aplica, coincidencia de varias señales del mismo activo.
Esa tercera parte es la que separa un buen detector de un generador de ruido. Una desviación instantánea de una sola señal casi nunca es un hallazgo; una desviación moderada sostenida durante horas en dos señales acopladas del mismo equipo casi siempre lo es. La sensibilidad no es un ajuste técnico interno, es una decisión de operación: cuántos avisos por turno está dispuesto a revisar el equipo y qué coste tiene no mirar.
La salida vive donde ya trabaja la planta: eventos trazables en el histórico, alertas y reglas cuando el patrón se repite, dashboards por activo, línea, rol o planta, workflows para el circuito de revisión, reporting periódico y APIs hacia ERP, MES, CRM o SAP. No hay un informe aparte que alguien tenga que ir a buscar.
La frontera entre una regla de umbral y una detección de anomalías
Reglas y alertas son una capacidad propia de Captia.ai y no dependen de ningún módulo de IA. Conviene entender bien la frontera, porque el error más caro de estos proyectos es pagar analítica para resolver algo que resolvía una comparación. Una regla de umbral codifica un conocimiento que ya existe: alguien sabe que por encima de 85 grados hay riesgo, y lo escribe. Es explicable, auditable, inmediata y no necesita histórico. La detección de anomalías cubre el caso contrario: nadie sabe qué valor es malo, o el valor malo depende del contexto, o el fallo no aparece en el nivel de la señal sino en su forma, en su ritmo o en la relación entre varias señales.
| Criterio | Regla de umbral | Detección de anomalías |
|---|---|---|
| De dónde sale el criterio | Del conocimiento de la planta: consigna, límite de placa, especificación de proceso | Del propio histórico del activo, condicionado al contexto de operación |
| Qué necesita antes de funcionar | La señal conectada y un valor límite acordado | Histórico suficiente para que la normalidad del activo esté representada |
| Qué detecta bien | Superaciones de un límite conocido y estable | Cambios de forma, derivas lentas y combinaciones anómalas entre señales |
| Dónde falla | Fallos por debajo del umbral y condiciones que dependen del régimen de operación | Modos de fallo sin precedente en el histórico y señales dominadas por ruido |
| Explicabilidad ante el operario | Total: el valor superó el límite | Relativa: la señal se aparta de su patrón, y hay que mostrar contra qué se compara |
| Coste de mantenimiento | Revisar el umbral cuando cambia el proceso o el producto | Vigilar falsos positivos, reajustar sensibilidad y reentrenar tras deriva del proceso |
Las dos capacidades conviven, y el orden correcto es de fuera hacia dentro: primero las reglas que codifican lo que la planta ya sabe, después la detección de anomalías para el territorio que las reglas no cubren. El circuito se cierra cuando una anomalía repetida se entiende, se le pone nombre y se convierte en una regla automática explícita: a partir de ese momento ya no es un hallazgo, es un control. La detección de anomalías es, en ese sentido, una fábrica de reglas futuras.
Requisitos de datos: qué hace falta antes de activarlo
El primer requisito es un histórico continuo y con marca de tiempo homogénea. Los huecos no son neutros: una serie con paradas de adquisición mal marcadas enseña al modelo que cero es un estado posible del proceso, y después ese cero deja de sorprenderle. Distinguir un equipo parado de un dato que no llegó es trabajo de la capa de adquisición, no del módulo.
El segundo es una frecuencia de muestreo coherente con la constante de tiempo del fenómeno. Una deriva térmica de días se ve perfectamente con muestreo por minuto; una cavitación o un pico de par no se ve con muestreo por minuto por mucha analítica que se aplique, porque el fenómeno ya no está en el dato. La granularidad se decide en el diagnóstico, señal por señal, según qué se quiere poder ver.
El tercero es la identificación de la señal. Una serie llamada AI_07 permite detectar que algo cambió, pero no permite decir qué activo lo hizo ni avisar a quien corresponde. La asociación de cada señal a un activo, una línea o una zona es parte de la normalización que hace Captia Connect y es la condición para que el evento sea accionable.
El cuarto es el contexto de operación. Sin saber si la máquina estaba en marcha, en vacío, en cambio de formato o en mantenimiento, buena parte de las desviaciones detectadas serán transiciones legítimas. El contexto puede venir del propio dato de planta o de la integración con ERP y MES, y es lo que permite comparar cada momento contra su normalidad y no contra un promedio que mezcla regímenes distintos.
El quinto es de calendario. Una planta con estacionalidad marcada necesita haber vivido sus estaciones antes de que nadie, humano o modelo, pueda decir qué es normal en ella. Si se activa el módulo en invierno con histórico solo de invierno, la primera ola de calor producirá una avalancha de eventos que no son averías sino verano. Hay dos salidas legítimas: esperar a tener el ciclo completo, o incorporar la variable exógena que explica la estacionalidad (temperatura ambiente, calendario de campaña) al contexto, de modo que la referencia de normalidad se condicione a ella en lugar de ignorarla.
El sexto no es un dato sino un compromiso: alguien tiene que revisar los eventos. Un detector cuyos avisos nadie clasifica no puede mejorar, porque no existe la información de qué era real y qué no. La disciplina de etiquetado, revisión y reentrenamiento pertenece al ciclo de vida del modelo, y está desarrollada en la guía de MLOps industrial.
Casos de aplicación industrial
En la práctica, lo que la planta llama anomalía son cuatro fenómenos distintos que se detectan de forma distinta y que generan salidas distintas en la plataforma. Confundirlos es la causa habitual de que un proyecto de detección decepcione.
| Tipología | Cómo se manifiesta en la señal | Ejemplo de planta | Salida útil |
|---|---|---|---|
| Anomalía puntual | Un valor aislado lejos del rango habitual de esa señal en ese contexto | Pico de intensidad en un arranque que no debería tenerlo | Evento en el histórico y alerta inmediata si persiste |
| Anomalía contextual | Un valor normal en absoluto, anómalo para el momento o el régimen | Consumo de nivel productivo un domingo con la línea parada | Alerta condicionada al contexto y revisión del calendario de operación |
| Anomalía colectiva | Un tramo cuya forma o ritmo se aparta, aunque ningún valor sea extremo | Ciclo de máquina que se alarga de forma sostenida sin superar ningún límite | Evento sobre el tramo completo y comparación contra ciclos anteriores |
| Anomalía relacional | Ruptura de la relación esperada entre dos o más señales del mismo activo | Caudal que cae mientras la presión y el consumo se mantienen | Evento a nivel de activo, no de señal, y aviso al responsable del equipo |
Un caso transversal y poco glamuroso merece mención propia: la anomalía del propio instrumento. Una señal congelada en el último valor válido, un sensor que deriva o un transmisor que satura son, estadísticamente, comportamientos anómalos, y el módulo los detecta igual que detecta un fallo de proceso. Vigilar la salud de la instrumentación es a menudo el primer retorno del módulo, porque un dato malo no solo no ayuda: contamina todo lo que se construya encima.
Cuando la desviación detectada apunta al deterioro progresivo de un equipo rotativo, el terreno natural es el módulo de mantenimiento predictivo, que va más allá de señalar la desviación y estima la evolución. Cuando apunta a consumo que no responde a la actividad, el ángulo correcto es el de optimización energética. La detección de anomalías es la capa de vigilancia general que hace visible el problema; el diagnóstico y la acción viven en el módulo que corresponda, y el diseño del circuito de aviso lo aborda la solución de predicción y alertas.
Cómo se implanta por fases
La implantación sigue las fases de la plataforma de datos industriales y nunca empieza por el módulo. Encender un detector el primer día es la forma más rápida de quemar la confianza del equipo de planta.
- Diagnóstico. Inventario de señales y activos críticos, protocolos disponibles, granularidad necesaria por fenómeno y, sobre todo, qué se quiere poder detectar. Aquí se decide también qué ya está cubierto por una regla y no necesita modelo.
- Despliegue del edge. Captia Connect en planta, normalización, buffering y persistencia sin conectividad. A partir de este punto existe histórico con calidad suficiente para hablar de normalidad.
- Reglas y alertas primero. Todo lo que la planta ya sabe se codifica como regla en Captia.ai. Esto no es un paso previo perdido: define la línea base sobre la que el módulo tendrá que aportar algo distinto.
- Periodo de observación en sombra. El módulo se activa sobre un conjunto acotado de activos y genera eventos que se registran pero no despiertan a nadie. Se revisa qué habría avisado, cuántas veces al día y con qué proporción de aciertos reconocidos por el equipo. Es el momento de ajustar sensibilidad, ventanas de persistencia y agrupación de eventos.
- Paso a alerta con destinatario. Solo cuando el ruido es asumible se conectan los eventos a alertas y workflows, con un responsable definido por tipo de aviso y un circuito para marcar los falsos positivos. Sin destinatario no hay alerta que valga.
- Operación y ciclo de vida. Reporting periódico, revisión de la tasa de falsos positivos, consolidación en reglas de las anomalías ya entendidas y reentrenamiento cuando el proceso derive. Ese último punto es permanente, no una fase que se cierra.
Límites y cuándo no aplica
Este apartado ahorra proyectos mal planteados. La detección de anomalías no aplica, o aporta poco, en estos escenarios:
- Cuando una regla ya lo resuelve. Si existe un límite conocido, estable y justificado por proceso, la respuesta correcta es una regla de umbral: más barata, más rápida y explicable ante cualquier auditoría. Añadir un modelo encima solo introduce incertidumbre donde había certeza.
- Sin histórico o con histórico no representativo. Una señal conectada esta semana no tiene normalidad contra la que compararse. Peor aún: un histórico que contiene un periodo averiado sin marcar enseña al módulo que la avería es lo normal.
- Cuando el fallo relevante no tiene precedente. El módulo aprende de lo que ha ocurrido. Un modo de fallo catastrófico que nunca se ha dado, o cuya firma no está en las señales instrumentadas, no se detecta por análisis del histórico. Ahí lo que corresponde es un análisis de modos de fallo y, probablemente, más instrumentación.
- Cuando el proceso cambia constantemente sin contexto registrado. Una planta que alterna productos, recetas y regímenes sin que ese cambio quede en el dato produce un flujo continuo de desviaciones legítimas. El módulo no distingue un cambio de formato de una avería si nadie le dice que hubo cambio de formato. Lo que falta ahí es contexto, no algoritmo.
- Cuando la señal está dominada por el ruido o por la resolución del instrumento. Si la variación real del fenómeno es menor que el escalón de medida o que el ruido de fondo, no hay modelo que recupere lo que el sensor no capturó. El problema es de instrumentación.
- Cuando nadie va a revisar los avisos. Un detector sin circuito de revisión degenera en semanas: los avisos se silencian, el equipo deja de mirarlos y el modelo nunca recibe la información que necesita para mejorar. Es preferible no activarlo que activarlo sin destinatario.
- Cuando lo que se busca es la causa. El módulo dice que el comportamiento se aparta y contra qué se compara. No dice por qué. El diagnóstico de causa raíz es trabajo de ingeniería sobre esa evidencia, y a menudo del módulo especializado que corresponda.
Tres límites merecen desarrollo propio porque son los que decide el éxito del despliegue.
Falsos positivos. No son un defecto que se elimina, son un parámetro que se elige. Bajar el nivel de puntuación que dispara un evento sube la detección y sube el ruido; subirlo hace lo contrario. El punto correcto depende del coste relativo de los dos errores en ese activo concreto: revisar en falso una bomba accesible cuesta poco, no detectar el fallo de un equipo sin repuesto cuesta mucho. Por eso la sensibilidad se fija activo por activo con el responsable de mantenimiento, y no de forma global.
Estacionalidad. Casi todas las señales industriales tienen varios ciclos superpuestos: el del ciclo de máquina, el del turno, el de la semana y el del año. Un detector que ignora la periodicidad marca como anómalo todos los lunes por la mañana. La alternativa correcta no es subir el umbral hasta que callen, sino condicionar la referencia de normalidad al momento y a las variables exógenas que la explican.
Deriva del proceso. La normalidad de un activo caduca. Un cambio de proveedor de materia prima, una reforma mecánica, un cambio de consigna o el propio envejecimiento desplazan el comportamiento sin que haya avería. Si el modelo no se revisa, confundirá el nuevo régimen con un fallo permanente, y el equipo aprenderá a ignorarlo. La vigilancia de esa deriva y el criterio para reentrenar están descritos en la guía de MLOps industrial.
Y un límite transversal: el módulo evidencia, no actúa. Detiene o modifica un proceso la operación, mediante las reglas y los workflows que el equipo define y supervisa. Esa separación entre detección y actuación es deliberada en entorno industrial.