What is the difference between an independent data layer and a common data environment?

A common data environment should be able to tell you which revision of an air-handling unit's maintenance manual is the approved one, and who approved it. What that unit's supply-air temperature was last Tuesday afternoon is beyond it. That second question belongs to an independent data layer.

A common data environment (CDE) manages approved project and asset information: drawings, models, specifications, manuals, certificates and the structured data that accompanies them. Its core purpose is control over who produced a document, which revision is current, and whether it has been checked and approved for use. An independent data layer manages operational information, meaning live and historical readings from building systems, events and alarms, linked to the assets and spaces they describe. Its core purpose is reliable access for applications.

Some products offer parts of both, but the workflows are different, and treating one as a substitute for the other is a familiar source of disappointment after handover.

The CDE: a controlled record

The ISO 19650 series sets out information management using building information modelling (BIM) across the whole life of a built asset. Its first part, ISO 19650-1:2018, which ISO has scheduled for revision, describes in its official abstract a framework that covers exchanging, recording, versioning and organising information. Guidance from the IMI Framework (formerly the UK BIM Framework) distinguishes the CDE workflow, meaning the processes for collecting, managing and disseminating information, from the CDE solution, the technology that enables them. Information moves through states such as work in progress, shared, published and archived, carrying metadata for status, revision and classification. A project's CDE may in fact be made up of several organisations' CDE solutions working together.

What comes out is a record you can rely on. You know which version of the operation and maintenance manual is the approved one, and who approved it.

The data layer: dependable operational data

A data layer connects to the building management system (BMS), meters and other systems, records time-stamped values with quality indicators, and links each value to an asset and a location. It is built to answer questions about how the building is behaving, which a document repository was never designed to do.

Putting both into one cloud platform does not make these requirements converge. A document repository is not automatically a dependable time-series service, and a live dashboard is not an approved record.

The asset identifier is the bridge

What connects the two is the asset identifier. If the air-handling unit is "AHU-03" in the handover information, in the maintenance system and in the data layer, an engineer can move from an abnormal trend to the approved manual and the maintenance history in a few clicks. If each system names it differently, someone has to reconcile them by hand, every time.

It also needs to be clear which system is authoritative for each kind of information, whether the asset register, space names, documents or readings, and how changes flow between them. Duplicated records without a reconciliation process soon leave operators unsure which one to trust.

Getting the handover right

The practical arrangements are modest. Agree one identifier scheme for assets and spaces and use it in both environments. Write down what each holds and which is authoritative, and define what happens when an asset is replaced or a space renamed. Then test the link at handover: pick ten assets and follow each one from document to data and back again.