Chapter 1.2 – The history of IFC

In practical use today are IFC2x3 and IFC4 Add2 TC1. IFC2x3 corresponds to ISO/PAS 16739:2005. IFC4 Add2 TC1 corresponds to ISO 16739-1:2018. IFC4.3 Add2 (with ISO 16739-1:2024) ISO standardized.

There is very little documentation on how IFC came about and what influences had an effect on it. The author of this article has witnessed the development in his professional life since 1985 and reports here as a contemporary witness.

The actual starting point for all the data models we know today lies in the 1960s and 1970s. At that time, it was recognized that computers could not only calculate, but also process information. With the application of mathematical relation theory to digital information processing, hierarchically organized structures could be defined(Edgar F. Codd et al.: IMS system with the DL/1 language), which we know today as relational database systems. A completely different approach was the development of net-like databases (CODASYL conference, COBOL language), which we know today as knowledge graphs or neural networks.

Relational databases have the advantage that they are relatively easy to understand. All you really need to know is that things and processes are represented as tables and the columns of the tables represent the properties of the things. The relationships between the things/processes (tables) can be mapped via linking references with the help of dedicated properties (table columns). These relations between the tables are structured hierarchically, circular connections (=nets) are to be avoided.

People are best able to find their way around hierarchical structures and try, wherever possible, to organize the world they control accordingly. In network structures (e.g. transportation networks), people quickly lose their bearings and need aids. The easy comprehensibility of the relational approach and the possibility of using it to implement the popular hierarchies in data technology have led to this approach being chosen frequently as a result.

This was also the case with the development of specifications for the exchange of product data at STEP (Standards for the Exchange of Product Data), which began in 1984 and was based on the predecessors IGEStop, SET and VDA-FS. Due to its complexity, the original plan to develop a single, complete product model was discarded, and so STEP was split into various parts and submitted to ISO in 1994/95. An essential component was and is the data modeling language EXPRESS, which was published as ISO 10303-11. While Part 11 can be used to describe the actual structures of a product data model, Part 21 (.spf, STEP Physical File Format, ISO 10303-21) defines the structures of an ASCII file for exchanging the actual product data (instances of a data model). A few years later, Part 28 (ISO 10303-28) defined how this product data can also be exchanged with XML files. Other basic formats are now available, each of which transfers the same content.

EXPRESS-G can be used to display the essential structures of an EXPRESS data schema in a graphic that is very similar to an entity relationship diagram. The close proximity to the relational data world is also evident here.

With the help of EXPRESS, so-called application protocols were then specified for specific use cases, whereby the initial focus was on the exchange of geometric data. AP 201 and AP 202 define basic, predominantly 2D geometry. AP 204 defines basic 3D boundary representation geometry. APs were also developed to describe specific mechanical components. WP 225 focused on components in building construction.

All these APs were heavily influenced by the CAD systems available on the market at the time. The focus was on geometry, to which classifications and some product properties could be attached like flags. To a certain extent, geometric components could be aggregated into component groups.

Many of the foundations for the developments at STEP were researched and developed in the EU-funded research projects at the time. It was there that the realization matured that data models for buildings, whose core structure was the geometry, were no longer useful. A U-turn followed and so-called semantic building data models began to be developed, which described the components as objects with attributes that could have relationships with each other. This view came to the fore, and from then on geometry played a role that was still prominently visible, but structurally subordinate.

Excursus: With ISO 10303-22 SDAI (Standard Data Access Interface), a standardized interface to databases whose data structures are generated by EXPRESS was already published last century. In other words, a standardized technical option would have been available last century to enable STEP data not only to be laboriously exchanged with files, but also to be shared by directly connecting applications to a database. Unfortunately, this was hardly used and has been forgotten.

In the EU project “VEGA” (Virtual Enterprises using Groupware Applications), a team led by Prof. Richard Junge and his former colleague Dr. Thomas Liebich, in cooperation with Nemetschek, where the author was still working at the time, developed an approach for a “semantic product model”, which was brought to market maturity in the 1990s with the in-house project O.P.E.N. (Object oriented Product Data Engineering Network) at Nemetschek. A “late-binding” approach was implemented, which allowed the data model for the server to be extended at runtime without having to recompile programs. This strategy made it possible to react quickly to changing requirements and new areas of application. This was the first industrial model server for the construction industry that could also be used via the Internet. However, it turned out that this was too early for the market, as the construction industry was still too attached to analog working methods. It was recognized that the processes in the construction industry would have to change fundamentally in order to achieve an increase in productivity with this approach, and that a software company alone could not bring about this paradigm shift. A company is not a research institute, which is why the O.P.E.N. project was discontinued. Subsequent history has shown that the approach was correct, but also that the timing was too early. Even today, a product like O.P.E.N. is still a gamble.

The advantages of the model approach from VEGA and O.P.E.N. were, in addition to the consistent turnaround away from the geometry-centric view, a layer model that had a level with common building components and topologies on a core with general structures, and a level for subject-specific structures above that. This architecture, implemented with a “late binding” approach, allowed for step-by-step development, as it was clear that the model would expand considerably, especially for different application areas.

