openBIM-Glossar

Die Standards werden von buildingSMART International veröffentlicht, einer gemeinnützigen Organisation, die unter anderem IFC, BCF und IDS pflegt.

Der Zweck ist praktischer, nicht ideologischer Natur. An einem Bauprojekt arbeiten Architektur, Tragwerksplanung, TGA, ausführende Firmen und Auftraggeber – und sie werden sich nie auf dieselbe Software einigen. openBIM sorgt dafür, dass eine Tragwerksplanerin in der einen Anwendung und ein Architekt in der anderen dasselbe Modell austauschen und produktiv darüber streiten können.

IFC ist international standardisiert: IFC4 ist als ISO 16739-1:2018 veröffentlicht, IFC4.3 wurde als ISO 16739-1:2024 anerkannt.

Eine IFC-Datei beschreibt nicht nur Formen, sondern auch, was jede Form ist – eine Wand, eine Tür, ein Lüftungskanal – samt Eigenschaften, Materialien und Beziehungen zu anderen Bauteilen. Genau das unterscheidet IFC von einem reinen 3D-Format wie OBJ oder glTF: Eine 3D-Form sagt nur, dass ein Objekt existiert, während IFC der empfangenden Software mitteilen kann, dass es sich um eine tragende Wand mit einer Feuerwiderstandsdauer von 90 Minuten handelt.

Praktisch bedeutet das: Ein IFC-Modell bleibt abfragbar. Sie können ermitteln, welche Wände tragend sind, nach Geschoss filtern oder prüfen, ob jede Tür eine Brandschutzklassifizierung besitzt – all das ist mit Geometrie allein nicht möglich.

IFC2x3 stammt aus dem Jahr 2006 und bleibt das Arbeitspferd der Praxis. IFC4 erschien 2013 und wurde als ISO 16739-1:2018 standardisiert. IFC4.3 erweitert das Schema um Infrastruktur – Straßen, Brücken, Schienenwege und Häfen – und wurde als ISO 16739-1:2024 anerkannt.

Neuer heißt nicht automatisch das, was bei Ihnen ankommt. Viele etablierte Exportprofile wurden vor Jahren auf IFC2x3 eingestellt und seitdem nie wieder angefasst, sodass IFC2x3-Dateien in laufenden Projekten weiterhin regelmäßig eintreffen. Ein Viewer, der nur das neueste Schema liest, hilft in der Praxis wenig.

Bimlyte öffnet IFC2x3, IFC4 und IFC4x3.

Eine BCF-Datei trägt den Kommentar, den Status und die exakte Kameraposition im Modell, verweist dabei aber auf das Modell, statt es zu enthalten. Genau darin liegt der Entwurfsgedanke: Statt ein 500-MB-Modell hin- und herzumailen, um auf eine Stütze zu zeigen, versenden Sie ein Issue, das festhält, welche Stütze, aus welcher Ansicht und worin das Problem besteht.

Das Ergebnis ist eine Datei, die klein genug für einen E-Mail-Anhang bleibt. Deshalb wurde BCF zur praktischen Währung der BIM-Koordination und nicht zu einer Spezifikation, die niemand einsetzt.

BCF 2.1 wurde im Oktober 2014 veröffentlicht, BCF 3.0 im Juni 2021. In 3.0 werden Projektwerte wie Status und Prioritäten als gewöhnliche Daten statt in einem XSD-Erweiterungsschema gespeichert; außerdem sind Pflichtfelder, Dokumente und Viewpoints genauer definiert.

Da sich die Werkzeuge in einem Projekt selten auf eine Version einigen, gehört das Konvertieren zum Alltag und ist kein Sonderfall. Beim Konvertieren nach unten können Daten anfallen, für die es kein Zielfeld gibt; beim Konvertieren nach oben können Felder verlangt werden, die zuerst ausgefüllt werden müssen.

Der Dateiname sagt nichts aus – beide verwenden die Endung .bcf. Erst die Datei bcf.version im Archiv gibt an, welches Schema das Paket tatsächlich verwendet.

Ein Topic trägt Titel und Beschreibung, Status und Priorität, einen Typ, einen Verantwortlichen und ein Fälligkeitsdatum, einen Strang aus Kommentaren sowie einen oder mehrere Viewpoints, die zeigen, wo im Modell es gilt.

Die meisten Anwendungen nennen das in ihrer Oberfläche ein „Issue“, während die BCF-Spezifikation selbst von einem Topic spricht. Gemeint ist dasselbe – der Unterschied stolpert vor allem denjenigen, die die Spezifikation zum ersten Mal lesen.

Eine BCF-Datei ist im Kern ein Behälter für Topics: „ein BCF exportieren“ heißt, eine Menge davon zu exportieren.

Neben der Kameraposition speichert er, welche Bauteile sichtbar oder ausgeblendet waren, welche Schnittebenen aktiv sind und auf welche Elemente sich das Issue tatsächlich bezieht.

Das macht BCF nützlich statt bloß beschreibend. Wer einen Viewpoint öffnet, steht an derselben Stelle im Modell wie die Person, die das Issue erstellt hat – „die Kollision beim Treppenkern“ wird damit in einem 40-geschossigen Modell zu einer Angabe statt zu einem Ratespiel.

