Immer wieder ist bei der Nutzung der Arbeitsweise BIM die Rede von Modell-Typen wie Planungsmodell, Abrechnungsmodell und as-built-Modell. In meinem heutigen Blog-Beitrag stelle ich dar, wie diese Modell-Typen zu unterscheiden sind und wie sich die Modelle beim Übergang zwischen den Projektphasen verändern. Dabei geht es in diesem Beitrag im Wesentlichen darum, wie Modelle aufzubauen sind, damit sie die erforderliche Metamorphose im BIM-Prozess unbeschadet überstehen!

Unterschiedliche Ansprüche an ein Modell

Erfahrungen aus der Praxis zeigen deutlich auf: Planende, ausführende Baufirmen und Bauherren in der abschließenden Nutzungsphase des Bauwerkes haben unterschiedliche Ansprüche an ein Modell.

Zunächst einmal gehen viele am BIM-Prozess Beteiligte davon aus, dass der Level of Detail (LOD) und der Level of Information (LOI) eines Modells im Laufe der Zeit zunehmend steigen. Immer mehr Informationen und Details werden in das Modell integriert – so scheint es zumindest auf den ersten Blick.

In Wirklichkeit ist es jedoch so, dass im Bauprozess viele Information benötigt werden, die die Nutzer des Bauwerkes später nicht mehr interessieren. Teilweise ist es so, dass Daten auch gar nicht weitergegeben werden sollen. Solche  Informationen werden schon heute in verknüpften Datenbanken von ERP-Systemen gespeichert und nur bei Bedarf am Ende der Baumaßnahme in das Modell übergeben.

Auch Anforderungen an die Geometrie unterscheiden sich

Etwas komplizierter ist es mit der Geometrie eines Modells. Auch hier muss die Betrachtung sehr differenziert erfolgen. Oft steigt bei der Geometrie der Bedarf nach größerer Detaillierung im Laufe der Zeit. Gemäß meiner Erfahrung ist es allerdings nicht immer so. 

Ein sehr praxisnahes Beispiel dafür ist die Betrachtung von Schächten und Haltungen im Kanalbau. Planende, die sich im Wesentlichen für hydraulische Berechnungen interessieren, sehen Schächte nur als vertikale Zylinder an. Und für sie sind Rohre der Haltung lediglich schräg im Raum liegenden Zylinder. Erst die ausführende Baufirma setzt sich damit auseinander, aus welchen konkreten Bauteilen die genannten Objekte erstellt werden sollen. Diese Informationen sind wichtig für die Bestellung und den Bauprozess. Doch schon bei der Abrechnung ist der geforderte Detaillierungsgrad geringer, weil die Rohre nicht nach Stück, sondern in aller Regel Rohrleitungen nach laufenden Metern abgerechnet werden. Gedanklich wird demnach erneut nur ein Zylinder als Platzhalter für die gesamte Rohrleitung verwendet.

Ein kleiner Zusatz zu diesem Aspekt: Auch an GIS-Systeme werden derzeit nicht die konkreten Rohre, sondern der Ersatz-Zylinder übergeben. Zum Beispiel mit Hilfe der ISYBAU-Schnittstelle.

BIM-Objekt als Container mit wechselnden Eigenschaften

Aus den bisher angestellten Überlegungen wird deutlich, dass einzelne Volumenkörper, die Planende, Bauausführende sowie Bauherren in ihrer jeweiligen 3D-Software sehen, nicht zwangsweise ein logisches BIM-Objekt repräsentieren. Es kann vorkommen, dass Gruppen von 3D-Körpern das logische Objekt darstellen. Innerhalb dieser Strukturen ist es möglich, dass sich der Detaillierungsgrad im Laufe der Baumaßnahme bzw. im Laufe der späten Nutzung ändert. Das kann in beide Richtungen passieren. Das heißt, aus einem 3D-Körper innerhalb des logischen Objektes kann eine Gruppe von Körpern werden – oder umgekehrt.

Betrachtende neigen dazu, das konkrete Bauteil, welches sie in 3D sehen, als das jeweilige Objekt zu verstehen. Allerdings ist im Allgemeinen ein BIM-Objekt im Grunde lediglich ein Container mit wechselnden Eigenschaften und wechselnden Geometrien und kann auch aus vielen einzelnen Körpern bestehen. Unveränderlich an diesem Container sind nur der Name und seine ID, häufig handelt es sich dabei um eine GUID (Globally Unique Identifier).

Dazu habe ich mehrere Beispiele: Während eine Mauerwerks-Wand im kompletten BIM-Prozess immer aus einem Körper besteht, kann ein Kanalrohr zeitweise aus vielen Unterobjekten bestehen, wie Rohren, Gelenkstücken und Abzweigen. Diese Unterobjekte können gleichfalls Attribute besitzen, die für den Bauprozess wichtig sind, später aber oft verworfen werden. Im Hochbau gibt es aber auch Objekte wie Fenster, die aus unterschiedlichen Teilen wie Rahmen und Glas bestehen. Deren Detaillierung muss erhalten bleiben, da die Teil-Objekte sich in ihren Eigenschaften wie Material und Hersteller unterscheiden. Bei einer Kanalhaltung genügt es, Detail-Informationen im as-built-Modell an dem Platzhalter-Zylinder zu speichern, da diese globalen Informationen wie Material und Rohrdurchmesser in aller Regel für alle einzelnen Rohre gleich sind.

