Connecting charging to a building management system is frequently requested and rarely specified beyond the word integration. The two worlds have different conventions, and the gaps between them are where the problems sit.
The question worth answering first is what the integration is actually for, because the answer determines how much of it is needed.
Establish the purpose
Visibility and reporting are straightforward. Load coordination is a control relationship with safety implications and deserves considerably more care.
- Visibility only: charging status appears alongside other building systems.
- Load coordination: the building system constrains charging to protect the supply.
- Scheduling: charging follows building occupancy or tariff periods.
- Reporting: charging energy appears in building consumption records.
Who holds the supply constraint
If the building system is to limit charging, it becomes responsible for keeping the site within its supply, and the charging system becomes subordinate. That is workable and it must be explicit.
Where both believe they are managing the constraint, the site is protected by neither in the moment it matters. This is the most consequential thing to settle in the integration.
Failure behaviour must be defined in both directions
If the building system becomes unreachable, charging must fall back to a limit safe on its own rather than to full rate. If charging becomes unreachable, the building system must not assume the load has disappeared.
Both directions are usually specified in neither system, and the resulting behaviour is whatever the defaults happen to be.
Timescale mismatch
Building systems commonly operate on intervals suited to thermal processes. Charging load changes far faster than that, and a control loop running on a slow interval will respond to conditions that have already passed.
Where fast response is needed, the charging system should hold local control within a budget the building system sets slowly, rather than the building system controlling directly.
Protocol translation
Building systems and charging platforms rarely speak the same protocol natively, so a translation layer exists somewhere. That layer is a component with its own availability and its own failure modes, and it needs an owner.
It is also where semantics get lost: a status that means one thing in charging may map onto a building alarm that means something else, generating alerts nobody can act on.
Alarm discipline
Charging generates events that are normal in charging and look like faults in a building context: a vehicle stopping, a session ending, a brief disconnection. Passing them through unfiltered trains building operators to ignore charging alarms.
Deciding which events genuinely warrant a building-level alarm, and suppressing the rest, is what makes the integration useful rather than noisy.