Caso de estudio 05 / 17Node Back-End
Motor de diagnóstico que separa las fallas de sensor de las de proceso
Evalúa la confianza de cada señal, contrasta cada tramo con la hidráulica y envía toda firma de falla nueva a revisión humana.
Stack
- TypeScript
- Node.js
- Next.js
- React
- MongoDB
- InfluxDB
- ECharts
01 · Cómo funciona
- HoyaModificado en este trabajo
- Flujo de datos
Qué hace
Diseñé y construí un motor de diagnóstico basado en reglas que corre junto al sondeo de datos de la plataforma de monitoreo. En cada sondeo califica cuánto se puede confiar en cada señal, compara cada tramo con lo que predice la hidráulica y lo reduce a un estado con huella que selecciona el escenario y su acción recomendada.
Leer más
Un superadministrador aprueba una vez cada huella nueva; desde ahí, el caso llega a los operadores con su evidencia y dos gráficos.
6 conexiones· elige un componente para ver su recorrido
- Proceso de sondeo a Filtro de confianza: lecturas cada 10–15 s
- Filtro de confianza a Vector de estado: pasa si confianza ≥ 0.6
- Vector de estado a Catálogo de huellas: busca su huella
- Catálogo de huellas a Cola de revisión: nueva o cambiada: propone
- Cola de revisión a Catálogo de huellas: aprobada una vez
- Catálogo de huellas a Panel de operadores: aprobada: va directo
02Resultados
- R01Cuanto más bajo, mejor
Propuestas cerradas antes de la revisión (de 68)
Antes 41, después 0, a cero. Cuanto más bajo, mejor.AntesDespués - R02Cuanto más alto, mejor
Muestras de ruido por falsa alarma de fuga, 5σ → 10σ
Antes 900, después 44,000, 49× mayor. Cuanto más alto, mejor.AntesDespués - R03Cuanto más bajo, mejor
Repintado más lento del panel, p95
Antes 414 ms, después 21 ms, 20× menor. Cuanto más bajo, mejor.AntesDespués
Qué logró
- Diagnóstico: alarmas sobre umbrales crudos → primero la confianza de la señal, luego la hidráulica y después un escenario con huella y su acción recomendada
- Supervisión humana: 41 de 68 propuestas cerradas sin revisión en un día → 0; solo una decisión cierra una
Leer más
- Carga del revisor: 68 tarjetas → 44, una por huella
- Falsas alarmas de fuga por ruido: una cada ~900 muestras → una cada ~44,000
- Consistencia: seis definiciones de la misma condición → dos, con 0 diferencias en una reproducción de 6 h
El desafío
Un día completo de alarmas mostró el problema real: la mayoría describía la instrumentación, no el proceso. Cerca de dos tercios eran alarmas de señal congelada que caían a la vez en todas las estaciones de un canal: fallaba un solo enlace de comunicación compartido, no muchos sensores. En una tubería, una diferencia sostenida entre dos caudalímetros mantuvo todo el día una alarma de fuga confirmada; una regla de umbral simple habría seguido alarmando durante 14 horas.
Leer más
Algunos umbrales configurados nunca podían dispararse, y las lecturas faltantes se guardaban como cero, justo la condición que dispara una alarma de tubería parcialmente vacía. Incluso la primera cola de revisión fallaba en silencio: las propuestas se cerraban solas tras diez minutos sin ser vistas.
Qué aprendí
Descubrir los escenarios, no enumerarlos. Un tramo de tubería tiene 81 vectores de estado posibles y uno de canal 243, pero miles de muestras reales produjeron solo nueve, así que el catálogo crece únicamente con lo que de verdad ocurre. Un mismo síntoma puede exigir acciones distintas, por eso la limpieza de la tubería se recomienda solo después de descartar las otras causas y cuando la tendencia se mantiene por días.
Leer más
Propuse un límite de 5σ, lo medí contra ruido y apliqué 10σ. Una reproducción grabada ahora falla si cambian las matemáticas.
Stack
- TypeScript
- Node.js
- Next.js
- React
- MongoDB
- InfluxDB
- ECharts
Habilidades
- Diseño de motores de reglas
- Detección de anomalías
- Modelado hidráulico
- Revisión humana en el ciclo
- Pruebas de regresión por reproducción
