ESI has been implementing SkySpark for several years. Due to the scope and scale of our key projects, we have extended the Project Haystack tagging taxonomy internally to address the wide variety of systems we have encountered.

We would like to contribute our extensions to Project-Haystack. We have uniquely identified, vetted, and tagged points in the following categories:

AHUs/RTUs - > 300 data points

• Fans
• Dampers
• Heating/cooling
• Multi-duct systems
• Setpoints
• Heat wheels

Central plants - > 300 data points

• Pumps
• Primary loop
• Secondary loop
• Condenser loop
• Cooling tower / fans
• Heat exchanger

Terminal units

• Fans
• Dampers
• Zone points
• Types

Our internal standard incorporates the current Project-Haystack standard and follows the established methodology. It has been vetted by implementing thousands of sites with over 20 different control system platforms.

To submit this volume of information to the current adoption process would take many months and we would lose the opportunity to push Project-Haystack a quantum leap forward. After discussing with Brian, we propose forming an ad-hoc committee that would take one of the categories listed above and review, debate, vet and submit for publication the points identified in the selected category.

We envision this committee utilizing live web meetings as well as off-line review and discussion. We hope to have the proposed standard ready for publication in less than 4 weeks. Please respond to this thread if you are interested in participating.

Steve Evans, Nick Harker and Mike Johnston – Haystack Team – ESI.

Looking forward to participating in this thread!

I would like to follow/participate in this effort.

Great news Steve. I talked with Brian in person today too, and would love to be apart of this. We can add this to nHaystack.

Let me know when you want to do the first meeting, I'll get Mike Jarmy involved too, and we can push it into nHaystack as soon as possible.

Steve,

this is fantastic. Many thanks to you and the ESI team for taking this step, I'm sure it will assist everyone and strengthen the community.

I would love to be involved and part of this standardisation process and I look forward to assisting you and the collective team in moving this forward as fast as possible.

Cheers, Richard

Cool ! Ça promet ! :-)

Fantastic! I've been trying to tag some of our sites, and running into issues with having to make up "many" custom tags.

I'm very in being a part of this. It is very generous to share your hard work.

Dan

Fantastic! Can you send me your email addresses? We will share the google doc and schedule a web meeting to get this moving! [email protected]

Great! It will help us a lot. Yours work are brilliant. Now, I met a tough question which I could not find standard tags for boiler and chiller. Looking forward to following this effort.

Thank you

I have sent out an email with everyone who responded that they would like to participate. If you want to join us and did not receive that email then let me know.

Hello Brian, I checked email, but didn't get it. My Email is [email protected] Thank you

We would like to participate as well.

I would like to participate as well.

I would like to participate.

I would like to participate as well.

Project Haystack

I was on the goto-meeting call today. I detected some confusion in audience (although not verbalized) myself included, when trying to grasp the presenter's content and follow his verbal discussion. There may not have been full understanding nor agreement with the presenters view of the subject. The content of the presentation may be too much to grasp and respond to in the time available.

For the next session I would suggest that the materials be sent out a day or so in advance to allow everyone a chance to review the materials before the call. This would not guarantee that everyone would do so but, might increase the possibility of getting more feedback.

Doc: Haystack AHU Duct

In reference to the document provided on Google after meeting, I am having considerable difficulty understanding the initial definition. It seems to be in direct conflict with mechanical engineering design and current manufacturers products. AHU's are entities in their own right and are connected by ductwork to a space(s) being served by that system. Ductwork is used to connect to an outdoor air source to introduce outdoor air into the air stream being conditioned for delivery to the space. Ductwork provides a path for air to be returned from the conditioned space to be recycled or exhausted to outdoors. Ductwork may be used to direct the exhaust air to he outdoor space.

AHU's cabinets are a direct part of the vessel used to direct air from the mixing chamber, through filters, heating, humidification and or cooling devices to fan inlet, including fan discharge to the supply ductwork which delivers the air to zone/space.

The following quote does not reflect the above understanding. “Ducts AHU Ducts represent pathways of air flow through an air handling system. These ducts contain sensors and elements that modify the condition, pressure, or flow of the air through the system. Ducts are not considered first-class equipment at this time.”

<preamble>

