De SCADA a decisión de mantenimiento: el pipeline de InverterAI

La forma end-to-end

El trabajo de InverterAI como sistema es estrecho: convertir telemetría SCADA en una cola de mantenimiento priorizada, con explicaciones. Todo lo demás — los modelos físicos, la arquitectura de la red neuronal, la interfaz de usuario — existe al servicio de esa única salida.

Esa conversión ocurre en cinco etapas, cada una con un contrato de entrada claro, un contrato de salida claro y un modo de fallo claro. La disciplina de mantener las etapas limpias es lo que hace mantenible el sistema; la disciplina de mantener las interfaces estrechas es lo que lo hace agnóstico al OEM.

Etapa 1 — Ingestión desde SCADAs heterogéneos

Sungrow, Huawei, SMA, Ingeteam, Power Electronics, FIMER, Schneider, Ampt, GE y el resto de Tier-1 exponen la telemetría del inversor a través de pilas SCADA distintas. Los protocolos se normalizan a un conjunto pequeño:

• Modbus TCP/RTU — con diferencia el más común en flotas europeas e ibéricas.
• OPC UA — cada vez más el estándar en puestas en marcha recientes, especialmente cuando el front-end SCADA es de un tercero y no del OEM.
• IEC 61850 — común cuando el inversor está detrás de una capa de automatización de subestación, especialmente en instalaciones con soporte a red.
• Exportaciones de historian a fichero — CSV, parquet o formatos binarios específicos de PI, Wonderware, OSIsoft y similares. Pragmático para retrofits y pilotos rápidos.

InverterAI normaliza los cuatro a un esquema canónico único en la ingestión. El conjunto canónico de etiquetas es deliberadamente pequeño — alrededor de 25-40 etiquetas por inversor — y mapea directamente a los modelos físicos aguas abajo. Cualquier cosa más rica se captura pero no se requiere.

La capa de ingestión es el único lugar que tiene que saber sobre rarezas específicas del OEM (enteros con o sin signo, factores de escala, diferencias de mapa de registros). Todo aguas abajo solo ve el esquema canónico. Esto es lo que hace al resto del pipeline agnóstico al OEM en la práctica, no solo en marketing.

Etapa 2 — Limpieza y comprobaciones físicas de sentido común

Los datos SCADA reales son más sucios de lo que reconocen los tutoriales. Caídas de sensor, valores congelados, deriva de reloj, bugs de conversión de unidades, clipping por rango y rellenos incompletos de historian aparecen en el mundo real. Los pipelines ML ingenuos los amplifican a salidas espurias del modelo; los pipelines fundamentados en física los rechazan.

La etapa de limpieza aplica cuatro familias de comprobaciones en secuencia:

1. Comprobaciones de rango. La temperatura de unión no puede exceder el máximo absoluto del dispositivo. La tensión DC-link no puede exceder el máximo nominal. La corriente AC no puede exceder el valor nominal más una tolerancia pequeña de instrumentación. Las violaciones disparan una marca, no una entrada al modelo.
2. Comprobaciones de consistencia física. La potencia AC de salida no puede exceder la potencia DC de entrada. La temperatura de unión no puede estar por debajo de la ambiente. La temperatura de disipador no puede caer más rápido de lo que permite la constante de tiempo térmica de la masa del disipador.
3. Comprobaciones estadísticas de salud. Detección de valores congelados en ventanas móviles. Detección de saltos anómalos inconsistentes con la dinámica física. Comprobaciones de correlación cruzada entre etiquetas (la T del disipador debe correlar con la potencia de salida a un desfase conocido; si no, algo está roto).
4. Detección de skew de reloj. Comparando timestamps del inversor con una referencia conocida (alineación del pico de irradiancia con mediodía civil, alineación de la rampa de irradiancia con el amanecer) detecta deriva antes de que corrompa el conteo de ciclos aguas abajo.

