The Charging Process of an Electric Vehicle from an IT Perspective. Part 3: State

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, …).

Only when using the app does the user identify himself directly, e.g. at the roaming provider

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:

Entering the queue is only possible for app-users. RFID-card users do have to register directly at the station.

 .

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:

Section of the state-depiction of a reserved 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:

State: charging process reserved

reserved

If the user terminates the process without ever starting the actual charging, the state of the charging process switches to

State: charging process aborted by user

aborted

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:

State: charging process requestested  by device

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

ongoing

The charging connector is marked as “occupied”, too:

Section of the state-depiction of an occupied charging connector

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”

Section of the state-depiction of an idle but occupied charging connector.

If Gridware wants to terminated the charging process (for example due to a user’s request), it must request that termination from the device:

State: charging-progress termination requested at 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 (regularly)

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

Incomplete

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:

Section of the state-depiction of an un-occupied charging connector.

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…

Share this Post

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *