BIM Datenaustausch: Warum IFC und BCF den Workflow steuern

BIM-Datenaustausch: Warum IFC und BCF den Workflow steuern

Genau an dieser Stelle trennt sich der belastbare BIM-Datenaustausch von einem bloßen Dateiversand.

IFC und BCF übernehmen dabei unterschiedliche Aufgaben. IFC beschreibt Bauteile, Geometrien und Eigenschaften in einem herstellerneutralen Datenmodell. BCF transportiert modellbezogene Hinweise, Rückfragen und Aufgaben. Das eine Format ersetzt das andere nicht. Erst das Zusammenspiel beider Ebenen macht aus einem exportierten Modell einen arbeitsfähigen Informationsfluss zwischen Architektur, Tragwerksplanung, Gebäudetechnik und Ausführung.

Für die Praxis des Ingenieurbüros ist deshalb nicht nur entscheidend, ob eine Software „IFC kann“. Entscheidend ist, welche Version, welches Exportprofil, welche Objektklassen und welche Eigenschaften tatsächlich unterstützt werden – und was im Projektvertrag für den Datenaustausch vereinbart wurde.

IFC als Fundament: Vom statischen Datencontainer zur ISO-Norm

Die Industry Foundation Classes, kurz IFC, bilden das Fundament des offenen Datenaustauschs im Bauwesen. Das Datenmodell beschreibt Bauteile nicht allein als Linien oder Flächen, sondern als fachlich eingeordnete Objekte. Ein Träger kann beispielsweise als Trägerobjekt mit einer bestimmten Geometrie, einem Querschnitt, einem Material und weiteren Eigenschaften übertragen werden. Für Stützen, Platten, Wände, Fundamente oder Bewehrung gelten jeweils eigene semantische Zusammenhänge.

Gerade für die Tragwerksplanung ist diese Unterscheidung wichtig. Ein statisches Modell enthält mehr als sichtbare Geometrie. Relevant können unter anderem sein:

• die Zuordnung eines Bauteils zu Geschoss, Tragwerk und räumlicher Struktur,
• Material- und Querschnittsinformationen,
• die Verbindung zwischen Bauteilen,
• Referenzen auf Profile oder Typen,
• Eigenschaften für Prüfung, Mengen, Klassifikation oder Ausführung,
• Informationen, die im jeweiligen Anwendungsfall für Koordination oder Übergabe benötigt werden.

IFC versucht, diese Zusammenhänge herstellerneutral abzubilden. Das bedeutet jedoch nicht, dass jede Information aus jeder Software automatisch in gleicher Qualität übertragen wird. Eine IFC-Implementierung kann auf den Import oder den Export beschränkt sein. Sie kann außerdem nur bestimmte Teile des Standards, bestimmte Objektklassen oder bestimmte Eigenschaften unterstützen. Selbst wenn ein Programm IFC sowohl einliest als auch ausgibt, sagt das allein noch nichts über die Tiefe und Zuverlässigkeit der Umsetzung aus.

Ein Export aus einem Statikprogramm kann deshalb in einem Projekt gut funktionieren und in einem anderen zu Lücken führen. Vielleicht werden Bauteile als passende IFC-Objekte ausgegeben, während bestimmte analytische Informationen fehlen. Vielleicht wird die Geometrie korrekt übertragen, aber eine projektspezifische Eigenschaft nicht. Oder die empfangende Software kann das Objekt zwar einlesen, stellt seine Attribute aber nicht vollständig dar.

Ein Export ist immer eine definierte Sicht auf das Modell

Die Vorstellung, eine IFC-Datei sei grundsätzlich ein vollständiger digitaler Zwilling des gesamten Planungsstands, führt in der Koordination schnell zu falschen Erwartungen. Ein IFC-Export kann das vollständige Modell eines bestimmten Fachbereichs enthalten. Er kann aber ebenso ein Teilmodell, eine Auswahl bestimmter Bauteile oder nur die für einen konkreten Anwendungsfall benötigten Informationen abbilden.

Welche Daten enthalten sind, hängt unter anderem ab von:

• dem verwendeten IFC-Schema und der Version,
• dem Exportprofil der Software,
• den gewählten Einstellungen,
• der Modellstruktur,
• dem Anwendungsfall,
• der Auswahl der zu exportierenden Bauteile,
• den tatsächlich implementierten Eigenschaften und Zuordnungen.

