IFCLint
Registrieren
Lektion 2.18 min Lesezeit

Was bedeutet openBIM?

openBIM heisst: Zusammenarbeit über offene, herstellerneutrale Formate. Diese Lektion zeigt, was das im Projektalltag konkret bedeutet, wo die Grenzen liegen und warum es nicht nur um Dateiformate geht.

KonstrukteureIngenieureBIM-KoordinatorenBIM-Manager

Lernziel

Nach dieser Lektion kannst du erklären, was openBIM als Ansatz ausmacht, worin der Unterschied zum Austausch über native Formate liegt und welche Rolle buildingSMART dabei spielt. Du kannst einschätzen, wann offener Austausch einem Projekt tatsächlich hilft — und wo seine Grenzen liegen.

Praxisproblem

Im Kick-off sagt jemand den Satz: „Wir arbeiten sowieso alle mit derselben Software. Dann brauchen wir IFC gar nicht."

Klingt vernünftig. Hält meistens bis zur ersten Vergabe.

Dann kommt der Tragwerksplaner mit einem anderen Werkzeug ins Team. Die Haustechnik arbeitet ohnehin in ihrer Fachplattform. Der Bauherr will die Modelle in fünf Jahren noch öffnen können, ohne dafür Lizenzen zu verlängern, die er sonst nicht braucht. Und der Betreiber übernimmt das Bauwerk in eine Facility-Management-Umgebung, die mit dem Autorenformat nichts anfangen kann.

Was im Kick-off wie eine Vereinfachung aussah, ist zwei Jahre später eine Abhängigkeit. Nicht dramatisch, aber teuer — weil jede Übergabe eine kleine Übersetzung braucht, und weil manche Information bei jeder Übersetzung verloren geht.

Genau an dieser Stelle setzt openBIM an.

1. Der Kern in einem Satz

openBIM beschreibt die Zusammenarbeit in Bauprojekten über offene, herstellerneutrale Datenformate und Prozesse.

Das Wort „offen" meint dabei zwei Dinge, die oft verwechselt werden. Erstens: Die Formate sind dokumentiert und frei verfügbar. Jeder Softwarehersteller kann sie unterstützen, ohne eine Lizenz zu erwerben oder um Erlaubnis zu bitten. Zweitens: Die Formate gehören keinem einzelnen Unternehmen. Sie werden von buildingSMART International gepflegt, einer herstellerunabhängigen Organisation, in der Softwarehersteller, Planungsbüros, Bauherren und Forschungseinrichtungen zusammenarbeiten.

Der Unterschied zu einem nativen Format ist damit weniger technisch als organisatorisch. Ein natives Format kann technisch hervorragend sein. Aber wer es lesen darf und wie lange es unterstützt wird, entscheidet der Hersteller — nicht das Projekt.

2. Was openBIM im Alltag konkret heisst

Austausch über native Formate im Vergleich zu openBIM Links: fünf Fachdisziplinen tauschen direkt untereinander aus, es entstehen zehn Verbindungen und damit zehn mögliche Fehlerquellen. Rechts: dieselben fünf Disziplinen liefern in ein gemeinsames offenes Format in der Mitte, es entstehen nur fünf Verbindungen. Austausch über native Formate Jede Verbindung braucht eine eigene Übersetzung Architektur Tool A Tragwerk Tool B HLK Tool C Sanitär Tool D Elektro Tool E 10 Übersetzungswege Austausch über offene Formate Alle liefern in dasselbe dokumentierte Format IFC IDS · BCF Architektur Tool A Tragwerk Tool B HLK Tool C Sanitär Tool D Elektro Tool E 5 Lieferwege Der Gewinn ist nicht, dass IFC perfekt wäre — sondern dass alle über denselben Zwischenstand reden.

Ohne offene Formate braucht jede Verbindung zwischen zwei Werkzeugen ihre eigene Übersetzung. Bei drei Beteiligten sind das noch überschaubare Wege. Bei sechs Fachplanern wird daraus ein Geflecht, das niemand mehr vollständig überblickt — und in dem jede einzelne Verbindung eine mögliche Fehlerquelle ist.

Mit offenen Formaten liefert jedes Werkzeug in dasselbe Format. Die Anzahl der Übersetzungen sinkt, und die verbleibenden sind dokumentiert. Das ist der eigentliche Gewinn: nicht dass IFC perfekt wäre, sondern dass alle über denselben Zwischenstand reden.

