BIM Klassifizierung für denVerkehrswegebau mit card_1

Eine gemeinsame Sprache bei der Planung und Umsetzung eines Projekts ist ein wesentlicher Erfolgsfaktor. Deshalb ist die Standardisierung von Objektnamen, die zu Klassen zusammengefasst werden, von großer Bedeutung. Ein standardisierter Klassenkatalog sorgt dafür, dass alle Beteiligten dieselben Begriffe und Definitionen verwenden, was die Kommunikation und Zusammenarbeit erheblich erleichtert. Dies führt im BIM Workflow zu einer effizienteren Datenintegration, verbessert die Koordination und reduziert Fehler.

Nicht selten kommt es vor, dass aufgrund unterschiedlicher fachlicher Hintergründe BIM Objekte unterschiedlich benannt werden. Aus der Hohlkastenbrücke wird dann schnell aufgrund der schön ausgeformten Bögen eine Bogenbrücke. Um solche Missverständnisse zu vermeiden, gibt es „Wörterbücher“, in denen verschiedene Objekte in Klassen zusammengefasst sind. Diese Kataloge übersetzen die verschiedenen Fachdialekte in eine gemeinsame Sprache, indem sie Objekte standardisieren und einheitlich benennen. Durch diese Standardisierung wird sichergestellt, dass alle Beteiligten im Bauprozess dieselben Begriffe und Definitionen verwenden.

Einer dieser Kataloge ist die Vorstandardisierungsarbeit „BIM-Klassen der Verkehrswege 2.0“ des buildingSMART Deutschland e. V. Dieser ist speziell auf das Klassifizieren von BIM Objekten der Kategorie Verkehrswege zugeschnitten. Neben den Bereichen Straße, Bahn, Brücke und Wasserwege werden zahlreiche Klassen anderer Fachbereiche abgebildet.

Solch eine Klassifizierung klingt in der Theorie ganz toll, aber wie lässt sich diese denn nun mit card_1 umsetzen? Dafür wurde für die Bachelorarbeit ein Beispielprojekt erstellt, in dem die Klassifizierung für eine Auswahl an Objekten exemplarisch durchgeführt wurde. Ziel war ein Anschauungsmodell mit beispielhaften Objekten, bei denen die Klassifikation per Mausklick abgefragt werden kann.

Um ein umfangreiches Anschauungsmodell zu erstellen, musste im ersten Schritt abgestimmt werden, welche Objekte und Möglichkeiten card_1 bietet und was davon mit den Objekten des buildingSMART Klassenkataloges übereinstimmt. Hierfür wurde zum einem das umfangreiche card_1 Kursangebot genutzt, um sich in die Software einzuarbeiten. Zum anderen erfolgte eine zielgerichtete Einarbeitung in das Demoprojekt „Bestandsmodellierung“, um eine Auswahl an geeigneten Objekten zu identifizieren. Es wurden 27 Klassen bzw. Objekte ausgewählt, die zunächst in einer Handskizze zu einem Anschauungsmodell zusammengebracht wurden. Durch die zeitliche Begrenzung der Bachelorarbeit konnten nicht alle Möglichkeiten der Software vollumfänglich untersucht und ausgeschöpft werden, auch im Hinblick auf die volumetrische Modellierung. Die erzielten Ergebnisse wurden vorrangig mit dem Neuen Straßenentwurf (NSE) und zu Teilen mit dem Konstruktionsbaukasten ConKit sowie der Bestandsmodellierung untersucht. Durch den katalogbasierten Ansatz des NSE werden Objekte schnell generiert. Dies ist von Vorteil, wenn nach Vorgaben modelliert werden soll.

Mit der Handskizze als Modellierungsvorlage konnte in card_1 ein Projektmodell erstellt werden. Die beispielhaft ausgewählten Klassen sollten zu einer Kreuzungsszene kombiniert werden. Für die Modellierung boten sich deshalb der Neue Straßenentwurf (NSE) und die Werkzeuge der Bestandsmodellierung an. Vor allem der NSE wusste zu beeindrucken. Durch die dialoggeführte Abfrage der Parameter konnten in einer zuvor ungeahnten Geschwindigkeit zwei auf das Gelände angepasste und komplett ausgestattete Straßen modelliert werden, welche anschließend zu einer Kreuzung kombiniert wurden. Durch die Werkzeuge der Bestandsmodellierung und des ConKit wurden weitere ausgewählte Objekte in die Szene integriert.

