CSMS API Specifications

Glossary

Overview

Information systems responsibilities

CSMS

Charging Station Management System :

• Connect to OCPP Charging Stations
• Acquire transactions, measurements and heartbeats from the Charging Stations
• Send transactions to Dreev
• Send measurements to Dreev :
  • Active energy import (Wh or kWh)
  • Active power (W or kW)
  • Current (A)
  • SoC (%)
• (Optional) Send Trips to Dreev, including :
  • Theoretical departure date
  • Theoretical return date
  • Energy requirement (Wh) to make the trip
• Receive or Fetch charging commands calculated by Dreev
• Translate charging commands into OCPP messages sent to Charging Stations
• Send the acknowledgements received for each charging command
• Resend data after recovering from connection losses between systems

Dreev

Smart Charging Service Provider :

• Receive data from the CSMS
• Optimize charging : Charging Commands computation
• Provide Charging Commands to the CSMS

Prerequisites

Charging Stations technical requirements

One of the goals of the CSMS API is for Dreev to be decoupled from the underlying communication protocol between the CSMS and the Charging Stations.

The following requirements are based on OCPP, but any protocol with an equivalent feature set can be translated into CSMS API messages.

• Versions : OCPP 1.6-J, OCPP 2.0, OCPP 2.1
• OCPP Smart Charging Profile
• Type of measurements (measurands) required in the MeterValues message :
  • Energy.Active.Import (location = Inlet)
  • Power.Active.Import (location = Inlet)
  • SoC
• "Clock Aligned" measurement readings (nice-to-have)
• Required features of the SetChargingProfile message
  • purpose : TxProfile, TxDefaultProfile
  • kind : Absolute, Relative
  • One stackLevel per purpose is sufficient
  • Ability to replace an existing profile if a new one is sent with the same purpose + stackLevel combination, according to the OCPP 1.6 specification (section 5.16.3)
  • chargingRateUnit : W or A
  • startSchedule :
    • Must be defined when kind=Absolute, the startPeriod offsets are interpreted as : startSchedule + startPeriod.
    • Not defined when kind=Relative, startPeriod offsets are interpreted as : transaction start date + startPeriod.
• Dreev can control Charging Stations both on the Outlet ("DC") or Inlet ("AC") interface.

In summary, the following two typical profiles must be supported by Charging Stations. The profile selection mechanisms must also be implemented according to OCPP 1.6 (or using Stack Level, or using profile IDs according to OCPP 1.6 paragraph 5.16.3).

OCPP Server Requirements

Limit on the number of concurrent transactions per badge

It is not possible for Dreev to have multiple transactions for the same vehicle or EVSE. Until the protocols implement strong vehicle identification, Dreev associates a badge (OCPP idTag) with a single vehicle. In principle, each user will receive a single badge for each vehicle. However, the CSMS must prevent the simultaneous presence of several transactions for the same badge.

For example, the OCPP SteVe server allows users to define the number of concurrent transactions for a given idTag. If a user tries to start a new transaction with their badge while a transaction is already in progress, the server will reject the second transaction.

Dreev assumes that the CSMS guarantees a maximum of one live transaction per vehicle. If Dreev receives a new transaction with a given badge, Dreev will assume that the previous open transactions are stopped.

Provisioning data

The following information is relatively static, and can be provisioned in Dreev’s system before the project starts.

To scale up, Dreev could set up endpoints to automate these exchanges.

Site topology

Dreev needs to know the topology of the site's electrical network to take into account power constraints. Some circuits are constrained to a maximum power lower than the sum of the maximum power of all the Charging Stations on that circuit. In this context, Dreev must sometimes anticipate the charging of vehicles in order to respect the constraints of the electrical installation and the drivers mobility needs.

Data needed :

• Delivery Points, also known as : PDL, Grid connection, Service Drop, Meter Point Administration Number (MPAN)...
• Energy Tariffs.
• Power constraints at the delivery point level.
• Electrical installation topologies :
  • Circuits hierarchy.
  • Power constraints of each circuit.
  • Charging Stations connected to each circuit.
• Priority of each Charging Station : In addition to the electrical installation, Dreev also needs to know whether certain parking spots block others.

Charging Station registry

The list of controlled Charging Stations. Dreev needs to know the technical characteristics of the Charging Stations in order to be able to properly control the charge. Charging Stations can be dynamically provisioned by the CSMS depending on the project.

Data needed:

• Unique identifier (UUID, mac address, ...)
• Name of the Charging Station (user friendly)
• Name of the manufacturer
• Serial number
• Technical characteristics of the model :
  • Maximum charging power
  • Minimum charging power (can be greater than or equal to 0)
  • Stand-by losses
  • Variable losses while charging

Vehicles registry

The list of vehicles with their technical characteristics. Vehicles can be dynamically provisioned by the CSMS depending on the project.

Data needed :

• Unique identifier (UUID, mac address, ...)
• Vehicle name (user friendly)
• Name of the manufacturer
• Technical characteristics of the model :
  • Battery capacity
  • Maximum charging power
  • Minimum charging power (can be greater than or equal to 0)

Charging Requirements - SoC Targets

Dreev can set SoC requirements for each vehicle following a weekly schedule.  This functionality is also available dynamically by the CSMS depending on the project, see section Charging Requirements.

Data flows

General dynamics

Dreev can send charging commands to the CSMS in real time after each optimization.

If it is not possible to allow Dreev-to-CSMS communication for security reasons, Dreev also provides a "pull" API that allows the CSMS to poll the latest charging commands.

If the CSMS architecture cannot react in real-time to OCPP messages, it is possible to trigger periodic batch processing to extract the accumulated OCPP data and send it to the Dreev API.

Periodicity

CSMS receives and records the following OCPP messages continuously:

• StartTransaction
• StopTransaction
• MeterValues
• Heartbeats
• ...

CSMS sends a near-real-time message to Dreev :

• Transaction Start & Stop events
• Charging command acknowledgements : SetChargingProfile.resp → ChargingCommand status
• Heartbeat messages
• Measurements (see description of flows)

Dreev sends the charging commands to the CSMS in real time after each optimization.

If this is not possible, the CSMS can also retrieve the charging commands every minute from Dreev. However, it is preferable to aim for real time, rather than batch processing.

Integration flows

Below are descriptions of different integration flows depending on the CSMS capabilities.

a) Real time Events + Push Charging Commands (optimal)

• The CSMS can react to transaction events in real time
• The CSMS can receive charging commands pushed by Dreev whenever they are computed

b) Real time Events + Pull Charging Commands

• The CSMS can react to transaction events in real time
• The CSMS polls Charging Commands frequently. This decision could be made for :
  • security reasons : impossible to open bidirectional communication between systems, prefering to keep the CSMS internal, etc.
  • convenience : it is easier to only call Dreev’s server than having to build and operate one.

c) Batch Events + Pull Charging Commands

• The CSMS cannot send transaction events in real-time, and has to send events in batch periodically. The CSMS could also choose this option for performance reasons (limiting HTTP calls).

• The CSMS cannot receive calls from Dreev, and has to rely on polling Charging Commands frequently.

Dreev CSMS HTTP API

Dreev’s CSMS API allows a Charging Station Management System to :

• Send transactions, measurements and heartbeats received via OCPP.
• Retrieve charging commands for each transaction.
• Acknowledge the status of each charging command.
• Report vehicle trips and energy requirements.

See CSMS API Authentication and CSMS API Endpoints.