Guides
Part of Automatic EV load management: a five-box map and commissioning tests
Automatic EV load management: questions before you buy
Automatic EV load management questions to settle before you buy: control boundary, CT inputs, OCPP version, NEC 625.42 path, fallback and setting owners.
To compare automatic EV load management options, compare the working system rather than a feature checklist. Two products can both advertise load management while using different inputs, control boundaries, administration paths, and recovery behavior. Those differences affect whether a team can operate and support the result.
What to take away
- Compare inputs and actions before comparing dashboards.
- Name the control approachpanel or circuit level, service or feeder level — before ranking options.
- Ask what is local, what depends on a service, and what happens when a dependency fails.
- Require each option to name its setting owner, its code path, and its test evidence.
- Do not score a system on promises that are outside the approved site design.
Compare the actual control path
List the condition each option receives, the service or device that interprets it, the action it may send, and the feedback it retains. This reveals whether a proposal can explain its behavior without relying on a product label.
Control Path Comparison
Option A
- Managed boundary
- Named electrical point
- Input source
- Device/service, freshness
- Permitted action
- Exact action, conditions
- Fallback
- Approved state, owner
- Evidence
- Test, event record
Option B
- Managed boundary
- Named electrical point
- Input source
- Device/service, freshness
- Permitted action
- Exact action, conditions
- Fallback
- Approved state, owner
- Evidence
- Test, event record
The control approaches you will actually compare
Automatic EV load management is not one thing. A panel-level or service-level electric vehicle energy management system (EVEMS) watches the whole service with current transformers (CTs) and lowers or pauses charging so the total stays under the service rating. Circuit-level or feeder-level control does the same for one branch circuit or a defined group of chargers. Within either approach, some systems reduce the current each vehicle may draw through the SAE J1772 control pilot, while others switch ports on and off. Hardwired and plug-in chargers also compare differently, because the connector changes what the device is permitted to do.
Where the two approaches part ways:
- Panel- or service-level controlreads the whole building load at the service, so chargers can use whatever capacity the rest of the building is not using at that moment. The price is reach: the CTs sit at the main service equipment, and a failed reading affects every managed charger at once.
- Circuit- or feeder-level controlonly sees the chargers on its own branch circuit or feeder. It cannot borrow unused building capacity, so it holds the group to the limit set for that circuit. The upside is a smaller boundary: a lost reading or a wrong setting affects one charger group rather than every managed charger in the building.
A comparison that ignores standards cannot predict interoperability. OCPP is the charger-to-backend language, and the version matters: OCPP 2.0.1 Edition 3 was accepted as IEC standard 63584 in late 2024, while OCPP 1.6 remains common in installed hardware. OpenADR 2.0b is the utility demand-response signal used in many managed-charging programs, and IEEE 2030.5 is the smart-energy profile some utilities use for grid coordination. On the equipment side, UL 916 covers energy management equipment, and UL 2231-1 and UL 2231-2 cover the personnel protection system for EV supply circuits.
The code path is not optional
NEC Article 625 covers electric vehicle power transfer, and Section 625.42 addresses energy management systems that limit the load charging places on the service. The authority having jurisdiction (AHJ) reviews that approach at permit and again at inspection, and the utility may add its own metering or interconnection requirement. Ask each option which code section and listing its control relies on, and keep the permit, the inspection sign-off, and the utility approval next to the comparison sheet.
The sheet below is a blank template: fill one column per shortlisted option with the vendor's written answer.
Option A response
- Managed boundary
- Named electrical point
- Input source
- Device or service and freshness
- Permitted action
- Exact action and conditions
- Fallback
- Approved state and owner
- Evidence
- Test and event record
Option B response
- Managed boundary
- Named electrical point
- Input source
- Device or service and freshness
- Permitted action
- Exact action and conditions
- Fallback
- Approved state and owner
- Evidence
- Test and event record
Check dependencies and ownership
Ask which parts keep working if a network, gateway, account, meter, or provider service is unavailable. Then ask who owns credentials, receives alarms, makes setting changes, and handles a resident report. A strong proposal answers both questions without implying that software alone replaces electrical review.
The Joint Office's software interoperability resource describes why charging equipment, backend systems, and data exchanges need to work together. For a property comparison, that means documenting each connection that the selected automatic action relies on, including the account or service responsible for it. Interoperability is not proof that a given site configuration will behave as intended.
Compare the operating burden
An option with more automatic behavior may also need more administration. Put training, access management, alert review, support escalation, configuration control, and evidence retention on the comparison sheet. This is not an argument for a simpler system. It is a way to expose work that an equipment quote might not state.
Cost structure belongs on the same sheet, even when no two quotes line up directly. Ask each option to separate equipment and installation from network or software subscription, per-port service fees, and any utility make-ready work or rebate the property is expected to claim. Seeing which lines recur and which are one-time is often more useful than a single total.
Incentive rules can also favor one control approach. In New York, the Public Service Commission's August 19, 2024, Order Establishing Load Management Technology Incentive Programs (Case 22-E-0236) approved the Joint Utilities' Load Management Technology Incentive Program (LMTIP) with modifications. The program provides incentives for eligible technologies such as on-site energy storage, energy storage integrated into charging equipment, and other advanced load management software and equipment. Central Hudson's implementation plan adds that eligible technologies must be configured for load management as the primary use case. If a property expects such an incentive, ask each option which technology segment it would fall under.
| Operating question | Evidence to request |
|---|---|
| Who changes a rule? | Authorized role, approval route, and change record |
| Who sees an alert? | Current contact route and example notification |
| What happens if data is absent? | Documented fallback behavior and recovery test |
| What can staff tell a driver? | Resident message tied to the active service rule |
| What proves the outcome? | Accepted scenario record with open items noted |
Vendor answers worth writing down
Push past the feature grid and ask for answers you can compare on one sheet:
- Which control boundary does it managethe whole service, a feeder, or one branch circuit?
- Which OCPP version does the charger and backend support (1.6 or 2.0.1)?
- What is the minimum current the system can hold per vehicle?
- How many ports does one controller manage?
- How quickly does a setting change or an alert arrive?
- Is an API available for reporting?
- What is the uptime commitment, and which cyber-security requirements must the property meet?
Answers in writing can be attached to the comparison; verbal promises cannot.
Use the same acceptance cases
Compare options against the same project-defined cases: normal operation, a managed condition, a documented fault or loss of communication, recovery, and a settings change. Record what was observed, not only whether a test was marked complete. This creates a fairer comparison than a long list of untested functions.
The General Services Administration's EVSE ordering guide includes testing, acceptance, and documentation activities in its charging-equipment ordering process. The guide does not choose a product for an apartment property, but it supports comparing options on the evidence that will exist at handoff, not just their claimed functions.
A useful final decision note
- State the chosen option and the exact operating boundary it covers.
- Attach the conditions and dependencies the selection assumes.
- Name the person who owns the setting, support route, and acceptance evidence.
- List unresolved questions that must be answered before activation.
- Set the next review trigger, such as a system, policy, or account change.
Common questions
Is a cloud connection always a disadvantage?
No. The useful question is what the connection supports, what occurs when it is unavailable, and whether the fallback and support responsibilities are documented.
Which approaches should I shortlist?
At minimum, one panel- or service-level system and one circuit-level or feeder-level system, each described with its own inputs, permitted actions, and fallback behavior. Comparing both shows whether the property needs service-wide control or can answer the load question at the branch circuit.
Can a comparison select the final design?
No. It organizes operating questions. Technical design, approvals, and configuration remain the responsibility of the appropriate parties.
What is the most useful comparison artifact?
A one-page signal-to-action table with dependencies, named owners, fallback behavior, and acceptance evidence is usually more useful than a marketing feature grid.
