top of page

OpenBIM in der Praxis: Warum der IFC-Austausch oft scheitert und was wirklich dahintersteckt

  • 1 day ago
  • 5 min read

Viele Tools, wenig Klarheit: Woran scheitern BIM-Projekte eigentlich?


Wie viele buildingSMART-zertifizierte Tools gibt es eigentlich? 10, 50 oder über 100? Wer sich mit BIM beschäftigt, stößt schnell auf eine wachsende Zahl an Softwarelösungen, Zertifizierungen und Standards. In vielen Diskussionen verschiebt sich der Fokus dadurch weg vom eigentlichen Ziel - einem konsistenten und nutzbaren Modell - hin zur Frage nach dem „richtigen Tool“.


In der Praxis zeigt sich jedoch ein anderes Bild: BIM scheitert selten an fehlender Software, sondern deutlich häufiger am Datenaustausch zwischen den Beteiligten - und dieses Problem wird bei steigender Anzahl an buildingSMART-zertifizierten Tools nicht weniger. Genau hier wird das Thema OpenBIM und insbesondere der IFC-Import und -Export entscheidend.



Bild von DC Studio auf Magnific


Worauf kommt es beim IFC-Austausch wirklich an?


Die Anzahl buildingSMART-zertifizierter Tools ist hoch, aber für den Projekterfolg nicht primär ausschlaggebend. Entscheidend ist, dass die Informationsanforderungen an das Projektmodell klar sind, damit weitere Vorgehensweisen festgelegt werden können. Wichtig ist auch, dass die Projektbeteiligten ein gemeinsames Verständnis für die Datenstruktur haben. OpenBIM funktioniert nämlich nur dann zuverlässig, wenn IFC nicht nur als Dateiformat, sondern als strukturierter Informationsaustausch verstanden wird.



OpenBIM ist mehr als IFC-Dateien austauschen


OpenBIM beschreibt ein Konzept, bei dem Fachmodelle unabhängig voneinander in nativen Softwares (z. B. Archicad, Revit,...) erstellt und anschließend über offene Standards, also einheitliche Dateiformate wie IFC, zusammengeführt werden.


buildingSMART entwickelt dafür zentrale Grundlagen wie IFC, BCF und IDS, um einen softwareunabhängigen Datenaustausch zu ermöglichen.


IFC bildet dabei die eigentliche Datenstruktur für den Austausch von geometrischen und alphanumerischen Informationen. Wichtig ist: IFC ist kein einfaches Austauschformat, sondern ein komplexes Datenmodell mit definierten Beziehungen, Eigenschaften und Hierarchien.


Ein häufiges Missverständnis besteht darin, OpenBIM mit „problemloser Austauschbarkeit“ gleichzusetzen. Tatsächlich ist der Austausch nur dann konsistent, wenn die zugrunde liegenden Anforderungen, Strukturen und Modellierungsregeln abgestimmt sind.



buildingSMART-Zertifizierung: Was sie leistet und was nicht?


Eine Software kann von buildingSMART zertifiziert werden, um eine korrekte Implementierung von IFC sicherzustellen. Ziel ist eine durchgängig hohe Übertragungsqualität.


Wichtig ist jedoch die Einschränkung: Die Zertifizierung bezieht sich nicht auf BIM insgesamt, sondern auf definierte Teilbereiche, sogenannte Model View Definitions (MVD). Diese beschreiben, welche Ausschnitte des IFC-Datenmodells für einen bestimmten Anwendungsfall relevant sind.


Ein Beispiel ist die Coordination View. Diese MVD wurde entwickelt, um Fachmodelle verschiedener Disziplinen für die Koordination zusammenzuführen. Dafür sind beispielsweise Geometrie, Bauteilklassifizierungen und räumliche Beziehungen relevant. Detaillierte Informationen für Ausschreibung, Betrieb oder Fertigung sind hingegen nicht zwingend enthalten.


