Open BIM oder Closed BIM: Welcher Workflow nützt der Statik?

Das Architekturmodell lässt sich zwar öffnen, aber die Stützen sind keine Stützen im statischen Sinn, die Decken tragen keine klaren Lastflächen, und eine Wand besteht aus mehreren Schichten, deren Tragwirkung erst einmal niemand definiert hat.

Die Debatte um Open BIM versus Closed BIM in der Tragwerksplanung wird deshalb häufig an der falschen Stelle geführt. Nicht das Dateiformat entscheidet, ob ein Austausch funktioniert. Entscheidend ist, ob alle Beteiligten vorher geklärt haben, welche Information zu welchem Zeitpunkt in welcher Qualität geliefert wird — und wer feststellt, dass sie fehlt. Ein glänzendes 3D-Modell ersetzt diese Vereinbarung nicht. Es kaschiert sie höchstens besser.

Die Realität der BIM-Kollaborationsmodelle: weniger Ideologie, mehr Übergabepunkt

Closed BIM bezeichnet einen Austausch innerhalb einer proprietären Softwarelandschaft. Architektur, Tragwerksplanung, Ausführung oder Konstruktion arbeiten dabei möglichst mit Programmen eines Herstellers oder mit Formaten, die speziell aufeinander abgestimmt sind. Das kann im Alltag sehr effizient sein: Geometrien, Attribute und Änderungen werden mit weniger Übersetzungsschritten übergeben. Wer ein Modell innerhalb derselben Produktfamilie weiterreicht, reduziert eine Fehlerquelle — aber eben nur diese eine.

Open BIM setzt dagegen auf offene Standards, vor allem auf IFC. Das Ziel ist nachvollziehbar: Die Zusammenarbeit soll nicht daran scheitern, dass ein Projektbeteiligter eine andere Software verwendet. In einem Bauprojekt mit Architektur, Tragwerksplanung, TGA, Fertigteilwerk, Stahlbau, Prüfstatik und Bauherrschaft ist das keine akademische Freiheit, sondern die normale Ausgangslage.

Beide Modelle haben ihren Platz. Problematisch wird es, wenn aus einer technischen Entscheidung ein Glaubenssatz wird.

Wer versucht, ein Architekturmodell aus einer proprietären Umgebung in die Statik zu übernehmen, stellt schnell fest: Auch ohne IFC kann die Übergabe fachlich unbrauchbar sein. Ein Bauteil mit der Bezeichnung „Stütze“ ist noch keine Stütze, die als vertikales Stabelement im Berechnungsmodell angesetzt werden kann. Es kann eine Verkleidung sein, ein Einbauteil, ein Verbundquerschnitt oder schlicht ein zu grob modelliertes Volumenelement.

Umgekehrt ist IFC kein digitaler Paketbote, der Verantwortung für den Inhalt übernimmt. IFC ist eine strukturierte Sprache für Bauwerksinformationen. Ob die Beteiligten darin präzise sprechen, bleibt ihre Aufgabe.

Open oder Closed ist keine Qualitätsstufe. Es beschreibt den Weg der Daten — nicht ihre Tragfähigkeit.

Die eigentliche Frage lautet daher nicht: „Welches System ist besser?“ Sondern: An welchem Übergabepunkt soll welche Information ohne manuelle Nacharbeit nutzbar sein? Für die Tragwerksplanung ist das ein engeres und zugleich anspruchsvolleres Ziel als der allgemeine Wunsch nach „einem gemeinsamen Modell“.

Informationsanforderungen: Der Vertrag beginnt vor dem Export

In vielen Projekten wird die Modellprüfung erst dann ernst genommen, wenn die erste Datei auf dem Server liegt. Dann fehlen Geschosszuordnungen, Materialbezeichnungen, Bauteilklassifikationen oder eindeutige Namen. Die Reaktion lautet oft: „Das kann man doch nachtragen.“ Kann man. Nur ist das dann kein digitaler Prozess mehr, sondern Nachmodellierung unter Zeitdruck.

Die Auftraggeber-Informationsanforderungen, kurz AIA, sind deshalb kein Dokument für die Ablage. Sie definieren Art, Umfang, Struktur und Qualität der Informationen, die im Projekt benötigt werden. Daraus entsteht nach Vertragsabschluss der BIM-Abwicklungsplan: Er konkretisiert, wer welche Modelle wann liefert, nach welchen Regeln sie geprüft werden und welche Übergaben verbindlich sind.

ISO 19650-1:2018 beschreibt hierfür den Rahmen des Informationsmanagements über den gesamten Lebenszyklus eines Bauwerks. Die Norm ist keine Bedienungsanleitung für eine bestimmte Software und schreibt auch kein bestimmtes Dateiformat vor. Das ist kein Mangel, sondern Absicht. Ein Krankenhaus, eine Brücke und ein mehrgeschossiger Wohnungsbau brauchen nicht dieselbe Informationsdichte, nur weil alle drei ein 3D-Modell haben.

Für die Tragwerksplanung müssen die Anforderungen jedoch deutlich konkreter werden als das übliche „Modell bitte als IFC liefern“. Eine brauchbare AIA beantwortet mindestens diese Fragen:

• Welches Fachmodell wird übergeben? Ein Koordinationsmodell ist etwas anderes als ein Strukturmodell, ein Bewehrungsmodell etwas anderes als ein Modell für die Vorbemessung.
• Welcher Bearbeitungsstand gilt? Entwurf, Genehmigungsplanung, Ausführungsplanung und Revision dürfen nicht in derselben Datei-Logik verschwimmen.
• Welche Bauteile müssen fachlich auswertbar sein? Bei Decken, Unterzügen, Stützen, Wänden und Rampen zählen nicht nur Abmessungen, sondern auch Funktion, Material, Tragwerksbezug und eindeutige Zuordnung.
• Welche Attribute sind verpflichtend? Name, Typ, Material und Geschoss sind keine dekorativen Metadaten. Ohne sie wird aus dem Modell ein Suchspiel.
• Wie werden Änderungen kenntlich gemacht? Eine neue Datei mit fast gleichem Namen ist keine Versionsstrategie. Gerade bei Lastabtrag und Auflagerbedingungen kann eine kleine geometrische Änderung große Folgen haben.
• Wer prüft welche Ebene? Formale Vollständigkeit, geometrische Konsistenz und statische Plausibilität sind drei verschiedene Prüfaufgaben.

Im AIA-Beispiel für Bundesbauten wird für das Fachmodell Tragwerksplanung IFC4 in der Version 4.0.2.1 genannt. Für Geschossdecken, Rampen, Stützen und Träger sind dort unter anderem Bauteiltyp, Maße, Material, Name und Funktion als Informationsmerkmale hinterlegt. Das klingt zunächst banal. In der Praxis trennt genau diese Banalität ein Modell, das weiterverarbeitet werden kann, von einem Modell, das nur gut aussieht.

Die Diskussion über Vorteile von Open BIM beginnt also nicht bei IFC, sondern bei der Informationsvereinbarung. Fehlt sie, wird die Offenheit des Formats zur Offenheit der Auslegung. Und das ist im Tragwerk eine denkbar schlechte Betriebsart.

IFC ist kein Zauberformat — aber ein belastbares technisches Rückgrat

IFC hat sich über mehrere Generationen entwickelt. IFC 2x3 stammt aus dem Jahr 2005 und ist in vielen Bestandsprozessen noch präsent. IFC4 folgte 2013, IFC4 ADD2 TC1 2018. Die aktuelle offizielle Fassung ist IFC 4.3.2.0, meist IFC 4.3 genannt; sie wurde als ISO 16739-1:2024 veröffentlicht.

Diese Versionsgeschichte ist kein Detail für Normensammler. Sie erklärt einen der häufigsten Konflikte in Projekten: „Wir liefern doch IFC“ sagt wenig, wenn nicht festgelegt ist, welche IFC-Version, welche Exportkonfiguration und welche Modellansicht verwendet wird. Ein Export aus IFC2x3 und ein Export aus IFC4.3 können dieselbe Geometrie zeigen, aber unterschiedliche Informationsmöglichkeiten und Zuordnungen transportieren. Dazu kommt die praktische Ebene: Nicht jedes Autorenprogramm exportiert jedes Merkmal gleich, und nicht jede Statiksoftware interpretiert jede Entität identisch.

Softwareinteroperabilität ist daher kein Schalter mit den Stellungen „an“ und „aus“. Sie besteht aus einer Kette von Entscheidungen:

1. Das Autorenmodell muss Bauteile fachlich sauber klassifizieren.

2. Der Export muss die vereinbarte IFC-Version und die benötigten Eigenschaften enthalten.

3. Das empfangende System muss diese Entitäten sinnvoll lesen können.

4. Die Tragwerksplanung muss entscheiden, welche Teile in ein Rechenmodell überführt werden dürfen.

5. Das Ergebnis muss gegen das Quellmodell und gegen die statische Logik geprüft werden.

Bricht eines dieser Glieder, ist nicht automatisch IFC schuld. Manchmal liegt der Fehler im Export. Manchmal in einer unklaren Modellierungsregel. Manchmal erwartet die empfangende Software etwas, das das Architekturmodell nie liefern sollte. Und manchmal ist die Erwartung selbst fachlich falsch.

Ein Datenaustausch ist erst gelungen, wenn die empfangende Disziplin damit arbeiten kann — nicht wenn eine Datei ohne Fehlermeldung geöffnet wurde.

