HVAC_Equipment and feeds/hasPart relationships

[danie...@csiro.au]

Hi everybody.

I have some questions relating to SHACL shapes on HVAC_Equipment in Brick 1.4 and 1.3. I haven't been able to find answers here or in the github issue tracker. Although I'm pretty certain there's at least one bug, I thought it was worth raising here for discussion rather than going to the issue tracker immediately.

The shapes in question are:

```
    sh:property [ sh:or ( [ sh:class brick:HVAC_Equipment ] [ sh:class brick:Valve ] [ sh:class rec:Space ] ) ;
            sh:path brick:feeds ],
        [ sh:or ( [ sh:class brick:HVAC_Equipment ] [ sh:class brick:Valve ] ) ;
            sh:path brick:hasPart ] ;
```

Observation 1, regarding tanks...

In Brick 1.4, we have the hierarchy:

- Equipment
- Tank
- Storage_Tank
- Water_Storage_Tank
- Hot_Water_Storage_Tank, Chilled_Water_Storage_Tank

The descriptions for these last two are:

"A tank designed to store hot water in an HVAC system."
"A tank specifically designed to store chilled water in HVAC systems."

However, neither is actually a subclass of HVAC_Equipment. So it appears that although at least some of the Tank subclasses are intended for use in HVAC systems and/or loops, it is always a SHACL violation for a model to have any HVAC_Equipment feed any tanks, or for HVAC_Equipment to have tanks as parts.

Observation 2, regarding Water_Distribution...

The description of Water_Distribution says "Utilize a water distribution source to represent how water is distributed across multiple destinations (pipes)". This class is not a HVAC_Equipment in 1.3 or 1.4, but given such a broad description it seems reasonable that it might be connected via 'feeds' to HVAC_Equipment. However, HVAC_Equipment subclass instances can't feed Water_Distribution instances.

Observation 3, more generally...

HVAC_Equipment may only directly feed other HVAC_Equipment, Valve or rec:Space (brick:Location in 1.3). However, it does not appear to be forbidden for an Equipment to directly feed an HVAC_Equipment. This permits some (not all) linear topologies of Equipment and HVAC_Equipment, but not the reverse, and not loops. e.g., a Cold_Water_Storage_Tank (a non-HVAC Equipment) could feed a Pump (an HVAC_Equipment), but a Pump can not feed a Cold_Water_Storage_Tank.

So, my questions are....

* Was it originally expected that the Hot_Water_Storage_Tank and Chilled_Water_Storage_Tank classes should be HVAC_Equipment? If not, is there a workaround to allow instances to be fed by HVAC_Equipment types?

* If some of the tank types were patched to become HVAC_Equipment, would it then be a problem that instances of those types would no longer be able to feed Water_Distribution instances?

* If we can't use a Water_Distribution downstream of any water-carrying HVAC_Equipment type, then is there a workaround, or should we simply not be attempting this? In other words, is this a bug, or have I misunderstood the purpose of Water_Distribution?

* Was the asymmetry in this shape (Equipment can feed HVAC_Equipment, but not the other way around) intentional, originally? And was this shape deliberately retained from 1.3 to 1.4, or did it just sort of hang around? Put another way, what is it really there to enforce in Brick 1.4? Could it safely be removed?

* How bad an idea would it be for us to privately or internally patch Brick to say that "all water-carrying equipment are HVAC_Equipment", to just make these validation problems go away? :) Or can we just downgrade / remove / ignore this shape and its violations?

* Finally, is it perhaps too limiting that HVAC_Equipment can only ever be composed of other HVAC_Equipment? This is probably less of a limitation than the feeds relationship (since you can model systems rather than compositions) but it seems to arbitrarily preclude an HVAC_Equipment composition from including Equipment like meters, relays or motors.

Thanks! :)

Dan. 

[Gabriel Fierro]

Hi Dan!

 

Thanks for the deep dive here. There are two things going on:

 

1. Some awkward modeling to get around our lack of pipes/etc. I would say this is more or less addressed in Brick 1.4 with support for connections from 223P (https://docs.brickschema.org/modeling/connections.html). Unless there’s a great reason to keep Water_Distribution, we may want to just remove it. Its role is more than satisfied by pipes/connections in 223P
2. We may have missed editing some shapes when moving things around, hence the inconsistencies.

 

Reading through your comments, I think it’s probably more sensible to keep Tanks out of HVAC_Equipment (because they really aren’t specifically for HVAC), and then amend the shapes so that they can interact with Tanks. There’s also no good reason nfor the asymmetry of “feeds” as it relates to HVAC equipment, so we can patch that too.

 

I can probably address this in an upcoming patch version of Brick. Is there a system diagram that I can model using connections/tanks/etc to use as an example?

 

Thanks,

Gabe

 

--
You received this message because you are subscribed to the Google Groups "Brick User Forum (Unified Building Metadata Schema)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brickschema...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/592ea6b5-65e0-4833-a3bd-080ac2d51c0en%40googlegroups.com.