Data Modeling Deep Dive: Series Introduction and Best Practices for Modeling Fans

Hello and welcome to a new blog series on the riveting and surprisingly controversial subject of data modeling.

For this series, we’re going to assume you’re well versed in the importance of data modelling for creating an integrated data layer and have a basic understanding of what building ontologies are, and hopefully even what OAP is and why we started the project. If not, start your reading journey there and circle back. We’ll be here in the weeds for a while so there’s no need to rush it.

With this series, we plan to dive deep into the theories and philosophies behind data modelling for time-series building data and expose how we tinker with the nuts and bolts of our ontologies. We’ll talk about our own approaches to solving the myriad modelling conundrums we’ve faced in our efforts to implement a scalable standard across diverse (and global!) deployments.

We look forward to you following along on this journey through the depths of data modelling and we sincerely hope you will participate in the conversation with us!

Part 1: Fans

Alright, now that we’ve set the stage for what’s to come, let’s dive into the deep end with a “fan” favorite.

It seems fitting to kick off a data modeling series with fans – one of the most elemental parts of a building HVAC system and one of the most frequently occurring entities in a building’s data model.

Below we dig into some of the nuance around how the OAP handles fans and their points and in so doing, reveal the guiding principles that we strive to execute across all equipment types defined in the ontology alignment effort.

Briefly, Some Basics

OAP is an ontology with roots in Project Haystack and as such it leverages many of the concepts that are defined there. However, there are some important things to note upfront:

• There are base entity classes in OAP including sites, spaces, equipment, devices and points.
• Relationships in OAP generally follow the same format as in Project Haystack – entities are tagged with a relationship that links it with the referent. A relevant relationship for purposes of this discussion is “equipRef” which denotes containment by an equip and links a point or equip to a parent equip.

Fanning out from there, we continue.

What are fans, in the ontological sense?

Fans are vital air-moving equipment that typically show up in HVAC systems within two contexts:

1. Fans that run as standalone equipment such as exhaust fans.
2. Fans that are contained inside another, larger piece of equipment such as a fan inside an air handler or cooling tower.

Fan Types

In the OAP, fans are a subtype of equipment. The OAP defines the following types of fans, and they can be specified either as an equip or nested inside another equipment.

Fan

• Cooling Tower Fan
• Discharge Air Fan
• Exhaust Air Fan
  • Garage Exhaust Air Fan
• Outside Air Fan
• Return Air Fan
• Stairwell Pressurization Fan

Fans are generally sub-typed based on the class of air they deal with (discharge, exhaust, outside, return), but you will notice there are some application-specific fans that have been defined as well, such as “cooling tower fan” and “stairwell pressurization fan.”

Modelling Fan Equips

In general, if a fan operates as a standalone equipment (i.e. it is not directly contained inside a larger piece of equipment), then it is typically modeled as its own entity.

Some common examples would be:

• Exhaust fans including garage exhaust fans, lab exhaust fans or just general building exhaust fans.
• Transfer fans

When fans are contained within other pieces of equipment, they are typically not modeled as standalone pieces of equipment and rather any points associated with them are “flattened” under the larger equipment. Equipment that often contains fans include:

• Air Handlers
• Cooling Towers
• Air-cooled condensers
• Fan-powered VAV boxes

Here’s a common example of how this flattening occurs. An air handler contains a discharge (commonly called “supply” fan) and return fan and there are points associated with each of those fans. These points would get modeled like this:

Air Handler

• Discharge Fan Command
• Discharge Fan Status
• Return Fan Speed Command
• Return Fan Status

The exception to this rule is when a piece of equipment contains 2 or more of the same type of fan with identical point sets. In that case, the only way to disambiguate between the fan points would be to model the fan as separate entities. An example might be a cooling tower that contains 2 fans. Here’s how that would get modeled in OAP parlance:

Cooling Tower

• Cooling Tower Fan (modeled as sub equip nested under Cooling Tower)
  • Fan Speed
  • Fan Status
• Cooling Tower Fan (modeled as sub equip nested under Cooling Tower)
  • Fan Speed
  • Fan Status

Modelling Fan Points

When modelling points associated with a fan either on a fan equip or a parent equip that contains fans, it is important to keep context in mind. Here are some general guidelines for our approach to modelling fans.

When the parent equip is a fan:

In this case, the most generic version of fan points can be used and it is not necessary to specify the type of fan at the point level. Here’s an example:

Exhaust Fan

• Fan Speed
• Fan Command
• Fan Status

Note that while it is preferable to use the more generic fan points, it is also acceptable to use the more specific versions of points, but all points related to the fan should use the same level of specificity. For example,

Exhaust Fan

• Exhaust Fan Command
• Exhaust Fan Speed
• Exhaust Fan Status

Is acceptable, while

Exhaust Fan

• Exhaust Fan Command
• Fan Speed
• Fan Status

Is not acceptable since it mixes generic and specific versions of fan points.

When the parent equip is not a fan:

In this case, it is generally best to be as specific about the point as possible regardless of whether there are multiple fan types contained within the equipment. Here are some examples:

Air Handler

• Discharge Fan Command
• Discharge Fan Status
• Return Fan Speed Command
• Return Fan Status

Fan-powered VAV

• Discharge Fan Command
• Discharge Fan Speed

Note that in all these cases since we are flattening the points of a sub-equipment onto a parent equip, we want to be specific about what that sub-equipment is at the point level.

Parting Thoughts

Great you made it this far! I’m a big fan of yours for that.

Now, we’re dying to know your thoughts – Does this match your approach to modelling fans and fan points? Would you suggest something different? Please share any perspective in the comments.

To kick it off, a poll:

Do you spell modeling with one “l” or two? Please vote in the comments below.