Solving EV charger anxiety

Many EV adventures are accessible using the charging network in Victoria, but faulty chargers still have the potential to induce charger anxiety on road trips.

Planning apps–EV drivers’ constant companions–may not fully solve this when the reported status of chargers is unreliable and faults are prevalent. As a driver, I want resilient plans that already include plan B if chargers are found faulty on arrival. It’s a fun modelling exercise at least, even if you’re not all that anxious.

In this post we’ll see what more resilient planning could look like, and how to accommodate faulty chargers without adding too much charging time.

Visualising resilience

Let’s start with visualisation. Being able to see the range at each point helps to understand options if the trip has to change. On a real road network, this could be done with isochrones.

To keep it simple, I’ve used circles to show the range or area the vehicle can access at each point, and I’ve represented the route as a straight line.

Below the vehicle departs with the orange range circle. On the left, it arrives at the destination with the darker (teal) range remaining circle, showing it can drive further in any direction. On the right, the destination is unreachable without charging along the route.

Now the vehicle charges at the half-way point. Darker circles are arrival range at each point, including the skipped charger on the right, and orange circles are range after charging. Bigger circles and more overlap mean more resilient trips.

I’ve introduced these visualisations first because I found them helpful for understanding and validating the optimal plans below.

Preparing a trip

I’m assuming we’ve started with a destination and crunched the real-world data on routes and charger locations down to our simple straight line with chargers spaced along it, which will work in many cases, so that we can skip to the good part for this post.

In this test case, the result is four chargers of increasing power spaced unevenly along a route that requires a minimum 100% total charge to complete. The numbers, as far as they matter: EV range 5, route length 10, chargers at 3, 4, 7, 8 with relative speeds 1, 2, 5, 5.

The charger stops we make and how much we charge will determine the charging time for the trip and state of charge (SOC), and hence range, at each point. Two example plans for this test trip are shown below, with the same total charge to reach the destination, but different in other respects.

Optimising plans

The example trip plans above are just illustrative; they aren’t optimised for any particular outcome. However, starting from the outcomes we want we can derive the details of the plan, using an approach similar to that described in planning EV charging networks.

Remember, we’re aiming for a plan that is resilient to finding chargers faulty on arrival, but still efficient in time. However, we’ll need to make a few stops on the way.

The model

I’m taking an operations research approach, using a CP-SAT constraint programming model to solve for the plan variables that satisfy specified constraints and best achieve objectives.

I choose the following variables:

• fills or SOC to add at each charger (from 0 to max 100, this is the plan output that we’ll act on) which are supported by
• stops boolean indicating a stop at each charger, and
• arrivals for the SOC on arrival at each charger

These variables are subject to base constraints, which must be true for any trip:

• fill > 0 means a stop and fill == 0 means no stop
• The arrival SOC at each charger must match the previous departure SOC, minus the SOC consumed over the intervening distance
• The arrival SOC plus the fill SOC at each charger is limited to 100%
• We must be able to reach the destination with SOC > 0%

The current objective is to minimize total charging time, which is a function of:

• The energy to be delivered with each charge, the delivery time being determined by the power of the charger, plus
• A fixed time for each stop

The resilience

So far, we’ve captured trip charging time as an objective that can be optimised. We’re also able to determine the state of charge (SOC) at each point through constraints. SOC is related to resilience, though there are many ways to express the relationship.

To get specific about the resilience outcomes we are seeking, we can now add further resilience constraints:

1. Must arrive at destination with greater SOC than a lower limit
2. Must arrive at each charger with greater SOC than a lower limit
3. Must be able to reach the next + 1 charger at each point
4. Must be able to return to previous charger at each point

1 & 2 are supported in existing apps, but they leave me guessing or performing mental arithmetic on whether I can actually reach another charger if one I’ve chosen is faulty. I’m not aware of any that support 3 & 4, the rules of thumb I followed in EV adventuring with resilience that allow us accommodate finding any one charger faulty on arrival. Constraints 3 & 4 may give plans with a better balance of time and resilience than the constraints 1 & 2.

While we’re here, I’d love any more ideas for resilience requirements!

The solutions

Now the solver will give us optimal plans under each of the further resilience constraints. We’ll see how they vary in sometimes subtle but significant ways.

Fast plan and SOC constraints

The fastest plan has no further constraints. We charge just enough to reach the next point towards the destination, the objective preferencing faster chargers and fewer stops. Adding a destination SOC requirement (#1) we follow a similar plan but charge more (to total 120%) at the fast stop, taking slightly longer.

With a further charger arrival SOC requirement (#2), the charges break down more evenly, which incurs additional time penalty for the slower charge. Note that the arrival SOC requirement doesn’t always allow us to make it to the next + 1 charger–the range on arrival/departure at the first skipped charger does not reach to the third charger.

Next + 1 and previous charger constraints

Implementing the next + 1 charger requirement (#3) increases resilience further (above and below) at the expense of time by splitting the first 60% charge over two chargers. The alternative requirement to be able to return to the previous charger (#4), is much more time efficient in this scenario due to shifting charge to a faster charger (until we hit a faulty charger and must retrace our steps, that is!)

We can see that implementing either the next + 1 or previous charger requirements make our trip resilient to a fault in any one charger, while this degree of resilience isn’t guaranteed by the SOC constraints. For some SOC, they might achieve this, but we might need more work to find the SOC, and it might come at an unnecessary time penalty.

So now we have a new method to trade off time and resilience to faulty chargers to support road trip planning. Maybe small adjustments to plans, but providing much greater confidence.

The code

You can also play along at home with the source code.

Recovery

How do these plans fare if we do actually find a faulty charger? With next + 1 plans, the trip can be completed in all cases of a single faulty charger, in some cases with the original robust plan, otherwise with a new plan based on starting from the faulty charger with its arrival SOC, as below.

Next + 1

There are many assumptions and simplifications in this prototype. With most chargers requiring deviation from the shortest route in the real world, while minor, we probably want charger selection to impact route, energy consumption and travel time too. We can review objectives as the amenity of chargers may compensate for charging time. And we can incorporate even imperfect charger status data.

We shouldn’t get too hung up on any one plan though, remembering from a resilience perspective that plans are worthless, but planning is everything. And one day, we hope network density and reliability will make all this planning obsolete anyway!

The visualisations can get a bit cluttered and do take some work to build intuition (they are a little like light cones). I used the linear vertical layout because I imagine it could work on mobile screens. Alternatives might use another axis to show range (like the earlier plan vs actual charts), or vary the colour of the route line, etc. I’d love to know what you think.

The biggest gap right now, however, is probably whether this is useful on a real road trip, so the optimal next step is to use real-world data for some real-world resilient planning.