I would like to propose a slight modification to the AHU discussion. Having spent the last 40 years or so working specifically with control systems their application, writing specifications, commissioning and troubleshooting, I have always considered “Air Handling Units(AHU)/Systems” as a general term applied to a specific group or types of equipment in buildings. From a control perspective I found it much easier to classify air handlers into 5 basic types, Constant Volume, Make-up Air, Variable Air Volume, Dual Duct, and Multi-zone with an allowance for special arrangements needed in laboratories or other special instances. Further discussions would be appropriate for Roof top installations or factory assembled (packaged) units versus built up units (assembled on site). Roof top units also have more than one configuration, for instance, constant volume, make-up air, and VAV.

<Proposal>

To the AHU tag, add a “type”tag, with the following choices:

Constant Volume, 
Make-up Air, 
Variable Air Volume, 
Dual Duct, (Hot deck, Cold deck)
Multi-zone – more than 2 (each having heating and cooling capabilities)
other special instances.

This approach allows point selection to be unique to the type, even though many points are repetitive between types, it avoids trying to fit certain points and the associated logic where they are not needed. For each AHU “type” a points list would be established for the type, fans would also have the appropriate points according to Constant Volume (constant speed) or Variable Volume (variable frequency drive VFD) requirements.

The use of the term “Discharge” should be limited to internal measurement ie (cooling coil air discharge temperature) (heating coil air discharge temperature). When discharge is used with AHU, the intent is not as clear as with AHU supply air temperature. When used with Dual Duct systems the significance is lost, Hot Deck coil discharge air temperature or hot deck supply air temperature are equally significant but for consistency use of “Supply” signifies the final value of the air for delivery to space. What does cold deck discharge refer to? Is there further conditioning applied after a discharge senor? In some cases humidification may be injected after the hot deck heating coil thus sensor designations should reflect the site installation.

Doc Haystack Zone Points

Zone or space sensors should be identified with the space they are located in, rather than with the AHU directly. The zone-ref tag should be used to identify the source of the conditioned air.

I believe that an important piece of equipment has been left out of the discussion, the “Terminal Device”. Terminal devices come in many configurations, such as Variable Air Volume, Variable Volume with bypass damper, Constant volume box being feed by hot and cold deck air (dual duct), and Personal variable volume units or fan powered box.

The present zone point list contains point names that are inappropriate eg. Humidity set-point. Humidity is never controlled locally in the space thus a set-point has no function.

It should be noted that more than one zone may be being served by a single AHU, the the term zone may not be helpful to identify the actual space being served. Space is normally identified by the building floor and the orientation of the space North, South, East and West or interior. The term zone lacks this orientation description. Point names need to reflect space identification.

I agree. It was quite a lot to take in on the short call. We have been having a hard time tagging our sites without a document of this level of detail. It isn't worthwhile in our opinion unless you are going to follow a well thought out tagging model, and unless the tagging model is flexible enough to describe as-built field conditions.

I think I like having it tagged as proposed.. lets draw an analogy to a plant.

Would your equip be the "plant"? Or would you equips be a chiller, boiler, pumps, and so on? Lets say that there is a final leaving sensor from a complicated plant... which equip under the plant would you associate this with? It doesn't belong to any equipment except the pipe right? (I'm pretty sure the "duct", thinking extends across their proposal.)

Where an ahu is really a fan, compressors, dampers, ductwork and so on.

I think the different types of systems should be "tagged" with the same thinking.

In the field / as-built (sometimes as designed), systems are pretty crazy, and as owners modernize and make improvements, existing job conditions for retrofits (especially plants, and built up ahus) don't always fit neatly into one category.

Question that may help me is with the proposed tagging model how would we tag points for a Constant Vol unit with several zones of reheat (not multi-zone). Where each zone of reheat has a space sensor, staged heat control, space setpoint, and discharge air temp. Would you make the reheat unit an equip? With a duct, and space under it? Which would be associated with the parent AHU?

Dan

I agree its a big chunk of stuff, but I think its good to take a look at the whole picture of an AHU to see how all the pieces fit together. I have a few take aways that I'd like to break out to begin the discussion.

Regarding duct vs cabinet, does this actually make a difference? Do we need to make a distinction b/w this? I'm assuming that sensors associated with discharge, return, etc don't really need to be specifically tagged as being in the cabinet or in the duct work do they?

