Further details found on this pull request: https://github.com/Project-Haystack/haystack-defs/pull/15

Mainly adding a Systems.fandoc, additional proposed types and details to system.trio and a modification to the vrf-system in vrf-trio.

Asking for community review and input!

Purpose

The Haystack Labs WG has developed the following system tag definition and system type tag conjuncts for the community to comment on before adding to Project Haystack.

Systems are meant to solve the logical container problem that practitioners have solved in a variety of ways with existing or bespoke haystack tools. Ultimately, this provides an alternative lens for viewing a haystack database. The standard has been Site/Equip/Point for some ten years now (with space leveraged in the middle more recently). This organization provides a straightforward parallel to the physical organization of entities within a building. However, often we view buildings based upon logical organization and associations. Systems are intended to allow for a Site/System/Equip/Point perspective on things, and to do so in a standard way. Having worked with several haystack practitioners across different projects, one common problem we all seem to solve (in one way or another) is how to provide some logical grouping of entities. Often, folks will use spaces to achieve this end, or some folder-based navigation. This has led to multiple bespoke methods of achieving the same end and can make the same building look very different on the database level.

The intent is for system to provide a common foundation for practitioners to accomplish this grouping. However, this proposal is not (intended to be) overly specific in terms of implementation; hopefully there is still enough flexibility for everyone to achieve their own ends.

Another intention is that by providing a standard way to achieve this grouping, those building the toolkits for practitioners can leverage this to allow for more flexible GUIs and navigation based upon a Site/System/Equip/Point model rather than just the standard Site/Space/Equip/Point model, since now they can account for a generic methodology rather than every individual practitioner’s preference.

Proposal

For the purposes of this proposal, we are formalizing system types that are generally a part of existing Building Management System (BMS) controls vernacular. Everything starts from the parent ‘system’ type and expands based upon the ‘phenomenon’ common to that system;, more qualifier tags are added to specify particular systems. The following hierarchy is proposed by the Working Group. and Tthe associated definitions are based on ASHRAE Terminology or ISO-16739 (IFC) 6.2.3.9 IfcDistributionSystem.

New defs: (also found in the systems.trio file on github)

def: ^air-system
is: ^system
docTaxonomy
mandatory
doc:
  Arbitrary air supply system.
children: [
  {equip},
  {point},
  ]
--------------------------------------------------------------------------
def: ^air-conditioning-system
is: ^air-system
docTaxonomy
mandatory
doc:
  Conditioned air distribution system for purposes of 
  maintaining a temperature range within one or more spaces.
children: [
  {equip},
  {point},
  ]
--------------------------------------------------------------------------
def: ^air-exhaust-system
is: ^air-system
docTaxonomy
mandatory
doc:
  Exhaust air collection system for removing stale or 
  noxious air from one or more spaces.
children: [
  {equip},
  {point},
  ]
--------------------------------------------------------------------------
def: ^air-ventilation-system
is: ^air-system
docTaxonomy
mandatory
doc:
  Ventilation air distribution system involved in either 
  the exchange of air to the outside as well as circulation 
  of air within a building.
children: [
  {equip},
  {point},
  ]
--------------------------------------------------------------------------
def: ^elec-system
is: ^system
docTaxonomy
mandatory
doc:
  A system that generates, converts, distributes, and/or stores electricity.
children: [
  {equip},
  {point},
  ]
--------------------------------------------------------------------------
def: ^evse-system
is: ^elec-system
docTaxonomy
mandatory
doc:
  System of equipment for Electric Vehicle Supply.
children: [
  {equip},
  {point},
  ]
--------------------------------------------------------------------------
def: ^lighting-system
is: ^elec-system
docTaxonomy
mandatory
doc:
  Electrical system dedicated for lighting, such 
  as a fixture having sockets for lamps.
children: [
  {equip},
  {point},
  ]
--------------------------------------------------------------------------
def: ^refrig-system
is: ^system
docTaxonomy
mandatory
doc:
  Refrigerant distribution system for purposes of fulfilling 
  all or parts of a refrigeration cycle.
children: [
  {equip},
  {point},
  ]
--------------------------------------------------------------------------
def: ^water-system
is: ^system
docTaxonomy
mandatory
doc:
  Arbitrary water supply.
children: [
  {equip},
  {point},
  ]
--------------------------------------------------------------------------
def: ^chilled-water-system
is: ^water-system
docTaxonomy
mandatory
doc:
  Nonpotable chilled water, such as circulated through 
  an evaporator.
children: [
  {equip},
  {point},
  ]
--------------------------------------------------------------------------
def: ^condenser-water-system
is: ^water-system
docTaxonomy
mandatory
doc:
  Nonpotable water, such as circulated through a condenser.
