Seven or eight tier one contractors agreed to take part in the challenge. We provided a building information model in Autodesk Revit and IFC2x3 format. The software vendors Graphisoft and Vectorworks then created equivalent design models in their native formats with corresponding IFC2x3 files too. This allowed each contractor to analyse the model using their chosen software applications.
The main challenge we gave to the contractors was to create the COBie data file, but we also looked at whether deliberate problems in the model could be found and then whether subsequent modifications could be verified.
The activity, the files produced and then the written feedback and the feedback received in a half-day user group meeting was fascinating.
The report on these findings is a free download from the NBS website:
- http://www.thenbs.com/topics/BIM/cobie/index.asp
My thoughts:
Firstly, IFC can definitely be used as an intermediate format to produce COBie datasets. When people report problems with the use of IFC they are always glitches in the geometry or visuals. The good news about COBie is that it is all about the objects and their property sets. So the hierarchical nature of IFC (building, spaces, type objects, component objects, property sets) makes this map perfectly to COBie. As COBie is originally a buildingSMART Alliance initiative this is no surprise. "COBie is a subset of IFC" is something that is often said.
In terms of the specific task of creating COBie from IFC, Solibri Model Checker in particular (which has always worked of IFC as the base file format) was very good once the IFC had been exported from the BIM design package.
So overall - very positive. However, there were also a number of recommendations made in the report. Looking at these now, there are three that really stood out for me. The good news is that I think that the parties involved in these respective items recognise this and progress is being actually already being made on all three.
1. "The group felt that there are weaknesses in the IFC import /export processes in existing software products..."
One way for this to improve is for users of the products to request it. Over the last year or two, as part of a growing move from lonely-BIM to collaborative-BIM, I think this is now happening. If you check the release notes from some of the BIM vendors you will see IFC mentioned a number of times everytime a new release or service pack comes out. Examples of this are below:
- Autodesk Revit 2013 Update 2 - release notes
- Graphisoft ArchiCAD 16 - feature list
2. "buildingSMART must enforce IFC import/export routines in the commercial software. To do this they must ensure their IFC certification programme does effectively enforce the quality of the data flow..."
This was discussed at the "BIM for free" event last year. Following my blog post after this event Jeffery Ouellette from Vectorworks responded:
Could a similar test be developed by buildingSMART that gave a very public test of graphics, visuals and data?
3. "The industry needs well defined model view definition for each COBie data drop. From this can come clear guidance on the 'level of detail' required at each COBie data drop..."
Asking for classified objects, their relation to spaces and their COBie FM properties (installation dates, warranties, supplier names) is a challenge. But a challenge that can be overcome with current technologies. But the bigger challenge is around the level of information required within these objects over-and-above the basics. This is the information that is found in the Attributes table in the COBie data set.
Does the client want every single parameter for each object to be dropped in here? - I think this is unlikely - the volume of unnecessary data would be huge.
So what data is needed? And which data drop is each piece of data needed for?
Take a Door for example - when does the client want to have the fire rating and acoustic rating added to the spreadsheet? Data drop 3 perhaps? Well... what about other properties such as air permeability, blast resistance, smoke resistance, wind resistance, weather tightness, inclusive design and then also the properties of frame, leaf, glazing etc... Defining all of this in a construction dictionary, for all major construction systems and products - and then defining at what level this information is required is a huge challenge. Can anyone truly say they have met the Government's 2016 targets until this task is done?
In the report, Nick Nisbet from the UK BIM Task Group explains the progress on this task...
Next steps:
Having a group of tier one contractors giving up their time and looking into this from private sector point of view is an extremely good thing.
The next steps that were discussed were (1) merging more than one model - so for example architecture, structural and services models developed in different software applications and (2) looking a little more under-the-hood into the specification properties within the objects.
As we stray into specification, it probably wouldn't be right for NBS to run the next trial. But through our membership of the BIM Technology Alliance we will certainly fully support it and offer NBS software and NBS content for the future stages.
So some thoughts from me - but please find the time to download and read the final report...
- http://www.thenbs.com/topics/BIM/cobie/index.asp
The report on these findings is a free download from the NBS website:
My thoughts:
Firstly, IFC can definitely be used as an intermediate format to produce COBie datasets. When people report problems with the use of IFC they are always glitches in the geometry or visuals. The good news about COBie is that it is all about the objects and their property sets. So the hierarchical nature of IFC (building, spaces, type objects, component objects, property sets) makes this map perfectly to COBie. As COBie is originally a buildingSMART Alliance initiative this is no surprise. "COBie is a subset of IFC" is something that is often said.
In terms of the specific task of creating COBie from IFC, Solibri Model Checker in particular (which has always worked of IFC as the base file format) was very good once the IFC had been exported from the BIM design package.
So overall - very positive. However, there were also a number of recommendations made in the report. Looking at these now, there are three that really stood out for me. The good news is that I think that the parties involved in these respective items recognise this and progress is being actually already being made on all three.
1. "The group felt that there are weaknesses in the IFC import /export processes in existing software products..."
One way for this to improve is for users of the products to request it. Over the last year or two, as part of a growing move from lonely-BIM to collaborative-BIM, I think this is now happening. If you check the release notes from some of the BIM vendors you will see IFC mentioned a number of times everytime a new release or service pack comes out. Examples of this are below:
- Autodesk Revit 2013 Update 2 - release notes
- Graphisoft ArchiCAD 16 - feature list
2. "buildingSMART must enforce IFC import/export routines in the commercial software. To do this they must ensure their IFC certification programme does effectively enforce the quality of the data flow..."
This was discussed at the "BIM for free" event last year. Following my blog post after this event Jeffery Ouellette from Vectorworks responded:
"Well, this IS being done, right now:
http://www.buildingsmart-tech.org/certification/ifc-certification-2.0/ifc2x3-cv-v2.0-certification
Right now, we are anticipating the first Export certifications to be completed Spring 2013."One idea I have been keen on for a number of years here is that there should be some independent IFC test file that each software application can be marked on depending on its ability to accurately represent it/read the data. The web community has done this for a number of years with the ACID3 test. The quality of web browser when it comes to open standards has improved beyond belief going from the days of Internet Explorer 6.
3. "The industry needs well defined model view definition for each COBie data drop. From this can come clear guidance on the 'level of detail' required at each COBie data drop..."
Asking for classified objects, their relation to spaces and their COBie FM properties (installation dates, warranties, supplier names) is a challenge. But a challenge that can be overcome with current technologies. But the bigger challenge is around the level of information required within these objects over-and-above the basics. This is the information that is found in the Attributes table in the COBie data set.
Does the client want every single parameter for each object to be dropped in here? - I think this is unlikely - the volume of unnecessary data would be huge.
So what data is needed? And which data drop is each piece of data needed for?
Take a Door for example - when does the client want to have the fire rating and acoustic rating added to the spreadsheet? Data drop 3 perhaps? Well... what about other properties such as air permeability, blast resistance, smoke resistance, wind resistance, weather tightness, inclusive design and then also the properties of frame, leaf, glazing etc... Defining all of this in a construction dictionary, for all major construction systems and products - and then defining at what level this information is required is a huge challenge. Can anyone truly say they have met the Government's 2016 targets until this task is done?
In the report, Nick Nisbet from the UK BIM Task Group explains the progress on this task...
There are already a couple of formal 'MVD's which define the maximum information content of COBie drops up to Tender and up to Handover. The UK documentation already contains extensive text and illustrations of the client Purposes and the content of the Drops. We are now working on developing these and the templates already published, into tables of object Types, groups of Attributes and the expected delivery based on the new CIC stage-gates. These schedules will then represent the minimum requirement for each Drop.So three big recommendations - but good news that all are progressing.
 |
| The user focus group |
Having a group of tier one contractors giving up their time and looking into this from private sector point of view is an extremely good thing.
The next steps that were discussed were (1) merging more than one model - so for example architecture, structural and services models developed in different software applications and (2) looking a little more under-the-hood into the specification properties within the objects.
As we stray into specification, it probably wouldn't be right for NBS to run the next trial. But through our membership of the BIM Technology Alliance we will certainly fully support it and offer NBS software and NBS content for the future stages.
So some thoughts from me - but please find the time to download and read the final report...
- http://www.thenbs.com/topics/BIM/cobie/index.asp
Wow, great article, I really appreciate your thought process and having it explained properly, thank you!
ReplyDeleteHow about focusing on the real problems with IFC Namely
ReplyDeletethe screwed up geometry....which leads to very poor simulations
From an Engineering perspective