BIM Grundlagen und Begriffe

Was bedeutet BIM und warum sind Grundlagen nötig?

Roman: Moin moin aus Hamburg und herzlich willkommen beim einzigen Podcast zum Thema Projektmanagement in der TGA. Sören Janson und ich, Roman Fritsches, wir sitzen an der Bar. Uns ist aufgefallen: Wir haben jetzt acht Folgen BIM gemacht und noch gar keine Grundlagen gelegt. Das ziehen wir jetzt nach. Was bedeutet BIM, und was bedeuten diese ganzen Drei-Buchstaben-Kürzel, von denen es rund zwei Dutzend gibt? In den Interviews ist uns aufgefallen, dass diese Grundlage vielleicht fehlt — wir sind davon ausgegangen, dass die Hörer alle tief im Thema und Experten sind. Wer die Grundlagen schon hat, kann diese Folge überspringen.

Sören: Es geht Schlag auf Schlag weiter. Aber um die Reihe abzuschließen, ist es sinnvoll, dieses Versäumnis nachzuholen und mit den Begrifflichkeiten anzufangen.

Roman: BIM heißt Building Information Modeling. Das sagt schon ganz gut: Es geht nicht um 3D-Modelle, sondern um Informationen am Modell. Wir versuchen nicht, in 3D etwas zu machen, was wir früher in 2D gemacht haben — der Schwerpunkt sind die Informationen, die an den Bauteilen hängen. Wir denken in Bauteilen. Das merkt man auch bei Revit oder anderer Software, die das nativ kann: Die denken nicht in Linien, sondern in Bauteilen, und die haben Informationen.

Sören: BIM ist also das Werkzeug, unter dem das Thema aktuell behandelt wird.

Roman: Genau. Integrale Planung ist die Methode, das ist das, was dahintersteckt. Und das Thema agiles Projektmanagement hängt eng damit zusammen. Integrales Planen ist die Methode und das, was mit dem Werkzeug BIM befördert werden soll.

Sören: Also die Digitalisierung des Bauens.

Roman: Das Werkzeug ermöglicht auch die Modellzusammenführung: Ich führe verschiedene Fachmodelle zusammen — das Modell der Tragwerksplanung, der Objektplanung, des Energieberaters — und ermögliche so die Überprüfung, nicht nur die Kollisionsplanung.

Was regeln AIA und BAP im BIM-Prozess?

Sören: Damit ich loslegen kann, bin ich schon bei den nächsten Abkürzungen: den AIA und dem BAP. Fangen wir mit den AIA an — die kamen zuerst, oder?

Roman: Die AIA kamen zuerst, dann der BAP. AIA steht für Auftraggeber-Informationsanforderungen. Darin werden die Anforderungen und Vorstellungen an das Modell und an den Informationsaustausch definiert — und welche Ziele ich mit BIM überhaupt verfolge. Warum will ich das Werkzeug benutzen? Diese Ziele werden in Anwendungsfällen beschrieben.

Sören: Das ist das erste Dokument, bevor es überhaupt digital losgeht. Da werden auch behandelt: welche Software genutzt wird, Dateiaustauschformate, Einfügepunkte und wörtlich, was die Ziele sind. Und als Antwort darauf gibt es den BAP.

Roman: Genau, den BIM-Abwicklungsplan. Darin definieren die Planer wiederum, wie sie das umsetzen. Es ist die Idee von Lastenheft und Pflichtenheft: Das Lastenheft sagt, das musst du tun; das Pflichtenheft sagt, ich habe mich committet, ich tue das.

Sören: In der alten Welt wären es Lastenheft und Pflichtenheft, in der neuen heißen sie AIA und BAP.

Roman: Spannend finde ich: Wir Fachplaner können sehr gut mit Anlagen zum BAP arbeiten. Ich habe gerade eine von Professor Wimmer bekommen, der in einem Dreiseiter beschreibt, wie das Architekturmodell aussehen soll. Ihm ist wichtig, dass es erst einmal einfach ist — in den ersten Leistungsphasen nur einfache Informationen, zum Beispiel der Wandaufbau nicht als Schichtenmodell, sondern nur als Block, und in diesem Block Wand steckt dann ein U-Wert. Das ist für ihn in Leistungsphase 2 zentral. In den nächsten Leistungsphasen kann ich über Level of Detail und Level of Information weitergehen.

Wofür stehen LOD und LOI?

Sören: LOD heißt Level of Detail — also wie detailliert ich etwas zeige. Wie eben beschrieben: den Wandaufbau nur als einfachen Block oder wirklich in Schichten mit Dämmung, unterschieden ob Beton oder Ziegelstein. Und Level of Information war das andere.

