„Geometrie ist nur die Eintrittskarte zu BIM“ sagte der Doktor der Informatik in meiner BIM-Expertenschulung. Dass IFC deutlich mehr ist als Geometrie und Attribute durfte ich in einem meiner Projekte auf die harte Tour lernen. Im Folgenden ein Erfahrungsbericht.

Es gibt ausschweifende Handreichungen verschiedenster CAD-Softwarelösungen dazu, wie modelliert werden muss, damit die Modelle dem benötigten Detailgrad entsprechen. Außerdem setzt sich immer mehr die Erkenntnis in den Köpfen der Anwender durch, dass die Anreicherung von Modellen mit Informationen das eigentlich spannende an BIM ist. Aber wieso bewertet der Projektsteuerer nun meine eingereichten IFC-Modelle als ungenügend, habe ich mich dann gefragt. Sieht im Solibri schick aus, alle Fachmodelle passen zusammen und die vorgegebenen Eigenschaften sind auch noch da. Was will man mehr?

Grundstruktur IFC

Um dies zu ergründen verlangt es einen tieferen Blick unter die Motorhaube der IFC-Struktur. Auch als „User“ ist es wichtig zu wissen, dass im IFC-Datenmodell Informationen vererbt und Entitäten miteinander referenziert werden. Das Bauteil „Rohr“ schwebt also nicht frei im Raum, sondern gehört zu einem Geschoss (IfcBuildingStorey), das wiederum zu einem Gebäude gehört (IfcBuilding), das wiederum zu einer Liegenschaft gehört (IfcSite). Jedes einzelne Bauteil verfügt also über eine Vielzahl an Verweisen. Umso wichtiger ist es, dass die Grundstruktur stimmt. Außerdem hatte ich schon den Fall, dass durch den Import von IFC-Gebäudemodellen der Architekten wiederum beim Export der IFC mehrere Gebäude in der Struktur erschienen, obwohl es in dem Projekt nur eines gab.

Beispiel für überflüssige Gebäude in einer IFC-Datei (aus LVZ CAD mit Solibri geöffnet)

Identifikatoren von Bauteilen

Durch die eben beschriebene Referenzierung der Bauteile untereinander ergibt sich die logische Schlussfolgerung, dass alle Bauteile eineindeutig identifizierbar sein müssen. Das wird über die sogenannten GUIDs gelöst. Leider kann es beim Export der IFC-Datei dazu kommen, dass es doppelte oder sogar fehlerhafte GUIDs gibt. Das Schema der GUIDs ist nämlich genau von BuildingSmart definiert (Link). Doppelte oder fehlerhafte GUIDs werden beim Öffnen in einen Viewer-Programm erstmal nicht bemerkt. Das Hauptproblem liegt bei der Weiterverwendung von IFCs. So beziehen sich zum Beispiel BCF-Issues auf die GUIDs der Bauteile. Ist der Identifikator fehlerhaft laufen auch die BCF-Issues ins Leere.

Duplikate und Lücken

Wem ist es nicht schon mal passiert, dass man sich verklickt und das gleiche Bauteil zweimal an derselben Stelle absetzt? Diesen Fehler lässt das IFC-Datenmodell ohne Probleme zu, denn die Bauteile haben unterschiedliche GUIDs und sind deshalb nicht identisch. Allerdings führen Duplikate zu ungewünschten Mengenmehrungen, falls das Modell für die Mengen- und Massenermittlung genutzt werden soll. Duplikate sind mit dem Auge fast unmöglich zu finden, können aber mit Abfragen z.B. im Solibri aufgespürt werden.

Ein etwas verzwickteres Thema sind Lücken und offene Enden z.B. in Rohrnetzen. Mithilfe von Solibri kann man etwa prüfen, ob jedes Bauteil mit mindestens einem weiteren verbunden ist. Diese Verbindung wird im IFC-Datenmodell über die Entität IfcDistributionPort definiert (Link). Diese Information ist allerdings kein muss und ist wahrscheinlich auch wegen des zusätzlichen Programmierungsaufwands erst in wenigen TGA-Softwarelösungen implementiert. In diesem Fall kann man leider keine automatisierte Suche nutzen, es bleibt nur die visuelle Prüfung. Allerdings ist es in beiden Fällen schwer zu bewerten, ob es sich nun tatsächlich um einen Planungsfehler handelt oder ob sich manche Details in der Autorensoftware konstruktiv einfach nicht darstellen lassen. Die Autorensoftware selbst lässt üblicherweise nur eine Berechnung zu, wenn die Netze durchgängig und korrekt angeschlossen sind. Wenn die Netze dann aber nicht korrekt ins 3D übersetzt bzw. bestimmte Anschlusssituationen nicht dargestellt werden, muss der Modellprüfer wohl darauf vertrauen, dass der Planer nicht gepfuscht hat oder in den bereitgestellten Plänen nochmal dieses Detail prüfen.