children: [
  {equip},
  {point},
  ]
--------------------------------------------------------------------------
def: ^hot-water-system
is: ^water-system
docTaxonomy
mandatory
doc:
  Liquid water heated from a boiler and circulated 
  through radiators.
children: [
  {equip},
  {point},
  ]
--------------------------------------------------------------------------
def: ^steam-system
is: ^water-system
docTaxonomy
mandatory
doc:
  Steam water vapor heated from a boiler and circulated 
  through radiators.
children: [
  {equip},
  {point},
  ]
--------------------------------------------------------------------------
def: ^domestic-water-system
is: ^water-system
docTaxonomy
mandatory
doc:
  Water for domestic or commercial purposes other than 
  space heating and process requirements.
children: [
  {equip},
  {point},
  ]
--------------------------------------------------------------------------
def: ^domestic-cold-water-system
is: ^domestic-water-system
docTaxonomy
mandatory
doc:
  Potable water distribution system.
children: [
  {equip},
  {point},
  ]
--------------------------------------------------------------------------
def: ^domestic-hot-water-system
is: ^domestic-water-system
docTaxonomy
mandatory
doc:
  Heated potable water distribution system.
children: [
  {equip},
  {point},
  ]
--------------------------------------------------------------------------

Thanks for putting this together Mike. I reviewed the GitHub Pull Request and made some suggestions.

I like the push for this as part of the standard, and what you have here looks great to me. I will let others offer any deep analysis. For my part, I have attempted when time has permitted me, to implement this sort of thing on my own in my projects. Thanks Mike!

Samuel

Awesome, I love the effort to subtype the new system tag! And Matt's specific definitions are a great addition.

Hi,

Great work, we love the idea of systems. Maybe a bit late in the process but 2 questions:

1. On large locations with multiple buildings we have sometimes combined hot-water-plants with equips located in different buildings (especially pump equips). For us it seems logical to group these equips in 1 system. Is this possible in the current design? Or in other words: can systems overlap multiple site records?
2. Can equip records be part of multiple systems? For example a chiller which inputs cooling-water and outputs chilled-water?

Thanks! Coen

Coen,

#1

I think this would depend on how individual toolkits are done, i.e. would the tool consider it an "error" to have an equip's systemRef target a system from another site. I don't think that should be the case. On the larger scale, there are posts floating around to propose entities above site (portfolio, campus, etc.). If those proposals take root, I think it would make sense to allow system to have be ref'd to a site or campus or portfolio. Since they aren't part of the ontology at the moment though, I don't think it makes sense to jump the gun accounting for them.

#2

The proposal covers co-membership in systems (we actually took a long time discussing this, and then I didn't cover it very well in my writeup!)

Short answer is that systemRef can be a list, so you would be able to specify co-membership for a chiller using systemRef: [@chwSystem, @cwSystem]. In the Systems.fandoc section of the pull request, I tried to cover this at the bottom with the examples.

Handling this a different way, for instance with fooSystemRef, makes it clunkier to find out which systems an entity belongs to programmatically, and creates type explosion for the ref type tags as well.

This proposal looks awesome! So right that there's been a lot of ad hoc groupings needed for actual haystack projects. Cool to see a great definition that is so extensible.

Hi Mike,

Thank you for your response.

1. I will keep an eye out on developments on the entities above site. We already have a custom implementation for that. We are working in Skyspark so I hope that they will allow in the definition of systemRef that this is referring to a system nested under a different site. That probably belongs to another forum.
2. The definition of systemRef as list was exactly what I was hoping for. So that is great!

Hi,

This is great work! Thanks to everyone involved.

FYI - The EV charging working group is reviewing a proposal for another definition for elec-evse-system and the idea of introducing a new system called: elec-distribution-system. We will follow up with the Labs working group later.

Also, I have a few questions:

• Which system would a receptacle circuit fall into?
• How do we plan to tag receptacles and lights on the same circuit or power fed from the same distribution board?
• How would we differentiate a lighting-system from an elec-circuit or are they the same?

Thanks,

Rick

A receptacle-system or plugLoad-system could be a useful addition, which tags would need to be developed for.

Systems provide a flexible grouping method, but do not replace other relationships. So as far as a receptacle and light on the same circuit, they would both share the same elecRef and may both be members of the same elec-system(s), but one may be in a lighting-system and the other in a "plugLoad"-system.

Hi Leroy, thanks for your response. This makes sense to me.

I agree that a receptacle-system or plugLoad-system would be a useful addition.

Is there a mechanism in place to combine systems? For example, would receptacle-lighting-system be viable assuming we agreed on defining receptacle-system?

Typically I would expect lights and receptacles to be on separate circuits. However, I could see how someone may want to group together lights and receptacles for different zones of a building.