IFC-Modellaustausch

Was ist der IFC-Modellaustausch?

Beim IFC-Modellaustausch wird ein Modell aus der Software, mit der es erstellt wurde, in eine neutrale, strukturierte Datei überführt, die jedes andere Programm eigenständig lesen kann. Industry Foundation Classes (IFC) ist das offene Schema dahinter, das von buildingSMART gepflegt und als ISO 16739 veröffentlicht wird. Es beschreibt Wände, Leitungen und Räume als benannte, typisierte Objekte – und nicht als Linien und einfache Geometrie. Austausch ist hier das Verb, nicht das Nomen: Exportieren, Mapping prüfen, Importieren und Round-Trip-Testen bestätigen gemeinsam, dass die empfangende Seite das erhalten hat, was die sendende Seite senden wollte.

Bei einem Wohnbauprojekt geschieht dies bei jeder Übergabe zwischen Gewerken, die keine gemeinsame Lizenz nutzen: vom Architekten an den Tragwerksplaner, vom Tragwerksplaner an die TGA-Koordination und vom gesamten Koordinationsmodell an den Bauherrn zur Übergabe. Jede Übergabe ist nur so gut wie die IFC-Datei, die sie überquert, denn das empfangende Werkzeug hat keinen Zugriff auf das, was im nativen Format zurückgeblieben ist.

Was überlebt einen IFC-Export tatsächlich – und was nicht?

Ein Export ist eine Übersetzung, und bei Übersetzungen gehen Dinge verloren. Eine Wand, die aus einer parametrischen Familie aufgebaut wurde, wird auf der anderen Seite des Exports zu einem festen Geometriestück, das als Wand mit einer Reihe von Eigenschaften getaggt ist: Sie erinnert sich nicht mehr an die Regel, die sie erzeugt hat, sondern nur an die Form und die Daten, die zum Zeitpunkt des Exports angehängt waren.

Überlebt in der Regel	Überlebt in der Regel nicht
Gesamtgeometrie und räumliche Hierarchie (Grundstück, Gebäude, Geschoss, Raum)	Native parametrische Regeln (die treibenden Maße und Randbedingungen der Familie)
Standard-Eigenschaftssets, die vom Autorentool gemappt werden (Material, Brandschutzklasse, Wärmedurchgangskoeffizient)	Benutzerdefinierte Eigenschaften, die das Tool nie auf ein IFC-Eigenschaftsset gemappt hat
Mengen, die der Exporteur zum Zeitpunkt des Exports berechnet (Fläche, Volumen, Länge)	Formeln und Live-Verknüpfungen, die diese Mengen antreiben
Objekttyp und Klassifikation (Wand, Leitungsabschnitt, Raum)	Ansichtsabhängige 2D-Bemaßung: Maßketten, Textnotizen, Detailhinweise, die an eine bestimmte Zeichnungsansicht gebunden sind

Ein Planer, der eine IFC-Datei erhält, kann die Planung nicht so bearbeiten, wie der Ersteller es könnte; er kann sie abfragen, vermessen, eine Kollisionsprüfung damit durchführen und Mengen extrahieren – aber nicht die parametrischen Regeln hinter einer Treppe oder Dachform. Austausch dient der Koordination und Dokumentation, nicht der gemeinsamen Bearbeitung.

Welche IFC-Schemaversion sollte ein Wohnbauprojekt verwenden?

Das Schema selbst hat Versionen, und die Wahl ist nicht nebensächlich.

Version	Veröffentlicht	Was sie gut abdeckt	Praktischer Hinweis
IFC2x3	2005	Gebäude: Architektur, Tragwerk, grundlegende TGA	Nach wie vor das am weitesten verbreitete Export- und Importziel in älteren Softwareversionen; die sicherste Voreinstellung, wenn das Werkzeug des Planers unbekannt ist
IFC4	2013	Gebäude, umfangreichere Eigenschaftssets, bessere TGA-Systeme und -Verbindungen	Ein saubereres Datenmodell, aber nicht jeder Viewer oder jedes ältere Tool liest es zuverlässig
IFC4.3 (ISO 16739-1:2024)	2024	Gebäude plus Infrastruktur wie Straßen, Schienen und Brücken	Für ein Einfamilienhaus überdimensioniert; relevant, sobald das Projekt die Grundstücksinfrastruktur berührt

Für ein Einfamilienhaus oder ein kleines Wohnbauprojekt bleibt IFC2x3 der pragmatische Standard für den externen Austausch: Es ist die Version, die jeder Viewer, jedes Prüfwerkzeug und jedes ältere Planungstool noch ohne Probleme öffnet. Auf IFC4 zu bestehen, lohnt sich, sobald alle Beteiligten in der Kette einen sauberen Export und Import bestätigt haben, da es strukturierte TGA-Daten zuverlässiger transportiert.

Wie unterscheidet sich der IFC-Modellaustausch vom Versenden einer nativen Projektdatei?

Eine native Datei (.rvt, .pln, .skp) ist eine vollständige, bearbeitbare Kopie des Projekts des Erstellers, aber sie öffnet sich korrekt nur in dem Werkzeug, das sie erstellt hat – oft nur in einer passenden Version. Das Senden an einen Planer, der diese Software nicht besitzt, sendet ihm etwas, das er nicht öffnen kann.

