NBS BIM Object Standard - Where is the Impact Statement?

When the NBS BIM Object Standard first came out I eagerly grabbed it to see if it contained any useful insights, anything that might help me structure the way I do my work.
Sadly I was disappointed. Not only did I found nothing I could immediately apply, I barely understood it.
But for me it didn't matter. I don't work in the UK, I could afford to ignore it.

A few months later I noticed a post in the NBS National BIM Library LinkedIn group asking for comment. So I thought I would revisit the NBS BIM Object Standard, try a bit harder to follow it, and work out why I was unimpressed.
After posting my comments on the LinkedIn group someone from the NBS posted a prompt reply. That was over a month ago. Since then no more comments from anyone else, which is disappointing. Seems no one cares.

WHAT IS THE NBS BIM OBJECT STANDARD?

But first, for those not in the UK, some background information.
NBS, the National Building Specification, is a commercial firm owned by the RIBA, the Royal Institute of British Architects. They provide specification products and other services - "information solutions to construction industry professionals." BIM services is a good fit for their business, so they are developing a range of BIM 'products'. As we all know establishing standards is necessary for any BIM system, the NBS BIM Object Standard is one of those standards. They have other BIM documents, for example I commented on their NBS Shared Parameters in another post.

The NBS National BIM Object Standard is available for free on-line. There is an on-line version and a downloadable PDF. The on-line version has guidelines built in (click on a clause). The web site is very well designed and easy to use.

In 2014 they won a UK government contract to "take forward development of the Digital Toolkit for Building Information Modelling (BIM)".  So any standards they develop are likely to become UK government endorsed, and quite likely government mandated. At the very least they are likely to be referenced in owner BIM requirements in the UK.

MY APOLOGY TO THE NBS

This post is critical of the NBS BIM Object Standard, and I apologize in advance. The standard is not a complete dud, there are many good things in it. A BIM Object Standard is necessary. Kudos to the UK government for funding it, and the NBS is an appropriate organisation to develop it. Much of BIM is new and untested, the NBS are, to an extent, finding their way, like the rest of us. I don't necessarily advocate abandonment of the standard or the NBS as author.

I'm more disappointed than anything else. There are real efforts being made elsewhere, standards that are much more comprehensive and, well, useful.  ANZRS, Australian and New Zealand Revit Standards, and BIM-MEP [AUS] come to mind. But these efforts are Revit specific and don't try and use IFC or other global standards.

As I say above, I don't work in the UK, as many of you probably don't either. We won't be directly affected by the NBS BIM Object Standard. I'm using it as a specific example of some of the problems I see in many BIM standards. I hope my criticisms are taken in that light, not as an attack on the NBS, but as a comment on all BIM standards, and a cautionary tale for future BIM standards.

WHAT IS ITS STATUS?

It is not entirely clear to me what the status of the NBS BIM Object Standard is. Is it the NBS in-house standard for creating objects for their library, or is it supposed to be a national (UK) standard for all creators of BIM objects?
No where does it state that it is a national standard, but the language and structure seem to assume that it is. The fact that the names of properties defined in the standard are not identified (e.g. by prefixing with COBie_ or IFC_) suggests they expect there will be no competing standards. Or perhaps they assume the thousands of people involved in the AECO industry will just know that 'Grade' is a COBie property.
The exception are properties specifically for the NBS proprietary specification service (e.g. NBSReference). At least they recognize they have competitors in the specification market, but it seems they don't expect to have any in the BIM market.

The scope of this standard is so narrow I can't see how it could seriously be taken as anything other than an in-house document. It should have been called the NBS BIM Object Library Standard to avoid confusion.

DIFFICULT TO FOLLOW

Even though I work in the BIM sphere, and have read way too many BIM reports, guides and standards, I found the NBS BIM Object Standard a difficult document to understand.

A large chunk of requirements seem to be hidden within BS 8541. I don't know if reading BS 8541 in conjunction with the NBS BIM Object Standard would make it more understandable or not because I don't have a lazy few hundred pounds sterling. But really, no document should rely on another to make it comprehensible.

There is an assumption IFC, and IFC terminology, is understood by readers. IFC is for computer nerds, not construction or FM professionals. If you actually want to engage them it needs to be explained in terms used in the AECO industry.
Does anyone know what this means?

