VRV systems

[clément bouvier]

Hi Brick forums,

I read the most of papers on the brick schema website and now I would like to learn and test the brick schema.

One of papers [1] claims "Without [...] documentation in hand, it is difficult to discern when to use a compound tag or several tags together".

This a one of pretty cool arguments because I'm not an expert in the building cooling system (even I know a little bit) and a beginner with Brick.  

If I can make a building model with Brick, it is likely to mean that  specialist building engineers might do the same ;-).

I have a couple of small buildings examples.

Most of them have one or several VRV systems [2]

I did explore definitions.cvs in the git repo [3], and there are several concepts such as:

- Brick#FCU

- Brick#Pump

- Brick#VFD

- Brick#Variable_Frequency_Drive

- Brick#Valve

- Brick#Pump_VFD

- Brick#Cooling_Valve

- Brick#Condenser

- Brick#Compressor

...

The concepts are pretty useful to represent a VRV. 

However, maybe because I'm a beginner, I have expected a kind of "tags" or an entity such as "VRV" to represent the outdoor unit of a VRV (compressor, controller, condenser, etc..)

Sorry because I'm using the haystack tag , but there is something like "dxCool".

Moreover, the refrigerant used in VRV are not "water" or "air" but more "R410A", etc...

Is there something to represent as resource this kind of refrigerant?

Finally do I need to use the most of concepts previously quoted if I want to modelize a VRV system in any building or I am in the wrong way?

Thanks in advance.

Regards,

Clément.

 

[1] https://brickschema.org/papers/HouseOfSticks-BuildSys-2019-Fierro.pdf 

[3] https://en.wikipedia.org/wiki/Variable_refrigerant_flow

[3] https://github.com/BrickSchema/Brick

[Dave Waterworth]

Hi Clement

One thing to note is what you've identified are tags - pretty much the same concept as Haystack has. But these are extensions to the base Brick philosophy of explicitly modelling each piece of equipment/telemetry point with an entity (or class) - tags can then be added to support queries etc. There's also a mechanism using python to infer Brick entities from Haystack tags - I've not investigated it though.

I'm not all that familiar with VRV's, and there are gaps in the Brick chiller modelling which is being addressed - see https://github.com/BrickSchema/Brick/issues/197, in general, a brick model might consist of a brick:Chiller entity with references to points (i.e. _:CH1 brick:hasPoint _:CH1_Chilled_Water_Supply_Temperature_Sensor) represents a chiller (CH1) which has a chilled water supply temp sensor (which is a brick:Point). This is slightly different to Haystack where you'd create an equip and a point, and then add the tags - brick does this for you if you select the correct classes. 

I suspect new classes need to be added for a VRV - a subclass of chiller perhaps for the outdoor unit, and a subclass of one of the air handling units for the indoor unit? Note air and water don't refer to the refrigerant, they're referencing the medium which is transferring the heat itself. I'm not sure how you'd represent the concept that the outdoor unit uses  R410A  as the refrigerant but it's certainly a parameter that we should consider as well -  being able to query refrigerent types over a large fleet would be a useful thing to be able to do.

David

[clément bouvier]

Hi Dave,

Thanks for your quick reply.

> One thing to note is what you've identified are tags - pretty much the same concept as Haystack has. But these are extensions to the base Brick philosophy of explicitly modelling each piece of equipment/telemetry point with an entity (or class) - tags can then be added to support queries etc. There's also a mechanism using python to infer Brick entities from Haystack tags - I've not investigated it though.

OK, so I need to focus more on the entities of brick before the brick's tagging.

> I'm not all that familiar with VRV's, and there are gaps in the Brick chiller modelling which is being addressed - see https://github.com/BrickSchema/Brick/issues/197, in general, a brick model might consist of a brick:Chiller entity with references to points (i.e. _:CH1 brick:hasPoint _:CH1_Chilled_Water_Supply_Temperature_Sensor) represents a chiller (CH1) which has a chilled water supply temp sensor (which is a brick:Point). This is slightly different to Haystack where you'd create an equip and a point, and then add the tags - brick does this for you if you select the correct classes.

