Table of Contents
Short history of IFC2x3 and IFC4
IFC2x3
IFC is not a new concept. We have already written about the general history of IFC format. If you havn’t read it yet, I ecourage you to do so here. The most popular format used by the industry today – IFC2x3 – came to our world in 2006. It was “shaped ready” in 2007 after one patch (Technical Corrigendum 1). Surprisingly, IFC2x3 was mainly quality improvements to previous version IFC2x2 from 2003. Hence x3 in the name – according to the buildingSMART terminology it means “minor version”. The core concept were created in IFC2.0 released back in 1999!
IFC2x3 was the first release that we can call as official standard – it was included in PAS 16739 (stands for Publicly Available Specification, kind of temporary standard. Further read here.
Main challenges with IFC2x3 format
The format became widespread in the construction branch with the majority of software certified in 2013 and 2014 (6-7 years after the release!). This covers also the time where BIM became spread commercially within the AEC industry.
During the course of the years, multiple projects encountered obstacles connected to faulty IFC 2×3 interoperability. Oftentimes it’s hard to find who to blame: BIM authoring tool for export, IFC viewer for faulty import or IFC for errors in the schema? Eventhough most of the software are IFC 2×3 certified, errors occur. They take place somewhere in translation between how one software defines an element while exporting it to IFC and how the other software understands an IFC element and translates it to it view. And sometimes it is the IFC 2×3 shortcomings.
Those translation errors are especially annoying for geometry issues. Some common errors:
- Thin slabs/coverings has problems with viewing openings (for example floor that is modelled as separate object)
- Cut-outs for doors have to have wall on both sides, even though there is another object between two separate doors and wall should be cut-out.
There are also many issues related strictly to IFC scheme:
- Does not support parametric geometry.
- Curves and rounded objects are modeled as polygons which slows down the model (no support for b-splines).
- Lack of infrastructural domain (though they deal with the topic pretty smoothly).
- Too little schemas and property sets for distribution systems. Although they all have their entities and many classes, the domain of building services has many shortomings.
IFC4
After the release of IFC2x3, BuildingSMART begun to work on the new version of the format – IFC2x4, or as we know it today – IFC4. As the original name suggests, IFC4 is not a completely new schema – it is rather quality improvement and extension of the existing IFC2x3 format. At some point, the scope of changes made to the schema were broad enough to risk compatibility break. That’s why it became major release and named IFC4 instead of IFC2x4. Anyways, IFC4 came to the world in 2013 and immediately made it’s way to ISO 16739:2013 standard.
So as you see, IFC4 is the enhencement of IFC2x3. Although builndingSMART doesn’t guarantee backward compatibility, I doubt we will face major problems, such as impossibility to even open the IFC2x3 file in software certified for IFC4. For the reasons that:
Schemas structure are similar (IFC4 is extension of some domains for IFC2x3)
So far, there is no software create solely to view IFC4 (and I doubt there comes any within next 5 or more years)
You don’t buy a yearly license to use IFC schema
You cannot say this about proprietary formats eventhough their new releases are also mainly corrections and enhancements of three or more decades old code 🙂
The official version is IFC4.0 (with even weirder name that I think makes sense only for IT people: IFC4 ADD2 TC1). So far, we had 2 minor releases focusing on infrastructural domain. Version 4.3 is under development, so who knows, maybe soon we are going to jump from IFC2x3 directly to IFC4x3 (or rather IFC4.3 which means the same)?
You can check all versions and their status here.
What improvements brings IFC4?
Overall IFC4 was meant to enhance consistency through the whole schema, reduce and optimize a file after populating model with datasets. One of the goals was to enable for more consistent results of IFC exports and enabling for round tripping of IFC models (export from one software and import to another for further development).
Some imporvements in the schema:
- Correction of technical problems known from IFC2x3.
- Building Elements subtypes allows now for a parametric exchange of their shape, material and element type.
- Standardized base quantity added to the IFC specification. No more multiple property sets with quantities depending on which software do they come from?
- Support for energy calculations and advanced simulations.
- Defined in the ISO 16739-1:2018 standard.
- Linking IFC property definition to the buildingSMART Data Dictionary thus allowing for using national languages and classifications.
- Added support for b-spline surfaces and curves. Welcome rounded geometry and bye-bye polygon-shaped curves! That should dramatically increase the performance of models containing a significant amount of curves.
- Enhanced work with 4D by simplifying the definition of task times, work calendars and schedules.
- Attaching cost values to items, not a relationship. This speeds up models that use 5D datasets.
- Enhanced BIM to GIS interoperability.
- Introduction of a distribution system entity, improvement in semantics and support for new elements for better capturing building services domain.
- Improving the readability of technical documentation to ease the implementation process.
- Enabling the extension of IFC to infrastructure: bridge, railways, roads and other domains (development team works on extensions themselves for the newest 4.3 release).
- Version 4.3 deprecate entity IfcBuildingElementProxy. I translate it that buildingSMART got pretty sure they covered all elements in available IFC classes. Which is very good.
As you see, changes are significant and embrace the whole spectrum of BIM usecases and workflow. Exciting!
Software certification in IFC2x3 and IFC4
Software achieve their buildingSMART certification basing on how well they handle export or import of their proprietary model into IFC format defined by Model View Definition. What is MVD you should know from this entry. In short, if the software is certified, it means that it handled the tasks completing majority of the test scenarios. It doesn’t necessary means, that it transfers proprietary model to IFC (or vice versa) without any loses/minor disturbances.
IFC2x3 begun with one official MVD used for multidisciplinary collaboration (out of four in total) called “Coordination View”. During those years, there have been created numerous of unofficial MVD “add-ins”. You can check the full list here.
The original goal of Coordination View MVD was to support (as the name suggests) coordination between different disciplines. But during those years, the model definition has been extended to better support the purpose of design transfer of IFC file between software. There were so many additions, that in the end bSI decided for a new release – Coordination View 2.0 that we use todays as a standard export definition.
On one hand that is good – 90% of exports uses only this MVD so designers don’t have to bother which to choose. But on the other – if something is for everything, is for nothing. None software was able to complete BuildingSMART certification 100% correctly, so bSI begun to give green, yellow and red checkmarks to which task the software is compliant with. Software doesn’t have to have all greens to become certified. And that created even more mess.
Therefore, the official MVD for IFC4 had a goal to completely split the two purposes: for coordination and for design transfer. For the first purpose, BuildingSMART created Reference View MVD and for the latter – Design Transfer. The certification now is more strict – software can pass only if it is fully compliant with the MVD. No exceptions allowed. Moreover, only after certifying for Reference View, vendor can apply to certify for Design Transfer.
That leads to a homogenous IFC export results across different software, hence unequivocal import of IFC file to a viewing/checking software thus, in the end, to better IFC models quality. Unfortunately, it also makes much harder to obtain the certificate by a software vendor.
Summary
Bibliography
https://standards.buildingsmart.org/IFC/DEV/IFC4_2/FINAL/HTML/annex/annex-f/ifc2x3-to-ifc4/index.htm
http://docs.buildingsmartalliance.org/IFC4x2_Bridge/link/annex-f.htm
https://technical.buildingsmart.org/
https://technical.buildingsmart.org/standards/ifc/ifc-schema-specifications/ifc-release-notes/
https://www.b-cert.org
Always interesting to read your articles! Have to conclude though, that even after all these years I still consider IFC as a 3D Export format rather than the two-way communication format many of us have been hoping for.. A 3D pdf on steroids.. Nevertheless, quite useful for coordination, but not so much for archiving..
Hey! Thanks a lot for your kind words 🙂
IFC is for now no-go for two-way communication (due to no available Design Transfer MVD). Though I reckon IFC is a very good standard for both coordination and archiving. On many projects where I was involved, Building Owner requires models in IFC. It is possible to open them years after completion of the project. Contrary to proprietary formats. Why do you think it is not that good for archiving?
Unfortunately, some of authoring software even today not available for export and moreover – import (!!!) in ifc4. Bentley, example.
So if i work in revit, i need to export to ifc 2*3 format to make it available for reading in software like Bentley…. It’s really problem
Thanks for article
Hey! Unfortunately, we would need to wait a few more years for IFC4 to get more popular. Thankfully, IFC 2×3 is functioning pretty well anyway 🙂