It has been over 15 years since I took an in-depth look at the IFC (Industry Foundation Classes) open standard (see the archived article, “The IFC Building Model: A Look Under the Hood”) and my reason for doing so at that time was that with the increasing interest in BIM (building information modeling) in the AEC community, “the issue of interoperability as a means to integrate the various model-based applications into a smooth and efficient workflow” had emerged to the forefront of professional attention. Here we are, all these years later, and the interoperability issue is still as critical as ever, if not more so. The number of applications for the AEC industry has exploded (see a full list at AECbytes VendorHub), and it is likely to continue to increase. We need all these applications to be able to work together in order for them to be able to do what they need to do — help AEC professionals design, construct, and operate buildings and infrastructure as quickly, efficiently, and cost-effectively as possible. And in order to work together, they need to be able to exchange the building data they are creating and using with each other freely using a common standard, which is what the IFC is.
At the time I wrote the article on the IFC — in 2004 — the industry organization that had developed it was still called International Alliance for Interoperability (IAI), and it had been in existence for 10 years prior to that. In 2005, in an attempt to make its name and what it did easier to understand, it was renamed buildingSMART (see the article “buildingSMART: Get Over it” by Mario Gutman, then firm-wide Director of HOK). Since then, buildingSMART has grown to a global organization with several regional chapters, and in addition to continuing to develop the IFC, it has developed several additional standards including BCF, MVD, IDM, and bsDD. What these various standards are and what they do is the subject of this AECbytes article.
The IFC is, of course, the earliest buildingSMART standard, and the one that jumpstarted the entire standards initiative for AEC technology interoperability. It is interesting to note that the IFC even pre-dated the term “building information modeling.” I wrote about this in my 2018 review of Solibri Model Checker, in which I described attending an "Interoperability" workshop all the way back in February 2001, where I saw a demonstration of how the IFC file format could be used to link various analysis tools to the building information contained in an object-oriented CAD model. Solibri Model Checker was one of the analysis tools that was demonstrated, and to date, it remains one of the key tools that showcases the power of the IFC.
While my 2004 article is still helpful in providing an in-depth look at the IFC, an excellent was more recently presented by Mark Baldwin in this BuildingSMART webinar: https://vimeo.com/348127214. To start with, the most fundamental aspect of the IFC is that it is an AEC-specific standard. To put it more accurately, it has, so far, been a building-specific standard (although that is about to change, as we shall see.) What this means is that it carries information about building elements, which is specifically of three kinds as shown in the graphic on the left in Figure 1: their geometry (e.g., the height and thickness of a wall); their properties (e.g., the U-value and material composition of the wall’s layers); and their relationships with each other (e.g., which floor the wall is on and what spaces are on either side of it).
Also noteworthy is the fact that the IFC is structured so that subsequent versions can build up on it by adding more elements, their properties, and their relationships. They do not affect what is already defined, as shown in the graphic on the right in Figure 1. This makes the IFC backward compatible, so that applications that support newer versions of the IFC also support older versions. The buildingSMART organization is currently working on expanding the IFC to include infrastructure elements, and further versions may expand to include FM elements and anything else that we might not foresee right now.
While the use of the IFC is well understand given its long history in the AEC technology industry, here is a quick recap:
The current official version of the IFC is IFC4; however, certification and implementation are typically behind by a couple of years, which means that most users are still using the last official version, IFC2x3, for which most applications have been certified. The certification of applications for IFC4 is starting to pick up, and its widespread implementation will soon follow. At the same time, buildingSMART’s IFC team is working on the next version, IFC5, which will extend it to include infrastructure elements, allowing applications like Autodesk Civil 3D, Allplan Engineering Civil, Bentley OpenRoads/OpenSite, etc., to use it for interoperability. There are also plans for IFC6 to extend it to operations and FM.
The BCF format has been specifically developed for coordinating multiple disciplinary design models which have been exported in IFC format to a coordination and clash detection application. Typically, there would be a large number of issues detected when bringing the different disciplinary models together, even for an average building, such as structural elements clashing with architectural elements, inadequate tolerances for the MEP elements, and so on. Before BCF, the conflicts that were detected had to be sent back to the individual BIM authoring applications in the form of reports describing each problem and including screenshots for clarity, and these would have to be painstakingly studied by the design team to figure out where and what the issues were with their design model so they could be corrected. The BCF format was developed by Tekla and Solibri in 2009 to streamline the process of compiling and reporting issues, and it was subsequently adopted as a standard by buildingSMART.
Given the importance of model coordination and clash detection to detect and resolve any design conflicts prior to construction, there are an increasing number of applications that perform this task, often in addition to other tasks. So, for instance, Solibri does model checking and quantity takeoff in addition to clash detection (Figure 2), BIMcollab does model validation in addition to issue management, Visicon has data visualization and model interrogation capabilities in addition to design coordination, and Bexel Manager has 4D, 5D, and 6D BIM capabilities in addition to coordination and clash detection.
Irrespective of what else they do, all these applications work with BCF in the same manner — the issues that are detected in the combined model are compiled and exported in BCF format, which can then be imported into the BIM authoring applications to make the necessary changes to the individual models. In order to address a specific issue, it simply needs to be selected from the BCF list that is imported. Because the BCF format also captures which elements are involved in an issue, selecting it will automatically take you to the location in the model where that issue was detected. An example of this is shown in Figure 4, where selecting an issue brought into Navisworks through BIMcollab’s BCF Manager directly takes you to the view of the model where the issue is detected. Essentially, a BCF file is shared between all the different disciplines that are coordinating the design.
In addition to the issue, its location, and the elements involved, the BCF format can also include the date when the issue was detected, its status, the person to whom it has been assigned, comments, priority level, the date it was resolved, and any other relevant information. This allows all the issues to be managed and tracked. As and when issues are resolved, their status is updated in the BCF file. The updated BCF file can then be returned to the coordination application along with the updated model in IFC format for the next round of coordination and clash detection.
These are three additional buildingSMART standards that are targeted primarily towards the developers of AEC applications rather than end users. Of these, the MVD (Model View Definition) is the easiest to understand. As shown in the graphic in the left of Figure 5, it refers to the different subsets of the full IFC model that would be needed for specific tasks such as energy analysis, structural analysis, daylighting calculations, and so on. So, for example, an energy analysis application does not need to know all the details of all the elements in the IFC, only those elements and properties that are relevant for energy analysis. Thus, rather than exporting the full IFC model, you would export only the MVD for energy analysis. In addition to making the analysis application faster — as it does not have to parse the entire file to ferret out what it needs — the file itself can be considerably smaller in size, which is always helpful. buildingSMART has developed MVDs for different tasks, and these can be seen in the different options that are available when a model is being exported to IFC in a BIM application (see Figure 5, right image). You would choose the MVD that is most relevant to the planned use of the IFC.
As the IFC continues to develop and add more elements, the number of MVDs will also continue to increase, enabling the IFC to be used for an increasing number of specialized tasks. For example, the new IFC4 format includes a new “Design Transfer View” for higher fidelity — it preserves the building data so you can technically export it to another application and continue working with it. Once we have IFC5, we will likely have an MVD for specific infrastructure elements such as roads, rails, etc. And looking even further ahead, we could have an IFC export specifically for FM.
The remaining two standards are even more technical. The IDM (Information Delivery Manual) was created in order to able to define the MVDs for different use cases. It maps out a process and determines what information is needed to carry out that process, which is then used to create the IFC MVDs. In addition to its use by the buildingSMART development team, IDMs are also often used by large organizations to define custom IFC subsets for internal processes.
And finally, the bSDD (buildingSMART Data Dictionary) is similar to a translator for BIM elements, mapping the terminology of different elements in different languages and classification systems to ensure that an element such as a wall or window has the same object definition, property information, and relationship information across all BIM applications, irrespective of country, localization, or classification system in use.
Interoperability is a critical issue for computer applications in any domain, ensuring that all the systems used for different tasks and by different users within that domain can talk to each other. We do not want to rely on one vendor to develop all the systems, assuming that was even possible. Just as multiple brands in any field are a sign of a vibrant, thriving industry, the large number of AEC applications points to an industry that is being well served by technology. We are fortunate to have an independent and neutral organization like buildingSMART that has been developing open standards for AEC technology applications for close to thirty years now. The IFC, in particular, has become synonymous with openness and interoperability, and by providing the foundation for OpenBIM, it ensures that innovative and useful technology solutions for the AEC industry can be developed both by large, publicly-traded vendors as well as by one-person startups alike.
Lachmi Khemlani is founder and editor of AECbytes. She has a Ph.D. in Architecture from UC Berkeley, specializing in intelligent building modeling, and consults and writes on AEC technology. She can be reached at lachmi@aecbytes.com.
Have comments or feedback on this article? Visit its AECbytes blog posting to share them with other readers or see what others have to say.
AECbytes content should not be reproduced on any other website, blog, print publication, or newsletter without permission.
This article provides a broad overview of the IFC model without delving too deeply into its technicalities, intended to provide a better understanding of it to the AEC practitioner interested in interoperability.
In this article, Mario Gutman, Vice-president and Firmwide CAD Director of HOK, discusses the rebranding of the International Alliance for Interoperability (IAI) to buildingSMART, an organization he sees as the best forum for developing rigor in how the AEC industry exchanges information.
This review takes a detailed look at its interface and functionality of Solibri Model Checker, including its BIM model-checking capabilities, multi-disciplinary coordination, clash detection, model comparison, quantity take-off, and issue management.
This review explores the features and functionality of the cloud-based collaboration solution, Aconex, which has grown from a fledgling company in Australia to a company that manages several large-scale construction and engineering projects globally.
