482 kW vs a 250 kW Transformer: How We Taught 40 Electric Vans to Share
A CP-SAT solver, a deadline-first rule and an independent safety validator let a 40-van EV depot run its whole night on a 200 kW connection instead of waiting 18 months for a grid upgrade. Here is the engine I built for AWS Environmental Hacks, including the experiment where the smarter solver lost the emergency.
Built for AWS Environmental Hacks (WeMakeDevs x AWS, DTU) · Track 03: Waste and Energy · Team AWSome Builds (HMSH4K)
Picture a delivery depot at 6 PM.
Forty electric vans roll in after a long day. Drivers hand over the keys, plug in, go home. Nobody did anything wrong. Every single van just did exactly what a van is supposed to do.
And the depot's power demand jumps to 482.6 kW.
The transformer feeding that depot is rated for 250 kW. That is 93% over its limit, caused by nothing more sinister than people plugging things in.
This is the quiet problem hiding inside "electrify the fleet". Everyone talks about the vans. Almost nobody talks about the wire in the ground that feeds them. And the standard fix, asking the utility for a bigger connection, means up to 18 months of waiting and a very large bill. Meanwhile all that charging lands in the evening peak, when the grid is at its dirtiest.
So we asked a different question: what is the smallest connection this depot actually needs, and can we run the whole night safely on it?
The answer turned out to be 200 kW. This post is about how we got there, what I built along the way, and (spoiler) the scariest bug of the whole weekend was not in the code. It was a YouTube upload bar. More on that at the end.
Our project is the Depot Connection Planner, and you can poke at the live version here: http://ec2-100-56-128-36.compute-1.amazonaws.com
The result, up front
Compared with the unmanaged baseline, on our live dashboard in Green mode:
- -48.2% — peak transformer load
- -51.3% — electricity cost
- -34.6% — carbon emissions
- 40 / 40 — vans fully charged by departure
The dashed grey curve is the unmanaged spike. The blue curve is the same fleet, same night, managed. These are simulated benchmark results (the depot telemetry is simulated; the AWS services are live).
The puzzle, in four numbers
- 40 delivery vans
- 10 fast chargers, 50 kW each
- 250 kW from the utility
- 96 time slots of 15 minutes across a day
If all ten chargers run flat out, the depot asks for 500 kW from a 250 kW wire. So only five can ever run at once. Forty vans, five plugs at a time, and every van must be full before it leaves. That is the whole game.
My part: the brain under the dashboard
Our team split the project into four layers. Roopanshu built the backend and the Amazon Bedrock assistant, Sarthak built the AWS infrastructure, Taksh built the dashboard. I built the part that decides who charges when, and then checks that the decision is safe. Five files, five jobs:
The solver and the rule propose. The validator decides. Only a schedule that passes reaches the operator.
Let me take them in the order we met them. Disaster first.
1. Making the disaster reproducible
You cannot prove you fixed a problem you cannot reproduce. So before writing any clever code, I wrote the villain.
The baseline is the "do nothing clever" depot: a van arrives, grabs the first free charger, and charges at full speed until it is full. No planning. No idea the wire exists.
Run it on our fleet and the load shoots up to 482.6 kW. That number became the anchor for the whole project. Every later result is a comparison against it.
2. The solver: let math pick the quiet hours
Now the fun part. For every van, every charger and every 15-minute slot, the solver has to answer one question: is this van plugged in right now, and how hard is it charging?
I used Google's OR-Tools CP-SAT, which you can think of as an extremely patient puzzle solver. You give it the rules, and it searches for the best answer that breaks none of them. The rules are the physics, and they are not negotiable:
- one van per charger, one charger per van
- total draw never above the transformer limit
- no charging while a van is out on the road
- every van gets the energy it needs before it leaves
Everything else goes into one score the solver tries to minimise: the electricity price at that hour, how dirty the grid is at that hour, and how spiky the load gets. I also added a small bonus for leaving a van on the same charger so the night-shift attendant is not sprinting around swapping cables.
The result: charging drifts into the cheap, clean hours of the night, and the peak flattens out under the cap instead of crashing through it.
What fought back: the solver only counts in whole numbers
CP-SAT is brilliant, but it only understands whole numbers. Electricity costs 4.20 rupees. Energy needed is 31.4 kWh. None of that is a whole number.
So I translated everything. Energy became a count of "kilowatt slots", and I always rounded up, because rounding down would quietly short-change a van and send it out half full. Prices were multiplied up into whole numbers. And carbon is tiny next to rupees, so I scaled it up, because otherwise the solver would treat carbon as an afterthought and our "carbon-aware" claim would just be marketing.
One more guard: before the solver starts, the code checks whether each van can even physically reach full charge in the time it is parked. If not, it says so in plain English ("Vehicle V08 physically cannot reach its target...") instead of grinding away and returning a mystery error. Operators need reasons, not error codes.
3. The plot twist: the smarter solver lost the emergency
The experiment in one line: the utility cuts the depot's limit from 250 kW to 180 kW at 21:15. The clever optimizer recovered 72% of the time. A much simpler deadline-first rule recovered 100%.
I was fully expecting the optimizer to win this one. It did not.
Here is the scenario. At 21:15 the utility, struggling with its own congestion, suddenly cuts the depot's limit to 180 kW. Now only three chargers can run instead of five.
The optimizer had cleverly pushed charging into the clean late-night hours to save carbon. Which means it had spent its spare time waiting for the greenest window. When the cap dropped, there was no spare time left to recover. On the dashboard you can see it labelled right in the corner: "Green CP-SAT (72% Recovery)".
Being the best on a normal night is not the same as being safe on a bad one.
So I built the opposite: a deliberately simple rule called Earliest Deadline First. It works like a boarding gate. Every slot, look at who is in the depot and still needs charge, and give the chargers to whoever leaves soonest. When the cap drops to 180 kW, the rule just uses three chargers instead of five and carries on. No fuss.
Add one small trick, sticky chargers: if a van was on charger C03 a moment ago and is still selected, it stays on C03. A naive plan unplugs and replugs vans all night. Stickiness keeps the physical work to about 18 cable moves a night, versus 38 for the solver, and gives the attendant a clean checklist: plug in, unplug, swap, with times.
Scoreboard from our simulated 60-night benchmark:
The trade is honest, though: the safe rule gives up most of the savings (on the dashboard in Safe mode it is about -16.2% cost and -3.2% carbon, versus -51.3% and -34.6% in Green).
So the system has two brains. Green when the night is calm and you want the cleanest, cheapest charge. Safe when something breaks and you need a plan in a blink that cannot go wrong. The humble rule won the emergency, and that is the part I am proudest of, because it came from letting the test results overrule the clever idea.
4. The referee: trust no one, not even me
We agreed on one rule early: nothing that can hurt a transformer is allowed to be "probably right".
The solver can have bugs. The simple rule can have bugs. And once Amazon Bedrock joins in to explain incidents to the operator, a language model should definitely not be the one adding up 40 vans across 96 time slots.
So the validator is a separate referee with one job. It takes any schedule, from the solver, from the rule, from anywhere, and checks it from scratch with plain arithmetic. Is the transformer ever overloaded? Is a charger double-booked? Is a van plugged into two places at once? Is anyone charging while away, or leaving half full? Seven checks in total.
It does not take the solver's word for anything. If something is wrong, it names the exact time slot, the exact van and the exact rule that broke. Only a schedule that passes is shown to the operator.
That is how the final system can say, with a straight face: "the AI explains; the validator decides."
5. The oracle: proving 200 kW
Everything above answers "how do we run the night". The sizing oracle answers the question that started this whole project: what is the smallest connection that still works?
It plays a game of twenty questions with the solver. "Can all 40 vans be ready with 250 kW?" Yes. "With 200?" Yes. "With 175?" No. It keeps narrowing down until it finds the smallest connection that still works, then presents it as a certificate.
Across our 60 simulated nights, the honest picture is:
- Relaxed (early arrivals, late departures) — 175 kW
- Normal depot — 200 kW
- Tight (late arrivals, early departures) — 250 kW
On a normal night, a depot needs 200 kW, not 250, and a plain first-come approach would need about 25% more. On a very tight turnaround, 250 kW really is the floor, and the tool says so instead of pretending otherwise. A sizing tool that always says "you can save money!" is not a sizing tool.
Where AWS fits
The engine is plain Python, living inside an AWS system my teammates built:
- Amazon EC2 runs the planner, the referee and the live dashboard
- Amazon Bedrock (Claude 3.5 Sonnet) reads each incident, finds the cause, calls the planner and writes the plain-English card the operator approves
- Amazon EventBridge carries every disruption: charger trips, cap drops, carbon spikes, late arrivals
- Amazon DynamoDB remembers the fleet, the chargers, the schedules and the incident log
- Amazon CloudWatch watches the transformer limit and raises an alarm
- AWS CDK sets all of it up as code
The key idea: Bedrock is the explainer. The maths belongs to the solver and the referee, and a human clicks Authorize.
The bug that was not in the code
Remember my spoiler? Here it is.
We finished the project, recorded the demo video, and went to submit. The clock said 10 minutes left. Then the demo video would not upload to YouTube. The progress bar crawled. I refreshed. I stared. I did the thing where you whisper "please" at a loading bar, as if it has feelings.
We pressed submit with two minutes to spare, in full panic, hearts racing, one very sweaty hurry.
Two minutes later, the deadline was extended by nine more hours.
I have never been so happy and so annoyed at the same time. Lesson learned: upload your video the night before, and never trust a progress bar. We still love how it ended.
What I would be honest about
- The depot telemetry in our demo is simulated (realistic duty cycles, but not from a real depot). The AWS services are live.
- The sizing curves on the dashboard come from our 60-night benchmark. The twenty-questions oracle exists in the code and can run on any fleet, but the dashboard shows the stored benchmark results.
- Green mode uses fixed default weights for cost, carbon and peak. A smarter version would learn them from real tariff and grid data.
What is next
Feed it real data (grid carbon APIs and an actual utility tariff), add a battery to the depot so the solver can store the cheap clean hours, and let multiple depots share one grid zone. The thing I like most about this idea is that it scales downward: the cheapest transformer upgrade is the one you never need to ask for.
Try it: http://ec2-100-56-128-36.compute-1.amazonaws.com
Code: https://github.com/sarthakv162/DECARB-EV
Credits and tools: Google OR-Tools (CP-SAT), Python, FastAPI, React, and the AWS services listed above. My teammates: Roopanshu Gupta (backend and Bedrock agent), Sarthak Verma (AWS infrastructure), Taksh Pal (dashboard and docs). AI tools: I used Claude to help draft and edit this post and to produce the animated demo video. (Add any AI coding tools you used for the code itself.)
Riddhima Bhargava · Team AWSome Builds · AWS Environmental Hacks 2026
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article