Rob Hollinshead

Depot charging is a scheduling problem wearing a hardware costume

2 min read
Depot infrastructureSmart charging

Sample post. This is placeholder content seeded to exercise the blog pipeline — listing, detail page, tags, and sharing. Replace it with a real post when ready.

Most depot electrification projects get sold on hardware: how many chargers, what power rating, how much trenching. All of that matters, but it's not what decides whether a depot actually works on day one.

The real constraint is time, not power

A depot with 40 vehicles and 20 chargers doesn't have a charger shortage — it has a scheduling problem. Vehicles arrive in a cluster after the last shift, need to be ready before the first shift, and the grid connection has a ceiling well below "everyone charges at once, full power."

Three questions decide whether the depot design will hold up:

  1. What's the actual dwell time distribution, not the average?
  2. How much of the fleet needs to be ready by the earliest departure, versus the latest?
  3. What happens on the one night a depot manager plugs in eight vehicles that weren't in the plan?

Software has to do the job hardware can't

You can oversize the grid connection to make the scheduling problem go away, but that's expensive and slow to permit. The alternative is software that sequences and throttles charging sessions against a known departure schedule — which only works if the depot's operational data (routes, shift patterns, vehicle SoC) actually reaches the charging system.

That integration gap — not charger count — is where most depot projects lose months.

Where this actually bites

The failure mode isn't a blackout. It's quieter: a handful of vehicles that don't hit full charge before their shift, every few weeks, for reasons nobody can immediately explain. Debugging that after the fact is much harder than designing for it up front.