Can a Digital Twin Actually Help Design an EV Battery-Swapping Network?

During a 30-hour hackathon, our team was asked to build something that sounded straightforward:

Build a digital twin of an EV battery-swapping network and use it to test infrastructure decisions before deploying them in the real world.

1st Runner-Up at HackSmart 2026 Hackathon

The obvious approach was to make the virtual city as realistic as possible.

That turned out to be the wrong place to start.

Act I: The Naive Trajectory

1. The Decision We Were Actually Trying to Make

Battery swapping looks simple from the driver's perspective.

A driver arrives with a depleted battery, hands it over, receives a charged one, and leaves.

Behind that interaction is a small inventory system.

Every swap removes a charged battery from the station and introduces a depleted one. That depleted battery occupies a charger until it reaches the required state of charge. Meanwhile, other drivers continue arriving.

If enough drivers arrive before enough batteries become available, a queue forms.

That creates the operational problem.

An operator might consider:

• adding a swapping station
• increasing charger and battery capacity
• moving batteries between stations
• changing replenishment policies
• responding to changes in demand

But these decisions have different costs.

Adding infrastructure requires capital. Rebalancing inventory requires logistics. Doing nothing can mean longer waits and lost swaps.

The question we were given was therefore not simply:

It was:

The distinction became important very quickly.

2. Our First Instinct Was to Make Demand Perfect

Our first instinct was to start with demand.

If the simulation was going to tell us whether a station needed more batteries, surely the demand going into it had to be realistic.

So we started thinking about everything that could influence where and when people swap batteries:

• morning and evening activity
• commercial areas
• residential areas
• restaurants and other points of interest
• roads and connectivity
• weather
• temporal patterns
• spatial differences between stations

This seemed reasonable.

The more accurately we could reproduce the city, the more accurate the digital twin should become.

That assumption led us toward an increasingly complicated demand model.

And then we asked a more useful question:

That question exposed the problem.

3. We Were Solving the Wrong Prediction Problem

We didn't actually need to know the exact location and arrival time of every future driver.

We needed to know whether a station would have enough usable batteries when drivers arrived.

That is a very different problem.

Consider two demand models.

The first predicts that 17 drivers will arrive at 10:00, followed by 21 at 11:00.

The second predicts 18 and 20.

If both models produce the same conclusion about whether the station runs out of charged batteries, the additional precision in the first model has very little operational value.

The important interaction was:

demand → charged battery inventory → charging → queue → wait time → lost swaps

That became the core of our model.

We stopped trying to reproduce the city perfectly and started trying to reproduce the mechanism that creates the bottleneck.

This was the first major change in our thinking.

Act II: Physics of a Battery Swap

4. What Does a Swap Station Actually Need to Know?

We reduced the system to a few interacting components.

At any point in time, a station has:

• batteries that are ready to be issued
• batteries currently being charged
• batteries that have been swapped out and are now depleted
• drivers arriving to swap
• chargers with finite capacity

A swap consumes one charged battery.

The incoming depleted battery enters the charging system.

It does not become useful again immediately.

That creates a feedback loop:

This is much closer to a queueing system than to a conventional forecasting problem.

And it gave us a useful abstraction:

5. Building the Minimum Useful World

We eventually structured the simulation into several layers.

Each layer answered a specific question.

5.1 Temporal demand

We used Gaussian Mixture Models to capture the shape of demand across the day, including morning and evening peaks. The model was concerned with the shape of demand, rather than pretending to know every future arrival.

5.2 Spatial redistribution

A city-level demand curve is not enough.

Two stations in the same city can have completely different demand because they serve different parts of the urban network.

We therefore divided the geographical space around existing swapping stations using Voronoi regions and redistributed demand using weighted Points of Interest.

The underlying idea was simple:

The HackSmart research notes specifically explored POI categories such as shopping centres, hospitals, restaurants, offices and residential areas as spatial demand signals.

This gave us a way to introduce geographic heterogeneity without attempting to model every driver's route.

5.3 Station state

Each station then became a stateful system.

We tracked:

• charger capacity
• battery inventory
• charged batteries
• batteries currently charging
• battery state of charge
• incoming demand

The charging model deliberately simplified the physical process. A full charge was represented as a fixed charging duration, while incoming batteries were assigned an SoC distribution centred around the depleted state. Batteries became eligible for swapping once they crossed the required charging threshold.

These weren't claims about the exact physical behaviour of every battery.

They were modelling assumptions.

That distinction matters.

6. The Assumptions Were Part of the Model

A simulation can look scientific simply because it contains equations.

That doesn't make it accurate.

Our simulation depended on assumptions about:

• charging duration
• initial battery SoC
• the SoC required before issuing a battery
• driver patience
• station inventory
• charger capacity
• demand during different conditions

For example, we treated batteries above the specified charging threshold as available for swapping and used a waiting threshold to classify demand that could not be served promptly.

The important thing wasn't that these assumptions were perfect.

It was that they were explicit.

Once an assumption is visible, an operator can challenge it.

If we hide it inside the simulation, the output can look much more authoritative than it deserves to be.

Act III: Counterfactuals and Optimization

7. The Interesting Part Was Not the Simulation

Once we had the basic simulation, we could run the question that actually mattered.

Suppose Station A is running out of charged batteries during the peak.

Should we:

• add more chargers?
• add more batteries?
• move batteries from another station?
• add a new station?

The answer depends on where the constraint actually exists.

If one station has excess charged inventory while a neighbouring station is repeatedly running out, buying more batteries for the whole network may be unnecessary.

The problem is not total inventory.

It is inventory in the wrong place at the wrong time.

This is where simulation became useful.

Instead of asking:

we could ask:

