Currently, Systems are defined as containing only equip entities. I think this is too limiting for modeling complex system ontologies.

I propose we expand the system entity definition to include containment of any other entity type (equip, device, space, point, system, site).

This would solve many problems/limitations identified with other entity types/references, (like complex relationships between equip, zone, and space). Since we could have a zone system and have any number of equip, point, space, device have systemRef to shared parent systems. (by the way, zone is essentially described in the standard as a type of system already). (multiple other forums posts about these issues, with no resolution to the problems)

I have many laboratory systems which require a broader system definition as well. And it would allow us to actually set a standard way of setting up these more complex system relationships rather than everyone coming up with their own imperfect bespoke solution due to limitations.

Perhaps sites would be the outlier here... but I have several large campuses that I work on where being able to model multiple sites as members of a larger campus system would work very well.

I can't think of any downsides.

I understand this would mean a substantial change. But I don't think it would result in a breaking change to anything existing. It really just expands the flexibility of using the system type, and the systemRef.

More philosophically... in systems theory/thinking, everything can be modeled into a system, we should try to align the standard with that reality.

This will be a good conversation to pick up on Haystack Labs WG (I've been on vacation but hope to pick up this thread soon :) ), but a few of my opinions below:

• Systems are a logical equivalent to Spaces for organization. Spaces are to physical organization what Systems are to logical organization. In that way, I think there's a good argument for children to include: system, equip, device, point but not space or site.
• I'd be interested in hearing more about the laboratory system example, but I think what you're looking to do is possible today. As a rough sketch:

edit: spaces/zones cannot use systemRef as of this post being written

id:@site
site
---
id:@airSystem
air
system
siteRef: @site
navName:"Lab Air System"
---
id:@exhaustAirSystem
exhaust
air
system
siteRef:@site
systemRef:@airSystem
---
id:@ventilationAirSystem
ventilation
air
system
siteRef:@site
systemRef:@airSystem
---
id:@hvacLabZone
hvac
zone
space
siteRef:@site
systemRef: [@ventilationAirSystem, @exhaustAirSystem]
//this ref the piece not currently supported ^^^
---
id:@dischargeVavBox (aside, not sure we have a good tag for lab supply boxes)
equip
vav
discharge
spaceRef:@hvacLabZone
systemRef: [@ventilationAirSystem]
siteRef:@site
---
id:@exhaustVavBox
equip
vav
exhaust
spaceRef:@hvacLabZone
systemRef: [@exhaustAirSystem]
siteRef:@site

This allows traversing two different kinds of relationships:

• equip->space->site
• equip->system->site

And since systems, like spaces, can contain themselves, we can nest systems into larger groups. I think there's a nice analogy here to organizing plants into a water-system that contains both chilled and condenser water systems. This gets into a larger conversation about should plant still count as an equipment, which involves its own substantial set of changes.

I think there are a lot of use cases that run in tandem for machine readability vs human readability, like being able to programmatically traverse these relationships for analytics but then visualize them in tools. As a SkySpark user, most of my "in the wild" deployments rely on that navigation, which won't be fully leveraged until SS4.

For EV charging applications I am proposing we model an evse-station as a system which may have one or more children evse-port-equip and several children points as well.

The evse-station-system may have a setpoint point that is used to control the load setpoints on multiple evse-port-equip for example.

This data model seems to align with some ideas by Adam and Mike.

@Mike, your example of the hvacLabZone is a perfect example of what I want to do to model lab zones with systemRefs. This is not part of the haystack standard today. (spaces/zones cannot reference systems).

As for sites referencing systems, I have some situations where a larger industrial system is served by siteA, siteB, siteC (usually smaller outbuildings serving a specific purpose in that campus system). There's no clean way to do this today with the haystack standard. Being able to put a systemRef on a related sites would just be a very clean way to do it.

Another case is a City Hall "complex" (for example), where the complex is made up of some smaller buildings very close to the main building. All referred to as part of the city hall complex, but each their own self contained building envelope/address in their own right. Right now, there's not a clean way to reference these related sites to one another. systemRef makes sense to me.

@Rick, great example of how points should be able to reference a parent system (points referencing systems is already possible, apparently?, even though systems are defined as only containing equips, not points, seems to be an inconsistency in the standard). I need to do this for lab systems. I think there's many logical examples we could come up with in this regard.

Also, it occurred to me that there's a couple other entities which I think should be able to reference a parent system: weatherStation, and syntheticModel (however, I currently don't need for my use cases, which is why I missed these entity types in my original post.)

Dont get me started on plant equip versus system tagging ... Worth it's own discussion, for sure.

This is not part of the haystack standard today. (spaces/zones cannot reference systems).

Thank you for reminding me, this is dredging up old conversations when the docs got put together. Added a note to my original example for future clarity.

Per https://project-haystack.org/doc/docHaystack/Systems:

>...meant to group multiple equip that serve a similar purpose.

In that way, systems can serve to group equipment based upon the function or purpose they serve. Conceptually, I always thought of a system consisting of producers and consumers. E.g., in a Chilled Water System, the Chillers & Pumps are producers, and AHUs or Chilled Water Coils are consumers.

In both the lab and site example I understand your point of zones and sites being served by a system.