Testing third-party integrations: commissioning a BMS high-level interface

A high-level interface, or HLI, is how the BMS talks to someone else’s system over comms instead of through wired signals: chillers, boilers, VRF, generators, meters, lighting and more. It’s also where a lot of commissioning time disappears, usually because nobody agreed in advance exactly what data would be exchanged.

Agree the points list first

Before any testing, both sides need to agree a point-by-point list covering:

• each point’s name and meaning
• whether it’s read or written
• the data type and units
• the protocol address: the BACnet object type and instance, or the Modbus register, function and data type
• the scaling, if any
• what it will be used for (display, alarm, control or trend)

Get it from the equipment supplier for the exact model and firmware, and put it in writing. Many integration arguments on site come down to someone working from an older points list.

Check the physical and network layer

Prove basic comms before worrying about points:

• IP-based devices. Check the address, mask, gateway, port and VLAN. Can you reach the device from the BMS controller?
• Serial devices. Check the baud rate, parity, stop bits, address, termination and biasing (see RS-485 and MS/TP wiring).
• Gateways. Find out what’s licensed and what’s configured, and whether the gateway is talking to the equipment on the far side.

Test every point

For each point on the list:

1. Read it and compare it with the equipment’s own display or a local measurement. Is the value right, in the right units?
2. Check the scaling. A chilled water temperature of 65 °C probably means a ×10 scaling has been missed. For Modbus specifics, including word order, see Modbus register offsets and word order.
3. Change the real condition where you can, and watch the value follow it, rather than just seeing a plausible number once.
4. Test writes. Change a setpoint or enable from the BMS and confirm the equipment actually responds, and that the value doesn’t get overwritten by the equipment’s local controls.
5. Test alarms. Trigger a fault or simulate one, and check it arrives at the BMS with meaningful text, not just a code.

Decide what happens when the link fails

This is the bit that often gets missed. Agree, and then test:

• On the BMS side. How quickly does it detect a lost link, and what alarm does it raise?
• On the equipment side. If the BMS stops writing, does the equipment keep the last value, fall back to a local setpoint, or stop? For a chiller enabled over comms, losing the link shouldn’t leave it running uncontrolled, or stopped with no alarm.
• Stale values. Make sure the BMS doesn’t keep displaying the last good reading as if it were live.

Pull the cable, or block the traffic, and watch what actually happens. It’s much better to find out during commissioning than during a heatwave.

Watch the polling load

Large integrations, such as hundreds of VRF indoor units or dozens of meters, can overload a gateway or a slow serial link if every point is polled every second. Poll fast-changing, control-critical points more often and slow-changing ones (run hours, totals) less often. Group Modbus registers sensibly so each request reads a useful block.

Write writes carefully

When the BMS writes to another system, especially over BACnet with priority arrays, be clear about:

• which priority level the BMS writes at
• whether anything else writes to the same point
• what releasing a write does, and whether the equipment then goes back to a sensible default

Points that two systems keep overwriting are a common cause of setpoints that “change by themselves”.

Record it

Keep the final points list, the test results and any quirks, such as “chiller ignores setpoint writes while in local mode”. That record is invaluable at the next firmware update, or when the next engineer arrives on site.