5 Misconceptions about Project Haystack

If you think Project Haystack doesn’t apply to you, let us help you debunk these common misconceptions.

It’s a naming convention

In the beginning, building automation devices and point names were limited to eight characters. Over the years, software has expanded the name field to allow virtually unlimited number of characters, but in practice, naming schemes were developed to piece together a description of what a point does. For example, area.equip.function = Floor1.AHU01.SpaceTemp. This required a “human in the loop” to decipher and translate the meaning of that name. 

Today, using metadata standards such as Project Haystack, the use of tags has replaced the naming scheme for helping data self-describe its meaning and relationships. In our previous example, the area served would be represented by tags such as space or floor, the equipment would be described with the equip tag, and the function would be described by a series of tags such as zone, air, and temp. Now with this metadata built into the database record that represents the point, any application can instantly “understand” what the meaning and purpose of this point is without any additional translation or interpretation from a human. 

It’s a lot of work to implement tagging

In comparison to naming conventions, at first glance, it appears that adding metadata is not only a lot of extra work, but remembering the tags that need to be added seems overwhelming. Traditional building automation systems built with their own data models do require additional configuration to support tags as an afterthought. Modern software applications and building automation systems have been built from the ground up using the Haystack data model. The tools and workflows in these systems oftentimes dynamically add tags as the solution is configured and utilized.

It’s only for getting data out of a system

Once a system has metadata included with the equipment and point definitions, a lot more functionality can be derived in addition to simply supporting some queries (which can be valuable as well). For example, creating user interfaces with dynamically linked data points happens automatically because the points are self-describing and the application literally builds the screen for you. Additionally, reference tags contain relationships between entities that can be leveraged to provide navigation and hyperlinking between user experiences (for example a summary screen that links to an equipment screen with no engineering required).

Imagine if equipment graphics, control routines, alarms, summaries, and O&M Manuals could be created once and be used many times across an entire project? With the use of tags, it is now possible to “relativize” any of these features so that they are engineered once and dynamically linked to all instances in a typical solution. For example, we all know the classic VAV graphic gets re-used for all typical VAVs. But now this concept applies across all functions, such as one control routine, dynamically linking to typical equipment…

It’s only one of many competing standards

There are a lot of people in the industry who take a “wait and see” mindset, not wanting to dive into one standard for fear of another competing standard becoming the dominant one. The real opportunity is to embrace utilizing metadata (tagging and data models) to start describing your equipment and points. By doing this, the data becomes self-describing and can be adopted into any standard - current or future. This future proofs your smart building and BAS independent of current protocol wars (but we really like Project Haystack). 

It doesn’t apply to me

As you can see, it does. Project Haystack is a community driven open standard model. And you can be part of that community! Learn more about the standard and join the community at projecthaystack.org and sign up for a free intro course here. To truly understand the real-world benefits of tagging and data modeling, download our whitepaper.