Related PostUnderstanding BIM in the UK Part 3: The Role of Uniclass 2015 in Achieving True Standardisation
3 Minute Read
April 12, 2022
This is the second blog in our series examining the current state of BIM in the UK, from demystifying what BIM is to where to look for the latest advice and guidance surrounding BIM. In Part 1, we provided an overview of the new ISO 19650 standard and how it relates to UK construction projects.
For this blog, let’s explore the UK Annex, its relation to ISO 19650, and look into the naming convention in more detail.
On the surface, the recent changes implemented by UK BIM Alliance may not look like much has changed, but that is far from the case.
We’re going to go through the naming convention now and try to better understand what the changes are and how they affect your team. At first glance, the naming convention in the UK annex of ISO 19650 looks very similar to the old BS1192 naming convention. It splits down into its various parts and a lot of them look to be the same.
It starts with a project and has an originator, that's the same. However, instead of volume and system, it has functional breakdown, and instead of level in location, it has spatial breakdown. Instead of type it has form, which is the type of information contained in a file that's been uploaded. Then, instead of role, it has discipline. Again, seems very similar but it ends up with no identical factors. At first glance, it looks as though not a lot has changed and that we're dealing with the same beast, in reality, that's not the case.
What it does say is that the identifiers for each part should be fixed within the project's information standard, hopefully by the client in the ISO, possibly by the assumption that the client always knows what they're doing, which isn't always going to be the case.
Nevertheless, the standard says this should be defined by the employer within the information standard and then rolled out. That means that on a project basis, or hopefully if you're a repeat client across all that client's projects, there will be a naming convention which is applicable. It's the variation where I think where I think that there is a missed opportunity here, but I will discuss this in the next part of this series.
There were some optional portions of the previous naming convention which could be added in and they were classification status and revision. Those sections I've just discussed could be expanded to include those now under ISO 19650. However, whereas those fields were optional, although most would always have captured status and revision within the CDE (common data environment), they are no longer optional. You must fill in classification and stats and revision. The standard says that any item downloaded from your CDE should have those fields added to the end of the naming convention.
Personally, I think that's a really good thing. In particular, I think that having classification as a compulsory field is a good thing. The first field is a project and this is a designation to be used by everybody working on the project. It then becomes everybody’s call throughout the project and it's initiated by the client.
In the year before, there was an indication of a number of characters that could be used and the fact that these could be letters or numbers. This didn't work for everybody because there were, for instance, long established repeat clients who already had a way of naming their facilities and their jobs. In other words, legacy ways of naming things that weren't compliant. Therefore, I think that freeing up that first section is a good thing to do.
What the standard says is there are no set codes for the project field. It's for the appointing party to define how the project field is used, including its relationship to any asset identification procedures defined as part of the management asset system. Therefore, the key thing is it must be defined and it must be the same for everybody involved with the project.
The next field is originator which is a unique code for your company. Obviously, the ideal would be that this can remain the same no matter what class you're using, but it's defined by the information standard on the particular job. I would suggest that you could propose what you're going to do, what you would like to use as part of your tender and the build, with the idea being that it becomes fixed within the information standard.
The next section is functional breakdown, where you see the unique identifier for all the functional aspects. This would include major elements or systems within the design e.g. the hot water system. This aspect works with the project idea and spatial breakdown so between those three sections, you could identify precisely what something something is about. There is a lot of flexibility here for you to define what works for you and this should be defined by the client.
The next section is form. What this is referring to is what is the form of the uploaded information container, whether it’s a model, video, or even a text file. Previously, we knew if it was a file, note or minutes because there were more designations. To accommodate this, the standard says that if you need to, you can expand these with project specific codes, which can extend the standard closure of the digital characters. A suffix is fine, but I would suggest that the bulk of people are going to want to know whether a uploaded model is a 3D representation, a 2D model, or a flat auto CAD file or a 3D Revit file.
The issue is, I think the bulk of people are going to want to know those additional bits of information. I also think codes are going to be expanded and I think people are going to want to expand them. It's good that we are saying you have to document how you want things labelled, but I don't think this constitutes a naming convention.
The industry is beginning to settle around a name for an information container file. I would suggest if you are a large tier-one contractor working on multiple projects, it's useful to be able to do metadata searches to extract the data and information about deliverable types across projects. The only way to do that is by having enough regularity in the way that you retrieve all of these particular types of schedules. If these are defined project by project, you're losing that ability.
The last section of the naming convention is EIR (Exchange Information Requirements) which is very similar to what it used to be. This is where all parties involved agree on how to transfer project data, what this looks like for each team, and in what format this should be shared. Whereas you previously might’ve said architect, you now say architecture, etc. But essentially this hasn't changed — it will still be a short list. The standard says that this list may be expanded with two character projects, specific codes. I would then argue that using this expansion further splinters the ability to search by metadata.
However, in the next blog, we’ll explore how Uniclass 2015 can be used to bring more standardisation across projects when used alongside ISO 19650.
3 Minute Read
April 12, 2022