IFC als universales Datenaustauschformat

IFC als universales Datenaustauschformat

Die Industry Foundation Classes IFC nehmen als Standard deutlich Fahrt auf. Zum einen ist IFC5 in Planung und bald als erste Vorab-Version zu erwarten. Parallel haben sich jüngst neue Arbeitsgruppen gefunden, die versuchen, den openBIM Gedanken mit Hilfe des IFC-Standards in neuen Bereichen zu etablieren.

So rief der Verband buildingSMART kürzlich zu einer Arbeitsgruppe auf, die IFC für  „Site, Landscape, and Urban Planning“ erweitern. Ihr Ziel ist, sämtliche Außenflächen im übergreifenden IFC-Standard einzufügen.

Doch wie sinnvoll ist so ein Vorhaben überhaupt? Brauchen wir solch einen erweiterten Standard wirklich?

Und wie fügt er sich in BIM und CAFM sinnvoll ein?

Möglichkeit ist im Unterbau schon da

Was mit den neuen Arbeitsgruppen beschrieben werden soll, lässt sich technisch schon heute in IFC abbilden. Nutzer können in IFC aktuell Objekte, die nicht im Katalog enthalten sind, als so genannte IFC-Proxys definieren. Diese erhalten individuelle Eigenschaftsmerkmale, so genannte IFC Propertysets. Das Problem: Durch die nach Gusto vergebenen Eigenschaften ist der semantisch transparente und damit verlässliche Datenaustausch zwischen verschiedenen Partnern nicht mehr gegeben.

Dass sich die neuen IFC-Arbeitsgruppen bilden hat also mit einem Manko des Standards zu tun: IFC sei zurzeit noch sehr gebäudezentrisch ausgelegt, schreibt buildingSMART selbstkritisch in der Ankündigung der Landscape-Arbeitsgruppe. Eine explizite Semantik für die Beschreibung von Außenanlagen fehle. Weder Bäume noch Außenmöblierung, Wege und ihre Beläge, Wasserleitungen und Kanalisation ließen sich mit den verfügbaren Elementen darstellen. Und auch nicht die Struktur der Landschaft oder in ihr befindliche Objekte wie zum Beispiel Gewässer und Seen.

IFC-Arbeitsgruppen überall

Analog lässt sich diese Kritik auch auf die weiteren Bereiche übertragen, zu denen sich in den letzten Monaten Arbeitsgruppen zusammen fanden. Dazu gehören solche für Verkehrswege, Brücken, Tunnel, Bahntrassen oder für Flughäfen. Einigen sich diese Gruppen auf verbindliche Ergebnisse, würde der IFC-Standard die Beschreibung von deutlich mehr bebauter wie gestalteter Umwelt und Infrastruktur ermöglichen.

Auch Branchen beginnen sich zu engagieren. Ein Beispiel ist die Fertigteilindustrie. Sie bildete die Arbeitsgruppe IFC Precast und bearbeitet die Modellierung von Einbauteilen. Als Fernziel wäre es möglich, jedes Fertigteil eindeutig zu identifizieren. Und zwar von der Planung über die Produktion durch Maschinen, die  IFC-Daten zur Steuerung nutzen, bis zur Montage. Hierdurch wäre Nachvollziehbarkeit gegeben – nicht bloß über den Gebäude-Lebenszyklus, sondern über den erweiterten Bauteil-Lebenszyklus hinweg.

Mit der Erweiterung zu IFC5 verfolgt buildingSMART ein weiteres wichtiges Ziel: mehr standardisierte Workflows zu schaffen. Grund ist, dass durch die zunehmende Verbreitung von BIM eine immer größere Zahl von Anwendern aus immer mehr Gewerken und Bereichen die BIM-Methode nutzt. Damit auch zukünftig der Datenaustausch klappt, müsse das Anforderungsprofil an den Beschreibungs-Standard erweitert werden, argumentiert der Verband.

Nur: Wie relevant ist solch eine Erweiterung wirklich, zumal mit Blick auf BIM und CAFM? Und zu fragen ist auch: Wem nutzten die Erweiterungen, wenn schon der jetzige IFC4 Standard – zum Beispiel in Deutschland – nur rudimentär eingesetzt wird?

Die Crux: Wen juckt’s?