The issue with constant volume, variable volume, etc is probably best picked up off our existing discussion under topic 85 - my post on May 17th has a specific proposal which we should tweak/rework. The twist is that ESI's stuff probably reworks the idea of multi-zone into more of a multi-duct terminology. But I say we use that topic to continue discussion on that specific topic. I think its orthogonal to much of the other new stuff just proposed and can be tackled on its own (in more manageable chunk).

Brian, The issue of duct versus cabinet (cabinet is not sacred) does matter. The use of the word duct is sacred, as it has been used in the HVAC industry for years) The definition of duct in the ESI docs is inconsistent with how the industry builds air handling units. Today a large number of units are factory assembled (packaged)and shipped as a unit. There is no ductwork associated with them. On site the units are connected to ductwork that connects to the space being served and to outdoor air source and exhaust to outside. Most such units have sensors, valves and dampers mounted internally during assembly.

Your point about sensor location is influenced by its location and distance (settling time) from mixing, heating or cooling functions. More over sensors placed in the air stream before a fan (assuming the fan is the last element the air passes through) will be influenced by the heat of the motor (many motors are mounted directly in the air stream) and fan friction during its passing through the air handling unit.

Your comment "I'm assuming that sensors associated with discharge, return, etc don't really need to be specifically tagged as being in the cabinet or in the duct work do they?" The answer is yes/maybe. The choice is yours and will impact the accuracy of your analysis you are looking for. I have seen cases where temperatures will increase from 3 to 8 degree F. just passing through a fan.

Brian, Further to your last comments "The issue with constant volume, variable volume, etc is probably best picked up off our existing discussion under topic 85 - my post on May 17th has a specific proposal which we should tweak/rework. The twist is that ESI's stuff probably reworks the idea of multi-zone into more of a multi-duct terminology."

It is not clear to me why you would not want to know the type of air handler you are dealing with. Performance wise each type has it's unique characteristics and performance expectations. In my view adding a type tag to each AHU will help identify performance expectations as well as system configuration issues (placement of dampers and valves) as well as permit point lists which are already suited for the application thus permitting quicker installation choices for installer/user.

The use of multi-duct versus multi-zone: Multi-duct does not give the user much information about anything,(multi duct could be splitting to ductwork to navigate around an obstacle and reconnect on the other side). Multi-zone on the other hand clearly indicates that more than one zone is being supplied. Therefore Multi-zone is a clear choice for this.

Regarding the process - thanks for the feedback. A few things became clear after our first meeting and we are more than willing to change.

It was a lot to consume in 60 minutes. To Brian's point, we decided a complete overview of an entire system would help the group with a wide, overall picture of our standard and methodology. We certainly didn't think we'd be able to understand, debate and agree upon an entire system within the confines of a 60 minute webinar.

It was also apparent that an open dialogue via webinar with roughly a dozen participants wasn't going to work very well.

Going forward, sharing the docs beforehand is certainly a good idea now that there is some familiarity with the format and our thought process.

As far as an agenda for this coming Friday, I think the current participants should suggest what the first few topics need to be. I'd assume higher level concepts need to be addressed first.

Winston, the multi-duct comment regarding "to navigate around an obstacle" really doesn't apply. With all of these things it is about the final destination, not the journey of how the air gets there. Anyone that has spent any time in a mechanical room would likely agree that an AHU does not look like the "H diagram" representation that most of the industry uses on their graphics. The AHU itself is often a box, with twisting ductwork coming in from multiple points. Often multiple returns join into the duct before it connects to the unit. Some sensors are located within the cabinet that is the "physical AHU" like averaging sensors. A single point sensor is usually located outside of the physical cabinet, inserted into the ductwork through a hole drilled in. Ultimately arguing about relatively minor issues like this don't advance tagging. The duct temperature sensor located a couple of feet beyond the cabinet, or the duct pressure sensor located 2/3rds the way down the ductwork are part of the larger system that is the AHU. The AHU on it's own cannot serve the zone, just as the ductwork needs the AHU to function. They belong together as a complete system, and are both components of it. Tagging sensors/dampers/coils with a location (cabinet, duct) and function (return, supply, exhaust) may be beneficial in helping to build a better understanding of exactly what data is being represented, but I would like to hear some other opinions on it.