Las etiquetas que fallan se enmascaran en lugar de sustituirse. Los modelos aguas abajo ven el hueco, no un valor alucinado. Esto es crítico: un pipeline ML black-box que interpola sobre valores perdidos producirá una respuesta confiada derivada en parte de su propia imaginación. Un pipeline fundamentado en física que enmascara simplemente devuelve mayor incertidumbre durante el hueco, que es el comportamiento honesto.

Etapa 3 — Ingeniería de variables físicas

Las etiquetas SCADA crudas no son lo que los modelos físicos consumen. Los modelos físicos consumen variables con significado físico derivadas de las etiquetas. La transformación de unas en otras es donde se codifican décadas de investigación en fiabilidad de electrónica de potencia.

Las variables centrales que produce el pipeline de InverterAI:

• Temperatura de unión estimada por rama de fase, vía inversión de la red térmica desde la temperatura de disipador, la ambiente y la disipación instantánea. El punto de partida es la red Foster del datasheet del OEM; la calibración usa la dinámica observada en flota para apretar las constantes.
• Histogramas rainflow de ciclos sobre la serie de Tj, calculados sobre ventanas móviles de horas y días, agregados luego a incrementos de fatiga por inversor-día que alimentan Coffin-Manson.
• Traza estimada de corriente de rizado DC-link a partir de los armónicos de corriente AC y la telemetría de frecuencia de conmutación. Donde existe medida directa de corriente DC-link, atajan esta estimación.
• Estimación de temperatura de núcleo del condensador desde la temperatura de disipador más el autocalentamiento por corriente de rizado, alimentando el modelo Arrhenius de vida útil.
• Fracción de carga parcial y delta ambiente sobre ventanas móviles, usadas como covariables en la PINN.
• Variables de densidad de eventos — conteos de arranque/parada, eventos de soporte a red, ocurrencias de derate — que capturan el contexto del régimen operativo.

Estas variables son las entradas que la PINN consume realmente. Diseñarlas explícitamente, en vez de pedirle a la red que las aprenda desde etiquetas crudas, es la mayor palanca individual sobre la calidad de predicción en la práctica. La física está en las variables, y las variables están en la pérdida.

Etapa 4 — Inferencia PINN e incertidumbre

Con variables limpias en la mano, la capa de inferencia PINN produce, para cada inversor y cada modo de fallo, una distribución de Remaining Useful Life (RUL) en vez de una estimación puntual. La banda de confianza del 90 % es parte de la salida, no una nota al pie.

La inferencia es barata una vez la red está entrenada — milisegundos por inversor, lo que permite reevaluar toda la flota en cada ventana SCADA nueva. El trabajo caro es el entrenamiento y la calibración, que ocurre offline sobre datos acumulados de flota y se repite cuando llegan observaciones de fallo materiales nuevas.

La salida para cada inversor es un objeto estructurado pequeño:

• Distribución de RUL por modo de fallo (mediana, percentiles 10 % y 90 %).
• Identificador del modo de fallo dominante.
• Atribución de variables contribuyentes — qué condiciones de operación impulsaron la predicción.
• Marca de calidad de confianza indicando si los datos subyacentes son suficientemente ricos para confiar en la predicción.

Este objeto viaja a la Etapa 5 tal cual. Nunca se colapsa a un solo número; el colapso es decisión del consumidor, no del modelo.

Etapa 5 — Decisión, explicación y handoff al CMMS

La RUL por sí sola no planifica el mantenimiento. La planificación real depende de al menos otras cuatro variables que el modelo no conoce y no debería fingir conocer:

• Accesibilidad. Distancia del sitio al depósito de la cuadrilla, estado de carreteras, acceso a vallado, autorizaciones de seguridad.
• Disponibilidad de repuestos. Qué hay en almacén, qué está pedido, qué está en soporte de fin de vida del OEM.
• Criticidad. Topología de bloque, exposición a mercado de energía, términos de disponibilidad contratada.
• Ventanas meteorológicas. Límites de viento, lluvia y temperatura ambiente para la intervención concreta.

