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’.

John Sands Jan blog

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.

About johnsands123
John Sands Principal Consultant, Sustainable Buildings Group John has recently joined BSRIA’s Sustainable Buildings Group to drive the development of BIM within BSRIA, to help industry understand the principles and practices which define BIM, and give support in making best use of this in their everyday operations via the BIM Centre, a joint venture with BRE which will be launched shortly, and the BSRIA BIM Network group. Prior to joining BSRIA, John worked at Hoare Lea where he was involved in a trial to automatically generate specifications from objects as they are inserted into the BIM model. This work will continue as a collaboration between Hoare Lea and BSRIA. John is actively involved in industry discussions on classification structures for BIM, and represents the CIBSE at CPIC committee level on this topic. He also sits on the CIBSE BIM Group, currently looking at developing standard information presentation techniques for use in BIM environments. John has a particular interest in the capture of data for use throughout the full life cycle of the building, covering such activities as performance monitoring in use and facilities management.

2 Responses to The practicalities of classification in a BIM Level 2 environment

  1. Nick n says:

    The bs is quite clear: If you can keep metadata away from the file name then you should. Putting metadata in the file name makes it a different file each time, disrupting referencing and ruining continuity, reducing repeatability and confidence. If you do your sharing with FTP or Dropbox etc, which don’t do metadata you are locked into poor practice.

    As for products that are in multiple systems, then classification common sense says you either choose a shorter (higher) code or you choose the primary purpose/function/elemental-breakdown. There can’t be a single code for every conceivable combination! Of course some bim objects and applications can carry multiple classification codes (sometimes called ‘faceting’) but one code for purpose (aka layering) and one for product (aka specification) should suffice.

  2. I would agree with Nick n above.
    An Electronic Document Management System will be a must with managing metadata. It is possible in the future we will get to a level where metadata is embedded at a component or system level, to enable better management and control.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: