We are looking into opportunities for aligning our organization's tagging standards with Project Haystack and Xeto development, with a mind for ontological effectiveness, but we were hoping for some clarification regarding the intended use of the "system" entity. Specifically, how are system-level points intended to be modeled?
For example, an air-conditioning-system may operate multiple airHandlingEquip units to provide air at a specified temperature and pressure within a common discharge duct. Similarly, a chilled-water-system operates multiple chiller and pump units to provide water at a specified temperature and pressure through distribution and return closed loop piping. There are points that belong only to the system, including the common temperature/pressure sensors and setpoints, the system demand (e.g. request) points that inform optimization strategies, and the points related to equip staging for airHandlingEquip, fan, chiller, pump, etc.
Do these points also need to exist within an equip?
It isn't intended for the entity to be both an equip and system, is it? So in theory each chilled-water-system needs its own chilled-water-plant equip (redundantly)...
How would queries reference these system-level points using airRef or chilledWaterRef?
It appears that systems are not defined as air-output or chilled-water-output entities; is it not the intent of Project Haystack that systems represent a particular grouping of equipment? (e.g. one of multiple air-conditioning-systems within a building, as there may be several different groupings of multiple AHUs each serving their own common ductwork or indeed multiple entirely separate chilled water plants with their distinct associated loops)
Mike MelilloMon 29 Jul
Noted on improving the docs chapter, will look at some ways to improve and bring it up on the next HS labs meeting.
I think there's something happening in the idea around what a "group of equipment" should mean. In putting that together, I think the idea was for system to serve as a bucket, with little more than a few markers to say what kind of a bucket it was. So in that way, a chilled-water-system would contain the chilled-water-plant that produces all of the chilled water, as well as all of the water-input equips that are consuming it. All of the chilledWaterRef stitching still exists at a lower level between AHUs and Plant etc.
For example's sake, we've utilized system in two specific manners.
To refer to producer (plant) + consumer (downstream equips) groupings
I've found this really useful in larger single buildings or across campus facilities like in higher ed. In this case, you might have a whole bunch of different consumers of chilled-water distributed throughout a several dozen story building, but they all commonly belong to one chilled-water-system. The same concept would apply to a central chilled water or steam plant on a campus that distributes steam out to to consumers throughout the campus.
To group abstract system types, e.g., Electrical vs. Mechanical infrastructure in a Data Center
I don't know if this requires much further explanation. But its served as a useful point and central node to organize underneath.
In any case where we are using systems extensively, I personally prefer to structure navigation (uiMeta for SkySpark folks) around systems. Usually site/system/equip/point. I will say in this case, I'm a big fan of how Tridium implemented hierarchies and leveraging that for different hybrid nav trees. For example, you could have CHW-SYS using site/chw-sys/{equip + chw-ref}/point, and then have HW-SYS using site/hw-sys/.... I think it's a powerful option for operators to be able to navigate the system following a logical grouping + direction of consumption rather than just spatially through a site. FWIW, in SkySpark specifically I have forgone extensive use of system in cases where I know the user is already acclimated to or will require the traditional site/space/equip/point navigation scheme.
A point I hope was covered well enough in the docs is that systemRef is the only defined ref pointer for this piece of the ontology. Rather than have the type explosion of fooSystemRef, we chose to leverage systemRef as a list. This has the added benefit of limiting the required defs, but also allowing for co-membership. For the application and interest of building tooling towards xeto, you can define equipment like chillers to belong to both condenser-water and chilled-water systems.
To address your point about ahu equip groups... although my first inclination is to make a parent ahu-equip and then equipRef both of the others up... I don't see a particular reason to not let points live there under systems.
Also, in regards to system + equip. I don't think there's anything illegal in the syntax for one entity to be both, but your assumption is correct (to me at least!). From my vantage point, the plant is a distinct thing from the larger system which would also include everyone consuming chilled water produced by that plant.
edit: this proposal was brought through from haystack labs WG, but as i wrote the original draft i'll do my best to help work through things
Brandyn CarlsonMon 9 Sep
Sorry for taking a while to get back to this... thank you very much for your response.
A question about how you would use "system" for consumers, as you reference in your first example - it would appear that systemRef should be reserved for only producers, since the consuming equip (such as an AHU) is likely to consume multiple sources from different systems (such as chilled water and hot water). They would need to reference chilledWaterRef and hotWaterRef separately (such that you could query the associated plant's chilled water temperature, for instance, in a rule identifying broken AHU chilled water valves) given that those are different entities. Am I understanding that right?
Say you have multiple air conditioning systems (comprised of multiple airHandlingEquips) served separately by two different chilled water plants (comprised of multiple chillers, pumps, etc.) within the same building. It would seem to me that the only way to reliably query information for your broken chilled water valve rule without enforcing a particular nested equipRef grouping structure around the chilled-water-plant equip would be to instead enforce one "plant" per "system" - which in my opinion would be substantially more straightforward if Project Haystack combined the notion of Chilled-Water-System and Chilled-Water-Plant into a single entity (because they would inherently be distinct for reference). It may make sense also to do so at the Air-Conditioning-System level as well... what is the rationale for not combining these concepts if you're not using system as a hierarchical organizer? (e.g. chilled-water-plant has equip + system tags)
I'm envisioning queries along the lines of...
read(point and systemRef==readLink(@p:project:r:ahu-equip-string)->chilledWaterRef->systemRef and leaving and temp and sensor)
...which could instead be...
read(point and systemRef==readLink(@p:project:r:ahu-equip-string)->chilledWaterRef and leaving and temp and sensor)
...because in theory you'd need to be capable of querying for points within equips sharing the systemRef of the associated plant equip and not only the plant equip directly.
Air-Conditioning-System(s)?
Air-Handling-Equip-1 (could be a system, but we NEED equip/point model for combined enable, pressure, temp, etc.)
AHU-01 (chilledWaterRef: Chilled-Water-Plant-1)
AHU-02 (chilledWaterRef: Chilled-Water-Plant-1)
EF-01
EF-02
Air-Handling-Equip-2 (e.g. west bldg addition)
AHU-03 (chilledWaterRef: Chilled-Water-Plant-2)
AHU-04 (chilledWaterRef: Chilled-Water-Plant-2)
Chilled-Water-System-1
Chilled-Water-Plant-1 (could be a system, but need equip/point model for combined enable, delta temp/pressure, etc.)
CH-01
CHWP-01
Chilled-Water-Entering-Pipe
Chilled-Water-Leaving-Pipe
chilled water leaving temp sensor
Chilled-Water-System-2
Chilled-Water-Plant-2
CH-02
CHWP-01
Chilled-Water-Entering-Pipe
Chilled-Water-Leaving-Pipe
chilled water leaving temp sensor
Sorry for being so long-winded, but I thought it was worth elaborating some more...
Brandyn Carlson Mon 29 Jul
Hi,
We are looking into opportunities for aligning our organization's tagging standards with Project Haystack and Xeto development, with a mind for ontological effectiveness, but we were hoping for some clarification regarding the intended use of the "system" entity. Specifically, how are system-level points intended to be modeled?
For example, an air-conditioning-system may operate multiple airHandlingEquip units to provide air at a specified temperature and pressure within a common discharge duct. Similarly, a chilled-water-system operates multiple chiller and pump units to provide water at a specified temperature and pressure through distribution and return closed loop piping. There are points that belong only to the system, including the common temperature/pressure sensors and setpoints, the system demand (e.g. request) points that inform optimization strategies, and the points related to equip staging for airHandlingEquip, fan, chiller, pump, etc.
Do these points also need to exist within an equip?
It isn't intended for the entity to be both an equip and system, is it? So in theory each chilled-water-system needs its own chilled-water-plant equip (redundantly)...
How would queries reference these system-level points using airRef or chilledWaterRef?
It appears that systems are not defined as air-output or chilled-water-output entities; is it not the intent of Project Haystack that systems represent a particular grouping of equipment? (e.g. one of multiple air-conditioning-systems within a building, as there may be several different groupings of multiple AHUs each serving their own common ductwork or indeed multiple entirely separate chilled water plants with their distinct associated loops)
Mike Melillo Mon 29 Jul
Noted on improving the docs chapter, will look at some ways to improve and bring it up on the next HS labs meeting.
I think there's something happening in the idea around what a "group of equipment" should mean. In putting that together, I think the idea was for system to serve as a bucket, with little more than a few markers to say what
kindof a bucket it was. So in that way, achilled-water-systemwould contain thechilled-water-plantthat produces all of the chilled water, as well as all of thewater-inputequips that are consuming it. All of thechilledWaterRefstitching still exists at a lower level between AHUs and Plant etc.For example's sake, we've utilized
systemin two specific manners.I've found this really useful in larger single buildings or across campus facilities like in higher ed. In this case, you might have a whole bunch of different consumers of
chilled-waterdistributed throughout a several dozen story building, but they all commonly belong to onechilled-water-system. The same concept would apply to a central chilled water or steam plant on a campus that distributes steam out to to consumers throughout the campus.I don't know if this requires much further explanation. But its served as a useful point and central node to organize underneath.
In any case where we are using
systemsextensively, I personally prefer to structure navigation (uiMeta for SkySpark folks) around systems. Usuallysite/system/equip/point. I will say in this case, I'm a big fan of how Tridium implemented hierarchies and leveraging that for different hybrid nav trees. For example, you could have CHW-SYS usingsite/chw-sys/{equip + chw-ref}/point, and then have HW-SYS usingsite/hw-sys/.... I think it's a powerful option for operators to be able to navigate the system following a logical grouping + direction of consumption rather than just spatially through a site. FWIW, in SkySpark specifically I have forgone extensive use ofsystemin cases where I know the user is already acclimated to or will require the traditional site/space/equip/point navigation scheme.A point I hope was covered well enough in the docs is that
systemRefis the only defined ref pointer for this piece of the ontology. Rather than have the type explosion offooSystemRef, we chose to leveragesystemRefas alist. This has the added benefit of limiting the required defs, but also allowing for co-membership. For the application and interest of building tooling towards xeto, you can define equipment like chillers to belong to bothcondenser-waterandchilled-watersystems.To address your point about ahu equip groups... although my first inclination is to make a parent
ahu-equipand thenequipRefboth of the others up... I don't see a particular reason to not let points live there under systems.Also, in regards to system + equip. I don't think there's anything illegal in the syntax for one entity to be both, but your assumption is correct (to me at least!). From my vantage point, the
plantis a distinct thing from the larger system which would also include everyone consuming chilled water produced by that plant.edit: this proposal was brought through from haystack labs WG, but as i wrote the original draft i'll do my best to help work through things
Brandyn Carlson Mon 9 Sep
Sorry for taking a while to get back to this... thank you very much for your response.
A question about how you would use "system" for consumers, as you reference in your first example - it would appear that systemRef should be reserved for only producers, since the consuming equip (such as an AHU) is likely to consume multiple sources from different systems (such as chilled water and hot water). They would need to reference chilledWaterRef and hotWaterRef separately (such that you could query the associated plant's chilled water temperature, for instance, in a rule identifying broken AHU chilled water valves) given that those are different entities. Am I understanding that right?
Say you have multiple air conditioning systems (comprised of multiple airHandlingEquips) served separately by two different chilled water plants (comprised of multiple chillers, pumps, etc.) within the same building. It would seem to me that the only way to reliably query information for your broken chilled water valve rule without enforcing a particular nested equipRef grouping structure around the chilled-water-plant equip would be to instead enforce one "plant" per "system" - which in my opinion would be substantially more straightforward if Project Haystack combined the notion of Chilled-Water-System and Chilled-Water-Plant into a single entity (because they would inherently be distinct for reference). It may make sense also to do so at the Air-Conditioning-System level as well... what is the rationale for not combining these concepts if you're not using system as a hierarchical organizer? (e.g. chilled-water-plant has equip + system tags)
I'm envisioning queries along the lines of...
read(point and systemRef==readLink(@p:project:r:ahu-equip-string)->chilledWaterRef->systemRef and leaving and temp and sensor)
...which could instead be...
read(point and systemRef==readLink(@p:project:r:ahu-equip-string)->chilledWaterRef and leaving and temp and sensor)
...because in theory you'd need to be capable of querying for points within equips sharing the systemRef of the associated plant equip and not only the plant equip directly.
Air-Conditioning-System(s)?
Chilled-Water-System-1
Chilled-Water-Plant-1 (could be a system, but need equip/point model for combined enable, delta temp/pressure, etc.) CH-01 CHWP-01 Chilled-Water-Entering-Pipe Chilled-Water-Leaving-Pipe chilled water leaving temp sensorChilled-Water-System-2
Chilled-Water-Plant-2 CH-02 CHWP-01 Chilled-Water-Entering-Pipe Chilled-Water-Leaving-Pipe chilled water leaving temp sensorSorry for being so long-winded, but I thought it was worth elaborating some more...