DURING CHARGING

How to use smart charging with OCPP

Intro

In this guide, we will explore how we can enable smart charging for electric vehicles by taking a deeper look into the components of a charging profile in OCPP 1.6J format and the process by which a charging station accepts charging profiles.

Using charging profiles allows smart charging to be implemented with OCPP-compliant chargers.

A charging profile is a set of power limits with defined time values in seconds. For example, a charging profile could look something like this:

‍

‍

Otherwise described as:

Power 10 kW from Time 0 Seconds to 120 seconds
Power 25 kW from Time 120 Seconds to 300 seconds
Power 5 kW from Time 300 Seconds to 600 seconds
Power 8 kW from Time 600 Seconds to 800 seconds

OCPP defines a standard format to create these charging profiles so that any OCPP-compliant chargers can accept and follow these commands. It looks like this:

‍

{
"connectorId": 3
"csChargingProfiles": {
"chargingProfileId": 26771,
"chargingProfileKind": "Absolute",
"chargingProfilePurpose": "TxProfile",
"chargingProfileSchedule": {
"chargingRateUnit": "kW",
"chargingSchedulePeriod": [
{
"limit": 2,
"startPeriod": 0
}
],
"duration": 86400
},
"stackLevel": 1,
"transactionId": 372812,
"validFrom": "2021-10-25T21:57:33.222092",
"validTo": "2021-10-26T21:57:33.222092"
}
}

‍

The OCPP backend can send a charging profile during a transaction (= charging sessions) or when no transactions occur. However, OCPP defines certain limitations in the latter case, which we will discuss further below (txDefaultProfile vs. txProfile).

In any case, several steps take place when a charging session occurs with smart charging enabled. Once a charging session is initiated, either through a StartTransaction or remoteStart, the Central System sends charging profiles using a SetChargingProfile.req.

The SetChargingProfile.req is one of the more complex OCPP message types and has many configuration options. This message makes energy management possible since it contains the flexibility to build complex logic. On the other hand, this can lead to complex problems and errors if used wrong.

The SetChargingProfile.req includes an object csChargingProfile. This object specifies core parameters such as the power or current limits, timeframe, and more.

For example, the units of the limit can be expressed in power (maximum power allowed in Watts) or current (maximum current allowed per phase in Amperes).

Certain parameters, such as numberPhases, Duration, can also heavily influence how a charge point will react to a command.

The charge point will respond to these commands with a confirmation, setChargingProfile.conf, which includes a response defined for ChargingProfileStatus as accepted, rejected, not supported. If the charger responded with rejected or not supported, you might need to verify the format of the setChargingProfile or verify the format with the hardware manufacturer. Most chargers have limitations and exceptions and will cause this response.

While the above is a simplification of the process and fields required, we will take a look at each of the required fields and what they represent below.

‍

Sending a Charging Profile using SetChargingProfile.req

‍

Background: In OCPP, the Central System sends the message SetChargingProfile.req to the charge point. The charge point confirms with SetChargingProfile.conf (Accepted, Rejected, NotSupported).

It is composed of the connectorId and the csChargingProfiles.

connectId (Required): The connector to which the charging profile applies. If connectorId = 0, the message contains an overall limit for the Charge Point.‍
csChargingProfiles (Required): The charging profile is to be set at the Charge Point.

‍

A SetChargingProfile.req can be sent:

At the start of a transaction to set the charging profile for the transaction:
Once a transaction has started, a charging profile is set to that specific transaction ID. This prevents mismatches between transactions and TxProfiles, ensuring that the charging command has a corresponding transactionID.
In a RemoteStartTransaction request sent to a Charge Point:
If a transaction is started remotely, the Central System can include a charging profile within the RemoteStartTransaction request.
During a transaction to change the active profile for the transaction:
There may be a need to update the charging profile during a transaction. In this case, another SetChargingProfile.req will be sent. The charge point will then reevaluate the collection of charge profiles to determine which profile is active. ‍
Outside the context of a transaction as a separate message to set a charging profile to a local controller, Charge Point, or a default charging profile to a connector: Default charging profiles can be sent to the charge point. These default profiles can be executed without transaction IDs, which can be useful when there are network connectivity issues, and allows for charging even without transactionIds.

‍

Describing the elements of the ChargingProfile with csChargingProfile

‍

A ChargingProfile consists of a ChargingSchedule, described in the next section, that details the power limits over time.

Here, we look at csChargingProfile, which describes the specific elements within the charging profile.

chargingProfileId (Required): Unique Identifier for this profile. This is defined by the energy management system or the OCPP backend.
transactionId (Optional): Only valid if the profile is TxProfile, in which case the transaction ID is used to match the profile to a specific transaction. This field is not required for txDefaultProfiles but is required for txProfiles.
stackLevel (Required): Value determining level in hierarchy stack of profiles. Higher values have precedence over lower values. The lowest level is 0.) This is used to stack several profiles on each other without deleting or overriding the previous one. The charge point will always use the profile on the highest available stack level. Stacking charging profiles with various levels allows the construction of complex schedules that can take into account times of day, days of the week, and even certain holiday exceptions.
chargingProfilePurpose (Required): Defines the purpose of the schedule transferred by this message. OCPP defines the following options:

