Vehicle-to-Grid (V2G) Data & Energy Exchange Platform
Primary service
Data Modeling & Lineage
Secondary service
Real-time Monitoring & Anomaly Detection
Proposed Cadvel capability — not a client case study.
Target client and segment
V2G program operators, utilities, aggregators and bidirectional EV fleets
Challenge
Bidirectional charging adds a second energy flow and a more demanding evidence trail. Operators need to reconcile requested discharge, actual export and customer constraints before assessing a program’s value.
Key capabilities
- Separate, traceable records of charging energy and exported energy.
- A view of requested versus observed response, constrained by vehicle availability.
- Reconciled interval data for program evaluation and downstream settlement checks.

Business Challenge
Compatibility is specific to the equipment
A protocol label alone does not establish end-to-end bidirectional capability. Vehicle, charger, firmware and EMS behavior must be verified together.
Import and export can be confused
Inconsistent signs, meter boundaries and clock alignment can turn energy exchange reports into incorrect net totals.
Mobility commitments limit flexibility
Minimum state of charge, departure times and customer overrides can change the energy available for a grid event.
Settlement evidence is incomplete
A control acknowledgement is not a billable energy measurement. Interval readings, tariff versions and exception handling are separate requirements.
Architecture and Tech Stack
Vehicle and charger interfaces plus meter readings → validated directional events → vehicle–session–meter model → command-to-measurement reconciliation → operator views and settlement-ready exports. Maintain immutable source readings and versioned corrections.
Technology options
A transactional database for session and command state; Kafka where asynchronous event replay is needed; ClickHouse for telemetry investigation; dbt for interval reconciliation. AWS or Azure hosting is a proposed choice, subject to deployment constraints.
Delivery boundary
Validate actual hardware and protocol combinations with the control-system provider. Cadvel’s data layer neither certifies V2G interoperability nor assumes market eligibility; settlement acceptance is a client program requirement.
Implementation and Solution
Proposed implementation stages
Define a bounded pilot
Confirm compatible equipment, metering boundaries, driver constraints and the intended grid service.
Model energy exchange
Separate import and export; align clocks and link requests, sessions and meter intervals.
Test exceptional states
Exercise disconnects, overrides, rejected commands and missing readings; investigate reconciliation gaps.
Evaluate and release
Compare pilot evidence with agreed criteria; approve data exports and operator procedures before expansion.
What this enables
Measurable success criteria — to be agreed and validated with the client; not achieved results.
Directional reconciliation
Absolute kWh difference between session and reference-meter import/export totals per pilot event.
Response tracking
p95 seconds from an accepted instruction to observed power response in the intended direction.
Driver constraint compliance
Eligible events completed without violating agreed mobility constraints ÷ eligible events.
Evidence completeness
Settlement intervals with valid readings, identifiers and tariff version ÷ expected intervals.
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 IMP PAN example describes AC and bidirectional charger integration with a local EMS. Its separate Flux story is explicitly a proof of concept for V2X control, energy tracking and billing. Neither source establishes commercial V2G market qualification for this proposed solution.
Reference context only. Proposed Cadvel design and KPIs are independent of the source delivery.