Charging an electrical vehicle (EV) takes more time than fuelling a traditional car with an internal combustion engine (ICE). The exact time it takes depends on various factors:

1. Battery size (e.g. 74kWh) and the difference between the current (e.g. 10%) and the desired charge (e.g. 90%¹)
2. Type (AC² or DC) and maximum output (e.g. 22kWh for AC or 300kWh for DC) of the charger
3. Maximum charge accepted by the car (e.g. 11kWh in AC and 250kWh in DC)

AC chargers are cheaper to build and require less infrastructure, which makes them more prevalent on the city level. In a fairly standard scenario, a Tesla Model 3 EV might charge at such a charger from 10% to 90%. While this exemplary charger can deliver up to 22kWh, the Tesla can only handle up to 11kWh. It will therefore require over 5 hours of charging time to arrive at 90%.

If the driver plans with the option to charge their car at a specific point in time (or rather: leave with a certain charge at a certain time), this duration can be a problem.

In this blog post, I am attempting to summarize the underlying issues. I also discuss a potential solution to the problem: a new “planned charging” API.

Availability issues of city level chargers

There are over 40.000 AC chargers in Germany with over 1.500 of them in Berlin alone. While this seems like abundance (less than 10.000 of the 1.2 million cars registered in Berlin in 2021 are EVs) certain types of issues limit the real availability of these chargers.

Overdrawing and overextending

The first issue is overdrawing the legal staying time (applicable to some chargers) which is defined as a maximum time in a specific time window. The Tesla from above requires over five hours of charging time but might legally be obliged to leave after four.

The second issue is overdrawing the required staying time for a desired charge. This would imply our Tesla stays parked after charging to its desired charge of 90%.

Both issues seem to affect drivers of PHEVs³ and car sharing vehicles more than EV drivers. PHEVs battery size is much smaller than those of EVs, requiring compliant drivers to swap parking spaces faster (an unlikely proposition). For car sharing vehicle drivers, the responsibility for the car ends with the rental period. This leaves the responsibility for unblocking to the fleet operators (who do not seem willing or able to comply, although no publicly available data documenting this exists for Berlin).

The last (and probably most minor) issue is overextending the required staying time by artificially lowering the maximum charge accepted by car (e.g. by lowering the maximum current). This would imply our Tesla charges with 8A instead of 16A, doubling the time to charge to 90%.

Blocking

Blocking issues are needless (no attempt at charging took place) physical obstructions to the usage of the charger.

Cars parked even slightly on the allocated spots for parking can reduce availability through partial blocking.

Full blocking is the usage of the charging spot as parking space. This is a behaviour mostly associated with ICE cars. EV cars parking without a connected cable or a started attempt at charging fall into the same category, though.

Current mitigation situation

In summary, the issues are:

1. Overdrawing the real and / or legal limits of a stay at a charging station
2. Overextending the stay at a charging station by artificially reducing charging speeds
3. Blocking a charger, fully or partially

The complexity of this set of issues makes enforcement by the authorities difficult.

Arguably the easiest availability issue to spot (full blocking) is not proactively enforced⁴ in Berlin (as opposed to Hamburg and Munich). Crucially, this seems not to be a legal issue but the lack of will and personnel to enforce the rules.

EV owners have the option to call the police (or the Ordnungsamt, which will also involve the police) and ask for the towing of the blocking car, but this a low priority request and accordingly often a lengthy process. Using apps is the most simple way to notify the Ordnungsamt (in case time is not an issue) but its effectiveness as a deterrent against blocking is unclear (blocking charging stations is not even a specific category in them).

Combined with the large number of cars in Berlin and the shrinking availability⁵ of once ubiquitous free street parking spots, planning with city level charging is quite challenging for EV drivers.

Data on the lack of availability through various forms of blocking are not available to the public, at least not in Berlin. It should be possible to derive data for some forms of blocking through existing channels, though:

1. Overdrawing and blocking by free floating car sharing⁶ providers should be available through their datasets

2. Overdrawing⁷ and overextending by EV users should be available through charger station operators

The parallel issues of opaque pricing and roaming schemas is another topic, possibly for another day.

Better mitigations

The central issue with city level chargers is the question of availability of a charger at a specific location (which is convenient for the driver) at a certain time (when the driver arrives) for a certain time (the time to charge the vehicle).

That implies the need for a new type of reservation API (either central or distributed through operators and / or roaming providers). In order to improve on the existing situation, this system should provide a fair compromise between the desire to overstay (nobody wants to leave a meeting to search for a new parking space or wake up at night for it) and the desire of other drivers to charge.,

Reservations

I propose using a coarse-grained clock for such an API (e.g. using 15m ticks). This should be a reasonable tradeoff between two different constraints. Nobody wants to wait at a charging station for a longer period. And nobody wants to be forced to rush to the charging station to make it available again. In this schema, a driver could reserve a station for e.g. 20:15 but not for 20:10.

