Smart charging is a deployment decision, not only a protocol feature
The OCPP profile model is useful, but deployers should start with a more practical question:
What system is allowed to decide site power, and what happens when charger behavior does not match the plan?
That drives the real deployment work:
- whether the site cap lives in the charger, the backend, or an external EMS
- how priorities are resolved when sessions compete
- what telemetry delay you can tolerate
- what fallback applies when communications fail
- how much variance different charger vendors introduce
If those rules are unclear, smart charging projects become hard to debug and even harder to trust commercially.
Why smart charging matters
A single DC fast charger can draw 150-350 kW. A parking garage with 20 AC chargers at 22 kW each needs 440 kW. Most commercial buildings have nowhere near enough electrical capacity to support every charger running at full power simultaneously.
Smart charging solves this by dynamically distributing available power across active sessions.
OCPP charging profile types
OCPP defines three types of charging profiles, each operating at a different scope.
ChargingStationMaxProfile
Sets the maximum power for the entire charging station. Think of it as the "circuit breaker" — no combination of sessions can exceed this limit.
Use case: Your building has a 200 kW grid connection. Set ChargingStationMaxProfile to 200 kW. The station firmware ensures total power draw never exceeds this.
TxDefaultProfile
The default charging profile applied to all new transactions on a specific EVSE. If no transaction-specific profile is set, this is what applies.
Use case: Set a default 7 kW limit on all connectors during business hours (09:00-18:00) to ensure building loads aren't affected. Outside business hours, set it to 22 kW.
TxProfile
A profile applied to a specific, active transaction. Overrides the TxDefaultProfile for that session only.
Use case: A fleet vehicle needs to be fully charged by 6 AM. Set a TxProfile that prioritizes this session with higher power allocation.
Profile scheduling
Charging profiles aren't just static limits — they're schedules. A single profile contains a sequence of time-based periods, each with its own power limit.
Profile: "Office Hours Load Management"
Stack Level: 1
Purpose: TxDefaultProfile
Schedule:
Period 1: 09:00 - 12:00 → 7.4 kW limit
Period 2: 12:00 - 14:00 → 11 kW limit (lunch = less building load)
Period 3: 14:00 - 18:00 → 7.4 kW limit
Period 4: 18:00 - 09:00 → 22 kW limit (building empty)Stack levels
What happens when multiple profiles apply to the same session? OCPP uses stack levels to resolve conflicts.
Higher stack levels take priority. A TxProfile at stack level 2 overrides a TxDefaultProfile at stack level 1, but only for that specific transaction.
Think of it as CSS specificity for charging power:
- ChargingStationMaxProfile (highest priority — absolute cap)
- TxProfile (transaction-specific override)
- TxDefaultProfile (default for the EVSE)
The effective limit is the minimum of all applicable profiles. If the station max is 100 kW and the transaction profile says 50 kW, the session gets 50 kW.
Load management strategies
Static load management
Set fixed limits based on known constraints. Simple but inflexible.
Example: 10 EVSEs, 100 kW grid connection. Set ChargingStationMaxProfile to 100 kW. Each EVSE gets a TxDefaultProfile of 10 kW.
Equal distribution
Divide available power equally among active sessions. As sessions start and end, recalculate.
Example: 100 kW available. 2 active sessions = 50 kW each. Third car plugs in = 33 kW each.
First-come, first-served
Early sessions get maximum power. Later sessions get whatever remains.
Example: 100 kW available. First car gets 50 kW. Second car gets 50 kW. Third car gets 0 kW (queued until capacity frees up).
Priority-based
Assign priorities based on user type, departure time, or business rules.
Example: Fleet vehicles (priority 1) get 22 kW. Employee vehicles (priority 2) get 11 kW. Visitor vehicles (priority 3) get 7 kW.
Dynamic optimization
Integrate with real-time signals: building energy management, solar production, grid tariffs, vehicle battery state.
Example: Solar panels producing 30 kW surplus → increase charging limits. Grid price spikes → reduce to minimum. Fleet vehicle leaving in 1 hour → boost to maximum.
OCPP 2.0.1 smart charging improvements
OCPP 2.0.1 adds several smart charging capabilities over 1.6:
- NotifyEVChargingNeeds — the charger reports what the vehicle actually needs (energy, departure time), enabling optimal scheduling
- ClearedChargingLimit — signals when an external constraint is lifted
- ReportChargingProfiles — query active profiles from the charger
- Cost-based optimization — communicate energy prices so the charger can optimize locally
Minimum acceptance tests before production
Before launch, test more than "profile accepted":
- Site cap enforcement Validate that total station draw respects the upstream limit during simultaneous sessions.
- Priority behavior Confirm that high-priority sessions actually receive the intended allocation under contention.
- Fallback mode Disconnect the backend or degrade connectivity and verify what limits remain enforced locally.
- Mixed hardware behavior Compare identical profiles across charger vendors and firmware versions to expose interpretation differences.
- Schedule transitions Test hour changes, tariff windows, and overnight schedules so the profile logic behaves correctly at boundaries.
- Telemetry reconciliation Compare commanded limits to actual power draw and meter values so operations can see whether the control loop is working.
If you do not have those six tests, you do not yet have a production-grade smart charging rollout.
Questions to force into charger and platform evaluation
Ask vendors and internal teams:
- Where does the authoritative site limit live?
- What happens when a charger accepts a profile but does not enforce it accurately?
- How are conflicting profiles debugged in production?
- Which parts of the logic run locally on the charger versus centrally in the backend?
- How do you handle mixed 1.6 and 2.0.1 fleets in one energy policy?
- What is the rollback plan if a smart charging policy destabilizes a live site?
How EV Cloud handles smart charging
EV Cloud provides a smart charging engine that integrates with your OCPP chargers:
- Visual profile editor — create and schedule charging profiles from the dashboard
- Automatic load balancing — equal distribution with configurable priorities
- API-driven — set profiles programmatically based on external signals (building EMS, solar inverters, grid APIs)
- Real-time monitoring — see active profiles and actual power draw per session
- Both OCPP versions — works with 1.6 SetChargingProfile and 2.0.1's enhanced model
Next step for rollout teams
If smart charging is part of your deployment plan, continue with:
- OCPP 2.0.1 deep dive for protocol differences that affect rollout.
- OCPP platform buyer guide if profile control quality matters in vendor selection.
- Talk to EV Cloud if you need help shaping site-cap logic, fallback rules, or mixed-fleet rollout.