Mit Blick auf den bisherigen Gedankengang wird deutlich: Die notwendige Metamorphose eines Modells über seinen Lebenszyklus erfordert zum einen eine sehr strukturierte Erstellung durch die Planenden. Zum anderen werden Schnittstellen benötigt, die diesen Anforderungen gerecht werden. Und nicht zuletzt braucht man Software-Produkte, die in der Lage sind, den Level of Detail (LOD) im Bauprozess wie erfordert zu ändern. Beispiele für geeignete Schnittstellen sind die Formate IFC sowie CPI-XML, denn sie unterstützen sogenannte Composites. Darunter werden Objekte verstanden, die aus mehreren Teil-Objekten zusammengesetzt werden.

Mehraufwand durch kluge Software-Verwendung minimieren

Meine Forderung lautet: Planende sollten Modelle liefern, die zusammengesetzte Objekte unterstützt. Denn wenn eine bauausführende Firma vom Planungsbüro ein Modell bekommt, das zwar gut aussieht, aber alle oben im Text beispielhaft genannten Objekte und Teilobjekte unstrukturiert in einer langen Liste aufführt, ist das vollkommen unzureichend. Ein solches Modell ist maximal zur Prüfung der Mengen in der Kalkulation geeignet – für weitere Prozessschritte muss es stark überarbeitet oder neu erstellt werden. Dazu nochmals eine Erfahrung aus der Praxis: Oft ist das Neuerstellen eines Modells durch das Bauunternehmen einfacher, als das Planungsmodell auszudünnen, eigentlich  zusammengesetzte Objekte aus losen Einzelteilen neu zu gruppieren und Geometriefehler zu beheben. In jedem Fall handelt es sich dabei um einen Aufwand, der vermieden werden kann.

Herausforderungen im Straßenbau

Und jetzt noch ein Exkurs in das Gewerk Straßenbau, wo wir derzeit die aus meiner Sicht schwierigste Situation vorfinden. Mit fast allen im Straßenbau verwendeten CAD-Systemen werden Volumenkörper abschnittsweise zwischen Querprofilen erstellt. Das heißt, dass logische Objekte wie Asphalt- oder Frostschutzschichten immer in viele Stücke zerlegt sind. In jeweils kleine, zehn oder 20 Meter lange Bereiche zwischen zwei Stationen.

Solche Modelle sind für eine Weiterverwendung in der Projektabwicklung durch Baubetriebe ungünstig. Zum Beispiel lassen sich Horizonte für eine GNSS-Maschinensteuerung nicht direkt daraus ableiten. Umso wichtiger im Straßenbau sind begleitende digitale Daten zur schnellen Rekonstruktion von Flächenmodellen (Digitale Geländemodelle – DGM) oder zur Erstellung von neuen durchgehenden Volumenkörpern. Je nach Projekt und verwendeter Software lassen sich Achsen, Gradienten, Querneigungs- und Rampenbänder erstellen, für die es schon seit EDV-Urzeiten Dateiformate wie KA40 gibt, die diese klassischen Datenobjekte beschreiben. Bevorzugt sollten jedoch moderne Formate wie LandXML verwendet werden. Auf IFC-Road muss man meiner Meinung jedoch nicht warten, die vorhandenen, zuvor genannten Schnittstellen sind ausreichend.

Bei nichtlinearen Bauvorhaben wie Kreisverkehre und Einmündungen kommen Nutzer mit den oben genannten Formaten hingegen an ihre Grenzen. Die gute Nachricht lautet jedoch: In den meisten Fällen sind 3D-Polylinien, die Fahrbahnränder und Knicke in der Oberfläche beschreiben, die erste Wahl zur geometrisch eindeutigen Beschreibung der Straßenkörper. In Verbindung mit eindeutigen Regelquerschnitten genügt dafür die schnöde Übergabe als DXF- oder DWG-Datei. Aus diesen 3D-Linien können Anwender mit geeigneter Software sehr schnell und einfach passende und durchgängige Flächen- und Volumenmodelle erstellen.

Zusammenfassung

Wenn in einem Planungsmodell die aus Abschnitten zwischen den Querprofilen bestehenden Teilstücke in einem Container zusammengefasst sind, können Nutzer diese Teile ganz leicht durch das neue Gesamtmodell ersetzen.    

Sind im Modell jedoch alle Teile einzelne Objekte, entsteht ein Bruch im BIM-Workflow. Denn es gibt kein Gegenüber, dem das neue Gesamtmodell als Geometrie zugewiesen werden kann. Solche Planungsmodelle sollten Bauunternehmen zwingend ablehnen.

Mir ist es im Hinblick auf eine wirkliche Durchgängigkeit des BIM-Prozesses wichtig, dass allen Beteiligten klar ist, was genau unter dem eigentlichen BIM-Objekt zu verstehen ist und wie mit Änderungen in der Geometrie innerhalb der Bauphase umzugehen ist.

Ein vollständiger BIM-Prozess – der dem Anspruch genügt, dass alle vom Planenden in das Modell gegebenen Informationen am Ende auch beim Nutzer des Bauwerks ankommen – kann nur funktionieren, wenn die von mir oben beschriebene Arbeitsweise von allen Beteiligten eingehalten wird.

Der nächste Beitrag wird sich damit beschäftigen, welche Funktion welcher Modelltyp – Planungsmodell, Vertragsmodell, as-built-Modell – im BIM-Prozess in vertraglicher und rechtlicher Hinsicht einnehmen sollte.

Frank Kocher