IFC (Industry Foundation Classes) – Part 08 – Exporting COBie using an IFC workflow from Autodesk Revit
By understanding the previous blogs in this series you should now have enough knowledge to export a good quality IFC and understand the importance of doing so. When I started testing these IFC workflows back in 2015 the catalyst was to export asset information as specified by the Construction-Operations Building information exchange (COBie) schema. I wanted to see if COBie could be exported as a part of an IFC process since after all it was a subset of IFC. From my testing I discovered for the majority of the data it was possible.
Model View Definitions
The whole IFC schema is huge! It’s not just elements, there are processes, resources and even people related entities, it covers a lot of uses for information in the built environment.
It captures so much for many different purposes, you wouldn’t want to exchange the whole thing and software wouldn’t be able implement it.
So we need to be able to filter it into mini schemas. These filters are called model view definitions or MVDs.
NOTE: Some of these are in development and not official buildingSMART MVDs
BuildingSMART are currently changing the way IFC is filtered replacing the rigid MVD concept with a more flexible modular Information Delivery Specification (IDS) concept which ties in much better with the exchange information requirements (EIR) process and incorporates the level of information need framework.
This blog post is the final part of this series and is what the previous posts have been building towards. If you have followed the previous posts you are well on your way to exporting COBie from Revit using the IFC workflow.
It’s worth noting that technically this isn’t true COBie, as COBie doesn’t require geometry but you cannot export data from Autodesk Revit without it, so currently it is a hybrid of the geometry from the coordination view 2.0 MVD and the required data to satisfy COBie.
At Bond Bryan Digital we ask consultants to follow the IFC workflow set out in this blog series to produce IFC models. We take these models and check them using Solibri Office. Because the data is in the same place each time we can run a set of rules to check the information for compliance. Using Solibri we then extract the data required by COBie and put into the spreadsheet format. As a final check we run the spreadsheet through the COBie QC checker as an official check. This is just one method there are other ways of extracting COBie data from an IFC-SPF file such as using BIMserver.
IFC-SPF workflow compared to the COBie Extension
The IFC workflows documented in this blog series allows you to build up an IFC data model in the background to enable IFC-SPF outputs for many different purposes, not just the ones captured by COBie. For example ensuring the entities are aligned correctly, naming of objects, classifying them and adding properties would be needed for any model view definition.
The COBie Extension is a bespoke workflow which will allow you to export a COBie formatted spreadsheet.
If the requirement for the project is just a COBie formatted spreadsheet – the COBie Extension will meet your needs. However on most projects in the UK a COBie spreadsheet and an IFC-SPF file are required. You cannot use the COBie Extension alone to export a quality IFC-SPF file you always need to use the IFC exporter. Therefore when this is the case rather than doubling up on workflows it much easier to do the IFC workflow which will also give you COBie. It also means we can export data for many different purposes not just the ones in COBie.
The COBie extension is also very literal as it adds specific COBie parameters for every COBie field – which using the IFC method are not needed because it makes use of the relationships from the IFC schema. This method also makes far more use of the hard wired Revit parameters.
Please note this blog is not about the detail of COBie. If you would like further information please see the following:
- NBIMs-US version COBie standard 2.4
- BS 1192-4 in the UK
- Bill East’s YouTube channel
COBie 2.4 is currently being updated by builidngSMART international.
In this blog post I’m going to go through the parts of the IFC schema required for COBie and point out where this data needs to live in Autodesk Revit. Most of it has already been covered in earlier blog posts.
The tables below list the:
- location in the IFC schema,
- parameter to use in Revit
- part of the COBie schema it will populate
- blog post where further information can be found
Mappings between IFC and COBie are available in annex A of the NBIMS-US v3 COBie standard 2.4.
Note that using the IFC Exporter I’ve had little success using the ‘IFC2x3 COBie 2.4 Design Deliverable’ set-up, the two additional tabs are limited in how well they work. Therefore I just create a bespoke one based on IFC 2×3 Coordination View 2.0.
(HW) = Hardwired parameter
(SP) = Shared parameter
All COBie worksheets
Currently this will be related to IfcBuilding or IfcSite. For this to work correctly it needs to be related to IfcOrganization, since it’s the address of the organization and not the facility that’s required. This is what the ‘Company Info’ tab of the COBie 2.4 set-up in the IFC exporter should do however I have little success with it.
COBie.Facility worksheet Phone, OrganizationCode, Category currently cannot be exported to IFC via Revit.
AreaMeasurement which is a base quantity cannot be exported to IFC via Revit.
*This is where one of the Autodesk pre-defined parameters could be used
**Autodesk Revit only calculates one area for rooms, which tends to be the net area. Even if you were to add the gross area manually (which wouldn’t be advisable) there is currently no way of doing this since the area base quantity override does not work.
Note: Manufacturer, ModelLabel and ModelReference are IFC properties therefore will automatically export (as long as Export IFC property sets is checked in the IFC Exporter) – therefore they do not need including in user defined property set text file in blog post 05.
Note: SerialNumber and BarCode are IFC properties therefore will automatically export (as long as Export IFC property sets is checked in the IFC Exporter) – therefore they do not need including in user defined property set text file in blog post 05.
As mentioned in blog post 07 true IFC systems can only be exported for Autodesk Revit Pipe and Duct categories and not electrical circuits or any other building system. Therefore due to these restrictions exporting the system might have to be done via properties which is technically incorrect and not ideal but at least the data for all the required systems would be present.
General points to note
The exported IFC-SPF file will automatically contain the information with regards to the following COBie fields:
- Unit fields
COBie fields which are referencing fields from other worksheets are captured as part of the IFC schema and the relationships between objects. For example COBie.Space.FloorName doesn’t have to be populated again because a space in IFC knows which floor/building storey it belongs to. This is why IFC is so powerful and why it’s important the data is in the correct place.
I hope this blog series has proven useful and demystifies the confusion surrounding this topic helping you in your daily work. The aim of this blog series was to improve the quality of IFC models being exchanged within the industry and the knowledge of those producing them. I hope you can see now why exporting an IFC model is simply not a case of just clicking export and the importance of IFC as a data model and specification.
Let’s hope this is as complex as it will ever get! Autodesk are now committed to making this process easier. If you have any ideas on how to improve it please let them know 🙂
Emma Hooper, Associate (Digital Information Specialist), Bond Bryan Digital
Terms and conditions
All content provided on this BIM Blog is for informational purposes only. The owner of this blog makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. Bond Bryan will not be liable for any errors or omissions in this information nor for the availability of this information. Bond Bryan will not be liable for any losses, injuries, or damages from the display or use of this information.
We are happy for others to share our blog pieces through all social media platforms. You may include links to the original blog pieces and use part of the blog to then provide a link to the original content. However we would appreciate it if the content is not reproduced in full on other sites or publications without written consent being granted by Bond Bryan.
This policy is subject to change at any time.