buildingSMART Forums

COBie and IFC mapping

I have seen the COBie responsibility matrix downloadable from this page. I have questions:

  1. The responsibility matrix seems to not be updated for IFC4. Is there an updated one out there?
  2. The IFC mappings in the spreadsheet are vague as to exactly what the relationships are and how to parse an IFC into a COBie spreadsheet.
  3. I have seen this COBie MVD and attempted to download the COBie.mvdxml but I am unable to import it in IfcDoc. Because I cannot open it, I cannot validate IFC files for their COBie content. Where can I find an .ifcdoc or .mvdxml that I can use, or how can I resolve this error message shown below that occurs when I try to import it?

In addition, does anybody know an open source and cross-platform IFC to COBie converter (not xBIM, as it is .NET based, and Mono is a pain on Linux)?

See the end of this message for details on invoking 
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.InvalidOperationException: The file is not of a supported format (mvdXML 1.0 or mvdXML 1.1).
   at IfcDoc.Schema.MVD.SchemaMVD.Load(DocProject docProject, String filename) in c:\dev\BuildingSmart\IfcDoc\SchemaMvd.cs:line 66
   at IfcDoc.FormEdit.toolStripMenuItemFileImport_Click(Object sender, EventArgs e) in c:\dev\BuildingSmart\IfcDoc\FormEdit.cs:line 794
   at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
   at System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
   at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met)
   at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met)
   at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
   at System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
   at System.Windows.Forms.ToolStrip.WndProc(Message& m)
   at System.Windows.Forms.ToolStripDropDown.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

************** Loaded Assemblies **************
    Assembly Version:
    Win32 Version: 4.7.3132.0 built by: NET472REL1LAST
    CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll
    Assembly Version:
    Win32 Version:
    CodeBase: file:///C:/Users/moud308/Downloads/IfcDoc-Exe-12-0/IfcDoc.exe
    Assembly Version:
    Win32 Version: 4.7.3062.0 built by: NET472REL1
    CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
    Assembly Version:
    Win32 Version: 4.7.3151.0 built by: NET472REL1LAST_B
    CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll
    Assembly Version:
    Win32 Version: 4.7.3062.0 built by: NET472REL1
    CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
    Assembly Version:
    Win32 Version: 4.7.3062.0 built by: NET472REL1
    CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
    Assembly Version:
    Win32 Version: 4.7.3081.0 built by: NET472REL1
    CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll
    Assembly Version:
    Win32 Version: 4.7.3062.0 built by: NET472REL1
    CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll
    Assembly Version:
    Win32 Version:
    CodeBase: file:///C:/Users/moud308/Downloads/IfcDoc-Exe-12-0/BuildingSmart.Utilities.Conversion.DLL
    Assembly Version: 7.0.3300.0
    Win32 Version: 7.0.3300.0
    CodeBase: file:///C:/windows/assembly/GAC/Microsoft.mshtml/7.0.3300.0__b03f5f7f11d50a3a/Microsoft.mshtml.dll
    Assembly Version:
    Win32 Version: 4.7.3062.0 built by: NET472REL1
    CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/Accessibility/v4.0_4.0.0.0__b03f5f7f11d50a3a/Accessibility.dll
    Assembly Version:
    Win32 Version:
    CodeBase: file:///C:/Users/moud308/Downloads/IfcDoc-Exe-12-0/BuildingSmart.Serialization.Step.DLL
    Assembly Version:
    Win32 Version:
    CodeBase: file:///C:/Users/moud308/Downloads/IfcDoc-Exe-12-0/BuildingSmart.Serialization.DLL
    Assembly Version:
    Win32 Version: 4.7.3130.0 built by: NET472REL1LAST_B
    CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/System.Runtime.Serialization/v4.0_4.0.0.0__b77a5c561934e089/System.Runtime.Serialization.dll
    Assembly Version:
    Win32 Version: 4.7.3130.0 built by: NET472REL1LAST_B
    CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/SMDiagnostics/v4.0_4.0.0.0__b77a5c561934e089/SMDiagnostics.dll
    Assembly Version:
    Win32 Version: 4.7.3062.0 built by: NET472REL1
    CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll
    Assembly Version:
    Win32 Version: 4.7.3062.0 built by: NET472REL1
    CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll
    Assembly Version:
    Win32 Version: 4.7.3062.0 built by: NET472REL1
    CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll
    Assembly Version:
    Win32 Version: 4.7.3062.0 built by: NET472REL1
    CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll
    Assembly Version:
    Win32 Version: 4.7.3062.0 built by: NET472REL1
    CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the section.