Beispiel für verbundene Netze in IFC (Regenwasser-Rohrleitungen aus Plancal Nova in Solibri)

Proxy-Elemente

Wie mancher Leser vielleicht schon weiß, wird jedes Modellobjekt bei der Erstellung der IFC einem Bauteiltypen zugeordnet. Alle Wände, egal welches Material, gehören z.B. zum Typen IfcWall. Kompliziertere Namen bekommt die technische Gebäudeausrüstung; z.B. IfcDistributionElement, zu dem alle Bauteile gehören, die in irgendeiner Form ein Medium verteilen. Im schlimmsten Fall ist das Bauteil gar keinem der IFC-Bauteiltypen zugeordnet und bekommt deshalb den Typ IfcProxyElement. Es ist also ein reines 3D-Element und weiß nicht, was für ein Bauteiltyp es ist.

Innerhalb der Autorensoftware gibt es üblicherweise eine Tabelle (sog. Mapping), bei dem festgelegt ist, welches Bauteil zu welchem IFC-Bauteiltypen gehört. Leider bieten manche Softwarelösungen nicht die Möglichkeit, diese Tabelle zu manipulieren. Letzten Endes ist es im ersten Moment nicht weiter tragisch, wenn es ein paar Proxy-Elemente in der IFC-Datei gibt. Ich als Nutzer kann ja vielleicht sogar an der Geometrie erkennen, was das darstellen soll oder das Bauteil über andere Informationen identifizieren. Allerdings ist ja der Clou an der IFC-Datei, dass die Bauteile „wissen“ was sie sind und somit für zusätzliche Anwendungsfälle weiterverwendet werden können. Denn Software-Lösungen zur Auswertung können oft nichts mit Proxys anfangen.

Manipulierbares Mapping mit Bauteilen und zugehöriger IFC-Klasse in Plancal Nova.

Modellursprung

Dass mehrere Fachmodelle nach dem Einladen ins Solibri auch übereinander liegen und den gleichen Einfügepunkt haben, ist auf jeden Fall ein Kraftakt zum Beginn eines jeden BIM-Projekts. Wenn dies jedoch geschafft ist, kann man erstmal beruhigt weiterarbeiten. Die meisten CAD-Programme bieten es jedoch an, auch die geographischen Koordinaten des Projekts zu hinterlegen. Auch diese werden in die IFC-Datei geschrieben. Die einzelnen Teilmodelle der Disziplinen können also perfekt zusammenpassen, allerdings können die geographischen Daten ganz unterschiedlich sein (je nachdem, was der Bearbeiter eingegeben hat).

Anzeige der Modellkoordinaten (IFCSite) in Solibri

Ob solche Spitzfindigkeiten nun für den Projekterfolg notwendig sind sei dahingestellt. Jedoch sollte man wissen, worauf man zu achten hat, wenn der Bauherr eine saubere IFC-Struktur einfordert.

Du bist immer noch am Lesen? Dich hat die Theorie nicht abgeschreckt? Und du willst jetzt endlich wissen, wie du IFCs nachträglich bearbeiten kannst? Dann freu dich schon mal auf den kommenden Artikel.

Checkliste IFC-Struktur.pdf

Susanne Bendrien

Schon früh entstand bei Susanne das Interesse an BIM-Themen durch ein interdisziplinäres Modul an der HTWK Leipzig im Rahmen Ihres Studiums Energie-, Gebäude- und Umwelttechnik. Folgerichtig hat sie sich auch in ihrer Masterarbeit „BIM in der technischen Gebäudeausrüstung“ in diesem Themenbereich bewegt. Über Ländergrenzen hinweg hat sie Ihr BIM-Interesse getragen, so dass sie ein Jahr in Japans ältestem Generalplanungsbüro (Nikken Sekkei) auch mit BIM-Software gearbeitet hat. Ihre Leidenschaft für Sprachen und fremde Kulturen konnte sie da perfekt zusammenbringen. In Deutschland zurück wurde sie auf der Suche nach einem Ingenieurbüro mit vertieftem BIM-Know-how bei der S&P Gruppe fündig. Als HLS Fachplanerin und BIM-Koordinatorin betreut sie mehrere BIM-Projekte.

Das könnte dich auch interessieren...

Der Blog von BIM-Experten für BIM-Experten und solche, die es werden wollen!