- Field of use
- How is OCPI being used?
- Description
- Maven
- Dependencies
- Requirements
- Changelog
- Getting Started
Open Charge Point Interface (OCPI) is an open protocol used for connections between charging station operators and service providers. Simply put, this protocol facilitates automated roaming for EV drivers between different EV charging networks. This interface supports the affordability and accessibility of charging infrastructure for EV owners, allowing drivers to charge across different networks. The protocol provides accurate data on charging stations, such as location, accessibility and pricing, and takes into account real-time billing and mobile access to charging stations. The OCPI protocol is managed and maintained by the EVRoaming Foundation, making it freely available to software vendors.
OCPI consists of several modules. The role of a company in the EV landscape determines which modules of OCPI you need and how you use it.
A Extrawest-OCPI-2.2.1-CPO-Server library is designed to make life easier for those who wants to implement a Charging Point Operator application. Library was created followed OCPI-2.2.1 Specification. It allows developers to reuse pre-created models, interfaces and APIs, defined in OCPI-2.2.1 Specification.
With this library, you can easily get started with the Open Charge-Point Interface. The design is driven by test, which will ensure premium software that is easy to adapt and modify to your needs.
Please note, this is a library and not an application, so there is no main method.
Currently, we support 2.2.1 OCPI version.
At 2.2.1 you can choose what kind of events will be supported by CPO or EMSP.
Find the maven repo here: https://mvnrepository.com/artifact/com.extrawest/Extrawest-OCPI-2.2.1-CPO-Server
Java-OCA-OCPP uses the following libraries:
- springdoc
- mapstruct
- lombok
- spock-core-0.7-groovy-2.0
- javax.validation
- javax.servlet-api
- javax.annotation-api
- springdoc-openapi-starter-webmvc-ui
- springdoc-openapi-ui
- swagger-annotations
- jackson-databind-nullable
- Java 17 or higher
- Maven 3.6 or higher
To install the API client library to your local Maven repository, simply execute:
mvn clean installAdd this dependency to your project's POM:
<dependency>
<groupId>com.extrawest</groupId>
<artifactId>Extrawest-OCPI-2.2.1-CPO-Server</artifactId>
</dependency>Extrawest-OCPI-2.2.1-CPO-Server contains CPO Models, Validations, Controllers, Interfaces. To implement CPO Server developers need to write own implementations for CPO Services, e.g. :
@Service
public class ClientInfoServiceImpl implements ClientInfoService {
@Override
public ClientInfoDto getHubClientInfo(String countryCode, String partyId) {
// your own implementation here
}
@Override
public void putHubClientInfo(String countryCode, String partyId) {
// your own implementation here
}
}Current library provides APIs for OCPI 2.2.1. To see changes between OCPI 2.2.1 and previous versions please check OCPI changelog for OCPI 2.1.1 to OCPI 2.2 -> OCPI 2.2.1
Lots of typos fixed and textual improvements. The following changes to messages/objects etc.
| Context (Module / Object) | Description |
|---|---|
| Status Codes | Added OCPI Status Codes. Added exceptions handlers and exceptions to handle common errors (see Errors) |
| All modules | Added parameter's validation. Wrapped response into Response format |
| Locations | Added Paginated response to getting the list of known Locations |
| Locations | Added Location's endpoints permissions per roles: CPO as Sender, eMSP - Receiver, HUB - Sender & Receiver, NSP - Receiver, NAP - Sender & Receiver |
| Locations | Added ability to retrieve Evse/Connector |
| Sessions | Added Paginated response to getting the list of known Sessions |
| Sessions | Added Sessions permissions per roles: CPO as Sender, eMSP - Receiver, HUB - Sender & Receiver, SCSP - Receiver |
| CDRs | Added CDR's permissions per roles: CPO as Sender, eMSP - Receiver, HUB - Sender & Receiver |
| CDRs | Added Paginated response to getting the list of known CDRs |
| Tariffs | Added Paginated response to getting the list of known Tariffs |
| Tariffs | Added Tariffs permissions per roles: CPO - Sender, eMSP - Receiver, Hub - Sender and Receiver, NSP - Receiver, SCSP - Sender and Receiver |
| Tokens | Blocking client access to objects that do not belong to them ( see Errors). |
| Tokens | Added Tokens module's permissions per roles: CPO as Receiver, eMSP - Sender, HUB - Sender & Receiver |
| Commands | Added Commands module's permissions per roles: CPO as Receiver, eMSP - Sender, HUB - Sender & Receiver |
| Charging Profiles | Added Charging Profiles module's permissions per roles: CPO as Receiver, HUB - Sender & Receiver, SCSP - Sender |
| Credentials | Added permissions for main OCPI roles |
| Versions | Changed URLs according Version information endpoint |
Functional Modules:
| Module | v2023.8.24 | Description |
|---|---|---|
| Locations | + |
The Location objects live in the CPO back-end system. They describe the charging locations of an operator |
| Sessions | + |
The Session object describes one charging session. The Session object is owned by the CPO back-end system, and can be GET from the CPO system, or pushed by the CPO to another system |
| CDRs | + |
A Charge Detail Record is the description of a concluded charging session. The CDR is the only billing-relevant object. CDRs are sent from the CPO to the eMSP after the charging session has ended |
| Tariffs | + |
The Tariffs module gives eMSPs information about the tariffs used by the CPO |
| Tokens | + |
The tokens module gives CPOs knowledge of the token information of an eMSP. eMSPs can push Token information to CPOs, CPOs can build a cache of known Tokens. When a request to authorize comes from a Charge Point, the CPO can check against this cache. With this cached information they know to which eMSP they can later send a CDR |
| Commands | + |
The Commands module enables remote commands to be sent to a Location/EVSE. The following commands are supported: CANCEL_RESERVATION, RESERVE_NOW, START_SESSION , STOP_SESSION, UNLOCK_CONNECTOR |
| Charging Profiles | + |
With the ChargingProfiles module, parties (SCSP but also MSPs) can send (Smart) Charging Profiles to a Location/EVSE. It is also possible to request the 'ActiveChargingProfile' from a Location/EVSE |
| Hub Client Info | + |
Provides parties connected to a hub with the connection status of other parties that are connected to a hub that they can communicate with. So, CPOs know which eMSP and other parties are online and vice versa |
Configuration Modules:
| Module | v2023.8.24 | Description |
|---|---|---|
| Credentials | + |
The credentials module is used to exchange the credentials token that has to be used by parties for authorization of requests |
| Versions | + |
Via this module, clients can learn which versions of OCPI a server supports, and which modules it supports for each of the versions |
Roadmap:
| Functionality | 2023 |
|---|---|
| Authentification | |
| Authorization |
We are devoted to push the marked for vehicles charging forward. There are many standards out there, we intend to implement and share them. Any help is much appreciated!
The market is in its defining state, the practices and standards we come up with now, may very well stick around for decades to come.
See our vision at https://www.extrawest.com/