Mantenimiento predictivo: el módulo de anticipación de fallo de Captia.ai

Cómo funciona el módulo de mantenimiento predictivo dentro de Captia.ai

El módulo no observa una máquina: observa el registro que la planta ya tiene de esa máquina. 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 modo que una parada de red no abre un hueco justo en el periodo que después habría explicado un fallo. El módulo trabaja sobre ese histórico ya consolidado, con marca de tiempo homogénea, y sobre los eventos registrados en Captia.ai.

Esa segunda entrada, los eventos, es la que distingue este módulo de una analítica de señales cualquiera. Una serie temporal por sí sola describe cómo se comporta un equipo, pero no dice qué le pasó. El evento sí: una parada, un aviso disparado por una regla, una intervención registrada, un cambio de estado de máquina. Cuando la señal y el evento comparten el mismo eje de tiempo dentro de la plataforma, el histórico deja de ser una curva y pasa a ser un expediente del activo, y sobre un expediente sí se puede anticipar.

El procesamiento tiene tres movimientos. Primero establece la referencia del propio equipo: cómo se comporta esa máquina concreta en condiciones comparables de operación, porque dos equipos del mismo modelo en la misma nave no comparten línea base. Segundo, mide la separación entre el comportamiento actual y esa referencia, y la sigue en el tiempo, que es lo que convierte una desviación puntual en una degradación. Tercero, sitúa esa evolución frente a los eventos ya registrados del activo, para que la señal se lea junto a lo que la planta hizo: si la deriva empezó tras un cambio de consigna o tras una intervención, eso forma parte de la lectura.

La salida no es una predicción suelta en un panel. Es material accionable dentro de la propia plataforma: dashboards por activo, línea, rol o planta; reglas y alertas cuando la degradación cruza el umbral acordado; eventos trazables que quedan en el histórico del activo; workflows que llevan el aviso a quien puede intervenir; reporting periódico para la revisión de mantenimiento; y APIs hacia ERP, MES, CRM o SAP cuando la intervención tiene que convertirse en orden de trabajo en el sistema de gestión. El aviso muere en el sistema donde se ejecuta el trabajo, no en un correo.

Conviene fijar la frontera con dos módulos vecinos, porque en planta se confunden. El de detección de anomalías responde a esto no es normal ahora. Este responde a esto va a peor y hay un margen para intervenir. Y el de forecasting proyecta el valor futuro de una variable sin pronunciarse sobre el estado del activo. Los tres pueden estar activos sobre el mismo equipo y no se sustituyen.

Requisitos de datos: qué hace falta antes de activarlo

El primer requisito es que exista señal del equipo, y no cualquiera. Hace falta la señal que se mueve cuando el modo de fallo que preocupa avanza. Un activo con únicamente una marcha o paro digital no ofrece gradiente: solo distingue funcionando de parado, y entre esos dos estados es donde vive la degradación. Qué variable resuelve qué modo de fallo es una decisión de ingeniería que se toma en el diagnóstico, y el marco conceptual está en la guía de mantenimiento predictivo industrial, no en el módulo.

El segundo es la frecuencia de muestreo. La cadencia tiene que ser suficiente para que el fenómeno sea visible: una señal promediada cada hora borra cualquier comportamiento que ocurra en segundos. Esto se decide antes, en la configuración de la adquisición en Captia Connect, porque lo que no se capturó no se recupera después.

El tercero es la identificación del activo. La señal tiene que estar asociada a un equipo concreto y ese equipo tiene que ser estable en el histórico. Si una misma etiqueta ha designado a dos máquinas distintas tras una sustitución, el histórico mezcla dos vidas y la referencia de comportamiento queda contaminada. Este trabajo de normalización y contextualización es exactamente lo que hace Captia Connect al capturar el dato, y es la parte que más se subestima en un proyecto.

El cuarto, y el más específico de este módulo, es el historial de intervenciones y eventos. Sin saber cuándo se intervino un equipo, una mejora en la señal parece una recuperación espontánea y una degradación reaparecida parece un fallo nuevo. Ese registro puede vivir en la propia plataforma como eventos y workflows, o llegar por integración API desde el ERP o el sistema de gestión de mantenimiento. Cuanto más pobre sea, más se limita el módulo a describir la evolución de la señal y menos puede acotar el margen de intervención.

El quinto es de calendario y no de tecnología: hace falta histórico que cubra el ciclo operativo normal del activo, incluidos sus cambios de producto, sus paradas programadas y su estacionalidad si la tiene. Un equipo cuya línea base solo se ha observado en una campaña generará avisos en cuanto empiece la siguiente, y esos avisos no serán degradación sino desconocimiento.

Casos de aplicación industrial

El caso más frecuente es el activo rotativo auxiliar de servicio continuo: compresores, bombas, ventiladores, grupos de frío. No suelen estar instrumentados como los equipos de proceso porque no paran la línea el día que fallan, pero condicionan el consumo y la calidad mientras se degradan. Aquí el módulo aporta algo que ninguna ronda de inspección da: continuidad. La comparación es contra el propio pasado del equipo, todos los días, también los fines de semana.

El segundo caso es el equipo cuello de botella de una línea. Cuando un solo activo fija el ritmo de la planta, el valor no está en detectar el fallo sino en poder elegir el momento de la parada. Ahí la salida útil del módulo no es la alerta: es el evento en el histórico del activo que permite a producción y a mantenimiento negociar una ventana con margen, y el workflow que deja constancia de esa decisión.

