← Retour à Architecture Protocole opérationnel · Baseline

Golden Run
Protocol

La signature de référence du véhicule sain. Un parcours contrôlé et certifié qui établit l'état zéro auquel le Filtre de Kalman comparera chaque signal futur.

Qu'est-ce que c'est

Le Golden Run Protocol (GRP) est la méthodologie opérationnelle propriétaire d'IN-SIGHT pour capturer, valider et certifier la signature de santé nominale d'un véhicule ferroviaire. C'est l'équivalent fonctionnel d'une « photographie de santé » prise lorsque le véhicule est en conditions optimales et fraîchement entretenu.

Sans un Golden Run valide, le système ne peut pas fonctionner en mode détection : le Filtre de Kalman a besoin de cet état de référence (x₀, P₀) pour se calibrer. Le GRP est donc la condition d'entrée au système IN-SIGHT pour chaque véhicule et définit la qualité de tous les diagnostics futurs.

La philosophie du protocole repose sur le concept de référence personnalisée : au lieu de comparer le véhicule à des valeurs nominales du constructeur (qui ne reflètent ni l'usure accumulée ni les particularités individuelles de chaque unité), IN-SIGHT compare chaque véhicule à lui-même dans son meilleur état connu.

Les trois phases du protocole

  1. Phase de Capture — Parcours de référence en conditions contrôlées : vitesse constante sur un tronçon connu, température de bogie entre 20-40°C, aucune alerte active préalable, minimum 45 minutes de circulation continue (ou 50 km). Pendant le parcours, les Pods enregistrent à résolution maximale : ~1 200 canaux à 3 200 Hz = ~1,4 Go/h de données brutes.
  2. Phase de Validation Automatique — Le système vérifie automatiquement : couverture spectrale complète (DC–6 kHz sans gaps), absence d'artefacts de saturation ou de clipping, stabilité temporelle des métriques (variance dans ±15 % de la valeur médiane), cohérence entre les multiples pods d'un même véhicule. Si une vérification échoue, le Golden Run est rejeté avec un diagnostic de cause racine.
  3. Phase d'Approbation et de Certification — L'ingénieur de flotte responsable examine les résultats dans le portail, compare le spectre de fréquences aux golden runs précédents (s'ils existent) et signe numériquement la référence. À partir de ce moment, le véhicule passe à l'état « monitored » et l'EKF s'active en utilisant cette référence.
Re-certification obligatoire : Le Golden Run expire après 12 mois ou après toute intervention majeure sur les sous-systèmes surveillés (remplacement de roulement, de roue, d'actionneur de porte). Cela garantit que la référence reflète toujours l'état actuel du véhicule.

Données capturées et stockage

Pendant le Golden Run, on capture, par véhicule et par session :

  • Signaux de vibration : 6 canaux triaxiaux (2 pods × 3 axes) à 6 667 Hz.
  • Signaux acoustiques : 2 canaux microphone MEMS (portes) à 3 200 Hz.
  • Température : Température de bogie et électronique, à 1 Hz.
  • Métadonnées contextuelles : Vitesse (intégrée depuis l'accéléromètre), timestamp synchronisé GPS, identifiant de tronçon de voie.

Les données brutes sont stockées dans Azure Data Explorer dans le tier cold (Parquet compressé, ~95 Mo par Golden Run). Les paramètres EKF dérivés (x₀, P₀, matrices de bruit Q et R ajustées) sont stockés dans le Device Twin de l'IoT Hub et téléchargés sur le CM4 à la synchronisation suivante.

Golden Run session
├── raw_signals/          ← Parquet, ADX cold tier
│   ├── pod_a_acc.parquet     (~85 Mo)
│   └── pod_b_acc_mic.parquet (~32 Mo)
├── ekf_params.json       ← matrices x0, P0, Q, R
├── spectral_baseline.npy ← FFT médiane par canal
└── certificate.json      ← signature numérique + metadata