Für Closed BIM gilt derselbe Maßstab. Eine direkte Schnittstelle zwischen zwei Programmen desselben Herstellers kann hervorragende Ergebnisse liefern, wenn die Fachmodelle sauber aufgebaut sind und die Versionen zusammenpassen. Sie kann aber ebenso Attribute verlieren, Bauteile falsch zuordnen oder Änderungen unklar übergeben. Die proprietäre Kette ist kürzer; sie ist nicht automatisch intelligent.

Das Architekturmodell ist nicht das statische Modell

Hier scheitern die meisten überzogenen Erwartungen an die Digitalisierung. Das Architekturmodell beschreibt das Bauwerk räumlich. Es enthält Wandaufbauten, Fassaden, Beläge, abgehängte Decken, Öffnungen, Schächte, Geländesprünge und eine Menge sinnvoller Informationen für Entwurf, Koordination und Mengenermittlung. Für eine Berechnung ist diese Detailfülle aber nicht automatisch hilfreich.

Die Statik benötigt ein idealisiertes Struktur- oder Analysemodell. Stäbe werden auf Systemlinien zurückgeführt. Flächentragwerke erhalten eine statisch wirksame Ebene. Auflager werden definiert, Exzentrizitäten bewusst angesetzt oder bewusst vernachlässigt. Gelenke, Einspannungen, Lasten und Steifigkeiten müssen als Berechnungsannahmen formuliert werden. Das ist keine Datenlücke, die man mit einem besseren Export schließen könnte. Es ist Ingenieurarbeit.

Ein Beispiel aus dem üblichen Geschossbau: Eine Stahlbetondecke wird im Architekturmodell oft mit Aufbau, Estrich, Dämmung, Belag, Unterdecke und Aussparungen geführt. Für das Berechnungsmodell muss zunächst feststehen, welche Ebene die tragende Platte repräsentiert, welche Dicke statisch wirkt, wie der Lastabtrag an Wänden und Unterzügen erfolgt und ob Öffnungen, Deckensprünge oder Randbereiche modellrelevant sind. Die Geometrie kann dabei sehr ähnlich aussehen. Die Bedeutung ist eine andere.

Bei Wänden wird es noch deutlicher. Eine architektonische Wand kann tragend, aussteifend, nichttragend oder nur raumbildend sein. Sie kann aus mehreren Schichten bestehen, an einer Stelle durchlaufen und an anderer Stelle auf einer Decke enden. Die statische Frage lautet nicht nur: Wo steht die Wand? Sie lautet: Welche Scheibenwirkung wird angesetzt, wie erfolgt die Lagerung, welche Lasten werden übertragen und welche konstruktiven Randbedingungen begrenzen die Annahme?

Die IFC-Entität IfcStructuralAnalysisModel ist dafür vorgesehen, ein statisches Analysemodell zusammenzustellen. Sie kann Tragglieder, Lager oder Anschlüsse, Einwirkungen und Berechnungsergebnisse referenzieren. Das ist ein wichtiger Baustein — aber kein Ersatz für die Entscheidung, wie ein reales Bauwerk idealisiert wird.

Wer versucht, den Übergang vollständig zu automatisieren, stößt daher schnell auf die entscheidende Grenze: Das Programm kann Beziehungen übertragen. Es kann nicht zuverlässig beurteilen, ob eine Modellierung statisch sinnvoll ist. Eine Wand, die in der Architektur sauber an eine Decke stößt, kann im Rechenmodell trotzdem eine ungewollte Lagerung erzeugen. Ein Unterzug kann geometrisch vorhanden sein und statisch dennoch nicht dort wirken, wo die Systemlinie ihn verortet. Ein Millimeter Versatz ist im Modell kaum sichtbar, im Lastpfad aber plötzlich sehr laut.

Für einen belastbaren Workflow sollte die Übergabe deshalb in Stufen erfolgen:

• Koordinationsmodell prüfen: Sind Achsen, Geschosse, Geometrien und Bauteilzuordnungen nachvollziehbar?
• Strukturmodell ableiten: Welche Bauteile tragen tatsächlich, und welche Informationen müssen dafür ergänzt oder bereinigt werden?
• Analysemodell aufbauen: Wo liegen Systemlinien, Flächenebenen, Lagerungen, Gelenke und Lastansätze?
• Rückkopplung organisieren: Welche Anpassungen betreffen die Architektur, welche nur das Rechenmodell, und wie werden Konflikte sichtbar gemacht?
• Änderungen kontrollieren: Bei jeder neuen Modellversion muss klar sein, ob sich nur Oberflächen geändert haben oder der Lastabtrag.

Das klingt weniger spektakulär als der vollautomatische Knopfdruck. Es ist dafür ein Workflow, der eine Prüfung überlebt.

IDS 1.0: Maschinenlesbare Anforderungen, aber keine digitale Prüfstatik