Ein Koordinationsmodell für die Kollisionsprüfung braucht möglicherweise andere Informationen als ein Modell für Mengen, die Übergabe an die Ausführung oder die Bestandsdokumentation. Ein Tragwerksplaner wird daher nicht einfach „das Modell“ exportieren, sondern eine für den Zweck geeignete Informationssicht erzeugen.

Das ist keine Schwäche des Formats, sondern eine Grundbedingung modellbasierter Arbeit. Ein bewusst reduziertes Teilmodell kann für einen Prüfprozess wesentlich nützlicher sein als eine möglichst große Datei, in der relevante Informationen schwer auffindbar sind. Umgekehrt darf eine reduzierte Datei nicht als vollständige Übergabe missverstanden werden.

IFC beschreibt, welche Bauteile und Informationen übertragen werden. Wie vollständig dieser Inhalt ist, entscheidet das Zusammenspiel aus Modell, Exportprofil, Implementierung und Anwendungsfall.

Die Normung als ISO 16739-1 schafft einen international anerkannten Rahmen für das Datenmodell. Sie macht aus IFC aber keine automatische Garantie für einen verlustfreien Austausch. Norm und Softwareimplementierung sind zwei verschiedene Ebenen: Die Norm definiert die Struktur und die möglichen Inhalte; die Programme müssen diese Struktur in konkreten Import- und Exportfunktionen umsetzen.

IFC-Versionen und Praxisfähigkeit

Mit IFC4 und IFC4.3 wurden Datenstrukturen und Anwendungsbereiche weiterentwickelt. IFC4.3 richtet den Blick stärker auf unterschiedliche Bereiche des Bauwesens und integriert Anforderungen, die über den klassischen Hochbau hinausgehen. In der Projektpraxis treffen diese neueren Möglichkeiten jedoch auf eine heterogene Softwarelandschaft.

IFC2x3 ist weiterhin in vielen Projekten anzutreffen, weil zahlreiche Programme und Arbeitsabläufe darauf eingestellt sind. IFC4 bietet in verschiedenen Bereichen modernere Strukturen, wird aber nicht von jedem Werkzeug mit derselben Qualität unterstützt. Die Entscheidung für eine Version sollte deshalb nicht allein nach dem Alter des Standards erfolgen. Maßgeblich ist, ob Sender und Empfänger genau die benötigten Inhalte in dieser Version austauschen können.

BCF: Die digitale Kommunikationsebene für modellbasierte Issues

Das BIM Collaboration Format, BCF, verfolgt einen anderen Zweck als IFC. Es transportiert in der Regel nicht die Geometrie des gesamten Fachmodells. Stattdessen beschreibt es modellbezogene Kommunikation: eine Kollisionsmeldung, eine Rückfrage zur Anschlussausbildung, eine Aufgabe für den nächsten Planungsstand oder eine Entscheidung, die an einem bestimmten Bauteil getroffen werden muss.

Ein BCF-Issue kann typischerweise enthalten:

• eine eindeutige Kennung,
• Titel und Beschreibung,
• Status und Priorität,
• Zuständigkeit,
• Kommentare und Bearbeitungsverlauf,
• Verweise auf betroffene Modellobjekte,
• eine definierte Ansicht,
• einen Screenshot oder weitere Kontextinformationen.

Die Stärke liegt darin, dass die Nachricht nicht als allgemeine E-Mail im Projektpostfach landet. Sie wird mit einem räumlichen und fachlichen Bezug versehen. Der Empfänger soll nicht erst suchen müssen, welche Wand, welcher Träger oder welcher Anschluss gemeint ist.

Das klassische Dateiformat ist BCF als komprimiertes Paket, häufig mit der Endung .bcfzip. Darin liegen die strukturierten Informationen zum Issue, die Verweise auf Objekte, die Beschreibung der Ansicht und gegebenenfalls ein Screenshot. Daneben gibt es die bcfAPI. Sie erlaubt es, Issues über eine Schnittstelle zwischen Systemen oder Plattformen auszutauschen und zu synchronisieren. Ob diese Möglichkeit tatsächlich genutzt werden kann, hängt wiederum von den beteiligten Anwendungen und der Projektumgebung ab.

BCF ersetzt auch nicht die fachliche Prüfung. Ein Issue mit dem Titel „Kollision“ ist noch keine bewertete Lösung. Es muss geklärt werden, ob tatsächlich ein Konflikt vorliegt, welche Randbedingung gilt und wer die Änderung verantwortet. Das Format sorgt dafür, dass diese Klärung strukturiert am Modell verankert werden kann.

Was ein guter BCF-Workflow leistet

