BIM-Schnittstellen in der Statik: Datenverlust vermeiden

Die Folge ist eine manuelle Nacharbeit, die im Projektbudget nicht eingeplant war. Schätzungen aus der Praxis beziffern den Anteil der Schnittstellenkorrektur an den gesamten Planungskosten mit bis zu 20 Prozent. Die Zahl betrifft sowohl die Neuerfassung von Daten als auch die Nacharbeit im Modell. Die Reduktion dieses Anteils erfordert eine bewusste Wahl der Schnittstelle. Die Trennung der Fachmodelle ist organisatorisch erforderlich. Die Trennung darf keine Datenverluste verursachen.

Das IFC-Format: Standard mit begrenzter Reichweite

IFC (Industry Foundation Classes) bildet seit 1994 den offenen Standard für den softwareunabhängigen Austausch von Bauwerksmodellen. buildingSMART definiert das Schema. Die Schemata IFC2x3 und IFC4 sind verbreitet. Der Standard dient der Koordination zwischen Fachplanern. Architektur, Haustechnik und Tragwerksplanung referenzieren ein gemeinsames Modell.

Der Transfer eines physischen Modells aus einem CAD-System in ein Berechnungsprogramm gelingt nur teilweise. Die Hürde liegt in der unterschiedlichen Interpretation der Modellinhalte durch die jeweilige Software. Ein physisches Koordinationsmodell beschreibt Bauteile mit ihrer realen Geometrie. Ein Berechnungsmodell erfordert eine Idealisierung: Stäbe statt Volumen, Linienlager statt Flächenlager, Materialzuweisung statt Bauteilbeschreibung.

IFC transportiert beide Welten. Der Transport erfolgt über separate Sichten. Die Model View Definitions (MVDs) trennen die Inhalte nach Verwendungszweck. Der Coordination View liefert die physische Beschreibung. Der Structural Analysis View liefert die ideale Form für die Statik. Der Wechsel zwischen beiden Sichten erfolgt über ein Mapping. Dieses Mapping erfordert eine vorherige Definition der Bauteil-Entitäten und ihrer Sachdaten. Fehlende oder falsche Zuordnungen führen zu Datenverlust.

Die Struktur von IFC folgt einer objektorientierten Logik. Jedes Bauteil erhält eine Klasse (IfcBeam, IfcColumn, IfcSlab) und eine eindeutige Kennung (GUID). Die Eigenschaften der Klasse werden über Property-Sets ergänzt. Die Kombination aus Klasse und Property-Sets bildet die Grundlage der Interpretation durch die Zielsoftware.

Structural Analysis Format: Spezialisierung für die Tragwerksanalyse

Die Übertragung von Berechnungs- und Analysemodellen verlangt ein eigenes Format. SAF (Structural Analysis Format) wurde 2017 als offene Initiative gestartet. SAF basiert auf Excel. Die tabellarische Struktur erlaubt eine verlustfreie Übertragung aller relevanten Analysedaten.

SAF überträgt Stäbe, Flächen, Lager, Baustoffe, Querschnitte, Lasten und Lastfälle. Die Übertragung erfolgt verlustfrei. Das Format dient nicht als physisches Koordinationsmodell. SAF ersetzt IFC nicht, sondern ergänzt es.

Die Trennung folgt einer Logik: IFC eignet sich für die Koordination der Fachmodelle. SAF eignet sich für den Transfer der Statik-Modelle zwischen Programmen wie RFEM, RSTAB, SCIA oder SOFiSTiK. Die Anwendung von SAF verlangt zwei Schritte: Export des Berechnungsmodells aus dem Quellprogramm, Import der SAF-Datei in das Zielprogramm. Diese Schritte entfallen die Notwendigkeit eines manuellen Neuaufbaus. Eine erneute Modellierung kostet Zeit und erzeugt Inkonsistenzen zwischen den Programmen.

IFC koordiniert das Gebäude. SAF transportiert die Statik. Die Trennung der Formate folgt der Logik der Aufgabe.

Die Spezialisierung von SAF bringt Grenzen mit sich. Das Format enthält keine Architekturinformationen. Die visuelle Kontrolle am 3D-Modell gelingt nur im Quell- oder Zielprogramm. SAF dient dem Datenaustausch, nicht der Koordination am Modell.

MVDs und das Mapping-Problem

Model View Definitions steuern, welche Informationen ein IFC-Subset enthält. Der Structural Analysis View definiert eine Auswahl an Entitäten, die für die Statik relevant sind. Die Definition einer MVD entlastet die Schnittstelle nicht von der Interpretation. Verschiedene Softwarehersteller implementieren die MVD unterschiedlich. Die Konsequenz ist eine Abweichung zwischen exportiertem und importiertem Modell.

Typische Fehlerquellen beim IFC-Transfer:

• Abweichende Geometrieinterpretation durch den Viewer zwischen CAD- und Statiksoftware
• Falsche Zuordnung von IFC-Entity zu Bauteil (etwa IfcMember statt IfcBeam)
• Fehlende Übertragung von Exzentrizitäten, Gelenken oder Federn an Auflagern
• Verlust von Lastkombinationen, Lastfällen und Lastwerten
• Einheitenkonflikte zwischen metrischem und imperialem System
• Inkonsistente Materialzuweisung zwischen Architekturmodell und Berechnungsmodell

