This post is an attempted tackle on the concepts of system, plant and closely related to the loop conversation that's been going on. I don't think it wholly addresses all of the related issues, but hopefully it helps consolidates terminology and helps set the stage for a solution. This topic specifically came up recently during a VRF WG meeting, and this post is consolidating some notes & conversations on the topic following that (a big thanks to annie mroz for talking through these ideas).
The reason for bothering with a system tag (and any restructuring needed for it to make sense) is to have a formal part of the ontology that groups entities logically rather than physically (like equipRef / containment). I've seen and implemented various forms of plant as the parent equip for numerous entities, or used a nonphysical space representing a larger mechanical grouping of entities as a logical container for things like KPIs or other computed points (e.g., creating a space called Central-Cooling-System). All of them are somewhat bespoke, and point to the need for a formal definition.
I'll start with suggested defs with some loose documentation then dive into the explanation. The doc for plant is not intended to replace what's existing, I just want to give it context for this post.
Disclaimer: I haven't totally digested how 940 works into this, so a lot of the mentioned type explosion problems may just be solved by implementing those changes.
Defs
def:^system
doc:
"A collection of subsystems or equips representing some logical grouping for a particular purpose.
By convention systems exist within some physical or geographic entity."
is:[^equip]
___
def:^siteSystem
doc:"Indicates this is the top level system for this 'systemSubject' in a particular site."
is:[^marker]
tagOn:[^system]
___
def:^subsystem
doc:"Marker tag indicating this is system is a logical subgroup of a larger system.
Should be required/implied for any 'system' with a 'systemRef' tag."
is:[^marker]
tagOn: [^system]
___
def:^systemSubject
doc:"Common phenomenon tying together the operation of certain systems/subsystems."
is:[^choice]
tagOn: [^system]
___
def:^plant
doc:"A collocated set of equipment involved in the production of some quantity or substance.
Typically the plant produces the main 'fuel' consumed by the rest of a connected system."
is:[^equip]
___
Notes
siteSystem is intended to be analogous to the way metering systems are structured. This allows querying for top-level systems without requiring and not subsystem. The only shortcoming for this would be in a campus scenario (e.g. college campus) where there may be a campus-wide Chilled-Water-System, maybe there's a better term than siteSystem.
Not listed is the tag systemRef would refer upward to a parent system. Note that systemRef is intended not for physical containment (like equipRef) but for logical grouping. subsystem should be a mandatory on any system with a systemRef tag -- i.e. systemRef implies that this system is not the top level grouping.
I will try to illustrate how subsystem can be used in this structure to fit the primary, secondary loop use case I've seen a lot of folks talk about in Example B. Hopefully it mostly fits the bill.
plant becomes something of the central production group within a system. For instance, in a chilled, water, system, all the equips/subsystems would be consumers of chilled-water in some way. The chilled, water, plant would be any equipment directly related in the production and distribution of chilled, water, i.e. removing the heat & flow/pressure control. That makes the plant a clean container for Chillers, Pumps, and Bypass/Flow Control Valves.
Downstream AHU valves (although they do regulate the flow/pressure in some way) also add heat back into the loop and thus can't be included in the plant group.
Issues
systemSubject is the biggest thing I'm wrestling with here. It mandates how the entities in a system are related. On the plus side, it makes a lot of machine readable relationships possible. I'm not sure what the downside would be, but I could see it boxing in certain decisions. Polling for feedback there!
Also, I'm not sure if system gets fleshed out to fooSystem subtypes, or if system is just a standalone marker and definition happens on the implementation side via systemSubject. The former lends itself to type explosion, the latter can make systemRef ambiguous. Can fooRef be a list? One key point here is that an equip can be a member of two different systems. Water Cooled Chillers come immediately to mind, where they should be part of both a Chilled-Water and Condenser-Water System.
The other important point out of fooSystem is that however systemRef gets pieced together, it is not analogous to modelling energy flow. That should still be achieved by fooRef to the plant entity. Reason being the plant is the physical grouping of equipment that actually produces a substance for consumption. The system is a logical grouping to help compare one group of equipment to another group that may have a similar purpose (for instance, I can use this to have one referent entity in the database if I want to compare an Air-Cooled vs. Water-Cooled Chilled Water System of Similar size).
RE: Loops & Shared systems. There's another issue with equipment belonging to two separate systems/plants. This isn't a big deal with a water cooled chiller, because the two systems have differing characteristics that haystack currently captures. chilled vs. condenser water However, in the case of a Primary/Secondary Heat Exchanger, the problem becomes apparent. Essentially, that Heat Exchanger has two condenserWaterSystemRefs or two condenserWaterRefs. I've tried to lay out an example of this overlap in each below, variants of airRef in the first, and variants of waterRef in the second. The "solution" implemented here is to just incorporate everything as a list of systemRefs.
I'm not particularly excited about that, but it works I guess? Alternatives I can think of are:
Adopt the convention of fooSystem ref as an applied marker, basically allowing type explosion without formally incorporating it to the modelling
Formally model various types of fooSystem, which leads to the daunting task of defining the myriad ways people use things like primary, secondary, tertiary loops
Allow one system to be a subsystem of multiple other systems.
For instance, in example two below, the secondary system, could have a systemRef to both the hot and primary condenser water systems. Establishing it as a downstream system.
Examples
Example A
Central Chilled Water System, Central chilled-water cooling AHUs, pushing air to tenant owned terminal VAVs. In this example, subsequence tenant systems could just be added and VAVs group according to tenant system. I'm using this example specifically to illustrate the type explosion problem. Even if we had a airSystem type, it wouldn't be sufficient because AHU-## could reasonably belong to both the central and distribution air systems. Central for the collective base building AHU collection, distribution as a part of an individual tenant. Probably overthinking it, would welcome a simpler suggestion.
navName: Chilled-Water-System
id:@chwsys
system
siteSystem
systemSubject: chilled-water
___
navName: Condenser-Water-System
id:@cwsys
system
siteSystem
systemSubject: condenser-water
___
navName: Core-Air-System
id:@cas
system
systemSubject: air
___
navName: Tenant-Air-System
id:@tas
system
systemSubject: air
___
navName: Chilled-Water-Plant
id:@chwplnt
chilled
water
plant
systemRef:@chwsys
___
navName: Condenser-Water-Plant
id:@cwplnt
condenser
water
plant
systemRef:@cwsys
___
navName:Chiller-##
systemRef:[@chwsys, @cwsys]
or... chilledWatersystemRef, condenserWatersystemRef
chilledWaterPlantRef: @chwplnt
equip
chiller
___
navName:CHWP-##
systemRef:@chwsys
chilledWaterPlantRef: @chwplnt
equip
chilled
water
pump
___
navName:CWP-##
systemRef:@cwsys
condenserWaterPlantRef: @cwplnt
equip
condenser
water
pump
___
navName:CT-##
systemRef:@cwsys
condenserWaterPlantRef: @cwplnt
equip
coolingTower
___
navName:AHU-##
id: @ahu##
systemRef:[@chwsys, @cas, @tas]
or... chilledWatersystemRef, centralAirsystemRef, tenantAirsystemRef
chilledWaterRef: @chwplnt
equip
ahu
___
navName:VAV-##
systemRef:@tas
airRef: @ahu##
equip
vav
Example B
Primary Condenser Water, HX's to Secondary CW feeding VRF system, Heating Loop. HW Injection to SCW and HX to Domestic Water
Excuse some spillover tags from vrf working group, wanted to provide a different kind of exampleRe: Haystack Labs Call 8/18, I still have the refrigPlant concept implemented here, which would essentially be a group of ODUs producing refrigerant for downstream consumption
Thanks for these thoughts Mike. I believe the concept of a logical system that is separate from containment has been a long time coming.
Couple comments:
I think the best pattern to model systems is to follow the existing design patterns we have with equipment:
a top level system tag
using subtype taxonomy to define different types of systems such as vrf-system, chilled-water-system, etc
using a single systemRef tag for the relationship
It might be better to hold off on a siteSystem and subsystem concept. You can already infer this by lack of a system's own systemRef. Personally it doesn't feel like that is an important as the concept as the building's main electric meter.
Regarding membership in multiple systems... that might be a tough one. Certainly the systemRef could be a list of references. But it definitely adds complexity. We will need to work thru some of the use cases further
I think a good starting point would be solicit feedback on what people have been modeling as "systems" today (hvac, air, chilled-water, electric, etc). As you said, people are already doing this today. If you are doing this today, can you please answer:
What systems do you model?
What is the level of granularity? Is it just a single system per building, or you get into subsystems?
Why do you model the systems (what kind of queries do you run?)
Mike MelilloWed 25 Aug 2021
Modelled Systems
Primarily Central Production Systems (where we typically see Plants)
Chilled + Condenser
Hot Water / Domestic Hot Water
Steam Generation
Would be interested in modelling electrical distribution as well
Intending to use this to model/group different Air-Side Systems (e.g. primary/core & shell air from a base building vs. various tenant air-side systems)
Granularity
Really we're just using single systems per building
In cases with paired systems like Chilled + Condenser Water, I've been just doing a condenserWaterRef and chilledWaterRef tag pointing in both directions
Why?
Container for Global/Virtual Points that might be calculated on the fly
E.g., Occupancy/Active Mode for an airside system
A container for rolling up/visualizing KPIs or System Level KPIs that don't belong on particular equipment
Common logical reference point for all entities in a system (better than everything with an hvac tag if a building is comprised of different primary/secondary/tenant level air-side systems)
Mike Melillo Wed 18 Aug 2021
Intro
This post is an attempted tackle on the concepts of
system,plantand closely related to theloopconversation that's been going on. I don't think it wholly addresses all of the related issues, but hopefully it helps consolidates terminology and helps set the stage for a solution. This topic specifically came up recently during a VRF WG meeting, and this post is consolidating some notes & conversations on the topic following that (a big thanks to annie mroz for talking through these ideas).The reason for bothering with a
systemtag (and any restructuring needed for it to make sense) is to have a formal part of the ontology that groups entities logically rather than physically (likeequipRef/containment). I've seen and implemented various forms ofplantas the parentequipfor numerous entities, or used a nonphysicalspacerepresenting a larger mechanical grouping of entities as a logical container for things like KPIs or other computed points (e.g., creating aspacecalledCentral-Cooling-System). All of them are somewhat bespoke, and point to the need for a formal definition.I'll start with suggested defs with some loose documentation then dive into the explanation. The
docfor plant is not intended to replace what's existing, I just want to give it context for this post.Disclaimer: I haven't totally digested how 940 works into this, so a lot of the mentioned type explosion problems may just be solved by implementing those changes.
Defs
Notes
siteSystemis intended to be analogous to the waymeteringsystems are structured. This allows querying for top-level systems without requiringand not subsystem. The only shortcoming for this would be in a campus scenario (e.g. college campus) where there may be a campus-wideChilled-Water-System, maybe there's a better term thansiteSystem.Not listed is the tag
systemRefwould refer upward to a parentsystem. Note thatsystemRefis intended not for physical containment (likeequipRef) but for logical grouping.subsystemshould be a mandatory on anysystemwith asystemReftag -- i.e.systemRefimplies that thissystemis not the top level grouping.I will try to illustrate how
subsystemcan be used in this structure to fit theprimary, secondaryloop use case I've seen a lot of folks talk about in Example B. Hopefully it mostly fits the bill.plantbecomes something of the central production group within a system. For instance, in achilled, water, system,all the equips/subsystems would be consumers ofchilled-waterin some way. Thechilled, water, plantwould be any equipment directly related in the production and distribution ofchilled, water, i.e. removing the heat & flow/pressure control. That makes the plant a clean container for Chillers, Pumps, and Bypass/Flow Control Valves.Downstream AHU valves (although they do regulate the flow/pressure in some way) also add heat back into the loop and thus can't be included in the plant group.
Issues
systemSubjectis the biggest thing I'm wrestling with here. It mandates how the entities in asystemare related. On the plus side, it makes a lot of machine readable relationships possible. I'm not sure what the downside would be, but I could see it boxing in certain decisions. Polling for feedback there!Also, I'm not sure if
systemgets fleshed out tofooSystemsubtypes, or ifsystemis just a standalone marker and definition happens on the implementation side viasystemSubject. The former lends itself to type explosion, the latter can makesystemRefambiguous. CanfooRefbe alist? One key point here is that anequipcan be a member of two differentsystems. Water Cooled Chillers come immediately to mind, where they should be part of both aChilled-WaterandCondenser-WaterSystem.The other important point out of
fooSystemis that howeversystemRefgets pieced together, it is not analogous to modelling energy flow. That should still be achieved byfooRefto theplantentity. Reason being theplantis the physical grouping of equipment that actually produces a substance for consumption. Thesystemis a logical grouping to help compare one group of equipment to another group that may have a similar purpose (for instance, I can use this to have one referent entity in the database if I want to compare an Air-Cooled vs. Water-Cooled Chilled Water System of Similar size).RE: Loops & Shared systems. There's another issue with equipment belonging to two separate systems/plants. This isn't a big deal with a water cooled chiller, because the two systems have differing characteristics that haystack currently captures.
chilledvs.condenserwater However, in the case of a Primary/Secondary Heat Exchanger, the problem becomes apparent. Essentially, that Heat Exchanger has twocondenserWaterSystemRefsor twocondenserWaterRefs. I've tried to lay out an example of this overlap in each below, variants ofairRefin the first, and variants ofwaterRefin the second. The "solution" implemented here is to just incorporate everything as a list ofsystemRefs.I'm not particularly excited about that, but it works I guess? Alternatives I can think of are:
fooSystemref as an applied marker, basically allowing type explosion without formally incorporating it to the modellingfooSystem, which leads to the daunting task of defining the myriad ways people use things likeprimary,secondary,tertiaryloopssystemto be asubsystemof multiple othersystems.secondarysystem, could have asystemRefto both thehotandprimarycondenser water systems. Establishing it as adownstreamsystem.Examples
Example A
Central Chilled Water System, Central chilled-water cooling AHUs, pushing air to tenant owned terminal VAVs. In this example, subsequence tenant systems could just be added and VAVs group according to tenant system. I'm using this example specifically to illustrate the
typeexplosion problem. Even if we had aairSystemtype, it wouldn't be sufficient becauseAHU-##could reasonably belong to both the central and distribution air systems. Central for the collective base building AHU collection, distribution as a part of an individual tenant. Probably overthinking it, would welcome a simpler suggestion.Example B
Primary Condenser Water, HX's to Secondary CW feeding VRF system, Heating Loop. HW Injection to SCW and HX to Domestic Water
Excuse some spillover tags from vrf working group, wanted to provide a different kind of example Re: Haystack Labs Call 8/18, I still have the refrigPlant concept implemented here, which would essentially be a group of ODUs producing refrigerant for downstream consumption
Brian Frank Wed 18 Aug 2021
Thanks for these thoughts Mike. I believe the concept of a logical system that is separate from containment has been a long time coming.
Couple comments:
I think the best pattern to model systems is to follow the existing design patterns we have with equipment:
systemtagvrf-system,chilled-water-system, etcsystemReftag for the relationshipIt might be better to hold off on a
siteSystemandsubsystemconcept. You can already infer this by lack of a system's ownsystemRef. Personally it doesn't feel like that is an important as the concept as the building's main electric meter.Regarding membership in multiple systems... that might be a tough one. Certainly the systemRef could be a list of references. But it definitely adds complexity. We will need to work thru some of the use cases further
I think a good starting point would be solicit feedback on what people have been modeling as "systems" today (hvac, air, chilled-water, electric, etc). As you said, people are already doing this today. If you are doing this today, can you please answer:
Mike Melillo Wed 25 Aug 2021
condenserWaterRefandchilledWaterReftag pointing in both directionshvactag if a building is comprised of different primary/secondary/tenant level air-side systems)