← Volver a Arquitectura Protocolo operativo · Baseline

Golden Run
Protocol

La firma de referencia del vehículo sano. Un recorrido controlado y certificado que establece el estado cero contra el que el Filtro de Kalman comparará cada señal futura.

Qué es

El Golden Run Protocol (GRP) es la metodología operativa propietaria de IN-SIGHT para capturar, validar y certificar la firma de salud nominal de un vehículo ferroviario. Es el equivalente funcional de una «fotografía de salud» tomada cuando el vehículo está en condiciones óptimas y recién mantenido.

Sin un Golden Run válido, el sistema no puede operar en modo de detección: el Filtro de Kalman necesita ese estado de referencia (x₀, P₀) para calibrarse. El GRP es por tanto la condición de entrada al sistema IN-SIGHT para cada vehículo y define la calidad de todos los diagnósticos futuros.

La filosofía del protocolo se basa en el concepto de baseline personalizado: en lugar de comparar el vehículo contra valores nominales de fabricante (que no reflejan el desgaste acumulado ni las particularidades individuales de cada unidad), IN-SIGHT compara cada vehículo contra sí mismo en su mejor estado conocido.

Las tres fases del protocolo

  1. Fase de Captura — Recorrido de referencia en condiciones controladas: velocidad constante en tramo conocido, temperatura de bogie entre 20-40°C, sin alertas activas previas, mínimo 45 minutos de circulación continua (o 50 km). Durante el recorrido, los Pods graban a máxima resolución: ~1.200 canales a 3.200 Hz = ~1,4 GB/h de datos brutos.
  2. Fase de Validación Automática — El sistema verifica automáticamente: cobertura espectral completa (DC–6 kHz sin gaps), ausencia de artefactos de saturación o clipping, estabilidad temporal de las métricas (varianza dentro de ±15 % del valor mediano), coherencia entre los múltiples pods del mismo vehículo. Si alguna verificación falla, el Golden Run se rechaza con diagnóstico de causa raíz.
  3. Fase de Aprobación y Certificación — El ingeniero de flota responsable revisa los resultados en el portal, compara el espectro de frecuencias con los golden runs anteriores (si existen) y firma digitalmente el baseline. A partir de ese momento, el vehículo queda en estado «monitored» y el EKF se activa usando ese baseline.
Re-certificación obligatoria: El Golden Run caduca tras 12 meses o después de cualquier intervención mayor sobre los subsistemas monitorizados (cambio de rodamiento, rueda, actuador de puerta). Esto garantiza que el baseline refleja siempre el estado actual del vehículo.

Datos capturados y almacenamiento

Durante el Golden Run se capturan, por vehículo y sesión:

  • Señales de vibración: 6 canales triaxiales (2 pods × 3 ejes) a 6.667 Hz.
  • Señales acústicas: 2 canales micrófono MEMS (puertas) a 3.200 Hz.
  • Temperatura: Temperatura de bogie y electrónica, a 1 Hz.
  • Metadatos contextuales: Velocidad (integrada desde acelerómetro), timestamp GPS-sincronizado, identificador de tramo de vía.

Los datos brutos se almacenan en Azure Data Explorer en el tier cold (Parquet comprimido, ~95 MB por Golden Run). Los parámetros del EKF derivados (x₀, P₀, matrices de ruido Q y R ajustadas) se almacenan en el Device Twin del IoT Hub y se descargan al CM4 en la siguiente sincronización.

Golden Run session
├── raw_signals/          ← Parquet, ADX cold tier
│   ├── pod_a_acc.parquet     (~85 MB)
│   └── pod_b_acc_mic.parquet (~32 MB)
├── ekf_params.json       ← x0, P0, Q, R matrices
├── spectral_baseline.npy ← FFT mediana por canal
└── certificate.json      ← firma digital + metadata