IFC4 oder IFC2x3: Welches Format nutzt der Statiker?

Spätestens beim ersten Import in die Statik wird daraus oft ein deutlich weniger glamouröses Ticket im Supportsystem: Stützen kommen ohne Profil an, Lastfälle bleiben draußen, Öffnungen verlieren ihre Zuordnung oder ein sauber modelliertes Bauteil wird zum geometrischen Fremdkörper ohne statische Bedeutung.

Die Frage „IFC4 oder IFC2x3 in der Tragwerksplanung?“ ist deshalb falsch gestellt, zumindest wenn sie allein stehen bleibt. Das Schema ist nur ein Teil der Vereinbarung. Entscheidend ist, welche Information von welchem Programm für welchen Anwendungsfall in welcher Richtung übertragen werden soll. Wer das nicht festlegt, bestellt keinen Datenaustausch, sondern eine Wundertüte mit Dateiendung.

IFC ist kein universeller Speicherknopf

IFC soll den offenen BIM-Datenaustausch ermöglichen. Das ist sinnvoll, gerade zwischen Architektur, Tragwerksplanung und TGA, deren Programme selten aus derselben Produktfamilie stammen. Aber IFC ist kein neutraler Klon eines Autoren- oder Statikmodells. Es ist ein standardisiertes Übergabeformat mit definierten Objekten, Beziehungen, Eigenschaften und Geometrien.

Schon hier beginnt die Verwechslung: Ein Tragwerksmodell ist nicht automatisch ein Berechnungsmodell.

Im Fachmodell können eine Decke, ein Unterzug und eine Stütze geometrisch plausibel, sauber klassifiziert und für die Kollisionsprüfung bestens geeignet sein. Für die Statik fehlen dann trotzdem Dinge, ohne die keine Berechnung entsteht:

• die tatsächlich wirksame Systemachse statt der Sichtgeometrie;
• Lagerbedingungen und Gelenke;
• exzentrische Anschlüsse;
• Querschnittsdefinitionen in der vom Berechnungsprogramm verstandenen Struktur;
• Materialien mit berechnungsrelevanten Kennwerten;
• Lasten, Lastkombinationen und Lastfälle;
• die Entscheidung, welches Bauteil tragend, aussteifend, aufgehängt oder schlicht nur Ausbau ist.

Das ist kein Fehler des IFC-Formats. Es ist eine Eigenschaft der Aufgabe. Architektur modelliert zunächst einen Baukörper. Tragwerksplanung modelliert ein mechanisches System. Beide Modelle dürfen zusammenpassen; sie müssen aber nicht identisch sein. Wer versucht, ein Architekturmodell per Export in ein fertiges Rechenmodell zu verwandeln, stellt schnell fest: Die Lücke zwischen Bauteilgeometrie und statischem Modell ist keine Schnittstelle, sondern Ingenieurarbeit.

Ein IFC kann ein sehr gutes Referenzmodell sein. Es ersetzt aber weder die Systembildung noch die Verantwortung für sie.

Die Versionsnummer ist nur die halbe Nachricht

IFC2x3 ist nicht „alt und damit schlecht“. IFC4 ist nicht „neu und damit automatisch richtig“. Beide Formate sind offizielle IFC-Versionen. IFC2x3 entspricht der Release-Version 2.3.0.1, IFC4 der Version 4.0.2.1. Mit IFC4.3 liegt inzwischen die aktuelle offizielle Version 4.3.2.0 vor, veröffentlicht als ISO 16739-1:2024.

Diese Reihenfolge erzählt aber noch nichts darüber, ob ein konkreter Austauschweg funktioniert.

IFC4.3 bringt einen erheblich erweiterten Datenumfang mit: mehr als 1.300 Entitäten und Typen sowie rund 2.500 Eigenschaften in über 750 Eigenschaftssätzen. Das ist für Infrastruktur, komplexere Fachmodelle und langfristige Standardisierung relevant. Für den Alltag einer Hochbau-Statik hilft diese Vielfalt allerdings wenig, wenn das empfangende Programm genau den benötigten Teil nicht sauber importiert. Mehr Schema ist nicht automatisch mehr Workflow.

Die belastbare Frage lautet daher nicht: „Kann Ihre Software IFC4?“ Sondern:

1. Welche exakte IFC-Version exportiert das Quellprogramm?

2. Welche Model View Definition wird dabei verwendet?

3. Welche Bauteile, Beziehungen und Eigenschaften kommen tatsächlich an?

4. Welche davon kann das Zielprogramm nicht nur lesen, sondern fachlich korrekt weiterverarbeiten?

5. Ist der Austausch nur einseitig als Referenzmodell gedacht oder soll ein bearbeitbares Modell entstehen?

