Why the manufacturer choice made at initial installation can lock a building owner in for decades.
When a building automation system (BAS) is specified, one decision matters more to the building's next thirty years than almost any other line item in the controls submittal: does the equipment talk to each other using an open protocol — a published, standardized specification any manufacturer can implement — or a proprietary protocol— a closed, manufacturer-specific scheme that only that manufacturer's own equipment speaks. It rarely looks like a consequential choice on day one. Both options control the same dampers, valves, and chillers just fine at commissioning. The difference only shows up years later, when the building owner wants to add a vendor, switch controls contractors, or discovers the original manufacturer has moved on.
An open protocol like BACnet or Modbus is a published, documented specification maintained outside any single company — anyone can read the spec, and any manufacturer can build a device that implements it. A BACnet thermostat from one manufacturer and a BACnet chiller controller from a completely different one can generally exchange data on the same network, because both were built against the same public rulebook. A proprietary protocol is the opposite: it's a scheme one manufacturer designed, controls, and keeps closed or licenses restrictively. Their own controllers talk to it fluently. Almost nothing else does, unless the manufacturer sells you a specific licensed gateway to bridge it — and even then, only partially.
A BAS installed today is typically expected to run for twenty, thirty, even forty years, with equipment replaced piecemeal along the way as components age out or the owner's needs change. An open protocol like BACnet means every one of those future replacement decisions can be shopped competitively: any manufacturer that implements the same published spec is a candidate, which keeps pricing honest and keeps the building from depending on any single company's continued existence. A proprietary protocol collapses all of those future decisions down to one option — whatever that original manufacturer still sells, if they still sell anything at all. The tighter integration a proprietary system can offer within its own ecosystem is real, but it's a bet placed once, at the very start of the building's life, on behalf of every decision the owner will need to make for decades afterward.
False, or at least a bet the building owner has no real way to verify at the time of purchase. Even well-established manufacturers discontinue product lines, get acquired, restructure their controls divisions, or simply become less price-competitive over a building's multi-decade lifespan — reputation and current market position at the time of installation say very little about what a company's product roadmap looks like thirty years later. A proprietary-protocol commitment made at initial construction genuinely constrains the owner's future options in a way an open-protocol system does not: there is no competing manufacturer who can bid on replacement equipment for a closed protocol, no matter how reputable the original vendor was or still is. This is exactly why many modern BAS specifications explicitly require open protocols like BACnet— not as an arbitrary technical preference, but as a deliberate, contractually enforced protection of the owner's long-term flexibility and procurement leverage.
Explains the difference between open building automation protocols (like BACnet or Modbus) and proprietary, manufacturer-specific protocols, and why the choice made at initial installation can lock a building owner into a single vendor's ecosystem for the entire multi-decade life of the building.
An open protocol such as BACnet (ASHRAE/ANSI 135) or Modbus is a published, standardized communication specification maintained outside any single manufacturer. Any company can build equipment that implements it, and because every implementer follows the same documented rules for how data is structured and exchanged, a device from Manufacturer A can generally communicate with a building automation system or device from Manufacturer B, provided both correctly implement the same open standard. This lets a building owner mix equipment from multiple vendors on one network and add or switch vendors later in the building's life without being tied to a single manufacturer's ecosystem.
A proprietary protocol is a communication scheme designed, owned, and controlled by one manufacturer, either undocumented or licensed restrictively to third parties. Equipment using it communicates fully only with other equipment from that same manufacturer; integrating with anything else typically requires a specific, often costly, licensed gateway that provides limited functionality at best. In exchange, a proprietary system can offer tighter, more optimized integration and manufacturer-specific advanced features within its own closed ecosystem — features that can be genuinely valuable as long as the owner never needs to look outside that one vendor.
A BAS protocol decision made during initial construction can have consequences decades later, long after the engineer who specified it and the owner who approved it have moved on. A building committed to a proprietary protocol may face an expensive, difficult retrofit or a full system replacement if that manufacturer's product line is discontinued, the manufacturer is acquired or exits the controls business, or its pricing simply becomes uncompetitive with no alternative supplier able to bid on replacement equipment. An open-protocol system preserves genuine future flexibility and competitive procurement across the building's life, at the cost of potentially somewhat less tightly integrated advanced features compared to a single-vendor proprietary system optimized end-to-end. This tradeoff is exactly why many modern BAS specifications and owner's project requirements (OPR) documents now explicitly require open protocols — BACnet in particular — specifically to avoid long-term vendor lock-in.
In principle any two devices implementing the BACnet standard should be able to exchange data, but real-world interoperability depends on which BACnet objects and services each device actually implements (its BACnet Interoperability Building Blocks, or BIBBs) and whether it holds a valid BTL (BACnet Testing Laboratories) listing. Basic monitoring and control generally works well across vendors; some advanced, vendor-specific features may still require that vendor's own software or supervisory layer. It is still dramatically more interoperable than a closed proprietary protocol, which offers no such guarantee at all.
Sometimes, through a gateway device the original manufacturer (or a third party) builds specifically to translate between the proprietary protocol and an open one like BACnet or Modbus. These gateways add cost, add a point of potential failure, typically expose only a subset of the proprietary system's full functionality, and often still depend on the original manufacturer's continued cooperation or licensing — they mitigate lock-in but don't eliminate it.
Potentially some, yes — a single manufacturer's proprietary ecosystem can sometimes offer more tightly coupled, purpose-built features because it controls both ends of the communication. But most owners find that ASHRAE Guideline 36-style sequences, scheduling, alarming, trending, and analytics are all fully achievable over open protocols today, and the long-term procurement flexibility an open protocol preserves is generally considered to outweigh a modest reduction in single-vendor feature depth.
Because the specification is written to protect the building owner's interests for the full life of the building, not just at the moment of installation. Requiring an open, published protocol ensures that future equipment additions, controls contractor changes, and replacement purchases can be competitively bid among multiple qualified manufacturers, rather than being locked to whatever pricing and product availability one original vendor happens to offer years or decades later.
Try our Smart Buildings Studio
More calculators, simulators, and guides for this discipline.