IFC-Datenaustausch in der Statik: Was ist zu beachten?

In der Tragwerksplanung endet dieses Versprechen oft an einer Stelle, die im Viewer völlig harmlos aussieht: Ein Unterzug liegt sauber unter der Decke, die Stütze trifft den Knoten, die Geschosse stimmen. Beim Import in das Statikprogramm fehlen dann Querschnittswerte, Achsen sind versetzt, Lager werden zu dekorativen Symbolen oder Lastfälle verschwinden still im Hintergrund.

Das Problem ist selten die IFC-Datei allein. IFC ist kein magischer Container, der aus einem Architekturmodell automatisch ein prüfbares Berechnungsmodell macht. Wer IFC-Datenaustausch in der Tragwerksplanung ohne Fehler organisieren will, muss vor dem Export klären, welche Information wofür gebraucht wird, wie sie im Zielsystem ankommt und wer den Inhalt fachlich prüft. Das klingt weniger spektakulär als ein bunter Digital Twin. Es spart aber genau die Stunden, die später im Modellvergleich, in Excel-Listen und in hektischen Telefonaten verschwinden.

Ein IFC-Modell kann geometrisch überzeugend aussehen und statisch dennoch unbrauchbar sein. Sichtbarkeit ist kein Qualitätsnachweis.

Erst den Austauschzweck festlegen, dann über IFC-Versionen sprechen

Die übliche Frage lautet: „Exportieren wir IFC2x3 oder IFC4?“ Das ist nicht falsch, aber sie kommt zu früh. Vorher steht eine andere Frage: Was soll der Empfänger mit dem Modell tatsächlich tun?

Soll der Tragwerksplaner das Architekturmodell lediglich als räumliche Referenz nutzen, braucht es eine andere Informationsdichte als bei einer teilautomatisierten Übernahme von Stützen, Wänden, Decken und Öffnungen in ein Analysemodell. Und wer erwartet, dass ein Fachmodell nach Änderungen wieder parametrisch in die Autorenanwendung zurückläuft, verfolgt noch einmal einen anderen Workflow.

Die internationale Norm ISO 16739-1:2024 beschreibt das aktuelle IFC-Datenschema. Sie wurde am 22. März 2024 veröffentlicht. Das Schema allein beantwortet aber nicht, welche Teilmenge davon in einem konkreten Projekt transportiert wird. Genau dafür gibt es Model View Definitions, kurz MVD. Eine MVD legt fest, welche Geometrien, Klassen, Beziehungen und Eigenschaften für einen bestimmten Austauschfall geliefert werden müssen.

Für die Koordination ist etwa die IFC4 Reference View sinnvoll: Das Modell wird zur Prüfung, Auswertung und Abstimmung übergeben. Es ist im Kern ein Einbahnstraßen-Workflow. Der Empfänger darf analysieren, kommentieren und Änderungsbedarf zurückmelden, soll das IFC-Modell aber nicht umarbeiten und als vermeintlich gleichwertige Rücklieferung zurückspielen. Das ist kein Mangel der Schnittstelle, sondern eine saubere Rollenverteilung.

Problematisch wird es, wenn Projektbeteiligte diese Trennung ignorieren. Dann wandert ein exportiertes Referenzmodell durch mehrere Programme, wird dort „ein wenig“ bearbeitet und später wieder exportiert. Am Ende weiß niemand mehr, welches Modell die fachliche Quelle ist. Das ist kein Open-BIM-Workflow, sondern Daten-Pingpong mit Haftungsrisiko.

Die Konsequenz ist pragmatisch: Im BIM-Abwicklungsplan oder in einer projektspezifischen Austauschvereinbarung müssen mindestens IFC-Version, Modellansicht, Austauschzweck, Lieferzeitpunkt und Verantwortlichkeiten stehen. Noch wichtiger ist die Aussage, was ausdrücklich nicht geliefert wird. Wenn keine Lastkombinationen, keine Lagerdefinitionen und keine FE-Modellierung vereinbart sind, darf später niemand überrascht sein, dass sie fehlen.

Geometrie ist nur die halbe Wahrheit

Wer versucht, ein Architekturmodell direkt in ein Statikprogramm zu exportieren, stellt schnell fest: Die Bauteilform ist meist das kleinere Problem. Ein Rechteck bleibt ein Rechteck. Schwieriger wird es bei der Bedeutung dieses Rechtecks.

Eine Wand kann im Architekturmodell eine Raumbegrenzung, eine Brandschutzanforderung oder eine tragende Scheibe sein. Eine Decke kann als sichtbare Platte modelliert sein, aber aus statischer Sicht aus mehreren Bereichen mit unterschiedlichen Dicken, Spannrichtungen und Auflagerbedingungen bestehen. Eine Stütze kann geometrisch auf einer Decke stehen, während ihre statische Achse bewusst exzentrisch geführt werden muss. IFC trennt deshalb zu Recht Geometrie und Semantik: Bauteilklasse, Typ, Eigenschaften, Material, Beziehungen und geometrische Repräsentation sind verschiedene Ebenen.