Thanks, I have read the issue.

>
> I suspect new classes need to be added for a VRV - a subclass of chiller perhaps for the outdoor unit,

I see your point. A VRV can be interpreted as a chiller but instead of water, its refrigerant is directly fed in the FCU…where the evaporator is.

At first approximation for the cooling, I think that the subclassing might work.
However, there are 2 families of VRV: 2-tubes even the heating or cooling and 3-tubes for the mixing of the heating and cooling (but I have not seen yet).

> and a subclass of one of the air handling units for the indoor unit?

Generally, the indoors units are like Fan-Coil-Unit and there is an entity in the brick schema, isn't it?

> Note air and water don't refer to the refrigerant, they're referencing the medium which is transferring the heat itself.

OK, I understand. Refrigerant would be considered as a medium which take part to thermodynamic cycle in changing its physical states.

> I'm not sure how you'd represent the concept that the outdoor unit uses R410A as the refrigerant but it's certainly a parameter that we should consider as well - being able to query refrigerent types over a large fleet would be a useful thing to be able to do.

Hum…
In some brick slides or papers, the concept of resource is used. A refrigerant would be a ressource, except we might not enable explicitly the physic state for its definition because we might expect that the refrigerant changes its state during a thermodynamic cycle.

I have another beginner question:
If I try to subclass an entity, or create any relation and constraints between entities to extend the brick model, what kind of software is used to check that the extension does not give some incoherencies?


Regards,
Clément.

> --
> You received this message because you are subscribed to a topic in the Google Groups "Brick User Forum (Unified Building Metadata Schema)" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/brickschema/NNWUHGI4Tmc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to brickschema...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/048858cb-50aa-4492-919e-b524630afc1fn%40googlegroups.com.

[Dave Waterworth]

Hi Clement

Thanks for the information, I've never really looked closely at split systems and I didn't actually realise the refrigerant was transferred between the indoor and outdoor units. So I assume the outside unit contains a compressor and condenser? And the indoor unit is like the evaporator side of an air-cooled chiller?

The best place to start is https://brickschema.org/ontology/1.1/classes/HVAC

Brick uses RDF to represent the concepts, RDF uses triples i.e. which form a graph ie.

:CH1 a brick:Chiller

:CH1_CHSWT a brick:Chilled_Supply_Water_Temperature

:CH1_CHSWT brick:pointOf :CH1

etc.

You're also generally free to build up a system from components in a hierarchy, or just use a single class with a series of points. So you might model the outside unit as an equipment class which contains a compressor class which has a speed sensor point (hierarchical model), or simply an equipment class which has a compressor speed sensor point (a flat model).

I don't see a number of the VRV concepts in the schema though, I think they need to be added (Gabe should I create an issue?). My view is you want a high-level class to represent the entire system (i.e. I think it's a split-system, multi-split-system, VRV?). Then you want classes for the outside unit and inside unit. Then the required points need to be identifier. Properties like refrigerant type would be applied to the system. The state of the refrigerant could be points of the indoor/outdoor unit (i.e. for a chiller you have the condenser and chiller water supply and return temps which I think is similar - in the github issue I've identified others like refrigerant pressure/temperature, compressor suction/discharge pressure...).

I'm not sure if you'd want to create specific sub-classes for the inside/outside unit depending on which type of split system you're dealing with - do VRV's and split-systems share the same type of outdoor(indoor) unit?

I'm just learning the brick tools myself, but I've been using the python package (py-brickschema) to create and validate models. There are some resources here - https://github.com/BrickSchema (and https://brickschema.org/tools/BrickStudio but I've not used it yet)

If you create a subclass you can put it in a different namespace to brick (i.e. my:VRV a brick:HVAC) and down the track if brick adds the same class you won't have a clash. You can even then create axioms which say that my:VRV is an equivalent class to brick:VRV - although it's probably cleaner to just update your model)