openBIM ist dabei mehr als ein Dateiformat. Es umfasst auch, wie Anforderungen formuliert werden, wie Probleme am Modell gemeldet werden und wie Begriffe projektübergreifend einheitlich benannt werden. Die dazugehörigen Standards heissen IDS, BCF und bSDD — wir sehen sie uns in den kommenden Lektionen einzeln an.

3. Warum das für Bauwerke besonders zählt

Software hat Versionszyklen von Jahren. Bauwerke haben Lebenszyklen von Jahrzehnten.

Dieses Missverhältnis ist der stärkste Grund für offene Formate. Ein Modell, das heute in einem Autorenformat der Version 2026 vorliegt, ist in zwanzig Jahren möglicherweise nicht mehr ohne Weiteres lesbar. Ein IFC-Modell hat bessere Chancen — nicht weil es unzerstörbar wäre, sondern weil die Struktur öffentlich dokumentiert ist und im Zweifel rekonstruiert werden kann.

Dazu kommt die Vergabesituation. Wer Modelle nur in einem einzigen Autorenformat annimmt, schränkt den Kreis möglicher Anbieter ein. Für öffentliche Auftraggeber ist das oft nicht nur unpraktisch, sondern vergaberechtlich heikel. Offene Formate halten den Wettbewerb offen.

Und schliesslich der Betrieb. Facility-Management-Systeme sind selten dieselben Werkzeuge wie die Planungssoftware. Ohne offene Übergabeformate wird aus jeder Bauwerksübergabe ein Datenmigrationsprojekt.

4. Was openBIM nicht bedeutet

Hier lohnt sich Genauigkeit, weil sich um openBIM einige Missverständnisse gebildet haben.

openBIM heisst nicht, dass die Wahl der Software egal wäre. Sie ist es nicht. Wie gut ein Werkzeug IFC schreibt und liest, unterscheidet sich erheblich — und diese Unterschiede merkt man im Projekt sehr deutlich. Ein Werkzeug, das saubere Klassifikationen und vollständige Property Sets exportiert, spart dem ganzen Team Arbeit. Gute Werkzeuge sind für openBIM wichtiger, nicht unwichtiger.

openBIM heisst auch nicht, dass native Formate verschwinden. Innerhalb einer Disziplin arbeitet man weiterhin im Autorenwerkzeug, mit allen Vorteilen der nativen Umgebung. Der offene Austausch beginnt dort, wo Disziplinen, Firmen oder Projektphasen aufeinandertreffen.

Und openBIM heisst nicht, dass ein IFC-Export am Projektende genügt. Wenn die erste Übergabe drei Wochen vor der Abgabe stattfindet, ist der Zeitpunkt für Korrekturen vorbei. Offener Austausch entfaltet seinen Wert nur, wenn er regelmässig stattfindet.

5. Die Grenzen, ehrlich benannt

Wer openBIM als Allheilmittel verkauft, tut ihm keinen Gefallen.

Der Export in ein offenes Format ist eine Übersetzung, und Übersetzungen sind verlustbehaftet. Parametrik geht verloren, manche Beziehungen zwischen Bauteilen werden vereinfacht, herstellerspezifische Konstrukte finden keine direkte Entsprechung. Für die meisten Anwendungsfälle ist das kein Problem — für einige schon.

Die Qualität der Umsetzung schwankt zudem zwischen Werkzeugen. Zwei Programme können dieselbe IFC-Version unterstützen und trotzdem unterschiedliche Ergebnisse liefern. buildingSMART arbeitet mit Zertifizierungsprogrammen gegen dieses Problem, aber es ist nicht vollständig gelöst.

Daraus folgt eine praktische Konsequenz: Offene Formate ersetzen keine Prüfung. Ein IFC-Modell kann in jedem Viewer sauber aussehen und trotzdem die vereinbarten Informationsanforderungen verfehlen. In der Praxis werden solche Prüfungen mit spezialisierten IFC- und IDS-Werkzeugen durchgeführt. IFCLint ist ein Beispiel für einen browserbasierten Ansatz, bei dem Anforderungen, Modellprüfung und Berichte in einem Workflow zusammenkommen.

6. Beispiel: Zwei Wege durch dasselbe Projekt

