← Back to Architecture Operational protocol · Baseline

Golden Run
Protocol

The reference signature of the healthy vehicle. A controlled, certified run that establishes the zero state against which the Kalman Filter will compare every future signal.

What it is

The Golden Run Protocol (GRP) is IN-SIGHT's proprietary operational methodology to capture, validate and certify the nominal health signature of a railway vehicle. It is the functional equivalent of a "health snapshot" taken when the vehicle is in optimal condition and freshly maintained.

Without a valid Golden Run, the system cannot operate in detection mode: the Kalman Filter needs that reference state (x₀, P₀) to calibrate itself. The GRP is therefore the entry condition to the IN-SIGHT system for each vehicle and defines the quality of all future diagnoses.

The protocol's philosophy is based on the concept of a personalised baseline: instead of comparing the vehicle against manufacturer nominal values (which reflect neither accumulated wear nor the individual peculiarities of each unit), IN-SIGHT compares each vehicle against itself in its best known state.

The three phases of the protocol

  1. Capture Phase — Reference run under controlled conditions: constant speed on a known section, bogie temperature between 20-40°C, no prior active alerts, a minimum of 45 minutes of continuous running (or 50 km). During the run, the Pods record at maximum resolution: ~1,200 channels at 3,200 Hz = ~1.4 GB/h of raw data.
  2. Automatic Validation Phase — The system automatically checks: full spectral coverage (DC–6 kHz with no gaps), absence of saturation or clipping artifacts, temporal stability of the metrics (variance within ±15 % of the median value), coherence across the multiple pods of the same vehicle. If any check fails, the Golden Run is rejected with a root-cause diagnosis.
  3. Approval and Certification Phase — The responsible fleet engineer reviews the results in the portal, compares the frequency spectrum with previous golden runs (if any) and digitally signs the baseline. From that moment, the vehicle moves to the "monitored" state and the EKF activates using that baseline.
Mandatory re-certification: The Golden Run expires after 12 months or after any major intervention on the monitored subsystems (bearing, wheel or door-actuator replacement). This ensures the baseline always reflects the vehicle's current state.

Captured data and storage

During the Golden Run, the following is captured per vehicle and session:

  • Vibration signals: 6 triaxial channels (2 pods × 3 axes) at 6,667 Hz.
  • Acoustic signals: 2 MEMS microphone channels (doors) at 3,200 Hz.
  • Temperature: Bogie and electronics temperature, at 1 Hz.
  • Contextual metadata: Speed (integrated from the accelerometer), GPS-synchronised timestamp, track-section identifier.

The raw data is stored in Azure Data Explorer in the cold tier (compressed Parquet, ~95 MB per Golden Run). The derived EKF parameters (x₀, P₀, tuned Q and R noise matrices) are stored in the IoT Hub Device Twin and downloaded to the CM4 at the next synchronisation.

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 ← median FFT per channel
└── certificate.json      ← digital signature + metadata