Dave

[clément bouvier]

Hi Dave,

> Thanks for the information, I've never really looked closely at split systems and I didn't actually realise the refrigerant was transferred between the indoor and outdoor units. So I assume the outside unit contains a compressor and condenser? And the indoor unit is like the evaporator side of an air-cooled chiller?

Yes, exactly.

I'm also a little bit surprised because in brick there is Condenser and Condenser_Heat_Exchanger but there is not the other part of a thermodynamic cycle with the Evaporator concept whereas the both may be useful when you do cooling system.
There is only Evaporative_Heat_Exchanger…
I missed something?

>
> The best place to start is https://brickschema.org/ontology/1.1/classes/HVAC
>
> Brick uses RDF to represent the concepts, RDF uses triples i.e. which form a graph ie.
>
> :CH1 a brick:Chiller
> :CH1_CHSWT a brick:Chilled_Supply_Water_Temperature
> :CH1_CHSWT brick:pointOf :CH1
>
> etc.
>
> You're also generally free to build up a system from components in a hierarchy, or just use a single class with a series of points. So you might model the outside unit as an equipment class which contains a compressor class which has a speed sensor point (hierarchical model), or simply an equipment class which has a compressor speed sensor point (a flat model).
>
> I don't see a number of the VRV concepts in the schema though, I think they need to be added (Gabe should I create an issue?). My view is you want a high-level class to represent the entire system (i.e. I think it's a split-system, multi-split-system, VRV?). Then you want classes for the outside unit and inside unit. Then the required points need to be identifier. Properties like refrigerant type would be applied to the system. The state of the refrigerant could be points of the indoor/outdoor unit (i.e. for a chiller you have the condenser and chiller water supply and return temps which I think is similar - in the github issue I've identified others like refrigerant pressure/temperature, compressor suction/discharge pressure...).

Thanks for the issue:
https://github.com/BrickSchema/Brick/issues/198

I thought about refrigerant because I can imagine that I need a SPARQL request where I want to know the equipments which process (or take part to thermodynamic cycle) the refrigerant for instance .
Brick has properties like hasInputSubstance, hasOutputSubstance, regulates...
I don't know if we can infer the equipments along the loop of a thermodynamic cycle but that could help for fault detection, etc...

>
> I'm not sure if you'd want to create specific sub-classes for the inside/outside unit depending on which type of split system you're dealing with - do VRV's and split-systems share the same type of outdoor(indoor) unit?
>
> I'm just learning the brick tools myself, but I've been using the python package (py-brickschema) to create and validate models. There are some resources here - https://github.com/BrickSchema (and https://brickschema.org/tools/BrickStudio but I've not used it yet)

Ok, thanks. So I will test that.

>
> If you create a subclass you can put it in a different namespace to brick (i.e. my:VRV a brick:HVAC) and down the track if brick adds the same class you won't have a clash. You can even then create axioms which say that my:VRV is an equivalent class to brick:VRV - although it's probably cleaner to just update your model)

Thanks, I will follow your recommendation.

Clément.

> To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/b29ad6ff-e9b3-4c4d-9c6e-764369ae04c9n%40googlegroups.com.

[Gabe Fierro]

Hi all:

Apologies for jumping into the conversation late! I am in the middle of
assembling faculty applications, so I'll be slow on the Brick front for
the next ~2 weeks.

I'll try to address the major points I can glean from the discussion,
but let me know if I left anything out.

