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."

Brian Turner CEO at Buildings IOT Oakland, California https://www.linkedin.com/in/iot-brian-turner/

Defining Google’s Digital Buildings Project

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 Project.

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:

·       Human readability

·       Machine readability and interpretation

·       Composable functionality

·       Dimensional analysis

·       Correctness validation

·       Cross compatibility

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.

Where is Project Haystack today?

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 top-level entities.

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.

Where is Brick Schema today?

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 consistent standard.

The Applied Approach

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.

Not another standard…

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 Digital Buildings.

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.