OpenBIM in Practice: Why IFC exchange often fails - and what actually causes it
- 9 hours ago
- 6 min read
Many tools, little clarity: What do BIM projects actually fail at?
How many buildingSMART-certified tools are there today? 10, 50, or more than 100? Anyone working with BIM quickly encounters a growing number of software solutions, certifications, and standards. In many discussions, the focus shifts away from the actual goal - a consistent and usable model - toward the question of choosing the “right tool.”
In practice, however, the picture looks quite different: BIM rarely fails because of missing software, but much more often because of problems in data exchange between project participants and this issue does not disappear simply because more buildingSMART-certified tools exist. This is exactly where OpenBIM, and especially IFC import and export, become critical.
This article covers:
What really matters in IFC data exchange?
The number of buildingSMART-certified tools is high, but this is not the primary factor determining project success. What matters is that the information requirements for the project model are clearly defined so that workflows and exchange processes can be properly established. It is equally important that all project participants share a common understanding of the data structure.
OpenBIM only works reliably when IFC is understood not merely as a file format, but as a structured exchange of information.
OpenBIM is more than exchanging IFC files
OpenBIM describes a concept in which discipline-specific models are created independently in native software environments (e.g. Archicad, Revit, etc.) and then merged using open standards such as IFC.
To enable software-independent data exchange, buildingSMART develops core standards such as IFC, BCF, and IDS.
IFC itself forms the underlying data structure for exchanging both geometric and alphanumeric information. It is important to understand that IFC is not a simple exchange format, but a complex data model with defined relationships, properties, and hierarchies.
A common misconception is to equate OpenBIM with “frictionless interoperability.” In reality, data exchange only works consistently if the underlying requirements, structures, and modeling rules are aligned.
BuildingSMART Certification: What it does and what it does not do?
Software can be certified by buildingSMART to ensure correct IFC implementation. The goal is to achieve consistently high transfer quality.
However, there is an important limitation: Certification does not apply to BIM as a whole, but only to defined subsets known as Model View Definitions (MVDs). These define which parts of the IFC data model are relevant for a specific use case.
One example is the Coordination View. This MVD was developed to combine discipline-specific models from different trades for coordination purposes. In this context, geometry, element classifications, and spatial relationships are essential. Detailed information for tendering, operations, or fabrication, however, is not necessarily included.
The actual use case therefore determines which information is required. Typical OpenBIM use cases include:
clash detection between architectural and MEP models
model-based coordination across multiple disciplines
quantity takeoff and quantity calculation
transferring models into facility management workflows
model-based review and approval processes
For users, this means:
certified software can technically read and write IFC data correctly
but it does not guarantee that the content is complete or meaningfully structured
and it does not verify whether project-specific requirements have been fulfilled
An important point is often overlooked: validation tools mainly check the formal conformity of an IFC file (e.g. syntax or schema compliance), not its actual content quality. This creates a false sense of security in many projects - technically, the data exchange works, but the informational basis may still be insufficient.
Information Requirements: The actual core of data exchange
For OpenBIM workflows to function properly, information requirements must be clearly defined. In projects, these are typically documented through EIR/AIR requirements.
These requirements define:
which information is needed
how this information must be structured
and at which project stage it has to be delivered
EIR/AIR requirements therefore form the basis for all downstream processes and define the exchange of information between client and contractor.
One critical observation from practice is this: without clearly defined requirements, each discipline-specific model may be “correct” on its own, while still being incompatible with the overall project model.
With newer approaches such as the Information Delivery Specification (IDS), these requirements are increasingly being defined in machine-readable form. This allows models to be automatically checked against predefined requirements.
This fundamentally changes the focus: the decisive factor is not the export itself, but whether the model actually contains the required information.
IFC Mapping: The underestimated critical step
Before a model can be exported, its contents must be mapped to the IFC data model. This process - known as IFC mapping - takes place inside the native software environment and is still a manual and often error-prone process in many projects.
Among other things, this process determines:
which building elements are assigned to which IFC classes
which properties are stored in which property sets
how hierarchies such as storeys or systems are structured
These decisions are not fully predefined and strongly depend on project requirements and discipline-specific logic.
In practice, many IFC-related issues do not arise during import, but much earlier — during mapping before export from the native software.
MEP: Why OpenBIM is especially challenging here?
Within OpenBIM workflows, MEP disciplines present a particular challenge. While architectural models are strongly geometry-driven, MEP models depend much more heavily on system logic and invisible information.
Typical challenges include:
components are small, dense, and often hidden
information such as dimensions or media types is not directly visible
system relationships are critical for the model logic
Especially in renovation projects or Scan-to-BIM workflows, much of this information cannot be directly captured and must instead be interpreted.
This leads to a key consequence: in MEP modeling, model quality is less a question of geometry and much more a question of technical expertise.
When such models are later merged via IFC, different interpretations collide. Without clearly defined requirements and aligned modeling logic, inconsistent federated models are inevitable.
Why many models work technically but fail in practice
In many projects, IFC files can be imported without any apparent problems. The model is visible, elements exist, and the structure appears plausible.
The real issues only become apparent during actual use:
attributes are missing or inconsistent
elements are classified differently
quantities cannot be evaluated reliably
systems are structured inconsistently
These problems are not caused by software errors, but by insufficient coordination beforehand.
OpenBIM merely provides the infrastructure for exchange. The quality of the content itself remains the responsibility of the project participants.
Practical Perspective: What is often underestimated in projects?
In real-world projects, OpenBIM is consistently underestimated in three key areas.
The effort required to define requirements EIR/AIR documents are often created too late or too superficially, even though they form the basis for all models.
The role of the data structure IFC is often misunderstood as a simple file format rather than a structured data model governed by rules.
The technical depth required within the disciplines Especially in MEP, the usability of a model depends heavily on the understanding of systems.
In addition, the OpenBIM approach intentionally relies on multiple software solutions. This significantly increases the need for coordination between project participants and this coordination effort is frequently underestimated.
OpenBIM is not a Software Problem, it’s an Information Management Problem
The question of how many buildingSMART-certified tools exist is understandable, but ultimately misses the point. Project success does not depend on the number of available tools, but on how consistently information is defined, modeled, and exchanged.
OpenBIM and IFC provide the technical foundation for interoperability. However, they do not automatically solve the underlying content-related challenges. Without clearly defined information requirements, clean mapping, and technical expertise, models may technically be exchangeable while still delivering little practical value.
Especially in complex disciplines such as MEP, one thing becomes clear: BIM is less a software issue and much more an issue of information management.
This article is based in part on the BIMcert Handbook “Grundlagenwissen openBIM” (buildingSMART, 2024) as well as practical project experience.
Are you interested in 3D modeling (BIM) and would like to find out more or do you have specific questions? We look forward to exchanging ideas with you!
Michael Danklmaier,
Miviso Co-Founder
E-Mail: michael.danklmaier@miviso.com
Tel.: +43 512 931824 200
Comments