6. Wurde der Weg mit der konkreten Softwareversion und den realen Projektbauteilen getestet?

Die letzte Frage wird erstaunlich oft übersprungen. Stattdessen diskutiert man vierzig Minuten über Open BIM und merkt erst nach dem Modellversand, dass die gewählte Exportoption keine Profile, keine Ebenenstruktur oder keine tragwerksrelevanten Attribute übergibt. Das Modell sieht dann im Viewer gut aus. Im Statikprogramm ist es trotzdem nur Dekoration mit Koordinaten.

Die MVD entscheidet, was die Datei überhaupt leisten soll

Eine IFC-Version beschreibt das Schema, also den möglichen Datenraum. Die Model View Definition, kurz MVD, beschreibt dagegen, welcher Teil davon für einen konkreten Austauschfall genutzt werden soll. Ohne MVD bleibt „IFC4“ ungefähr so präzise wie „wir bauen aus Beton“.

Eine brauchbare Austauschvorgabe benennt daher mindestens Schema und MVD, etwa IFC2x3 Coordination View 2.0 oder IFC4 Reference View 1.2. Erst damit wird klarer, ob das Modell zur Koordination, zur Mengenprüfung, zur Sichtprüfung oder zur Übertragung bestimmter Fachinformationen dienen soll.

Die Tabelle enthält bewusst kein Feld „beste Wahl“. Das beste Format gibt es nur im Kontext eines Anwendungsfalls.

Coordination View: robust, verbreitet, aber keine Statik-Automatik

Die IFC2x3 Coordination View 2.0 ist eine finale MVD und weiterhin die am häufigsten verwendete Definition für Fachkoordination. Sie dient dem Austausch räumlicher und physischer Komponenten zwischen Architektur, Tragwerk und TGA. Für Referenzmodelle, Prüfungen, Auswertungen und Koordinationsrunden ist sie ein bewährter Nenner.

Das Wort „bewährt“ ist hier wichtiger als manche Versionsdebatte. In gemischten Projektlandschaften mit unterschiedlichen Autorenprogrammen, Prüfwerkzeugen und Fachmodellen ist IFC2x3 häufig der Weg mit den wenigsten Überraschungen. Nicht, weil es technisch alle Wünsche erfüllt, sondern weil die beteiligten Werkzeuge diesen Austauschweg seit Jahren kennen.

Für die Tragwerksplanung bedeutet das: Ein IFC2x3-Modell kann hervorragend geeignet sein, um Achsraster, Geschosse, tragende Bauteile, Öffnungen und relevante Geometrien gegen das eigene Modell zu prüfen. Es ist aber nicht automatisch geeignet, daraus ein prüffähiges Berechnungsmodell zu erzeugen.

Die gefährliche Abkürzung lautet: „Die Stütze ist im IFC, also ist sie auch in der Statik.“ Nein. Sie kann im IFC als geometrisches Objekt vorhanden sein und trotzdem keine verwertbare Querschnittslogik, keine korrekte Lage zur Systemachse oder keine Information über die tatsächliche Lastabtragung besitzen.

Reference View: bewusst einseitig

IFC4 Reference View 1.2 ist ebenfalls eine finale MVD. Sie zielt auf vereinfachte geometrische und relationale Referenzmodelle für die Fachkoordination. Typische Anwendungen sind Kollisionsprüfungen, Mengenabzüge und visuelle Kontrollen.

Das wichtige Wort lautet: Referenz.

Ein Reference-View-Modell ist dafür gedacht, gelesen und geprüft zu werden. Es ist nicht als Einladung zu einem verlustfreien Hin-und-zurück zwischen Programmen gebaut. Der Empfänger soll es nicht verändern und anschließend wieder in die ursprüngliche Fachlogik zurückspielen. Das ist keine Einschränkung, die man mit Optimismus wegmoderieren kann, sondern der definierte Charakter dieses Workflows.

Gerade im BIM-Datenaustausch der Tragwerksplanung ist das oft die vernünftigste Lösung. Die Architektur liefert ein belastbares Referenzmodell. Die Tragwerksplanung entwickelt daraus ihr eigenes Fach- und Berechnungsmodell. Änderungen werden über klar definierte Modellstände, BCF-Themen oder fachliche Rückmeldungen koordiniert. Weniger elegant auf Folien, aber wesentlich kontrollierbarer in der Praxis.

Ein Modellrundlauf klingt effizient, bis die erste Fachsoftware aus einem intelligenten Bauteil eine hübsche, aber bedeutungslose Geometrie macht.

Structural Analysis View: fachlich passend, praktisch nicht selbstverständlich

