Standards & Interoperability

Interoperability is the ability of independent systems to exchange information and use it - to work together without a custom, hand-built bridge for every pair. In a building it is not a nicety; it is the difference between a coherent system and an expensive pile of silos. Without it, the lighting cannot tell the HVAC a zone is empty, the analytics platform cannot read the meters, and every new device needs bespoke integration work that costs more than the device.

Interoperability has layers. At the bottom is connectivity - can the devices physically exchange bytes (BACnet, Modbus, KNX, MQTT)? Above that is semantics - do they agree on what the bytes mean? A value of 22 is useless unless both sides know it is the supply-air temperature of AHU-3 in Celsius. This is the harder, more valuable layer, and it is why data schemas like Brick and Project Haystack matter as much as the wire protocols. True interoperability needs both: a shared language and a shared dictionary. Get it, and a building becomes a platform you can build on; miss it, and every improvement is a fresh integration bill.

An open standard is published, vendor-neutral and implementable by anyone - BACnet (ASHRAE/ISO 16484-5) for building automation, MQTT (OASIS/ISO) for lightweight messaging, KNX for control, and open data schemas like Brick and Haystack for meaning. Because many vendors implement them, parts from different suppliers interoperate, and you can swap or add components without ripping out the whole system.

A walled garden is the opposite: a vendor whose devices, protocol and cloud are proprietary and only work with each other. It is often genuinely easier at first - one throat to choke, a polished experience, fast setup. The cost arrives later. When everything speaks only the vendor's private language, your exit cost is the entire system: to change one part you must change all of it, the vendor sets the price because you have no alternative, and if they raise fees, drop a feature or go out of business, you are stranded. Your data may be trapped in their cloud in a format you cannot export. The honest trade-off: walled gardens optimise for convenience today; open standards optimise for freedom and cost over the building's life. For an asset that lasts decades, that second horizon almost always wins - which is why insisting on open protocols and exportable data is one of the most valuable specification decisions you can make.

Standards are not only about making things talk; they are also about doing things safely and provably. The headline security standard is ISO/IEC 27001, the international standard for an information security management system (ISMS). Crucially, it is not a product or a firewall you buy - it is a managed discipline: identify your information risks, select and apply controls to treat them, check that they work through audit and monitoring, and continuously improve. A plan-do-check-act cycle that makes security an ongoing practice rather than a one-off purchase.

For a building project, 27001 (often alongside the NIST Cybersecurity Framework from the first lesson, and OT-specific standards such as the IEC 62443 family for industrial control systems) gives everyone a shared, auditable language for how secure is secure enough. When a client asks a platform vendor 'are you 27001 certified?', they are asking whether security is a governed system there, not an afterthought. As a designer you will not run the ISMS, but you should know to ask for these credentials, to write them into the brief, and to treat certification as a meaningful signal - while remembering that a certificate is evidence of a managed process, not a guarantee of invulnerability. The deep assessment and certification remain the work of qualified security professionals and accredited auditors.

Principles get real at specification time, so walk through a concrete brief. A client is fitting out a mid-size office and wants smart HVAC, lighting, access control, metering and an analytics dashboard from several suppliers. Left to chance, each trade installs its own controller, its own protocol and its own app, and two years later the client discovers that adding a simple 'empty room, lights off' rule means paying three vendors to build custom integrations - and that their energy data lives in a dashboard they cannot export. That is the walled-garden outcome arriving by drift, one procurement at a time.

The open alternative is written into the brief before anyone buys anything. At the connectivity layer you require compliance with open protocols - BACnet for HVAC and controls, KNX or BACnet for lighting, Modbus or BACnet for meters, MQTT where lightweight IoT messaging is used - so any compliant device from any vendor can join the network. At the semantic layer you require the delivered system to be tagged to an open schema - Brick or Project Haystack - so the data is self-describing and a new analytics tool can read 'supply-air temperature of AHU-3' without a bespoke mapping exercise. You require ISO/IEC 27001 credentials, or a clear NIST-framework mapping, from any platform vendor. And - the clause most often forgotten - you require data portability: the right to export all historical and live data in an open format, at any time, at no punitive cost.

On a larger project you also name who owns interoperability: a master systems integrator whose job is to make these standards actually hold across trades. The result is a building that behaves like a platform - swap a chiller vendor, add an analytics startup, change platforms - without ripping everything out. None of this bans proprietary products; if a closed device is genuinely the best tool, it can still be chosen, but as a deliberate, costed exception with an exit path, not a default. The whole discipline reduces to a sentence a designer can carry into any procurement meeting: prefer open, insist on export, and make proprietary a decision, not an accident.

Pull the threads together and standards reveal their real strategic value: they are insurance against being trapped. Three practical rules protect a project. First, specify open protocols - require BACnet, MQTT, KNX or equivalent at the connectivity layer so devices from any compliant vendor can join. Second, demand a shared semantic model - Brick or Haystack tagging - so the data is self-describing and a new analytics tool can understand it without a bespoke mapping project. Third, and most overlooked, secure data portability in the contract: you must be able to export your building's historical and live data, in an open format, and take it with you. Data you cannot export is data you do not really own.

The rise of the master systems integrator - the specialist who makes many vendors interoperate around open standards - exists precisely because this is hard and valuable. None of it means never buying proprietary technology; sometimes a closed product is genuinely the best tool. It means going in with eyes open - pricing the lock-in, keeping an exit path, and never accidentally surrendering your data or your freedom to switch. For a designer, the memorable rule is simple: prefer open, insist on export, and treat proprietary as a deliberate, costed choice - never a default you drifted into.

It helps to remember why this matters more for buildings than for most technology. A phone or a laptop is replaced every few years, so a little lock-in is tolerable; a building stands for decades, and the systems inside it are expected to be upgraded, extended and re-tendered many times over that life. A lock-in decision taken casually at fit-out therefore compounds for thirty years, long after the person who made it has moved on. Open standards are how you hand the next owner, the next integrator and the next analytics tool a building they can still work with. That long horizon - designing for people and systems you will never meet - is exactly the architectural instinct this course keeps returning to, applied now to data and protocols rather than brick and steel.