BTL Mark: Resolve interoperability issues & increase buyer confidence
|Google’s Digital Buildings
What it Means for Haystack and Brick Implementations
When Ken Sinclair shared introduction language to the Google Digital Buildings Project on LinkedIn, people across the smart buildings industry started talking and fast. To recap, Google's Digital Buildings project is " an open-source, Apache-licensed effort to create a uniform schema and toolset for representing structured information about buildings and building-installed equipment."
CEO at Buildings IOT
When Ken Sinclair shared
introduction language to the Google Digital Buildings Project on LinkedIn, people
across the smart buildings industry started talking and fast. To recap,
Google's Digital Buildings project is " an open-source, Apache-licensed
effort to create a uniform schema and toolset for representing structured
information about buildings and building-installed equipment."
What really got our industry thought
leaders going was the last line in the description - "Digital Buildings
work has been inspired by Project Haystack and Brick Schema and maintains
cross-compatibility and/or convergence as a long-term objective." One
commenter put it simply: "Wow. Could this really lead to a convergence of Haystack
and Brick?" And that, perhaps, is the million-dollar question. Before I put
in my two cents, it's worth diving a bit deeper into the Digital Buildings
The ontology itself is being used by Google
to manage buildings across the globe because of an urgent need to operate its
very large, very heterogenous portfolio in a scalable way, as stated in the
readme file on the GitHub site. The goals are for the model to be
"semantically-expressive," or deeply meaningful, but abstract enough
to be applied across their vast swath of buildings that contain many multitudes
of equipment configured and provided by innumerable engineers, design teams and
contractors. The model must also be written in an easy-to-use configuration
language and complete with validation tools so that different teams of people
can contribute as they apply it across the world.
Google says the Digital Buildings team has
considered the following:
Machine readability and
Although the long-term objective of
cross-compatibility with Project Haystack (Haystack) and Brick Schema (Brick)
is clear, the market (not just Google) is looking for something that will bring
the overarching goals of a unified buildings ontology to a fast reality. The
open-sourced nature of Digital Buildings means anyone can contribute and anyone
can use the model and apply it to their own buildings. The same is true for
Haystack and Brick. At first glance, the similarities between the three may
seem to end there. For example, many people who use Brick or are seriously
considering Digital Buildings do not realize Haystack 4 made significant
progress in the area of entities and relationships in the last 18 months.
I have heard the comment many times that
Haystack is a good naming standard, but it is much more than that now. Project
Haystack released Haystack 4 for public review at the end of 2019. With that,
Haystack upgraded many aspects that were considered lacking in Haystack 3 that
kept it from being considered a true ontology - for example, Haystack 4 has introduced
a more complete ability to define relationships amongst, within and between
entities. Also new in Haystack 4 is the introduction of spaces and devices as
It is not clear how many Haystack community
members and integrators have implemented these concepts, or who is working
toward updating their Haystack 3 implementations to Haystack 4. As far as
cross-compatibility goes, Haystack 4 is the only version that will have a
chance of aligning with Digital Buildings and Brick, so any convergence between
the three needs to start there.
Brick Schema does a pretty good job in the
areas of HVAC and electrical systems when it comes to defining classes and
relationships. It is also clear that the people managing Brick Schema are aware
of the need to include other operational systems in the building, though the
spread is limited at the moment. What is more difficult to ascertain is how
widely Brick is being used in buildings around the world. There is no doubt it
is being used and should be included when aligning the standards.
On a more anecdotal note, I have seen Brick
referred to in many specifications as a building data model standard, but it is
listed as an option alongside Haystack. Which one is the contractor or
integrator supposed to use? These two models are slightly different which will
lead to problems down the road if the systems within the project don’t follow a
It is important to keep in mind the reason
we're all here under this big ontology tent in the first place. Building data
needs to be modeled in such a way that it is portable and consistent across
multiple buildings regardless of the design engineer, system vendor or installing
contractor. Once this is done, the products and solutions upstream will improve
to be utilized across a broad spectrum of projects. The data we have been
trying to unlock for years will actually be opened up and it will be well
defined, related, and available. This will remove the ever-growing development
of black-box solutions that hold data hostage.
Haystack, Brick and now Digital Buildings
are getting us closer to a uniform tagging standard that master systems
integrators are using every day to normalize data for buildings around the
world. But the lack of a consistent strategy for modeling relationships leaves space
for each integrator to define this crucial element in a slightly different way,
meaning we still don't have a buildings standard that is uniformly applied.
Meanwhile, the need for this is only
increasing at the project level. Word is out that connected buildings are the
way to go for building owners and operators who want to find operational efficiencies
with open systems and a usable data model. That's the foundation from which we
can all build successful implementations.
When I read "cross-compatibility"
and "convergence" I see the opportunity to align the three standards in
a toolset to make them each more robust and usable in and of themselves. One of
the biggest problems with ontologies as they exist for buildings today is the
lack of direction on how they are applied.
If you have ever attempted to use the data
in an enterprise or combine multiple sources of data with shared relationships,
you have encountered this application problem. When we get out of a single
building and into a portfolio level analysis, we often find that the data
modeling structure is too vague, or the meta-data is incomplete. Something as
low as 20% variance between implementations makes a significant difference when
data sharing needs to take place at a centralized server, for example.
Another common problem is selecting a
platform to perform analytics on the data. Wouldn’t it be nice to load the data
into two or three cloud platforms with the knowledge that the source data does
not need to be manipulated in order to be useful in each platform? Another
outcome could be for end users to share knowledge and algorithms knowing that
the source data is modeled in a consistent way.
Can data-rich systems be integrated with
the models available today? At the moment, we have three reasonably good
choices that allow us to solve complex problems in buildings. And this appears
to leave us all with some big choices – migrate to Haystack 4, use Brick or use
We all know that the industry itself is fractured
by design to allow many players to participate in the organization, creation
and management of the sources-of-truth for individual data types. Given this,
there is a strong need for simple direction on applying these standards that
can be used by every contractor in the data value chain.
Now that we’ve laid out the problem, I hope you’ll check back here in Automated Buildings next month for our attempt at a solution.
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]