Auch wenn der Hype um BIM abgeflaut ist und manche hämisch sagen, „BIM ist tot“, halte ich die Idee des modellbasierten Arbeitens im Bauwesen weiterhin generell für richtig. Es gibt jedoch eine Reihe von Gründen, warum BIM nicht so recht ans Laufen kommt.

Das sogenannte big BIM kann nur entstehen, wenn bereits der Auftraggeber BIM will und entsprechend planen lässt. Sehr oft werden dabei jedoch die Belange der Bauausführung vergessen und der Auftragnehmer sieht somit das Modell nur als Bürde, welches er pflegen und als as-built-Modell abgeben muss. Einen eigenen Nutzen von BIM hat er jedoch nicht.

Neben der Tatsache, dass die am BIM-Prozess Beteiligen die Bedürfnisse und Arbeitsweisen der jeweils Anderen oft nicht kennen oder nicht verstehen, entstehen Schwierigkeiten durch die weiterhin übliche Verwendung von IFC-Dateien beim Datenaustausch. IFC steht für ‚Industry Foundation Classes‘. Das Besondere an dem Format ist, dass es spezielle Typen von Objekten für die verschiedenen Gewerke bietet. Eine Wand hat natürlich andere geometrische Eigenschaften als eine Treppe oder eine Fahrbahndecke. Diese Unterscheidung in Bauteiltypen ist an sich eine gute Idee -die große Variabilität das Formates ist aber auch das Problem.

Die Variabilität von IFC-Dateien als Segen und Fluch

Im Folgenden gehe ich auf die Variabilität von IFC ein, die aus drei Punkten besteht:
IFC bietet die Freiheit,

• den Bauteilen beliebige weitere Informationen (Eigenschaften) mitzugeben
• den Bauteilen verschiedene Ausprägungen an Geometrie mitzugeben oder diese gar weg zu lassen
• die notwendigen Beziehungen zwischen Bauteilen zu verschweigen

Der Container für die Eigenschaften

Jedes Bauteil kann ein eigenes PropertySet besitzen. Das IfcPropertySet ist ein standardisierter Container innerhalb des IFC-Formats, um zusätzliche spezifische Informationen zu Bauteilen in einem BIM-Modell zu bündeln und zu organisieren. Ein PropertySet enthält eine Liste von Properties. Ein Property besteht immer aus den Paar ‚Name/Wert‘, zum Beispiel „Wandstärke“=0.24.

Auf IFC-Dateien basierende weiterführende Prozesse sind oft nur möglich, wenn sich der Anwender zum Beispiel dafür entscheidet, welche Eigenschaften aus dem IfcPropertySet die richtigen für den weiteren Prozess sind. Daher ist für Prozessketten, in denen eine Maschinenlesbarkeit wichtig ist, eine IFC-Datei alleine nicht geeignet. Denn es muss geprüft werden, ob die benötigten Eigenschaften überhaupt vorhanden sind und ob korrekte Werte darin stehen.

Digitalisierung nur mit Standardisierung

Um Prozessketten zu ermöglichen, gibt es zusätzlich die Information Delivery Specification (IDS), in der definiert werden kann, welche Properties (Eigenschaften) zwingend vorgeschrieben sind und wie der Name des jeweiligen Properties lautet. So etwas kann man theoretisch auch im BIM-Abwicklungsplan (BAP) des jeweiligen Projektes festlegen. Aber aus meiner Sicht ist es ein sehr hoher Aufwand, „das Rad in jedem Projekt neu zu erfinden“. Klar ist: Digitalisierung funktioniert nur mit Standardisierung. Es gibt jedoch leider bislang nur wenige IDS für bestimmte Anwendungsfälle. Ausnahmen sind die IDS für die Mengenermittlung im Hochbau zum Zweck der Kostenermittlung sowie Ermittlung der Mengen für die Ausschreibung. Weitere Infos dazu unter folgender Internetadresse: https://ucm.buildingsmart.org/de/use-cases/3449/de

Der Anwendungsfall Mengenermittlung zur Abrechnung ist im oben beschriebenen standardisierten IDS hingegen ausgeschlossen und sollte gesondert definiert werden. Zudem muss in anderen Gewerken als im Hochbau die Mengenermittlung in weiteren zusätzlichen IDS beschrieben werden.

