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...
Mike MelilloTue 29 Oct
First going to try to address your questions, then add further context/my own opinions.
I would use systems to contain both producers and consumers. Sorry if my wording did not represent that properly.
It is valid syntax for systemRef to be of type list, which allows for the concept of co-membership. That is, an AHU which consumed both hot & chilled water, could be defined with systemRef: [@chwSys, @hwSys], hotWaterRef: @hwPlant, chilledWaterRef: @chwPlant
I think one of the main functions of system is to be a hierarchical organizer. This is also probably one of the more difficult bits to see value in today, because most tools like SkySpark don't easily do this in their current iteration (holding out for a SS4 beta license). Maybe better worded is that system should be another hierarchical organizer. The idea of systems wasn't to be instead of site-equip-point but rather in addition to.
I can definitely see some messier applications, like combined/dual headered AHUs where considering it as a system or series of nested equips can get subjective. I'm not sure that subjectivity is a bad thing, it will be driven by your needs and how your tooling is built.
Aside from hierarchical, I also see potential in using systems for analytics in a more loosely coupled way. Right now, we only have some hooks and inference into what equipment does by virtue of things like foo-input and foo-output. The whole fooProcess structure gets some of the way there, but not the whole way home. But basically, I would want to take your query example and do something like this:
Some fault detected on AHU-1 related to its cooling process could lead to:
//check for upstream roots
upstreamSystem: read(system and id == ahu1->systemRef)
//a different way to search for producers rather than looking at a plant ref
//might also help with complex systems with more than one producer?
producers: upstreamSystem.toEquips().findAll(eqp=> eqp.isChilledWaterOutput())
//maybe specify for fault related to chw-temp and chw-pressure
producers.findChilledWaterFaults()
//check for sibling faults
siblings: readAll(equip and systemRef == upstreamSystem and id != @ahu1).findAll(eqp=> eqp.isChilledWaterInput())
siblings.readAllFaults()
Presumably that last line could be replaced by just looking at ALL faults where the target is of the same type as the problem ahu1 had... this application gets a lot more useful when we have more than just AHUs as consumers in our system.
A lot of this is doable today, but (as far as I can tell) requires some traversing through defs() and figuring out what kind of a point or equip you're dealing with to find some axis that everything lines up on. Using Xeto/Specs instead, where you can take a target or target filter and align it with specFits() I think can drive some really sophisticated analysis. Hopefully that clears up more than it muddies.
edit: noting the above pseudo code examples contain fake functions just for readability, this is something I would like to do as an application, it is not all built into haystack directly
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...
Mike Melillo Tue 29 Oct
First going to try to address your questions, then add further context/my own opinions.
list, which allows for the concept of co-membership. That is, an AHU which consumed bothhot&chilledwater, could be defined withsystemRef: [@chwSys, @hwSys], hotWaterRef: @hwPlant, chilledWaterRef: @chwPlantI can definitely see some messier applications, like combined/dual headered AHUs where considering it as a
systemor series of nestedequipscan get subjective. I'm not sure that subjectivity is a bad thing, it will be driven by your needs and how your tooling is built.Aside from hierarchical, I also see potential in using systems for analytics in a more loosely coupled way. Right now, we only have some hooks and inference into what equipment does by virtue of things like
foo-inputandfoo-output. The wholefooProcessstructure gets some of the way there, but not the whole way home. But basically, I would want to take your query example and do something like this:Some fault detected on AHU-1 related to its cooling process could lead to:
Presumably that last line could be replaced by just looking at ALL faults where the
targetis of the same type as the problem ahu1 had... this application gets a lot more useful when we have more than just AHUs as consumers in our system.A lot of this is doable today, but (as far as I can tell) requires some traversing through defs() and figuring out what
kindof a point or equip you're dealing with to find some axis that everything lines up on. Using Xeto/Specs instead, where you can take atargetor target filter and align it withspecFits()I think can drive some really sophisticated analysis. Hopefully that clears up more than it muddies.edit: noting the above pseudo code examples contain fake functions just for readability, this is something I would like to do as an application, it is not all built into haystack directly