Open vs Proprietary Systems

A proprietary building system is one whose inner workings - its protocol, its data format, its programming tools - are controlled by a single vendor and not openly published. On its own, one vendor's ecosystem can be slick: the controllers, the software and the dashboard are designed to work together, and installation is smooth. The trouble arrives later, and it has a name: vendor lock-in. Because only that vendor can read the protocol, program the controllers or extend the system, the owner is tied to them for every future change, every added sensor, every price negotiation, and every attempt to connect something new - like a digital twin.

Lock-in shows up in painfully practical ways. Want to add a third-party analytics platform? It cannot read the proprietary points. Unhappy with the vendor's service or price? Switching means replacing the whole system. Want to integrate the new lighting system with the old HVAC? They speak different private languages and the bridge is a costly custom project. The data your building generates - which the owner arguably owns - sits behind a protocol the owner cannot read without paying the gatekeeper. Proprietary is not evil, and sometimes a specialist system justifies it, but every proprietary layer is a door that only one company holds the key to, and the bill for that comes due precisely when you try to make the building smarter.

Lock-in is rarely the result of a villainous decision; it accumulates quietly. A subsystem is chosen for a good reason, a vendor's convenient tool is adopted, an extension is bought from the same supplier because it is easiest, and one procurement at a time the building becomes captive - each step sensible, the sum a trap. That is why openness is a stance to hold from the very first specification rather than a rescue to attempt at the end.

The alternative is open systems built on openly published protocols that any qualified party can implement. In building automation the anchors are BACnet (the dominant open BMS protocol, an ASHRAE/ISO standard), Modbus (a simple, ancient, ubiquitous open protocol for meters and plant), and KNX (an open standard for lighting, blinds and room control). Because these are public standards, controllers and software from different vendors can interoperate, third-party tools can read and write data, and a digital twin can connect without asking anyone's permission.

An honest caveat matters here: open is not the same as free, effortless, or perfectly interoperable. Two devices can both 'support BACnet' and still not talk usefully, because they name and structure their data differently - which is exactly why the metadata schemas of Module 4 (Brick, Haystack) exist to add shared meaning on top of shared protocol. Open systems still need skilled integration and good engineering. What open buys you is not zero effort; it is freedom of movement: the ability to mix vendors, choose your own analytics and twin, swap out a component without ripping up the system, and negotiate from a position of strength. Openness is insurance against being trapped, and its value grows every year the building lives.

There is also a spectrum hiding inside the word 'open', and it pays to see it. A protocol can be an open standard yet still be implemented in a locked way; a system can be open at one layer (it speaks BACnet to the outside) but proprietary underneath (only its vendor can reprogram the controllers). And 'has an API' is not the same as 'open' - a vendor cloud with a rate-limited, changeable API still leaves the owner dependent on that vendor's goodwill. When you assess openness, ask the sharper questions: can a third party read and write the data, reprogram the logic, and export the history, without the original vendor's permission or a per-seat licence? The answers, not the marketing label, tell you how open a system really is.

Real buildings are rarely all-open or all-one-vendor; they are messy mixtures - BACnet HVAC here, a KNX lighting island there, a proprietary access system, Modbus meters, a handful of cloud gadgets. Someone has to make this menagerie behave as one coherent system, and that role has a name: the master systems integrator (MSI). The MSI is an independent party - not tied to any one equipment vendor - whose job is to normalise every subsystem onto common protocols and a shared data model, and present a single, open, coherent layer that applications and a digital twin can build on.

The MSI matters because integration does not happen by itself, and leaving it to each equipment vendor recreates the silos of Lesson 3.2 - every vendor bolts on its own front-end and none of them agree on what 'occupied' or 'Level 4' means. An MSI instead owns the whole picture: mapping points, reconciling names, bridging protocols with gateways, applying a consistent tagging scheme, and keeping the integrated layer open so the owner is not simply locked into the integrator instead of the manufacturer. This is a newer, fast-growing discipline - part engineering, part data architecture, part politics - and it is one of the most valuable and least-filled roles in the whole smart-building industry. For a twin, a good MSI is often the thing that makes the twin possible at all: it turns a building of babbling islands into one system that speaks a language the twin can read.

Openness is not a purist's preference; it is the practical foundation of a digital twin and a protection for the building owner. A twin's entire premise is a live connection to the building's data - and if that data is locked behind a proprietary protocol, the twin either cannot exist or exists only as another product from the same vendor, on their terms. Open protocols let the owner choose the best twin, analytics and applications independently of who supplied the controllers, and let those choices change as the market and the building's needs evolve over a twenty- or thirty-year life.

For the owner, the stakes go beyond any one twin. Openness is fundamentally about owning your own building's data and destiny: the freedom to change service providers, to benchmark competing bids, to add capabilities the original vendor never imagined, and to avoid a future where every improvement requires the permission and the price of a single supplier. It is also, increasingly, about resilience and security - open, well-understood standards can be scrutinised and secured, where obscure proprietary ones hide their weaknesses (a theme Module 9 develops, alongside the reminder that connected buildings carry real cyber risk that qualified security professionals must sign off). The practical guidance is consistent and worth carrying into every project: specify open by default, treat every proprietary layer as a deliberate, justified exception, insist the owner can read and export their own data, and keep the integrated layer vendor-neutral. Do that, and the building stays twin-ready and the owner keeps the keys - for decades.

This closes the module's arc. We began with the BMS as the building's existing nervous system, opened it into its HVAC, lighting and access subsystems, went inside the control loops and sequences that make it act, and now see who ultimately controls all of it. The through-line is ownership and access: a building is only as smart, and only as twin-ready, as its data is reachable. Every earlier lesson - the point list worth reading, the occupancy signal worth sharing, the trend worth analysing - depends finally on this one: can you get in, on open terms, and does the owner rather than a vendor hold the keys. Carry that question into every building you assess.