Caso de estudio 02 / 21Ciencia de datos
Banco de pruebas que califica detectores de fugas con fugas conocidas
Escribe fugas sintéticas con respuesta conocida en un servidor OPC UA de prueba y califica tres detectores: el mejorado ganó 83.9 a 69.3.
Stack
- n8n
- TypeScript
- Node.js
- OPC UA
- InfluxDB
- PowerShell
01 · Cómo funciona
- HoyaModificado en este trabajo
- Flujo de datos
Qué hace
Una app de flujos con nodos construida sobre n8n, sin tocar el código de n8n: un nodo propio lee un servidor OPC UA industrial en solo lectura y nodos de cálculo encadenados convierten sus señales en resultados como puntajes de sensores y alarmas de fuga. Sobre ella construí un banco de pruebas que escribe casos sintéticos de una tubería, cada uno con su respuesta conocida, en un servidor OPC UA de laboratorio que leen tres detectores a la vez: el detector existente como línea base, una copia fiel 1:1 en nodos y un modelo mejorado.
Leer más
Cada corrida recibe una nota de 0 a 100 y se dibuja como línea de tiempo, así el equipo ve en qué detector confiar y si un cambio al modelo ayudó.
8 conexiones· elige un componente para ver su recorrido
- Generador de casos a Servidor OPC UA del lab: una fila por segundo
- Generador de casos a Nota de 0 a 100: la respuesta conocida
- Servidor OPC UA del lab a Detector existente: lee cada 0.5 s
- Servidor OPC UA del lab a Copia 1:1 en nodos n8n: solo lectura, cada 10 s
- Servidor OPC UA del lab a Modelo mejorado: solo lectura, cada 2 s
- Detector existente a Nota de 0 a 100: estado de alarma y lugar
- Copia 1:1 en nodos n8n a Nota de 0 a 100: una línea por ciclo
- Modelo mejorado a Nota de 0 a 100: estado, lugar y tasa
02Resultados
- R01Cuanto más alto, mejor
Nota media en las mismas 48 corridas, base y mejorado
Antes 69.3, después 83.9, +21%. Cuanto más alto, mejor.AntesDespués - R02Cuanto más bajo, mejor
Tiempo mediano para confirmar, base frente a mejorado
Antes 458 s, después 165 s, 2.8× menor. Cuanto más bajo, mejor.AntesDespués - R03Cuanto más alto, mejor
Fugas detectadas de 33, base frente a mejorado
Antes 27, después 30, +11%. Cuanto más alto, mejor.AntesDespués
Qué logró
- Casos de prueba: ninguno con respuesta conocida → un catálogo de 30 plantillas con casos de borde y 51 corridas calificadas, cada una con su línea de tiempo segundo a segundo
- Nota media sobre 100 en las 48 corridas con lectura de la base: 69.3 de la línea base → 83.9 del modelo mejorado, que además vio 30 de 33 fugas frente a 27 y no dio ninguna falsa alarma
- Tiempo mediano para confirmar una fuga: 458 s → 165 s, con un error mediano de ubicación de cerca de un tercio del de la línea base
- Lógica de detección existente: solo dentro de una aplicación de escritorio → también como copia 1:1 en 57 nodos de flujo, que igualó su estado de fuga en cada minuto grabado y en el 88 % de los minutos del banco
Leer más
- Cambios al modelo: probados con una sola fuga de prueba → 11 cambios, cada uno comprobado repitiendo las corridas que tocaba; la última repetición completa de las 51 corridas, para los dos modelos en nodos, dejó 3 notas mejores, 99 iguales y 0 peores
- CPU por tubería: 163 % de un núcleo para la aplicación de escritorio → 49 % para toda la app de flujos con los dos modelos en nodos y sus páginas, 20 % para los modelos solos, medidos en máquinas distintas
El desafío
Un detector de fugas solo se puede juzgar con fugas cuyo lugar, tamaño y hora de inicio se conocen, y no había ninguna con qué juzgarlo. Las señales de desarrollo estaban congeladas: ninguna de las 225 se movió en 55 minutos. La última repetición de un escenario de fuga grabado escribía una fila cada 14 s en vez de una por segundo, y ninguna salida del detector existente llegó al servidor en sus 3607 filas, así que ni siquiera se podía leer una línea base.
Leer más
Ese detector funciona solo en vivo, por lo que una corrida no se podía repetir después.
Cualquier afirmación de que un modelo nuevo era mejor se habría basado en opiniones, y la copia de la lógica existente solo se había comprobado con tres grabaciones, ninguna con un evento a una hora conocida.
Qué aprendí
Un banco puede engañar con la misma facilidad con que mide. Mi primera fuga sintética movía solo los caudalímetros, al instante, y después una firma de presión dibujada al revés hizo que los tres detectores la ubicaran al final de un tramo; cuando las presiones siguieron a la fricción y a la velocidad de la onda, la ubicación se pudo medir. Califico la estimación mediana después de la detección, no la primera, y solo cuento corridas completas; una corrida sin valor se repite sola.
Leer más
La repetición también descartó ideas: una regla de ubicación que arreglaba un caso de rotura falló cuatro minutos después, y la reemplacé por un escalón ajustado a todos los tramos entre dos caudalímetros. Los datos sintéticos no son la planta: antes de cualquier decisión va una fuga real controlada.
Stack
- n8n
- TypeScript
- Node.js
- OPC UA
- InfluxDB
- PowerShell
Habilidades
- Detección de fugas en tuberías
- Diseño de bancos de prueba y de notas
- Datos sintéticos desde un esquema real
- Detección secuencial de cambios
- Pruebas de regresión por repetición

