In modern commercial buildings, the question is rarely which protocol to choose. The real question is: how do we create a robust, open, and future-proof Building Management System (BMS) in a world with many protocols?
The answer starts with one primary protocol and a deliberate strategy for the rest, where architecture matters more than individual choices. If you want a clear introduction to what a BMS actually is, read: What is a Building Management System?
Today’s buildings are composed of complex systems
Very few buildings are “pure” or built according to a single, coherent plan. Most commercial buildings result from multiple construction phases, refurbishments, tenant fit-outs, and ongoing technological evolution.
As a result, different parts of the building often rely on different technologies and protocols:
- Energy meters and technical components often communicate via Modbus.
- Lighting control, solar shading, and room control are often delivered with KNX.
- Higher-level energy and data systems increasingly use OPC UA.
- The building automation system and its core logic typically use BACnet.
This does not indicate poor planning; it reflects how modern commercial buildings evolve. The challenge only arises when these systems are allowed to exist as parallel worlds, without a shared structure, shared terminology, or clear ownership of the data. This often results in duplicated functionality, limited insight across systems, and a high threshold for further development and reuse of the BMS.
Standardised protocols in modern building automation
Several standardised protocols are used in building automation, but with very different roles and responsibilities.
BACnet - the backbone of building automation
Developers created BACnet specifically for building automation, and it should serve as the primary protocol in a Building Management System. Unlike many other protocols, BACnet reflects how buildings actually operate. It does not focus on simple I/O or raw data points. The protocol describes components as objects with defined properties, states, and relationships, creating a natural link between technical systems and the building’s function.
This provides several important advantages:
- Object-based model tailored for buildings – Functions such as temperature, airflow, pressure, and energy are represented as meaningful objects rather than just addresses or registers.
- Standardised point types and functions – Similar functions can be described consistently across vendors, simplifying operation, troubleshooting, and further development.
- Support for large and complex systems – BACnet is scalable and suitable for everything from single buildings to large property portfolios with many subsystems.
- Vendor independence – Building owners and operations teams have greater freedom to combine and change vendors over time without rebuilding everything.
- Well suited for refurbishment and reuse – Existing components and systems can be integrated and retained while the overall structure is modernised.
Most importantly, BACnet provides a structured and consistent information model for the building. As a result, data gains context and meaning, regardless of where it originates. When the BMS integrates Modbus, KNX, or other systems, it maps their data into the same model and appear as part of a single coherent whole. This makes BACnet particularly well suited as the backbone of a modern BMS, not necessarily as the only protocol, but as the supporting structure that holds the building together over time.
Modbus - a field protocol for technical components
Modbus is a simple and robust protocol widely used in technical components in buildings. It is commonly found in energy meters, variable frequency drives, boilers, chillers, and other technical subsystems where the primary requirement is reliable transmission of measurements and simple control signals.
At the same time, Modbus has clear limitations. The protocol is register-based and lacks any built-in understanding of what the data represents. It lacks semantics and context and is therefore poorly suited as a foundation for supervisory control, analysis, and further development of a building automation system.
In a modern BMS, Modbus should therefore not stand alone; the BMS should integrate it into an overarching BACnet model. When Modbus data is mapped to BACnet objects, measurements gain proper context, points can be named consistently, and the system becomes easier to understand, operate, and evolve over time. This makes it possible to leverage existing Modbus-based components without allowing them to constrain the overall system.
Modbus is therefore a valuable part of many buildings, but should never form the core structure of the BMS. It is a protocol for technical components, not for describing the building’s overall function.
KNX - room level and user interfaces
KNX is a widely used standard in buildings, particularly for functions closely tied to individual rooms and user interaction. The protocol is well suited where local control and flexibility are important, for example in tenant fit-outs and changes to room layouts.
Building designers commonly use KNX for:
- Lighting control and scenes
- Blinds and solar shading
- Room control and occupancy
At the same time, KNX is not well suited for supervisory control and analysis at building level. Its decentralised structure and limited semantics mean that KNX alone does not provide a holistic view of building operation and energy use. This is also one reason why energy efficiency in commercial buildings requires a strong central BMS.
In a modern BMS, KNX should therefore be used as a room-level system and integrated into an overarching BMS. When KNX functions are mapped to BACnet objects, room data can be included in common control strategies and analyses without losing flexibility at room level.
OPC UA - an industrial protocol for system integration
OPC UA originates from the industrial domain and is well suited for:
- Integration with energy platforms
- Data exchange with IT systems
- Cloud and analytics applications
OPC UA is not a field protocol, nor is it designed for direct control of building components. It is intended for structured and secure data exchange at a higher level in the system architecture. In modern buildings, System architects therefore place OPC UA above the BMS, not in place of it. Building logic is handled within the BMS, usually based on BACnet, while OPC UA is used to further utilise data towards higher-level systems, analytics platforms, and IT solutions.
Architecture for modern building automation systems
A robust building automation system is not about choosing the “right” protocol once and for all, but about establishing an architecture that can withstand change over time. Because buildings last for decades, technical systems, usage patterns, and digital solutions inevitably change. For this reason, designers must create a BMS for continuous adaptation rather than as a snapshot at handover.
In practice, this means there must be one clear primary structure in the system. This structure must provide a shared understanding of the building’s function and consolidate data into a consistent and meaningful model. When the system describes all core functions in the same way, teams gain full control and insight. This approach prevents complexity from escalating with every change. For relevant security practices in such systems, see Zero-trust security in building automation.
At the same time, a modern BMS must be able to integrate other protocols in a controlled manner. Existing equipment, room systems, energy meters, and external platforms will often use different standards, and these cannot, and should not be eliminated. The challenge is therefore not the diversity itself, but how that diversity is handled. Without a clear primary structure, you risk fragmented systems, unclear data ownership, and increasing dependency on individual vendors.
A deliberate architectural choice makes it possible to avoid proprietary lock-in while still leveraging existing investments. When the building’s core functions are consolidated into a single coherent model, other protocols can be connected where they add the most value without undermining the whole. In practice, this can be summarised simply: BACnet serves as the backbone of the building automation system, while other protocols act as satellites around it. This role distribution provides both flexibility in the BMS and control.
Zaphire BMS
Zaphire BMS is developed based on how modern buildings are actually used. Rather than assuming a single protocol or one technical system, the architecture accounts for the fact that buildings consist of both new and existing installations, delivered over time and based on different technologies.
The solution is cloud-based and built around BACnet as the primary structure. This provides a consistent and understandable model of the building’s function, where control, monitoring, and logic are brought together in one coherent system. At the same time, the architecture is open to integration of other standardised protocols such as Modbus, KNX, and OPC UA.
Through clear interfaces and a deliberate role distribution between protocols, existing equipment can be reused in the BMS without compromising structure, security, or future flexibility. Zaphire BMS therefore enables stepwise modernisation, allowing buildings to evolve over time rather than having to be rebuilt from scratch.
