June’s Feature Friday #4: Going Live

In this last post of the June Feature Friday, we’re looking at the OCHP Direct interface, the OCHP extension allowing for direct communication between the actors connected to the clearing house.

Why a Direct Interface?

While the central hub focus of OCHP allows for easy technical integration with a wide array of partners and enables roaming with a reduced amount of development need on the side of the connected backends, many of the more advanced use-cases such as giving live feedback for the driver on his session from the charger require a direct, live interface. For this, OCHP 1.3 introduced the first version of OCHP Direct, which will be aligned to the same version number (1.5) in the upcoming OCHP release.

In the current version, a wide number of use-cases is already covered, including but not limited to:

  • Trigger Remote Start/Stop Transactions
  • Reserving charging spots
  • Getting live data about charge point availability directly from the backend

There is already a range of information that the CPO can provide to the EMP via the “Inform Provider” method, giving live updates on a charge-in-progress to display in an app, for instance.

Going live

In order to facilitate protocol alignment with the market, and cover additional use cases, OCHP Direct 1.5 will include methods for live validation of existing tokens on an EMP endpoint. This means that even for use-cases where a customer swipes a card in front of a charger, the CPO checks via OCHP direct if that card is valid. As discussed in the first installment of the OCHP Feature Friday, these tokens will have the “Live Authorization” attribute to let the CPO know whether it SHALL or CAN be validated.

Currently, the recommendation is to use the OCHP Direct Session ID as the Authorization token for the CDR that follows it. However, with this change, a new optional field will be added to the CDR called “DirectID” which SHALL include the Session ID if one existed. The token field can then either contain the customer credentials if they were used, or otherwise the session ID again to ease backwards compatibility.

Posted in Protocol update.