The current BIM software market offers us many opportunities for choice as to which tool we are going to use. Each of the programs is different and provides a variety of features to the user. The choice of the tool itself is frequently determined by the place where the person works, what they do, and to what extent they are familiar with the particular tool.
The majority of the popular programs save the results in their formats (so-called native formats). Long story short, if we save the project in Revit, we receive a .rvt file, and if we do it in ArchiCad we get .pln. It’s pretty simple, isn’t it? Apparently yes, but still there is a problem.
What if many industries are working on the project, and each of them uses another software and different native formats? How do the industries cooperate while exchanging models? How do they choose which file format is the leading information carrier and which is not? How do they make models from one program communicate with models from another?
We have only one answer to these and many other similar questions. The open IFC file format. Let’s start from the beginning.
1. IAI & buildingSMART, that is a little bit of history
In 1994, Autodesk established the International Alliance for Interoperability (IAI), an association of 12 companies. The association aimed to create a set of definitions of object classes as a neutral product. Since 2005, the association has been operating under the name of buildingSMART (https://www.buildingsmart.org/).
The organization is constantly improving the data exchange between applications employed in the construction industry. They develop standards, norms, and tools supporting the flow of information among different platforms. The main values of the organization are openness, neutrality, not-for-profit as well as internationalization.
The membership in buildingSMART is open to companies, governmental organizations as well as institutions from all over the world at various levels of membership.
It is worth knowing the structure of the buildingSMART organization, whose individual „Chapters”, i.e. national member organizations, develop and promote the application of open standards in their countries. BuildingSMART develops, standardizes and provides specific solutions (the so-called open formats) for the exchange of data in the openBIM process: BCF(BIM Collaboration Format), bsDD (buildingSMART Data Dictionary) and the abovementioned IFC (Industry Foundation Classes).
openBIM is a universal approach to the design, construction, and operation of buildings based on open standards. The openBIM methodology supports transparent, open cooperation of all project participants regardless of the implemented software.
IFC, in turn, is regarded as the basic standard for data exchange in openBIM. That is why IFC is so important in BIM since openness and interoperability are the key to success.
IFC or Industry Foundation Classes is a global standard for describing, sharing and exchanging information on building and facility management.
It is a non-proprietary, neutral data format. IFC provides a set of definitions for all types of object elements encountered in the construction industry and a text structure to store such definitions in a data file.
The IFC schema is constantly evolving. The current version, released in 2013, is IFC 4 (the prior releases were labelled as 1.0, 1.5, 1.51 and then 2x, 2×2, 2×3).
The IFC 5 version is still in preparation with further parametric capabilities and the activation of the infrastructure domain.
BuildingSMART International has defined a certification process to guarantee that the correct processes for importing and exporting IFC data are followed, ensuring compliance with the standards. All IFC certified programs are capable of reading, writing and exchanging information with other software solutions according to data provided by buildingSMART. IFC files may be exported and exchanged between software products using .ifc, .ifcXML and .ifcZIP file formats.
Differences between individual types of IFC model exports.
This is the default exchange format represented by a plain ASCII text file (only text, without formatting). The scheme defines how the text of the file is transformed into objects connected by mutual relations.
IFC data file is using XML document structure instead of ASCII like it was in the standard .ifc file
The .ifcXML file is usually 300-400% larger than the .ifc file.
It is a standardized .ifc or .ifcXML compression format (using appropriate compression algorithms). This is possible because both .ifc and .ifcXML are saved as text files.
.IfcZIP files usually compress the .ifc file by 60-80% and the .ifcXML file by 90-95%.
The graphics below show the differences in the IFC structure exported as plain .ifc and .ifcXML
4. IFC & BIM
The IFC in the general workflow can be compared to PDF. Where does this comparison come from? To illustrate it more clearly, I will take the example given by Mark Baldwin (Australian BIM specialist and architect).
Let’s imagine that we make a drawing, for instance in AutoCAD. When the drawing is finished, we want to share it with other participants in the process. Typically, we provide a PDF version. For several reasons. First of all, by sharing a native file, anyone can modify it, edit it without our knowledge or consent. Secondly, not everyone can open a .dwg file due to a lack of appropriate software. PDF, in turn, may be opened by anyone, as it is an open file standard and can be opened by a simple browser, while retaining a fair amount of features, such as searching for text, adding comments, etc.
The same applies to the model. Instead of sharing a native 3D model, which apart from compatibility issues (the recipient would have to own the same software, often in the same version), there are also intellectual property issues in the form of their own families, objects, components that we would have to share. In this instance, the IFC is a BIM’s PDF.
The available model retains geometry and additional information such as elemental features, parametric dependencies, quantity. As a result of this additional information, the model can be applied throughout the entire life cycle of the building, from data exchange between different disciplines (architecture, structures, HVAC) to the building use phase, i.e. Facility Management.
5. The best way to use IFC
What is the best workflow during the application of the IFC files? It is quite often said that you can start creating a 3D model in one software, export IFC to another program, and continue working on that model. Some programs have the ability to convert IFC to their native objects (Tekla Structures), however, it is not the best solution. In a general process, you should treat the IFC as a reference or performing another scope of work on the project.
As an example, we could imagine an architect working in their native software to create an architectural model of a building. Then the model is exported to the IFC and passed it on to HVAC designers and used there as a reference to run the ducts. If there is a problem or a change is required (e.g. moving a wall or making a hole in a duct), they do not alter the IFC model themselves but send a request to the architect with the specified changes. This one makes the necessary modifications and exports the updated IFC model.
Using the IFC itself is not a guarantee of interoperability. While it is of course designed to facilitate data sharing, there is a dependency on software vendors supporting and working properly with the format. On the buildingSMART website, you will find a list of all organization-certified programs supported by the IFC: https://www.buildingsmart.org/compliance/software-certification/certified-software/
In 2013 IFC was registered by the International Organisation for Standardization as ISO 16739 ‘Industry Foundation Classes (IFC) for data sharing in the construction and facility management industries’ https://www.iso.org/standard/51622.html
Moreover, in Norway, the IFC is the official (next to PDF) format applied for archiving.