Open Protocols Do Not Guarantee an Open Building

BACnet, Modbus and KNX make it possible for equipment from different manufacturers to exchange information. They reduce the need for a bespoke connection every time two systems meet. They also give owners more options when a product is replaced or another layer of software is added.

But the protocol is only one part of the delivered system. Lock-in can remain in the engineering tools, control programs, point mapping, supervisor database, licences, passwords and service arrangements around it.

What the protocols actually provide

BACnet defines messages, formats and rules for exchanging building-automation data, commands and status information. Its object model gives systems a common way to represent values such as temperatures, setpoints, alarms and schedules.

Modbus is simpler. It provides a well-understood way to read and write coils and registers. That makes it useful for meters, drives, packaged plant and many other devices, but the meaning of each register still depends on a separate manufacturer map.

KNX is a standardised ecosystem for home and building automation, backed by certified products and a common engineering tool. It is especially established in lighting, room control and residential systems.

Those are meaningful forms of openness. They make interoperability possible. They do not prove that a particular integration is complete, documented or easy to maintain.

Where a technically open system can still close up

A controller may expose its live values over BACnet while requiring a vendor-only tool and licence to change its program. A packaged unit may provide a Modbus interface while its register map is incomplete or tied to one firmware revision. A supervisor may read several brands but store graphics, histories and configuration in a format that only its own engineering environment understands.

There are also softer forms of lock-in. The owner may never receive the latest controller backups. Device names may be inconsistent. Passwords may remain with the installer. The points list may describe the design rather than the final installation. Trend data may be visible on screen but awkward to export in bulk.

None of this means the vendor has done something improper. Specialist engineering tools and partner networks can support quality and accountability. The problem is not that specialised knowledge exists. It is when the owner does not know which parts of the building depend on it, or cannot make a sensible plan for future support.

Openness is a handover outcome

A useful handover should leave the next competent engineer able to understand the system without reconstructing it from scratch.

For the controls layer, that normally means current controller programs and backups, the final points and network schedules, graphics source where applicable, alarm and trend configuration, software and licence requirements, and a clear record of overrides or unfinished work.

For the data layer, it means knowing what can be exported, at what frequency and in what form. An API is helpful, but only if its scope, authentication, rate limits and commercial terms are understood. A CSV export is useful, but not if all the equipment context has been lost.

For the service layer, it means being clear about who is authorised to make changes, how access is granted and removed, and what happens if the incumbent maintainer changes. Current NCSC guidance for operational technology places open standards and interoperability within a maintainable OT architecture, with data exchange handled through standardised interfaces.

Questions worth putting into the specification

Before choosing a system, an owner or consultant should ask:

Which devices and functions use an open protocol, and which remain proprietary? Can another qualified integrator discover the devices and read the standard objects or registers? What engineering software, licences and vendor training are needed to modify the system? Will the owner receive editable source, current backups and the final network architecture? Can histories, alarms, asset metadata and audit records be exported without manual screen-scraping? Are proprietary BACnet objects or private Modbus registers essential to normal operation? What breaks if a cloud subscription ends or the supervisor is unavailable? How will credentials, remote access and software versions be managed over the building's life?

These questions are less exciting than a smart-building demo. They are also much more likely to determine the owner's choices ten years later.

The practical middle ground

Automatry regularly works with BACnet, Modbus, KNX and vendor-specific engineering environments. We favour open-protocol designs because they make integration and long-term support more realistic. We also know that a protocol label on a schematic is not enough.

The useful standard is straightforward: the building should keep operating locally, the owner should understand what they have, and another competent team should be able to support or extend it without an avoidable rebuild.