One quick clarification on the usage of "Duct" in the AHU Duct Points document: Each "Duct" was meant to represent a specific node in the path of air through the system, similar to Brian's diagram in the AHU Documentation. Ducts were not meant to represent the physical ductwork which connects the air handler to terminal units, zones, or other air sources. Ex: discharge and exhaust tags represent the points where air exits the AHU system bounds. To address Winston's question above, in this definition, the sensor must be after all conditioning elements to truly qualify as a discharge or exhaust point.

Michael and Nicholas, The main focus of my comments has been to keep Haystack on track and with continuity with standard MEP standards established through ASHRAE and other building code standards setting bodies. Introducing new terms (or redefining their meaning) will be shied away from by the industry. This would not be helpful for Haystack.

Michael made reference actual field installations where ductwork may make some very unique and strange changes of direction and do not reflect the traditional lazy "H" (H on it's side) that has been used schematically for many years. My perspective here is to convey to the data user the significance of the data received. I am not suggesting that point tags indicate the exact sensor location with the exception of sensors providing data that does not truly represent the physical properties of the fluid being delivered to the space/zone. There are many cases where there can be discrepancies where sensor placement is of concern. The diagram in the AHU Documentation would be better represented by the traditional lazy "H". This would present data users with a clearer understanding of the significance of the data being evaluated.

Nicholas, the use of the word "duct" as you have used it in the definition of the AHU document does not concur with industry understanding and use of the term. There also seems to be a difference in understanding of the use of the AHU term itself. It is true that the ductwork connect to the AHU, but generally is not part of the Air Handler itself. The key here is that an AHU is a "unit" as it's name implies. An Air Handler is the package that might be delivered from a manufacturers factory or built on site. What is added on site, the ductwork and piping, is beyond the AHU but necessary for the operation and delivery of the services it supplies.

The examples you used at the close of you comments do not reflect the point I think you were trying to make. One would not add sensors outside an exhaust opening. The discharge point does support your point about being after all the elements of the AHU's conditioning functions including the fan itself.

Winston,

I would be more than happy to replace "duct" with "section" in the proposed documentation if that term is more agreeable to the community and it will avoid any further confusion. (Note: the tag duct was not part of any of the points with the exception of the multiDuct proposal) Again, The purpose of that distinction was simply to indicated where in the "Lazy H" the point is located. Often, that corresponded to a boundary of the cabinet and the duct, thus the choice of words in the original proposal.

We've examined the process to date and suggest the following changes. This will be the focus of our call tomorrow.

1. The conference call concept for open dialogue is not practical. If all connections are un-muted, the background noise is intrusive. Furthermore, getting a quorum of participants has been difficult. Going forward, we suggest only having a conference call on an as-needed, as-requested basis.
2. Conceptually, we suggest a process like this:
   1. A new topic is posted on Monday. Links to supporting documentation are provided.
   2. Between Monday and Wednesday, comments are offered. We would like a single comment representing each organization. Brevity and clarity is always appreciated.
   3. Thursday morning, comments are consolidated and voted upon. One vote per organization.
   4. Friday, votes are tallied, modifications made to the original proposal and it is subsequently published.

The intent of this process is not to eliminate debate and dissent. It is simply to drive the community to a timely conclusion without endless debate and dissent. Our end game is to create a well thought out tagging taxonomy in a timely fashion and we are missing the target in that regard.

As always, we are open to suggestions.

Steve, Mike, Nick - ESI Haystack Team

With respect to moving forward, let me say I've been down similar roads before, it is not easy to get everyone on the same page together. Conference calls only work with a very specific topic and not allowing divergence to other topics on the way (challenging).

Looking at Steve's proposal, I am not clear just what is intended. Creating a "new" topic for each Monday does not seem productive. Many of the existing posts have been up for a considerable time, it seems without resolution. This is discouraging to those who took the time to post the issue and is likely to cause that person to loose interest.

I would propose that an agenda be drawn up including a detailed list of issues that need to be addressed.

I would further suggest that issues dealing with things other than tag naming be separated to a sub forum so that those who are not active programmers can focus on the big picture items.

I would also suggest that the main documents be viewed from a similar perspective, all issues pertaining to tags be put together and topics pertaining to programming and implementation be in a separate chapter(?). I consider both to be important, however not all interested parties are programmers. Personally I have not kept up to speed with new techniques for the last five years or so (an eternity?).

I feel that the foundational matters are essential to have in place to build on so the work stays on track. I feel we are not focused on matters that are substantial.