What is it good for?
Absolutely nothing, say it, say it, say it
Oh IFC, is an enemy to all mankind
The thought of IFC blows my mind
IFC has caused unrest within the AEC community
Frustration, then dissatisfaction, who wants to fail?"
with apologies to EDWIN STARR
Looking through blog posts and discussion groups there seems to be a lot of dissatisfaction with IFC. Some samples:
"It can (if done properly) be used for a static as-built record Information, but even when used for this purpose validation of the data is critical."
"Data Loss IFC has a horrible habit of losing information or dropping data when exporting from its native format."
" IFC is that it doesn't currently support all the clever time saving parametric stuff that we expect from BIM components these days. IFC is all about the geometry and data and upon export it normally dumbs it down to just that."
" The biggest barrier in my opinion is that no matter how good IFC becomes, it will never be as good or have the functionality as the native BIM package it was created in. "
"It annoys me when I see new BIM users (most of the time without software experience) shouting about how we must all adopt IFC & openBIM now-today, because on the outside it looks like a perfect solution, when in fact its actually a load of work arounds."
So what is going on? We keep getting lectured by BIM evanglists about how wonderful IFC is. These same evanglists are busily lobbying governments and large corporations to mandate IFC deliverables. There seems to be a lot of claims about what IFC can do, but little on what it can't do. I don't put myself forward as an expert on IFC and welcome comments that prove me wrong, but I thought I would share my investigation into IFC.
WHAT IS IFC
I won't go into a lot of detail of what IFC is, but paraphrased from wikipedia:"IFC is an object-based file format with a data model developed by buildingSMART to facilitate interoperability in the architecture, engineering and construction (AEC) industry, and is a commonly used format for BIM. The IFC model specification is open source and is an official International Standard ISO 16739:2013.
For more information look at the buildingSMART web site, and as an example of their view of what Revit users need to know.
PROBLEMS WITH IFC
EXCHANGE FORMAT DOES NOT EQUAL OPEN FORMAT
One of the things many people don't seem to appreciate is that IFC (and by extension COBie) is an exchange format. It is not a common format, like open source formats (DOCX, JPEG, XVID, etc.), or common proprietary formats (DWG, PDF etc.)IFC is designed to be a format that only exchanges data between other formats. When you import IFC into a software it gets converted into that software's format.
Software that can open IFC files directly are IFC viewers, they can't actually edit the IFC file.
It is a good idea, an agnostic data format.
But what it means is that there are two points of possible error creation - when the IFC is exported, and when it is imported.
With common formats there is only one - at import when using the software's format, or at export when using different software.
So although an exchange format like IFC may be theoretically more efficient across an industry, in practical terms for individuals it is not. To get a specific result it is easier (and quicker) to write one set of code in one software than to write two sets of code in two separate softwares.
FUNCTIONALITY
IFC doesn't seem to capture all the functionality of BIM authoring softwares. For example it contains size dimensions, but doesn't know which geometric entities these dimensions control. So it can't transfer working parametric objects.Effectively an IFC import creates static objects, no longer editable.
This behaviour perpetuates problems that BIM is supposed to overcome. If size parameters are exchanged and are editable, but the geometry doesn't change with those edits, there is potential for situations where the scheduled size of equipment doesn't match its geometric size. Which makes spatial planning and clash detection unreliable.
BUILDINGS ONLY, NOT COMPONENTS
Although you can create an IFC file of a building that contains components, you can't create an IFC file of only one component. The file is effectively a building with one component in it.I find this surprising. You would think an open format for distributing components would be high on the priority list.
There are a number of initiatives to create BIM component standards, like the UK NBS National BIM Library. But they have had to include Revit files due to the lack of functionality of IFC files.
That said, it should be entirely possible for a component IFC file schema to be created, and I believe buildingSMART is looking at this. See this presentation.
But currently IFC is not a suitable format for components.
ARCHIVAL QUALITY
IFC is pushed as an archival format. The argument being that the constant upgrades to proprietary software formats means any files retained now will be unreadable in the future. Whilst IFC, being a published standard, will always be readable.But as explained above IFC is not a software format. It is an exchange format that requires other softwares to create and read it. Therefore it relies on proprietary softwares to maintain the ability to read older IFC formats. Which seems to me no different from relying on those proprietary softwares to maintain the ability to read their own formats. One could argue it is more likely they will do this for their own format than for an external format they derive no income from.
There is a mitigating factor though, the fact that IFC rarely gets updated means proprietary softwares don't have very many versions of IFC converters to maintain.
But the fact remains the problems of archival storage of digital data are NOT solved by using IFC.
AS-BUILT and FUTURE WORKS
IFC is pretty much useless for As-Built BIM that will be used as a resource for future changes to a building. As an exchange format IFC can't be directly edited. And most data that handles the original authoring software functionality has been lost in the exchange. So at best IFC can only be used as a static background in an authoring software with editing capability restricted to deleting parts.Even if you import this static model there is the problem of loss of fidelity when an IFC file is imported into an authoring software. Without painstakingly checking every element it is not known whether everything from the IFC model has been replicated.
Then once the changes have been made in the authoring software, the export back to IFC is also problematic. If only part of the building has been changed how do you integrate that into the original IFC model? If the whole building is exported back replacing the original IFC model how do you deal with the time lag that means differences in data content, or the problems that arise if the IFC model is linked to a third party database.
COMPLEXITY
I have looked through the IFC and COBie descriptions, and I'm sure if I tried really hard I could understand it. But I don't want to try, I've got more important things to learn that are actually relevant to my area of expertise. I'm an architect, not a computer programmer. I'm sure most people in the AEC industry feel the same way.Just look at what IFC stands for - Industry Foundation Classes. What does that even mean? (when I talk about IFC to a project team they ALWAYS get confused and think IFC is "Issued for Construction").
Does this really matter? IFC is a software standard, not a human process standard. In theory us users should be shielded from the inner workings of IFC by the software we use. But the reality is we end up having to delve into IFC because the softwares don't provide what is required for us to do our work. We are also getting owners with specific IFC deliverables, that describe these deliverables in IFC terms.
DOES IFC ACTUALLY WORK IN THE REAL WORLD
This issue is one I can't answer because I am not a computer programmer. All I can go on is what I read in discussions and blogs by people who know a lot more than I do. And I have to say what I have read is concerning, some of the issues seeming to be rather fundamental.It seems some that have tried to use IFC are, if not exactly giving up, accepting IFC limitations.
Jon Mirtschin at GeometryGym has been using IFC as an exchange method to transfer data generated in Rhino by Grasshopper to BIM authoring softwares. I saw him speak at an IFC 4 launch, and what he does is amazing, and he is a strong IFC supporter. But he admitted he was having problems with IFC and has started to write code to import directly into Revit to overcome them. It seems you can only go so far with IFC.
On another front Bentley have announced they are developing an "RFA interpreter" that can import rfa files (Revit's component file format) into their BIM product.
But even given IFC's problems, and despite my scepticism, IFC is actually being used around the world.
WHAT IS IFC USEFUL FOR?
Lets not throw out the baby with the bathwater. Underneath the practical limitations there is a fundamentally good idea. The fact is it is not, and never will be, the panacea it is claimed to be. But IFC must be useful for something.ANALYSIS
Generally a BIM model used for analysis purposes doesn't require the whole model. Structural analysis only requires the structural components, thermal analysis only requires spaces, zones and envelope data. Some analysis software only requires parts of a building, or does the analysis one part at a time (e.g. floor by floor). Because IFC is an open format receivers of IFC files can break up them up without requiring the authoring software. Their analysis software may do it, or it can be done manually with third party software like simpleBIM at datacubist.com.As IFC is usually simpler than the format of the authoring software so analysis softwares require less code to get the information they require, and it is easier for them to manipulate that data before importing it. This issue is becoming more important as cloud computing is taken up for analysis.
If all an analysis software does is the analysis then a static model like IFC is sufficient, but if you want to modify the model based on the results of the analysis IFC won't work for you.
So if you want to provide your model to some-one else for them to do an analysis IFC is a good idea, but if you want to do an analysis yourself that will result in changes to your model your authoring software is better.
FACILITIES MANAGEMENT
A Facilities Management system does not need the ability to easily modify a building's geometry. The geometry is mainly there as a navigation tool for the data the system holds. In fact you don't want people to accidentally move fixed elements around (which can happen in authoring softwares).You also don't want an unnecessarily complex file format that can do more than you need.
So using IFC for FM makes sense. It is a simple format that has its geometry locked down. It also makes sense, in theory, for FM software houses to utilise IFC as they can then import data from multiple sources. I say in theory because they then become victim to the quality of IFC those sources create.
Of course if you need to make changes to the building's geometry, like add a door or change a wall, you will need to do that with a different software and try and integrate that change back into your IFC model. I'm not aware of a way to do this, but I suggest you make sure you have a robust, tested, process before committing to a reliance on IFC for FM.
COORDINATION
Current specialized clash detection software work by importing static models. They don't attempt, or have the capability to, alter imported geometry. Therefore IFC is a prime candidate for these types of software.The ideal situation would be to have the ability to alter model geometry to over come clashes whilst doing the clash detection. But currently authoring softwares are not good enough at clash detection to make this practical. And then there is the issue of who makes the changes. Should the BIM Manager, who is not a structural engineer, have the ability to make changes to the structural model?
So at present, until authoring software improves and the responsibility problems are resolved, IFC is fine for clash detection and coordination.
WHAT IS IFC NOT USEFUL FOR
AS-BUILT FOR FUTURE WORK
IFC is not an authoring software format and in its current form is too limited to be really useful for making changes to an existing building.However the pain associated with dealing with IFC could be alleviated by careful construction of the IFC model. For example by breaking it down into linked sub-models. If it is contemplated that IFC be used for As-built, as a minimum the process for updating building geometry should be established before hand-over to FM.
EXCHANGES BETWEEN AUTHORING SOFTWARES
IFC's inability the keep the data authoring softwares rely on to make them useful means IFC is a bad choice for model exchange. If all you require is a static background IFC may be usable, but only if you are confident all objects survive the double transfer - firstly from the originating software and secondly into the receiving software.The other problem is even if you get the IFC into your authoring software the control you have over it (visibility, display, data content) may be limited.
COMPONENTS
IFC simply doesn't have the ability to contain the parametric properties we expect from BIM components. Maybe one day it will, but for now don't waste your time.SHOULD IFC BE SUPPORTED?
When ever I bring up the shortcomings of IFC in public I get berated for not getting involved. It is open source, they say, anyone can contribute they say. But I'm an architect, I don't have the expertise to solve any of these problems. My contribution is limited to bringing up the short-comings of IFC. And I don't see how bringing up these issues in a closed forum could possibly be more effective than doing it publicly.But should we practitioners support IFC? I believe we should. It is fundamentally a good idea.
Certainly volunteer to buildingSMART if you think you can contribute directly.
But if you want to contribute some of your time for free, my view is the most effective thing you can do is give IFC a try. Test it out, experiment with it.
And share you experiences. If things don't work bitch and complain, if they do heap praise on it.
IFC RESOURCES
IFC DISCUSSIONLinkedin:
http://www.linkedin.com/groups/Industry-Foundation-Classes-IFC-3690870
IFC VIEWERS
Solbri:
viewer: http://www.solibri.com.au/other-products/solibri-model-viewer
optimizer: http://www.solibri.com.au/other-products/solibri-ifc-optimizer
Tekla:
http://www.teklabimsight.com/downloads.jsp
List of IFC software:
http://www.ifcwiki.org/index.php/Free_Software
IFC / REVIT
Open source Revit to IFC Exporter:
http://sourceforge.net/projects/ifcexporter/files/
IFC to Revit importers (both are optimized for services and/or structure):
GeometryGym: http://geometrygym.wikidot.com/downloads
ArchiCAD: http://www.graphisoft.com/downloads/interoperability.html
Tekla (optimized for structure):
http://www.tekla.com/international/solutions/building-construction/Pages/export-revit-tekla-structures.aspx
IFC SOFTWARE
Software like simpleBIM (http://datacubist.com) can clean up IFC files.
EXAMPLES OF IFC USE:
Geometry Gym:
http://geometrygym.blogspot.com.au
http://geometrygym.wikidot.com
NBS [UK] Revit Plug-in:
http://www.thenbs.com/products/nbsplugins/index.asp
Bored with BIM? Need a present for that special woman in your life? The Lost Woman series follows the adventures of Christina as she makes her way through a world of design, architecture and ... men. Book one of the series, "Awakening the lost woman", is available now on Amazon, Google Books, Kobo and iBooks. |