Ich gebe zu, die Frage ist falsch gestellt. Unbestreitbar ist ein Standard immer zu begrüßen und grundsätzlich relevant. Er hilft, Inhalte verbindlich für verschiedene Nutzer bereit zu halten. Zu fragen ist daher, wie die Umsetzung hierzulande verbessert werden kann. Grundlegendes ist durchaus zu finden:

Zum Beispiel sind in den meisten BIM-Modellen Daten für infrastrukturelles CAFM zu finden. Bei technischen Anlagen bleiben die Möglichkeiten von IFC dagegen fast immer ungenutzt. Und das, obwohl es innerhalb des IFC „Domain Layers“ hinreichende Möglichkeiten gibt, auch hier zu modellieren.

BIM-Modelle, die ich heute vorliegen habe, zeigen die klaffenden Lücken: Planer verwenden oft die übergeordnete IFC-Entitäten, statt die konkrete Untertypen einzusetzen. In der Elektro/Klimatechnik wird alles pauschal als IFCFlowTerminal ausgewiesen, auch wenn es sich um eine einfache Lampe oder um einen Heizkörper handelt. Oder es werden nicht sinnvolle Entitäten gewählt. So kommt es vor, dass im Bereich Brandschutz die RWA-Klappen häufig als IFCWindow und damit als Fenster ausgewiesen werden.

Oder es wird der generische Weg über ein IfcBuildingElementProxy gewählt so dass zum Beispiel Aufzüge dann nicht mehr als IfcTransportElement vom Typ ELEVATOR zu erkennen sind.

Für CAFM und BIM sind die Erweiterungen von IFC und die Novellierung mit IFC5 ein guter und wünschenswerter Fortschritt. Aber damit die Erweiterungen Früchte tragen, müssen ihre Möglichkeiten konsequent genutzt werden. Fachplaner werden sich hierfür selten freiwillig durch die Tiefen der Nomenklatur klicken. Flanierend sollte es eine vollständige Übersetzungsmatrix im Unternehmen geben, die jeden Bauteiltyp der dementsprechenden IFC Entität zuweist.

Feindifferenzierung aktiv einfordern

Die nötige Feindifferenzierung muss aktiv eingefordert werden –  sei es vom Bauherrn, sei es vom späteren Nutzer und Betreiber, sei es von Partnern, die im Zuge des BIM-Prozesses auf klare Informationen angewiesen sind.

Aufpassen muss man auch bei Planungssoftware. Sie bevorzugt per Default leider auch nur allgemeine Entitäten. Erst durch Parametrierung der entsprechenden BIM Authoring Tools wie Revit oder Allplan werden vernünftige IFC Exporte erzeugt.

BIM-Manager als Torwächter

Dass die Angaben aus IFC korrekt im BIM-Modell abgelegt sind, liegt in der Verantwortung des BIM-Managers. Er hat zu überwachen, dass die geplante Nomenklatur des Projektes eingehalten wird und sie bei Missachtung aktiv einzufordern.

Immerhin: Die kommenden Erweiterungen werden dazu beitragen, das IFC als universales Datenformat Einzug in noch mehr Branchen findet. Damit wird das Ziel von openBIM, als zentrale Datenbasis und zentrales Austauschformat zu fungieren, wahrscheinlicher. Und damit einhergehen dürfte eine zunehmende Disziplinierung aller Beteiligten. Profitieren würden jeder, ob mit Blick auf Gewerke und Kollaboration oder mit Blick auf die Internationalisierung von Projekten.

Damit kann ich nur dazu raten: Spielen wir alle mit. Dann ist der Standard bereits heute mit IFC4 und auch zukünftig als IFC5 für BIM wie CAFM sehr sinnvoll.

Beste Grüße

IFC als universales Datenaustauschformat signature KUN RIB IMS
IMS-Team-Marcel-Kunzmann-
Beitrag erfasst von: Marcel Kunzmann

Marcel ist Technologieberater und Ideen-Geber für unsere Software. Er eruiert das technisch Machbare und testet kommende Techniken, zum Beispiel AR und IoT. Nach Feierabend schwingt er sich auf’s Rad – sein analoger Ausgleich zu digitalen Höchstleistungen.

Blog
Previous reading
Alles mit nur einer Software- CAFM bei der ALNO AG in Pfullendorf
Next reading
Weihnachten: Elektrisch, aber wartungsfrei!