Mit IDS 1.0 steht inzwischen ein endgültiger Standard zur Verfügung, um Anforderungen an IFC-Modelle maschinenlesbar zu beschreiben und automatisiert zu prüfen. IDS kann festlegen, welche Objekte vorhanden sein müssen, welche Klassifikationen, Materialien, Eigenschaften und Werte erwartet werden. Für die Tragwerksplanung ist das ausgesprochen nützlich.

Man kann beispielsweise definieren, dass alle tragenden Stützen eine eindeutige Kennung, ein Material, eine Geschosszuordnung und einen bestimmten Bauteiltyp tragen müssen. Ebenso lassen sich Anforderungen für Träger, Decken oder Wände formulieren. Die Modellprüfung wird dadurch reproduzierbar: Statt bei jeder Übergabe per Sichtkontrolle nach fehlenden Attributen zu suchen, lässt sich die formale Informationsqualität automatisiert abgleichen.

Das ist ein echter Fortschritt, weil er eine bislang teure Routinearbeit aus dem Prozess nimmt. Aber auch hier lohnt sich eine nüchterne Grenzziehung. IDS prüft keine Geometrie. Es prüft keine Kollisionsfreiheit. Es entscheidet nicht, ob eine Decke richtig gelagert ist, ob eine aussteifende Wand im richtigen System angesetzt wurde oder ob die Lastweiterleitung plausibel bleibt.

Ein Modell kann also jede IDS-Prüfung bestehen und statisch trotzdem problematisch sein. Das ist keine Schwäche des Standards. Es wäre nur eine Schwäche der Erwartung, wenn man aus einer Attributprüfung eine Tragwerksprüfung machen wollte.

Sinnvoll eingesetzt, trennt IDS zwei Dinge sauber voneinander: Erst wird geprüft, ob die vereinbarte Information vorhanden und korrekt strukturiert ist. Danach prüft der Tragwerksplaner, ob diese Information im konkreten Bauwerk fachlich richtig interpretiert wird. Der erste Schritt ist automatisierbar. Der zweite bleibt Verantwortung.

Die richtige Entscheidung fällt projektweise, nicht im Grundsatz

Für kleine Teams mit dauerhaft gleichen Werkzeugen kann ein geschlossener Workflow sinnvoll sein. Wenn Architektur und Tragwerksplanung auf abgestimmten Anwendungen arbeiten, die Austauschwege getestet sind und die Projektarten vergleichbar bleiben, spart die direkte Übergabe Zeit. Allerdings nur, solange die Kette nicht an der Fachplanungsgrenze endet. Spätestens bei externen Fachmodellen, Prüfprozessen, Fertigteilplanung oder einem Betreiber mit eigenen Datenanforderungen wird die proprietäre Komfortzone kleiner.

Open BIM ist dort stark, wo verschiedene Beteiligte langfristig verlässlich zusammenarbeiten müssen, ohne dass alle dieselbe Software einsetzen. IFC schafft dafür eine gemeinsame technische Grundlage. Der Preis ist nicht unbedingt höherer Aufwand, sondern höherer Klärungsbedarf am Anfang. Wer diesen Aufwand spart, zahlt später mit manueller Bereinigung, Rückfragen und Modellständen, die niemand mehr sicher auseinanderhalten kann.

Die pragmatische Entscheidung lässt sich deshalb so zusammenfassen:

• Closed BIM eignet sich für eng gekoppelte, getestete Prozessketten mit stabiler Softwarelandschaft.
• Open BIM eignet sich für heterogene Projektteams und definierte Übergaben über Organisations- und Herstellergrenzen hinweg.
• Für die Tragwerksplanung ist in beiden Fällen ein separates, fachlich verantwortetes Analysemodell notwendig.
• AIA, BIM-Abwicklungsplan, Versionsregeln und Prüfverfahren sind wichtiger als das Etikett auf dem Austauschweg.
• IFC4 oder IFC4.3 sind kein Selbstzweck. Entscheidend ist, dass das vereinbarte Ziel mit den tatsächlich eingesetzten Programmen geprüft funktioniert.

Die Wahl zwischen Open BIM und Closed BIM ist damit keine Entscheidung zwischen Freiheit und Komfort. Sie ist eine Entscheidung darüber, wo ein Projekt seine Abhängigkeiten akzeptiert und wie es Übergaben kontrolliert. Tragwerksplanung braucht dabei keine digitale Ideologie. Sie braucht belastbare Bauteilinformationen, nachvollziehbare Modellstände und einen Übergang vom Bauwerksmodell zum Rechenmodell, der nicht auf Hoffnung basiert.

Das ist weniger glänzend als die Softwarefolie. Im Projekt ist es meistens der Unterschied zwischen einer Datei und einem funktionierenden Prozess.