Herausforderung Geometrie der Bauteile

Neben den oft zweideutigen Properties kann auch die Geometrie der Bauteile in Bauprojekten sehr unterschiedlich beschrieben werden. Theoretisch gesehen ist die geometrische Beschreibung sogar optional.

Im Hochbau beispielsweise besteht eine Wand entweder statisch aus 3D-Punkten und Dreiecken oder parametrisiert aus einem Grundrisspolygon und der Höhe. Seit Einführung des Formates IFC 4×3 kann im Straßenbau die Deckschicht einer Fahrbahn über Achse, Gradiente und Querprofile, als statischer Volumenkörper aus 3D-Punkten und Dreiecken, über Leitlinien, die die Ränder beschreiben oder als Flächenobjekt beschrieben werden. Und das je nach Anwendungsfall. Das Chaos ist vorhersehbar. Darüber hinaus ist es zulässig, in einer IFC-Datei gleich mehrere geometrische Repräsentationen zu übergeben.

Fehlende Verknüpfung der Objekte

Im Gewerk Tiefbau sind auch Verknüpfungen von Objekten wichtig. So ist ein Kanalnetz mathematisch ein Graph (Knoten-Kanten-Modell). Das bedeutet: Eine Rohrleitung ist immer verknüpft mit zwei Schächten. Ein Schacht am Anfang, der andere am Ende. Mit IFC lassen sich ebenfalls Verknüpfungen darstellen (IfcRelationship), aber auch das ist optional. Für die weiteren Prozesse sind diese Verknüpfungen aber oft sehr wichtig, in der Regel fehlen sie.

GAEB und ISYBAU als speziellere Austauschformate

Andere erfolgreiche digitale Austauschformate wie GAEB oder ISYBAU – welches im Kanalbau genutzt wird – bringen als modernere XML-Dateien über deren Schema engere Korsette gleich von Anfang an mit. Das Schema beschreibt unter anderem, wie die Namen bestimmter Eigenschaften (Properties) lauten und welche Werte sie annehmen dürfen. Damit ist eine Maschinenlesbarkeit viel eher gegeben, als wenn diese wie bei IFC völlig frei sind.

Bei GAEB gibt es für diverse Anwendungsfälle die Formate X80 bis X89. ISYBAU unterscheidet zwischen Fällen wie Stammdatenübergabe, Hydraulik und Sanierung. Das einlesende System kann am jeweiligen Dateiformat erkennen, welche Datensätze zu erwarten sind und sie automatisiert weiterverarbeiten.

Nutzung von IFC im Bauprozess

Eine IFC-Datei ohne IDS ist meiner Meinung nach im schlechtesten Fall ein besseres 3D-PDF. Schön anzuschauen und der Anwender kann die Eigenschaften betrachten. Aber eine Automatisierung weitergehender Prozesse ist kaum möglich.

Zum Glück ist IFC ohnehin nicht das bevorzugte Eingangsformat für den Bauprozess im Straßen- und Tiefbau. Für die Beschreibung von Horizonten, Linien, Punkten und anderen Objekten ist LandXML das anerkannte Format. Es gibt sogar eine ISO-Norm, die den Datenaustausch beschreibt: ISO/TS 15143 – earth-moving machinery and mobile road construction machinery – worksite data exchange

Planer von kommunalen Bauprojekten liefern aktuell weder IFC, noch LandXML. In der neuen Modellierungsrichtlinie der Deutsche Einheit Fernstraßenplanungs- und -bau GmbH (DEGES) ist dagegen erfreulicherweise festgehalten, dass Planer neben einem 3D-Modell als IFC auch weitere Daten, zum Beispiel im Format LandXML, liefern sollen.

Fazit

IFC bleibt im Straßenbau derzeit eher ein Zusatz zur Visualisierung und Mengenermittlung. Für andere Prozesse ist das Format eher nicht geeignet.

Anders gesagt: BIM ist nicht tot, aber man muss sich von der Vorstellung verabschieden, dass ein Datenaustausch in Form von IFC-Dateien die globale Lösung für die Digitalisierung ist. Die Definition von IDS für weitere Anwendungsfälle ist dringend geboten, denn für manche Anwendungsfälle ist IFC alleine schlicht ungeeignet.

Zu diesen anderen Anwendungsfällen folgen bald weitere Fachbeiträge.