Hello Haystack community,

With respect to discussions happening in the ASHRAE 223 working group, as well as through discussions I've had with individuals, it seems like there is interest in trying to push aspects of Haystack beyond where we are at currently. I would summarize them as follows:

1. Defining more specific types of certain components and their associated tagsets. For example, expanding on heatingCoil to further define the substance / mechanism used to transfer heat (dx, hotWater) as well as some expectations about the controllability of that thing (single stage, two stage, etc.). A final equipment proto for this might look something like: {singleStage dxHeating heatingCoil equip}. This to me gets to the question of: "What additional metadata would we like to include about different equipment types that isn't already covered". For example, with fans, it would be nice to also have some sort of concept of how it would be controlled (on/off, multiple discrete stages and how many, or fully continuous). I think we can begin with air side systems, define the building blocks necessary, and bring up questions that 223 is currently exploring.
2. Coming up with reference implementation "guidebook / user manual / best practice documentation". The purpose of this would be to put together more comprehensive example documentation for equipment configurations. In a similar fashion to the 223 group, I think we could start off with some well documented "typical systems" that are agreed upon amongst the community as being most important in order to generate this documentation. Putting a list together of which systems we should cover would be a first step, and I welcome thoughts / suggestions. We could also probably start with G36 Figures A1 - A12 and go from there.
3. Another aspect I think we should consider is capturing typical controls information. For example, how could we capture information regarding the following:
   • Discharge air temperature reset strategy:
     • outdoor air temperature reset
     • return air temperature reset
     • zone trim and respond
   • Discharge air pressure reset strategy ...
   • Economizer control strategy ...
   • Ventilation control strategy ...
   • How is occupancy determined (select all): Schedule, Sensor, Override
   • Simple rules for defining mode expectations and how those should be conveyed. For example, if no heatingCoil is present, there would only be a cooling mode. If no economizing damper exists, then there would be no economizing mode, etc. Hopefully not super challenging, but something maybe important to get out there / take a stance on.

If it is the intention of ASHRAE to propose a semantic data model standard in the next, say, 3-5 years, we as the Haystack community should be looking into what we can do in the near term to strategically begin aligning with their modeling paradigm and define best practices. Haystack4 is a great start, but what else do we need? I think we can begin with equipment and sub-equipment modeling, then move to points.

I'm of the mindset that we can make progress quickly if we get the right people to the table. I also think that we shouldn't be afraid of "breaking Haystack", if it ends up that we want to express certain things that we are currently unable to express. Obviously, the thought is to explore the space, find out what is missing, come up with suggestions for how we can address that in Haystack, and present those findings back to the community. Maybe they get accepted, maybe they need adjustment, maybe not. I still think it is worth the exercise.

I first would like to get a sense from the community:

1. Who is interested in participating?
2. What is your expertise / application (FDD, BMS, controls eng, mechanical eng, etc.)?
3. What kind of weekly time commitment could we expect from you?
4. What other aspects do you think are important for consideration?
5. Do people think this is straying too far outside the scope of Haystack?

Curious to hear thoughts and thanks for the consideration, Cory

Hey Cory,

I'm down for this. I think there is a lot that can be done to have a fully comprehensive standard that is simple to use, which will have a positive impact on the consistency across projects implemented by different integrators.

Time is not something I have in abundance but I might be able to dedicate an hour a week.

Thanks for the initiative! Rodolfo

I feel these are all great topics, and believe the Haystack model should evolve to provide options for describing every aspect of a piece of equipment and its operation without ever seeing the actual equipment. This of course also has to be balanced with the flexibility to allow for situations were minimal information is available.

I frequently find myself trying to find ways to identify aspects of the equipment's sequences of operation, to determine the proper rules to run against it and/or properly categorize a spark as faulty operation or potential for an improved sequence, as they are often addressed differently.

To answer your questions:

1. Who is interested in participating? I am
2. What is your expertise / application (FDD, BMS, controls eng, mechanical eng, etc.)? I have experience in commercial mechanical service work, BAS Design, Energy Engineering, and Building Analytics
3. What kind of weekly time commitment could we expect from you? An hour a week seems doable
4. What other aspects do you think are important for consideration? Documenting equipment rated capacities, efficiencies, ect.
5. Do people think this is straying too far outside the scope of Haystack? Not as long as it is done in an optional way that does not interfere with a more simplistic approach when limited information is available

Hi Cory,

I'm definitely interested in participating. My background is w/ building HVAC design and controls, but I'm also very familiar with fdd, energy analysis,lighting etc.

