IFC und BCF: Was ist der Unterschied?
Kurzantwort: IFC und BCF sind keine konkurrierenden Formate. IFC enthält das Gebäudemodell, BCF die Issues zu diesem Modell. Eine IFC-Datei transportiert Geometrie und Sachdaten von Wänden, Leitungen oder Stützen und ist typischerweise zehn bis mehrere hundert Megabyte groß. Eine BCF-Datei enthält nur Kommentar, Status und eine gespeicherte Kameraposition und bleibt deshalb klein genug für eine E-Mail. Beide offenen Standards werden von buildingSMART International veröffentlicht und im normalen Koordinationsablauf gemeinsam eingesetzt.
IFC und BCF werden häufig im selben Atemzug genannt. Das verleitet zu der Annahme, es handle sich um konkurrierende Formate. Das ist nicht der Fall: Sie lösen zwei unterschiedliche Probleme innerhalb desselben BIM-Workflows.
IFC dient dem Austausch des Modells. BCF dient dem Austausch der Kommunikation über dieses Modell.
Diese Unterscheidung klingt schlicht, erklärt aber, warum kein Format das andere ersetzen kann. Eine IFC-Datei gibt dem Projektteam etwas zu prüfen. Eine BCF-Datei hilft dem Team festzuhalten, was gefunden wurde, wo es gefunden wurde und was als Nächstes geschehen soll.
Was ist IFC?
IFC steht für Industry Foundation Classes. Der offene Standard ermöglicht den Austausch digitaler Gebäude- und Infrastrukturdaten zwischen unterschiedlichen BIM-Anwendungen. Er wird von buildingSMART International veröffentlicht und ist von der ISO standardisiert: IFC4 als ISO 16739-1:2018, IFC4.3 als ISO 16739-1:2024.
Im Projektalltag ist eine IFC-Datei die übergabefähige Fassung eines Modells. Sie kann die Geometrie von Wänden, Decken, Trägern, Leitungen oder Brückenbauteilen enthalten – zusätzlich aber auch die Informationen, die diesen Objekten ihre Bedeutung geben: was sie sind, wie sie zueinander stehen und welche Eigenschaften ihnen zugewiesen wurden.
Genau darin unterscheidet sich IFC von einem einfachen 3D-Export. Eine dreidimensionale Form zeigt nur, dass ein Objekt existiert. IFC kann der empfangenden Software darüber hinaus mitteilen, dass dieses Objekt eine Tür, eine tragende Stütze oder ein Luftdurchlass ist. Das Modell ist dadurch nicht nur sichtbar, sondern bleibt strukturiert und damit prüfbar, filterbar und auswertbar.
Der praktische Zweck von IFC ist Interoperabilität. Architektur, Tragwerksplanung, TGA, ausführende Firmen und Auftraggeber arbeiten in aller Regel mit verschiedener Software, benötigen aber dennoch einen gemeinsamen Projektstand. IFC liefert diese gemeinsame Referenz, ohne dass sich alle Beteiligten auf dasselbe Autorensystem einigen müssen.
Streng genommen ist IFC mehr als eine Dateiendung: Es handelt sich um ein standardisiertes Datenschema, das in verschiedenen technischen Formen abgebildet werden kann. In der Projektsprache meint „das IFC“ jedoch meist die Modelldatei, die zur Übergabe oder Koordination herausgegeben wird – und in dieser Bedeutung wird IFC üblicherweise mit BCF verglichen.
Was ist BCF?
BCF steht für BIM Collaboration Format. Es entstand aus einem anderen Bedürfnis: die Kommunikation über ein Modell präzise, übertragbar und über Softwaregrenzen hinweg verständlich zu machen.
Stellen Sie sich vor, bei einer Prüfung fällt auf, dass eine Lüftungsleitung einen Unterzug durchdringt. Das gesamte Modell mit der Nachricht „bitte die Kollision im 2. OG prüfen“ zurückzuschicken, lässt reichlich Raum für Missverständnisse: Welche Ansicht soll geöffnet werden? Welche Bauteile sind betroffen? Ist die Feststellung neu, erledigt oder wartet sie auf eine Entscheidung?
Ein BCF-Issue hält diesen Kontext zusammen. Es kann den Empfänger an die betreffende Stelle im Modell zurückführen, die betroffenen Objekte benennen und Kommentar, Status und Zuständigkeit mitführen. Statt nur zu beschreiben, wo das Problem liegt, versetzt BCF die Software in die Lage, es zu zeigen.
Entscheidend ist: BCF muss das vollständige BIM-Modell nicht mittransportieren. Es verweist auf das Modell, das dem Projektteam ohnehin vorliegt. Der Austausch bleibt dadurch leichtgewichtig, und Koordinationskommentare können zwischen Werkzeugen wandern, ohne dass jedes Mal große Modelldateien versendet werden.
BCF ähnelt damit eher einem strukturierten Mängel- und Aufgabenregister als einer Planungsdatei. Es beschreibt nicht das gesamte Bauwerk, sondern das, was jemand daran besprechen, prüfen, ändern oder freigeben möchte.
IFC und BCF im direkten Vergleich
| IFC | BCF | |
|---|---|---|
| Zweck | Modell austauschen | Issues austauschen |
| Inhalt | Geometrie, Eigenschaften, Beziehungen | Kommentare, Status, Viewpoints, Snapshots |
| Typische Größe | Zehn bis mehrere hundert Megabyte | Meist deutlich kleiner |
| Ersetzt das Modell? | Ja, als Austauschmodell | Nein, verweist auf das Modell |
Worin besteht der Unterschied konkret?
Am deutlichsten wird er, wenn man fragt, was fehlen würde, wenn eines der beiden Formate nicht existierte.
Ohne IFC hätte das Team womöglich Kommentare, aber kein verlässliches, herstellerneutrales Modell, auf das sich diese Kommentare beziehen. Ohne BCF hätte das Team das Modell, aber keinen einheitlichen Weg, die bei der Prüfung gewonnenen Feststellungen auszutauschen.
Eine IFC-Datei beantwortet Fragen wie: Was steckt im Modell? Wo liegen die Bauteile? Was sind sie, und welche Informationen tragen sie?
Ein BCF-Issue beantwortet andere Fragen: Was erfordert Aufmerksamkeit? Wo liegt das Problem? Wer soll reagieren, und wie ist der aktuelle Status?
Deshalb ist es unwirtschaftlich, für jeden neuen Kommentar ein neues IFC zu exportieren. Modell und Koordinationsprozess entwickeln sich in unterschiedlichem Tempo: Ein Planungsteam gibt vielleicht einmal pro Woche ein neues Modell heraus, während die Prüfenden dazwischen Dutzende Issues anlegen, aktualisieren und schließen. BCF hält diesen Dialog am Laufen, ohne jeden Kommentar in einen vollständigen Modellaustausch zu verwandeln.
Wie arbeiten beide Formate zusammen?
In einem typischen Koordinationszyklus veröffentlicht die planende Stelle ein IFC-Modell, und die Koordination prüft es in einem Model-Checking- oder Koordinationswerkzeug. Kollisionen, Rückfragen und planerische Bedenken werden als BCF-Issues erfasst und an die zuständigen Fachplaner zurückgegeben. Diese aktualisieren daraufhin das Quellmodell, beantworten die Issues und veröffentlichen zum nächsten Austauschtermin ein überarbeitetes IFC.
IFC und BCF sind also keine Alternativen, sondern ergänzen einander. IFC ist die gemeinsame Projektinformation; BCF ist der strukturierte Dialog, mit dem das Team sie verbessert.
Wo Bimlyte hineinpasst
Der Unterschied zwischen IFC und BCF ist theoretisch klar. In der Praxis benötigen viele Beteiligte jedoch keine große BIM-Plattform. Sie müssen lediglich ein Modell öffnen, eine Feststellung nachvollziehen und einen Bericht erzeugen, mit dem andere weiterarbeiten können.
Bimlyte bringt diese Aufgaben direkt im Browser zusammen. Sie öffnen ein IFC-Modell zur visuellen Prüfung und arbeiten mit den zugehörigen Koordinations-Issues. Das Modell liefert den Projektkontext, die Issues halten die Fragen, Kommentare und Maßnahmen fest, die bei der Prüfung entstehen.
Sollen die Informationen in eine andere BIM-Anwendung wandern, exportieren Sie sie als BCF. Sollen sie an Auftraggeber, Bauleitung oder Baustelle gehen, die keine BIM-Spezialsoftware einsetzen, lassen sich dieselben Informationen als PDF- oder Excel-Bericht ausgeben.
Das ist deshalb relevant, weil gute Koordination nicht davon abhängen sollte, dass alle Beteiligten dieselbe Software oder dieselbe BIM-Erfahrung haben. IFC hält das Modell offen, BCF hält die Abstimmung strukturiert – und Bimlyte macht beides leichter zugänglich. Die Dateien werden dabei auf Ihrem Gerät verarbeitet; Projektdaten müssen also nicht erst auf einen entfernten Server hochgeladen werden, bevor sie geprüft werden können.
Weitere Begriffe erklärt das openBIM-Glossar. Schritt-für-Schritt-Hilfe finden Sie in den Anleitungen, oder Sie öffnen Bimlyte direkt und probieren es mit Ihren eigenen Dateien aus.
Gefällt Ihnen Bimlyte oder der Blog? Beides ist kostenlos – wenn es Ihnen nützt, freue ich mich über einen Kaffee über Buy Me a Coffee.(wird in einem neuen Tab geöffnet)