Reservations

This is a general outline on how Reservations currently work with OCPP and OCPI and why there are limitations to widespread use.

OCPP and OCPI capabilities w.r.t. Reservations

OCPP and OCPI are not aligned to ensure seamless resevations across networks:

• OCPI allows to just specify a Location ID with the CPO ensuring that at least one EVSE is available. This requires logic on the CPO backoffice software as OCPP handles only individual Charge stations.
• OCPP requires a specific CS to be reserved, but there is no official way to communicate this via OCPI
• Neither system can properly handle future reservations or queue reservations
• No official way for CPOs to communicate max advance reservation time (this means in principle a CS could be reserved between 'now' and 5 months from now)
• OCPI 2.1.1 doesn’t support cancellations

--> Reservations via CPO specific App with bespoke reservation tool are the only way forward

x = required
? = optional
empty = not specified

GreenFlux reservation approach

GreenFlux will expose an API that mirrors OCPP commands. This means a CS will be reserved between now and expiry date.

However, the API is ‘dumb' and only accepts ReserveNow and CancelReservation. Any logic or constraints need to be handled by a custom Reservation App that CPOs need to develop.

At its core, a reservation App and underlying ‘reservation Handler’ should do the following tasks:

• Front end: Collect required information from driver
• Set configuration parameters (max and min advance reservation time)
• Pricing (additional costs for reservation or no show)
• Queuing mechanism
• Reservation management

However for it to work in practice, there needs to be an 'enforcement mechanism'. CPOs would need to experiment with this e.g. naming and shaming Users, fines or banning Tokens from using reservations.

OCPP and Charge station reservation constraints

ReserveNow
OCPP only enables chargers to be reserved between Now (the moment of reservation) and expiryDate. Unless configured at the input side, this could be days in advance.
i.e. if a Driver wanted to reserve for tomorrow evening, the charge station would be reserved between Now and tomorrow evening, so more than 24.

Visual indication
Currently few charge station models have reservation identifiers (LEDs, displays etc), so that ad-hoc drivers know it is reserved.
The experience of parking, connecting and only to realise that the charger is reserved can be very frustrating.
→ Chargers require visual indication of being reserved, or charging at specific location must be reservation only.

Complex queuing/availability algorithm
Assuming a Reservation system enables future bookings (tomorrow evening), these reservations needs to be stored and activated at the right moment. In combination with having little control over how long drivers actually charge, this can be complex.

Example below:
A Driver has a reservation for next day 10:00 and another driver for 18:00. Depending on the logic applied, the Charge station would need to be kept reserved the entire night and several hours before 18:00. However, how can you guarantee that the Charge Station is available again at 18:00?