IFC vs. proprietäre Formate: Warum Open BIM (irgendwann) gewinnen wird

Der Dateiformate-Kalte-Krieg

Jede Woche bei der Sasez GmbH durchliefen wir das gleiche Koordinationsritual. Der Architekt schickt eine .rvt-Datei. Der Tragwerksplaner schickt eine .dwg. Das TGA-Team (wir) schickt eine weitere .rvt. Der Fassadenberater schickt eine .ifc. Und der Projektleiter öffnet jede einzelne in einem anderen Viewer und sucht nach Kollisionen, die möglicherweise gar nicht existieren.

Das ist die Realität der BIM-Koordination im Jahr 2025. Wir haben einen universellen Standard — IFC — der die Interoperabilität lösen soll. Und wir haben proprietäre Formate — RVT, DWG, PLN — die tatsächlich die Daten enthalten, die man braucht.

Nach über 3 Jahren täglicher BIM-Arbeit bin ich zu einem Schluss gekommen: IFC wird irgendwann gewinnen. Aber „irgendwann" könnte ein Jahrzehnt entfernt sein, und der Weg dorthin ist unordentlicher, als die meisten BIM-Evangelisten zugeben.

Was IFC eigentlich ist

IFC — Industry Foundation Classes — ist ein offenes, ISO-standardisiertes Datenmodell zur Beschreibung von Gebäude- und Bauwerksdaten. Die aktuelle Version ist IFC4 (ISO 16739-1:2018), wobei IFC4.3 die Abdeckung auf Infrastruktur (Brücken, Straßen, Schienen) erweitert.

Im Kern ist IFC ein Schema. Es definiert Entitäten wie Wände, Kanalabschnitte, Räume und die Beziehungen zwischen ihnen. Eine IFC-Datei ist ein serialisierter Graph dieser Entitäten, typischerweise im STEP-Format (.ifc) oder zunehmend in XML (.ifcXML).

Das Format ist nicht hübsch anzusehen — es ist ein dichtes, maschinenorientiertes Textformat. Aber es ist universell. Jede BIM-Software, die das IFC-Schema implementiert, kann es lesen.

Wo IFC heute funktioniert

IFC glänzt in Szenarien, in denen der Datenaustausch nicht bidirektional sein muss:

Behördliche Einreichungen

In Deutschland akzeptieren oder verlangen viele Baubehörden mittlerweile IFC-Dateien für Baugenehmigungsanträge. Das Modell wird als Momentaufnahme eingereicht — niemand muss es weiter bearbeiten. Das kann IFC gut.

Modellprüfung

Tools wie Solibri und SimpleBIM nutzen IFC-Dateien für automatisierte Regelprüfungen. Hat jeder Raum einen Fluchtweg? Sind alle Flure breit genug für Rollstuhlzugang? Ist der Lüftungskanalabstand ausreichend? Diese Prüfungen arbeiten auf dem IFC-Datenmodell und brauchen keine parametrische Bearbeitungsfähigkeit.

Archivierung

IFC ist ein ISO-Standard mit über 20-jähriger Erfolgsgeschichte. Wenn man ein Gebäudemodell für die nächsten 50 Jahre archivieren muss, ist es riskant, auf ein proprietäres Format zu setzen, das in 10 Jahren möglicherweise nicht mehr existiert.

Multi-Vendor-Projekte

Wenn der Architekt ArchiCAD nutzt, der Tragwerksplaner Tekla und das TGA-Team Revit, ist IFC die einzige gemeinsame Sprache. Unvollkommen, aber alternativlos.

Wo IFC noch versagt

Und nun die harten Wahrheiten.

Round-Trip-Bearbeitung ist weitgehend ein Mythos

Das Versprechen von „Open BIM" ist, dass man IFC aus einem Tool exportiert, in einem anderen bearbeitet und die Änderungen zurückimportiert. In der Praxis funktioniert das fast nie sauber.

