PLQ2.4 – COBie Round 1

Hello BIMfans,
After lasts weeks review of The Importance of being openBIM, this week I have managed to fully populate my mechanical model with all of the assets I want to capture within it to satisfy my Plain Language Question 2.4 (only Architectural and Electrical to go!).   The work in progress model can be accessed as both a Native Revit file, an IFC file, and have I even tried to do a COBie export to see where the gaps lie…

Needless to say it hasn’t exactly been a smooth process so far.

While I haven’t given it too much thought, when creating new objects I have tried to ensure that I fill them with the information I need to answer my Plain Language Questions about attribute data; for the most part this has been successful.

Note:  So far all I have done is map over the COBie properties and my additional property sets, I haven’t tried to make all my sheets work; that happens during PLQ 2.5.  

However, nothing in life comes easy, and COBie is no different.  Shown below is a screenshot showing that my components have at least successfully transferred over some of their data with them.

The file is far from complete, but if you want to see how my mechanical COBie file is shaping up, you can access it here.

At this point I have noticed a number of elements work well, and a number of elements work not so well.  Note:  It is worth pointing out that there is likely to be (an element of) user error as I have not fully investigated how to export this information correctly; yet.

The Good:

Because I have used the shared parameters and property set mapping files I introduced in the last blog post many of my properties are exporting correctly, such as: Bar Code, Serial Number, Material, Shape & Size.  I have also managed fixed my dimension error from last week thanks to Autodesk customer support (I had to change the data type from ‘Real’ to ‘Length’).  So the attribute mapping process appears to be going well.

The Bad:

I’m afraid that it isn’t all sunshine & rainbows however as some elements are not working exactly as I hoped.  Currently: ‘Category’ properties don’t seem to carry despite appearing within the IFC object’s properties, and something similar is also happening with ‘Description’.  As you can see below, my IFC file captures this information but when I use xBIM to create COBie the information just doesn’t seem to carry.

Where has that hammer gone?

The Ugly:

It gets worse.  As the IFC export doesn’t capture data from linked files I need to create rooms/spaces in each model so that my components can export space information. This means that when I produce my combined COBie file I will need to delete duplicate space instances as I’ll end up with three Living rooms.  In addition, no matter what I do I cannot seem to get an object’s ‘Category’ to export and appear within the COBie type sheet  (or even other sheets when I tested them too) despite appearing within the IFC.  For matters like this I normally turn to xBIM’s Github but sadly I have not found the solution yet.

Finally, within my attribute tab, I am getting duplicate attributes.  It appears that despite being recorded as an instance or type property, when exporting some properties are coming out as both; making the sheet more difficult to read and much longer too.

Over the next few weeks as I complete the graphical element of my information model, I will also be looking into resolving these issues to attempt to create a bespoke IFC FM Handover that’ll include as much information to complete my COBie export as possible, and satisfy my data requirements.

But first, let’s focus on the matter at hand.  What assets are in my home?  Well here is a schedule of all the Mechanical assets I am including that fall under the responsibilities outlined within my Design Responsibility Matrix.

To be honest, at this point I just need to know how many assets I have.  I should just be happy that I have 10 objects within my IFC file, and 10 components within COBie too!

And there you have it, now that I have a schedule of my mechanical assets, I am well on my way to answering this Plain Language Question.  This means that subject to ensuring I follow suit my Architectural and Electrical information models; completing PLQ2.4 shouldn’t be far away!

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 Mechanical is sufficiently developed, it’s time to look at some more electrical objects…

6 thoughts on “PLQ2.4 – COBie Round 1

  1. Can some explain why we have a goal of outputting COBie data via IFC?
    Is the COBie data a lot more accessible, auditable, and mush easier to export using the Spreadsheet output? This is the final format the UK BIM Level 2 looks for, so why push a process on suppliers which may be unnecessary.
    The goal of BIM Level 2 is to be lean. Revit to IFC to a COBie spreadsheet is not lean. In fact, holding all that data directly Revit is a bad idea – see this:
    So I ask again: “Why we have a goal of outputting COBie data via IFC?”


    • Hi Brian, as you know IFC isn’t a requirements of BIM Level 2. However, it is a requirement that I specified within my EIR.

      To achieve my IFC export, I haven’t done anything extra as all the data I’ve added I need to satisfy my data requirements. I can’t see why this is less lean then having to map all of this into the Revit COBie plug in but end up with non-IFC friendly properties?

      The core of what I am trying to achieve with this blog is to show the power of good data. In order for me to export my data into COBie, I chose the IFC route as it would allow me to validate my data has exported correctly and ensure I had structured my data in a consistent and open manner. I also wanted an IFC export at the end of this process to maximise the use of my house model; so why not kill both birds with one stone?


  2. Thanks Dan

    I’m not sure if you read the link I posted above. We have to add the design data anyway. That would be part of the COBie deliverables. The issue is managing the data we add, and then collecting the commissioning and submittal data.
    No BIM Authoring app. manages data. Pretending it does, is just kidding ourselves.
    No BIM Authoring App. manages commissioning data, including associated docs, Assembly, Connection, Impact & Issue,Spare, Resource & Job worksheets.
    How are you going to address these items in an IFC delivery approach?
    The more we convert data from one format to another the more we waste time and degrade the data.
    As you can see you are also having problems with generating COBie from multiple models. IFC is just adding to your problem. Also, we need to consider, the project will be using more than just Revit. Some of the apps. may have limited IFC export capabilities.
    As I said again. The client is looking for an outcome. Delivering quality COBie is very difficult. Keeping the process as simple as possible is going to make it easier.
    I believe you need to relook at your EIR. Why is it a requirement that the COBie data is an integral part of the MVD (IFC) delivery?


    • IFC is not at fault; outside of the blog I tried the direct Revit to COBie and still had the same space and attribute mapping issues. The problem is the capability of the authoring tool, and the level of information being collected. You seem to think that IFC is hurting my export when it is actually helping me check and validate my properties by providing a slimmed down file to the FM Handover MVD to review (330kb (yes kilobyte) is the total size of my Mechanical IFC file).

      I don’t require COBie to exported out of IFC in my EIR, but I have asked for COBie & IFC and decided during production that it was better to manage these in tandem as opposed to in isolation.

      You are right in that no authoring tools manage data well, and I don’t expect them to. I will be managing my data during operation using a different tool, one by

      I am using Revit to capture object attribute data. Because a number of services are hidden I have consciously chosen not to capture connections and assemblies (both optional anyway). I would never expect the IFC to capture spares, impacts, resources and jobs; these are input and managed by the FM in their own software and only go into COBie when needed to exchange this information. COBie is just a suitcase. (Even if this wasn’t the case, I have no spare radiators in my home and the fiancee would be offended if I referred to her as a resource!)

      Considering my requirements, the tools available to me, and my capability in each this process works for my house and this scenario. This blog isn’t a best practice blog, it is an account of me developing and delivering the data I want about my house.


Leave a Reply

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

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

Facebook photo

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

Connecting to %s