Ein einzelnes Topic kann mehrere Viewpoints enthalten – hilfreich, wenn ein Problem erst aus mehreren Blickwinkeln klar wird.

Es ist der Teil von BCF, der den Kontakt mit Menschen außerhalb des BIM-Teams übersteht. Auftraggeber, Bauleitung oder Nachunternehmer sehen den Snapshot in einem PDF-Bericht und verstehen das Problem – ohne Software und ohne Schulung.

Snapshots lassen sich mit Pfeilen, Text, Formen und Hervorhebungen markieren, sodass der konkrete Hinweis mit dem Issue reist, statt in einer separaten E-Mail zu versanden.

Er beantwortet die Frage „Haben wir bekommen, was wir bestellt haben?“, ohne dass ein Mensch das Modell öffnet und Eigenschaft für Eigenschaft prüft. Eine als IDS geschriebene Anforderung lässt sich automatisch gegen ein geliefertes IFC ausführen und liefert pro Anforderung ein Bestanden oder Nicht bestanden.

Das gelöste Problem ist real und teuer: Informationsanforderungen lebten traditionell in PDF-Dokumenten, die sich maschinell nicht prüfen ließen – Abweichungen fielen deshalb spät oder gar nicht auf.

Die IDS-Unterstützung befindet sich bei Bimlyte in Entwicklung.

Nichts wird verschmolzen. Architektur-, Tragwerks- und TGA-Modell bleiben bei ihren jeweiligen Autoren; die Föderation besteht schlicht darin, sie in denselben Koordinatenraum zu laden und gemeinsam zu betrachten.

Dort treten die meisten Kollisionen zutage, denn ein Lüftungskanal, der einen Unterzug durchdringt, ist unsichtbar, solange jedes Modell für sich betrachtet wird. Genau deshalb sind Koordinatensysteme und gemeinsame Nullpunkte so wichtig: Modelle, die nicht zueinander passen, erzeugen Kollisionen, die es nicht gibt, und verbergen jene, die es gibt.

Für BIM ist das nicht nur eine Haltungsfrage, sondern eine geschäftliche. Verlässt ein Modell das Gerät nicht, gibt es keinen Projektdatei-Upload, den man einem Auftraggeber erklären müsste, keinen fremden Verarbeitungsserver mit vertraulicher Geometrie und kein Projektkonto, das geprüft oder kompromittiert werden könnte.

Es verändert zugleich, was im Störungsfall passiert – in beide Richtungen: Das Werkzeug arbeitet weiter, wenn das Netz ausfällt, aber niemand kann Ihre Arbeit für Sie wiederherstellen, weil anderswo keine Kopie existiert.

Der Speicher ist von anderen Websites isoliert und für das übrige Dateisystem unsichtbar – eine Website erreicht nur ihren eigenen OPFS-Bereich und sonst nichts auf Ihrem Rechner.

Erst dadurch wird die Arbeit mit einem großen IFC-Modell im Browser praktikabel statt theoretisch, weil das Modell zwischen Sitzungen auf dem Gerät bleiben kann, statt jedes Mal neu eingelesen zu werden.

Da dieser Speicher der Website auf Ihrem Gerät gehört, wird er beim Löschen der Website-Daten mit entfernt. Genau deshalb ist ein exportiertes Paket der richtige Weg, eine Kopie von allem zu behalten, woran Ihnen liegt.

Das Paket kann optional mit einem Passwort geschützt werden, und der Empfänger benötigt weder BIM-Software noch ein Konto: Es öffnet sich im Browser.

Der Unterschied zu IFC oder BCF liegt im Umfang. IFC transportiert das Modell, BCF die Issues; keines von beiden ist dafür gedacht, eine Arbeitssitzung mit ihren gespeicherten Ansichten, Auswahlen und Viewer-Einstellungen wiederherzustellen.

Es ist außerdem der praktische Weg, ein Projekt zwischen Geräten zu bewegen – local-first gespeicherte Daten synchronisieren sich nicht von selbst – und der richtige Weg, eines zu sichern.

Diese Unabhängigkeit ist der Punkt: Die Prüfung eines Modells sollte keine Lizenz für das Werkzeug erfordern, in dem es entworfen wurde. In einem Projekt mit fünf Fachdisziplinen wären das sonst fünf Lizenzen für jeden, der nur hineinschauen will.

Ein browserbasierter IFC-Viewer geht einen Schritt weiter und benötigt überhaupt keine Installation. Das zählt auf gesperrten Firmenrechnern, auf denen die Installation von Software ein IT-Ticket erfordert, und unter macOS oder Linux, wo viele Desktop-BIM-Viewer schlicht nicht laufen.

Der Unterschied zu einem Viewer besteht darin, dass ein Manager auch schreibt und nicht nur liest: Er erzeugt standardisierte BCF-Dateien, die andere Werkzeuge verarbeiten können, und behandelt Kommentare, Status, Attribute und Viewpoints als bearbeitbare Daten.

In einem laufenden Koordinationskreislauf ist das der Unterschied zwischen Mitwirken und Zuschauen. Ein Viewer zeigt Ihnen, was jemand anderes festgestellt hat; ein Manager lässt Sie antworten, neu zuweisen, schließen und das Ergebnis zurückschicken.