The practicalities of classification in a BIM Level 2 environment

I first raised the issue of classification in the BSRIA blog back in March 2014 – my, how time flies.  As you would expect (or at least hope) things have moved on and there are some issues within the general world of classification which are worth raising, particularly in the context of BIM Level 2 with the UK Government’s mandate almost with us.

Current classification systems commonly used in construction typically work at ‘system’ level.  The highest level of classification is for a group of system types eg in CAWS (Common Arrangement of Work Sections).  This level is represented by a single letter: ‘S’ represents Piped Services, a category including systems such as Cold Water, Natural Gas, etc.

However, most classification systems available have an inherent flaw – they are not capable of classifying at a multi-services level, something that is common in the world of MEP.  In CAWS language, there needs to be a way of combining mechanical systems and electrical systems under a single heading, as the various mechanical systems are combined under the Piped Services ‘S’.

The success of information management depends heavily on the ability to retrieve a piece of information once generated.  BS 1192:2007+A1:2015 details a method for naming information files, and consists of a number of mandatory and optional fields.  The following extract from BS 1192 shows all the fields, together with their obligation – ‘Required’ or ‘Optional’.

Using this process would result in a file name (a similar process can be used for drawing numbers) as follows.  I have ignored the last two fields – Suitability and Revision – for the moment, and I’ll explain why later:

PROJ1-BSRIA-00-ZZ-RP-H-T31-00001

In this example, the CAWS classification system has been used, giving T31 for Low temperature hot water heating system.  And this is my point (finally, I hear you say) – the classification field is the only part of the file string which tells the recipient what the subject of the file is.  In future, when searching for information about a particular aspect of a project in the information repository, this classification code is the best way to identify relevant content.  Therefore, I feel it is vital that the classification field is used for all file names in order to make the information available for future use.  This reuse of information is where efficiency increases are realised and errors reduced by not having to reproduce information over and again.

Now, suppose that the report in the above example was the building services scheme design report, covering all mechanical, electrical and public health systems.  Which classification could be applied for that topic?  This takes us back to the point I made at the start of this article – for any classification system to work effectively it needs to be able to represent multi-services applications.

The classification system chosen for use in the UK Government Level 2 BIM requirements is Uniclass 2015, a development of Uniclass 2 which was produced by CPIC (Construction Projects Information Committee).  Uniclass 2015 has been prepared by NBS as part of an Innovate UK research competition won by their parent company RIBA Enterprises, and consists of a number of individual classification tables.   Although this is the classification system chosen to take us into Level 2 and beyond, it does not appear to be capable of meeting at least one fundamental requirement – the ability to deal with multi-services applications.

Don’t get me wrong.  This issue is not new and is certainly not confined to Unicalss 2015.  CAWS couldn’t handle multi-services classification either, but it was hoped that a new system, developed specifically for BIM, would provide the answer.  BSRIA has been raising this issue, both in its own name and as part of CIBSE initiatives, since Uniclass 2 was released.  Throughout the development of Uniclass 2015 we have raised a number of queries about the arrangement and capability of the format, but on this particular point we are still waiting for a meaningful response.

Whilst I’m at it, here’s another thing to think about.

As I mentioned earlier, the success of an information management system – for that’s what BIM is – is the ability to retrieve information once created.  The file naming convention described in BS 1192:2007+A1:2015 described above goes a long way in enabling this but there are some points of concern with its approach.

A document or file may be superseded a number of times in its life, and BS 1192 describes the process for moving that superseded file into the ‘Archive’ area of the information store.  This ensures that the complete history of the project is retained for future reference.  However, the way the successive versions are named is causing a little concern in practice as more people start to use these methods on live projects.  This is where those last two fields I conveniently ignored above come into play.

Historically, we have managed revised and superseded documents by using revision codes – in most cases a single letter after the final number (PROJ1-BSRIA-00-ZZ-RP-H-T31-00001A using the previous example).  This additional letter distinguishes each version of the same base document, and also has the added benefit of changing the file name to allow it to be saved whilst remaining recognisable.   The two remaining fields in the BS 1192 extract above appear to provide this facility within the BS 1192 approach.

However, the guide to BS 1192 (Building Information Management – A Standard Framework and Guide to BS 1192) states that:

Recommendation: status and revision should not be included as part of the file name as this will produce a new file each time those elements are updated, and an audit trail will not be maintained.

This doesn’t appear to be a very sensible approach to me.  You cannot save multiple versions of a file with the same name, so the addition of the revision letter to the file name is a simple and workable solution.  This might seem like a small or trivial issue in the big world of BIM, but it’s the sort of thing that could stop the widespread uptake of an otherwise very worthwhile file naming approach.

BSRIA has posted several blogs on the topic of BIM that can be read here.