Home / Work / 004

Race-day telemetry, thirteen channels, no second attempt

A race weekend does not pause while you restart a service. Building ML for motorsport telemetry taught me that the modelling is the easy half — the hard half is operating under a deadline that cannot move.

Saudi Motorsport Kafka Scikit-learn TensorFlow Docker Kubernetes
13Channels per lap
3Models in the loop
Real-timeStreaming inference

The problem

A car on track emits a continuous stream of measurements: throttle position, brake pressure, tyre temperatures across four corners, longitudinal and lateral G-forces — thirteen channels per lap, arriving without pause for the duration of a session.

The engineering value of that stream is entirely time-bound. Knowing that tyre degradation crossed a threshold is decisive information on lap 14 and a historical curiosity on lap 40. Detecting a mechanical anomaly is worth a great deal before the component fails and nothing afterwards.

So the constraint is not accuracy in the abstract. It is accuracy that arrives in time, on infrastructure that does not get a second attempt.

The operating reality

There is no maintenance window during a race weekend, no opportunity to redeploy mid-session, and no tolerance for a service that needs manual intervention. Reliability was a first-class requirement, not an afterthought.

Approach

Streaming ingestion

Kafka as the transport layer, which decouples telemetry ingestion from model inference. If a consumer stalls, the stream buffers rather than dropping data — and the models can be restarted independently without losing the session.

Three models, three questions

  • Anomaly detection — identifying channel behaviour inconsistent with the established envelope for that car, corner and session. Tuned deliberately toward sensitivity: a false positive costs an engineer thirty seconds of attention, a false negative can cost the session.
  • Lap-time prediction — projecting lap time from in-progress channel data, which turns the telemetry into a forward-looking strategy input rather than a backward-looking record.
  • Tyre degradation modelling — tracking thermal and performance decay across a stint to inform pit strategy.

Predictive maintenance

The same telemetry supports component-level failure prediction between sessions. I later generalised this into a standalone predictive maintenance pipeline — rolling feature engineering with an XGBoost failure predictor at AUC-ROC 0.97 and a 48–72 hour lead time.

Motorsport streaming telemetry architectureThirteen telemetry channels per lap flow through Kafka into feature computation and three parallel models — anomaly detection, lap-time prediction and tyre degradation — surfacing to the race engineer, with the whole inference path containerised for race-weekend reliability.STREAMING TELEMETRY ARCHITECTURECar on track13 channels / lapKafkabuffers, decouplesFeature computationrolling windowsAnomaly detectionsensitivity-weightedLap-time predictionin-progress lapTyre degradationstint decayRace engineerdecision in timeDocker + Kubernetes — identical environments, automatic restart, independent deployability
Fig. 1 — Streaming telemetry architecture. The dashed boundary is the containerised inference path.

Making it survive a race weekend

Everything was containerised with Docker and orchestrated with Kubernetes. That decision was not about scale — the throughput here is modest by data-engineering standards. It was about predictability:

  • Identical environments between development and trackside. The classic failure mode of a race-day system is an environment difference discovered at the worst possible moment.
  • Automatic restart on crash, without a human in the loop.
  • Independent deployability — updating the tyre model cannot take down anomaly detection.
  • Resource isolation, so one model's memory behaviour cannot starve another.

What I took from it

  • Latency budgets change model selection. Several architectures that scored better offline were disqualified by inference cost. Gradient-boosted and classical models earned their place on the clock, not the leaderboard.
  • Error asymmetry should be designed, not inherited. The cost of a false positive and a false negative differ by orders of magnitude here, and the decision threshold should reflect that explicitly.
  • Operational simplicity is a modelling constraint. A slightly worse model that restarts cleanly beats a slightly better model that needs attention during a session.
  • Domain experts are the evaluation set. Race engineers could tell instantly whether an anomaly flag was meaningful — feedback no offline metric was going to supply.

View the repository