La capa de decisión combina la salida del modelo con estas variables operativas para producir una lista priorizada de inversores — la cola. Cada elemento lleva su distribución de RUL, su atribución de modo de fallo y la justificación de programación que lo coloca donde está.

El handoff al CMMS existente es vía API. InverterAI no sustituye al CMMS — lo alimenta. Las órdenes de trabajo heredan la explicación como nota estructurada, así el técnico que llega a la cabina sabe lo que el modelo esperaba encontrar y puede confirmarlo o refutarlo in situ. Los resultados confirmados y refutados retroalimentan el bucle de calibración.

Lo que la plataforma deliberadamente no hace

Dos cosas que el pipeline no hace, por diseño:

• Sin escrituras de control de vuelta al SCADA. InverterAI es solo lectura. Nunca emite comandos, nunca ajusta setpoints, nunca participa en el bucle de control. Esto es lo que hace que el despliegue esté libre de riesgo de puesta en marcha — el peor comportamiento posible de InverterAI es equivocarse en una predicción, no desestabilizar un activo en operación.
• Sin contratos de datos propietarios del OEM. Las etiquetas SCADA estándar bastan. La plataforma no necesita acceso a firmware, registros privados del OEM ni acuerdos de intercambio de datos cloud-to-cloud con el fabricante del inversor.

Estas restricciones no son pereza — son elecciones de diseño deliberadas. Son lo que hace la plataforma desplegable en un trimestre y no en un año, y lo que la hace agnóstica al OEM en la práctica y no solo en los decks.

Time-to-first-value

Una flota nueva pasa típicamente de la firma del contrato a salida de RUL utilizable en 60-90 días. Las fases:

1. Semanas 1-2 — Conectividad. Asegurar el feed SCADA, validar rutas de red, establecer el mapeo a esquema canónico para las familias de inversor concretas.
2. Semanas 3-6 — Calidad de datos. Descubrir y caracterizar las caídas de sensor, las derivas de reloj y los huecos de historian específicos de la flota. Esta fase produce valor real por sí sola — la mayoría de operadores aprenden cosas sobre su calidad de datos que no sabían antes.
3. Semanas 6-10 — Calibración. Afinar las constantes de red térmica y los parámetros Coffin-Manson / Arrhenius contra la historia de flota y cualquier fallo pasado documentado.
4. Semanas 10-12 — Operacionalización. Integración con CMMS, entrega de la cola al flujo de O&M existente, rollout de dashboard, formación.

A partir de la semana 12, la plataforma entrega el overlay predictivo en régimen permanente. Las bandas de confianza de RUL se estrechan en los trimestres siguientes a medida que se acumulan más datos de flota y el mecanismo de actualización bayesiana integra resultados de fallo confirmados.

Qué hace robusto este pipeline

La disciplina de cinco etapas es lo que hace funcionar el pipeline fuera del laboratorio. Cada etapa tiene responsabilidades acotadas, modos de fallo claros e interfaces explícitas. La física atraviesa todo el pipeline como variables, ecuaciones y restricciones — no como una capa de marketing aplicada sobre un modelo black-box.

Operativamente, esto importa porque:

• Los fallos de cualquier etapa están localizados. Un sensor malo en la Etapa 2 no se propaga a una predicción equivocada y confiada en la Etapa 4; se propaga a datos enmascarados e incertidumbre ensanchada, que es el comportamiento honesto.
• Añadir una nueva familia de inversor toca la Etapa 1 (mapeo canónico) y la Etapa 3 (constantes de red térmica) pero no las Etapas 4 y 5. La física es la física.
• Las mejoras de calibración se acumulan. Cada fallo confirmado retroalimenta la actualización bayesiana; la plataforma mejora prediciendo ese modo de fallo concreto en esa familia concreta, automáticamente.

Mira la plataforma en acción → Lee el stack técnico completo →