Ein funktionierender BCF-Workflow beginnt nicht beim Export, sondern bei klaren Regeln für die Zusammenarbeit. Dazu gehören beispielsweise:

1. Issues eindeutig benennen: Der Titel sollte das Problem so beschreiben, dass es auch außerhalb der ursprünglichen Ansicht verständlich bleibt.

2. Verantwortlichkeiten festlegen: Ein Issue braucht einen Adressaten oder eine zuständige Rolle. Eine allgemeine Nachricht an das gesamte Projektteam wird selten effizient bearbeitet.

3. Status konsequent pflegen: Offen, in Bearbeitung, beantwortet oder geschlossen müssen im Projekt einheitlich verstanden werden.

4. Ansichten nachvollziehbar speichern: Kameraposition, Schnittdarstellung oder Sichtbarkeitseinstellungen geben dem Empfänger den notwendigen räumlichen Kontext.

5. Entscheidungen dokumentieren: Eine Änderung sollte nicht nur als neuer Modellstand sichtbar sein. Die Begründung gehört in den Kommunikationsverlauf, soweit sie für die Nachvollziehbarkeit erforderlich ist.

6. Abschluss prüfen: Ein Issue ist nicht automatisch erledigt, nur weil ein neues IFC-Modell vorliegt. Die verknüpfte Änderung muss im passenden Modellstand kontrolliert werden.

Damit wird BCF zu einer Arbeitsoberfläche für die Koordination. Das Format dokumentiert nicht zwangsläufig jede Kommunikation des Projekts, sondern die modellbezogenen Vorgänge, die für den vereinbarten Prozess relevant sind.

Die Rolle der GUID: Wie IFC-Objekte und BCF-Nachrichten korrespondieren

Die GUID, also die Globally Unique Identifier, ist die zentrale Verbindung zwischen IFC-Objekt und BCF-Issue. Sie dient dazu, ein Objekt im Modell eindeutig zu referenzieren. Ein Issue kann dadurch nicht nur auf eine Position im Raum, sondern auf ein bestimmtes modelliertes Element verweisen.

Ein typischer Ablauf sieht so aus: Der Tragwerksplaner erstellt ein Fundament und exportiert sein Fachmodell nach IFC. In der Koordinationssoftware wird eine Überschneidung mit einer geplanten Leitung festgestellt. Die prüfende Person erstellt ein BCF-Issue, speichert die GUID des betroffenen Fundaments und legt eine passende Modellansicht mit dem Konflikt an. Der Tragwerksplaner importiert das Issue in seine Arbeitsumgebung und kann über die Referenz und die Ansicht direkt zur fraglichen Stelle navigieren.

Die technische Referenz ist dabei nur so stabil wie der Modellierungs- und Exportprozess. Wird ein Bauteil gelöscht und neu angelegt, kann es eine andere GUID erhalten. Auch Änderungen am Exportprozess oder an der Modellstruktur können dazu führen, dass eine frühere Referenz nicht mehr wie erwartet aufgelöst wird. Nicht jede Änderung der Geometrie führt automatisch zum Verlust einer GUID; problematisch sind vor allem Prozesse, bei denen Objekte neu erzeugt, aufgeteilt, zusammengeführt oder durch andere Objekte ersetzt werden.

Das hat eine praktische Konsequenz: Der BCF-Verlauf sollte nicht isoliert vom Modellmanagement behandelt werden. Zu jedem Issue muss nachvollziehbar sein, auf welchen Modellstand und welche Version des Fachmodells sich die Kommunikation bezieht. Ein Dateiname allein reicht dafür oft nicht aus. Version, Autor, Freigabestatus und Austauschzeitpunkt müssen im Projektprozess eindeutig geregelt sein.

GUID ist kein Ersatz für Modellqualität

Eine GUID macht eine Referenz technisch präzise, sie erklärt aber nicht automatisch die fachliche Bedeutung eines Bauteils. Wenn ein Träger falsch klassifiziert, unvollständig exportiert oder im Empfängersystem nicht korrekt interpretiert wird, kann die GUID zwar auf ein Objekt zeigen, die fachliche Aussage bleibt trotzdem unzureichend.

Für die Interoperabilität in der Tragwerksplanung müssen daher mehrere Ebenen zusammenpassen:

• das Bauteil muss im Ursprungsmodell korrekt angelegt sein,
• die IFC-Entität muss zum Bauteil und zum Anwendungsfall passen,
• die erforderlichen Eigenschaften müssen exportiert werden,
• der Empfänger muss diese Entität und Eigenschaften interpretieren können,
• die GUID muss über die vorgesehenen Modellstände hinweg sinnvoll verfolgt werden.

