Vehicle-to-Grid / Vehicle-to-Load Control Logic and Scheduling

The problem

An EV battery can power appliances (V2L) or support the grid (V2G), but every kilowatt-hour exported uses battery life and may leave the owner without enough range. The control logic must accept grid requests, respect owner preferences and battery limits, and schedule discharge sensibly. The policy matters as much as the power electronics.

Objectives

• Define V2L and V2G operating modes, owner settings and a grid request message set over CAN
• Implement a rule-based controller with SOC reserve, power limits, temperature limits and an RTC schedule
• Implement an optimisation-based scheduler on the PC and compare it with the rule-based controller
• Quantify energy exported, reserve violations, revenue proxy and a degradation proxy

What you need

This project uses the kit's lithium cell. Respect polarity, never short the terminals, and don't leave the cell charging unattended.

Key concepts

V2L and V2G

V2L powers local loads from the vehicle battery; V2G exports power to the grid on request. On the kit both are emulated by discharging into the resistive loads.

SOC reserve

A minimum state of charge set by the owner, so that the vehicle always keeps enough energy for the next trip regardless of grid requests.

Discrete power steps

The three loads give a few fixed discharge levels. The controller meets a requested power by choosing the nearest combination, much like a real system with limited setpoints.

Degradation proxy

A simple measure, such as equivalent full cycles or throughput weighted by depth of discharge, used to compare policies for battery wear without claiming a lifetime prediction.

Step-by-step guide

1. 1

   Modes, actors and messages

   Define the actors: owner, vehicle controller, BMS and grid operator. Define modes: idle, charging, V2L, V2G and protected. Design CAN messages: grid request (power, duration, price signal), vehicle availability (SOC, reserve, available energy, power limit) and vehicle status. Owner settings, entered on the keypad, include reserve SOC, departure time and whether V2G is allowed. Cell safety: check polarity, never short the cell and never leave charging unattended.

   Checkpoint: A message table and mode diagram reviewed by the guide.

2. 2

   Board and bus setup

   Enable the DIP switches for CAN, RTC, keypad, LCD, battery, loads, relay and charger. Set both controllers to 72 MHz. On the main controller configure bxCAN with filters for the grid IDs, I2C for the RTC, keypad GPIOs and the LCD. On the BMS unit configure the ADC for cell voltage and temperature and GPIOs for loads and relay. Connect the USB-CAN adapter with correct termination.

   Checkpoint: Grid request frames from Python reach the controller and its availability frames reach the PC.

3. 3

   Power and energy estimation

   Measure each load resistance with the cell disconnected. Compute discharge power as V²/R for the active combination and integrate exported energy. Build a voltage-to-SOC table for the cell from a slow discharge. Document that current is estimated from resistance and state its error. Recheck the table after a few cycles, because contact resistance can change, and use the table values in both the firmware and the Python optimiser so they use the same power figures.

   Checkpoint: A table of power for each load combination at full and half charge.

4. 4

   Rule-based controller

   Implement the rules: accept a grid request only if V2G is allowed, temperature is within limits and SOC is above reserve plus a margin. Choose the load combination closest to the requested power without exceeding the vehicle limit. Stop exporting when SOC reaches reserve or departure is near. In V2L, serve the requested local load while protecting the same reserve.

   Checkpoint: Scripted grid requests give the expected accept, reject and stop decisions in each case.

5. 5

   RTC scheduling

   Use the RTC to plan the session: export only in grid-requested windows, ensure recharge to the departure SOC before departure using the charger's known rate, and refuse requests that would make this impossible. Store the schedule and settings in non-volatile memory with a checksum. Show the reason for every rejection on the LCD and in a CAN response, so the grid emulator can log why a request failed and the owner can understand the decision.

   Checkpoint: With departure set close, the controller rejects a long export request and explains why on the LCD.

6. 6

   Grid operator emulator

   Write a Python grid emulator that sends requests from a day-long scenario: price signals, demand-response events and random requests. Compress time so a day runs in an hour, scaling energy accordingly, and state the compression in the report. Log all frames and vehicle responses. Make scenarios reproducible by fixing random seeds, and keep each scenario as a file so the rule-based and optimised runs see exactly the same requests.

   Checkpoint: A compressed day runs to completion with a full log.

7. 7

   Optimisation-based scheduler

   In Python, formulate a linear programme over the day: choose export power in each interval to maximise a price-weighted revenue proxy minus a degradation cost, subject to SOC limits, reserve, departure SOC and power steps. Send the resulting schedule to the vehicle as setpoints. The embedded controller still enforces all limits. Re-solve when conditions change, for example a new request or an SOC measurement that differs from the plan.

   Checkpoint: The optimiser's plan is feasible and the embedded controller follows it without violating any limit.

8. 8

   Comparison experiments

   Run the same scenarios with the rule-based controller and the optimised schedule. Compare energy exported, revenue proxy, reserve violations, departure SOC achieved, the degradation proxy and the number of relay operations. Repeat with different reserve settings and price shapes. Present results as tables and as daily plots of SOC and export power, so the behaviour behind each number is visible, and test whether differences are larger than run-to-run variation.

   Checkpoint: A comparison table across at least three scenarios and two reserve settings.

9. 9

   Fault and edge cases

   Test a lost grid connection, a request above the vehicle limit, an RTC reset, a temperature limit during export and an owner override from the keypad. Each must lead to a safe, explained state. For each case, record how long the controller took to reach a safe state and whether it recovered automatically when the fault cleared, or needed the owner to intervene from the keypad.

   Checkpoint: An edge-case table with the observed behaviour for every case.

10. 10

    Report

    Document the design, the optimisation formulation, the results and the limitations: emulated power flow, stepped loads, compressed time and no real grid interface. Discuss what a real bidirectional charger and grid code would add. Include the message table and state diagrams, and list the assumptions behind the degradation proxy and the revenue proxy so readers can judge how far the comparison would carry over to a real vehicle.

    Checkpoint: A complete report with tables, plots and limitations.

Testing & validation

• Reserve SOC never violated across all scenarios
• Departure SOC achieved or the request rejected in advance
• Rule-based and optimised policies compared on energy, revenue proxy and degradation proxy
• Safe behaviour under lost communication, over-limit requests and RTC reset

Expected results

A V2L/V2G controller on the kit that accepts grid requests over CAN, protects the owner's reserve and departure needs, and a quantified comparison of rule-based and optimisation-based scheduling.

Take it further

• Add a second kit as another vehicle and coordinate both
• Use a stochastic departure-time model
• Replace the linear programme with model-predictive control updated every interval
• Add a phone interface for owner settings through an HC-05 Bluetooth add-on

Viva and review questions