BACKGROUNDThe National Building Specification (NBS) in the UK is a commercial organization owned by the Royal Institute of British Architects (RIBA). It produces specification products for architects and has lately been developing a range of BIM products.
One of it initiatives is the development of a National BIM Library of manufacturer BIM components. The aim is to be software agnostic but to be relevant in the real world, and the fact that IFC doesn't cope well with component definitions, they are including different software formats, including Revit.
As part of this process they have had to define standard parameters for the components in their library. They developed the NBS BIM Object Standard document explaining these parameters. And that is why they made available a Revit shared parameter file containing these parameters.
The NBS is to be applauded for their efforts. Their web site clear, concise and open to everyone, and all these tools are freely available.
But . . . .
THE PROBLEMThe names of the parameters in the NBS shared parameter file are not identified as belonging to, or originating from, the NBS.
Which is a bit rude considering we are inviting those parameters into our models to live amongst our, and other guest parameters.
Although the parameters are in their own group and have unique GUIDs (Global Unique IDentifiers) many names are regular English words, with ambiguous parameters like "Revision", "Version", "Name". Revision of what? - COBie export; specification; schedule; O&M manual; manufacturer model?
And some parameter names are identical to built in Revit parameters. For example "Description"; "Manufacturer"; "Finish".
For Revit users this is a problem. Unlike older softwares Revit doesn't use the name of things as the main identifier. Like a properly constructed database it uses an internal unique identifier. The name is merely another piece of data associated with that identifier. That is why when you rename, say a section detail, or a sheet number, it renames all references everywhere - instantly.
When creating schedules Revit lists all parameters available as fields that can be used in the schedule. As names are just data, if there are multiple parameters with the same name they will be listed. So if you use the NBS shared parameters there will be two available fields called "Description". The problem is you can't tell which is which. Both the group they are in and their GUID are not accessible when creating a schedule.
But the problem is wider than for mere Revit users. Imagine the scope of this problem when there are multiple models from multiple authors. Lists of fields all with the same name, with no (easy) way of identifying who created them or what they are for.
The usual way around this issue is to not just ensure names are unique within the project, but that they help identify where they came from or what their purpose is.
The most common approach is to prefix or suffix custom parameters with an acronym identifying the author firm or organization. For example the ANZ Revit Standards group adds an '_ANZRS' suffix to its shared parameters, software house RTV Tools uses a 'RTV' prefix, Codebook uses "CdeB_".
And parameters without a prefix or suffix are assumed to be built-in Revit parameters.
|ANZRS Shared Parameter file example|
With a prefix or suffix parameters can be identified by their name:
Which makes the schedule much more user friendly:
But the NBS has decided their parameters are the only ones anyone needs. To quote from a LinkedIn discussion:
"We see the launch of the NBS BIM Standard as a document that the industry will adopt and apply to the content created for projects whether this content is created by the NBS, designers, or content creators."
Apparently the ONLY document we will all adopt.
THE ATTITUDEWhat NBS is ignoring is that BIM deliverables are only one of many things model authors require from the parameters in their models.
As design professionals our primary deliverable is sufficient information to construct the facility, things like door schedules, finishes schedules, room data sheets. These may include some parameters required by other deliverables like COBie, but there are parameters not required by COBie, as well as parameters required by COBie that we don't use.
Contractors use the designers information to organize the construction of the building. Again there is not a one to one relationship between what they require and other uses and deliverables.
We also use parameters for our own internal purposes, such as various analysis like daylight contribution, structural design, mechanical system design, construction sequencing etc, as well as for internal QA and compliance. For example to check building code compliance I created a ARCH_VentilationArea parameter for windows that calculates the area available for ventilation when a window is fully open.
By the NBS assuming their standard will be the only one creates a headache for software vendors who are trying to sell their software across the world, and for large firms that operate in different countries. Believe it or not there are other standards than the NBS.
THE SOLUTIONIf the NBS continue to remain recalcitrant there is a work around in Revit.
|Note that this will only work if done BEFORE any NBS components are placed into your project. Once a shared parameter exists in a project file, whether brought in by placed components or created via project parameters, its name can not be changed. This is the case even if you attempt to remove all references to it by purging all components and deleting all project parameters.|
1. Edit the shared parameter file by adding a prefix to each name (e.g. NBS_ or COBie_ ).
(the quickest way is to open the shared parameter file in spreadsheet software like MS Excel, OpenOffice Calc, Google Sheets, do the edit then save or export as a tab delimited file)
2. Point Revit to your edited NBS shared parameter file.
3. Add each parameter from your edited file to your project (or Template file) as Project Parameters.
(you may find an add-in to do this faster, e.g. CTC Shared Parameter manager, RTV, Rushforth Projects for paid, Case Apps for a free tool)
4. Point Revit back to your standard shared parameter file.
Now when any components from the NBS library are inserted into your project all the NBS parameters will use your names instead of the NBS names.
Parameters in NBS component (Revit family .RFA file):
Parameters of component placed in your project:
Even though the name is different the GUID is the same. So if you link a model from someone else that uses the standard NBS name that data will appear in your model under your renamed parameter. If they link your model your data will appear under the name they used for the parameter.
If someone is extracting data for, say a COBie export, it should make no difference as long as the export relies on GUIDs and not names.
If names are critical then either rename the field in your Revit schedule or rename columns in the receiving software (e.g. COBie spreadsheet).
|What you DON'T want to do is create your own new shared parameters (via Revit's Shared Parameter dialog) that mimic the NBS shared parameters. If you do this your parameters will have a different GUID to the NBS parameters and therefore will not contain the data in NBS components.|
CONCLUSIONIt is disappointing the NBS has taken this attitude. Part of the BIM revolution is the breaking down of the "silos" people work in, allowing people to work collaboratively. The NBS approach seems to be to replace the silos of others with their particular silo.
Not very BIM like.