Ein Verwaltungsgebäude mit vier Fachplanern. Zwei Varianten, wie der Modellaustausch organisiert wird.

Variante A, nativ. Alle liefern in ihrem Autorenformat. Der BIM-Koordinator hält für jede Kombination eine Übersetzungsroutine bereit. Solange das Team stabil bleibt, funktioniert das. Als in der Ausführungsphase ein Fachplaner wechselt, muss der Koordinator eine neue Route aufbauen — und stellt fest, dass die Brandschutzangaben auf dem neuen Weg anders ankommen als vorher.

Variante B, offen. Alle liefern zusätzlich zum nativen Arbeitsstand ein IFC-Modell nach vereinbarter Struktur, alle zwei Wochen. Der Wechsel des Fachplaners betrifft die Lieferstrecke nicht, weil die Anforderung am Format hängt und nicht an der Software. Die Brandschutzangaben werden bei jeder Lieferung geprüft — Abweichungen fallen innerhalb von Tagen auf, nicht Monaten.

Variante B ist in der Einrichtung aufwendiger. Sie ist robuster gegenüber allem, was sich in zwei Jahren Projektlaufzeit ändern kann. Und das ist erfahrungsgemäss einiges.

7. Typische Fehler

  1. openBIM erst am Projektende einführen. Ein IFC-Export drei Wochen vor Abgabe erfüllt eine Vertragsklausel, aber er bringt dem Projekt nichts.
  2. Offene Formate mit fehlender Prüfung verwechseln. Der Export ist die halbe Strecke. Ohne Prüfung gegen die vereinbarten Anforderungen ist unklar, ob die Lieferung brauchbar ist.
  3. Struktur der Lieferung nicht vereinbaren. „Liefert IFC" reicht nicht. Welche Version, welche Klassifikation, welche Pflicht-Properties, welcher Detaillierungsstand — das gehört in die Vereinbarung.
  4. Native Formate als überholt darstellen. Sie sind das Arbeitswerkzeug der Disziplin. Der offene Austausch kommt an den Schnittstellen dazu, nicht statt ihnen.
  5. Von einem Export auf alle schliessen. Werkzeuge exportieren unterschiedlich gut. Wer den Export eines Werkzeugs kennt, kennt nicht den aller anderen im Team.
  6. Betriebsanforderungen ignorieren. Was der Betreiber später braucht, entsteht in der Planung — oder gar nicht.

8. Mini-Checkliste

Bevor der Modellaustausch in einem Projekt festgelegt wird, prüfe:

  • Ist vereinbart, in welchem offenen Format und in welcher Version geliefert wird?
  • Ist die Struktur der Lieferung beschrieben — Klassifikation, Pflicht-Properties, Detaillierungsstand?
  • Steht ein Rhythmus für den Austausch fest, oder wird nur am Meilenstein geliefert?
  • Wird jede Lieferung gegen die vereinbarten Anforderungen geprüft?
  • Ist geklärt, was der Betreiber am Ende braucht?
  • Können alle Beteiligten das vereinbarte Format in ausreichender Qualität erzeugen?

Sind drei oder mehr Punkte mit „Nein" beantwortet, steht zwar openBIM im Vertrag, aber der Nutzen ist noch nicht abgesichert.

9. Reflexionsfrage

Denk an ein Projekt, in dem Modelle zwischen Beteiligten ausgetauscht wurden. Wie viele verschiedene Übersetzungswege gab es zwischen den Werkzeugen — und wusste am Ende jemand, welche Information auf welchem Weg verloren ging?

Wenn du diese Frage nicht beantworten kannst, geht es dir wie den meisten. Interessanter ist die Folgefrage: Was müsste im nächsten Projekt anders vereinbart werden, damit sie beantwortbar wird?

Merksätze

openBIM heisst Zusammenarbeit über offene, herstellerneutrale Formate und Prozesse — nicht, dass die Wahl der Software gleichgültig wäre.

Software hat Versionszyklen von Jahren, Bauwerke Lebenszyklen von Jahrzehnten. Dieses Missverhältnis ist das stärkste Argument für offene Formate.

Ein Export ist eine Übersetzung. Ohne Prüfung gegen die vereinbarten Anforderungen bleibt offen, ob die Lieferung brauchbar ist.

Quellen und weiterführende Literatur