Smart charging is here. V2G is real. You can model both today. This post shows how. We build a full project in MATLAB. We validate with power flow. We publish a video and code for you.
I created a YouTube walkthrough. The project is live. The full code is on Gumroad.
Why EV fleet charging and V2G planning matters
Fleets change the grid. Loads become flexible. Cars can act like resources. This needs planning. It needs a model. It also needs a fast solver.
Costs are volatile. Feeders have limits. Voltage must stay within bounds. EV owners want charged batteries. Planners need reliable tools. EV fleet charging and V2G planning gives that.
Project overview: EV fleet charging and V2G planning
This project schedules an EV fleet on a radial feeder. It runs on the IEEE‑33 Bus network. It uses linear programming. It enforces voltage limits with LinDistFlow. It validates results with a BFS load flow.
The model buys low and sells high. It uses a simple TOU tariff. It respects SoC targets by departure. It limits charge and discharge power. It handles availability windows.
You can run it in minutes. You can tune it in seconds. You can learn a lot.
Network model: IEEE‑33 Bus radial feeder
The feeder is standard. It is the Baran–Wu 33‑bus case. Bus 1 is the slack. The base is 12.66 kV and 100 MVA. Lines use ohmic R and X. Loads are static P and Q.
We convert to per‑unit. We keep the topology radial. That keeps the math simple. It also makes BFS fast.
Voltage model: BIBC/BCBV and LinDistFlow
We build BIBC and BCBV matrices. They map currents to voltages. They use the radial paths. We get sensitivities S_P and S_Q. These link P and Q to voltage drops.
We use LinDistFlow. It is a linear model. It is good for planning. It keeps the LP convex. It makes the solver fast.
We add soft voltage slacks. This avoids infeasibility. Slacks are penalized. They are capped. You can tune the penalty.
Optimization approach: linprog with soft limits
The core is an LP. We use linprog. No genetic algorithms. No heuristics. The objective is energy cost. Charging adds cost. Discharging earns revenue.
We add SoC dynamics. We add power limits. We add availability masks. We add voltage constraints. We keep all constraints linear.
We solve 24 time steps. We support any horizon. We use 1‑hour steps by default.
Watch the video and get the code
- Watch the YouTube walkthrough. See the setup. See the results. See the plots. [Add your link]
- Get the MATLAB code on Gumroad. Run it now. Modify it later. [Link]
Please like the video. It helps others find it. Share feedback. I read every comment.
How to run EV fleet charging and V2G planning
Setup is simple.
- Download all .m files.
- Open EV_V2G_IEEE33_main.m.
- Press Run.
- Watch the command window.
- Review the plots.
Requirements are modest. You need MATLAB R2020a or newer. You need the Optimization Toolbox. You need about 8 GB RAM.
Default settings are safe. The RNG is fixed. Results are reproducible.
You can change inputs. You can set the number of EVs. You can edit the price vector. You can change voltage limits. You can swap the feeder.
Key features at a glance
- Linear program with linprog
- IEEE‑33 Bus feeder
- BIBC/BCBV LinDistFlow
- BFS load flow validation
- TOU pricing
- Soft voltage slacks
- SoC targets at departure
- EV availability windows
- 7.2 kW charge and V2G per EV
- Clear plots and tables
Files explained
| File | Purpose |
|---|---|
| EV_V2G_IEEE33_main.m | Main script. Builds inputs. Calls the LP. Runs BFS validation. Prints tables. Plots results. |
| build_ieee33_data.m | Feeder data. Lines in ohms. P/Q loads per bus. Base values. |
| make_BIBC_BCBV.m | Path matrices. BIBC and BCBV for a radial network. Per‑unit branch impedances. |
| bfs_loadflow.m | Backward/Forward Sweep load flow. Voltages and feeder losses. |
| schedule_ev_lp.m | Linear program builder. Decision variables. Constraints. Soft voltage slack handling. |
The structure is modular. You can extend any part. You can reuse the solver.
EV and SoC modeling
EVs are placed at selected buses. Each EV has a location. Each EV has a capacity. Each EV has a start SoC. Each EV has a target SoC. Targets are due by the last available hour.
Charge power is capped. Discharge power is capped. Both are 7.2 kW by default. Efficiencies are 0.92 for charge and discharge. That captures round‑trip losses.
Availability matters. Home cars plug in at night. Work cars plug in during the day. You can edit these windows. You can import real data.
The SoC model is simple. It is a cumulative sum. It is linear. It is robust and fast.
Voltage constraints and slacks
Voltage must stay within limits. We use 0.95 to 1.05 pu. We enforce this in the LP. We use S_P and S_Q sensitivities. We map EV net power to each bus.
Soft slacks keep the problem feasible. Slacks are non‑negative. They are limited to a max. They add cost in the objective. Large slacks are discouraged.
You can tune the slack penalty. Use lambda_v to set weight. Use vslack_max to cap it. You can also turn slacks off. Use with care.
Results and insights for EV fleet charging and V2G planning
What should you expect? First, you should see cost savings. Charging shifts to off‑peak. V2G may occur at peak hours. That depends on availability.
Second, voltages should stay within limits. Small violations may occur if slacks are used. The penalty will keep them small.
Third, losses change. Charging at distant buses can raise losses. V2G near peaks can help. The BFS load flow quantifies that.
You will see tables in the console. You will see total energy bought. You will see energy sold via V2G. You will see net cost. You will see EV SoC compliance. You will see per‑bus energy.
You will also see plots. The first plot shows price and net EV power. The second shows the worst‑hour voltage profile. The third tracks the minimum bus voltage over time. The fourth stacks charge and discharge energy by bus.
Troubleshooting
No feasible solution? Enable soft slacks. They are on by default. Increase vslack_max a little. Reduce lambda_v if needed.
Still stuck? Reduce the number of EVs. Relax the SoC target to 70%. Widen the voltage range slightly. Check that Optimization Toolbox is installed.
We also use a fixed RNG. Different RNG seeds change placements. Try rng(42) to replicate my run.
Performance and scaling
The LP is fast. It scales linearly with time steps. It also scales with EV count. Hundreds of EVs are fine on a laptop. Thousands may need care.
LinDistFlow is efficient. BFS is also fast. Both suit planning runs. You can run many scenarios in a loop.
Keep data sparse. The code does this. It helps linprog. It reduces memory use.
Who should use this project?
Researchers can test ideas. Utilities can study feeders. Aggregators can plan schedules. Educators can teach network‑aware charging.
If you run a pilot, this helps. If you write a paper, this helps. If you build a product, this helps.
Assumptions and limits
This is a planning model. It is not a full market model. It uses TOU prices. It does not model real‑time prices.
EVs use unity power factor. No reactive power is modeled. Thermal limits are not enforced. Only voltages are bound.
LinDistFlow is a linear model. It is an approximation. BFS helps validate results. Always check with a full AC power flow if needed.
Next steps: extend EV fleet charging and V2G planning
You can add feeder limits. Include line ampacity. Add transformer limits. Keep it linear with care.
You can add battery wear. Include cycle costs. Add demand charges. Include export caps.
You can add uncertainty. Use scenarios. Run a robust LP. Try chance constraints.
You can swap the network. Use IEEE‑69. Use a real feeder. Update build_ieee33_data.m. The rest will work.
You can add reactive power. Add Q limits. Extend the voltage model. Re‑compute sensitivities.
Call to action
- Watch the YouTube video now. See the full build. See the results. [Add your link]
- Get the complete MATLAB project on Gumroad. Run it today. Adapt it for your use. [Add your link]
- Share feedback. Ask questions. Suggest features. I am happy to help.
Summary
EV fleet charging and V2G planning is practical. It is also powerful. This project proves it. It uses a clean LP. It respects network limits. It validates with BFS.
The code is modular. The data is clear. The results are visual. The workflow is fast.
Use it for research. Use it for teaching. Use it for pilots. And improve it as you go.