Roman: Genau, das ist die Frage, wie viele Attribute es gibt und wie sie strukturiert sind.

Sören: Welche Informationen im Endeffekt noch dranhängen.

Roman: An den Bauteilen. Beim Level of Detail ist das klassische Beispiel: Wenn ich ein Bauteil habe, das aus 3.000 Punkten oder Bauteilen zusammengesetzt ist, dann sprengt das das Modell, es wird mit Detailinformationen überfrachtet. Beliebtes Beispiel ist auch die Plakette vom Hersteller: ein Lüftungsgerät als Bauteil, und die Plakette besteht aus 4.000 Vektoren, die wahnsinnig viel Speicherplatz fressen.

Sören: Das wird oft als Anlage zum AIA herangefügt, wo beschrieben ist,

Roman: wann, in welcher Leistungsphase, welches Level of Detail und welches Level of Information ins Modell soll. Ein wichtiger Begriff.

Was unterscheidet Little BIM von Big BIM?

Roman: Was wir bisher gar nicht besprochen haben, sind die Begriffe Little BIM und Big BIM.

Sören: Im Deutschen ist die Übersetzung weit unspektakulärer. Bei einem Little BIM, einem kleinen BIM, wende nur ich beziehungsweise meine Unternehmung die BIM-Prozesse an. Ich habe kein offizielles BIM-Projekt, sondern nutze im Haus schon die entsprechende Software, bilde alles 3D-mäßig ab und wende weitere Anwendungsfälle an — in meiner geschlossenen TGA-Software.

Roman: Oder Softwares — ich habe zwei im Büro.

Sören: Auf jeden Fall heißt es: Ich als Einzelteilnehmer wende die Methodik BIM an, gar nicht zwangsläufig in Abstimmung mit den anderen Objekt- oder Fachplanern.

Roman: Und es ist ein Anfangspunkt. Wenn ich meine Elektro-, Heizungs-, Luft- und Sanitär-Software habe, tausche ich darüber mit dem IFC-Standard Daten aus — das wäre Little BIM.

Sören: Gerade, um für sich Erfahrungen zu sammeln, wenn es Neuland ist. Bei einem überschaubaren Projekt teste ich den einen oder anderen Anwendungsfall in-house, ohne es an die große Glocke zu hängen.

Roman: Eine super Trainingsumgebung — damit kann ich auch meine BIM-Fachkoordinatoren schulen und ausbilden. Und dann komme ich zum Gegenstück: Big BIM. Das heißt, alle Beteiligten bearbeiten ein Modell zusammen über die Schnittstelle IFC. Ich arbeite nicht innerhalb einer Software oder eines Büros, sondern nutze eine neutrale Schnittstelle und lasse jedem seine Software, die er nutzen möchte.

Sören: Das wird auch als Open BIM verstanden: Alle arbeiten mit dem Werkzeug BIM, jeder kann in seiner Software arbeiten, aber man hat ein einheitliches, zentrales Austauschformat.

Roman: Sebastian Theißen hat das nochmal erläutert: Wenn ich eine Insellösung mache und nur ein spezifisches Datenformat nutze, hätte ich Little Closed BIM — ein geschlossenes Modell, aber immerhin mit Gebäudeinformationen. Öffne ich es über öffentliche Datenformate, hätte ich Little Open BIM. Ich könnte auch keine Insellösung, sondern eine integrierte Lösung machen, aber zum Beispiel nur mit Revit arbeiten. Das ist ein problematisches Thema, weil ich da einen Industrievorteil von Autodesk sehe: Viele Projekte sagen, nutzt bitte Revit, lieber TGA-Fachplaner — dann muss ich mir Revit kaufen und die Aufsätze dazu, und das ist vielleicht nicht so gut wie die spezialisierten Fachsoftwares.

Sören: Darum geht es hier nicht. Es geht darum, welche Möglichkeiten es mit der Planungsmethode BIM gibt. Revit ist als Marktteilnehmer ein Closed BIM — alles in einer Software, in der zwar gewerkeübergreifend zusammengearbeitet wird, aber mit der zentralen Vorgabe, diese oder jene Software zu nutzen. Es muss ja nicht Revit sein.

Roman: Muss nicht Revit sein. Die anderen wollen ihre Software auch verkaufen. Unser aller Ziel ist Open Big BIM: Jeder kann seine Software benutzen, es gibt einen Markt, der sich spezialisieren kann — und die Softwarehersteller sind aus meiner Sicht schon sehr spezialisiert für die jeweilige Fachplanung und Objektplanung. Dann können alle zusammen über eine Schnittstelle, ein Austauschformat, arbeiten.

