Connected Vehicles & Fleet

The Vehicle as a Data Endpoint

A modern connected vehicle generates 25–30 gigabytes of data per hour of driving from ECU logs, sensor streams, camera feeds, and CAN bus data. Fleet telematics systems filter this to a manageable telemetry stream — typically 50–500 signals at 1Hz — and transmit it over cellular. For a fleet of 10,000 vehicles running 8 hours/day, that is 4–40 TB of raw signal data per day. The engineering challenge is not storage — cloud storage is cheap — it is building the data pipeline that transforms raw telemetry into actionable fleet intelligence within minutes.

The US and EU connected vehicle ecosystem has distinct characteristics: pervasive 4G/5G coverage enables nationwide telematics, and regulation increasingly governs the software lifecycle rather than just the hardware. The UNECE R156 (software update management) and R155 (cybersecurity management system) regulations now make type approval contingent on a managed OTA and cybersecurity process, and ISO/SAE 21434 defines the engineering practice. This creates a compliance-driven data and process foundation that fleet AI applications must build on.

Telematics Data Pipeline Architecture

The canonical fleet telematics pipeline has four layers:

Layer 1: Edge (Vehicle)

The telematics control unit (TCU) or OBD-II dongle reads CAN bus data, applies local edge filtering, and transmits to cloud via MQTT or HTTPS. Edge processing reduces bandwidth — instead of streaming all CAN signals, edge compute aggregates to 1Hz samples and computes local features (harsh braking events, idling time).

Layer 2: Ingestion

AWS IoT Core / Azure IoT Hub / GCP IoT Core handles MQTT ingestion, device authentication (X.509 certificates per vehicle), and fan-out to processing streams. For a US fleet deployment, us-east/us-west region hosting reduces latency; for the EU, eu-central hosting also keeps data resident per GDPR.

Layer 3: Stream Processing

Apache Kafka + Flink or AWS Kinesis + Lambda processes the real-time stream. Use cases requiring < 1 minute latency: geofence breach alerts, route deviation, harsh event notification.

Layer 4: Batch Analytics

S3/GCS data lake with hourly Spark jobs for fleet-level aggregations, driver scoring computation, and ML model inference on historical data.

# Telematics event processing — harsh braking detection
# Open data/fleet-telematics-stream.json for sample CAN bus telemetry

import json

with open("data/fleet-telematics-stream.json") as f:
    stream = json.load(f)

# Each record: {vehicle_id, timestamp_ms, lat, lon, speed_kmh,
#               longitudinal_accel_g, lateral_accel_g, engine_rpm,
#               fuel_level_pct, coolant_temp_c, dtc_codes}

def detect_harsh_events(records, vehicle_id):
    vehicle_records = [r for r in records if r["vehicle_id"] == vehicle_id]
    vehicle_records.sort(key=lambda x: x["timestamp_ms"])

    harsh_braking = []
    for r in vehicle_records:
        if r["longitudinal_accel_g"] < -0.35:  # > 3.4 m/s² deceleration
            harsh_braking.append({
                "timestamp": r["timestamp_ms"],
                "location": (r["lat"], r["lon"]),
                "severity_g": r["longitudinal_accel_g"],
                "speed_at_event_kmh": r["speed_kmh"]
            })

    return harsh_braking

events = detect_harsh_events(stream["records"], "FLEET-AB-1234")
print(f"Harsh braking events: {len(events)}")

OTA Update Rollout Strategy

Over-the-Air (OTA) software updates are how connected vehicles receive ECU software updates, map refreshes, and feature additions post-sale. Tesla popularised overnight OTA updates; GM (Ultifi), Ford (Power-Up), VW, Stellantis, and Rivian all now offer OTA across their connected platforms.

The engineering challenge is controlled rollout: a software update deployed to 50,000 vehicles simultaneously that introduces a regression can trigger a massive recall — and under UNECE R156, the update process itself is type-approved, so an uncontrolled rollout is also a compliance failure. ML-assisted staged rollout:

