The number one job of OCPP is to start a charging session when the driver uses their credit card, member card, or mobile app. In many cases, such as fleet operation, we want the session to start automatically, without any user action.
Here, we’re discussing how to start a charging session with the startTransaction request. This OCPP message initiates the charging and is one of the most common messages in the charging world.
In order to start a charging transaction initiated by the OCPP client we need the following OCPP messages:
To begin with the process, the EV charger needs to be available for charging. The charger does this by sending a statusNotification request (statusNotification.req) to the OCPP backend. When no charging is happening and the charge point is ready for the next session, the notification message will say “Available”. Also, the charge point and the OCPP system are exchanging heartbeats, which shows that the bidirectional communication is alive.
If the charger is not available, it will send other possible status information, such as “Charging”, “Finishing”, “Reserved”, or “Faulted”.
When the EV driver initiates the charging, they will plug the charging plug into the vehicle’s inlet. The charger will send a new statusNotification.req message to the OCPP server. This notification message contains the information “Preparing”, or in other words, preparing for charging. Without this status update, the charger will not initiate the charging.
If the OCPP backend is ready, it will respond with a statusNotification.conf message to confirm that the message was received and understood. The confirmation does not contain any information.
Below you see the flow of the status notification request in OCPP:
The statusNotification.req message is used widely in many scenarios beyond the start of the session. It includes the following information:
In the case of the StatusNotification.req connectorId, if the charger has more than one outlet, the connectorId will be numbered 1,2,3, etc. This is important, as some chargers allow simultaneous charging. Connector 1 might then be on the status “Preparing” while connector 2 is still on the status “Available”. In case only one single plug can charge at a time, the other connectors will send a statusNotification request containing the status “Unavailable”.
Here you see an example of the statusNotifcation.req
Next, we want to authorize the vehicle. While the connector is technically ready to provide energy, the backend typically wants to verify the user or vehicle. There are various ways to do this (RFID, mobile app, etc.), which we will discuss in a separate guide. For now, we just need to know that the charger has to send a piece of information to the OCPP backend.
To authorize the charging session, the charger sends the Authorize Request (authorize.req) to the OCPP backend. The only information that the OCPP message contains is the idTag. The idTag is typically a number and letter combination (token), that needs to be registered at this charging network or this charge point.
The OCPP backend responds with the Authorize Confirmation (authorize.conf) containing the AuthorizationStatus “Accepted”. This means, the central system verified the idTag and allows the driver to charge the vehicle. If the central system is not able to verify the idTag, it returns “Invalid”, “Blocked”, or “Expired”.
Finally, after the status change from “Available” to “Preparing” and the successful authorization, the user initiates the charging session. Therefore, the charger sends the startTransaction Request (startTransaction.req).
In some cases, this step is initiated by the charger automatically, after the charger received the authorization confirmation. For example, when a user swipes an RFID card, the driver typically doesn’t have to act after the RFID card was authorized.
The charge point sends a StartTransaction.req to the central system to inform about a transaction that has been started. Upon receipt of a StartTransaction.req the central system responds with a StartTransaction.conf, which confirms the message. Although the central system has already verified the idTag, it typically still has to validate the identifier as it might have been authorized locally on the charger using outdated information. The central system then responds with the StartTransaction.conf.
The request and confirmation message both include important information that we want to discuss:
As mentioned before, the OCPP backend will answer with the startTransaction confirmation. Even if the backend is denying the charging request, it will answer with that message type. The confirmation contains the two fields: idTagInfo and transactionId.
The transactionId is a simple number (e.g., 14023), which serves as an identifier for any other messages related to this charging transaction and also later for reporting purposes. The idTagInfo contains more information:
The expireDate and the parentIdTag are fields, which we saw already in previous messages. The status field is the same status that was used for the authorize request. It will contain “Accepted” if the charging session can start.
Here you can see an example for the startTransaction.req and the startTransaction.conf:
Only after receiving this startTransaction confirmation message including the transactionId and the “Accepted” status, the charge point is allowed to provide energy to the vehicle.
The charge point will change the status from “Preparing” to “Charging”, by sending a new status notification to the central system. Then, the charge point will start charging.
The startTransaction, authorize, and statusNotification are important OCPP messages, that we used frequently at EV charging networks or private charging hubs.
The typical process to plug-in start a charging session is:
Plug-in Events and Status Notification
Authorization Request and idTag
Start Charging Requests and Energy Offering