Fleet Intelligence System

A Tier-1 commercial vehicle supplier needed real-time visibility into a heterogeneous fleet of 12 000 trucks, vans, and specialty vehicles spread across eight European countries. Individual vehicle data was locked in proprietary telematics boxes, inaccessible for cross-fleet analytics. In less than six months, MobilityCortex delivered a production-grade fleet intelligence platform ingesting over two million events per day.

Problem: Fragmented Telematics, No Fleet-Level Insight

The client operated vehicles from four OEM sources, each with a different telematics system. Data was siloed: per-OEM portals with no API access, proprietary binary formats, and retention policies as short as 30 days. There was no way to answer cross-fleet questions — which vehicles were approaching service intervals, where route efficiency was degrading, which drivers showed risk-relevant behavior patterns — without manual data exports and spreadsheet reconciliation.

• 4 telematics providers, 3 proprietary binary formats + 1 REST API
• No common vehicle identifier across systems
• Alert latency: 4–48 hours (batch exports)
• Data retention: 30–90 days depending on provider

Architecture: Event-Driven Ingestion at Scale

The platform is built on an event-driven architecture with a multi-source ingestion layer that normalizes all vehicle signals into a unified Vehicle Signal Specification (VSS)-compatible schema in real time. Each telematics connector runs as an independent microservice, decoupled from the processing pipeline via Kafka topics.

Ingestion Layer

Custom connectors handle each telematics source: a binary CAN log parser for OEM A, a MQTT bridge for OEM B, a polling REST adapter for OEM C, and a direct FTP batch processor for legacy OEM D data. All connectors publish normalized VehicleEvent messages to Kafka, tagged with a canonical vehicle ID derived from VIN cross-referencing.

Stream Processing

Apache Flink consumes the Kafka streams for stateful real-time computation: rolling odometer reconciliation, driving-style scoring (harsh braking, acceleration, cornering detection via 3-axis IMU signals), geo-fence violation detection, and fault code aggregation. Aggregated metrics are published to a time-series store (TimescaleDB) for dashboard queries and to PostgreSQL for operational records.

-- Example: vehicles approaching service threshold
SELECT vehicle_id, vin, odometer_km, last_service_km,
       (odometer_km - last_service_km) AS km_since_service
FROM fleet.vehicle_state
WHERE (odometer_km - last_service_km) > 14500   -- 500 km before 15k interval
ORDER BY km_since_service DESC;

Alerting & Notifications

A rule engine evaluates configurable threshold conditions (DTC severity, geofence, idle duration, fuel anomaly) against incoming events with P95 latency under 800 ms. Alerts route via PagerDuty for dispatch teams and webhook integrations for the client's ERP system (automated work order creation on critical fault codes).

Results

Technology Stack

• Apache Kafka (MSK) for event streaming and backpressure management
• Apache Flink for stateful stream processing and CEP
• TimescaleDB for time-series metrics, PostgreSQL for operational state
• Next.js dashboard with WebSocket live updates
• Kubernetes (EKS) — connectors and processors as independently-scaled deployments
• Terraform + Terragrunt for multi-environment infrastructure as code

Interested in this capability?