Genau an dieser Stelle entstehen die meisten Fehler im Datentransfer zwischen Architektur und Statik. Nicht weil jemand „falsch exportiert“ hat, sondern weil die Zuordnung zwischen Autorenmodell, IFC-Eigenschaften und Zielsystem nicht festgelegt wurde. Das sogenannte Property-Mapping ist die unspektakuläre, aber zentrale Arbeit.

Ein belastbares Mapping beantwortet beispielsweise:

• Welche Architekturbauteile als tragend gelten und wie diese Kennzeichnung im Modell erfolgt.
• Welche IFC-Klassen verwendet werden: etwa Wand, Platte, Stütze, Träger oder ein projektspezifisch definierter Bauteiltyp.
• Wo Materialangaben, Betonfestigkeitsklassen, Stahlgüten, Querschnitte und Bauteildicken stehen.
• Wie Tragwerksachsen, Bezugslinien, Exzentrizitäten und lokale Koordinatensysteme übergeben oder dokumentiert werden.
• Welche Öffnungen und Durchbrüche als echte geometrische Aussparung vorliegen und welche nur grafisch angedeutet wurden.
• Welche Eigenschaften als verbindlich gelten und welche aus dem Architekturmodell lediglich informativen Charakter haben.

Die unangenehme Wahrheit: Ein Property Set mit dem Namen Pset_Statik löst noch kein Problem. Entscheidend ist, ob Inhalt, Einheit, Datentyp und Zuordnung konsistent sind. „C30/37“ kann ein sauber interpretierbarer Materialwert sein. Es kann aber auch als Freitext in einem Feld stehen, das beim Export nicht vorgesehen ist und im Zielsystem als leere Information endet. Der Name wirkt dann sehr digital, die Datenqualität bleibt analog-chaotisch.

Auch die geometrische Repräsentation verdient Aufmerksamkeit. Für eine Referenznutzung genügt oft ein Oberflächenmodell. Soll ein Bauteil in einer anderen Autorenanwendung weiterbearbeitet werden, reichen rein explizite Oberflächenbeschreibungen jedoch nur begrenzt. Änderbare Geometrie braucht eher implizite Beschreibungen wie Extrusionen, Sweeps oder boolesche Operationen. Das ist kein akademischer Unterschied. Es entscheidet darüber, ob ein Bauteil im Zielsystem als bearbeitbares Objekt ankommt oder als geometrisches Fossil.

IFC 4.3 kann Analyseinformationen abbilden – aber keine Statik verantworten

IFC4.3 erweitert den Blick über die reine Bauwerksgeometrie hinaus. Mit IfcStructuralAnalysisModel lassen sich Analysemodelle strukturieren: tragende Stäbe und Flächen, Lager und Verbindungen, Einwirkungen, Lastgruppen, Lastfälle, Lastkombinationen sowie Kraft- und Verschiebungsergebnisse gehören grundsätzlich zum vorgesehenen Umfang.

Das ist relevant, weil der Austausch damit nicht zwangsläufig bei der Frage enden muss, ob eine Wand 20 oder 24 Zentimeter dick ist. Allerdings beginnt hier auch die Zone, in der Marketingfolien gerne zu viel versprechen.

Ein IFC-Strukturanalysemodell verlangt eine konsistente Topologie. Werden Strukturelemente innerhalb eines Analysemodells zusammengefasst, müssen sie dieselbe Objektplatzierung wie die gemeinsame Platzierung des Analysemodells verwenden. Klingt nach einem Detail aus dem Schema. Im Alltag ist es ein Schutz vor einem sehr realen Fehlerbild: Knoten, Achsen und Lastangriffspunkte liegen nach dem Import nicht dort, wo sie fachlich hingehören, obwohl das Bauwerksmodell optisch korrekt erscheint.

Ein weiteres Detail zeigt, wie ernst man Datenpräzision nehmen muss: Bei einer Lastgruppe ist der Lastfaktor als Coefficient hinterlegt. Auch der Wert 1,0 soll ausdrücklich exportiert werden. Fehlt der Wert, bedeutet das nicht automatisch „eins“, sondern zunächst: nicht bekannt oder nicht festgelegt. Software kann damit unterschiedlich umgehen. Wer sich auf implizite Standardannahmen verlässt, überlässt dem Importer eine statische Entscheidung. Das ist ungefähr so charmant wie ein Auflager, das nur „wahrscheinlich“ gelenkig ist.

