Buildings IOT tackles smart building data model fragmentation

As more building owners and managers are pursuing smart building strategies, a fragmented ecosystem of ontologies, schemas and data models is not making things easy for them. Buildings IOT, which helps companies plan and manage properties enabled with IoT and automated systems, is looking to change that with its Ontology Alignment Project (OAP). 

Buildings IOT official told Fierce Electronics by email that the existence of multiple would-be data model standards for planning smart building environments, such as Project Haystack, BrickSchema and the Google Buildings Ontology Project, leaves property owners with major headaches even before they get their projects off the ground.

“There are several schemas and ontologies used in the industry today, with no true consensus or front runner,” the company said via email in response to questions posed by Fierce Electronics. “It feels to many that this decision–what ontology to use–must be made before everything else. This slows down the process of creating smart buildings as time and effort is spent on picking the data model to apply. Often owners can become paralyzed by these decisions, which prevents them from moving forward at all.”

Buildings IOT made clear it is not looking to propose yet another standard with OAP, which instead “is simply a resource for building owners, integrators, and software developers on how to model in any standard,” the company said. “We hope that in the future, if you choose to model your building in one standard, whether it be Brick, Haystack, RealEstateCore, etc., you can easily convert that model to any of the other standards. This removes/reduces the importance of what standard is chosen, because converting data from one standard to another is easy.

OAP has a webpage organized in plain language and requiring no understanding of any other data model to use. “The GraphQL API is also extremely simple and self-documenting,” the company said. “Each ontology provides detailed documentation on structure and approach. Classes and subclasses, types and subtypes, tag definitions, children, etc. The OAP’s focus is on the application of the ontology and is removed from the details of the specific ontology itself.”

A big part of smart building ontology is the point tags and naming conventions associated with various systems, machines, devices and locations within a building. The OAP’s data translation component makes it possible for users of other ontologies to make sense of all this even if they already have used other models, and without having to start over on any tags or naming conventions they may have already deployed. 

The OAP defines both the name and the points associated with building entities as diverse as rooftop units, electric meters, and booster pumps to make their data more readable by machines. It also provides a model for specifying relationships that define how entities within the building's systems relate to each other. For example, a reference can designate that an air handling unit is supplying air to a variable air volume unit. By designating these relationships within the data model, system-based and root cause analytics can be applied more efficiently, the company said. 

In addition, normalizing and standardizing building and IoT data improves programmatic application of analytics, user interfaces, fault detection and diagnostics (FDD), and other use cases that leverage building data for more effective management and operations, according to Buildings IOT.

The company already used the OAP to model the data in all connected systems at 800 West Fulton Market in Chicago, a deployment for property owner Thor Equities that Buildings IOT first discussed last year. In this use case, Buildings IOT said the OAP delivered on several proof points, including:

  • System models were easily leveraged by the various applications relying on the data.

  • Integration was completed faster and with less re-work as the team was given a clear and concise list to follow at the beginning of the project.

  • The time from integration to front-end deployment was significantly reduced. 

RELATED: Nine IoT podcasts worth your time