I tried poking around the site and Haystack4 documentation, but I get the feeling I'm not looking in quite the right place. Would appreciate some info to point me in the right direction, as I'm guessing at least part of this conversation has already taken place.

Short version: How to treat storing equipment design data that's been (I think) more the purview of BIM, facility asset/equipment management, etc.?

Details:

But, here's the situation:

I have an equip, an ahu.

The ahu was designed with a certain outside air flow: a number on the mechanical plans used to size and select the piece of equipment that is then installed. Let's say it's in cfm.

I want to compare the value from an outside air flow sensor to this design value. What is the appropriate way to model this design value so it's referenced to the ahu?

My first thought was min outside air flow sp. In an air system with an economizer, this design outdoor air is regularly referred to as "min outdoor air" or similar.

But, if you have a system with CO2-based demand-controlled ventilation and an economizer, the design outdoor air is neither the max or the min that the unit will see.

You could go down a road that outlines a max outdoor air flow setpoint when not in economizer mode, but I think that may lead to unnecessary complexity when you really are looking for a "static" point like design outside air flow.

EDIT: Realized that having a static value for a historized point probably isn't really the best way to go for multiple reasons, so still unsure. Maybe a consistently-named ahu-specific tag is the way to go.

Hey Joseph - I think this is a great time to bring up these questions. I think the AHU WG would be the best place to start - we have an upcoming meeting next week, for which the current agenda is as follows:

• Distinguishing minimum outside air dampers and economizing dampers
• dxHeating/heatPump interactions: https://project-haystack.org/forum/topic/797
• Dedicated outside air system VS makeup air unit
• Whether RTU should be an AHU sub-type or just a feature tag
• How to support multiple heating or cooling sources (primary/secondary)
• Open forum for any additional ideas

I also think it makes sense to try and embed some mechanical design information into Haystack - so let's do it!

Typically, these "design" or "face plate" values would be added as number tags directly on the equipment. I don't think you would want to model them as points since the values don't change over time. You can then reference these equipment tags in your rules or custom reports and compare to actual flow point values.

I have played with several models of including system design and rating values in Haystack models. None have seemed ideal, but I have flushed out issues with some approaches.

One of the first things I ran into is making sure that the ratings data is not confused with trended data points. For example one of my first mistakes was adding a tag like voltage:460V, but would then confuse the voltage tag with the volt marker tag in searches for actual voltage trend points. So I started using ratedVoltage: 406V which seemed much less confusing.

Similarly I wanted to document the make, model, and serial number of equipment such as an RTU. However, I realized those tags could be confused with the BAS controller make and model, so I started using equipMake:"Str", equipModel:"Str", equipSerial:"Str".

Next was capacity ratings, I started off putting them on the command point such as on a heating point adding ratedCapacity:150kBTU. This initially seemed like the best approach since other tags on the point would identify the specifics of the heat such as location. However, in a multi-stage unit it can be difficult to determine were to put the rating tag and/or how to divide the total capacity between stages. I also found issues were not all data points existed, but still wanted to record the capacities for consistency or reporting.

My most recent attempt is adding a series of rating tags at the equipment level. This seemed fitting because we already include the type of heat or cool at the equipment level and it allows all the data to be imported from an equipment schedule off a drawing even if the actual points don't exist. Here are some of the points I have been using:

• supplyFanHP:0hp
• supplyFanFlow:0cfm
• supplyFanCntrl:"none" options: none, vsd, igv, bypass, dischargeDpr
• coolCap:0tonrefh
• coolEff:0EER
• preheatCap:0kBtuh
• preheatEff:0%
• reheatCap:0kBtuh
• reheatEff:0%
• reheatType:"elecHeat" options:elecHeat, gasHeat, heatpump, hotWaterHeat, steamHeat
• ratedOAFlow:0cfm

This is far from a flawless method, and just throwing it out there for discussion. I do feel it is very important to have a way to incorporate as much information about the physical equipment as possible. I frequently integrate this information into energy modeling and fault costing. I also think this is increasingly important as the people doing the analysis get further removed from the actual site. While this information is not always available it can be imperative to putting the trend data into proper context and magnitude.

Thanks for sharing @Leroy. We've developed a very similar system, but all of our tags start with design to avoid conflicts with existing Haystack marker tags. For example, designDischargeAirFlow, designOutsideAirFlowMin, designChilledWaterPower, etc.

My least favorite part of this solution is that we often end up mashing together normal haystack tags into a single camel-cased version: discharge air flow -> designDischargeAirFlow, etc.

I definitely think that a much better solution is possible and that the community should work together toward a it.

The one concept that I see is: coolingCapacity

which is limited in the sense that its definition is tied to a chiller, but is a start.

The notion of adding design in front of everything doesn't seem like the worst - it atleast makes it easy to understand conventionally.

I think it would be useful to come up with a list of design concepts we would like to store within Haystack, as well as to which equipment these would likely be applied. Leroy's list gives us a solid start.

Quick Thoughts:

• Difference between a concept like preheatCap and heatCap applied at the AHU? Could we just use heatCap or heatingCapacity to align with existing coolingCapacity?
• Can we untie the coolingCapacity from a chiller and make it generic?

Jay - maybe makes sense to just continue our AHU WG meetings and throw this conversation into the mix as well?

On AHUs with multiple heating coils or sources it is important to differentiate tags like preheatCap from heatCap.

For example from an energy estimating perspective if an AHU has a preheat coil with a capacity of 100kBTU and a heating coil with a capacity of 50kBTU, the values would need to be differentiated to translate a heat cmd or preheat cmd to an estimated energy input or output.

I often see multiple heating sources in units, and they can typically be defined by preheat, heat, or reheat. However, while it can occur it is very rare to see multiple cooling sources in one AHU.