Building a BACnet Integration Acceptance Test Checklist

Acceptance is the last moment you have leverage. After it, every defect becomes a support request against a system somebody has already been paid for, and the ones that matter most, recovery after an outage, behaviour on restart, whether anything is quietly writing to the building, are precisely the ones a demonstration does not cover. The remedy is a test list agreed before the work starts, so that it shapes the build rather than judging it afterwards.

The message up front: a BACnet integration acceptance test has to cover five things a demonstration never does. That nothing is written to the building unless you intended it. That data survives an outage rather than leaving a hole. That restarts at either end recover without intervention. That the metadata, units, identifiers and mapping, is correct rather than merely present. And that the thing fails loudly when it fails. Agree the list at tender stage, attach it to a payment milestone, and require recorded evidence rather than a tick.

1. Before testing: what must already exist

Testing against undocumented systems produces opinions rather than results. Four documents first:

• The protocol implementation conformance statement for every device type, which is the manufacturer's declaration of what the device supports. It tells you which tests are even applicable.
• The completed points map, with structural identifiers, units, roles and collection mechanism per point, as set out in BACnet objects, device instances and addressing.
• The network topology: subnets, routers, trunks, device counts and which broadcast management device serves which subnet.
• The intended read and write scope, stated explicitly. An integration that is supposed to be read-only should say so in writing before anyone tests whether it is.

2. Prove it is read-only, if it is supposed to be

The most important test and the one almost never performed, because nobody imagines the integration would write anything.

• Inspect the priority array on a sample of commandable objects before the integration is connected, and again after it has been running. Any new entry is a write you did not expect. The mechanism is explained in the object model article, and an unintended write at a high priority will make the building ignore its own schedules indefinitely.
• Confirm no objects were put out of service by the integration or during its commissioning. A forgotten out-of-service object reports a simulated value forever.
• Where writes are intended, confirm the priority level matches what was agreed, that it is documented per point, and that a release is demonstrated: write, observe the plant respond, release, observe control return to the building's own logic.
• Check the credentials and access the integration uses are scoped to what it needs, which is the subject of securing read-only BACnet data access.

3. Data integrity tests

4. Resilience tests, which are the point of the exercise

Each of these takes minutes and each proves something no demonstration shows.

• Collector restart. Stop it, wait, start it. Confirm subscriptions re-establish, current values are read, and no duplicate rows appear. Detail in COV subscription recovery.
• Network interruption. Disconnect for a defined period, reconnect. Confirm the gap is detected and reported, and that buffered data arrives with device timestamps intact rather than being stamped on arrival. See store-and-forward buffering.
• Controller restart. Confirm the integration notices and recovers that device without anyone intervening.
• Out-of-order arrival. Confirm the destination accepts readings that arrive after newer ones, rather than rejecting or misordering them.
• Duplicate delivery. Force a re-read of buffered data and confirm no duplicates land.
• Loss detection. Leave one device disconnected and confirm something reports it within a defined period, rather than the interface continuing to display its last value. This is the test that fails most often.

5. Load and scale

• Read success rate per trunk over a representative period, including a busy one. Intermittent failures concentrated on one trunk indicate a load problem rather than device faults.
• Headroom check. Confirm the configured regime leaves capacity for growth, with the figure stated rather than asserted.
• Subscription count per device against its documented limit, including subscriptions held by other clients.
• Behaviour under sustained load, over at least a full daily cycle including any overnight batch activity, rather than a ten-minute sample.

6. What the evidence should look like

A signed checklist with ticks is not evidence. What to require:

• Recorded values, not confirmations. For comparison tests, the two values and the timestamp. For timing tests, the measured interval.
• Before and after states for anything that could have changed the building, particularly the priority array snapshots.
• The test date, the person, and the system versions. Evidence without a version is evidence about an unknown system.
• Exceptions listed explicitly, with what was not tested and why. An acceptance pack with no exceptions is usually an acceptance pack where the hard tests were skipped.
• The documents from section 1 as issued, so that what was tested and what was delivered can be compared later.

Attach the pack to a payment milestone or a retention release. Documentation without a commercial hook arrives late, incomplete, or not at all, which is the same lesson as in BMS service contracts.

7. The tests worth repeating later

Acceptance proves a moment. A few of these are worth re-running periodically, because the things they catch develop over time:

• Priority array inspection, annually. Writes accumulate from projects nobody told you about.
• Clock offset across devices, annually and after any network change.
• Coverage count, quarterly. Points stop arriving quietly.
• Loss detection, after any change to monitoring or networking, because this is the capability most easily broken by an unrelated change.
• Read success rate, continuously, as described in BMS ingestion monitoring.

The idea to walk away with

A demonstration proves that data can flow. An acceptance test proves that it keeps flowing, that it means what you think it means, that nothing is quietly writing to the building, and that you will be told when it stops. Those are different claims, and only the second set is worth paying for.

Agree the list before the work starts. Its real value is not in catching defects at the end; it is in telling the integrator at the beginning which behaviours will be checked, which changes how the thing gets built.

Final thoughts

If you have an integration already in service that was never tested this way, the two tests worth running retrospectively are the priority array inspection and the loss detection check. Between them they catch the two failure modes with the longest tail: a write nobody knows about, and a monitoring system that cannot report its own blindness.

Both take under an hour on a sample, and both occasionally find something that has been quietly true for years.

Related reading: BACnet objects and addressing, COV subscription recovery, Securing read-only BACnet access, Timestamps and clock synchronisation, Store-and-forward buffering, BMS service contracts.