The application must also be compiled with debugging

For example:

    < jitDebugging="true" />

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.

Welcome to the jungle.

You have to build your own COBie (or whatever you want to name it).
And I think in @IFCWebServer you find something, but I don’t know does it in which stage? Just a concept or something more?

However, with IfcDoc you can build your own COBie MVD/DTV
Just open that PDF file and see tables (responsibility matrix) that included IfcXs
And also open COBie spreadsheet and look at ExtObject columns and their values and relationships on PickLists

I checked that page now you provided.

  1. Download the whole NBIMS V3 and check COBie section and its COBie Annex A & B
  2. Check this page
  3. Download Spreadsheet Template from the link you provided at first, NIBS page.

And do aforementioned path

As I could not find a satisfactory and transparent IFC->COBie spreadsheet converter, I am writing my own based off the official COBie responsibility matrix, discovered as the current “source of truth” for how COBie->spreadsheet mappings are meant to work thanks to @jonm.

I am still in the process of doing so, but it seems as though that the updates to IFC4 are minor at a first glance (e.g. a particular attribute might’ve been renamed)

The code will be in Python, which interprets exactly what is written in the original responsibility matrix. it will be open-source so anyone can contribute and inspect the exact programmatic relationships. Please note that the relationships are not a simple mapping, they actually follow “if” and “loop” logic, which is why this approach is taken.

Development can be tracked here:

Some months ago I said COBie is not suitable today

Still you can follow COBie, because the industry still works based on COBie, especially COBie spreadsheet, but soon you will realize that you need to focus on FIM and AIM, and forget what COBie is

In case there is any misunderstanding, I would note that COBie deliverables are first and foremost delivered in an IFC file that validates with the COBie MVD. The assets included in this IFC file, by default, follow the asset and asset type lists shown in the COBie responsibility matrix. However, this may change should the client particularly require it for the asset management system.

I personally do not condone COBie to be delivered in a spreadsheet format for any large / complex / significant project. This is taken from the original publication by Bill East, where he says:

When people want to look at the COBie data directly, and they do not want to learn to read complex STEP file formats, they can use a translation of data into a spreadsheet.

He also says:

Why is COBie a spreadsheet? A

Given a large project and progressive owner, there will be sufficient overheads needed to provide a wide range of value-added services that may include the proprietary development of Facility Handover data sets. Most public projects are, however, relative simple, square buildings, completed on a shoestring budget with taxpayer funds. An open exchange format for facility handover data must, therefore, accommodate both the large custom buildings and small public buildings with the least common denominator of technology allowing the widest possible set of project stakeholders. COBie for large projects uses IFC-standard STEP and ifcXML formatted files. Small projects may exchange COBie data, displayed as spreadsheets, and directly update COBie data using these common spreadsheet programs.

Emphasis added is my own.

That said, an open, transparent, simple COBie IFC->Spreadsheet converter tool is very useful for quick auditing, even on large projects. The ability to view COBie data in a spreadsheet form is not an excuse for poor data quality in the originating IFC file, nor is it an excuse to omit other useful data that is present in the COBie MVD but not exposed in the spreadsheet … overall, it is still a very human-readable snapshot, which is invaluable.

For this reason, I am building this tool based on Bill East’s original intentions of how the spreadsheet snapshot would operate.

Please do not interpret COBie to be purely a spreadsheet. COBie is an MVD.

I admire COBie and Bill East’s work because it was one of the first practical attempts to build a (small) “Relational Information System” inspired from Charles Eastman’s efforts

Indeed, Bill East has tried to build an “efficient Information System”

Today, for FIM, for AIM, for BOM, for PM, for anything, you just need to extract data/information (especially objects/components) from IFC and control data/information exchange (rule checking)

I don’t talk about IFC and IFC-STEP (because some may be unhappy)

And at the end you will need these three :grinning::

  1. Material Template/Pass -->
  2. Product Template/Pass -->
  3. Facility Template/Pass -->

