Opacity of IFC, openBIM and buildingSMART
IFC-format or, more specifically, its controlling organisation buildingSMART, under the additional marketing umbrella of Nemetschek OpenBIM™ (openBIM® – registered buildingSMART designation) is heading towards a global data format for the construction industry.
Unfortunately, the buildingSMART organisation has de facto control over the development of the IFC project, and the project itself is subject to lobbying by individual interests, which prevents the development of the format itself from being considered transparent and open.
Asian and European beneficiaries of the openBIM movement
The active developers and main beneficiaries of the IFC idea today are European vendors seeking to reverse Autodesk’s hegemony over data, and Asian companies involved in the New Silk Road project.
The main focus of buildingSMART today is the development of the IFC Road, IFC Rail, IFC Ports, IFC Tunnel sections: almost all the achievements of the IFC format over the last seven years are related to the development of classifiers and documentation for infrastructure projects.
Asian investors (buildingSMART members) need to build a transport infrastructure from central China to central Europe within a reasonably short time frame. New railways are being laid across Asia and eastern Europe, and from Greek ports via Serbia to northern Europe, which will help speed up the delivery of goods from China to Europe via overland high-speed lines.
In 2020, the New Silk Road freight service already covered more than 13,000 km of roads.
The New Silk Road is a Chinese mega-project that would connect 65 countries by sea and land.
To synchronise project information, Asian and European specialists use the IFC format, with new feature classes (entities) and parametric geometries added to the classification, so that by describing these geometries a specific element is displayed in the same way in any (Asian or European) CAD program.
Unfortunately, not all elements or classes added to IFC are used in construction elsewhere in the world, i.e. rare elements or classes used in a less wealthy country (unable to promote its manufacturers through buildingSMART) will not be included in the official IFC classification and will only be recognised by all CAD programs through an additional “crutch” – IfcBuildingElementProxy.
The latest edition of IFC 4.3 Bridge shows how the lobbying of individual interests works: a Bridge Cap element has been added to the IFC format classification, which is only used when building in one particular European country. This happened because the developers from the specific committee (rooms) for the IFC Bridge discussion only work in one country, and it was particularly important for these specialists to add this element to the IFC classification, without taking into account the fact that elsewhere in the world, the Bridge Cap element is either not used in construction, or elements with a different geometry are used in that location when building bridges.
In other words, small groups of specialists with certain connections are able to write down the national elements of their manufacturers with a detailed description as a standard in the new version of the IFC world classification without additional discussions.
One example of the lobbying of individual countries (and their manufacturers) in buildingSMART standards is the rail connector Bonded joint (RTR_OT_TR-70). This common connection element in IFC is described in great detail, and specifically for this element there are all the properties and standard parameters, for automatic visualisation in any CAD program in the world.
But if railway builders in other countries do not have similar connectors in their projects or use similar connectors with different properties, these builders need to organise a national buildngSMART committee in their country so that after paying membership fees for certain access rights, through difficult lobbying of their interests in certain committees (rooms and chapters) they can add their native elements to the next version of the IFC world building element library.
And even with a good description of the geometry for such elements, importing and exporting it in different programmes turns into a quest of putting together a puzzle, which leads to different results in different CAD programmes.
Hidden features of the IFC format
Within construction companies, in order for the receiving (importing IFC) side to understand what kind of object has been exported to the IFC, the user exporting the model must have a good understanding of the task and purpose of the model transfer, while considering who the consumer of the model will be and what software will perform the import, which in practice is often an unfeasible task.
The completeness of the data transfer through the IFC file depends on how well the developers of the CAD solution have designed and implemented the IFC export/import module. If the export module from a 3D CAD program (Revit, Archicad) and the import module into another 4D-7D program or service (BIM360, Nevaris, Solibri) are worked on by developers from the same CAD corporation (Autodesk or Nemetschek), then all information will be transferred correctly and lossless through the IFC format.
But if you are working with data between systems with different developers, then because of the object-oriented approach and “small features” of the IFC format, it is not possible to correctly export, geometry-tune and transfer the data via IFC format without time-consuming manual mapping (matching) of all UserDefined properties and geometry in IfcBuildingElementProxy.
As a result, the strong point of SDK (software development kit), working with IFC-format, is not the 100% correct implementation of buildingSMART standards, but base of typical bugs in format implementation – i.e. ability to decrypt “not simple” IFC file.
Only strict adherence to the general requirements published in the huge number of buildingSMART IFC specification documents can guarantee quality data transmission via the IFC format. Documents are available free of charge, but there is a lack of transparency in a lot of bureaucratic texts as to how to interpret certain provisions in the requirements. The correct understanding of ‘certain provisions’ is only available to paid participants. As a consequence, whoever wants access to important knowledge (certain IFC features) will have to pay, or get to it by their own research, which may come out more expensive than the buildingSMART membership fee.
From an interview with a Renga CAD software developer (a buildingSMART member actively implementing the IFC format in his solutions): “You come across a question about importing and exporting data via the IFC format and ask fellow vendors: “Why is the information about parametric room transfer transmitted this way in IFC file? The open specification from buildingSMART does not say anything about this”. Response from “more knowledgeable” European vendors: “Yes, it doesn’t say, but it’s acceptable”.
The solution to this problem was to certify programmes to buildingSMART standards, which through compliance with a large number of bureaucratic points would solve the issue of proper implementation. Certification from buildingSMART for a small software company can start in six figures, which is a big burden on the business of such companies, and unfortunately one cannot fully trust the certification information, as the existence of a certificate often means that the IFC is only read, but one can only guess at the quality of that reading.
To avoid interpretation problems and to get a quality IFC file in different programs, it is necessary to openly publish additional recommendations (implementation agreements), now available only for paid members, to gather developers from big and medium companies every year and together with buildingSMART to force them with each release of new IFC version to connect all changes and innovations from buildingSMART with the innovations in their CAD-Legacy product in a quality way.
The complexity of working with the IFC format
In the IFC classification today there are almost 885 (4 years ago there were 700) Entities with a rather complex classification. The active addition of Entities in recent years has taken place thanks to the New Silk Road project.
The problem with the standard classification from buildingSMART is that it often does not coincide with internal national or construction company classifiers, which makes it impossible to automatically derive quality volumes from models in 4D-7D systems. In the case of absence of a certain class in an IFC classifier, to calculate 5D estimates (in costing, budgeting, operation) it is often necessary either to create a new “internal” IFC format with its own classes and properties, or wait for several years and “trust” foreign specialists to update or correct classifiers, disputes over which due to multi-level bureaucracy can last for years.
In order to communicate the complex process diagrams and logic for working with IFC format to designers, buildingSMART has an interesting approach (similar to ISO certification) to how knowledge about openBIM technology should reach the construction industry.
Obtaining initial buildingSMART certificates (training is often outsourced through third parties) starts at $1000-2000 for ordinary engineers. Prices for YouTube courses and workshops on buildingSMART standards for professionals or students from anywhere in the world start from €199.
In order to attract new professionals to IFC and openBIM, buildingSMART is coming to new countries. For most of the world, buildingSMART creates a business website where you can only pay for membership or buy training on IFC standards for a few thousand dollars.Thus, construction or software companies in countries that do not have an active buildingSMART presence (chapters и rooms) only pay money for membership, for the opportunity to receive a 30% discount on training and for the opportunity to put the buildingSMART logo on their website.
From the outside, such an ‘entry ticket’ to international business and a non-transparent management structure looks more like a monopoly industry cartel with local branches that are only set up to sell subscriptions and training.
Unfortunately, IFC format development today is not under the control of the Free Developers Society and the Open Source community, but under the control of the semi-closed organization buildingSMART and only its members, who have connections at a certain level and have bought an expensive subscription, can describe processes, define data structure, translate processes into technical requirements, create terminology and describe product properties. All these changes to the IFC standards are read-only, where no changes can be made without buying membership.
The construction community is left with the release of new versions of CAD software each year,
to rely on the goodwill of CAD corporation owners and the buildingSMART organisation to implement IFC import and export modules in the same way. The utopian nature of this idea unfortunately prevents the IFC data format from being considered a meaningful electronic document today.