Der eigentliche Anwendungsfall entscheidet also darüber, welche Informationen benötigt werden. Typische openBIM-Anwendungsfälle sind beispielsweise:


  • Kollisionsprüfung zwischen Architektur- und TGA-Modellen

  • modellbasierte Koordination mehrerer Fachdisziplinen

  • Mengen- und Massenermittlung

  • Übergabe eines Modells an das Facility Management

  • modellbasierte Prüf- und Freigabeprozesse


Das bedeutet für Sie als Anwender:


  • Zertifizierte Software kann IFC-Daten technisch korrekt lesen und schreiben

  • sie garantiert jedoch nicht, dass die Inhalte vollständig oder sinnvoll strukturiert sind

  • sie prüft nicht, ob projektbezogene Anforderungen eingehalten wurden


Achtung: Validierungswerkzeuge prüfen nicht die inhaltliche Qualität, sondern in erster Linie die formale Konformität einer IFC-Datei (z. B. Syntax, Schema). Hier entsteht in vielen Projekten ein falsches Sicherheitsgefühl, denn der Datenaustausch funktioniert technisch, aber inhaltlich könnte die Grundlage fehlen.



Informationsanforderungen: Der eigentliche Kern des Datenaustauschs


Damit OpenBIM funktioniert, müssen die Informationsanforderungen klar definiert sein. Diese werden im Projekt üblicherweise über AIA/EIR beschrieben.


Diese Anforderungen legen fest:


  • welche Informationen benötigt werden

  • in welcher Struktur sie vorliegen sollen

  • zu welchem Zeitpunkt sie geliefert werden müssen


Die AIA/EIR sind damit die Grundlage für alle nachgelagerten Prozesse und definieren den Informationsaustausch zwischen Auftraggeber und Auftragnehmer .


Ein entscheidender Punkt aus der Praxis: Ohne diese Anforderungen modelliert jedes Fachmodell „für sich richtig“, aber möglicherweise nicht kompatibel zum Gesamtmodell.


Mit neueren Ansätzen wie der Information Delivery Specification (IDS) werden diese Anforderungen aber zunehmend maschinenlesbar formuliert. Dadurch können Modelle automatisiert gegen definierte Anforderungen geprüft werden.


Das verändert den Fokus nochmal: Nicht der Export selbst ist entscheidend, sondern die Frage, ob das Modell die geforderten Informationen überhaupt enthält.



IFC-Mapping: Der unterschätzte kritische Schritt


Bevor ein Modell exportiert wird, müssen die Inhalte auf das IFC-Datenmodell abgebildet werden. Dieses sogenannte Mapping erfolgt in der nativen Software und ist in vielen Projekten ein manueller (und leider oft fehleranfälliger) Prozess.


Dabei werden unter anderem festgelegt:


  • welche Bauteile welchen IFC-Klassen zugeordnet werden

  • welche Eigenschaften in welchen Property Sets landen

  • wie Hierarchien (z. B. Geschosse, Systeme) aufgebaut sind


Diese Entscheidungen sind nicht eindeutig vorgegeben und hängen stark von Projektanforderungen und Fachlogik ab.


In der Praxis zeigt sich, dass viele Probleme nicht beim IFC-Import entstehen, sondern bereits beim Mapping vor dem Export aus der nativen Software.



TGA: Warum ist OpenBIM hier besonders anspruchsvoll?


Die TGA stellt im OpenBIM-Kontext eine besondere Herausforderung dar. Während Architekturmodelle stark geometrisch geprägt sind, basiert die TGA wesentlich stärker auf Systemlogik und nicht sichtbaren Informationen.


Typische Herausforderungen:


  • Bauteile sind klein, dicht und oft verdeckt

  • Informationen wie Dimensionen oder Medien sind nicht direkt sichtbar

  • Systemzusammenhänge sind entscheidend für die Modelllogik


