June’s Feature Friday #3: Token Module

When an EV Driver presents his/her card before the card reader on a charging point, the card and the charging point starts communicating with each other  and  a couple of informations get exchanged between the two. A relationship is established between the two and that relation is a  successful one if the information provided by the card are true, valid and known to the charging point, thereby allowing the vehicle to be charged.

And this step is what we call Authorisation and if the information is all acceptable by the charge point it implies a successful authorisation .

When roaming connections exist between EVSP-CHS-CPO, roamingauthorisation info exchanges occur between the EVSP-CPO and viceversa  via the CHS. The common language they undertsand is OCHP.


  1. What are these informations that are exchanged? and
  2. How are these informations known to the charging point?

In OCHP the informations that are exchanged are as follows:

  • EmtId
  • contractId
  • printedNumber
  • expiryDate
  1. An EmtId also known as a Token-ID is basically an Electrical Vehicle Contract Identifier. It consists of:
    • instance which holds the payload or the message
    • representation which specifies in which representation the token instance is set. For eg: plain or sha-160
    • type of supplied instance i.e. rfid or remote or other
    • subtype which specifies the exact type of the supplied instance .i.e mifareCls or calypso or others
  1. ContractId also known as an EVCO-ID is the agreement that the EV driver holds with the Provider.
  2. printedNumber is used mainly for manual authorisation.
  3. expiryDate as the name suggests implies whether the token is active or not . Tokens may be used until the date of expiry.

And, these informations are regularly retrieved by the charging points from the CHS database.

In OCHP 1.5, it is planned to exchange the data between the charging point and eclearing using REST Web Service communication protocol coupled with JSON instead of SOAP as used in OCHP 1.4 to improve performance, useability and many more advantages.

The comparison between SOAP and REST (JSON) response is shown below:

Figure 1: SOAP vs REST Response

Additionally the various SOAP requests would translate to REST methods in OCHP 1.5. An example for the messages concerning Exchange of Authorisation Data is shown below

SOAP Web Service Corresponding REST Web Service Methods
GetRoamingAuthorisationList.req GET
GetRoamingAuthorisationList.conf Response of GET method
SetRoamingAuthorisationList.req PUT
SetRoamingAuthorisationList.conf response of PUT method
GetRoamingAuthorisationListUpdates.req GET
GetRoamingAuthorisationListUpdates.req response of GET method
UpdateRoamingAuthorisationList.req PUT
UpdateRoamingAuthorisationList.conf response of PUT method
Posted in News.