Why most OCPP deployments leave smart charging unused
Open Charge Point Protocol (OCPP) has been the dominant communication standard between charge points and central management systems (CPMS) since around 2015. The version most widely deployed in European fleet depots today is OCPP 1.6, with OCPP 2.0.1 adoption accelerating for new hardware installations from 2023 onwards. Both versions include a Smart Charging specification — a set of messages and data structures that enable a CPMS or upstream energy management system to control how much power each charge point delivers, on what schedule, and under what conditions.
Despite being part of the standard, smart charging functionality is systematically under-implemented. A survey of common CPMS deployments reveals that the majority use only the basic transaction flow: BootNotification, Authorize, StartTransaction, StopTransaction, StatusNotification, MeterValues. The entire SetChargingProfile / ClearChargingProfile / GetCompositeSchedule message family goes unused, not because the hardware doesn't support it — most modern AC charge points do — but because the CPMS has no logic to generate meaningful profiles and no energy management backend to tell it what the profiles should contain.
This gap between hardware capability and deployed functionality is where fleet charging optimisation lives. Understanding the OCPP charging profile model is the prerequisite for closing it.
The three charging profile purposes and when to use each
OCPP 1.6 and 2.0.1 define three chargingProfilePurpose values. They form a hierarchy: higher-purpose profiles can override lower-purpose ones at the same or lower stackLevel.
ChargePointMaxProfile
ChargePointMaxProfile sets an absolute power ceiling for the entire charge point (all connectors combined). This profile purpose is used to implement site-wide transformer limit enforcement. When the energy management system determines that the depot can only deliver 200 kW total to the EV sub-panel, it sends a ChargePointMaxProfile that limits each charge point's contribution accordingly. This profile is not connector-specific and cannot be overridden by lower-level profiles — it is the top of the hierarchy. In OCPP terms, it is set via SetChargingProfile.req with chargingProfilePurpose: ChargePointMaxProfile targeting the charge point ID, not a specific connector.
TxDefaultProfile
TxDefaultProfile defines the charging behaviour that applies to any transaction that doesn't have a transaction-specific (TxProfile) override. It is the workhorse profile for fleet scheduling: the energy management system uploads a 24-hour ChargingSchedule to each charge point specifying the current limit (in Amps or Watts, depending on chargingRateUnit) for each 15-minute interval. When a vehicle connects, the charge point immediately applies the applicable interval from the default profile without waiting for any further instruction from the CPMS. This means the smart charging schedule is enforced even if the CPMS loses connectivity after pushing the profile — a critical reliability property for overnight depot charging.
The typical structure of a TxDefaultProfile for overnight fleet charging:
{
"chargingProfileId": 42,
"stackLevel": 1,
"chargingProfilePurpose": "TxDefaultProfile",
"chargingProfileKind": "Absolute",
"validFrom": "2026-01-28T17:00:00Z",
"validTo": "2026-01-29T07:00:00Z",
"chargingSchedule": {
"duration": 50400,
"startSchedule": "2026-01-28T17:00:00Z",
"chargingRateUnit": "A",
"chargingSchedulePeriod": [
{ "startPeriod": 0, "limit": 6 },
{ "startPeriod": 18000, "limit": 32 },
{ "startPeriod": 39600, "limit": 16 },
{ "startPeriod": 46800, "limit": 32 }
]
}
}In this example: 6A (minimal) from 17:00 to 22:00 (peak demand window), 32A (maximum, ~22 kW on 3-phase) from 22:00 to 04:00 (cheap tariff window), 16A (medium) from 04:00 to 06:00 (topping off phase), 32A from 06:00 to 07:00 (emergency top-off for late connectors).
TxProfile
TxProfile applies to a specific active transaction, identified by transactionId. It overrides the applicable TxDefaultProfile for the duration of that transaction. The primary use case for TxProfile in fleet contexts is per-vehicle emergency override: if a vehicle arrives with a critically low SoC that the TxDefaultProfile schedule cannot recover by departure time, the scheduler can push a TxProfile that allocates maximum current to that vehicle immediately, overriding the default overnight schedule for that specific session only. This allows the fleet manager to guarantee departure readiness for the occasional vehicle that arrives in an unexpected state without disrupting the cost-optimised schedule for the rest of the fleet.
The stackLevel mechanism and profile conflicts
The stackLevel field determines precedence when multiple profiles of the same chargingProfilePurpose overlap in time. Higher stackLevel values take precedence. This is important for deploying multi-source constraints: a CPMS might set a TxDefaultProfile at stackLevel 0 for tariff optimisation, while the energy management system uses stackLevel 1 to push real-time transformer limit overrides that take precedence when grid conditions change. The charge point applies the schedule from the highest-stackLevel profile whose validity window covers the current time.
In OCPP 2.0.1, the profile model is extended and renamed: ChargingProfilePurpose values include ChargingStationMaxProfile (the OCPP 2.0.1 equivalent of ChargePointMaxProfile), TxDefaultProfile, and TxProfile, broadly preserving the same semantics. OCPP 2.0.1 also adds Smart Charging extensions including local controller mode, absolute vs. recurring schedule kinds, and improved support for bidirectional (V2G/V2B) setpoints expressed as negative current limits.
We're not saying that implementing the full OCPP smart charging specification is necessary for every deployment. For a fleet of fewer than 20 vehicles with a simple overnight charging window and a flat TOU tariff, a static TxDefaultProfile that limits current during peak hours and maximises it overnight may be sufficient. The complexity of dynamic profile updates, intraday re-optimisation, and per-vehicle TxProfile overrides becomes necessary when the fleet is larger, the tariff structure is more granular, or the departure schedule has significant variance.
Common implementation failures and how to avoid them
Several failure modes appear repeatedly in OCPP smart charging deployments that were implemented without a clear understanding of the profile model:
Profile not persisted across charge point reboot. OCPP 1.6 specifies that charge points should persist profiles across reboots, but this is a "SHOULD" recommendation, not a "MUST". Several charge point firmware versions do not persist TxDefaultProfile across firmware updates or power cycles. A fleet that relies on profiles set months ago and never re-validates them is running without active smart charging after the first firmware update. Profiles should be re-pushed after any charge point reboot or firmware update event, triggered by the BootNotification message.
Incorrect chargingRateUnit. OCPP allows profiles to specify limits in Amps (A) or Watts (W). Some charge point firmware implementations interpret Amp limits as per-phase rather than per-connector, others as total connector current. For 3-phase AC chargers, specifying 32A in a profile that the firmware interprets as per-phase delivers 3 × 32A × 230V = 22 kW, while a firmware that interprets it as total-connector current delivers 32A / 3 × 230V = 2.5 kW — an 8.8× difference that will result in vehicles charging far too slowly for departure readiness. Always validate the firmware's interpretation with a known-good test session before deploying fleet-wide profiles.
NumberPhases mismatch. OCPP 1.6 includes a NumberPhases field in ChargingSchedulePeriod that can restrict charging to 1 or 3 phases. Some firmware treats an absent NumberPhases field as "1 phase", dramatically under-delivering power. Explicitly set NumberPhases: 3 for all 3-phase AC charger profiles to avoid this ambiguity.
Profile overlap causing unexpected current reduction. If multiple profiles are active with overlapping validity windows at different stackLevel values, the charge point applies the highest-stackLevel matching profile. A stale high-stackLevel profile from a previous month that wasn't cleared via ClearChargingProfile.req can silently reduce all charging to its limit values, with no visible error in the CPMS. Regular profile audit via GetChargingProfiles.req (OCPP 2.0.1) or equivalent is good practice.
Testing smart charging profile compliance before fleet deployment
The OCPP Alliance maintains a compliance test specification for Smart Charging (SC) functionality, identifying specific test cases for SetChargingProfile, ClearChargingProfile, GetCompositeSchedule, and related flows. Before deploying a new charge point model into a fleet that depends on smart charging profiles, operators should verify compliance with at minimum: SC-01 through SC-10 (basic profile set/clear/retrieve), and the composite schedule test cases that validate how the charge point resolves profile conflicts at runtime.
The practical approach for a depot deploying a new charge point model alongside existing hardware is to run a parallel test: connect one unit of the new model, push a TxDefaultProfile with a distinctive limit pattern, connect a test vehicle, and verify that the OCPP MeterValues messages reflect the limit from the profile — not the charger's default maximum — within 30 seconds of session start. This takes 20 minutes and catches the most common firmware non-conformances before they affect an entire fleet deployment.