What is the Difference Between TxProfiles and TxDefaultProfiles in OCPP?

In our previous article, we described the basics of OCPP for smart charging and 3 tricks on how to leverage OCPP the right way.

We also described that OCPP (Open Charge Point Protocol) uses the concept of charging profiles (power over time). Charging profiles can be defined by using external technology such as an energy management system.

A charge point can receive and store a charging profile that defines how quickly a vehicle takes to charge over time and how much power is used.

(original file:https://docs.google.com/presentation/d/1y7lHIPwD-gTxkCiRRY76G3_n1K_QOaEbXa5hU1LYR3A/edit?usp=sharing)

OCPP 1.6 JS and higher versions use SetChargingProfile.req messages, to send charging profiles from the OCPP server (backend) to the charging station (EVSE). Below you can see the general message flow to set a charging profile with OCPP 1.6 JS.

Amongst others, this SetChargingProfile.req contains the actual chargingSchedule (time series of power or ampere values). The message also contains the ChargingProfilePurpose, which we will discuss in more detail in a moment.

In this article, we’re only discussing the ChargingProfilePurposeType. However, we have noticed that it is common for companies to get confused about charging profiles, so we hope you will benefit from the guidance set out below.

Let’s get started.

What is the ChargingProfilePurpose?

The OCPP implemented ChargingProfilePurpose to differentiate between charging profiles. However, it’s important to be aware that the actual format of the profiles and the JSON stay the same. So, the only difference is how the charging profiles are used on the charging hardware and how the hardware executes them.

The charging protocol is differentiated into three types:

• TxProfile: transaction-related profile
• TxDefaultProfile: pre-defined profile for all upcoming transactions
• ChargingPointMaxProfile: profile limiting power from the grid.

You will see that the OCPP founders actually did a pretty good job in defining these types. One case in point is the difference between TxProfile and TxDefaultProfile, which helps us to implement very dynamic and reliable smart charging.

What is the TxDefaultProfile?

An OCPP backend can send TxDefaultProfile to one specific connector or to all connectors of the EVSE. OCPP says:

“If TxDefaultProfile is set to ConnectorId 0, the TxDefaultProfile is applicable to all Connectors. If ConnectorId is set >0, it only applies to that specific connector.”

But the magic of a TxDefaultProfile is that it can be sent without knowing the transaction. More specifically, the TxDefaultProfile is always valid, no matter which transactionId is currently active on this connector.

Why is this important? If you use it right, you can set a charging profile and the charge point will follow the instruction during connectivity issues or system downtime. More precisely, when a driver starts a charging transaction and the EVSE cannot connect to the internet, it will simply follow the existing instructions: the TxDefaultProfile.

This has both advantages and disadvantages. The main advantage is that every transaction will follow the same profile. But the main disadvantage is that this is pretty static and not ideal for most smart charging use cases in public charging or fleet charging.

For this reason, it’s often better to use the TxProfile.

What is the TxProfile?

TxProfiles are only valid for one specific EV charging transaction. This means that after a vehicle is plugged-in, the OCPP backend assigns a new transactionID. If the EVSE (charge point) has stored an old TxProfile, it will not use this profile. Instead, it will allow the maximum possible power for this charging session.

OCPP specification says: “If there is no transaction active on the connector specified in a charging profile of type TxProfile, then the Charge Point SHALL discard […]”

Important note: the TxProfile can only be sent to one specific connector, in contrast to the TxDefaultProfile which also allows you to set the connectorId = 0 and the TxProfile requires the connectorId > 0.

How does Ampcontrol use TxProfiles and TxDefaultProfiles?

‍

Here is the cool thing: OCPP defines: “If a transaction-specific profile with purpose TxProfile is present, it SHALL overrule the default charging profile with purpose TxDefaultProfile for the duration of the current transaction only. After the transaction is stopped, the profile SHOULD be deleted.”

Our engineers have identified the best combination of different profile types to use. For different situations and use cases, AmpControl can send different combinations of profiles.

Each profile is calculated individually in real-time and Ampcontrol doesn’t use any static, pre-defined charging profiles. This makes the technology unique and extremely reliable for offline use cases or when internet connections are malfunctioning.

If you would like to see a demo or ask us any questions, send us a message today using the contact form at https://www.ampcontrol.io/demo