VAVs and CAVs - Supply and Extract/Return VAVs

[Richard-Jackson-Arup]

device/asset description
air terminal box - variable air volume box - Supply
air terminal box - variable air volume box - Extract/Return
air terminal box - constant air volume box - Fixed Operation - Supply
air terminal box - constant air volume box - Fixed Operation - Extract/Return
air terminal box - constant air volume box - Actuator Driven - Supply
air terminal box - constant air volume box - Actuator Driven - Extract/Return

The separation of supply and extract is useful for ease of referencing systems that will tend to have both alongside each other.
The fixed and motorised differentiation is useful as it is common to miss the difference.

device/asset name
SVAV
EVAV
SCAVF
ECAVF
SCAVM
ECAVM

device/asset documentation
Provide link to a datasheet/manual/any supporting documentation
example document

[RitaLav]

We would suggest that the free text field is used in this case to provide more detailed description about the function of the unit. eg VAV-1_Supply

[Richard-Jackson-Arup]

That could work but my understanding was that when referencing for controls, the combination of item and number needed to be unique and the suffix is useful to the reader but not really properly part of the reference.

i.e. from a controls perspective VAV-101001_Supply and VAV-101001_Extract are the same thing and I would need to change the numbers.

Given the supply and extract most often come as a pair physically and operationally as a pair that will make designing and numbering much more painful.

Or have I got myself knotted up?

[JimGriffin88]

Just a thought, but would this be a reasonable use case for the recently introduced asset.type? i.e.

VAV1 may infer that it is supply by it's type (1)
VAV2 may infer that it is extract by it's type (2)

Providing names such as:
VAV1-101001
VAV2-101001

This allows you to keep the numbering paired as you mentioned?

[Richard-Jackson-Arup]

Hi Jim,

Apologies but I am new around here so not aware of the asset.type thing you describe.

That would work if it is a thing although it is making things a bit more impenetrable to the casual user (my focus is ease of information to contractors and site operatives).

The extra letters are easier and matches up with a lot of the rest of the list i.e. a category type that most people may well use and then alternative references for sub-categories if a project wants to go that way.

[JimGriffin88]

Hi Richard, no problem at all!

It's probably best if I refer you to the specification doc to have a quick read:

https://theodi.github.io/BDNS/BDNS_Specification_naming_syntax.html#deviceasset-type-asset.type

Hopefully this approach might help with your issue in this instance.