The technical development of the data model was initially the responsibility of Autodesk employees, who were released from their duties for this purpose. After a few missteps, they became aware of the developments at STEP and brought in experts from this community. It was decided to take up a model approach by Prof. Frits Tolman, from which IFC was developed and presented and discussed in the versions 0.96 and 0.98 in larger rounds. After several prototype implementations, version IFC1.5.1 was the first to be supported by some software systems. The data exchange was proudly demonstrated at ACS 1998 using floppy disks.

Anecdote: the world’s first IFC file was exported from Allplan, which also supported STEP AP225 at the time, and therefore sufficient STEP know-how was available in the development department.

Note: If the STEP regulations were strictly adhered to, IFC files that are exchanged in the STEP Physical File Format should actually have the extension “.spf”. It was the pride and marketing of the modelers at IAI (buildingSMART) that established the “.ifc” extension, which was then surprisingly also accepted by ISO.

As IFC continued to develop, it became clear that the chosen approach had a decisive disadvantage: the model architecture was too monolithic. Every functional extension entailed changes right down to the core. It was recognized that such a data model could not be the basis for a global implementation, where each software company has its own release cycles. Incompatibilities could only have been avoided if everyone had always implemented at the same pace and published new releases at the same time. Synchronization was perhaps still conceivable with the small group of interested software houses at the time, but illusory for a global implementation.

In the meantime, it was clear that Nemetschek would discontinue the O.P.E.N. project for the reasons mentioned above. Prof. Junge received permission from Prof. Nemetschek to take the model approach from O.P.E.N. with him and thus save and further develop it. Shortly after IFC2.0 was published, the critical discussion about the emerging difficulties increased. The model approach from VEGA and O.P.E.N. was presented as a solution, which meant a complete new start, but solved the core problem of the previous IFC model thanks to the expandable layer architecture. Based on Nemetschek’s development experience, they also knew that this new approach would work in principle.

You can imagine that those who had put their heart and soul into developing IFC up to version 2.0 were not at all enthusiastic about a new start. The result was fierce disputes. But far-sighted managers at IAI understood that this change was necessary. Jeffrey Wix was appointed project manager and the new start was implemented, Thomas Liebich took over as head of the modeling group (MSG – Model Support Group), the author led the group of IFC-implementing software companies (ISG – Implementer Support Group) right from the start and was able to show them the way to the new version based on his experience. This was to be pursued further as IFC 3.0, but a version 3.0 so soon after the release of version 2.0 was considered too humiliating. The diplomatic way out was to give this new approach the name IFC2x, so that the “2” was still visible and the “x” stood for “extendable”, which most people could then swallow.

Of course, IFC2x data was completely incompatible with IFC2.0 data. This was accepted because this effect would have occurred sooner or later with IFC2.0 anyway, and because the group of supporting software houses was still manageable. The majority had very quickly recognized the advantages of IFC2x, and since STEP know-how was available from previous implementations, the developers were also able to switch relatively quickly.

The next step should have been an IFC version “3x”. In the meantime, however, only a few people knew where the “x” in the version numbers came from. However, since the “3” was so prominent in circulation with IFC2x3 and since IFC2x was actually already an IFC 3, they wanted a visible difference and decided to drop the “x” and make it clear with IFC4 that this also introduced changes to the basic structures. These improvements and new features resulted in a few more additions and corrections, which led to the IFC4 Add2 TC1 version. This version, now in conjunction with the so-called RV (Reference View), is also considered to be technically mature and is the basis for the certification of the software interfaces.

The new b-Cert certification platform was developed for IFC4, which has implemented a higher degree of automation for tests and can also support different MVDs and IFC versions.

The versions IFC4.1 to IFC4.3 have no changes to the core and contain extensions to the application layer for infrastructure buildings; IFC4.4 will follow, in which tunnels will also be taken into account.

This is currently being discussed under the number IFC5. The author’s thoughts on this: STEP formats are an area of expertise – knowledge of them lies with relatively few specialists. The selection of supporting tools for software development is therefore limited. You could certainly think about replacing the STEP formats with technical alternatives that reflect the current state of the art. This would make it easier for younger software developers to get started and there would be more supporting tools available. On the other hand, the huge number of IFC files generated to date means that STEP will still have to be exported and imported in the foreseeable future. Last but not least, the Finnish National Library has identified IFC4 as an archive format.

As long as you stick with technical foundations that essentially implement the relational model, replacing them with more modern variants will ultimately not change much for users. What users notice when they switch internally from technology that is still relational is marginal.

This effect was also evident, for example, when switching from IFC2x3-CV2.0 to IFC4-RV, which primarily brings internal technical advantages. The “user experience” with both variants is very similar. As a result, it is very difficult to motivate software houses to switch to IFC4-RV. Although it is an investment in the future, it offers no tangible immediate benefits for the customer. In addition, support for IFC2x3-CV2.0 cannot simply be switched off because there are too many of these files in practice – so both versions must be supported and this saves nothing in development.

This experience shows that a technical improvement that only works internally but is not recognizable from the outside is not very motivating for software companies.