BCF kann eine fehlerhafte IFC-Übergabe nicht reparieren. Es kann aber sehr genau markieren, wo eine Information fehlt, eine Geometrie nicht übereinstimmt oder eine Modellannahme geklärt werden muss.

Versions-Wirrwarr in der Praxis: Von IFC2x3 bis zum Ausblick auf IFC X

In laufenden Projekten existieren häufig mehrere Versionen nebeneinander. Das ist weniger ein theoretisches Normproblem als eine Frage der täglichen Zusammenarbeit. Ein Büro arbeitet mit IFC4, der Koordinator fordert IFC2x3, und die verwendete Prüfsoftware liest zwar beide Dateien ein, verarbeitet bestimmte Eigenschaften aber nur aus einer der Versionen.

Die Versionsangabe allein beschreibt noch nicht die Qualität des Austauschs. Zwei Programme können dieselbe IFC-Version unterstützen und dennoch unterschiedliche Ergebnisse liefern. Das betrifft etwa die Zuordnung von Bauteilen, die Darstellung von Profilen, die Übertragung von Eigenschaften oder die Behandlung von Beziehungen zwischen Objekten.

Für die Praxis ist deshalb ein kleiner Testlauf sinnvoll. Nicht erst nach Beginn der eigentlichen Koordination sollte geprüft werden, ob ein Fundament, ein Unterzug, eine Stütze oder eine Decke im Zielsystem korrekt ankommt. Ein Testmodell mit typischen Bauteilen aus dem Projekt zeigt schneller als jede Herstellerbeschreibung, welche Informationen erhalten bleiben.

Der Ausblick auf IFC X

Die Weiterentwicklung des IFC-Ansatzes wird seit Längerem diskutiert. Unter der Bezeichnung IFC X werden Ideen für einen stärker modularen und webbasierten Umgang mit Bauwerksinformationen zusammengefasst. Dabei geht es unter anderem um flexiblere Datenstrukturen, API-basierte Zugriffe und Formate, die sich besser in digitale Plattformen integrieren lassen.

Für ein laufendes Tragwerksprojekt ist daraus jedoch nicht automatisch ein sofortiger Handlungsauftrag abzuleiten. Solange Spezifikation, Implementierungen und verlässliche Austauschprofile nicht ausreichend etabliert sind, bleibt IFC X ein Zukunftsthema. Die bewährte Strategie lautet daher: aktuelle Projektanforderungen sauber definieren, vorhandene Versionen testen und keinen neuen Standard allein wegen seiner angekündigten Möglichkeiten zur Vertragsgrundlage machen.

Auch bei BCF gibt es verschiedene Versionsstände und unterschiedliche Grade der Softwareunterstützung. BCF 2.1 ist in vielen Umgebungen noch relevant, während neuere Versionen zusätzliche Möglichkeiten bieten. Entscheidend ist nicht, die höchste Versionsnummer zu verwenden, sondern einen durchgängigen Prozess zwischen den tatsächlich eingesetzten Werkzeugen sicherzustellen.

Interoperabilität im Ingenieurbüro: Strategien für den Datenaustausch

Eine belastbare IFC-Schnittstelle für Ingenieurbüros beginnt mit der Frage, welche Informationen ein Empfänger wirklich benötigt. Der Export sollte nicht als pauschale Abgabe des gesamten Arbeitsmodells verstanden werden. Für die Tragwerksplanung kann beispielsweise die Koordination der Bauteilgeometrie im Vordergrund stehen. In einem anderen Austausch sind Material, Querschnitt, Klassifikation oder Angaben zur Ausführung entscheidend.

Daraus folgt eine einfache, aber oft übersehene Regel: Das Exportprofil muss zum Zweck passen. Ein Koordinationsmodell, ein Prüfmodell und ein Übergabemodell können aus derselben Planungsumgebung stammen und trotzdem unterschiedliche Inhalte benötigen.

Das Exportprofil als fachliche Entscheidung

Vor dem ersten regulären Austausch sollten mindestens folgende Punkte festgelegt werden:

• Welche IFC-Version wird verwendet?
• Welche Fachmodelle werden getrennt oder gemeinsam übergeben?
• Welche Bauteilklassen müssen enthalten sein?
• Welche Eigenschaften sind für Prüfung und Koordination erforderlich?
• Werden Mengen, Klassifikationen oder Ausführungsinformationen benötigt?
• Wie werden Änderungen und neue Modellstände gekennzeichnet?
• Welche Einschränkungen des Import- und Exportwerkzeugs sind bekannt?
• Wer prüft die Datei nach dem Export?