Für die Übergabe von Analysemodellen gibt es mit der IFC2x3 Structural Analysis View eine finale MVD. Sie ist genau für den Fall formuliert, dass ein in einer Tragwerksplanungsanwendung erzeugtes Analysemodell an eine oder mehrere Anwendungen zur Tragwerksanalyse übergeben wird.

Übertragbar sein können dabei unter anderem:

• statisch relevante Bauteile und ihre analytische Repräsentation;
• Lagerpunkte und Randbedingungen;
• Querschnitte;
• Materialien;
• Lasten.

Das liest sich wie die Lösung für jeden Import zwischen Modellierungs- und Berechnungssoftware. Ist es aber nicht. Eine finale Spezifikation bedeutet, dass die MVD standardisiert beschrieben ist. Sie bedeutet nicht, dass jede Software sie vollständig implementiert, sauber exportiert, zuverlässig importiert und über mehrere Bearbeitungsschritte stabil erhält.

Hier trennt sich Standardisierung von Produktrealität. Ein Hersteller kann IFC2x3 importieren und dabei primär Coordination View meinen. Ein anderer kann Analyseinformationen schreiben, aber nur in einer bestimmten Exportkonfiguration. Ein dritter liest das Modell, erzeugt jedoch aus bestimmten Bauteiltypen keine nutzbaren Stabelemente oder Flächenelemente. Auf dem Papier sprechen alle IFC. Im Projekt sprechen sie unter Umständen aneinander vorbei.

Deshalb gehört ein Analysemodell-Workflow nicht in eine allgemeine BIM-Präsentation, sondern in einen Testfall. Und zwar nicht mit einem isolierten Rechteckraum, sondern mit dem, was später Probleme macht: geneigten Stützen, Wand-Decken-Knoten, Unterzügen mit Versatz, Öffnungen, auskragenden Bauteilen, unterschiedlichen Materialien und denjenigen Lastannahmen, die tatsächlich übergeben werden sollen.

Warum IFC4 Design Transfer kein Freifahrtschein ist

Beim IFC4 Design Transfer View liegt die Versuchung nahe: Der Name verspricht Übertragung von Entwurfsinformationen, also endlich einen hochwertigeren digitalen Übergabekanal. Der Status ist jedoch entscheidend. Diese MVD wird als Entwurf geführt, nicht als finale Definition.

Sie zielt auf eine weitergehende, aber weiterhin einseitige Übertragung von Modellinformationen und Verantwortung zwischen Werkzeugen. Ein allgemeiner verlustfreier Rundlauf ist damit ausdrücklich nicht beschrieben. Wer daraus eine universelle Bearbeitungsschnittstelle ableitet, liest mehr in den Namen hinein, als die Spezifikation hergibt.

Das ist keine Kritik an IFC4. Es ist eine Kritik an der verbreiteten Gewohnheit, Produktankündigungen, Schema-Versionen und echte Projektfähigkeit in einen Topf zu werfen. Der Topf heißt dann „Digitalisierung“. Heraus kommt im Zweifel ein Nachmodellierauftrag.

Wo IFC4 in der Tragwerksplanung tatsächlich sinnvoll sein kann

IFC4 hat reale Stärken. Es bietet eine modernere Grundlage, differenziertere Modellierungs- und Eigenschaftsmöglichkeiten und ist in vielen Auftraggeberanforderungen zunehmend präsent. In einem veröffentlichten AIA-Praxisbeispiel für Bundesbauten ist für das Fachmodell Tragwerksplanung beispielsweise IFC4 in der Version 4.0.2.1 festgelegt. Für Decken, Rampen, Stützen und Träger sind dort zugleich Informationsanforderungen nach LOIN hinterlegt.

Der entscheidende Punkt ist nicht die Version 4.0.2.1 allein. Der entscheidende Punkt ist, dass die Version dort in ein Anforderungssystem eingebettet ist: Anwendungsfälle, Informationsbedarf, Bauteilanforderungen und dokumentierte Regeln gehören zusammen.

IFC4 ist in der Tragwerksplanung dann eine gute Wahl, wenn der Projektkontext diese Fragen sauber beantwortet:

• Der Auftraggeber oder die AIA verlangen IFC4 in einer konkret benannten Version.
• Die geforderte MVD passt zum tatsächlichen Zweck: Referenz, Koordination, Mengen, Übergabe oder Analyse.
• Autoren-, Prüf- und Empfängersoftware wurden in ihren eingesetzten Versionsständen getestet.
• Die Modellierungsrichtlinie definiert Bauteilklassifikationen, Ebenen, Attribute und Geometrieregeln.
• Der Informationsumfang ist über LOIN oder vergleichbare Festlegungen konkret beschrieben.
• Es gibt einen festgelegten Prüfprozess mit Verantwortlichkeiten und Rückmeldeweg.

