The Advantages of Using Haystack
Image courtesy of [Caliphoto] via Getty Images
The building automation industry continues to hear more and more about these things called haystack tags, haystack servers, etc., but what exactly are they? There seems to be much confusion and knowledge gaps depending on usage, training, and job roles. First and foremost, haystack, at its core, is an attempt to standardize the way a point is identified and categorized, i.e., a temperature sensor in a room or a flow on the chiller. Any data the automation system brings in is referred to as a point. The core problem haystack is attempting to solve is, “How can code, logic, alarming, and graphics be standardized if every customer wants to name their points differently?” If one customer requires a zone temperature to be labeled ZN-T and another prefers Zone-Temp, how can technicians link their logic to identify those as the same kinds of point? If this problem could be solved, it would create enormous amounts of reusable work, save time, lower costs, and streamline interoperability between automation systems.
The tagging system tends to scare some people off, but, in reality, it is very intuitive. There are three major categories in the hierarchy of tagging. The first is a “site,” which is the location an automation system is controlling. Everything referenced within a site is identified as “equip,” which is short for equipment. Then, there is a “point,” which is the actual point data is read from. Points roll up under equip, and equips roll up under site.
For example, let’s assume a technician is adding a piece of equipment called an air handler to a site. That equipment would be tagged “equip” and “ahu.” Now, let's also add a VAV box to the site. That piece of equipment would be tagged “equip” and “vav.” The beauty here is that equipment can be named whatever a technician wants and can even be presented in multiples: AHU-1, AHU-2, VAV-1, VAV-2, and so on, but equipment may be categorized beyond only its name. Graphics can now be added to each of these AHUs by referencing the tag names “ahu” and “equip.” Alarms can be placed on all the VAVs by referencing “equip” and “vav.” These points could also be pulled into another haystack server that understands immediately the type of equipment being addressed.
Under each piece of equipment, points exist. For example, if a VAV's points are tagged, at a bare minimum, data will represent a temperature sensor, temperature set point, airflow sensor, airflow set point, and damper command. Every point is going to be categorized as either a “sensor” or a set point (sp). Sensors are non-commandable points, and set points are commandable. These points are generally tagged accordingly:
Zone Temperature (air, temp, sensor), Zone Temperature Set Point (air, temp, sp), Airflow (air, flow, sensor), Airflow Set Point (air, flow, sp), and Damper Command (damper, cmd).
These tags can now be used to make changes to any of these points without having to reference the point name itself. This adds to the tremendous ability to reuse and standardize processes between multiple building automation sites. If trends need to be added to the damper commands, they can be added by referencing “damper” and “cmd.” If graphics are built in a haystack-compatible system, a tech can design them to reference the tag names and quickly replicate them across multiple units.
The building automation industry continues to hear more and more about these things called haystack tags, haystack servers, etc., but what exactly are they? There seems to be much confusion and knowledge gaps depending on usage, training, and job roles. First and foremost, haystack, at its core, is an attempt to standardize the way a point is identified and categorized, i.e., a temperature sensor in a room or a flow on the chiller. Any data the automation system brings in is referred to as a point. The core problem haystack is attempting to solve is, “How can code, logic, alarming, and graphics be standardized if every customer wants to name their points differently?” If one customer requires a zone temperature to be labeled ZN-T and another prefers Zone-Temp, how can technicians link their logic to identify those as the same kinds of point? If this problem could be solved, it would create enormous amounts of reusable work, save time, lower costs, and streamline interoperability between automation systems.
The tagging system tends to scare some people off, but, in reality, it is very intuitive. There are three major categories in the hierarchy of tagging. The first is a “site,” which is the location an automation system is controlling. Everything referenced within a site is identified as “equip,” which is short for equipment. Then, there is a “point,” which is the actual point data is read from. Points roll up under equip, and equips roll up under site.
For example, let’s assume a technician is adding a piece of equipment called an air handler to a site. That equipment would be tagged “equip” and “ahu.” Now, let's also add a VAV box to the site. That piece of equipment would be tagged “equip” and “vav.” The beauty here is that equipment can be named whatever a technician wants and can even be presented in multiples: AHU-1, AHU-2, VAV-1, VAV-2, and so on, but equipment may be categorized beyond only its name. Graphics can now be added to each of these AHUs by referencing the tag names “ahu” and “equip.” Alarms can be placed on all the VAVs by referencing “equip” and “vav.” These points could also be pulled into another haystack server that understands immediately the type of equipment being addressed.
Under each piece of equipment, points exist. For example, if a VAV's points are tagged, at a bare minimum, data will represent a temperature sensor, temperature set point, airflow sensor, airflow set point, and damper command. Every point is going to be categorized as either a “sensor” or a set point (sp). Sensors are non-commandable points, and set points are commandable. These points are generally tagged accordingly:
Zone Temperature (air, temp, sensor), Zone Temperature Set Point (air, temp, sp), Airflow (air, flow, sensor), Airflow Set Point (air, flow, sp), and Damper Command (damper, cmd).
These tags can now be used to make changes to any of these points without having to reference the point name itself. This adds to the tremendous ability to reuse and standardize processes between multiple building automation sites. If trends need to be added to the damper commands, they can be added by referencing “damper” and “cmd.” If graphics are built in a haystack-compatible system, a tech can design them to reference the tag names and quickly replicate them across multiple units.
Tags are not just limited to the recommended standard. There may be a special piece of equipment that needs to be tagged as critical and received separately. Or, a certain style of unit may need to be linked to a specific style of graphic. Once the basics have been mastered, tags can be used in many different and unique ways.
The one thing people tend to not realize is that haystack itself is not just talking about a tagging standard, it is also a communication standard. If an automation system is referred to as a haystack server, it means it can communicate with other haystack servers and clients. It outlines a communication API that standardizes the way point data can be written to and read by other devices and servers. Points may also be brought in from any system to another, and vice versa, when this standard is followed. In simple terms, haystack to haystack is seamless.
Why is this an important step forward? Automation systems, like everything else in the world, are becoming increasingly more complex with more and more points and data to capture. Having a way to replicate a process, regardless of the naming convention, is a tool everyone should be embracing right now. Anything that embraces system interoperability is beneficial to the industry and its customers.
James Regan James Regan has been working in the building automation industry since 2013. He started as a controls technician for Johnson Controls, working primarily in critical hospital environments. He moved on to an energy engineering role optimizing the automation systems of hospitals with a major focus on maintaining proper air quality settings as efficiently as possible. In 2018, he accepted a role as building systems analyst with Piedmont Service Group. In this role, he supported efforts to increase efficiency through identifying poor sequences, faulty field devices, or failing mechanical equipment. He currently is the analytics manager overseeing the building analytics platform where he supports Piedmont Service Group and CMS Controls with optimizing or continuous commissioning through analytics.
Looking for a reprint of this article?
From high-res PDFs to custom plaques, order your copy today!