Gerade der letzte Punkt ist entscheidend. Ein Export ist nicht abgeschlossen, wenn die Datei erzeugt wurde. Sie muss im Zielsystem geöffnet und kontrolliert werden. Sichtbare Geometrie, Objektzuordnung, Geschossstruktur und ausgewählte Eigenschaften sollten anhand konkreter Bauteile geprüft werden. Bei einem statischen Modell kann zusätzlich relevant sein, ob die für die Koordination nötigen Querschnitts- oder Materialangaben tatsächlich angekommen sind.

Nicht jede Information aus der Statiksoftware hat ein direktes Gegenstück im IFC-Modell. Berechnungsergebnisse, interne Modellannahmen und analytische Zusammenhänge lassen sich nicht ohne Weiteres mit einer sichtbaren Bauteilgeometrie gleichsetzen. Der Empfänger muss wissen, ob er ein Koordinationsmodell, ein Analysemodell oder eine andere Informationssicht erhält.

BCF als geregelter Prozess statt als Dateianhang

Auch BCF funktioniert nur, wenn die Projektbeteiligten die gleiche Arbeitsweise vereinbaren. Ein Issue sollte mindestens erkennen lassen, welches Modell betroffen ist, worin das Problem besteht und welche Reaktion erwartet wird. Die Modellansicht unterstützt die Orientierung, ersetzt aber keine präzise Beschreibung.

Für ein Ingenieurbüro kann es sinnvoll sein, Issues nach fachlichen Kategorien zu unterscheiden, etwa:

• Geometriekonflikt zwischen Tragwerk und TGA,
• fehlende oder widersprüchliche Bauteilinformation,
• Klärung einer Anschluss- oder Durchbruchsituation,
• Abweichung zwischen Plan, Modell und Ausführungsstand,
• Prüfhinweis ohne unmittelbaren Änderungsauftrag.

So wird aus einer langen Sammlung von Markierungen ein bearbeitbarer Vorgang. Ebenso wichtig ist die Trennung zwischen einem fachlichen Hinweis und einer verbindlichen Anweisung. Ein Issue kann eine Prüfung anstoßen, ohne bereits die Entscheidung über die Lösung vorwegzunehmen.

Die digitale Dokumentation sollte außerdem nicht mehr versprechen, als der Prozess leisten kann. BCF bildet modellbezogene Abstimmungen ab. Es ist nicht automatisch ein vollständiges Protokoll sämtlicher Besprechungen, E-Mails oder Freigaben. Welche Bedeutung die Issues im Projekt haben, muss zwischen den Beteiligten festgelegt werden.

Vertragliche Bedeutung und HOAI

Die technische Qualität eines IFC- oder BCF-Austauschs darf nicht mit seiner rechtlichen oder vertraglichen Verbindlichkeit verwechselt werden. Ein IFC-Modell kann im Vertrag als maßgebliche Informationsquelle für bestimmte Geometrien oder Eigenschaften vereinbart werden. Ebenso kann festgelegt werden, dass BCF-Issues für definierte Prüf- und Abstimmungsprozesse verwendet werden. Ohne eine solche projektspezifische Vereinbarung folgt diese Vertragsrelevanz jedoch nicht allein aus dem Dateiformat.

Das gilt auch für die Leistungsphasen nach HOAI. Die HOAI schreibt IFC- oder BCF-Dateien nicht generell als eigenständige Pflichtbestandteile der Leistungsphase 5 vor. Ob und in welcher Form digitale Modelle, Issue-Listen oder Austauschdateien geschuldet sind, hängt von den beauftragten Leistungen, den Vertragsunterlagen und den konkret vereinbarten BIM-Anwendungsfällen ab.

In den Projektunterlagen sollte daher eindeutig geregelt werden:

• welches Modell zu welchem Zweck geliefert wird,
• welche IFC-Version und welches Exportprofil gelten,
• welche Informationen als verbindlich betrachtet werden,
• wie BCF-Issues erstellt, beantwortet und geschlossen werden,
• welche Modellstände für Prüfungen maßgeblich sind,
• wie Abweichungen zwischen Modell, Plan und anderen Dokumenten behandelt werden,
• wann eine Übergabe als erfolgt und geprüft gilt.

