Protocols · Integration
Protocol Integration Checklist for Building Automation
A phase-by-phase checklist for protocol integration: inventory, point list, mapping, testing, failure behaviour and handover.
Quick answer
A protocol integration checklist covers the system inventory, interface audit, point list, address and object maps, read and write rights, failure behaviour, testing and handover. It should be agreed before design and signed at commissioning. The checklist is what turns a collection of gateways into a documented, maintainable interface that another engineer can diagnose.
Before design: inventory and ownership
Start with a system inventory: equipment, protocol, firmware, interface, point count and the party responsible for each interface. Then build an ownership matrix. Who supplies the gateway? Who configures it? Who owns the point list? Who may write to a setpoint? Who tests the failure path? These questions sound administrative until a plant item trips and two vendors disagree about who owns the signal. The audit should also record what is not available: a controller with no protocol documentation, a meter with a proprietary port, a BMS that will not release its points. The inventory is also the scope boundary; anything not on it should be added deliberately, with its interface cost. Record that gap in writing.
- List every system, protocol and firmware version
- Assign one owner to every interface
- Record what documentation is missing
During engineering: maps and naming
Translate the inventory into engineering documents: a point list with a unique name, unit, range, direction and failure state; an address schedule for buses and gateways; an object or register map for each protocol; and a network drawing. Agree the naming convention early. A point called AI-17 is not a point; a point called AHU-01 Supply Air Temperature is. Define time synchronisation, units, scaling and alarm mapping. If two systems can write the same value, decide the priority and document it. These documents are the contract between the trades. A naming convention is not cosmetic; it is the address book that makes alarms, trends and graphics agree, and it should be enforced in review.
- Use building-based names, not terminal numbers
- Define units, scaling and time sync
- Document priority where two systems can write
Commissioning: prove every direction
Test each point in both directions where applicable: read the value, write the command, read it back, release it and confirm the fallback. Pull a communication cable and record the resulting state. Reboot the gateway and confirm recovery. Check that alarms arrive once, with the right priority, and that they clear. Verify trend intervals and time stamps. Measure the update latency for points used in interlocks. A screenshot of a green dashboard proves very little; a signed test sheet with the failure cases proves the interface. Record who witnessed each test and which firmware was running; an integration result without that context is hard to reproduce and harder to defend.
- Test read, write, release and fallback
- Record the state after cable loss and reboot
- Measure latency for interlocked points
Handover: make it maintainable
Hand over the point list, address maps, network diagram, gateway configurations, firmware versions, credentials, licences and test records. Record spare capacity: free points, free addresses and spare gateway ports. Train the owner's team on the diagnostics, not only the dashboard. Agree who supports each interface and how a change is requested. A good handover lets a new engineer trace a faulty value from the screen to the field device without calling three vendors. That is the real deliverable of protocol integration. The final test is a short diagnostic exercise with the owner's team: give them a faulty value and see whether they can trace it to the field device without calling three vendors.
- Hand over maps, configurations and licences
- Record spare points, addresses and ports
- Train diagnostics, not just dashboards
Integration checklist by phase
7 rows| Phase | Artifact | Acceptance test |
|---|---|---|
| Inventory | System and protocol register | Every system has an owner and an interface |
| Interface audit | Responsibility matrix | Gateway supply and configuration agreed |
| Point list | Named points with units and direction | Reviewed against sequences and graphics |
| Protocol mapping | Object, register or group-address schedule | Spot-check against live devices |
| Network design | VLAN, addressing and routing drawing | Connectivity and segmentation verified |
| Commissioning | Signed point and sequence tests | Read, write, fault and recovery proven |
| Handover | As-builts, backups and credentials | Restore and diagnostic walkthrough complete |
Project images
3 images
Frequently asked
01What is a point list?
A schedule of every signal the system reads or writes, with its name, unit, range, direction and failure state. It is the backbone of integration.
02Who owns the gateway?
The party responsible for the interface, as recorded in the responsibility matrix. Ownership should include configuration, backup and firmware.
03How do we test an integration?
Read, write, release, fault and recover. Test the failure path as carefully as the normal path, and record the result.
04How much spare capacity should we keep?
Enough to cover the changes expected after handover. State it in the point list and the gateway schedule rather than leaving it to chance.
05What if a vendor will not provide protocol documentation?
Treat it as a scope risk. Either exclude the system, require a documented interface as a condition, or budget for reverse engineering with the owner's consent.
Next step
Bring us the building.
Tell us the building type, systems in scope and the outcome you need. We will map the shortest path to a working system.