← Lesson diary · Process Identification and Control

PEV Aggregator Lab

Process Identification and Control · Lesson 14

PEV Aggregator Lab

An aggregator operates the chargers of a fleet of electric vehicles. It has sold the grid a power profile it promises the fleet will follow, and at the same time every driver has asked for a charge by a given hour. The two goals pull against each other, and the controller has to choose. This is the aggregator problem of the lesson, solved in your browser.

The fleet and the request

 

Fleet

What the grid asks for

The controller

Power of the whole fleetkW
asked by the grid with the aggregator's MPC everyone charges on arrival
Each vehicleplugged in, and charging
plugged in charging giving power back left below the requested charge
Charge at departure against what the driver asked% of the battery

The day, in numbers

StrategyMean deviationWorst deviationEnergy deliveredDrivers left shortMissing energyPeak power

 

What to notice

  • Flexibility is parked time, not power. A car that stays eight hours to take three hours of charge can be moved anywhere inside its window; one that arrives nearly empty and leaves in two hours cannot be moved at all. Shorten the stays, or raise what the drivers ask for, and the fleet stops being able to follow the grid even though the chargers are the same.
  • Charging on arrival is the worst of both worlds. The dotted line is what happens without a controller: a wall of power in the morning and nothing afterwards. It follows no reference, and it does not serve the drivers any better — they get their charge either way, just earlier than anyone needed.
  • The priority slider is the weight of the lesson. All the way to the grid, the controller sacrifices the drivers' requests to follow the profile; all the way to the drivers, it serves every request and follows the profile only with what is left over. Sweeping it from one end to the other traces the Pareto frontier of the two goals, the picture of the previous lesson: on this fleet, going from "the drivers" to "mostly the grid" buys about one kilowatt of tracking for some thirty kilowatt-hours the drivers do not get.
  • The request can be impossible, and the problem must survive it. Ask for more power than the fleet can absorb, or for charges that do not fit in the time available, and nothing breaks: the relaxation variables take the violation and the solution tells you how much was impossible. That is why the deadlines are written with the slack εp and not as hard constraints — a hard version would simply report infeasible and leave the controller with nothing to apply.
  • V2G buys the ability to go down. With discharging allowed, the fleet can follow a reference that asks it to stop, or even to give power back, at the price of energy that has to be bought again later.

The problem being solved

One optimization over the day, with the arrivals, departures and requests of every vehicle known. In closed loop it is re-solved at every step on the vehicles connected at that moment, which is the set PEVi|k of the lesson.

min   d1 Σi (Pi|k − Prefi|k)2  +  d3 Σp εp

Pi|k = Σp (Pchi|k,p − Pdisi|k,p)
xi+1|k,p = xi|k,p + ηch T Pchi|k,p − (1/ηdis) T Pdisi|k,p
xFp|k,p ≥ xrefp − εp    εp ≥ 0    0 ≤ xi|k,p ≤ xmaxp

The deadline of each driver is the relaxed constraint of the lesson: the slack εp is free to be positive, and it is paid for in the cost with the weight d3, which is what the priority slider moves. A small d3 lets the controller disappoint a driver to follow the grid better; a large one makes it disappoint a driver only when the request cannot be met at all.

Two notes on how this page differs from the blackboard. The square of the deviation is replaced by the largest of a family of tangent lines to it, which keeps the problem linear and is exact to within a fraction of a percent here; switching the penalty to the plain absolute value, with the checkbox, changes the shape of the solution, because the square spreads the error over many hours while the absolute value concentrates it in few. And the minimum charging power of a real charger — the semi-continuous variable of the lesson — is left out: it would turn this linear program into a mixed-integer one, as in the Building Energy Lab.

The solver is the same simplex written for the building lab, checked against the Cbc solver on random instances of this model.