Canary and Blue-Green Deployment for Vehicles

ML models monitor telemetry from updated vehicles vs. non-updated vehicles, detecting:

The statistical test is a two-sample test (e.g., Kolmogorov-Smirnov) on the distribution of each monitored metric, with Bonferroni correction for multiple comparisons across the 50+ metrics monitored per vehicle.

Prompt: "I am planning an OTA rollout for a BMS calibration update to 45,000 EVs.
The update changes SOC estimation algorithm from EKF to LSTM-based estimator.
Key risk: if the LSTM estimator has a systematic bias in high-temperature conditions,
range estimates will be wrong for customers in Arizona and Southern Europe.

Design the staged rollout monitoring plan:
1. What metrics to monitor during canary phase (which DTC codes, telemetry signals)
2. Statistical test design for detecting regression vs. baseline fleet
3. Rollback decision criteria — what constitutes a 'stop rollout' signal
4. Communication plan: how to notify affected customers if rollback is triggered
   (and the UNECE R156 documentation required for the update campaign)"

Fleet Route Optimization

For commercial fleet operators — logistics companies, ride-hail platforms, last-mile delivery — route optimization directly impacts fuel cost, driver utilisation, and delivery SLA compliance. The Vehicle Routing Problem with Time Windows (VRPTW) is the mathematical framework; ML enhances it with learned travel time estimates that outperform static map-provider ETAs for regular routes.

Traffic-Aware Routing

Static routing assumes deterministic travel times. US and EU urban traffic — particularly in metros like Los Angeles, New York, London, and Paris — has high temporal variance driven by:

ML routing models trained on historical GPS telemetry from the fleet itself outperform third-party APIs because they capture route-specific patterns invisible to aggregate map data:

# Building a travel time prediction model from fleet GPS data
# Open data/fleet-route-history.json for 6 months of trip records

import json
import numpy as np
from sklearn.ensemble import GradientBoostingRegressor

with open("data/fleet-route-history.json") as f:
    trips = json.load(f)["trips"]

# Features for each route segment (origin_zone → dest_zone):
# hour_of_day, day_of_week, month, is_holiday_week, precipitation_mm,
# avg_speed_trailing_15min, historical_percentile_travel_time

X = np.array([[t["hour"], t["dow"], t["month"], t["is_holiday"],
               t["precip_mm"], t["trailing_speed"]] for t in trips])
y = np.array([t["actual_travel_time_min"] for t in trips])

gbr = GradientBoostingRegressor(n_estimators=200, max_depth=5, learning_rate=0.05)
gbr.fit(X, y)

# Route planning: use predicted travel times as edge weights in Dijkstra/A*
# Recompute edge weights every 15 minutes during peak hours

Usage-Based Insurance Models

Usage-Based Insurance (UBI) prices vehicle insurance based on actual driving behaviour rather than demographic proxies. Telematics data enables per-trip risk scoring. The market in the US and EU:

UBI Feature Engineering

From the raw telematics stream, the canonical UBI features:

Model architecture: gradient boosted trees on aggregated monthly features (not raw telemetry) predicting claim probability and claim severity separately. The product is a risk multiplier applied to base premium.

Cyber and OTA Compliance: R155, R156, and ISO/SAE 21434

UNECE R155 mandates a Cybersecurity Management System (CSMS) across the vehicle lifecycle, R156 mandates a Software Update Management System (SUMS), and ISO/SAE 21434 is the engineering standard that operationalizes them. Type approval in UNECE markets (EU, UK, Japan, Korea, and others) now requires:

The OEM compliance engineering task: ensure the TCU firmware, OTA backend, and update campaign tooling meet R155/R156 requirements, with signed updates, secure boot, and an auditable update ledger. ML-relevant aspect: anomaly detection on fleet telemetry doubles as an intrusion-detection signal feeding the CSMS — unexpected CAN traffic patterns or DTC anomalies can indicate either a defect or a security event, and the same anomaly pipeline serves both.

Key Takeaways