Part 3: States During a Charging Process
The state of a charging connector and the state of the charging process reflect the real world. So let us start with the perspective of a user who wants to charch their car.
1. Searching and selecting the charging connector
Before the charging process can be started, the charging connector must be searched and selected. The user can find and select a (semi-) public charging connector by themselves. Often, however, an app or the car’s navigation device is being used for this. The software usually knows the user’s (preset) charging requirements (plug type, consumption-acceptance of the car, …).
During the selection of the charging connector, the charging process is not considered to have started yet.
2. Immediate booking or entering a queue
Next is the booking phase. If the charging connector is unoccupied, it will booked immediately. If the charging connector is still occupied, it can be booked using a virtual queue:
3. Reservation of the Charging Connector
Typically, the booking is not directly followed by the power transmission. Even if the user is in position 1 in the queue, the plug has to be plugged in beforehand. Furthermore, a payment process often has to be completed.
The charging connector must therefore be reserved exclusively for this user for a short time so that no other user “snaps” the charging connector:
For this purpose, the Open Charge Point Protocol (OCPP) provides the “Reservation” feature profile . However, this feature is not implemented by every hardware. For this reason, the reservation is also monitored by Gridware.
In addition, a charging process is now created in gridware with the status:
If the user terminates the process without ever starting the actual charging, the state of the charging process switches to
If, on the other hand, the user has met all the requirements, Gridware initiates the charging process at the charging station, and the status of the charging process then shows:
requested by device
If the device does not mind either, it will enable the power and inform the backend about it. From the user’s point of view, the charging process now begins.
4. Charging the Car
The charging process is often also called “charging session”. The user is informed about he amperage, their only option (besides waiting) is the abortion of the charging process:
The state of the charging process changes to
The charging connector is marked as “occupied”, too:
As soon as the amperage stops, the charging session switches to it’s next state:
ongoing without energy consumption
similarly, Gridware marks the charging connector as “occupied but idle”
If Gridware wants to terminated the charging process (for example due to a user’s request), it must request that termination from the device:
termination requested at device
5. Finalized Charging Process
Once the charging process has been ended (no matter how), it can have one of the following two states:
Finalized (with errors)
Special Case: Incomplete Charging Process
But beware: Sometimes a charging station sends the status message (OCPP statusNotification) “available”, although no corresponding termination command (OCPP stopTransaction) has been received for the charging process in question. In such cases, Gridware sets the status of the charging process to
This state is a “reason to act”. The charging process will remain in this state until the charging station has submitted the data for regular finalization (in particular the final counter reading) to the backend. No receipt can be created for the charging process before that is done.
The charging connector, on the other hand, is available as if everything was normal. It can be used again right away:
The Open Charge Point Protocol (OCPP) does not provide any rules regarding the order of state- and StopTx-notifications. Therefore this approach is not unusual.
What is next?
How can parts 1-3 be combined into the big picture? Find out in part 4…
This post is also available in: Deutsch (German)