How FleetEnergies Cut Fleet Emissions 40% on a Real-Time Decarbonization Loop

By the time FleetEnergies brought us in, the telematics was already there. The intelligence wasn't. FleetEnergies operates across France and India helping customers cut both the energy costs and the environmental footprint of their vehicle and heavy-equipment fleets, and the raw signal they sat on was enormous: a large mixed-OEM network of Mercedes, Scania, Renault, Volvo and other vehicles, instrumented with OEM and aftermarket telematics devices including AGX and Teltonika, streaming position, fuel, load and engine data continuously. The problem was that this signal lived in more than 300 on-prem databases, roughly 50 TB of it, fragmented by vehicle, by device vendor, and by customer. Generating a report meant stitching those sources together by hand and waiting hours, by which point the operational moment the report described, an idling truck, an empty return leg, a fuel anomaly, had already passed. FleetEnergies had built the sensing layer and the customer base that depended on it, and the decarbonization thesis was sound. What they didn't have was a unified platform that could turn 2 million events a day into a decision in seconds, or a real-time surface that could act on an emissions lever while it still mattered.

The RILCO2 platform now runs end-to-end on Microsoft Fabric, with OneLake as the single central data repository and Real-Time Intelligence (RTI) as the surface for everything in motion. Telematics signal from the OEM and aftermarket devices, AGX, Teltonika and the rest, lands in Fabric through Data pipelines for the historical and batch corpus and through Eventstream for the live stream; Fabric Data Engineering on Spark transforms and aggregates it; and an Eventhouse stores and serves the time-series events for low-latency KQL queries. Power BI and Real-Time Dashboards sit on top for analytics, Activator watches the stream for conditions that warrant an immediate response, and consumer-facing applications run as containerized workloads on Azure Kubernetes Service (AKS) with Azure Functions handling serverless microservices such as carbon-emission calculation. Governance followed the Microsoft Cloud Adoption Framework throughout. The data moves through three coordinated stages. Ingestion splits by tempo: Fabric Data pipelines extract from the legacy on-prem sources and load roughly 50 TB into OneLake, while Eventstream takes the live device feed, around 2 million events a day, off the mixed-OEM fleet. Processing runs in Fabric Data Engineering on Spark, normalizing the divergent device schemas, aggregating fuel, load and route telemetry, and writing into the Eventhouse for time-based query. Real-time serving exposes that surface two ways: Real-Time Dashboards and Power BI reports for the operational and analytics views, and Activator for detection, firing alerts the moment a threshold trips, including theft detection when a vehicle moves against pattern, while the AKS apps and Azure Functions serve customer-specific workloads and the carbon math. Crucially, we moved more than 300 on-prem databases into this platform with zero downtime to daily operations and 100% data integrity, and we used the same real-time backbone to close a decarbonization loop rather than just report on one. The platform does not stop at measuring emissions; it acts on the four levers that move them. Load optimization reads how vehicles are actually filled and rebalances against capacity, fuel monitoring integration surfaces consumption anomalies as they happen, energy optimization tunes routes and operating profiles, and empty-ride reduction targets the unladen return legs that burn fuel for no payload. Because detection, calculation and alerting all run on the live RTI stream, an emissions lever can be pulled while the trip is still underway, which is what turns a 40% carbon reduction from a quarterly chart into an operating result.

Two things, honestly. First, we under-scoped schema normalization across 300 sources. The migration headline, 300-plus databases at 100% integrity with zero downtime, was real, but the harder cost was hidden inside the variance: every one of those sources had drifted independently over years, and the same field, a fuel reading, an odometer value, a vehicle identifier, carried different units, types and null conventions depending on which database and which device generation it came from. We built much of that reconciliation as a transformation layer in flight when it belonged in a hardened, source-by-source mapping contract written before any pipeline ran. Next time we'd treat schema normalization as the first deliverable, not a stage inside ingestion. Second, we cold-started the Activator alerting thresholds on assumptions rather than on the live distribution. With mixed OEM and aftermarket devices, AGX and Teltonika and the OEM telematics, event-schema drift between device families meant a fuel-anomaly or theft threshold tuned against one device fired noisily against another. The detection logic was sound, but the first weeks produced false positives until we rebaselined per device class. We should have run Activator in a logging-only mode against two weeks of real stream traffic before letting it raise a single alert.