Dynamic EV load balancing: inputs, rules, and test cases

Dynamic EV load balancing means the charging allocation can change as the conditions supplied to the controller change. That description is useful only when the property can name those conditions, explain how they become a decision, and show what the charger group is allowed to do. Without that chain, "dynamic" is only a label.

This guide helps a property team define the inputs, allocation rules, and commissioning tests that shape a dynamic load-balancing design for a multifamily site. It is not an electrical design, a capacity finding, a resident-service guarantee, or an instruction to change a live system. Required decisions remain with the responsible technical, utility, code, contractual, and operating parties.

What to take away

Design checklist

Start with the decision, not the display

The first question is not what a dashboard shows. It is what the system is permitted to decide. A dynamic controller may distribute a defined amount among active sessions, delay a lower-priority request, lower a session limit, or wait for a condition to clear.

The allowed action must be tied to a specific group and a specific source of authority.

Write a short decision statement before comparing equipment: "When the approved available amount changes, the controller may allocate it among the named stations according to the current rule." Add the data source, update interval, and fallback state. It makes the rule clear enough for the responsible parties to review.

For a U.S. installation, the electrical basis starts with the locally adopted National Electrical Code (NEC) and the authority having jurisdiction (AHJ). NEC Article 625 covers electric vehicle power transfer equipment; the project’s electrical designer should identify the applicable provisions and code edition.

For existing service, NEC 220.87 provides an optional method for determining existing load when its conditions are met; it is not a blanket capacity allowance. Have the electrical designer document the applicable load calculation and approved capacity, then set the charger-group limit from that review. Dynamic control does not replace the capacity review.

Build an input register

For each input, record four things: what it represents, where it comes from, how often it should update, and what the controller does when it is late or missing. Possible inputs include a reviewed available amount, group membership, session status, a schedule, or a disclosed preference.

The system should not silently treat a missing value as valid.

An input register creates a useful divide between facts and assumptions. A meter reading is not the same as a forecast. A resident-entered time is not the same as a verified operational requirement. Label each input accurately so it receives the right level of trust and review.

A filled sample row for a typical apartment group:

Choose a priority rule residents can understand

A property does not need to expose the internal logic in every resident notice, but it should be able to state the service rule honestly. Possible approaches include equal sharing among eligible sessions, a documented priority category, or a schedule-based sequence. The selection depends on the approved service model and technical review.

Worked example: Four eligible sessions share a 32 A group limit. Each gets 8 A. If one session ends, the three remaining sessions each get 10.67 A. If a measured input goes stale, the controller holds the last valid 8 A share for 60 seconds, then suspends new allocations and alerts support.

Avoid mixing incompatible rules without explanation. For example, equal sharing and priority treatment can coexist only if the plan defines when each applies. A human operator should be able to answer a simple question: "What changes the order or allocation?" If that answer is vague, the rule is not ready for resident-facing language.

Use a version number or date for the rule. A rule change may affect resident expectations even when the charger hardware has not changed. Keep the former version, the reason for the change, the approving party, and the test result with the record.

Decide how often the system may react

Dynamic does not necessarily mean instantaneous. Rapid changes can create confusing behavior, while a slow response can make an input irrelevant. Set the expected update or evaluation interval based on the design and operating context. Then define how the system avoids excessive toggling, how it handles delayed data, and who reviews unusual patterns.

Choose the evaluation interval based on the design, data path, and operating context. Specify how long a changed condition must persist before the allocation changes, how the system avoids excessive toggling, and what happens when data is delayed.

The test should observe the time dimension. A valid result is not simply that a new setting eventually appeared. The evidence should show the relevant condition, the decision time, the affected assets, the observed response, and the state after recovery. That allows later reviewers to distinguish a planned delay from a communications problem.

For a networked system, name the communications protocol and supported version in the specification, such as OCPP 1.6J or OCPP 2.0.1. Confirm that the charger and management software support the required functions; OCPP does not itself establish site capacity or allocation limits.