Gleichzeitig hat IFC4.3 klar benannte Grenzen. Nicht vollständig im Geltungsbereich des Strukturanalysebereichs liegen:

1. Dynamische Analysen. Erdbeben-, Schwingungs- oder komplexe dynamische Nachweise lassen sich nicht pauschal als vollständig austauschbarer IFC-Standardprozess behandeln.

2. Vorspannung und Vorspannlasten. Gerade bei anspruchsvollen Betontragwerken ist das keine Randnotiz, sondern eine wesentliche Modell- und Nachweisfrage.

3. FE-Topologie und detaillierte Netze. Die konkrete Diskretisierung ist Teil der Berechnungslogik des jeweiligen Statiksystems und kein neutraler Beipackzettel.

4. Detaillierte Spannungs- und Dehnungsergebnisse. Ergebnisse können strukturiert übergeben werden, aber die vollständige Tiefe eines programmspezifischen FE-Auswerteprozesses ist nicht allgemein standardisiert.

IFC transportiert Informationen. Die fachliche Entscheidung, welches Rechenmodell daraus entsteht, bleibt beim Tragwerksplaner.

Daraus folgt keine Absage an IFC, sondern eine vernünftige Arbeitsteilung. Das Architekturmodell liefert belastbare Ausgangsdaten. Das Tragwerksmodell wird daraus kontrolliert entwickelt. Für einfache, wiederkehrende Bauteile kann diese Übernahme weit automatisiert sein. Bei komplexen Anschlüssen, aussteifenden Systemen, nichtlinearen Effekten oder Sonderbauweisen bleibt sie ein fachlicher Modellierungsprozess. Ein Importknopf ist kein Prüfingenieur.

IDS verschiebt die Prüfung nach vorn

Lange Zeit bestand die Qualitätskontrolle eines IFC-Exports aus zwei Schritten: Datei öffnen, drehen, bunt anschauen. Das erkennt grobe Geometriefehler. Es erkennt aber nicht zuverlässig, ob alle tragenden Wände die vereinbarte Klassifikation besitzen, ob Stützen ein Material zugewiesen haben oder ob die geforderte Eigenschaft für die Konstruktionsart tatsächlich vorhanden ist.

Die Information Delivery Specification, IDS, setzt genau dort an. IDS v1.0 ist seit dem 4. Juni 2024 ein endgültiger buildingSMART-Standard. Sie beschreibt Informationsanforderungen maschinenlesbar und ermöglicht eine automatisierte Prüfung von IFC-Modellen: Objektarten, Klassifikationen, Materialien, Eigenschaften und Werte können gegen vereinbarte Regeln geprüft werden.

Das ist kein Ersatz für die Ingenieurprüfung. Aber es trennt maschinell prüfbare Vollständigkeit von fachlicher Plausibilität – und diese Trennung ist im Alltag Gold wert.

Eine sinnvolle IDS-Prüfung für einen Architektur-zu-Statik-Export könnte zum Beispiel verlangen, dass:

• alle als tragend markierten Stützen eine eindeutige Bauteilklasse, Materialangabe und Querschnittsinformation tragen;
• tragende Wände als Wandobjekte vorliegen und nicht als allgemeine Modellobjekte oder Volumenkörper;
• Deckenbereiche ihre Dicke, Tragwerksrelevanz und Geschosszuordnung besitzen;
• Öffnungen in tragenden Bauteilen als echte Öffnungselemente oder nachvollziehbare Geometrie vorliegen;
• projektspezifische Kennzeichnungen für Tragwirkung, Bauabschnitt oder Umbauzustand in definierten Eigenschaften abgelegt sind;
• Einheiten und zulässige Wertebereiche eindeutig geregelt sind.

Der entscheidende Punkt: IDS funktioniert nur dann gut, wenn die Anforderungen vorher fachlich formuliert wurden. „Das Modell soll vollständig sein“ ist keine prüfbare Anforderung. „Jede tragende Stahlbetonstütze benötigt Materialfestigkeit, Querschnittsbreite, Querschnittstiefe und Tragwerkskennzeichnung“ dagegen schon.

Wer erst nach dem ersten fehlerhaften Import anfängt, diese Regeln zu formulieren, nutzt IDS als Reparaturwerkzeug. Besser ist es als Gate vor der Übergabe einzusetzen. Dann bleibt der Fehler beim Erzeuger, dort, wo er mit überschaubarem Aufwand korrigiert werden kann.

Der funktionierende Workflow beginnt vor dem ersten Export

Ein belastbarer Open-BIM-Workflow im Tragwerk entsteht nicht durch die Installation eines Viewers. Er entsteht durch eine Abfolge kleiner, nachvollziehbarer Entscheidungen. Die meisten davon sind nicht glamourös. Gerade deshalb werden sie gerne übersprungen.