Eine solche Regelung schützt beide Seiten. Der Auftraggeber erhält Klarheit darüber, welche Informationen erwartet werden. Das Ingenieurbüro kann nachvollziehbar abgrenzen, welche Daten tatsächlich Bestandteil der Leistung sind und welche Aussagen ein Export nicht leisten soll.

Die technische Offenheit von IFC und BCF schafft noch keine vertragliche Eindeutigkeit. Erst Projektvereinbarung, Exportprofil und Prüfprozess bestimmen, welche Information am Ende belastbar ist.

Werkzeugauswahl und CDE

Die Softwareauswahl sollte sich nicht an einer langen Liste von Formatlogos erschöpfen. Ein Programm kann IFC und BCF unterstützen und dennoch im konkreten Workflow wichtige Funktionen vermissen. Zu prüfen sind deshalb Import und Export getrennt voneinander, ebenso die unterstützten Versionen und Objektklassen.

Für ein Ingenieurbüro sind unter anderem diese Fragen relevant:

• Kann die Software die benötigten IFC-Versionen importieren und exportieren?
• Werden Bauteile und relevante Eigenschaften korrekt interpretiert?
• Bleiben GUIDs bei vorgesehenen Aktualisierungen nachvollziehbar?
• Können BCF-Issues mit Ansichten, Kommentaren und Statuswerten verarbeitet werden?
• Ist eine bcfAPI-Anbindung vorhanden und für die eingesetzte Plattform nutzbar?
• Lassen sich Modellstände und Issue-Versionen eindeutig dokumentieren?
• Können Prüfungen in die vorhandene CDE-Struktur integriert werden?

Die bcfAPI kann den manuellen Austausch von .bcfzip-Dateien reduzieren, sie beseitigt aber nicht automatisch alle Versionskonflikte. Auch ein cloudbasierter Workflow benötigt Regeln für Rechte, Zuständigkeiten, Statuswechsel und Freigaben. Eine technisch moderne Schnittstelle ersetzt keine Projektorganisation.

Was der Vergleich von IFC und BCF für die Tragwerksplanung bedeutet

Der Vergleich der BIM-Datenaustauschformate IFC und BCF ist deshalb kein Duell zwischen zwei Alternativen. IFC und BCF lösen verschiedene Probleme:

Für die Tragwerksplanung ist die Trennung besonders nützlich. Das IFC-Modell kann als definierte Informationssicht des Tragwerks übergeben werden. BCF hält fest, welche Fragen an diesem Modell offen sind und wie sie bearbeitet werden. Wird beides vermischt, entstehen leicht Missverständnisse: Eine neue IFC-Datei gilt dann fälschlich als Antwort auf jedes offene Issue, oder ein BCF-Kommentar wird als Änderung des Modells interpretiert.

Der robuste Workflow besteht daher aus drei wiederkehrenden Prüfungen:

1. Modell prüfen: Sind Geometrie, Objektklassen und benötigte Eigenschaften im Export enthalten?

2. Kommunikation prüfen: Ist jedes Issue verständlich, adressiert und mit dem richtigen Modellstand verknüpft?

3. Änderung prüfen: Wurde die beschlossene Anpassung im nächsten Modellstand tatsächlich umgesetzt und kontrolliert?

Diese Schritte klingen unspektakulär. In der Praxis verhindern sie jedoch die typischen Brüche des Datenaustauschs: falsch verstandene Bauteile, verlorene Referenzen, ungeklärte Zuständigkeiten und scheinbar erledigte Konflikte.

IFC und BCF steuern den Workflow nicht deshalb, weil eine Norm den Projektbeteiligten jede Entscheidung abnimmt. Sie geben dem Austausch vielmehr eine Struktur. IFC sorgt dafür, dass Fachmodelle in einer gemeinsamen Sprache beschrieben werden können. BCF sorgt dafür, dass die daraus entstehenden Fragen am Modell bleiben und nicht in verstreuten Nachrichten verschwinden.

Für ein Ingenieurbüro liegt die eigentliche Leistung deshalb nicht im bloßen Erzeugen einer IFC-Datei oder im Export eines BCF-Pakets. Sie liegt in der bewussten Wahl der Informationsinhalte, im kontrollierten Umgang mit Modellständen und in einer Vereinbarung darüber, welche Daten und Issues im konkreten Projekt welche Bedeutung haben. Wer diese Ebenen sauber trennt und anschließend konsequent verbindet, schafft Interoperabilität, die auch im Alltag der Tragwerksplanung belastbar bleibt.