hr/week seems ok to me.

What other aspects do you think are important for consideration? -- +1 for documenting equipment-specific data (efficiency, etc). Would also like to see design data and location/spatial information captured. Lastly, I think capturing typical controls information as you mentioned is going to be super important going forward. By way of example, a lot of information contained in manufacturer's BACNet points actually relate to configuration of control strategies (even something simple like the option to choose fan off/auto/"smart" on a thermostat). A way to standardize and convey this information is really important.

Cory, you can include me too.

Hi Cory, I am interested in furthering this conversation and it would draw us to participate in Haystack more. These are concepts we represent for our analytics but do not see as always representable in a standard way in haystack. I think it is something 223, Brick and Haystack all need.

Hi count me in ... I'm more from the ontology background, and often felt that in places haystack needed some more notational precision. Can't promise much time, though.

Hi Cory, I am also interested in being part of this.

Cory,

My company Altura is very interested in participating in this discussion. We have expanded upon Haystack tag models through our project consulting services (we call it Haystack+) to specifically include metadata defining typical controls processes such as trim & respond (based on ASHRAE GL-36) and other devices/processes not yet included in Project Haystack. We want to align with efforts to move the Project Haystack community forward on this front.

We've also built some hierarchical models for hydronic system equipment that I feel have been poorly defined thus far by the community at large (Central CHW Plant/Pri CHW Loop/CH-1/CHWP-1) relating to your point #2.

You can include me as the primary POC but we might engage other folks as applicable (or as I need to split my time).

Thanks!

Hey all - thanks for your initial thoughts and glad to see a welcome response! Based on initial comments, I have created a Title Purpose and Scope document, the contents of which are pasted below. This is just v1 and we can iterate on this as desired once we get meetings going.

---

Title

Pushing Haystack - Exploring new directions for the Project Haystack community

Purpose

The purpose of this working group is to identify areas in Project Haystack that should be further developed and refined, including:

1. Identifying areas where users currently struggle in conveying a concept and seeking to rectify the issue
2. Identifying new areas where users would like to convey concepts but for which there is currently no mechanism
3. Creating a ‘guidebook’ with community agreed upon reference implementations in order to document best practices. This initially will consist of airside systems.

Scope

Although the scope at this point is still to be further developed, the following summarizes the Working Group’s current thoughts:

1. Creating ‘equipment protos’ and building blocks for typical system components in air side systems. The initial list includes: Fans, Dampers, Heating Coils, Cooling Coils, Thermal Zones, Air Terminals, Air Handlers, Zone Equipment, Pumps, Valves, etc.
2. Define mechanisms to convey equipment design information, such as capacities, efficiencies, etc.
3. Define a set of control loops for which information should be captured
4. Develop a methodology to convey typical controls strategies and reset strategies for the control loops in (2) above.
5. Develop a set of typical equipment types for which to create models. These equipment types should demonstrate both the capability to use ‘equipment protos’ to build up equipment, convey key equipment design information, and convey key information about control loops and reset strategies.

---

Haystack admins - can we create a Working Group for this (I will be champion). The title I think could be one of the following (other suggestions welcome):

• Haystack R&D Team
• Pushing Haystack

Cory,

I'd suggest you create a new fresh post (maybe link to this one for context in the intro) and then we will make it a working group and everyone can join.

Based on your write-up, I'm envisioning this a standing WG that focuses on requirements and roadmap for things to tackle next. And most importantly attaching some priorities (because ideas are easy, doing the work is hard). But I think once an idea is generated, it probably makes sense to split it out into its own WG with leader. Or is your idea that this group would actually do the development work to define content?

If this is more of an "idea factory" group, then I'd suggest a title something like "Haystack Labs" or along those lines

I'd suggest you create a new fresh post (maybe link to this one for context in the intro) and then we will make it a working group and everyone can join.

Will do!

Based on your write-up, I'm envisioning this a standing WG that focuses on requirements and roadmap for things to tackle next. And most importantly attaching some priorities (because ideas are easy, doing the work is hard).

Yes, I think requirements & roadmapping + prioritization is a good summary.

But I think once an idea is generated, it probably makes sense to split it out into its own WG with leader. Or is your idea that this group would actually do the development work to define content?

That's a good question. My initial thought was that this group would do the development work to define content. Maybe it looks more something like having a develop branch, with each of the identified priorities / ideas branching off as a feat/abc branch (i.e. a new WG). Maybe we can start off with Haystack Labs as a standing WG and see how it goes defining priorities?