Der IFC-Austausch tauscht Bearbeitbarkeit gegen Unabhängigkeit ein: Die empfangende Seite erhält eine Datei, die jeder IFC-fähige Viewer öffnen kann – um den Preis der oben beschriebenen parametrischen Intelligenz. Er tauscht auch eine Lizenzabhängigkeit gegen eine Formatabhängigkeit ein: Eine native Datei wird unlesbar, sobald niemand im Projekt mehr eine gültige Lizenz für diese Software besitzt, während eine IFC-Datei als offener ISO-Standard lesbar bleibt, unabhängig davon, für welche Werkzeuge noch gezahlt wird.

Die beiden sind keine Konkurrenten: native Dateien für die Bearbeitung innerhalb einer Disziplin, IFC-Austausch für alles, was eine Disziplin- oder Softwareschranke überquert.

Wie sieht ein disziplinierter Austausch-Workflow in der Praxis aus?

Ein zuverlässiger Workflow besteht aus vier Schritten, die bei jeder Modellausgabe wiederholt werden – nicht einmal am Ende:

• Export mit einer definierten Zuordnung. Die IFC-Exporteinstellungen des Autorentools legen fest, welche Eigenschaftssets, welche Schemaversion und welcher Detaillierungsgrad der Geometrie ausgegeben werden. Bei Standardeinstellungen variieren diese Angaben je nach Werkzeug und Version. Daher sollte ein Projekt sie einmal festlegen und dann wiederverwenden.
• Prüfung des Ergebnisses vor dem Versand. Öffnen Sie die exportierte Datei in einem neutralen Viewer – nicht im Autorentool – und überprüfen Sie, ob räumliche Hierarchie, Einheiten und Koordinatenursprung mit den Erwartungen des Empfängers übereinstimmen. Ein Modell, das 40 Meter von seinem Sollort entfernt liegt, sitzt unsichtbar falsch, bis es jemand bemerkt.
• Round-Trip-Test beim ersten Austausch des Projekts. Exportieren, dann in eine zweite Instanz des Quellwerkzeugs oder einen Viewer reimportieren, um zu bestätigen, dass nichts stillschweigend verloren gegangen ist. Einmal pro Projekt durchführen, nicht einmal pro Datei.
• Erneuter Export bei jeder Modellausgabe. Koordination ist nur sinnvoll, wenn die Datei, die die Grenze überquert, aktuell ist; ein veralteter Export macht den Zweck einer gemeinsamen Common Data Environment zunichte.

Warum sollte ein privater Bauherr sich für das Austauschformat interessieren?

Zwei Konsequenzen ergeben sich aus der Wahl eines offenen Austauschformats gegenüber nativen Dateien. Erstens behält der Bauherr ein lesbares Modell, nachdem die Lizenz eines Planers ausgelaufen ist, dieser den Anbieter gewechselt hat oder nicht mehr verfügbar ist: Eine IFC-Datei öffnet sich noch Jahre später in kostenlosen Viewern, während eine native Datei aus einer aufgegebenen Lizenz sich möglicherweise gar nicht mehr öffnen lässt. Zweitens kann jede Disziplin weiterhin das Werkzeug verwenden, das sie tatsächlich beherrscht, weil IFC die gemeinsame Sprache zwischen ihnen ist – und nicht ein gemeinsames Programm.

Dies ist auch die Voraussetzung für einen brauchbaren Bestandsplan: Ein IFC-Export des koordinierten Modells, zusammen mit den Plänen, ist etwas, das ein zukünftiger Wartungsunternehmer öffnen kann, ohne etwas besitzen oder lizenzieren zu müssen.

Was geht beim Austausch häufig schief – und wie wird es erkannt?

Der wiederkehrende Fehler ist keine korrupte Datei, sondern eine stille Diskrepanz: Einheiten, die in Millimetern exportiert und in Metern importiert werden, eine Eigenschaft, die das sendende Tool nie gemappt hat, sodass die empfangende Seite ein leeres Feld sieht, oder ein geometrischer Detaillierungsgrad, der für eine Kollisionsprüfung zu grob ist. Keiner dieser Fehler löst einen Fehler aus; sie tauchen erst später auf – als ein Leitungsstrang, der im Koordinationsmodell „nicht vorhanden" ist, oder eine Brandschutzklasse, die als „nicht gesetzt" angezeigt wird.

Die Lösung ist prozessualer Natur: Jemand öffnet die exportierte Datei unabhängig von dem Werkzeug, das sie erstellt hat, und prüft sie anhand einer kurzen Checkliste (Ursprung, Einheiten, Geschossanzahl, einige bekannte Maße) – dieselbe Disziplin, die hinter einer ordentlichen Level of Development-Deklaration steht.

Wo steht der IFC-Austausch im gesamten Koordinationsprozess?

Austausch ist der Mechanismus, nicht das Ziel. Er ist das, was die BIM-Koordination zwischen getrennt lizenzierten Disziplinen überhaupt erst ermöglicht: Ohne ihn hat die Kollisionsprüfung nichts Gemeinsames zu testen, und eine gemeinsame Datenumgebung hat keine neutrale Datei, die sie aufnehmen kann. Die Einstellungen, die Versionswahl und die Prüfroutine einmal frühzeitig richtig festzulegen, ist das, was jeden späteren Schritt mit Daten versorgt, die tatsächlich jeder öffnen kann.