Protocol integration
BACnet Integration
How BACnet/IP devices, objects and services are discovered, mapped, written and tested when plant equipment joins a building platform.
What BACnet is used for
BACnet is a common open protocol in plant rooms. Chillers, boilers, AHUs, VAV boxes, energy meters and building controllers expose their data as BACnet objects. BACnet/IP runs over Ethernet; BACnet MS/TP runs over a serial bus. The protocol defines object types, properties and services, so a third party can read a temperature or write a setpoint without the manufacturer's software. That is the theory. In practice, the quality of the integration depends on how completely each device implements the standard. Two devices with the same object type may support different services, different properties and different performance. The audit exists to find those differences before the point schedule is fixed. Protocol reference: MS/TP segments run from 9.6 to 76.8 kbit/s, and the slower the segment, the more polling discipline matters. BACnet/IP uses the building network, so IP addressing and broadcast domains become part of the controls design. The audit should include a sample read and a sample write, not only a document review.
- Chillers, boilers and central plant
- AHUs, VAV boxes and fan-coil controllers
- Energy meters and power monitoring
- BMS and DDC controllers from other vendors
Discovery, object mapping and point naming
Start with a network survey: device instances, network numbers, IP addresses, BBMD settings and routing. Then browse each device and export its objects. The mapping record should carry the object name, type, instance, present value, unit, resolution, read/write rights and the platform point it feeds. Watch for vendor objects: a manufacturer may expose a critical status only through a proprietary property. Agree the mapping in a spreadsheet before configuration, and keep the object instance visible in the point name so that field support can trace it. Naming should follow the building standard, not the device default. The object export and the point schedule should be compared line by line; a missing object is easier to find now than during commissioning. Count points by object property, not by device: one controller can expose hundreds of objects, most of them irrelevant. Mark each point as monitored, commanded, alarmed or trended, because each role needs a different test. Where two objects represent the same value, choose one as the master and document the other as derived.
- Device instance and network number
- Object type, instance and property
- Read/write rights and priority
- Vendor-specific objects flagged early
- Point role: monitor, command, alarm, trend
Writes, priority and alarms
BACnet writes go through a priority array. A command at a higher priority overrides a lower one until it is relinquished. That is useful for safety and manual override, but it also means a stuck high-priority write can make a setpoint appear unresponsive. The project should define which system writes at which priority, and what happens when communication is lost. Alarms and change-of-value subscriptions need the same discipline: confirm which events are generated by the device, which are calculated by the platform, and who acknowledges them. Alarm rationalisation applies here as it does to any BMS: an alarm should describe a condition that needs action, not every state change the device can report. A write test should prove the value at the device, not only on the platform screen. A release test should prove that the point returns to its local control when the platform lets go. Log the user, time and previous value for every writable point. A priority that is never released is a design fault, not a device fault.
- Define write priority and relinquish behaviour
- Separate device alarms from platform alarms
- Confirm COV subscriptions and update rates
- Record who owns each writable point
Network design and gateway selection
Network design decides whether a correct object map works in practice. On BACnet/IP, plan subnets, broadcast domains, BBMD placement and NAT before addressing devices. On MS/TP, plan baud rate, termination, bias, segment length and the number of devices per segment. A gateway or router is needed when the two worlds meet, or when a segment cannot be routed directly. Choose it by supported services, point capacity, throughput and diagnostics, not by port count alone. Keep the controls network separate from the corporate network, and document the route between them. A controls network that shares a flat VLAN with office traffic is difficult to secure and difficult to diagnose. A spare IP range and spare device instances cost nothing now and save a project later. Label every cable and every port; BACnet troubleshooting starts with the physical layer. Record the broadcast domain and the BBMD route on the network drawing.
- Subnets, broadcast domains and BBMD
- MS/TP baud rate, termination and segment length
- Gateway by services, capacity and diagnostics
- Controls network separated from office IT
Testing and commissioning
Test in layers. First, network reachability and device discovery. Second, object reads and scaling against the device's own display. Third, writable points, including priority and release. Fourth, alarms and trends. Fifth, failure: disconnect the network, confirm the plant keeps running and the platform reports the loss. The handover pack should include the device list, object export, point schedule, network diagram, test records and the names of the people who can change each device. A browse tree is not a handover. Where sequences cross the BACnet boundary, test the sequence end to end, including the case where one device is offline. Point-to-point tests should cover every object in the schedule, not a sample chosen by the installer. For analogue values, test at two points in the range and at the alarm limit. For binary values, test both states and the feedback. For multi-state values, test every state that the operator can select. Keep the test evidence with the as-built point schedule.
- Network, discovery and object export
- Read scaling against local display
- Write, priority and release tests
- Network loss and recovery
- Device list, point schedule and test records
Documentation, limitations and responsibilities
BACnet is explicit but not uniform. Some devices support only a subset of services; some expose hundreds of objects that no one needs; some have slow response times or limited concurrent connections. MS/TP segments need baud rate, termination and polling discipline. IP routing, NAT and BBMD configuration can defeat an otherwise correct design. Licensing and engineering access may sit with the original vendor. None of these are reasons to avoid BACnet; they are reasons to audit before promising a point count or a control function. Documentation should include the device register, the object export, the point schedule, the network drawing, the test records and the access arrangements for each vendor. Responsibilities should be explicit: who owns the plant sequence, who owns the BACnet mapping, who owns the IP network and who approves a firmware update. The boundary between plant safety and platform supervision belongs in the contract, not in a meeting note. A third party should be able to continue the integration from the handover pack alone.
- Service and object support varies by device
- MS/TP timing and termination
- IP routing, NAT and BBMD
- Vendor access and licensing
- Named owner for sequence, mapping and network
BACnet integration stages
14 rows| Stage | What to check | Output |
|---|---|---|
| Network survey | IP range, device instances, BBMD, routing | Network diagram |
| Device discovery | Object list, firmware, supported services | Device register |
| Object mapping | Type, instance, unit, scaling | Point schedule |
| Point naming | Instance in name, role and owner | Naming register |
| Read/write rights | Writable points, priority, release | Ownership matrix |
| Write testing | Value at device, relinquish, logging | Write test record |
| Alarms and trends | Device events, COV, history | Alarm and trend plan |
| Network and gateway | BBMD, NAT, MS/TP, router choice | Network design record |
| Integration build | Platform points and graphics | Configured platform |
| Point testing | Value, unit, command, feedback | Test record |
| Failure testing | Network loss, device offline, recovery | Resilience record |
| Performance check | Polling load, response time, stale data | Performance record |
| Documentation | Device register, exports, network drawing | As-built pack |
| Handover | Exports, diagrams, access contacts | Handover pack |
Project images
3 images
Frequently asked
01Can you integrate a BACnet chiller?
Usually yes, if the chiller exposes the required objects and the vendor grants read/write access. The audit confirms object support, writable setpoints and any proprietary points before the scope is fixed.
02Do we need a BACnet gateway?
Only when the device or network segment cannot connect directly. BACnet/IP devices can sit on the building network; MS/TP segments normally need a router or gateway.
03What is a BACnet point?
A point is a mapped object property, such as an analogue input's present value or a binary output's command. The point schedule records its object instance, unit, scaling, direction and owner.
04Can two systems write the same BACnet point?
They can, but the project must define priority and ownership. Without that, the last writer wins and the operator sees inconsistent behaviour.
05Does BACnet include scheduling?
The standard includes schedule and trend objects, but not every device implements them. Many projects keep schedules in the platform and write setpoints or enable commands to the plant.
06What happens when the network fails?
A correctly designed plant controller keeps its local sequences and safety functions. The platform should raise a communication alarm and show the affected points as stale, not as normal.
07Can we keep our existing BMS?
Often yes. The platform can read the existing BMS through BACnet/IP and add cross-system functions without replacing plant control.
08How long does BACnet integration take?
It depends on device count, object quality and access to the plant. Discovery and mapping are usually the long parts; writing graphics before the point schedule is agreed creates rework.
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.