"The BIM object may include Pset BuildingElementProxyCommon if no IFC common property set (Pset xxxxCommon) exists for that object in IFC 2x3. Where PsetBuildingElementProxyCommon is used, the BIM object shall include a ‘Reference’ property completed with an alphanumeric value acting as an identifier for the specific object type."

Some parts are particularly unclear. Clause 2.2 talks about "The BIM object property". Is it the value of the property which identifies the object (if so what is the property name?), or is it generic - applies to all property values?

Each property is described, but many are not clear on what they are to be used for. Things like Features, Grade, Constituents. When is something a Feature instead of a Constituent? Generally examples would be helpful. I have trouble imagining how most of how the standard could apply to what I do (as an Architect).

UNCLEAR STRUCTURE

Properties included seem to privilege FM. For example I didn't see anything there that would help me do a door schedule.
The response from the NBS was that COBie is mandated by UK BIM so must be included (presumably to comply with NBS's government contract).

That's fine, but if you are trying to develop a standard shouldn't it cover all use cases?
Their response to that was that the NBS standard is "not a static document". Again, not an unreasonable intent, although perhaps challenging to the usual concept of a 'standard'.

But there is no recognition of this in the structure of the document. I get that it is not possible to instantly produce all information, but I would expect a standard to have a structure that reflects long term goals, that won't require constant restructuring to include new information.

This issue is partly the reason I find it so difficult to follow. Under section 2: Information Requirements, there are heading for IFC, COBie  and NBS_General. So these are presumably requirements, but there is no definition or explanation around them.
From what I can gather COBie is data for operations (i.e. FM), NBS_General are for specification co-ordination. Perhaps IFC is for all other uses? I don't know. It is not clear.

REPEATED AND UNCLEAR INFORMATION

I thought the point of standardizing data was to avoid unnecessary duplication.
Yet there are a number of parameters that appear to be for the same information.
Clause 2.6.1.16-18 defines 'NominalLength', 'NominalWidth' and 'NominalHeight'. Clause 2.6.1.21 defines 'Size'. Aren't they describing the same thing?

As an aside it is disappointing 'NominalLength' and 'NominalWidth' are not more clearly defined. NominalLength is defined as "primary horizontal dimension", NominalWidth is "secondary horizontal dimension", which leaves it to users to interpret which is "primary" and which is "secondary".
More definitive would be to define 'NominalLength' as left to right horizontal dimension, and 'NominalWidth' as front to back horizontal dimension, something I've written about previously.

There are parameters that contain more than one piece of information (e.g. Category - number, colon then name), yet other single parameters that would only apply to a limited range of objects and would be best contained in one general description parameter, things like 'Grade', 'Constituents' and 'Features'.

To be fair these problems are due to inadequacies in COBie, another issue I have previously written about. But is it sensible to propagate poor practices without question?

Use of Classification is confusing. There are two main english language classification systems, Uniclass from the UK, and Omniclass from the USA.
In the NBS BIM Object Standard there are two places to put classification; COBie, clause 2.6.1.2 has 'Category', and NBS_General, clause 2.7.8 has 'Uniclass2'.

In addition to the two classification parameters there is a third, NBSReference, which is for an NBS Clause Reference. (as well as NBSDescription which is for an NBS clause title, presumably the text that accompanies a clause reference, so I don't know why you need both).

The reason behind all this, according to the NBS, is so you "can have more than one classification associated with a product (BS ISO 15686-4)".
Which on the face of it seems prudent. But why would you want to have more than one classification system associated with a product? How does that work?
Are we supposed to completed both parameters with the same value, or can we leave on blank?
Do we put Omniclass in one and UniClass2 in the other for all components?
Or have a mixture so some components have Omniclass, others Uniclass?

And why is there a separate parameter for specification? Isn't the whole point of a unified classification system that the same classification number is used for all purposes - specifications, costing, scheduling, asset management?

But to me the silliest parameter is BIMObjectName, which is the same as the actual name of the component. Why? The object has a name so why repeat it as a parameter? It just adds another layer of work and potential error in the data.

INEFFICIENT NAMING CONVENTION

In section 5: Metadata Requirements all naming follows the same format:

 role / source / type /subtype / differentiator

Where 'role' means BIM object author and 'source' means product manufacturer.

I'm not sure how you would apply this to components made of multiple products by multiple manufacturers. Objects that have layers of materials like walls, roofs, ceilings and sometimes floors.

The naming schema does follow the "major to less minor" structure that lists similar things together, which is the best strategy.
Except this structure lists by component author, then product manufacturer. Neither of these bits of information are important to the vast majority of people who will be using BIM objects.

Who cares who the author is when you are searching a list to find a door, or a pump, or a sprinkler? It doesn't matter if is was NBS, or Arcat, or BIMobject, or BIMcomponent.
Next most useless information is manufacturer. The actual product, and hence manufacturer, is not known for many components until a contractor is appointed. Architect and engineers do design intent BIM, our work is largely finished by the time the manufacturer is known.

For those of us who have to use standards (as opposed to those who just create them) this introduces an enormous inefficiency when trying to select components by their name. We are confronted with lists sorted by who made them, then sorted by manufacturer. What we need are components listed by what they are, not who made them.

To make it worse clause 5.2.3 says "The manufacturer name shall not be abbreviated." So not only are our components sorted in a manner useless to us, we can't read the information we need as it is hidden when the name extends beyond the width of our dialog boxes. For example names like Australian Sustainable Hardwoods (30 characters), BAC Advanced Composites Technologies (33 characters).

Complying names in Revit:

in Windows:

But interestingly in the NBS National BIM Library components use what sort of thing they are straight after author. Did the NBS find their own standard unworkable?

And what happens when a product is selected, when it goes from being a generic component to a specific one? Currently we just change, or more likely add, the relevant information. Replacing our well structured components with manufacturer components is not a realistic option. That would possibly cause them to relocate themselves in our model, and almost certainly destroy our existing schedules.
So realistically the standard requires us rename the component. Not only do we complete the manufacturer and model information we have to rename the component and change the value of the NBS BIMObjectName parameter. It may not sound like much but it effectively doubles our work.
Oh, and COBie also has a Name parameter for the component's name, but apparently it is not, or doesn't have to be, the name within the BIM platform. So the component has two names?

As an aside names of things in a BIM system should be treated as the HUID for the object - Human Understandable ID. Just like computers need a GUID to identify objects, those of us that create BIM need a human understandable way to identify objects. A name that suits our working practices so we can be efficient. Names should NEVER be used as a data field as they are unreliable and invariably repeat data already embedded in proper data fields.

And the justification for all this?
"The NBS BIM Object standard draws upon BS 1192 and BS8541 for naming conventions. This document states that ‘Source’ e.g. Library author/ Manufacturer is the first field within the naming convention."

Why draw on something that is inappropriate?

UNREALISTIC

We get this all too often in standards, rules and requirements that are impossible or difficult and time consuming to comply with.

Clause 2.3.5  states "The BIM object shall map hard coded properties that do not conform to naming conventions in section 5 ‘Metadata Requirements’ to a correctly spelt property based upon the order of selection in clause 2.3.3, e.g. ‘Fire Rating’ (hard coded) should be mapped to the IFC property ‘FireRating’."

You can't do that in Revit. You can't map a text parameter to another text parameter. Now, admittedly you should be able to, Autodesk should hang their head in shame. But the reality is the majority of people authoring BIM use Revit, so none of us can comply.

Which brings up another issue. Why are we being made to put things into our BIM model, the one we rely on to produce the work we are contracted to do and are responsible for? Why are we being made to wade through a sea of parameters that we don't use?
And it is so unnecessary. Our parameters can be mapped to what others want on export. They don't HAVE to exist as separate parameters in our models.  All we should be required to do is ensure we have the necessary parameters to map to IFC and/or COBie properties for export. Particularly since one of our parameters is likely to populate multiple IFC / COBie properties, as described above.

This comes under the 'are they serious' department.
There is an overarching requirement to fill values not applicable or not known with 'n/a', including, bizarrely, revision.

I can understand why you might put n/a as a value for parameters that never will be applicable to a particular object (which makes you wonder why they are there in the first place), but why do it if the value is simply not know?
And how do you, or how does compliance checking software, tell whether it is not applicable or not know - not available?

But what irks me the most is the amount pointless effort that will be required to fulfil this requirement. Generally software will leave a value blank if it is not filled in. What the NBS BIM Object Standard is demanding is that someone take the time to go through and change all these blank values to n/a. Across tens of parameters in an object, hundreds of objects in a project, thousands of different firms, and projects within those firms. Millions of man hours per year across the industry. And why?

"During consultation, feedback advised us that having blank COBie fields resulted in failed COBie compliance tests. BS1192-4 suggests unknown values are entered as ‘n/a’."

So rather than the few hours it would take to make some COBie compliance software cope with null values, the whole AEC industry is expected to waste millions of man hours.

FUNDAMENTAL PROBLEMS

A summary.

POORLY STRUCTURED

For an industry document I find the NBS BIM Object Standard poorly structured and not clearly written. It reads like an internal document between Standard writing wonks. What appears to be explanatory clauses are really just lists that could have been formatted in tables.
Unfortunately the NBS BIM Object Standard is not the only BIM document to attract this criticism.

LIMITED SCOPE

The NBS BIM Object Standard only covers a very small part of BIM processes. It tries to cover FM by including some COBie parameters, and specification coordination through the NBS parameters. Mind you, very limited specification coordination as NBS is only one of many available systems, and of no use to those who do in-house specifications.

And you do wonder if it is appropriate for COBie data to be in objects contained in what is design software. Software like Revit and ArchiCAD are fundamentally unsuitable for FM. There is no intrinsic reason for FM data to be embedded in these softwares, as it is of no use to anyone making use of the BIM benefits they bestow. There are other junctures, and other softwares, in the construction process where inputting of FM data would be much more efficient.

DOGMATIC ACCEPTANCE OF OTHER STANDARDS

A few of the shortcomings of the NBS BIM Object Standard stem from the unquestioned following of other standards. I suppose the argument is that the purpose of the NBS BIM Object Standard is to assist in compliance with other standards. But are those standards appropriate?
Is it really necessary to follow another standard's internal requirements, requirements developed for purposes different from the needs of a BIM Object Standard?
The real question here is should a standard be the same as other standards or should the aim be to make it compatible with other standards. To be something useful rather than recycle things that exist elsewhere.

NO IMPACT STATEMENT

But perhaps the most disappoint aspect of this, and most, if not all, other standards for BIM, is the lack of any thought to industry impact. I'm not talking about supply chain impact, but additional work that will be required across the industry to comply with a standard.

The argument that the overall gain in efficiency of a common standard will surpass any additional individual effort doesn't hold water.

Firstly any irrelevant effort should be eliminated as a matter of course.

Secondly, how do you know what the overall gain will be if you don't deduct new inefficiencies?

And thirdly, the burden of additional effort is not equally shared. Only some parties are weighed down with additional work and inefficient practices, whilst other benefit with no or little effort. This may not be completely avoidable, but where it does occur there should be robust assessment of costs and benefits to ensure it is a worthwhile sacrifice.

CONCLUSION

Standards are boring and often difficult to understand. But make no mistake, once published they will affect what you do.

The NBS BIM Object Standard may in reality only be an in-house document for their library, but they are promoting it as a national standard. And as we know standards, even ones pretending to be national, are invariably included in contracts by people who have no understanding of what they are.
We are already seeing this with the inclusion of COBie in contracts with no definition of what is to be included in the COBie deliverable. Thousands of man hours wasted on providing something those requesting it have no capacity or intention of using.


What can be done?
Don't take it lying down. If your boss makes you do something to comply with a standard that takes extra time make it known, if a client demands compliance with standards question the need, and charge if it takes additional effort, and if your BIM consultant suggests you should include a standard in contracts demand a proper cost benefit analysis, don't accept 'you might need it' or it is 'what everyone else is doing', and don't believe them if they say 'it shouldn't cost extra'.

And when comment is sought on new standards take the opportunity to have your say. Or pester your industry association to comment, they are, after all, supposedly there to protect the interests of their members.

If you would like to comment directly to the NBS email them at info@thenbs.com, or join the discussion on their LinkedIn page at https://www.linkedin.com/groups/National-BIM-Library-4103410/about