5 Data Modeling Challenges in Smart Buildings and How to Solve Them

Innovation in our daily lives has introduced us to the capabilities of technology. And for those of us working in the built environment, it has introduced a number of what-ifs about the capabilities of buildings. As we drive to work in our vehicle that brakes for us to avoid a collision, automatically adjusts the air conditioning to each driver’s preference, and automatically turns on the headlights when it’s raining, we begin to wonder how buildings can implement such intelligence to curb carbon emissions, improve occupant experience, and cut operational inefficiencies and costs. But buildings are complex, much more complex than a modern vehicle. Each one with thousands of data points on thousands of devices and equipment, all with their own technologies, vendors, building management system protocols, and networks.

Most experts across the smart building industry agree that for buildings to reach the level of intelligence we see in other industries an independent data layer (IDL) that simplifies the complexity of building technology is crucial. They also understand that to achieve this it is important for the industry to have a standardized approach to organizing building data. Cue the building data model.

While the “why” has been well established, the “how” is often less clear. The road to a well-modeled building is often riddled with potholes. Here are 5 tips to pave the way to a smoother data modeling journey.

Challenge 1: How to get uniform data modeling and consistency?

The complexity of the built environment has brought about substantial inconsistencies in tagging and data modeling in the built environment. These inconsistencies make it difficult for data modelers to choose and implement a consistent and uniform data model across equipment, buildings, and even portfolios. For instance, iIf someone asked you to model the point `AHU1DATSP`, how would you do it? Would you tag it `ahu`, `discharge`, `setpoint`, `temp` ? Or maybe `supply`, `air`, `temp`, `setpoint`?

Solution:

This inconsistency in tagging and data modeling is the motivation behind our Ontology Alignment Project (OAP). In addition to bringing together multiple ontologies under one hood, the OAP gives prescriptive guidance for tagging points and equipment. Instead of guessing what a good set of tags could be a data modeler can select from a predefined list of point names. So the point named `AHU1DATSP` can be tagged by applying the OAP’s point definition: `Discharge Air Temperature Setpoint` that defines the correct set of tags: `air’, `discharge`, `effective`, `point`, `sp`,`temp`.

Challenge 2: How to go about data modeling?

The complexity of built environments – data points, equipment, buildings, spaces, relationships – results in significant amounts of data. With so much data to model, it can be difficult for data modelers and developers to know how and where to start. This can result in significant bottlenecks in the development and implementation of intelligent building solutions or can add even more complexity to the environment.

Solution

At Buildings IOT, we have developed tools and processes to easily onboard your building’s data and allow building integrators and data modelers to get a building mapped quickly and efficiently.
In addition, the OAP data standard is completely open, accessible, and queriable for others to leverage and build their own tooling via a GraphQL API.

Challenge 3: Data modeling is a repetitive and time-consuming process.

Simplifying the complexity of the built environment often means tagging numerous entities repeatedly. It is a time-consuming process for data modelers and developers to standardize the built environment’s data across buildings and portfolios. Even for experienced data modelers, it becomes cumbersome to tag “AHU1DATSP” as “Discharge Air Temperature Setpoint” for the thousandth time.

Solution

To that end, we leverage Machine Learning and artificial intelligence to automatically identify points and apply the data model based on point or entity names and historical data. This saves significant time and allows us to apply data models faster and with more accuracy.

Challenge 4: How much data modeling do I need?

It’s a common concern of data modelers and developers that they’re getting the right data for their needs. Making that concern worse, it can be nearly impossible to know what data needs to be modeled without having a set goal in mind for the digitization of your building. As a result, it can be very easy to get carried away with data modeling and build an overly detailed or overly complex model.

Solution:

Solving this problem starts with establishing a specific and measurable goal for your building’s digital transformation. Ask yourself, what is the use case and what problem are you trying to solve? Use the answers to those questions to guide the data modeling to constrain scope and only model as much as needed. For instance, will you be doing Analytics? Fault Detection? Energy Insights? Graphics? Occupant Experience? Ask --How will this data be used and am I serving that need? With those questions in mind, it is much easier to narrow in on the required information that needs to be modeled.

Challenge 5: Did I do it right?

Once a data model is complete, it’s easy to wash your hands and walk away, but it is important to verify that a complete and accurate model has been created that will handle the required use cases.

Solution

Validation tools are key to making sure that the building was modeled wholly and without errors. For example, if an air handler has a hot water valve control point, is its heating process defined as using heating hot water? Does it have a hot water relationship to the plant that serves it?

Establishing and checking relationships is an important last step in model creation. At Buildings IOT, our validation tools are built off both in-house expertise as well as the OAP modeling standards.

To learn more about our approach to addressing the data modeling challenges in smart buildings, visit the Ontology Alignment Project (OAP) page on our website.