Ohne diesen Rahmen bleibt der behauptete IFC4-Vorteil abstrakt. Dann exportiert man vielleicht ein moderneres Schema, aber keine bessere Information.

AIA und BAP: Der Workflow beginnt vor dem ersten Export

Die IFC-Schnittstelle der Statik wird nicht durch einen Knopf im Exportdialog stabil. Sie wird durch Projektvereinbarungen stabil. AIA und BAP sind dabei keine Verwaltungsschleife für BIM-Beauftragte, sondern die Stelle, an der sich entscheidet, ob die Fachplanung später Daten nutzen kann.

In den Auftraggeber-Informationsanforderungen sollte stehen, wofür Modelle geliefert werden. Nicht nur: „Abgabe als IFC4“. Sondern beispielsweise: Koordination der Tragstruktur mit Architekturmodell, Prüfung von Deckendurchbrüchen, Abgleich von Stützenlagen, Mengenermittlung oder Übergabe definierter Analyseinformationen.

Der BIM-Abwicklungsplan übersetzt das anschließend in einen funktionierenden Prozess. Für die Tragwerksplanung gehören dort konkrete Festlegungen hinein:

1. Lieferobjekte und Modellstände: Welches Fachmodell wird zu welchem Meilenstein bereitgestellt? Ist es ein Referenzmodell, ein Koordinationsmodell oder ein Modell mit weitergehenden Informationsanforderungen?

2. Schema und MVD: Nicht nur IFC4 oder IFC2x3 nennen, sondern die genaue Version und die vorgesehene Sichtdefinition. „IFC4“ ohne MVD ist keine ausreichend präzise Schnittstellenvereinbarung.

3. Bauteilmodellierung: Wie werden tragende Wände, nichttragende Wände, Unterzüge, Stützen, Deckenränder, Fundamente und Öffnungen klassifiziert? Welche Bauteile sind im Architekturmodell für die Statik verbindlich, welche nur geometrische Vorplanung?

4. Informationsumfang: Welche Attribute braucht die Tragwerksplanung tatsächlich? Materialbezeichnung, Feuerwiderstand oder Bauteil-ID können wertvoll sein. Ein Attributfriedhof mit hundert uneinheitlich gefüllten Feldern ist hingegen kein Mehrwert, sondern Datenmüll mit Herkunftsnachweis.

5. Export- und Importeinstellungen: Diese sind software- und versionsabhängig. Sie müssen dokumentiert werden, weil sie oft darüber entscheiden, ob Profile, lokale Koordinatensysteme, Eigenschaftssätze oder Öffnungen korrekt ankommen.

6. Prüfung und Abnahme: Wer prüft was, mit welchem Werkzeug und gegen welche Erwartung? Eine Sichtprüfung allein reicht nicht. Ein Modell kann geometrisch stimmig aussehen und fachlich unbrauchbare Zuordnungen enthalten.

Gerade der letzte Punkt verdient mehr Aufmerksamkeit. Der IFC-Export ist kein Abschluss, sondern ein Übergabeschritt. Die relevante Frage lautet nicht: „Datei erzeugt?“ Die relevante Frage lautet: „Ist die vereinbarte Information im Zielsystem fachlich brauchbar angekommen?“

Der pragmatische Maßstab: getestete Übergabe statt Formatglauben

Es gibt keinen allgemeinen Grundsatz, nach dem Statiker immer IFC4 oder immer IFC2x3 nutzen sollten. Es gibt Projektanforderungen, Softwarelandschaften und Austauschziele. Daraus ergibt sich eine Wahl, nicht aus dem Alter einer Versionsnummer.

IFC2x3 Coordination View 2.0 bleibt für viele Koordinationsprozesse ein belastbarer Standard. IFC4 Reference View 1.2 ist sinnvoll, wenn ein kontrolliertes, einseitiges Referenzmodell gefragt ist. Die Structural Analysis View beschreibt einen fachlich passenden Weg für Analysemodelle, muss aber in der konkreten Programmkette nachgewiesen werden. Und IFC4.3 mag der aktuelle offizielle Stand sein – für einen laufenden Hochbau-Workflow ist das allein noch kein Argument, die etablierte Schnittstelle umzubauen.

Die reife Entscheidung wirkt von außen oft unspektakulär: ein klarer Anwendungsfall, eine präzise MVD, dokumentierte Einstellungen, ein Testmodell und ein geprüfter Import. Kein digitales Feuerwerk. Dafür weniger verlorene Profile, weniger manuelle Nacharbeit und weniger Diskussionen darüber, warum die Datei „doch eigentlich offen“ sein sollte.

In der Tragwerksplanung ist das die bessere Definition von Fortschritt.