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.

Recipe for Success

 

Ian Harman of Marflow Hydronics

Ian Harman, Technical Applications Enginner, Marflow Hydronics

Months are spent putting them together, and thousands of pounds are spent printing and promoting them, but it still seems that the wealth of documentation out in the industry, that could help users design, install and commission systems, is not always used.

No one could just pick up a pen one day and design a flawless system, whatever core skills they have.  It takes training and understanding; it takes skills that have to be developed over many years.  To support this, collected groups of people with the right knowledge and experience produce documentation that explains best practice and provide methods for success.  But in our busy industry, there isn’t always time to sit and follow best practice guidelines, sometimes you just have to use the best knowledge you have.

What if you were baking a cake, though, would you just use your best knowledge then?  You may have made a cake before, but are you really going to remember every single step, every single ingredient, every single amount to be used?  And if you did just use your memory, would you really expect the cake to turn out perfectly?  It’s highly unlikely.

So why not follow the ‘recipe’ when designing, installing and commissioning systems?

Designing Long Term

design-support-l1In my team, we’re always telling our customers to start with the end in mind.  The first step is always the design stage.  It’s vital that this is done with the complete picture in mind, keeping all the factors of how it’s going to work long term, in real life conditions, in mind.  For example, what are the best products to use?  How will seasonal commissioning take place?  How can you optimise efficiency?  It’s far easier for all contingencies to be considered up front, because if you realise you’re missing something further down the road it’s much harder to add it in later.  If we go back to the cake analogy, you wouldn’t start to bake a cake without considering what sort of cake it’s going to be.  If you later decided you wanted a chocolate sponge, it would be too late to add the cocoa after you’ve started to cook it.  Full consideration of every point needs to be done up front.

Ultimately, designers want to make sure that they design the most efficient systems possible using the simplest method.  No matter what the system, problems will always be inevitable, so designers also need to think about how systems can be troubleshooted when things do go awry that will cause limited disruption and can offer the quickest solution.

All this leads to one conclusion:  a system needs to be designed so it can work as well as it possibly can, with a few contingencies in mind.

CIBSE Commissioning Code W

CIBSE Commissioning Code W

Doing it Right

The documentation that’s been put together by collected groups of experts should provide anyone with all the information they need.  A Commissioning Code, for example, such as Code W, will provide guidance on what needs to be specified and included to make a system work; and then a BSRIA document will give all the important detail to achieve individual areas such as Pre-Commissioning.

The benefit of such guides is that they are not the opinion of just one author, they are made up of the knowledge of a group of experienced individuals who have to agree on what the best practice is, providing the greatest possible level of information.

My team at Marflow Hydronics actively encourages the use of such documentation, as getting the design, installation and commissioning of systems right, and right first time, is so important to the long term welfare of any system.

This was a guest post by Ian Harman, Technical Applications Engineer at Marflow Hydronics, BSRIA Member

%d bloggers like this: