The problem
Depots and apartment car parks often cannot supply full power to every charger at once. Charging must be shared under a transformer or connection limit, while each vehicle still gets the energy it needs before it leaves. Central optimisation needs reliable communication; distributed methods let edge nodes decide locally but must converge and stay within limits.
Objectives
- Formulate fleet charging under a site power limit with arrival, departure and energy needs
- Implement a centralised scheduler and a distributed scheduler with edge nodes on CAN
- Run hardware-in-the-loop experiments with real kit nodes and simulated vehicles
- Quantify peak power, unmet energy, fairness, convergence time and CAN bus load
What you need
From the EV Embedded Development Kit
- STM32F103C8T6 microcontroller unit (main controller)
- Second STM32F103C8T6 as the Smart BMS unit
- CAN bus interface with screw terminal
- Serial UART interface
- RTC with CR2032 backup cell
- 1S battery with connector and T-sense input
- Battery charging unit with its own switch
- Charge/discharge control relay
- 16×2 LCD
Software
- STM32CubeIDE with HAL drivers
- Embedded C and FreeRTOS
- Python with python-can, pandas, NumPy and SciPy
- A linear programming solver available from Python
Extra parts
- USB-CAN adapter — Connects the PC simulator of the rest of the fleet and the site controller to the bus.
- Additional kits (optional, two or more) — More physical edge nodes on the same CAN bus make timing and communication results more realistic than one kit alone.
This project uses the kit's lithium cell. Respect polarity, never short the terminals, and don't leave the cell charging unattended.
Key concepts
- Site power limit
- The maximum total charging power the connection or transformer can supply. The sum of all vehicles' charging power must stay below it at all times.
- Centralised scheduling
- A site controller collects every vehicle's needs and solves one optimisation, then sends each vehicle its power. It needs all data and a reliable link.
- Distributed scheduling
- Each node solves a local problem using a shared signal, such as a price or Lagrange multiplier, updated iteratively until the total fits the limit. Examples are dual decomposition and ADMM.
- Jain fairness index
- A measure from 1/n to 1 of how evenly a resource is shared, applied here to the fraction of requested energy each vehicle receives.
Step-by-step guide
- 1
Problem formulation and scenarios
Formulate the problem: vehicles with arrival time, departure time, energy needed and maximum power share a site limit over discrete time slots. Write the centralised linear programme and a distributed version. Build scenarios from public EV charging session data, such as Caltech's ACN-Data, scaled to the testbed, plus synthetic stress cases. Define metrics before running experiments. Fix the slot length and horizon early, because they affect solve time and bus load.
Checkpoint: A formulation document with equations, scenarios and metric definitions.
- 2
Testbed architecture
Design the testbed: each kit is one physical edge node, the PC simulates the other vehicles as virtual nodes on the same CAN bus through the USB-CAN adapter, and a site controller runs either on the PC or on one kit. Assign CAN IDs per node and per message type, and compute expected bus load for the fleet size and message periods. The kit cell, charger and relay represent one vehicle's charging at kit scale.
Checkpoint: An architecture diagram and a CAN message table with an estimated bus load below a chosen ceiling.
- 3
Board and time synchronisation
Enable the DIP switches for CAN, UART, RTC, battery, charger, relay and LCD. Configure bxCAN at 500 kbit/s with filters for site and node messages, the RTC over I2C and a UART log. Implement time synchronisation: the site controller broadcasts a time frame and each node corrects its local timer offset, with the RTC as a holdover. Cell safety: check polarity, never short the cell and do not leave it charging unattended.
Checkpoint: Node clocks agree within a measured bound after synchronisation, logged over a one-hour run.
- 4
Edge-node firmware
Under FreeRTOS, create tasks for CAN communication, the local scheduler and charging control. The node reports its needs: energy, departure and maximum power. It applies the power setpoint by enabling charging for the fraction of each slot that matches the setpoint, with minimum relay on and off times. The BMS limits always override the setpoint. Measure the CPU load and stack use of each task, and check that CAN reception keeps up with the bus at the largest planned fleet size.
Checkpoint: A node receives a setpoint and its relay duty over each slot matches it within the slot resolution.
- 5
Centralised scheduler
Implement the centralised linear programme on the PC site controller. Every slot, it collects reports, solves, and broadcasts setpoints. Handle a node that does not report by giving it a safe default. Log solve time and the schedule. Measure how solve time grows with fleet size, and decide what the site does if a solve takes longer than one slot, for example reusing the previous schedule scaled to the limit. Record the objective value for later comparison.
Checkpoint: A scenario with all nodes completes with the site limit never exceeded and the schedule logged.
- 6
Distributed scheduler
Implement dual decomposition or ADMM: the site broadcasts a price, each node computes its preferred power locally in fixed point on the STM32 or in Python for virtual nodes, reports it, and the site updates the price. Stop after convergence or a maximum number of iterations, then apply a safe projection to guarantee the limit. Tune the step size or penalty parameter and report its effect on convergence.
Checkpoint: The distributed method converges on the test scenarios and its total stays within the limit after projection.
- 7
Communication faults
Inject faults: lost frames, delayed frames, a node dropping off the bus and a site controller restart. Measure how each method copes: limit violations, unmet energy and recovery time. Nodes must fall back to a safe minimum power if they stop hearing the site. Use the USB-CAN adapter to drop or delay frames in a controlled, repeatable way, and repeat each fault several times so that the results show a spread rather than a single lucky or unlucky run.
Checkpoint: A fault table shows no limit violation in any case, with measured recovery times.
- 8
Experiments at scale
Run scenarios with increasing fleet sizes, mostly virtual, with the physical nodes included. Record peak power, unmet energy, fairness index, convergence iterations, wall-clock time per slot and measured bus load. Repeat each scenario several times with different random seeds. Watch for bus load approaching saturation as the fleet grows and record where message timing starts to slip, since this sets a practical limit on fleet size for a single classic CAN bus.
Checkpoint: Results for at least three fleet sizes and both methods, with mean and spread.
- 9
Analysis
Compare the methods against an uncontrolled baseline in which every vehicle charges at full power on arrival, capped by the limit. Discuss scalability, communication cost and robustness. Check that physical-node results agree with virtual-node behaviour, which tests the embedded implementation. Quantify the price of decentralisation: how much worse the distributed solution is than the centralised one, against how much less information each node needs to share, and discuss when each approach suits a real depot.
Checkpoint: A comparison table and plots, with physical and virtual node results compared.
- 10
Write-up and artefacts
Write the thesis chapter or paper with the formulation, testbed, results and limitations, including the kit-scale power and the virtual majority of the fleet. Release scripts, scenario files and firmware structure for reproducibility. Describe the testbed in enough detail that another group could rebuild it, including CAN IDs, message periods, slot length and the exact scenarios. Separate results measured on physical nodes from those obtained with virtual nodes.
Checkpoint: A draft with reproducible figures and a clear limitations section.
Testing & validation
- Site power limit never exceeded in any scenario or injected fault
- Unmet energy and fairness compared across uncontrolled, centralised and distributed methods
- Convergence iterations and time per slot for the distributed method
- Measured CAN bus load against the design estimate
- Time synchronisation error between nodes
Expected results
A hardware-in-the-loop fleet charging testbed with kit edge nodes and simulated vehicles, centralised and distributed schedulers, and a quantified comparison of performance, fairness, robustness and communication cost.
Research angle for your PhD
Research questions: how do distributed schedulers implemented on low-cost edge controllers compare with centralised optimisation once communication delay, loss and limited compute are included? Metrics: peak power, unmet energy, Jain fairness, iterations to convergence, time per slot, bus load and recovery from faults. Baselines: uncontrolled charging and centralised LP. Data: public session data such as ACN-Data, scaled. A publishable contribution is an open hardware-in-the-loop methodology with measured communication effects, rather than simulation alone.
Take it further
- Add uncertainty in departure times and use stochastic or robust scheduling
- Include on-site solar generation as a time-varying limit
- Add V2G capability to some vehicles
- Bridge to a cloud aggregator through an ESP32 gateway add-on
Viva and review questions
Why include physical nodes if most of the fleet is simulated?
The physical nodes test the embedded implementation, timing, fixed-point maths and CAN behaviour that pure simulation would hide.
How do you guarantee the limit with a distributed method that may not converge?
After a fixed number of iterations the site applies a projection that scales setpoints to fit the limit, and nodes default to safe minimum power if they lose contact.
How do you apply a power setpoint with an on/off charger?
Each node enables charging for a fraction of each slot proportional to the setpoint, with minimum relay on and off times to protect the relay.