ChargePointMaxProfile: Configuration for the maximum power or current available for an entire Charge Point.
TxProfile: Profile with constraints to be imposed by the Charge Point on the current transaction or a new transaction when this is started via a RemoteStartTransaction.req with a ChargeProfile. A profile with this purpose SHALL cease to be valid when the transaction terminates. This is the most frequently used charging profile purpose.
TxDefaultProfile: a default profile to be used for new transactions. More on the differences between TxProfiles and TxDefaultProfiles can be found here. Typically a default profile can be sent without a transactionID, for example, to ensure charging occurs in a controlled manner if connectivity is lost.

chargingProfileKind (Required): Indicates the kind of schedule.

Absolute: Schedule periods are relative to a fixed point in time defined in the schedule.
Recurring: The schedule restarts periodically at the first schedule period.
Relative: Schedule periods are relative to a situation-specific start point (such as the start of a Transaction), which is determined by the charge point.

recurrencyKind (Optional): Indicates the start point of a recurrence.

Daily: Schedule restarts at the beginning of the next day
Weekly: Schedule restarts at the beginning of the next week (Monday morning)

validFrom (Optional): Point in time at which the profile starts to be valid. If absent, the profile is valid as soon as the Charge Point receives it. Remember that most charge points use the UTC time zone.
validTo (Optional): Point in time at which the profile stops being valid. If absent, the profile is valid until it is replaced by another profile.
chargingSchedule (Required): Contains limits for the available power or current over time. This is technically the core of the setChargingProfile.req and contains the actual “charging profile.” We will go into more detail in the next section.

‍

ChargingSchedule: describing the amount of power or current that can be delivered per time interval

‍

The ChargingSchedule component found within the csChargingProfiles includes power or current limits over time for the charging profiles. Additionally, it also includes other information such as units, etc.

Duration (Optional): Duration of the charging schedule in seconds. If the duration is left empty, the last period will continue indefinitely, or until the end of the transaction, in case startSchedule is absent. Important: some charge points require this field.
startSchedule (Optional): Starting point of an absolute schedule. If absent, the schedule will be relative to the start of charging.
chargingRateUnit (Required): The unit of measure Limit is expressed in:

W: Watts (power) defines the maximum power allowed on the charge point
A: Amperes (current) defines the maximum current allowed per phase

chargingSchedulePeriod (Required): List of ChargingSchedulePeriod elements defining maximum power or current usage over time. The startSchedule of the first ChargingSchedulePeriod SHALL always be 0. This always has:

startPeriod (Required): Start of the period, in seconds from the start of schedule. The value of StartPeriod also defines the stop time of the previous period.
Limit (Required): Charging rate limit during the scheduled period, in the applicable chargingRateUnit, for example, in Amperes or Watts. Accepts at most one digit fraction (e.g. “8.1”).
numberPhases (Optional): The number of phases that can be used for charging. If several phases are needed, numberPhases=3 will be assumed unless another number is given.

minChargingRate (Optional): Minimum charging rate supported by the electric vehicle. The chargingRateUnit defines the unit of measure. This parameter is intended to be used by a local smart charging algorithm to optimize the power allocation if a charging process is inefficient at lower charging rates. Accepts at most one digit fraction (e.g. “8.1”). Certain vehicles stop charging or go into sleep mode if the charging rate is too low. This parameter sets a minimum power so that the charging remains engaged at the most minimal level.

‍

Wrapping up: Real applications with EVSE Brands

{
"connectorId": 3,
"csChargingProfiles": {
"chargingProfileId": 26771,
"chargingProfileKind": "Absolute",
"chargingProfilePurpose": "TxDefaultProfile",
"chargingSchedule": {
"chargingRateUnit": "kW",
"chargingSchedulePeriod": [
{
"limit": 2,
"startPeriod": 0
}
],
"duration": 86400
},
"stackLevel": 1,
"transactionId": null,
"validFrom": "2021-10-25T21:57:33.222092",
"validTo": "2021-10-26T21:57:33.222092"
}
}

‍

While the above highlights the required and optional components of charging profile messages using OCPP, what we found at Ampcontrol is that certain manufacturers have slightly different nuances in their interpretation of OCPP.

For example, many chargers don’t follow the standard as anticipated and expect a different format. Others may only accept limits with a certain number of stack levels or phases. There might be some tweaking required for the exact charging profile sent to the charger; otherwise, the charger will reject the message.

Besides calculating and sending charging profiles, it is equally important to understand error messages and conduct hardware testing with manufacturers. At Ampcontrol, we typically test with models before running complex charging profiles on a real charging site.

‍

Summary

To use smart charging in your charger operations, you must first start a charging session. You can do this either through StartTransaction or remoteStart. Once initiated, the Central System sends charging profiles using a SetChargingProfile.req.

The SetChargingProfile.req includes an object csChargingProfile. This object specifies core parameters such as the power or current limits, timeframe, and more. The charge point will then respond to these commands with a confirmation, setChargingProfile.conf, which includes a response defined for ChargingProfileStatus as accepted, rejected, not supported.

Outline

Intro

Sending a Charging Profile using SetChargingProfile.req

Describing the elements of the ChargingProfile with csChargingProfile

ChargingSchedule: describing the amount of power or current that can be delivered per time interval.

Wrapping up: Real applications with EVSE Brands

Summary