Wenn man ein Revit-Modell nach IFC exportiert, verliert man:

  • Parametrische Beziehungen (eine Wandhöhe, die an ein Geschoss gebunden ist)
  • Familiendefinitionen (die „Intelligenz" der Revit-Komponenten)
  • TGA-Systemverbindungen (welcher Kanal mit welchem Lüftungsgerät verbunden ist)
  • Ansichtsspezifische Einstellungen und Beschriftungen
  • Plan- und Mengendaten, die an Revit-Parameter gebunden sind

Man bekommt Geometrie und Basiseigenschaften. Das ist nützlich, aber es ist kein funktionsfähiges Modell.

TGA-System-Genauigkeit ist mangelhaft

Das ist mein spezifischer Schmerzpunkt als TGA-Ingenieur. IFC kann HLK-Systeme darstellen — Kanäle, Rohre, Formstücke, Endgeräte, Verteilsysteme. Theoretisch kann man ein komplettes Kanalnetz beschreiben.

In der Praxis hängt die Exportqualität vollständig vom IFC-Exporter des Autorenwerkzeugs ab. Revits IFC-Export für TGA-Systeme hat sich seit 2020 deutlich verbessert, aber ich stoße regelmäßig auf:

  • Fehlende Systemzuordnungen. Kanalabschnitte, die ohne ihre Verteilungssystem-Beziehung exportiert werden.
  • Unterbrochene Konnektivität. Formstücke (Bögen, T-Stücke, Reduzierungen), die nicht korrekt mit ihren angrenzenden Segmenten verbunden sind.
  • Verlorene Property Sets. Benutzerdefinierte Shared Parameters in Revit, die nicht auf Standard-IFC-Property-Sets abgebildet werden und stillschweigend entfallen.
  • Vereinfachte Geometrie. Komplexe TGA-Komponenten (Lüftungsgeräte, Wärmetauscher), die zu Bounding Boxes reduziert werden.

Das Property-Set-Problem

IFC definiert Standard-Property-Sets für gängige Attribute — Nenndurchmesser, Form, Betriebsdruck für Kanalabschnitte. Aber jedes Büro verwendet zusätzliche benutzerdefinierte Properties, die nicht in diese vordefinierten Sets passen.

Es gibt keine universelle Vereinbarung über Namenskonventionen, Einheiten oder Werttypen. Das „InsulationThickness" eines Büros ist das „Insul_Thk_mm" eines anderen ist das „DämmstärkeInMillimeter" eines dritten.

buildingSMARTs bSDD (buildingSMART Data Dictionary) soll das mit einem gemeinsamen Klassifikationssystem lösen, aber die Verbreitung ist noch gering.

Was buildingSMART dagegen unternimmt

IFC4.3 — Infrastruktur-Erweiterung

IFC4.3 erweitert das Schema auf Straßen, Brücken, Schienen, Häfen und Wasserstraßen — ein großer Schritt für Infrastrukturprojekte.

IDS — Information Delivery Specification

IDS ist eine maschinenlesbare Methode, um zu definieren, welche Informationen ein IFC-Modell enthalten muss. Statt eines 50-seitigen BIM-Abwicklungsplans, den niemand liest, definiert man eine IDS-Datei, gegen die automatisierte Tools validieren können. Potenziell transformativ.

IFC5 — Der Neuentwurf

IFC5 befindet sich in früher Entwicklung und zielt darauf ab, grundlegende Schema-Probleme zu beheben. Die größte Änderung: der Umstieg von STEP-Serialisierung auf ein modernes Format (wahrscheinlich JSON-LD), das für Webanwendungen einfacher zu verarbeiten ist.

Was die Branche jetzt tun kann

In Open-Source-Tools investieren

  • IfcOpenShell — Das beste Open-Source-IFC-Toolkit.
  • BlenderBIM — Eine vollständige BIM-Autoringsoftware auf Basis von Blender. Open Source und erstaunlich leistungsfähig.
  • xBIM — Eine .NET-Bibliothek für IFC, beliebt in der Revit-Add-in-Welt.

IFC-native Tools bauen

Statt Tools zu bauen, die aus proprietären Formaten importieren und IFC als Nachgedanken exportieren, sollte man Tools bauen, die IFC-nativ sind — wo IFC das primäre Datenmodell ist.

Das ist, was ich mit Mepbau erforsche: Kann ein webbasiertes HLK-Berechnungstool nativ IFC-Output erzeugen, damit die Ergebnisse direkt in den BIM-Koordinationsworkflow einfließen?

Meine Prognose

IFC wird proprietäre Formate nicht für das Authoring ersetzen. Architekten werden weiterhin in ArchiCAD entwerfen, Tragwerksplaner in Tekla, TGA-Ingenieure in Revit.

Was IFC ersetzen wird, ist die Austauschschicht. Innerhalb von 10 Jahren wird meiner Meinung nach:

  1. IFC + Cloud-APIs den dateibasierten Modellaustausch ersetzen.
  2. IDS die PDF-basierten BIM-Abwicklungspläne ersetzen.
  3. IFC-native Web-Tools für spezifische Workflows entstehen (Modellprüfung, Mengenermittlung, Energiesimulation, HLK-Dimensionierung).
  4. Property-Standardisierung über bSDD in bestimmten Domänen kritische Masse erreichen.

Der proprietäre Dateiformate-Krieg wird nicht mit einem Vertrag enden. Er wird enden, weil die Austausch-Infrastruktur so gut wird, dass es keine Rolle mehr spielt, in welchem Format man arbeitet.

Arbeiten Sie an IFC-Tooling oder Open-BIM-Entwicklung? Schreiben Sie mir an hello@laborsam.com.