BDNS for equipment type tagging / custom tags

[jgunstone]

• BDNS is currently predominantly designed for asset tagging during the as-built phase of a design
• It outlines compliant asset naming syntax whereby every unique asset has its own unique tag.
• at the last meeting we discussed using BDNS abbreviations to tag "types" of equipment, at Max Fordham this is how we are using it during the design stages (RIBA Stage 2 - 5) so I'll outline our experience

note the below is presented for discussion - and does not yet outline a proposal about how this might be supported in BDNS...

Broadly, common practice follows like so:

1. Major plant items

• e.g. main electrical distribution equiment (panel boards, distribution boards, consumer units), main mechanical equipment (air handling units, heat pumps etc.)
• these typically do have a unique reference and are specificed individually

2. Smaller, ancilliary equipment

• e..g. light fittings, socket outlets, fan coil units, etc.
• these would typically have a type based reference. A type on a drawing would correspond to a type in an equipment schedule.
• e.g. Drawing and schedule shown below
• 
• 

In addition to this, on many larger projects we are provided with an "Asset Information Requirements" document that requires plant references are built in a specific way, and sometimes the requirements for mechanical plant is different than for electrical plant (!):
therefore we require flexibility in approach to adapt to changing client requirements.

To give flexibility, our process is as follows, every digital asset contains the following "identity data" fields:

• abbreviation (required)
• type_reference (required)
• function_reference
• instance_reference
• volume_reference
• level_reference

an equipment reference is then built from these fields.
on a project, we can specify how the equipment reference is built

for type references:

e.g. 
TYPE_MARK_DEFAULT_TAG = {
    "abbreviation": "{abbreviation}",
    "type_reference": "-{type_reference}_",
    "function_reference": "{function_reference}",
}
# e.g. 1
# type_mark_data = dict(abbreviation="DB", type_reference=1, function_reference="")
# type_mark = DB-1
# e.g. 2 (with function reference)
# type_mark_data = dict(abbreviation="DB", type_reference=1, function_reference="SMLPWR")
# type_mark = DB-1_SMLPWR

e.g. for instance references:

MARK_DEFAULT_TAG = {
    "abbreviation": "{abbreviation}",
    "type_reference": "-{type_reference}",
    "instance_reference": "-{instance_reference}_",
    "function_reference": "{function_reference}-",
    "volume_reference": "{volume_reference}-",
    "level_reference": "L{level_reference}",
}
# e.g. for
# mark_data = dict(abbreviation="LT", type_reference=1, function_reference= "", instance_reference=1, volume_reference=A, level_reference=2}
# mark = LT-1-1_A-L2

on projects, for main pieces of electrical distribution equipment there was a desire to only show the instance information in the tag - that way if the type specification of the equipment changes, this change only happens in the schedules and the drawings don't need to change. this can be done as follows:

e.g. for instance references of major electrical distribution equipment:

MARK_DEFAULT_TAG = {
    "abbreviation": "{abbreviation}",
    "type_reference": "",
    "instance_reference": "-{instance_reference}_",
    "function_reference": "{function_reference}-",
    "volume_reference": "{volume_reference}-",
    "level_reference": "L{level_reference}",
}
# e.g. for
# mark_data = dict(abbreviation="DB", type_reference=1, function_reference= "", instance_reference=1, volume_reference=A, level_reference=2}
# mark = DB-1_A-L2

in the example above the type information still exists as data in the asset, but is not shown on the tag.

it would be great if in BDNS we could acknowledge this type of use case, and potentially develop a "tag definition schema" that provides a compliant method for defining how equipment references should be built for type and instance references.

[jgunstone]

we talked about this today, some notes from the discussion:

• do we want to support Type tags?
  • deviation from original use case of asset tagging during as built stage
  • ... but type references are essential when dealing with BIM data which is a listed use case
  • the abbrevations themselves are very useful for encouraging standardisation in equipment references
• BDNS is keen to avoid developing a meta-schema for how to build an equipment reference, preferring to have a simple, defined and documented approach that can be adopted or not
• being able to easily distinguish at TypeReference from a unique Asset Identification Reference is essential to avoid confusion
  • maybe they could use different separators instead of "-" ?

next steps - try and come up with some examples of how TypeReferences could work, demonstrate that it won't cause confusion when comparing to the primary use case of unique Asset Identification Reference.

[jgunstone]

discussed this internally...
liked the idea of a "." as separator for type references (or "" potentially).
reinforced the point that for some items of equipment type tags are essential for the production of design info (drawings etc.) and that the abbreviations should remain consistent as the design progresses to the "in-operation".

[pisuke]

After more discussions, we achieved agreement on creating an asset.type in the form of XZ where X is the abbreviation and Z is an incremental number. Then the asset.name can be in the form of X-Y or XZ-Y, where Y is still the instance incremental number.

[jgunstone]

asset type tagging is now supported:
https://theodi.github.io/BDNS/BDNS_Specification_naming_syntax.html#deviceasset-type-asset.type