El tercero es la deriva lenta de consumo de un equipo respecto a su propio pasado. Una máquina que necesita más energía que hace seis meses para el mismo servicio está diciendo algo sobre su estado. Este módulo y el de optimización energética miran la misma curva desde dos ángulos: uno pregunta cuánto cuesta, otro pregunta por qué sube. Leídos juntos suelen cerrar el diagnóstico.

El cuarto es el parque distribuido: varios equipos del mismo tipo en distintas ubicaciones. La ventaja no es aplicar un modelo único a todos, que casi nunca funciona, sino disponer de las mismas señales normalizadas y del mismo esquema de eventos para todos, de modo que la comparación entre unidades sea legítima. Esa homogeneidad la produce la capa de adquisición, no el modelo.

El quinto es el activo con contrato de mantenimiento externo. Cuando el trabajo lo ejecuta un tercero, el histórico de señales y eventos de la plataforma es la base objetiva de la conversación: qué se hizo, cuándo, y qué le pasó a la señal después. El módulo no sustituye al contrato, lo hace verificable.

Cómo se implanta por fases

La implantación sigue las mismas fases que el resto de la plataforma, descritas en el hub de plataforma de datos industriales, y no empieza por el módulo. Empieza por tener expediente del activo.

1. Diagnóstico. Criticidad de los activos, modos de fallo que preocupan de verdad, señales existentes y protocolos disponibles. Aquí se decide qué equipos entran, qué se mide, con qué cadencia y qué instrumentación falta. Un activo cuyo fallo no tiene consecuencia operativa relevante no debería entrar aunque sea fácil de medir.
2. Despliegue del edge. Captia Connect en planta, conexión de equipos y sensórica, normalización, buffering y persistencia sin conectividad. A partir de este punto existe histórico, y el reloj del proyecto empieza a correr de verdad.
3. Puesta en marcha de la plataforma. Dashboards por activo, usuarios y roles, y las primeras reglas y alertas deterministas sobre umbrales conocidos. Esta fase no es un trámite previo al módulo: es la que genera el registro de eventos del que después vivirá el predictivo.
4. Operacionalización. Workflows de aviso e intervención, reporting periódico e integración por API con ERP o MES para que la intervención se convierta en orden de trabajo. Aquí se cierra el ciclo: cada aviso acaba con una constancia de lo que se hizo, y esa constancia es el dato de entrenamiento del futuro.
5. Inteligencia. Con histórico de señal consolidado y eventos registrados se activa el módulo de mantenimiento predictivo. Antes de este punto no tiene un pasado contra el que comparar ni un desenlace con el que aprender. El acompañamiento de ingeniería para ajustar umbrales y enrutado de avisos es el trabajo de predicción y alertas.

Límites y cuándo no aplica

Conviene decirlo con claridad, porque este es el módulo que más expectativas genera y el que más proyectos mal planteados acumula. El mantenimiento predictivo de Captia.ai no aplica, o aporta poco, en estos escenarios:

• Fallos súbitos sin degradación previa. Una rotura frágil, un fallo electrónico instantáneo o un error de operación no dejan rastro creciente en la señal. No hay nada que anticipar porque no hay evolución que observar. Frente a esos modos de fallo lo que protege es el diseño, la redundancia o la protección, no la analítica.
• Sin histórico de fallos ni de intervenciones. El módulo puede describir la evolución de una señal desde el primer día, pero acotar el margen de intervención exige haber visto cómo terminaron episodios anteriores. Una planta sin registro de lo que le ha pasado a sus equipos empieza a construirlo el día que despliega la plataforma, no antes.
• Activos con muy pocas horas de funcionamiento. Un equipo que opera de forma esporádica acumula historia por calendario, no por uso. La referencia de comportamiento tarda en formarse y el módulo pasa mucho tiempo sin poder distinguir una condición de arranque de una degradación.
• Instrumentación que no cubre el modo de fallo. Medir una variable que no se mueve cuando el equipo se degrada no produce predicción, produce ruido. Aquí lo que falta es sensórica y criterio de ingeniería, no modelo. El módulo hará visible el vacío pero no lo llenará.
• Cuando no existe capacidad de intervenir. Si no hay repuesto, ventana de parada, contrato o personal para actuar sobre el aviso, la anticipación no cambia el resultado: solo adelanta la fecha en la que alguien supo que iba a pasar. Antes de activar el módulo conviene comprobar que existe una decisión posible al otro lado.
• Cuando lo que se busca es un plan de mantenimiento. Definir la estrategia de un parque, sus criticidades y sus políticas es un trabajo de ingeniería y organización previo. El módulo alimenta ese plan con evidencia continua, no lo redacta.
• Cuando lo que se busca es entender la disciplina. Si la pregunta es cómo se elige un indicador de estado, qué horizonte tiene sentido o cómo se estructura un programa predictivo, el terreno es el de la guía de mantenimiento predictivo industrial. Esta página describe la capacidad del módulo, no la metodología.

Y un límite transversal que aplica a todos los módulos de IA de la plataforma: el módulo evidencia y avisa, no ejecuta paradas por su cuenta. La decisión de intervenir la toma la operación, con las reglas y los workflows que el equipo define y supervisa. En mantenimiento esa separación no es una cautela formal: un paro no solicitado cuesta lo mismo que el fallo que se quería evitar.