Key:ref:ocpi

The Open Charge Point Interface protocol (OCPI) is a free to use, publicaly documented protocol that enables communication between different players in the electric vehicle (EV) charging ecosystem—specifically between Charge Point Operators (CPOs) and eMobility Service Providers (eMSPs). That is to say it is a protocol focused on enabling roaming between different charging networks. As an example use case, the protocol enables an EV owner registered with one provider to change their EV at a station operated by another provider and still get billed correctly.

OCPI ensures interoperability across EV charging networks by allowing:

• Authentication of EV drivers across networks
• Real-time sharing of charging station locations and availability
• Transparent pricing and tariff information
• Billing and settlement between CPOs and eMSPs
• Remote session management, like starting/stopping a charge via app
• Smart charging capabilities and support for roaming

The OCPI protocol is maintained by the EV Roaming Foundation, a global industry membership organisation, and is widely used across Europe and beyond.

Terminology

The OCPI protocol sets out a three level/hierarchy data structure for charging infrastructure, or 'objects' as they are referred to in the protocol:

1. Location object: OCPI has Location at the highest level. This is defined as a one, or a grouping of charge points (man_made=charge_point in OpenStreetMap) that share close proximity. In OpenStreetMap the OCPI Location object maps to amenity=charging_station. While OCPI allows for operators with a number of charge points in close proximity to assign each charge point to it's own Location object, they advise against it. Instead they prefer that all the operator's charge points within that close proximity area should be associated to a single OCPI Location object. They argue that "an EV driver does not care if a destination consists of one charge point with a very large amount of EVSEs, or a large amount of charge points with only one EVSE. The EV driver wants to know how many EVSEs are available. Grouping charge points in close proximity into one OCPI Location will show better on a map". that shows Charging Locations.
2. EVSE object: Each Location object can have multiple EVSE objects. An EVSE is the part that handles the charging process of one EV at a time and may have one or several connectors (sockets/plugs) but only one connector can be used at the same time.
3. Connector object: Every EVSE object can have one or more Connector objects. The connector is the physical interface connecting to the car. We use the socket:*=* tag for this regardless of whether the connector is a socket/plug or tethered cable.

Note that this hierarchy differs from that of other standards, such as the eMI³ standard described on the ref:EU:EVSE=* wiki page.

Parking objects were added in OCPI in version 2.3.0 of the protocol. The purpose of Parking objects is to allow CPOs in the EU to comply with requirements in the EU’s Alternative Fuel Infrastructure Regulation (AFIR) which requires charge point operators (CPOs) to report the number of parking spots and certain properties of those parking spots. An EVSE object can have none, one or many Parking objects associated to it. A Parking object can be assigned to multiple EVSE objects (for the case where a parking space is shared between EVSEs).

OCPI IDs in OpenStreetMap

The OCPI protocol has identifiers (IDs) for each of the object types listed above. For EVSE objects, it has it's own ID but also allows for use of an EVSE ID conforming to the eMI³ standard as described on the ref:EU:EVSE=* wiki page. The table below sets out how these map into OpenStreetMap.

Please only add these references if you are certain that they are genuine OCPI references in use as part of a data sharing practice.

OCPI Object	Property	DotNotation Propery	Format/Syntax	Description & example in the OCPI protocol	OSM tag
Location	id	Location.id	CiString(36)	Uniquely identifies the location within the charge pint operators (CPOs) platform (and suboperator platforms). This field can never be changed, modified or renamed.	ref:ocpi:location:id=*
EVSE	uid	EVSE.uid	CiString(36)	Uniquely identifies the EVSE within the CPOs platform (and suboperator platforms). This field can never be changed, modified or renamed. This is the 'technical' identification of the EVSE, not to be used as 'human readable' identification, use the field evse_id for that. This field is named uid instead of id, because id could be confused with evse_id which is a field in a specific format defined by eMI3 and IDACS. Note: OCPI feel the need to introduce the EVSE.uid as they want a unique identifier that can never be re-used. In comparison, the eMI3 (and IDACS) EVSE ID relates to the physical hardware so could be re-used if that hardware is moved from one location to another.	TBC
EVSE	evse_id	EVSE.evse_id	CiString(48)	Optional. An ID compliant with the following specification for EVSE ID: "E-mobility ID-codes: the purpose of IDs, ID usage and ID format" (https://evroaming.org/contract-evse-ids/). Note: This specification is defined on the ref:EU:EVSE=* wiki page as "EVSE ID". Former versions of OCPI referenced the eMI3 standard here but this has been updated now that the eMI3 website is no longer online.	ref:EU:EVSE=*
Connector	id	Connector.id	CiString(36)	Identifier of the Connector within the EVSE. Two Connectors may have the same id as long as they do not belong to the same EVSE object.	None. This ID is not required in OSM.
Parking	id	Parking.id	CiString(36)	The identifier for this parking space. The value of this field MUST be unique among all Parking objects in the same Location object.	None (yet)/TBC

Here CiString(n) means a case insensitive string of maximum length n. Only printable ASCII characters are allowed (non-printable characters like: Carriage returns, Tabs, Line breaks, etc are not allowed).

Note that, in theory, a charge point operator could use a Pool ID using the syntax set out in the eMI³ standard and as described on the ref:EU:EVSE=* wiki page for their OCPI Location.id.