#942 Notes on System & Plant (Re: Loops)

Mike Melillo Wed 18 Aug

Intro

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 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

navName: Primary-Condenser-Water-System
id:@pcwsys
system
siteSystem
systemSubject: condenser-water
___
navName: Secondary-Condenser-Water-System
id:@scwsys
system
subsystem
systemRef: @pcwsys
systemSubject: condenser-water
___
navName: Hot-Water-System
id:@hwsys
system
siteSystem
systemSubject: hot-water
___
navName: VRF-System
id: @vrfsys
system
siteSystem
systemSubject: refrig
___
navName: Primary-Condenser-Water-Plant
id:@pcwplnt
systemRef:@pcwsys
condenser
water
plant
___
navName: Secondary-Condenser-Water-Plant
id:@scwplnt
systemRef:@scwsys
condenser
water
plant
___
navName: Hot-Water-Plant
id:@hwplnt
systemRef:@hwsys
hot
water
plant
___
navName: CT-##
systemRef:@pcwsys
condenserWaterPlantRef: @pcwplnt
coolingTower
equip
___
navName: PCWP-##
systemRef:@pcwsys
condenserWaterPlantRef: @pcwplnt
condenser
water
pump
equip
___
navName: CWHX-##
systemRef:[@pcwsys, @scwsys]
condenserWaterPlantRef: [@pcwplnt, @scwplnt]
condenser
water
heatExchanger
equip
___
navName:Refrig-Plant
id:@refplnt
systemRef:@vrfsys
refrig
plant
___
navName:ODU-##
systemRef:@vrfsys
refrigPlantRef:@refplnt
odu
equip
___
navName:IDU-##
systemRef:@vrfsys
refrigRef:@refplnt
idu
equip

Brian Frank Wed 18 Aug

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:

  1. What systems do you model?
  2. What is the level of granularity? Is it just a single system per building, or you get into subsystems?
  3. Why do you model the systems (what kind of queries do you run?)

Mike Melillo Wed 25 Aug

  1. 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)
  2. 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
  3. 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)

Login or Signup to reply.