How to start a charging session with startTransaction

Intro

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:

• StatusNotification request
• Authorization request
• StartTransaction request

‍

Plug-in Events and Status Notification

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:

• connectorId: Shows the identifier of the charging connector, which is typically 1, 2, or 3. If the charge point has more plugs, this number will be higher.
• errorCode: Shows potential errors that are reported by the charger. To start the session, it should ideally contain “NoError”. However, possible errors can be “EVCommunicationError”, “UnderVoltage”, or similar. In many cases, the status will show “OtherError” and will show a vendor error code in the additional info or vendorErrorCode field.
• status: As mentioned above, this should be changing from “Available” to “Preparing” when the driver plugs in the cable to the vehicle. In some cases, the charger shows this “Preparing” status when the user presents a driver card.

‍

‍

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‍

{
   "connectorId": 1,
   "errorCode": "NoError",
   "status": "Preparing",
   "timestamp": "2022-06-12T09:13:00.515Z"
}

‍

Vehicle Authorization Request and idTag

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”.

‍

Start Charging Request and Energy Offering

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:

• connectorId: The charger plug identifier, typically 1, 2, 3, etc.
• idTag: The same token that we sent and authorized in the authorize.req. This will ensure that the session was authorized.
• meterStart: The charger sends the meter value (energy, in Wh) for the beginning of the charging session. This can be either zero or any positive value and will help to count the total energy usage during a charging session.
• reservationId: Not relevant for this scenario, but this field will contain a reservation id that is known for the OCPP backend and allows to reject or accept the charging request. This is often used for public charging when drivers can reserve a charge point ahead of time.
  

‍

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:

startTransaction.req‍

 {
   "connectorId": 1,
   "idTag": "04222182626081",
   "meterStart": 0,
   "timestamp": "2022-06-12T09:13:09.819Z"
 }

‍

startTransaction.conf

{
   "idTagInfo": {
   "status": "Accepted"
},
   "transactionId": 1176518341
}

‍

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.

‍

Summary

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:

1. Change of status from available to preparing
2. Authorization of member card, credit card, or similar
3. Start of the charging process by the user
4. Change of status from preparing to charging
5. Beginning of energy usage and metering