**Regarding modeling of resources, e.g. refrigerant**
For now, I would concentrate on making sure that the appropriate Brick
equipment and point classes are defined in the schema, and ensuring that
their textual definitions indicate what they are. It sounds like we
should be adding some VRV concepts to Brick --- I think if you can list
these under the existing Chiller issue (https://github.com/BrickSchema/Brick/issues/197),
that would be best, but you can also file an independent issue if you'd
like. It sounds like a VRV should be a subclass of Chiller; if there are
attributes of the VRV that don't merit their own subclass, let me know.
They might be a good fit for the other development effort on properties
which is happening here (https://github.com/BrickSchema/Brick/issues/189).

We have some initial modeling mechanisms for handling the actual
resources themselves (e.g. a fan might move brick:Air, a pump might move
brick:Water), but they aren't documented well enough for widespread use
just yet.

**Validating added subclasses**
For definitions that are added to the Brick schema definition, we have a
unit test suite and contributions documentation
(https://github.com/BrickSchema/Brick/blob/master/CONTRIBUTING.md) which
detail how to add new classes of equipment/points/etc and should do some
checking to ensure they are defined appropriately. We also have some
initial work using SHACL (https://github.com/BrickSchema/Brick/tree/master/shacl)
to validate Brick model instances themselves.

**Using tags**
Dave is right that the tags are essentially to help with querying (sort
of like "key word search"). The py-brickschema package (documentation
located at https://brickschema.readthedocs.io/), then you can use a
BrickInferenceSession to automatically add the tags to the entities in
your Brick model.

Best,
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/b29ad6ff-e9b3-4c4d-9c6e-764369ae04c9n%40googlegroups.com.

[Dave Waterworth]

I think it would be best to treat than as a separate concept to a chiller - for a start they heat and cool (https://commercial.daikin.com.au/our-product-range/vrv/vrv-r-heat-recovery)

I wouldn't expect a sparql query for chillers to also return VRV's, package units, splits etc.

Dave

[clément bouvier]

Hi Gabe, Dave,

Thanks for the advices.

Concerning VRV system and chiller.
I'm agree with Dave that a VRV could not be considered as a subclass of a chiller.

I looked at a little more seriously Brick [1].

At very high level, we need a thermodynamic cycle if we want to cooling down something…
The thermodynamic cycle is composed at least:
* a condenser
* a evaporator
* a expansion valve
* a compressor
* a refrigerant
The cooling circuit is inside a chiller whatever it is.
There is the evaporator circuit with the chilled-water going to AHU, FCU in any chiller.
For a water-cooled chiller there is a supplementary water circuit going from the condenser to the water tower.

Now about a direct-expansion system (VRV, multi-split).
The thermodynamic cycle components are split into 2 parts:
The evaporator and expansion valve are inside a FCU (sometimes named indoor-unit),
The condenser, compressor are inside an "outdoor-unit".
The refrigerant is circulating between the both units.

Of course, we assume here only a cooling system.

The VRV system can be a heat pump too…so
evaporator and condenser are "switched" and the expansion valve in the outdoor-unit.

Probably you know that but I wanted to emphasize that VRV subclass of a chiller seems weird…
Maybe we need also a "superclass" of chiller family and "VRV" family and this class is at least composed of previous components...

Regards,
Clément

> To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/7986647d-b9cf-4096-96a2-04ca84c867ddn%40googlegroups.com.

[Paul Raftery]

Maybe a parent class of 'heat pump' is a way to handle most of these types of equipment in a generalizable way? I gave a more detailed response in the Chiller issue on Git.

Regards,

Paul

Paul Raftery, Ph.D.

Professional Researcher 

Center for the Built Environment  |  University of California Berkeley

Phone: + 1 (510) 725-0562

To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/530B00BC-04CC-4E07-A10B-9A52EF7488A0%40gmail.com.

[Dave Waterworth]

I agree that makes sense - I've responded in the issue thread as well (https://github.com/BrickSchema/Brick/issues/197#issuecomment-736832684) 

To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/CAF1fu63ROE8mZHTOHsSfWwCon2GMSVutevCQdZMYOV5%3DNtA4xw%40mail.gmail.com.

[clément bouvier]

Heat pump is relevant but a classification about cooling or heating, cooling and heating (at the same time) could make sense too.
I put a comment on the thread (https://github.com/BrickSchema/Brick/issues/197#issuecomment-737433176) .

Regards,
Clément