8. From Simulation to Optimization

Simulation tells us what happens.

It doesn't automatically tell us what to do.

So we added an optimization layer.

For rebalancing, the system could consider moving batteries between stations before the peak period and evaluate the resulting network state.

We used a Genetic Algorithm to search for useful rebalancing configurations rather than manually testing every possible combination.

The objective was tied to the operational KPIs we actually cared about, while accounting for the cost of moving inventory. The HackSmart design used a rebalancing cost per battery and focused the intervention on the peak period, where the charging bottleneck was most consequential.

The important architecture became:

The simulation and optimizer therefore formed a loop.

Propose → simulate → measure → modify → simulate again.

That is much closer to how we wanted the system to be used.

9. The KPIs Changed How We Thought About the Network

The final model did not try to produce a single "network score."

We tracked several operational consequences.

Average wait time

How long does a driver have to wait when a charged battery isn't immediately available?

Lost swaps

How much demand effectively goes unserved because the required battery does not become available within the defined patience window?

Charger utilization

How much of the charging capacity is actually occupied?

Idle inventory

How many charged batteries are sitting at a station without being used?

Operational cost

What does an intervention cost, particularly when comparing inventory rebalancing with additional infrastructure?

These metrics are related, but they don't always move in the same direction.

That is exactly why a simulation is useful.

Adding batteries might reduce wait time while increasing idle inventory.

Rebalancing might reduce waiting without increasing total inventory.

Adding chargers might increase processing capacity while creating a different capital trade-off.

There isn't necessarily one universally optimal intervention.

10. Then We Tried to Break the Model

We also introduced demand shifts.

For example, rainfall could change travel behaviour and therefore swapping demand. Rather than building a sophisticated weather forecasting system, the final model represented rainfall as a demand adjustment with a lag.

This was another useful lesson.

We didn't need to predict rainfall perfectly.

We needed to test:

That is a much more tractable question.

It also gave us a way to test whether a proposed intervention was robust or only worked under one carefully chosen demand curve.

Act IV: Domain Reality and Mental Models

11. The Hackathon Exposed the Difference Between "Interesting" and "Useful"

Our first version was built around the things that were technically interesting to us.

Demand modelling was interesting.

Geospatial modelling was interesting.

Weather effects were interesting.

But during the hackathon, we presented the prototype to domain experts from Battery Smart.

Their feedback changed our priorities.

They were less interested in whether we could construct an increasingly elaborate model of urban behaviour.

They were more interested in questions such as:

• Where are batteries becoming constrained?
• How long are drivers waiting?
• How many swaps are being lost?
• Which stations have excess inventory?
• What happens if inventory is rebalanced?
• How does that compare with adding infrastructure?

That distinction was important.

They weren't telling us that demand modelling was useless.

They were showing us that the useful output of the model was operational.

The model existed to support a decision.

Not the other way around.

12. We Reworked the Model

Between the preliminary round and the finals, we changed a substantial part of the analytics pipeline.

The centre of gravity moved from:

to:

That meant simplifying some things while making other parts more explicit.

We spent less effort trying to make synthetic demand indistinguishable from reality.

We spent more effort making the station dynamics interpretable.

We made the intervention layer explicit.

And we evaluated scenarios through operational KPIs rather than through the sophistication of the underlying model.

That was probably the most valuable iteration of the entire project.

13. But Was This Really a Digital Twin?

There is an uncomfortable question here.

We called the system a digital twin.

Strictly speaking, what we built was closer to a decision-oriented simulation sandbox than a continuously synchronized digital replica of the physical network.

It wasn't receiving a live stream of every station state and continuously mirroring reality.

It was using available information, assumptions and synthetic demand to construct a model of the network and run counterfactual experiments.

That distinction is important.

But it also changed our definition of success.

The question wasn't:

It was:

For our use case, that meant capturing the relationship between demand, inventory, charging capacity, geography and interventions.

If it could do that well enough to distinguish between plausible operational strategies, it was already useful.

14. What the Model Could Tell Us

The resulting system could answer questions that would otherwise require experimentation in the real network:

• What happens if a station is added?
• What happens if an existing station is removed?
• Where should inventory be rebalanced?
• How does a demand shift affect station-level bottlenecks?
• Does additional inventory actually solve the problem?
• Is the constraint charging capacity or battery availability?
• What happens to wait time and lost swaps after an intervention?
• What is the operational cost of making that intervention?

These are counterfactual questions.

And that is where the digital twin became useful.

We weren't trying to predict the future perfectly.

We were trying to make alternative futures cheap to test.

15. What It Could Not Tell Us

The model also had clear boundaries.

It could not establish that the assumptions about demand, charging behaviour or driver behaviour were universally correct.

It could not guarantee that an intervention would perform exactly as simulated.

And it could not replace operational data.

This is an important property of simulation that is easy to overlook:

If the assumptions change, the result can change.

That isn't a weakness unique to our model.

It is one of the fundamental reasons simulation needs to be treated as a decision-support tool rather than an oracle.

16. The Bigger Lesson

Our initial mental model was:

More realism → better digital twin → better decisions.

The project changed that to:

Better abstraction → better decision model → better experiments.

There is a subtle but important difference.

A model can become more realistic while becoming less useful.

Every additional variable introduces:

• another assumption
• another source of uncertainty
• another parameter to estimate
• another interaction to validate
• another way for the model to become difficult to interpret

The right question is therefore not:

It is:

For a battery-swapping network, that turned out to be less about predicting every driver's behaviour and more about understanding what happens when stochastic demand meets finite charging and inventory capacity.

17. Changed Belief

That distinction is what ultimately made the simulation useful.

The hardest part wasn't writing the simulation.

It was deciding what not to simulate.