Transactions are the OCPP term for charging sessions and in a high level setting these terms can be used interchangeably. However it should be noted that an OCPP transaction technically covers a broader scope than a charging session, a transaction may start before charging commences and end after as we will explain below.
Transaction handling has a major overhaul in OCPP 2.0.1 compared to previous versions. The updates allow for much more granular control and insight into when transactions start and stop and the events that occur in between. This is all due to the new message introduced which is the TransactionEvent.
For details on OCPP transaction use cases refer to section E of the OCPP-2.0.1_part2_specification.pdf document.
All transaction information is conveyed using TransactionEvent messages which are always sent as requests from the CS, the CSMS usually responds with an empty response as shown below.
TransactionEventRequest messages are highly flexible and can be used to convey the start of a transaction, the end of a transaction, or some information in between such as the latest meter values delivered.
The eventType distinguishes a started, updated, or ended transaction event, each has their own expected structure and requirements. For example the ended transaction event must include a summary of the meter values reported during the transaction.
Below is an example of a TransactionEventRequest that might be send at the start of a transaction, indicating that a transaction has been started due to an authorization.
TransactionEventRequest (started):
TransactionEventResponse:
Another key difference in 2.0.1 transactions from previous versions is the ability to set the start and stop points for transactions from the CSMS. This means the operator can define for themselves what a transaction actually is.
For example if you set the start and stop points to “EVConnected” then the transaction events will only be sent from when the vehicle is first connected to when it is disconnected, any events outside of those (such as an authorization with an RFID card) would not be included in the transaction event data.
Transaction start and stop points are set using specific variables in the Device Model:
TxCtrlr.TxStartPointTxCtrlr.TxStopPointThe allowed values are:
EvConnected (Both ends of the cable are connected)Authorized (Driver or EV is authorized)PowerPathClosed (Misleading name, this just means EVConnected AND Authorized)ParkingBayOccupancy (EV is detected in the parking bay)EnergyTransfer [Recommended not to be used as a TxStartPoint] (Energy is being transferred between charger and EV)DataSigned [Not to be used as a TxStopPoint] (When the first signed meter value is received from the meter, likely only ever to be used where regulation, such as the German calibration law, requires it)In most cases operators will use the simpler start/stop points; EVConnected, Authorized, or PowerPathClosed. It also simplifies things to use the same start and stop points for a station to prevent a “hanging” transaction. For example if the start point is EVConnected and the stop point is Authorized then a driver connecting then disconnecting their vehicle will start a transaction but not stop it. It’s also advised to set the same start/stop points across the network so that the transaction definitions and reporting is consistent.
Meter values are measurements normally from the electricity meter inside the charging station. These are electrical measurements such power, energy, current, and the vehicles state of charge.
Meter values can be recorded and sent to the CSMS at any time but most commonly are sent during a charging session. In this section we will cover the main use cases for meter values and how to configure them.
These are values that are recorded during a transaction (charging session). Typically meter values are sent at the start of a transaction, at the end, and during at regular intervals.
TransactionEventRequest (updated):
These are values that are recorded outside of a transaction, also called “Clock Aligned” meter values. They can be useful for general monitoring of the electrical conditions at the charging station, for example to monitor an over voltage fault.
Non-Transaction related meter values are sent in their own message called the MeterValuesRequest which has the same nested JSON that meter values sent in a TransactionEventRequest have.
MeterValuesRequest:
MeterValuesResponse:
Get transaction status messages are used to get the status of a specific transaction from the station, specifically to check if there are queued messages which have not yet been sent. This is useful for debugging faulty transaction data.
GetTransactionStatusRequest:
GetTransactionStatusResponse:
Implementing OCPP 2.0.1 transaction handling can be one of the more complex areas for CSMS or CS software developers. The change from the relatively simple OCPP 1.6 transaction system to this one is a big jump and handling all of the possible transaction start and stop points correctly can be especially difficult on the CS side.
Some key simplifications can be made in regards to the start and stop points, as noted above. It’s also worth making some voluntary simplifications at the beginning of development, for example by only supporting one or two start and stop points.
On the CSMS side transaction handling is slightly simpler. It is required to respond to the requests, store the responses, and build up some data object of a transaction which can be easily visualised on the front end. Meter values should be given special consideration in terms of data storage as they are likely to be one of the more high volume message types and have special importance for use cases like smart charging.