Die Korrektur erfolgt manuell. Die Korrekturkosten summieren sich über ein Projekt. Die Fehleranfälligkeit steigt mit der Komplexität des Modells.

Das Mapping zwischen physischem und analytischem Modell verlangt eine vorherige Klassifikation der Bauteile. Ein Stützträger aus Stahlbeton erfordert im Coordination View eine IfcColumn-Entität. Im Structural Analysis View erfordert derselbe Träger eine IfcStructuralMember-Entität mit der korrekten Querschnittsdefinition. Die Transformation zwischen beiden Klassen erfolgt über ein Mapping-Tool oder eine Konfigurationsdatei.

Die Kosten der Schnittstelle

Der Austausch zwischen CAD und Statik gehört zu den zeitintensivsten Vorgängen in der Tragwerksplanung. Die Trennung der Fachmodelle ist organisatorisch erforderlich. Architekt und Tragwerksplaner arbeiten in unterschiedlichen Systemen. Die Schnittstelle verbindet beide Welten.

Die Kosten der Schnittstelle setzen sich aus mehreren Komponenten zusammen:

Die Reduktion dieser Kosten erfordert eine bewusste Wahl der Schnittstelle. IFC dient der Koordination. SAF dient der Analyse. Die Kombination beider Formate im Workflow reduziert die Verluste. Die digitale Durchgängigkeit erfordert eine Rückführung der Ergebnisse. Berechnete Schnittgrößen, Verformungen und Ausnutzungsgrade müssen in das physische Modell zurückfließen. IFC transportiert diese Ergebnisse über Property-Sets. Die Zuordnung der Ergebnisse zu den Bauteilen erfolgt über die GUID.

Strategien zur Fehlervermeidung beim Import

Die Qualität des Datenaustauschs hängt von der Vorbereitung ab. Die folgenden Punkte strukturieren die Vorbereitung eines Imports in die Statiksoftware:

1. Definition des Analyseziels vor dem Export. Die Frage nach der Tragwerksidealisierung (Stabwerk, Finite-Elemente-Modell, Membrantragwerk) bestimmt die Wahl der MVD oder des Formats.

2. Prüfung der Entitäten und Sachdaten vor dem ersten Export. Die Bauteil-Klassifikation in IFC muss der Tragwerkslogik entsprechen. IfcMember für Stützen, IfcBeam für Träger, IfcSlab für Flächen.

3. Verwendung von SAF für den reinen Statik-Transfer zwischen Berechnungsprogrammen. SAF erhält alle Analysedaten verlustfrei.

4. Versionskontrolle der IFC-Schemata. IFC2x3 und IFC4 sind nicht kompatibel. Die Konvertierung erfordert Zwischenschritte oder spezielle Konverter.

5. Pilotprojekt vor dem Produktiveinsatz. Der Import eines Testmodells deckt Mapping-Fehler vor dem Echtprojekt auf.

6. Dokumentation der Mapping-Regeln. Die Konsistenz zwischen Projekten erfordert dokumentierte Standards.

7. Plausibilitätsprüfung nach dem Import. Die Summe der Auflagerreaktionen muss dem Gesamtlastbild entsprechen. Die Massenverteilung muss mit der Statik übereinstimmen.

8. Rückkopplung der Ergebnisse. Die berechneten Schnittgrößen fließen über Property-Sets zurück in das Architekturmodell. Die Rückkopplung erfordert eine konsistente GUID-Verwaltung.

Die Schnittstelle ist kein neutraler Datenkanal. Sie übersetzt zwischen zwei Welten. Die Übersetzung kostet Genauigkeit, wenn die Regeln nicht definiert sind.

Die Position des Tragwerksplaners

Die digitale Durchgängigkeit verlangt eine aktive Rolle des Planers. Die Schnittstelle reagiert nicht auf Wünsche. Die Schnittstelle verarbeitet definierte Eingaben. Der Tragwerksplaner definiert die Regeln. Er prüft die Übereinstimmung zwischen übertragenem und erwartetem Modell. Er trägt die Verantwortung für die Korrektur.

Die Wahl zwischen IFC und SAF ist keine Glaubensfrage. Es ist eine Frage des Anwendungsfalls. Die Koordination mehrerer Fachmodelle erfordert IFC. Der Transfer von Analysemodellen zwischen Statikprogrammen erfordert SAF. Die Kombination beider Formate bildet den Workflow der digitalen Tragwerksplanung.

Die Praxis zeigt eine Tendenz zur Spezialisierung. IFC bleibt der Standard der Koordination. SAF etabliert sich als Standard der Analyse. Die beiden Standards ergänzen sich. Die parallele Nutzung erfordert Disziplin bei der Modellpflege. Die Disziplin entscheidet über die Qualität der Schnittstelle. Die Schnittstelle entscheidet über die Effizienz der Planung. Die Effizienz entscheidet über die Wettbewerbsfähigkeit des Büros.

Die Investition in saubere Mapping-Regeln amortisiert sich über die Projektlaufzeit. Die Nacharbeit am Modell verschwindet. Die Plausibilitätsprüfung am importierten Modell verkürzt sich. Die Freigabe der Berechnung erfolgt schneller. Die Qualität der Statik steigt durch die Konzentration auf die Analyse statt auf die Datenpflege.