The Importance of Being Open(BIM)

Hello BIMfans,
Last week I started to build my mechanical model and had managed to compare different object vendors to select my preferred boiler object.  This week I have started to build my electrical model and wanted to discuss the importance of proper data formatting.  I need to do so to ensure that when information is exported from my native authoring tool (Revit) into IFC, it is formatted correctly.  As an active member of buildingSMART, I am a strong believer in open formats, and the importance of being open(BIM).

TheImportance of Being Open(BIM)

What is openBIM you ask?  In short, it is the use of non-proprietary methods to delivery asset information.  There is a short video that explains it better than I can here.

The non-proprietary method I’m referring to is Industry Foundation Class (IFC); think of it as the PDF of the built environment.  No matter what software you use to make a document, if you convert it into a PDF it’ll allow others to access this information without having purchased the software you used; this is what IFC achieves.  Note:  There any many other benefits too I won’t discuss here, but if you are interested I suggest you read Rob Jackson’s excellent blog post on Why Use IFC).

As IFC has a language (Schema), it comes with its own grammar (Property Sets) which includes acceptable words (Properties) that can be used providing consistency and the opportunity for validation.  For example, take my Nest Thermostat.  Under IFC2x3 (the current recommended release) it is classified as an IfcSensorType and I can associate a number of standard property sets to this object to define it.  Note:  In IFC4 a thermostat is a IfcUnitatryControlType, but for the purposes of this blog I am sticking to the recommended release of 2×3.

To make this a successful BIM Level 2 project, I need to export information about my Thermostat that I defined at the start of blog when I discussed my Model Purposes & Data Requirements.  As I discussed during these posts, I will need properties relating to condition, warranty, and manufacturer information.  By looking through the IFC Schema I can find suitable property sets and properties to include that are structured in a consistent manner.  After searching, I came up with the list below:

  • Pset_ServiceLife
  • Pset_EnvironmentImpactIndicators (for my energy use)
  • Pset_Condition (for monitoring until it requires repair/replacement)
  • Pset_Warranty (for reference when being repaired/replaced)
  • Pset_ManufacturerTypeInformation (because it is a manufactured product)
  • Pset_ManufacturerOccurrence (because it is a manufactured product)

Note:  I will also need any properties required for types & components to satisfy COBie within BS1192-4.  

The problem is that to do this properly, it take a lot of work.

To help, there is a COBie extension for Revit that helps create COBie files from the native file format (A requirement of PAS1192-2).  However, it does not create correctly named IFC properties and each property that is created is prefixed with ‘COBie.<sheet>.<property>‘, I also found it difficult to control which properties did export and which did not.  Because of this, I chose not to use the export tool.  Also, since I requested IFC as a deliverable within my EIR, I need to make sure that the properties are structured properly; so I have decided to do this the long way.

In order to get a decent looking IFC, I needed to define my property sets. Revit can’t do this.  So to do it I had to create a number of shared parameters and a custom property set definition file to allow them to export correctly using the IFC Exporter.  At the same time is also used it to define my COBie properties too (excerpt below).

IfcExportSample
A copy of the defined property set file can be found here.

Using this file, it moves object properties into the defined property sets.  This is important because in Revit you cannot create property sets.  Because you can’t all the properties end up under one of the pre-defined categories (I’ve chosen IfcParameters for many of them). However this definition file resolves this when exporting.

MappingBeforeAfter.JPG
Shown Left:  Properties in the Revit file, Shown Right:  Properties in the IFC file, Shown off screen:  My agony in getting all of this to work!

Note:  To view IFC files there are many viewers available.  For this blog I have chosen to use xBIM. xBIM is a free open source viewer that also has the ability to federate models and export COBie files.

IfcThermostat
You can access the IFC File for my electrical model here.

Now here is the exciting bit.  Because I have defined the property sets I require including all of my Data Requirements and COBie properties I am able to create my COBie data in a number ways including:

  • Export Revit schedules to transpose into a COBie template;
  • Export directly from IFC into COBie; and
  • Install the COBie Extension and remap its properties to use my IFC properties.

So whichever method I choose I have a good set of data I can rely on.

COBieExport
I have 99 problems, but my Thermostat ain’t one.

I will point out however that it isn’t all sunshine and rainbows.  There are a few problems that I still need to resolve when exporting into IFC:

  • I cannot get an object’s category to export properly;
  • Under my attributes tab, a number of properties have duplicate instances.

UPDATE:  I have an issue with my NominalLength and NominalWidth properties, but after contacting Autodesk they have advised me to use ‘Length’ instead of ‘Real’ during the property mapping to achieve this.  I have now tested it and it works perfectly, so thank you Angel & Autodesk!

I will continue to explore this and will report back in the future post, but if anymore has any ideas feel free to let me know!

And there you have it, after reviewing how I create my information, I have now developed an openBIM workflow that allows the information I have created in Revit to be exported as an IFC, and this IFC aligned data can be used to create a fully populated* COBie file. Because of this my data is well structured and most importantly consistent with an international schema.

This means that if I apply this process to all of the assets within my model I should then be able to answer this Plain Language Question, and will have all the information I need to have delivered a fully compliant BIM Level 2 Information Model.  So let’s get to it!

Model Generation:
2.1 What existing information is available?
2.2 Is there sufficient information to produce a BEP?
2.3 What is the layout of the house?
2.4 What assets are contained within?
2.5 What asset information can be linked to the graphical model?

Now that I have started my electrical model, it’s time to add other assets such as my lights and fire alarms…

Note:  If you have any comments or opinions regarding my openBIM process, please let me know either on twitter, or commenting below.

2 thoughts on “The Importance of Being Open(BIM)

Leave a comment