IFC 4 is the current version of the buildingSMART data model (The openBIM core specification). It is also the version of IFC that is an ISO standard, ISO 16739:2013. IFC4 has been out for three years now. Getting to the first IFC4 release took six years of development and in the time since it has been improved with two addendums and new Model View Definitions. However, the community uptake has been minimal so far.
In this post we look at reasons for using IFC4, whether the new version is really ready and look at ways to bridge the adoption gap. We will compare it to the version that everyone is currently using - IFC 2X3 - and give examples on how the new standard will benefit common BIM workflows.
We will also share the result of our testing using IFC4 to exchange data between common BIM tools. We hope to help visualize the current state of support and identify improvements needed for the future. We want IFC to evolve. To do so there needs to be more testing, experimenting, understanding and supplier pressure. It all starts with knowledge of where we are, where we are heading and a plan to tackle the obstacles along the way.
Why you should use IFC4
IFC 4 have fixed a lot of the complaints and limitations of previous versions. It also serves as the foundation for future development and research around openBIM. It is therefore important that the community picks it up and starts adopting it. If not openBIM will get stuck with IFC2x3 and stagnate.
Have a look at the figure below. What happens if the evolution does not continue? IFC will be stuck as a toddler and native formats will regain control, as there are no real alternative open schema yet.
The main critique for using IFC as a BIM exchange format has been the data loss when moving data from one authoring tool to another. For IFC4 full BIM round tripping is still not supported. However there has been big improvements in making IFC better at supporting parametric design and design transfer from one application to another. Full round tripping will probably never be the available as leading native formats always will have features that interoperability layers have not caught up with yet.
Geometry improvements aside, it is the completeness and granularity of the “data” part of the schema that gets us most excited. As BIM expands outside its design collaboration origins there is a need to complement for new processes, new disciplines and new phases for BIM to become a true lifecycle solution. IFC4 is a step in that direction and the progression needs to continue.
Before diving into the details let us have a walk through of some of the main improvements and see how it addresses issues identified in the community
What has improved - IFC4 vs IFC 2X3
The list of changes and improvements are too long to list here. Main change have been fixing problems with the previous standard, complementing both core and domain specific schemas and improving documentation and tool support. Here we will focus on the core changes. Please refer to the change log for further details.
Geometric improvements
One of the main complaints from designers when evaluating IFC is the loss of intelligence and the lack of parametric support. IFC has been seen as an OK way to export and federate discipline models for visualisation and clash detection, but not as a way to move the design from one application to another. IFC has also been seen as a rather inefficient format for transferring and representing 3d geometry. IFC4 has made several changes and updates to address those requests.
Examples of geometric improvements are more parametric support by supporting NURBS and more efficient handling of meshes by supporting tesselated geometry.
Some improvements have also been made to how to add textures, lighting settings etc, to make real-time visualizations more efficient and higher quality, aligning with other web standards for 3D graphics and gaming engines.
Data improvements
There have been multiple improvements to make the IFC data model both more complete and more granular. The original IFC schema originated out of Autodesk and was more evolved in the design phase and architecture domain than in other phases and disciplines. Initial use cases have been design visualization and clash detection. As BIM is expanding into other domains, e.g. building services and structural analysis and new BIM workflows emerge (e.g 4D scheduling and 5D estimating) needs for extensions and corrections to the data model has been identified.
Practical use also show that the use of property sets have been too unstructured. Usually BIM tools and/ or designers use their own property sets instead of using the ones supplied in the standard and therefore breaking interoperability with the data consumers downstream by making the export non-standard. BIM tools downstream needs to know where to find the data to be able to automate processes (e.g. using expected lifetime and replacement cost to model lifetime cost and long term budgeting).
In the domains mentioned there have been both new classes added and changes made to existing classes. E.g. in the building services domain many of the generic element classes (eg IfcFlowController has become abstract classes and been subtyped into more specific domain elements (e.g. IfcAitTerminalBox, IfcDamper, IfcElectricDistributionBoard and IfcValve etc). Also IfcSystems have been subtyped into different subsystem classes, e.g building systems and distribution systems. The subsystems are given new enumeration values to classify them. E.g distribution systems are classified as air conditioning, fire protection, security, heating, lighting etc etc. All in all these changes may for many users reduce or eliminate the need for classification systems for FM use as the combination of the classes and the enumerations should be sufficient in describing both the system and type/element functionality.
The number of property sets have increased from 317 to 506 (413 property + 93 quantity sets). In addition to adding to the number of sets there have also bee a effort to further map relevant property sets to the specific types and classes. Lets use an air flow regulator (IfcAirTerminalBox) as an example. IFC2x3 will only list one property set with 15 properties, but ifc4 will list with a total of 11 property-sets with a total of 87 properties. Hopefully this should limit the use of custom property sets to ease interoperability. For specific needs in the project custom properties may still be needed but for handover requirements you should really check to see if your required information fits into the 1694 supplied properties.
All property sets are now also connected to the buildingSMART data dictionary (bsDD). This way the integration with product libraries and manufacturer databases could be simpler going forward. As the bsDD is expanded all properties in the IFC4 data model can be translated into different languages. Currently the supported languages seems to be English, French and Japanese (and some German).
New and changed Model View Definitions
Model View Definitions (MVDs) are the subsets (smart filters) of the IFC schema that defines what parts of the data model should be included in an information exchange (and what to leave out). IFC 2X3 have two different version of the coordination view which is the main MVD in practical use. To augment these there is also some add on views (e.g. space boundary and 2d annotation) and also some alternative views (structural analysis and basic FM handover).
For IFC4 the coordination view has been replaced by two official MVDs releases aligning with the two core use cases of model exchange.
The IFC4 reference view is made to export the subset of the model needed for downstream use to federate and reference models. This MVD is quite geometric centric but the geometry need not be parametric. Designers will provide their model exports for downstream use in processes like clash detection, visualization, quantity takeoff and virtual inspections. If the downstream users identify issues they are expected to report them as BCF issues or similar and not make edits themselves. The issues will be transferred back to the original author that then will do the edits and publish a new model version.
The IFC4 Design Transfer View (DTV) is more ambitious. Here the recipient are supposed to be able to modify elements and spaces in the received model. Instead of just transferring geometric meshes the exported geometry must then be expressed as parameters that the downstream users can manipulate. The focus of the IFC4 DTV is on editing interconnected elements. Typical use cases are when the architect create the original layout and geometry of the building, but then the structural or building services engineers need to make modifications to the design by editing elements originating from the architect. This model view will also be relevant for hand over from the project to the owner at completion as the owner or the facility manager may need to modify the model due to changes made during modifications or major works.
The IFC4 reference view is defined to suit most of the common BIM coordination tasks in practical use today. IFC2X3 is capable of doing this but the IFC4 version is better specified and more filtered. Reference view exports/imports are expected to happen continuously to coordinate and federate models according to the BIM collaboration workflow.
The use cases of the Design transfer View on the other hand are made possible with the changes and improvements made to IFC4 and is an answer to the “we lose data and intelligence” complaints of IFC 2X3. Design transfer workflows are expected to be more one-off exercises. You transfer the model and now it lives elsewhere. In practice we expect to see many “grey area” use cases in between these two main ones, and also specialised workflows where very specific subsets of IFC are required. Owners and project teams need then to decide if one of the common MVDs will fill their needs or if custom MVD definitions are required (see tooling below).
Tools and Usability improvements
With the IFC4 schema release there also come updated tooling and documentation support.
The documentation for IFC4 is much more user friendly and comprehensive than the IFC2X3 one. It is easier to navigate and follow links and also more information is included on each of the classes. As IFC4 is almost a superset of IFC 2X3 we tend to use the IFC4 documentation also when working with the older format, and then peek back in the old documentation to verify if everything is the same (the IFC4 documentation will tell you on every class and property set whether there have been any changes for IFC4). The documentation also incorporates the ifcXML format in addition to the traditional EXPRESS specification
Related to the IFC4 release there is also a tool supplied to generate custom MVDs and validation schemas. We have not seen this much in use yet but are planning to test and share our experiences in a later post
Testing IFC4 - what we found
The main challenge of testing IFC4 is the lack of IFC4 sample files that are really utilising the capabilities of the “new” standard on a large scale. What we were able to test was
- Small sample files included in the IFC4 documentation showcasing specific new features. Those are mainly geometry focused and do not contain much data or structure other than what you need to contain the geometry.
- IFC 4 files generated by exporting models from common BIM tools, either from projects already using IFC4 or from our own test exports where we had access to the native files (we have tested exports from Revit, Archicad and MagiCAD).
We tested import of those files into Solibri Model Viewer v9.7.5. We also analysed the contents of the STEP files when issues arose
The results was a bit disappointing.
Importing the sample files into Solibri gave three different results
- Some files imported correctly with no signs of errors or data loss
- Some files imported without errors reported but some geometry was missing
- Some files imported without errors but elements in the IFC structure was missing and as a consequence no geometry was shown.
The sample files were quite evenly distributed in these three categories
Importing files from BIM tool exports also varied a bit
- Some files did get better geometry. E.g. pipes and bends seem to have smooth geometry instead of triangle meshes.
- Other files did have geometric errors. More complex geometry like pipe bends got distorted.
- Some files just crashed the import
The data in these files are “valid” according to the IFC4 spec but there is not much added value. They do use the new classes from the building services domain, e.g. (IfcAlarm and IfcAirTerminalBox instead of all being IfcFlowControllers). However in IFC3x2 you could get that data from the “type reference” anyway, so not that much value added. On the properties side the properties for IFC2x3 and IFC4 looks almost identical. Sometimes a new property set was added to the IFC4 export, but the content of the property set was usually just empty values.
This all confirms our suspicion. Currently IFC4 support in design tools can be described as a “compatibility mode”. BIM tools are mostly able to generate valid IFC4 exports. However the changes are mostly limited to mapping changed and deprecated items over to the new schema. New additions to the schema and new property sets are not used.
To be fair. It needs to be pointed out that using these new features in most cases requires custom mapping and that is probably something you should do anyways. If you want IFC4 you have to specify it more properly, at least specify that properties should follow the IFC4 property set definitions when available. Hopefully that will force the vendors of BIM design tools to harmonise their properties with IFC standard properties for export. This again will let providers of downstream BIM tools add more intelligence to their applications without requiring manual and costly data transformation projects.
So then- is IFC4 ready?
To summarize what we have learned so far we will try to answer some common questions in a quick and simple way.
Is there a need for IFC4?
Yes. There are many limitations of IFC2x3 that have been fixed in IFC4. Also there needs to be new versions of IFC in the future and IFC4 still seems like a better foundation for new initiatives like support for road, rail, airport, asset management etc.
Is IFC4 finished?
The standard is published as a ready to use standard and it get improvements (addendums) along the way that are backwards compatible (with other IFC4 versions). Due to the lack of adoption there it hard to tell if it is complete and finished or not. There is however no need for waiting for an upcoming version. You may want to wait for general adoption or better implementation in BIM tools though.
Is it approved as a standard?
Yes. It is approved as the current buildingSMART International standard. It is also the one that is ISO certified. (IFC2x3 never was).
Is it supported by tools?
BIM tools are generally supporting IFC 4 now. However that is mostly in compatibility mode. If you design your model using the normal design workflow and just press “export to IFC” and choose version 4 you may get a valid IFC4 file but chances are big you will not be utilising the full feature set of IFC4.
Similarly files created using this compatibility mode are starting to be openable in BIM viewers and downstream applications. However when you use some of the newer features there is a bigger risk of failure.
More than half of the files we tried to import into the the current version of Solibri Model Viewer failed to display correctly, either by missing geometry or by crashing the viewer.
Is there a way to require it?
You should never just require IFC. As a minimum you should require a model view definition. Currently there are either Reference View (for design collaboration) or Design Transfer View (for moving models across applications). There are tools to generate custom requirements but they have seen little uptake yet. In addition to defining the format, version and MVD you need to specify your information needs, either as “plain language questions”/ embedded into the specification or as reference to the IFC standard (what classes and properties to use)
Is there a way to validate it?
A system for validating existing or custom MVDs are provided. Using them will be covered by a later article. It is possible but not easily accessible.
Some challenges in the current state of IFC4
The main challenge for IFC4 is community uptake. The main thing stopping community uptake is proper support in common BIM tools.
Even if most of the changes between IFC4 and IFC2X3 is additions there are also some changes and deprecations that break backwards compatibility. For tools vendors this is a major issue. Tools need to handle multiple versions of the schema and they need to transfer between them.
There are also challenges for projects. Until all project participants have tools that fully support the new version the project cannot start using the new version for coordination and collaboration.
There is also a challenge with the current way of defining a theoretical standard first and then hoping for community uptake. IFC2X3 to IFC4 migration is a big bang migration where not much of the changes have been tested in the community.
Market leading vendors have no real incentive to be forerunners in supporting interoperability standards. They only give in when the marked pressure/ demand for support is big enough for them to have to support it.
The way IFC4 breaks compatibility with IFC2X3 leave uncertainties in the “IFC as an archive format” debate. Unless the community or buildingSMART itselfs come up with a clear and standard upgrade path legitimate questions will be raised.
For some situations IFC4 have aimed to make the format simpler. However for other cases IFC has turned into a more complex format, especially for this period where you have to support both versions at the same time. Things should be made more simple and straightforward to drive adoption in the general market
The IFC4 certification process (for BIM tools) is also in a limbo. Certification based on IFC2X3 is stopped while certification for IFC4 is not yet ready. This make it harder for new entrants to get into the market. This is counterintuitive to the original idea of openBIM
There is a similar gap between current research and development in the industry. Most research and development under the buildingSMART umbrella is based on IFC4 and beyond. This is the same for research being done by grant-funded research. At the same time most of the development done by commercial tool vendors are done around IFC2X3 as that is the version in use and that is the test data you can verify your system against. Similarly all the practical use, learnings and community adoption is done using the old standard. IFC will never get rid of some of the “complaints” if people are not exposed to the new stuff (and the new stuff are allowed to incrementally improve).
We will address some of these issues in later articles. For now just let us conclude that there is generally a need for the community to understand more about IFC developments and know what, how and when to require its use and how to put pressure on their vendors to define better support.
Moving ahead
Moving forward all starts with sharing good reasons for upgrading and sharing success stories from successful upgrades. If you have such stories please share in the comments section below. Also if your view differs on any of the statements or findings also please share so we and other readers can getter a better understanding of how the community understands and thinks about this important topic.
As promised we will continue to explore this and similar topics related to openBIM adoption and progress. If you are interested in following our journey, please sign up to our newsletter