Um die Zugehörigkeit der Objekte in card_1 zum Klassenkatalog zu dokumentieren, sollte den Objekten ihre Klasse als Attribut angehängt werden. Hierfür wurde das Nebenattributsystem genutzt. Für jede verwendete Klasse des Klassenkatalogs wurde eine eigene Nebenattributdefinition erstellt. Diese enthielt neben dem Namen und einer Vorbelegung, die den Klassennamen laut Klassenkatalog beinhaltete, auch einen externen Namen. Mit „bs_class“ wurde allen Objekten ein einheitlicher externer Name gegeben. Dieser wurde verwendet, um die vergebenen Nebenattribute im IFC-Schema auszulesen und zu untersuchen.

Nachdem die Modellierung und Attributierung abgeschlossen war, sollte das Anschauungsmodell im offenen Austauschformat IFC untersucht werden. Hierfür wurde es als IFC4x1-Modell exportiert, wobei jedoch auffiel, dass einige Objekte nicht dargestellt wurden. Es stellte sich heraus, dass die Objekte zwar ohne Geometrie exportiert wurden, jedoch trotzdem im IFC-Schema abgebildet werden. In IFC stellt die Geometrie neben den Beziehungen der Objekte untereinander lediglich eine Eigenschaft dar. Auch wenn die Objekte im IFC-Viewer nicht dargestellt werden, so sind sie trotzdem im IFC-Schema beschrieben und somit wurden auch deren Klassifikationen, welche in den Nebenattributen abgelegt wurden, abgebildet.

Das IFC-Schema bietet verschiedene Möglichkeiten zur Darstellung von Objekteigenschaften. So sind häufig genutzte Standardeigenschaften, wie Länge oder Breite, fest im Schema verankert. Da es aber eine unlösbare Aufgabe wäre, alle Eigenschaften, die von Nutzenden vergeben werden können, im Schema zu verankern, bietet IFC verschiedene Entitäten zur Vergabe eigener Eigenschaften an. Eine dieser Entitäten ist IfcPropertySingleValue, also eine einzelne Eigenschaft, die auch card_1 nutzt. Durch die Vergabe des einheitlichen externen Namens in den Nebenattributdefinitionen kann nun die Klassifikation in der IFC-Datei ausgelesen werden.

Durch die Nutzung von IfcPropertySingleValue kann trotz der Vergabe des eindeutigen externen Namens ein beliebiger Freitext eingegeben werden. Um nun zu überprüfen, ob das, was in der Nebenattributdefinition als vermeintliche Klasse eingetragen wurde, überhaupt Bestandteil des Klassenkataloges ist, wurde ein Programm in der Programmiersprache C# geschrieben. Es liest die von card_1 erzeugte IFC-Datei mittels der Bibliothek xbim aus und validiert diese gegen den Klassenkatalog, der als CSV-Datei eingelesen wurde. Anschließend wird angezeigt, ob die erzeugten Objektklassifizierungen einer Klasse des Klassenkataloges entsprechen. Diese Information kann entweder direkt auf der Konsole oder in einer Protokolldatei, zusammen mit einigen Statistiken zur Datei, ausgegeben werden.

Für die Abbildung von Klassifikationen über die Attributierung in IFC nutzt card_1 aktuell das IfcPropertySingleValue, was im Rahmen einer dynamischen Attributierung zur Abbildung von frei definierbaren Klassifikationssystemen eine gute Wahl ist. Um standardisierte Klassifikationssysteme mittels IFC besser erkennbar zu machen, bietet IFC mit ifcClassificationReference eine eigens für Klassifikationssysteme entwickelte Entität an. Diese könnte zukünftig über ein zusätzliches Feld mit dem Namen „Klassifikationen“ in den Nebenattributdefinitionen implementiert werden.

Im Rahmen der Bachelorarbeit konnte festgestellt werden, dass eine Umsetzung der Klassifizierung mit Softwarelösungen wie card_1 auch praktisch umsetzbar ist. Im Gesamtergebnis der Arbeit lassen sich folgende Aspekte festhalten: Unter Verwendung des Neuen Straßenentwurfes wurde ein Anschauungsmodell modelliert, der gesamte Prozess detailliert in einem Modellierungshandbuch festgehalten und die Objekte durch die Nutzung von Nebenattributen nach dem buildingSMART „BIM-Klassenkatalog der Verkehrswege 2.0“ klassifiziert.

Der Artikel erschien erstmals im Kundenmagazin der IB&T Software GmbH.

Die Bachelorarbeit und das Modellierungshandbuch sind im Volltext unter folgender URL abrufbar: https://nbn-resolving.org/urn:nbn:de:bsz:520-qucosa2-913036

Betreuer der Arbeit:
Prof. Dr. Christian Clemen (Hochschule für Technik und Wirtschaft Dresden)
M. Eng. Jacqueline Eggert (IB&T Software GmbH)