What is an independent data layer in a smart building?

An independent data layer is a governed service that gathers information from a building's systems, such as the building management system (BMS), meters, lighting, access control and maintenance records, gives it consistent identities and context, and makes it available to any authorised application through documented interfaces. "Independent" means that the information, and the means of getting at it, belong to no single application supplier.

The case for one is architectural. Controls, meters, software platforms and analytics tools are replaced on different cycles, rarely at the same time, and a data layer lets the building's information outlive the products that produce and consume it. That independence has to be demonstrated, though, through access, portability and operating arrangements. A platform that calls itself "open" or "vendor-neutral" has proved nothing by saying so.

Six functions, one layer

It can be a single product or several services assembled together. Either way, the owner needs a named party responsible for maintaining connections, fixing errors and keeping the information model current.

One boundary deserves an explicit decision early on: whether the layer carries only readings and history, or events and commands as well. Read-only access is simpler and safer. Sending commands back into building systems is a different capability, with its own safety and security design, and is better treated as a separate decision.

Four questions that reveal whether it is really independent

Can a second application get what it needs without the original supplier's help? Ask to see it done, with a tool the supplier did not choose.

Can identifiers, relationships and history be exported in documented formats? A dump of readings without the relationships loses most of the value.

Who owns the mappings? This is often the most revealing question. Linking raw points to assets and spaces can be the most expensive part of the work, and if those mappings exist only inside one supplier's application, they leave when the supplier does.

How long does exit take? A contractual right to your data is of little use if exporting a year of history takes months.

Open representation helps with the third question. Brick, for instance, holds context as an openly documented graph in the standard RDF data model, which makes mappings more portable, although it does not by itself guarantee that two products will exchange them without effort.

Settle the operating model before choosing a platform

Before going to market, an owner should be able to write down which systems and data the first phase covers, who maintains each connection and resolves errors, which identifier scheme and semantic model will be used and who curates them, whether the layer will issue commands and under what controls, and what format, timescale and assistance apply at exit. Those answers should shape the platform choice. Too often it happens the other way round.