Separate allocation from capacity claims

Balancing divides something that is already defined for a group. It does not prove that the underlying amount is correct for an installation, nor does it grant authority to expand a group. A property should not tell residents that dynamic balancing guarantees unlimited access, eliminates the need for approval, or makes an unreviewed upgrade unnecessary.

Keep the words precise. "The system applies the current approved allocation rule to the listed stations" is a process statement. "The property has unlimited capacity" is a broad factual claim that requires different evidence and may be incorrect. The first can be supported by operating records. The second cannot be inferred from a dashboard.

Design a conservative bad-data response

Every input should have a defined stale-data or unavailable-data response. The site may need a project-specific conservative setting, suspension of new allocations, a manual procedure, or another approved response. The correct behavior depends on the design. The required planning step is to make the response visible before an incident.

Create a simple decision table and give it to the support team. It should not require them to diagnose electrical conditions. It should tell them what facts to collect, which team receives the issue, what resident message is approved, and what evidence is needed before normal operation is confirmed.

Confirm required safety listings with the electrical designer and AHJ. Ask whether equipment listed under UL 3141 or UL 916 is applicable to the intended use; do not assume either standard applies to every component or system.

Commission the behavior under different conditions

Commissioning a dynamic allocation system is a test of behavior, not only connectivity. Build cases around the actual rule: one normal group state, one condition that prompts a different allocation, one late or missing input, and one recovery. If a user preference or schedule is part of the rule, use a safe representative case approved for testing.

Record the input values and their source, the rule version, expected result, observed result, time window, assets involved, and person who reviewed the result. Do not treat a screen capture as complete proof unless it identifies the relevant data and state. A later team must be able to understand why the observed result was accepted.

Worked case: Three sessions active, available group current 24 A, update interval 15 s. Expected equal share of 8 A each. Observed: 8.0 A on all three within 20 s. Accepted.

Create an operating handoff that survives staff change

Dynamic systems can become hard to support when the only explanation lives with an installer, a software administrator, or a former manager. The handoff should include the input register, priority rule, station group, current contacts, escalation route, setting owner, test record, and change process.

Limit the turnover packet to current information and controlled references. It need not contain private account data or every historical message. It should, however, let an incoming team identify the current rule, ask the right questions, and reach the people responsible for technical decisions.

Keep resident communication direct

Resident guidance should tell people where to charge, how the approved service rule affects access if relevant, how to report a concern, and what information helps support investigate. It should not promise a session rate, departure result, or technical outcome that the property cannot verify.

Ask for a station identifier, date and time, visible message, and contact method. Preserve that report as an incident fact. Let the responsible technical team interpret control logs and equipment conditions before a diagnosis is given to the resident.

Before procurement, obtain project-specific quotes for equipment, installation, software or per-port fees, service upgrades, utility charges, and billing. Decide whether the owner or HOA, residents, or charging users through per-kWh billing will pay each cost. Ask the serving utility to identify applicable EV programs, tariffs, service-upgrade requirements, and approval steps, then record the applicable program or tariff by name. For tax-credit eligibility, confirm whether the Alternative Fuel Vehicle Refueling Property Credit applies to the installation and whether Schedule A (Form 8911) must be filed.

Common questions

The items below address the decisions a multifamily team most often revisits after a dynamic allocation system goes live.

Does dynamic balancing give every session the same power?

Not necessarily. The outcome depends on the approved allocation rule and the inputs it receives. A property should state its service rule in clear language rather than implying universal equal treatment.

Can an allocation rule be changed from a dashboard?

The ability to change a setting is not the same as authority to change it. Use the documented approval, implementation, test, and record process for any material change.

What is the most useful first document for a new operator?

Start with the input register and one-page rule summary. They show what drives a decision, which stations are involved, who owns the setting, and how a problem is escalated.