Was ist IFC und warum ist eine offene Schnittstelle so wichtig?

Sören: Die Schnittstelle ist dann IFC. Und warum heißt das eigentlich IFC? Industry Foundation Classes.

Roman: Genau.

Sören: Was ist der Vorteil? Man könnte ja auch argumentieren: Wenn ich ein geschlossenes System habe, das alles verfügbar hat — Architektur, Tragwerksplanung, TGA —, ist es mir doch fast egal.

Roman: Wenn ich keine standardisierte Schnittstelle habe, habe ich nicht die Möglichkeit, dass alle Marktteilnehmer mit ihren eigenen Produkten antreten. Dann habe ich keine Konkurrenz, sondern einen Monopolisten, der sagt: Hier ist die Software. Diese perfekte Software, die ohne Schnittstelle alle Gewerke und alle Fachplanungen beinhaltet, müsste es ja erst einmal geben. Und ich glaube, das ist wie in der Baubranche generell: Wir wollen keine großen Einzelplayer, sondern eine atomisierte Branche, in der sich jeder mit dem darstellen kann, was er besonders gut kann — und dann gibt es viele Experten.

Sören: Das ist auch das Ziel von IFC: diesen Standard zu schaffen. Über buildingSMART arbeiten schlaue Köpfe daran, die Nomenklatur fortzuschreiben, wie ein IFC-Modell beziehungsweise eine IFC-Datei auszusehen hat, damit sie über Schranken hinaus funktioniert.

Roman: Genau, damit die Schnittstellen definiert sind. Wir sehen aber, das ist immer noch zu breit — die Schnittstelle wird jährlich revisioniert und verbessert.

Sören: Ich weiß gar nicht, in welcher Version wir gerade sind.

Roman: Das müssen wir mal nachschauen. Bei buildingSMART wird auf der Homepage geteilt, welche Softwares dafür zertifiziert sind. buildingSMART hat viele Chapter und Untergruppen, die sich regelmäßig treffen, auch eine in Hamburg. Wir treffen uns zum Thema Schnittstellen, und wir stellen immer noch fest, dass ein großes Thema die Attributzuordnung und die Produktfamilien sind. Da ist noch viel Arbeit zu tun, gerade die TGA-Bauteile so zu beschreiben, dass sie gleichwertig ausgetauscht werden können. Eine Lüftungszentrale müsste immer folgende Attribute haben —

Sören: mit demselben Aufbau.

Roman: — und dann müsste jeder Hersteller sein Lüftungsgerät mit exakt diesen Attributen und dieser Zuordnung beschreiben und auf eine Plattform bringen. Dazu ist die VDI 3805 interessant: Da ist beschrieben, was Produkthersteller liefern müssen, um ihre Produkte als BIM-Modell zur Verfügung zu stellen.

Sören: Welche VDI nochmal?

Roman: 3805. Das ist hochinteressant und auch ein Appell. Ich merke, dass bei der Standardisierung der Produktdaten und der Attribute, die diese Bauteile beschreiben, noch einiges zu tun ist. Für TGA-Planer ist das ein Nachteil, weil sie viel komplexere Daten im Modell haben als ein Architekt. Der Architekt hat seine Wände, Betongüten, Stahlmengen und Massen. Bei uns hat jedes Bauteil einen hochkomplexen Katalog an Informationen. Wenn das nicht standardisiert ist, können wir nicht neutral ausschreiben, nicht sauber planen und das verbaute Produkt nicht bis zum Schluss im BIM-Modell verfolgen.

Sören: Aber der Anfang ist über IFC geschafft.

Roman: Der Anfang ist vor ich weiß nicht wie vielen Jahren über IFC geschaffen worden.

Sören: Es entwickelt sich weiter.

Roman: Darauf haben sich alle geeinigt, und das wird so bleiben. Die Industry Foundation Classes sind gesetzt — Austauschformat für BIM-Modelle und Produktdaten. Es gibt noch die BIM-Rollen, BIM-Manager und so weiter, das hatten wir ausführlich in einer Folge, und die Anwendungsfälle haben wir auch besprochen.

Sören: Damit sind wir unserem Versäumnis nachgekommen und haben die Einleitungsfolge nachgesetzt. Ich bestelle uns noch eine Runde.

Roman: Wir glauben, dass das Thema BIM in einer anderen Folge noch einen kleinen Punkt mitbekommt. Aber mit den BIM-Wochen sind wir erstmal durch.

Sören: Das denke ich auch. Schöne Wochen.