Case studyML / Energy2025
Forecasting EV charging demand to optimize smart grids
Operators needed a recommendation they could act on, not a probability distribution to interpret themselves.
- Context
- Public EV charging networks face demand spikes that strain local grid capacity, and static planning rules cannot keep up with how usage actually varies.
- What I built
- Machine learning demand models paired with ChargeGuide, a decision layer that turns a forecast into a charging network recommendation.
- Headline result
- A forecasting system and applied research testbed that now feeds directly into my doctoral work on grid load management.
Specification
- Role
- Independent researcher and builder
- Timeline
- 2025
- Stack
- Machine learning, Python, predictive modeling
- Status
- Applied research
The problem
Public EV charging networks see demand that swings by location, time of day, and season in ways static capacity rules were never built to handle. Operators need a forecast that anticipates a spike ahead of time, not a fixed threshold calibrated to average conditions.
As adoption grows, the gap between planned capacity and actual usage becomes a real constraint on how reliably a network can serve drivers. Any approach had to hold up across genuinely variable, real-world usage patterns rather than an idealized load curve, and it had to produce something an operator could act on, not just a number.
The approach
I chose machine learning forecasting over static demand rules because charging patterns vary by location, time, and season in ways fixed thresholds cannot capture. A model that learns from usage data adapts as patterns shift; a fixed rule has to be retuned by hand every time conditions change, which is exactly the maintenance burden a growing network cannot absorb.
I built ChargeGuide as a separate decision layer on top of the models rather than exposing raw predictions. Operators needed a recommendation they could act on, so ChargeGuide translates a forecast into a concrete network decision. Keeping that translation separate also meant I could improve one side without retesting the other from scratch.
I prioritized interpretability over marginal accuracy gains. In an applied context feeding a live decision layer, a forecast an operator cannot reason about is a forecast they will not trust, so I favored approaches whose outputs I could explain. That tradeoff felt obvious once I framed it as a decision an operator has to defend, not a benchmark score to optimize in isolation.
I treated the project as an applied testbed for the grid-optimization thinking I was already developing in my doctoral research, particularly around real-time load balancing. Building against real charging demand data gave that research a working system to test ideas against instead of a purely theoretical model.
- 01
Usage data
Real charging behavior by location, time of day, and season.
- 02
Demand model
A learned forecast that adapts as patterns shift, chosen for outputs that can be explained.
- 03
ChargeGuide
A separate decision layer that turns the forecast into a concrete recommendation.
- 04
Operator action
A decision the operator can act on, and defend, ahead of the spike.
Operators needed a recommendation they could act on, not a probability distribution to interpret themselves.
The outcome
The models and ChargeGuide give operators a way to anticipate charging demand instead of reacting to it after a spike has already strained the grid. The more durable result is where the work went next: it became the applied seed for the grid-optimization and EV infrastructure pillars of my dissertation, which now studies real-time load balancing and cooperative agent decision-making.
This feeds directly into my doctoral research rather than sitting separate from it, and that connection is why I still treat it as active rather than finished. The forecasting problem did not end when the project did. It moved into a longer question about how far cooperative, agent-based control can push load balancing beyond what a single model does on its own.
What I would do differently
Formalize the handoff between the applied build and the dissertation research earlier, so the connection was structured from the start instead of becoming clear in hindsight. Instrument ChargeGuide’s recommendations against real outcomes sooner, to close the feedback loop faster.
Some specifics are abstracted for confidentiality. I am glad to go deeper in conversation.