The code for the COBie IFC->Spreadsheet extraction is now complete for all worksheets in the COBie spreadsheet template. The bug ( has now been closed. With this tool, you will now be able to take any IFC file (even one that hasn’t been especially created with the COBie MVD requirements - although of course it is ideal that it should be) and convert it into a COBie spreadsheet.

The tool will be integrated into Blender BIM, and also released as a standalone utility soon. I will mark this as solved.

I should note that it is based on the responsibility matrix, which according to Bill East is not authoritative, and in fact should follow the MVDxml. This means that the tool is not yet complete, and needs another round of review. However, it is a starting point.

An example output (with a bit of censorship) is shown here:

Well done Dion,

Now, focus on this and see your solution does this correctly? Most software can’t do this:

Also, add these six:


The spreadsheet data conversion is only as good as the input data available in the IFC file.

Most authoring software implement owner history poorly, to my understanding.

There is no need to add those six, as they already exist in the IFC file. Just because they don’t appear in the spreadsheet doesn’t mean it doesn’t exist.

In the future I will build a feature where you can add custom columns with your own mappings, and therefore you can, indeed, add those six yourself.

Both IFC and COBie spreadsheet are not “static” and most of the times, COBie spreadsheet doesn’t use just as an archive (which the input data just comes from IFC file)

For this reason “you have to have a mechanism to archive changes inside the spreadsheet”

IFC has IfcOwnerHistory yes, but as you mentioned nobody uses it and even bSI is thinking to drop it. But I think it’s useful, especially after ISO 19650 which mainly focuses on legal aspects, so owner and owner history becomes important

Also, take a look at IfcOwnerHistory it doesn’t have any “logic” to archive “all” changes, it just provides the last change

About the feature that adds custom columns, I think it would be really useful

I saw you work on an invaluable idea to be able to generate “custom MVDs = MicroMVDs”

Hello, Dion.
Is it already developed to test it?
I was talking with @jonm because we were testing his ggExcelIfc addin to generate COBie Spreadsheet, and he suggested me to ask you about your development.
Let me know.

Hey @daviddelven - it is ready for testing. A few things to keep in mind:

  1. It follows the mapping in the responsibility matrix to the letter. It expects to find data in exact locations.
  2. The results are only as good as the IFC input. If the authoring program that produces the IFC is incapable of recording the data in the right places, the spreadsheet output will not give you “good” results.
  3. It is alpha software. It would be great to get people testing it! However, it is rather fresh so I expect bugs to be found. If your share the bugs, I can help fix them :slight_smile:

Which OS are you on? Have you got IfcOpenShell and Python already installed? If not, I can help package it for you for your particular OS.

Feel free to send me an email at

Hi, Dion.

  1. Good.
  2. What we expect.
  3. That’s the point!

We are running W10 Home 64bits
IfcOpenShell and Phython not installed, yet.

Your help would be welcome…!

There is a plugin for the Polish BIM Vision IFC viewer/evaluator, called COBie Exporter, which is generating COBie spreadsheets from the IFC import, @daviddelven, it’s also in Spanish :slight_smile:

David, see you in Poland :slight_smile:


1 Like

Hello, Rob

Thanks! We know it.
I only use english or INT versions.
I like the modular approach of BIM Vision, in general.

I hope to see you in Poland, too!


For now, we are trying to test + COBie plugins.
We’ll see.

@daviddelven - I will package it for you tomorrow :slight_smile:

1 Like

I appreciate it, Dion!

@daviddelven - please see latest Windows build here:

It is called cobie-191024-win.exe. It should be self explanatory - it requires a file called input.ifc in the same folder you are running the program from.

When run successfully, it should let you know, and give you an option to exit. However, being alpha software, it may run into bugs - if this is the case, please run it using Powershell on Windows, and that will give me debug information I can use to fix it. Ideally, also send me an email or we can chat in real-time on IRC on the ##architect channel and send me your IFC file.

This tool essentially should do the same as what the BIMserver + COBie plugins does, with a few differences:

  1. Smaller, lighter, and easier to get started with. It does not depend on Java, it does not require integration with an entire BIMserver, so you can run it on Jenkins, any CI server, or as a hook called by Git, a Makefile, etc - it makes it very, very flexible.
  2. It outputs CSV, which makes it a bit more “open” for data parsing.
  3. It outputs a log which outputs exactly where data is missing in your IFC file.

In the future, I expect it to allow adding custom columns, check project specific requirements, and integrate with other tools like BIMTester, which can do human-language style IFC auditing, which can make it quite powerful, I believe. I also plan to integrate it into BlenderBIM to allow people to, within the BlenderBIM authoring tool, graphically query results, and fix the IFC data.

Edit: I think when packaged for Windows, it expects an IFC 2X3 file (although it actually can run on IFC4 too). This is something I need to resolve for Windows.