Battery Swapping Station Sizing and Queue Simulation

The problem

Battery swapping is used for delivery fleets and three-wheelers in India because a swap takes minutes while a charge takes hours. The operator must decide how many spare batteries and chargers to buy: too few and riders queue, too many and capital sits idle. This is a queueing problem with time-varying demand, which discrete-event simulation answers well.

Objectives

• Model vehicle arrivals, swap service and battery recharging as a discrete-event system.
• Represent each battery as an entity with SOC that moves between vehicles, queue and chargers.
• Measure waiting time, queue length, charger utilisation and battery availability.
• Size batteries and chargers for a target service level.
• Test sensitivity to peak demand and charger power.

What you need

Key concepts

Discrete-event simulation

The model jumps from one event to the next, such as an arrival or a swap completing, instead of stepping through fixed time. It suits queues and service systems where nothing changes between events.

Entity

An object that moves through the model and carries attributes. Here vehicles and batteries are entities, and each battery carries its SOC and cycle count.

Little's law

Average number in a system equals arrival rate times average time in the system, L = λ·W. It is a quick check on any queueing simulation.

Service level

The share of arrivals served within a target wait, for example 95 per cent of riders swapped within 5 minutes. It turns a queueing result into a business requirement.

Step-by-step guide

1. 1

   Define the station and demand

   Take an example station for electric two-wheelers: two swap bays, a rack of chargers and a pool of 1.5 kWh batteries. Swap service takes 2–3 minutes. Build an hourly arrival-rate profile with morning and evening peaks, for example 10 riders per hour off-peak and 40 at peak. Riders arrive with a battery at 10–30 per cent SOC. Write all values in a parameter script.

   Checkpoint: A demand plot over 24 hours and a parameter table with service time, battery size and charger power.

2. 2

   Model arrivals

   In SimEvents, use an Entity Generator with time-based generation whose intergeneration time is drawn from an exponential distribution with a mean set by the hour-of-day rate. Implement the time-varying rate with a MATLAB action in the generator or with thinning. Give each vehicle entity attributes for arrival time and incoming battery SOC. Check the generator by counting arrivals per hour over many simulated days and comparing the mean with the demand profile. Store the arrival time on each entity so waiting time can be computed when the swap begins.

   Checkpoint: A count of arrivals per hour over a simulated day that follows the demand profile within normal random variation.

3. 3

   Model the swap bays

   Send vehicles to an Entity Queue (FIFO) and then an Entity Server with capacity two, representing the bays. The server must only start when a charged battery is available, so gate it with an Entity Gate controlled by the count of full batteries, or acquire a battery from a Resource Pool. Service time is uniform between 2 and 3 minutes.

   Checkpoint: With an unlimited supply of charged batteries, simulated mean wait matches the M/G/2 approximation or Little's law within a few per cent.

4. 4

   Model batteries and charging

   Represent batteries as entities in their own loop. A depleted battery from a swap joins a charger queue, then an Entity Server whose capacity equals the number of chargers and whose service time is energy needed divided by charger power, with a CV tail factor. When charged it joins the full-battery store. Track a cycle-count attribute. Seed the model with the chosen pool size, all batteries full at the start of the day. Charging time can include a fixed overhead for handling, so that the charger is not freed the instant a battery is full.

   Checkpoint: Every battery entity is accounted for at all times: in a vehicle, in the charger queue, charging or in the full store, and the total stays constant.

5. 5

   Collect statistics

   Log rider waiting time, queue length, number of full batteries, charger utilisation and bay utilisation. Use the statistics ports of the queue and server blocks, and log to the Simulation Data Inspector. Run a warm-up of one day and discard it, then simulate several days. Use Little's law as a consistency check on the logged results. Also log the number of riders who find no charged battery on arrival, since that event, not only the waiting time, is what an operator worries about most.

   Checkpoint: Little's law holds within a few per cent for the swap queue across the measured period.

6. 6

   Run replications

   Discrete-event results vary with the random seed, so run at least 20 replications per configuration with different seeds, using a script with sim() and Simulink.SimulationInput. Compute the mean and 95 per cent confidence interval for mean wait, 95th-percentile wait and service level. Keep the seeds recorded so results can be reproduced. Use the same set of seeds for every configuration (common random numbers), which reduces the variance of the difference between configurations and makes comparisons sharper for the same number of runs.

   Checkpoint: Confidence intervals narrow enough to separate configurations, for example half-width under 10 per cent of the mean.

7. 7

   Size the station

   Sweep the number of batteries (for example 20 to 60 in steps of 5) and chargers (10 to 30). For each pair, compute the service level. Plot a contour of service level over the grid and mark the region that meets the target. Add a simple capital cost per battery and per charger, as example placeholder values supplied by the user, to find the cheapest pair that meets the target.

   Checkpoint: A contour plot showing that adding batteries can substitute for chargers up to a point, and a chosen configuration that meets the service level.

8. 8

   Sensitivity analysis

   Rerun the chosen configuration with peak demand 20 per cent higher, with faster chargers, and with longer swap time. Report how each change shifts the service level and which parameter the station is most sensitive to. Note any configurations that become unstable, where the queue grows without bound at peak. Change one parameter at a time from the chosen configuration, keep the seeds fixed, and present the change in service level as a percentage so parameters with different units can be compared side by side.

   Checkpoint: A tornado-style chart ranking the sensitivity of service level to each parameter.

9. 9

   Report

   Document the event model, its validation against queueing theory, the replication method, the sizing result and the sensitivity study. State the simplifications: a single station, no battery degradation, Poisson arrivals and fixed charger power. Explain how real arrival data from a fleet operator would replace the assumed profile. Include a short user note explaining how an operator could rerun the sizing with their own demand profile by editing only the parameter script.

   Checkpoint: A report with the model diagram, validation table, sizing contour and sensitivity chart.

Testing & validation

• Unlimited-battery case matches queueing theory within a few per cent.
• Battery entity count conserved throughout every run.
• Little's law satisfied for the swap queue.
• Confidence intervals reported for all key metrics.

Expected results

A SimEvents model of a swapping station that gives waiting time and service level for any battery and charger count, with a recommended sizing for the example demand and a ranked sensitivity study.

Take it further

• Add battery degradation so old batteries are retired after a set cycle count.
• Add smart charging that charges more batteries when grid tariff is low.
• Model a network of stations with riders choosing the nearest.
• Add battery health screening at swap time.

Viva and review questions

Learn it at DIYguru

These DIYguru courses and programmes teach what this project needs.