Gerade bei Bestandsprojekten oder Scan-to-BIM-Prozessen sind viele dieser Informationen nicht direkt erfassbar und müssen interpretiert werden.


Das führt zu einer zentralen Konsequenz: In der TGA ist die Qualität des Modells weniger eine Frage der Geometrie als eine Frage des Fachverständnisses.


Wenn solche Modelle später über IFC zusammengeführt werden, treffen unterschiedliche Interpretationen aufeinander. Ohne klare Anforderungen und abgestimmte Modellierungslogik entstehen inkonsistente Gesamtmodelle. Dabei können wir Sie jedoch unterstützen - hier kommen Sie zu unseren TGA-Modellierungsleistungen.



Warum viele Modelle technisch funktionieren, aber inhaltlich scheitern


In vielen Projekten lassen sich IFC-Dateien problemlos importieren. Das Modell ist sichtbar, Bauteile sind vorhanden, die Struktur wirkt plausibel.


Die Probleme zeigen sich erst bei der Nutzung:


  • Attribute fehlen oder sind uneinheitlich

  • Bauteile sind unterschiedlich klassifiziert

  • Mengen lassen sich nicht zuverlässig auswerten

  • Systeme sind nicht konsistent aufgebaut


Diese Probleme entstehen nicht durch Softwarefehler, sondern durch fehlende Abstimmung im Vorfeld.

OpenBIM stellt dabei “nur” die Infrastruktur für den Austausch bereit, die Qualität der Inhalte bleibt jedoch Aufgabe der Projektbeteiligten.



Praxisperspektive: Was in Projekten oft unterschätzt wird


In realen Projekten zeigt sich, dass OpenBIM vor allem an drei Punkten unterschätzt wird.


  1. Der Aufwand für die Definition von Anforderungen.AIA/EIR werden häufig zu spät oder zu oberflächlich erstellt, obwohl sie die Grundlage für alle Modelle bilden.

  2. Die Rolle der Datenstruktur.IFC wird oft als Dateiformat verstanden, nicht als strukturiertes Datenmodell mit Regeln.

  3. Die fachliche Tiefe in den Disziplinen. Gerade in der TGA entscheidet das Verständnis von Systemen darüber, ob ein Modell später nutzbar ist.


Hinzu kommt, dass der openBIM-Ansatz bewusst auf den Einsatz mehrerer Softwarelösungen setzt. Dadurch steigt der Abstimmungsbedarf zwischen den Beteiligten (und genau dieser wird leider häufig unterschätzt).



OpenBIM ist kein Softwareproblem, sondern ein Informationsproblem 


Die Frage nach der Anzahl buildingSMART-zertifizierter Tools ist nachvollziehbar, greift aber zu kurz. Für den Projekterfolg ist nicht entscheidend, wie viele Tools verfügbar sind, sondern wie konsistent Informationen definiert, modelliert und ausgetauscht werden.


OpenBIM und IFC schaffen die technische Grundlage für Interoperabilität. Sie lösen jedoch nicht automatisch die inhaltlichen Herausforderungen. Ohne klare Informationsanforderungen, sauberes Mapping und fachliches Verständnis entstehen Modelle, die zwar austauschbar sind, aber keinen belastbaren Mehrwert liefern.


Gerade in komplexen Bereichen wie der TGA zeigt sich: BIM ist weniger ein Softwarethema als ein Thema des Informationsmanagements.


Dieser Artikel basiert u. a. auf Inhalten aus dem BIMcert Handbuch „Grundlagenwissen openBIM“ (buildingSMART, 2024) sowie praktischen Projekterfahrungen.



Sie interessiert das Thema 3D Modellierung (BIM) und möchten mehr darüber erfahren oder Sie haben konkrete Fragen? Über einen gemeinsamen Austausch freuen wir uns sehr!


Michael Danklmaier, Miviso Co-Founder

Tel.: +43 512 931824 200




Comments


bottom of page