EV Fleet Charging Data Aggregation for Utilities
Primary service
Data Modeling & Lineage
Secondary service
Performance & Cost Optimization
Proposed Cadvel capability — not a client case study.
Target client and segment
Utilities, charging aggregators and operators of multiple depots
Challenge
Charging data arrives through incompatible vendor interfaces. Utilities need one consistent fleet view without making each dashboard a separate integration project or allowing query costs to grow unchecked.
Key capabilities
- Comparable sessions, energy and availability metrics across charging vendors.
- Utility and depot views with explicit data ownership and access boundaries.
- Predictable analytical performance and cost as event volumes grow.
Business Challenge
The same event has different meanings
Vendors use different session boundaries, connector identifiers and status codes. A common schema must preserve the original meaning and source record.
Energy totals do not reconcile
Counter resets, missing closing readings and duplicate events can create mismatches between session energy and depot meters.
Fleet structure changes
Vehicles move between depots and chargers change ownership. Historical reporting needs effective-dated relationships, not only today’s asset list.
More data makes dashboards expensive
Repeated raw-event scans can slow operational views. Retention and aggregation policies need to follow actual utility queries.
Architecture and Tech Stack
Vendor APIs and protocol gateways → raw event archive and validation → canonical utility–depot–charger–connector–session model → analytical serving layer → tenant-scoped dashboards and data APIs. Preserve event identifiers and reconciliation status end to end.
Technology options
Kafka for asynchronous feeds; ClickHouse for high-volume event queries; dbt for repeatable session models and checks. Use object storage on AWS or Azure for raw history. Add a separate warehouse only if reporting requirements justify it.
Delivery boundary
Existing charging platforms retain operational control. Cadvel normalizes and serves data; source-specific capabilities and missing measurements stay visible rather than being flattened into false equivalence.
Implementation and Solution
Proposed implementation stages
Inventory feeds and workloads
Agree canonical metrics, data rights, query patterns and baseline operating costs.
Build the common model
Integrate representative vendors, retain source lineage and reconcile session energy with meter intervals.
Benchmark the serving layer
Test concurrency, late corrections and tenant isolation; tune partitions, aggregates and retention.
Onboard and operate
Publish versioned data contracts, vendor acceptance checks and a measured cost and performance budget.
What this enables
Measurable success criteria — to be agreed and validated with the client; not achieved results.
Reconciliation exceptions
Session-to-meter energy variance in kWh per depot and day, using aligned measurement boundaries.
Data coverage
Expected vendor events or reporting intervals received and validated ÷ expected events or intervals.
Query response
p95 seconds for agreed fleet queries at the agreed concurrent-user load.
Unit platform cost
Monthly ingestion, storage and query cost per million accepted events at a fixed retention policy.
KPI targets and acceptance tolerances are set with the client during discovery; no achieved outcomes or ROI are asserted.
Source inspiration / reference
Source-derived facts
Codibly’s eFleet case describes a platform for an unnamed global technology provider, with remote charging management, demand response and multi-tenant permissions. It lists OCPP, MODBUS and ChargePoint API integration. The canonical model and cost optimization approach below are Cadvel proposals.
Reference context only. Proposed Cadvel design and KPIs are independent of the source delivery.