1. Referenzmodell und Berechnungsmodell sauber unterscheiden

Das Architekturmodell ist die räumliche und konstruktive Referenz. Das Berechnungsmodell ist eine abstrahierte technische Interpretation. Diese Modelle dürfen eng gekoppelt sein, sie müssen aber nicht identisch sein.

Eine Unterzugachse kann im Rechenmodell mittig geführt werden, obwohl die sichtbare Geometrie verspringt. Eine Decke kann für die Berechnung in Teilflächen zerlegt werden. Ein Wandpfeiler kann statisch anders idealisiert werden als architektonisch modelliert. Wer Identität verlangt, erzeugt entweder ein unhandliches Rechenmodell oder ein unzureichendes Architekturmodell. Beides hilft niemandem.

2. Einen Pilotexport nicht als Formalität behandeln

Vor dem ersten großen Liefertermin braucht es einen kleinen, repräsentativen Testfall: ein Geschoss, typische Wand- und Deckensituationen, Stützen, Unterzüge, Öffnungen und wenigstens eine kompliziertere Anschlusszone. Dieser Export wird im Zielsystem importiert und nicht nur visuell begutachtet.

Zu prüfen sind dabei unter anderem Bauteilanzahl, Klassen, Achslagen, Höhenbezüge, Abmessungen, Materialwerte, Querschnitte und Öffnungsgeometrien. Für Knotenanschlüsse und Achsversätze gibt es keine universelle Millimetertoleranz, die man blind aus einem Handbuch kopieren könnte. Die Toleranz muss projektspezifisch vereinbart werden: abhängig von Tragwerk, Modellierungsrichtlinie und den beteiligten Programmen.

3. Änderungen nicht über Dateinamen verwalten

Statik_final_neu_letzteVersion_03.ifc ist keine Versionsstrategie. Bei jeder Lieferung muss eindeutig sein, welche Modellrevision vorliegt, welchen Bearbeitungsstand sie abbildet und welche Änderungen gegenüber der vorherigen Übergabe enthalten sind.

Für die Koordination reichen häufig klar referenzierte Modelle und strukturierte Änderungsanforderungen. Für die Tragwerksplanung ist zusätzlich relevant, ob eine Änderung nur Geometrie betrifft oder die Systemannahme verändert: Wand verschoben, Deckenöffnung ergänzt, Stütze entfällt, Material wechselt, Bauzustand ändert sich. Nicht jede Änderung ist gleich groß, auch wenn sie im Viewer gleich klein aussieht.

4. Den Import fachlich freigeben

Der Importbericht eines Programms ist hilfreich, aber nicht ausreichend. „1.248 Elemente erfolgreich importiert“ sagt noch nichts darüber aus, ob die 1.248 Elemente richtig interpretiert wurden. Der Tragwerksplaner muss das übernommene Modell gegen die Planungsabsicht prüfen: Lastabtrag, Lagerung, Aussteifung, Achsbezüge, Systemgrenzen und wesentliche Querschnitte.

Das ist kein Misstrauensvotum gegen die Architektur. Es ist die normale Qualitätssicherung an einer Schnittstelle, an der zwei Fachmodelle unterschiedliche Zwecke erfüllen.

Die häufigsten Fehler liegen nicht im Format, sondern in den Erwartungen

Bei BIM-Schnittstellen in der Statik wird IFC oft entweder überschätzt oder vorschnell abgeschrieben. Beides ist bequem. Beides verhindert Verbesserung.

IFC ist stark, wenn es um transparente, softwareübergreifende Übergaben von Geometrie, Bauteilsemantik und definierten Informationen geht. Es ist besonders nützlich, wenn Modelle geprüft, koordiniert und langfristig nachvollziehbar gehalten werden sollen. Mit klarer MVD, dokumentiertem Property-Mapping und automatisierter IDS-Prüfung wird aus einer Datei ein kontrollierbarer Datentransfer.

IFC ist schwach oder zumindest nicht ausreichend spezifiziert, wenn man erwartet, dass jede Berechnungsentscheidung, jede Dynamik, jede Vorspannung und jedes FE-Netz verlustfrei zwischen beliebigen Programmen wandert. Das ist keine Niederlage des Standards. Es ist eine Erinnerung daran, dass Tragwerksplanung mehr ist als Bauteile in 3D.

Der robuste Weg ist deshalb erstaunlich unspektakulär: Austauschzweck definieren, Modellanforderungen konkret formulieren, einen Pilotexport prüfen, Mapping dokumentieren, IDS als Qualitätsgate einsetzen und die fachliche Verantwortung nicht an einen Importdialog delegieren. Weniger Magie, mehr Workflow. Im Bauwesen ist das meistens die verlässlichere Innovation.