Drivers using this API can ask for reservations in a radius around a target destination. There should not be an option to have multiple reservation request active except for prioritized drivers (who might need more flexibility). Prioritized drivers are special needs users of specific stations. These could include elderly, disabled and commercial drivers (e.g. taxis).

The API answers with a best station reservation, based on price, applicability and distance to target. This reservation is binding.

If no matching option is available, the API offers a few applicable stations sorted by time to availability, price and distance. The resulting reservation would be binding as well.

Reservations requests include a minimum acceptable reservation type. These types are a list of reservation terms that are ordered by flexibility: the higher the tier, the less flexible it is. Depending on various factors (forecast demand or reservations by priority drivers) certain lower tiers will be unavailable on certain locations at certain times.

This minimum acceptable reservation type is configurable by the requesting driver.

Opportunistic charging type

This type reserves a charger at the time desired (e.g. 20:15) or available (e.g. 20:45) for the desired duration (e.g. 5:30h).

If a prioritized driver requests a reservation overlapping with the existing one, the driver must be ready to leave within 15m of the desired time. In order to support this, the API implements a notification schema.

Flexible charging type

This type reserves a charger at the time desired (e.g. 20:15) or available (e.g. 20:45) for the desired duration (e.g. 5:30h).

After a charge is complete, the drivers must be ready to leave within 15m.

Various levels of overnight charging types

The same rules apply as before, but the driver must be ready to leave at 06:00, 08:00 or 10:00, respectively. For these tiers, escalating parking fees would apply for the hours between charging and leaving.

For drivers parking at night where the desired charge time exceeds the specified hours when a driver must leave, these tiers translate to allowed parking times instead. A simple schema would be 2h for each tier, allowing up to 6h of parking when arriving at night.

Example: a Tesla Model 3 arrives at 4:00 requiring 6h of charging using a Tier 3 reservation. The driver has to be ready to leave (when notified) as soon as 12:00.

If the same Tesla arrived at 05:45 using a Tier 5 reservation, the time to leave would be 17:45.

Availability of reservation types

The API should expose historical usage for chargers (including for priority driver requests) and consider potential reservations (those not taken because of unavailability) as potential historic usage data of charger as well. This would allow the system to learn to some extent, making forecasts and type availablity selection possible.

Potential extensions could include additional required characteries of chargers such as

1. vehicle size, including the option to park with attached trailers
2. accessibility of the parking space (when used by disabled drivers)

The system should handle all forms of overdrawing or overextension with fines. Any vehicle that did charge with a certain power in the past and is requesting less power now (e.g. 3kw instead of 11kw) I’d consider overextending.

Both abuses of the system would automatically cancel an existing reservation request and allow the triggering of a new one.

Based on adaption and real-world telemetry, the introduction of additional types might be sensible and useful.

Blocking

The authorities should handle blocking quickly for this scheme to succeed. Potential mitigations would include measures such as:

1. camera surveillance or any other means of automatic detection of partial or full blocking
2. visual and / or acoustic signalling of partial or full blocking
3. swift towing procedures and costly fines, even for partial blocking offences

Summary

This post summarises observations from a user’s perspective. I have never worked for or in the electrical vehicle charging industry.

The legal landscape surrounding chargers is likely complex. It’s governed by city level, national and European regulations. It’s also affected by existing charging station operator and roaming provider business relations.

That said, I am in no position to suggest at which level such an API is best implemented (if at all). I merely suggest that in absence of API based planning option, reliably planning with city level charging is an impossibility. This does not bode well for the future adoption of EVs in cities, unless we’re getting rid of cars in cities completely.

---

1. Charging under the maximum capacity of the battery is a longevity best practice in many EV models. ↩︎

2. Favouring AC charging over DC charging (when circumstances permit) is a longevity best practice in many EV models. ↩︎

3. PHEVs are more of a problem (or emission accounting trick for their manufacturers) than a solution to local emissions. The NGO European Federation for Transport and Environment goes as far to speculate about a new Dieselgate scandal regarding real PHEV emissions in the field. ↩︎

4. According to the Senatsverwaltung für Umwelt, Verkehr und Klimaschutz Berlin the actual issue is enforcement by the police, not the legal environment. ↩︎

5. The current strategy paper of the Senat is listing several measures aimed at reducing public parking space (e.g. for new developments ) and free parking specifically. Currently pending initiatives such as berlin autofrei aim even higher and ask for an almost complete elimination of private car traffic in Berlin. ↩︎

6. Since the EV sharing economy has to deploy “Juicers” to some extent, their general usage of public chargers seems to operate in legally murky waters as well. Especially WeShare owner Volkswagen should be able to sustain their business models by operating their own charging infrastructure (potentially open to the public). ↩︎

7. E.g. EnBW already charges strict blocking fees. These are independent of regulations for the specific charger and the time of the day. ↩︎