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.

India's connected vehicle ecosystem has unique characteristics: Jio's 4G penetration extends to tier-3 cities, enabling telematics coverage that would have required expensive dedicated networks a decade ago. The Government of India's mandate for vehicle tracking under CMVR (Central Motor Vehicles Rules) for commercial vehicles drove rapid adoption — over 3 million commercial vehicles had Automatic Vehicle Tracking (AIS-140 compliant) as of 2023. This creates a data foundation that fleet AI applications can 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 an Indian fleet deployment, Mumbai region hosting reduces latency.

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"], "MH12-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; Indian OEMs — Tata Motors (Nexon EV), Ola Electric, Mahindra XEV series — all now offer OTA.

The engineering challenge is controlled rollout: a software update deployed to 50,000 vehicles simultaneously that introduces a regression can trigger a massive recall. 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 Tata Nexon 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 Chennai and Hyderabad.

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"

Fleet Route Optimization

For commercial fleet operators — logistics companies, taxi aggregators, 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 Google Maps ETAs for regular routes.

Indian Traffic-Aware Routing

Static routing assumes deterministic travel times. Indian urban traffic — particularly in Delhi, Mumbai, Bengaluru, and Chennai — 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_festival_week, rainfall_mm,
# avg_speed_trailing_15min, historical_percentile_travel_time

X = np.array([[t["hour"], t["dow"], t["month"], t["is_festival"],
               t["rainfall_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 India:

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.

CMVR Compliance: AIS-140 and Beyond

AIS-140 mandates a Vehicle Location Tracking (VLT) device with emergency button, tamper detection, and GPRS transmission to the Vahan platform for:

The OEM compliance engineering task: ensure the TCU firmware and backend integration meet AIS-140 data format requirements, transmission intervals (at minimum 1 Hz position updates when moving), and Vahan API endpoint integration. ML-relevant aspect: the Vahan data is a secondary enrichment source for fleet analytics, and anonymised aggregate flows are available for urban mobility research.

Key Takeaways