Subscribe & get the latest news in your email
blue x
Charging Technology

How to Send EV Charging Profiles to Your OCPP Charging Station

By

November 11, 2021

If you think that EV charging is just about connecting a cable from a mains source to a vehicle — you’re wrong!

There’s much more to it. And just as EV technology advances, so does charging technology. Companies are getting creative to improve the EV charging experience for drivers. This is due to the fact that many early adopters of EVs have been frustrated by a large number of apps, slow registration processes, and the number of errors that occur during charging.

But those days are finally behind us. Why? Because networked chargers are now connected to central cloud systems and continuously communicate with the Charging Point Operator (CPO). The CPO has a variety of services, monitoring systems, features, etc. connected remotely. This has opened the door to many technological advancements, such as mobile apps, RFID cards, and contactless charging.


What is the best way to connect to your EV charging station?

The most common way to connect a charge point with a central cloud system for EV charging is to connect an Open Charge Point Protocol (OCPP) to the internet. To learn more about how OCPP and smart charging can work together to optimize your EV operations, check out our report What Is OCPP and How to Use It For Smart Charging.

With the introduction of OCPP 1.6, there are two different types of OCPP:

  • SOAP-based implementations (OCPP-S)
  • JSON alternative (OCPP-J)

JSON is more compact and runs over Websockets. It also has much better diagnostics capabilities. Receiving and sending data with JSON is simple as it uses HTTP requests.

SOAP is less compact, more complicated, and overall more difficult to maintain.

A comment in Stack Overflow sums it up nicely: “Nowadays SOAP is complete overkill, IMHO. It was nice to use it, nice to learn it, and it is beautiful we can use JSON now.” Of course, that’s only one opinion, but it’s one that we share here at Ampcontrol. As most major charge point manufacturers use OCPP clients, the role of the CPO or operator of the central system is to have a full OCPP implementation according to the OCPP guidelines. Using a non-OCPP software system can lead to expensive adaptations later on and is not advised.


What is the general concept of OCPP for charge points?

The protocol is used for a large number of reasons. OCPP allows you to authorize an EV driver on a certain charging station, receive meter value (for example, Wh) during a charging process, and allows the operator to update a charger’s firmware.

Messages often include information about connectorId, chargePointId, transactionID, and other fields.

Every interaction starts with a request from the client (chargePoint) or server (central system), for example:

StartTransaction.req(connectorId, idTag, meterStart, timestamp, [reservationId]).

The other side (server or client) responds with a confirmation message such as:

StartTransaction.conf(idTagInfo, transactionId).


In the above example, we just started a charging process for one charging station.

Sequence Diagram: Example of starting and stopping a transaction — OCPP 1.6


Every message contains a JSON file as below:


{
“$schema”: “http://json-schema.org/draft-04/schema#",
“title”: “StartTransactionRequest”,
“type”: “object”,
“properties”: {
   “connectorId”: {
       “type”: “integer”
       },
       “idTag”: {
           “type”: “string”,
           “maxLength”: 20
       },
       “meterStart”: {
           “type”: “integer”
       },
       “reservationId”: {
           “type”: “integer”
       },
       “timestamp”: {
           “type”: “string”,
           “format”: “date-time”
       }
 },
 “additionalProperties”: false,
 “required”: [
     “connectorId”,
     “idTag”,
     “meterStart”,
     “timestamp”
]
}


How to send charging profiles with OCPP 1.6


The beauty of OCPP 1.6 and beyond, is the capability to implement smart charging for electric vehicles. Smart charging means that the central system can send load profiles or charging commands to the charge point. Smart charging is mostly used for load balancing, peak reductions, cost-based optimizations, or similar.

Therefore, with OCPP, the central system sends the message SetChargingProfile.req to the charge point. After receiving the load curve, the charging point sends a setChargingProfile.conf to confirm that the device received and accepted the profile. The charging station will follow these “instructions”.

Sequence Diagram: Set Charging Profile with OCPP 1.6

As well as the “typical” information such as connectorId and transactionId, the SetChargingProfile.req contains a part csChargingProfiles that specifies the charging profile and how the charging point must use the load profile.

Below you will find an example of a csChargingProfiles sent from the central system to a charge point.


“csChargingProfiles”: {
    “chargingProfileId”: 158798,
    “chargingProfileKind”: “Absolute”,
    “chargingProfilePurpose”: “TxProfile”,
    “chargingSchedule”: {
        “chargingRateUnit”: “W”,
        “chargingSchedulePeriod”: [
            {
               “limit”: 11000.0,
               “startPeriod”: 0
            },
            {
               “limit”: 9000.0,
               “startPeriod”: 780
            },
            {
               “limit”: 4500.0,
               “startPeriod”: 1680
            },
            “duration”: 1680
            },         ],
     “stackLevel”: 0,
     “transactionId”: 339373,
     “validFrom”: “2020–10–15T14:32:00+00:00”,
     “validTo”: “2020–10–16T14:15:00+00:00”
}


Below you will find an overview to get a better understanding of the instructions:

chargingProfileId (integer)
Identifier of the load curve

chargingProfilePurpose (string)
Defines the purpose of the schedule.
TxProfile: when related to the current charging event (transaction).
TxDefaultProfile: when not related to the current charging event.
ChargePointMaxProfile: to configure the maximum power available on the entire chargePoint

chargingSchedule
Contains the charging profile information such as start, stop, duration, and the actual profile (time series

stackLevel (integer)
Value determining level in hierarchy stack of profiles. Higher values have precedence over lower values.

chargingSchedulePeriod (array)
List of ChargingSchedulePeriod elements defining maximum power or current usage over time (that’s the charging profile!). Each element contains startPeriod, limit (W or A), and numberPhases (optional)

How to generate a charging profile for OCPP 1.6

If you already have or plan to use an OCPP backend, one of the best ways to generate charging profiles is to use the Ampcontrol app.

The process is simple:

  1. A vehicle connects to the charging station.
  2. Your OCPP backend receives the authentication request.
  3. This triggers an API call to Ampcontrol.
  4. Ampcontrol provides you the charging profile.

With Ampcontrol you can set your optimization goal (e.g., peak load reduction) for each charging location or customer. The best thing is, it provides you with the correct format automatically. Every profile is sent as csChargingProfiles for your OCPP server.


Summary

The key takeaways from this article are:

  • Use OCPP-J for JSON to communicate from the server (central system) to the charging station rather than OCPP-S.
  • OCCP-J has Websocket communication, charging station, and central system exchange messages.
  • OCPP 1.6 allows you to implement smart charging for electric vehicles.
  • Use the csChargingProfiles to specify the charging profile and how the charging point must use the load profile.
  • Ampcontrol is the fastest and most convenient way to generate a charging profile with your OCPP backend.

Learn more about smart charging with OCPP in our report, What Is OCPP and How to Use It for Smart Charging.

Tags:
Related Posts
See All Posts

Learn how fleet operators use Ampcontrol

Ampcontrol is a cloud-based software that seamlessly connects to charging networks, vehicles, fleet systems, and other software systems. No hardware needed, just a one-time integration.