IFC: Schnittstelle zur BIM-Welt

23. Oktober 2020 Mehr

Ohne IFC-Schnittstelle gibt es keine Big oder Open BIM-Projekte. Was leistet das wichtigste BIM-Datenaustauschformat, wo liegen die Grenzen und was muss man beim Im- und Export beachten?

Der Fachplaner erhält vom Architekt digitale Projektdaten, die er allerdings nicht oder nur fehlerhaft in das eigene CAD-Programm einlesen kann. Deshalb werden sie notgedrungen neu erstellt und mit eigenen Informationen ergänzt. Diese gehen an den Architekt zurück, werden von ihm geprüft und wichtige Informationen manuell in das eigene CAD-Programm übernommen. Ein Planungs-Szenario aus prähistorischen EDV-Zeiten? Leider nicht! Dass in digitaler Form übernommene Pläne von Tragwerks- oder TGA-Planern, Energieberatern oder Bauphysikern neu erstellt werden müssen, ist eher die Regel als die Ausnahme. Weil Fehler beim Import entstehen oder Daten verloren gehen und eine Anpassung der Importdaten an das eigene Programm aufwendiger wäre als eine Neueingabe, geschieht das Jahr für Jahr viele tausend Male. Schätzungen zufolge könnten bis zu 20 Prozent an Planungskosten eingespart werden, gäbe es leistungsfähigere Schnittstellen und Datenaustauschformate.

 

In der BIM-Planung werden nicht 2D-Pläne, sondern 3D-Gebäudemodelle fachübergreifend per IFC-Datenformat übertragen.
In der BIM-Planung werden nicht 2D-Pläne, sondern 3D-Gebäudemodelle fachübergreifend per IFC-Datenformat übertragen. © Autodesk, Network Rail and Jacobs

 

Keine Kooperation ohne Datenaustausch

Datenaustauschformate sorgen dafür, dass ein Programm eines bestimmten Herstellers die Daten eines von einem anderen Hersteller stammenden Programms lesen, gegebenenfalls kommentieren und ändern kann. Austauschformate haben allerdings ein Problem: Sie müssen sich als „Vermittler“ zwischen zwei unterschiedlichen Programm-Welten auf einen kleinsten gemeinsamen Nenner einigen, damit der Datenaustausch funktioniert. Deshalb ist er prinzipiell mit Datenverlusten verbunden und die ausgetauschten Informationen verfügen nicht mehr über die Qualität und „Intelligenz“ des Quellformats. Beim Austausch von Texten oder Bildern ist das weniger problematisch, bei CAD- oder BIM-Daten aber sehr wohl. Aktuelle CAD- und BIM-Programme sind objektorientiert. Das bedeutet, dass Bauwerksmodelle nicht aus „dummen“ Linien, Flächen oder 3D-Körpern bestehen, sondern aus „intelligenten“ Objekten wie Wänden, Stützen, Decken, Versorgungsleitungen und anderen Bauteilen. Sie sind parametrisierbar, kennen ihre wechselseitigen Beziehungen, wissen, was sie sind, welche technischen Kennwerte sie haben, was sie kosten und so weiter. Überträgt man diese Bauteile mit den herkömmlichen CAD-Austauschformaten wie DXF, DWG oder DGN, gehen diese Informationen verloren, weil diese Datenformate nur geometrische 2D- und 3D-Informationen speichern.

 

IFC-Daten beschreiben Gebäudemodelle nach einer logisch aufgebauten, baumartigen Struktur. © Autodesk
IFC-Daten beschreiben Gebäudemodelle nach einer logisch aufgebauten, baumartigen Struktur. © Autodesk

 

Vom Geometrie- zum Objektdatenaustausch

Mit der BIM-Planungsmethode stehen nicht mehr Pläne im Zentrum des Informationsaustausches, sondern Gebäudedatenmodelle. Deshalb wurde ein neues Austauschformat notwendig, das neben der Grafik auch Bauteil- oder Objektdaten übertragen kann. 1996, noch lange vor BIM, wurde mit den Industry Foundation Classes (IFC) ein offener, internationaler Standard für den softwareübergreifenden Austausch von Bauwerksdatenmodellen vorgestellt, ursprünglich von der Industrieallianz für Inter­operabilität, heute bekannt als buildingSMART International. Hervorgegangen ist das IFC-Datenformat aus den STEP-Standard (Standard for the Exchange of Product Data), einem in der Maschinenbau- und Automobilindustrie verbreiteten Format zum Austausch produktdefinierender Objektdaten. Seit 2017 ist mit der DIN EN ISO 16739 IFC ab der Version 4 auch offiziell das europäische Datenformat für den Austausch von Geometrien und Bauteileigenschaften eines BIM-Modells zwischen Softwareanwendungen verschiedener Hersteller.

Vom IFC-Datenformat abgebildet, werden Gebäudestrukturen und logische Wechselbeziehungen, zugehörige Eigenschaften (Attribute) sowie Geometrien. Ausgetauscht werden IFC-Informationen über Dateien mit der Endung IFC, die über einen ASCII-Editor geöffnet, gelesen und modifiziert werden können. Gebräuchlich sind auch komprimierte IFC-Dateien (IFCZIP) und IFC-Dateien im XML-Standard (IFCXML) für den Austausch mit Berechnungsprogrammen, die kein IFC unterstützen. Seit Einführung des IFC-Standards wurden sukzessive neue Versionen entwickelt, wovon erst die Version IFC 2×3 in der Praxis eine nennenswerte Verbreitung gefunden hat. Sie wird inzwischen von den meisten Programmen für CAD, Tragwerksplanung, Gebäudetechnik, Mengen- und Kostenermittlung, Bauphysik oder CAFM unterstützt und daher am häufigsten verwendet. Der 2014 eingeführte Nachfolger IFC4 enthält viele Verbesserungen und Erweiterungen, etwa von IFC-Klassen, von Modell View Definitions (s.u.) etc. IFC 4 wird derzeit zwar nur von einigen Software-Anbietern unterstützt, soll IFC 2×3 aber sukzessive ablösen. In Vorbereitung ist bereits die Version IFC 5, die Erweiterungen vor allem für den Infrastrukturbau enthalten soll (siehe: https://technical.buildingsmart.org/standards/ifc/ifc-schema-specifications/ifc-release-notes).

 

Beim IFC-Export komplexer Bauteile wie mehrschichtiger Wände müssen neben der Geometrie eine Vielzahl an Bauteildaten übergeben werden. © Autodesk
Beim IFC-Export komplexer Bauteile wie mehrschichtiger Wände müssen neben der Geometrie eine Vielzahl an Bauteildaten übergeben werden. © Autodesk

 

Wie sind IFC-Daten aufgebaut?

IFC-Daten beschreiben Gebäudemodelle nach einer vordefinierten, logisch aufgebauten, baumartigen Struktur: ifcProject (Projekt), ifcSite (Grundstück), ifcBuilding (Gebäude), ifcBuildingStorey (Geschoss), ifcBuildingElements (Gebäudebauteile). Gebäudebauteile werden wiederum in sogenannte Modellelemente oder IFC-Klassen strukturiert. Zu den Architektur-Modellelementen gehören beispielsweise ifcWall (Wand), ifcSlab (Decke) oder ifcStair (Treppe). Beispiele aus der TGA sind ifcBoiler (Heizkessel) oder ifcPipeSegment (Rohr) und aus der Tragwerksplanung ifcReinforceingBar (Bewehrungsstab) oder ifcReinforceingMesh (Bewehrungsmatte). Daneben existieren auch allgemeine IFC-Klassen, wie zum Beispiel ifcBuildingElementProxy für nicht definierte, individuelle Bauteile. Da es hinsichtlich des Datenvolumens und der Verarbeitungsgeschwindigkeit sinnvoll ist, in IFC-Dateien nur jene Bauwerksinformationen abzubilden, die auch tatsächlich benötigt werden, beschreiben sogenannte Modell View Definitions (MVD) eine Teilmenge der umfangreichen IFC-Datenstruktur. MVDs bilden also eine Art Informationsfilter, die bestimmte Inhalte aus den IFC-Modellen exportieren und damit die in der Praxis auftretenden Austauschszenarien unterstützen. Eingesetzt werden sie in Form von Einstellungen beim Export und Import von IFC-Daten. MVDs entscheiden darüber, für welchen Zweck eine IFC-Datei verwendet wird. Soll beispielsweise das BIM-Architekturmodell für die Energieanalyse genutzt werden, wählt der Architekt die passende MVD. Dabei werden nur die benötigten Informationen wie Gebäudehülle, Räume und U-Werte exportiert. Für die TGA-Planung werden Informationen zu Elementen der Gebäudetechnik wie Heizung, Lüftung/Klima oder Elektro benötigt. CAFM-Systeme setzen Raum- und Bauteilinformationen zu Nutzungsflächen, zum Brandschutz oder zur Wartung voraus und so weiter. MVD’s werden gemeinsam mit der IFC-Version für den Datenaustausch festgelegt. Die aktuell am häufigsten verwendete MVD für den Austausch von Gebäudemodellen zwischen Architekten, TGA- und Tragwerksplanern, Bauphysikern und Gebäude-Energieberatern ist die IFC 2×3 Coordination View 2.0. Parallel zur Version IFC4 wurde speziell für die Übergabe energetisch relevanter Daten die Energy Analysis View definiert, die aufgrund der geringen Verbreitung von IFC4 allerdings praktisch noch keine Rolle spielt. Eine Übersicht aktueller MVDs finden Sie hier: https://technical.buildingsmart.org/standards/mvd/mvd-database

 

Übergabeprobleme aufgrund falsch modellierter oder editierter Bauteile und Bauteilanschlüsse lassen sich durch softwarespezifische Modellierungsrichtlinien vermeiden. © Graphisoft Deutschland
Übergabeprobleme aufgrund falsch modellierter oder editierter Bauteile und Bauteilanschlüsse lassen sich durch softwarespezifische Modellierungsrichtlinien vermeiden.
© Graphisoft Deutschland

 

Herausforderungen beim IFC-Datenaustausch

In der Praxis kam und kommt es insbesondere beim Austausch über ältere IFC-Versionen immer wieder zu Übertragungsfehlern: Komplexere Bauteile wie mehrschichtige Wände, Wanddurchbrüche, Treppen oder Rampen etc. werden falsch, unvollständig oder überhaupt nicht übertragen. In einigen Fällen resultieren Fehler allerdings nicht aus den durchaus vorhandenen Unzulänglichkeiten des IFC-Datenformats, sondern aus falsch deklarierten oder unsauber modellierten, respektive editierten Bauteilen. Das fängt schon bei der Wand an: Wo beginnt, wo endet sie? Wie sieht der Wand­anschluss im Detail aus? Sind Raumgeometrien oder Raumflächen und ihre Eigenschaften korrekt definiert? Gilt das auch für Installationsschächte, Hohlräume unter abgehängten Decken etc.? Werden diese und weitere Details bei der BIM-Modellierung nicht beachtet, kommt es zwangsläufig zu Auswertungs- und Übergabefehlern. Auch eine nicht regelkonforme Bearbeitung eines Standard-Bauteils kann schnell zu Fehlern führen, etwa wenn nicht mit den dafür vorgesehenen Werkzeugen in eine Geschossdecke eine Öffnung oder ein Gefälle eingefügt wird. Geometrien werden dann beim IFC-Export oder ­-Import falsch interpretiert und sind dadurch nicht mehr mit den gewohnten Werkzeugen bearbeitbar oder auswertbar. Häufig fehlen BIM-Programmen auch wichtige Standard-Bauteile, die vom Anwender dann durch andere Bauteile oder frei definierte Objekte ersetzt werden. Als Folge werden beim IFC-Export falsche Elementtypen übertragen. Deshalb bieten manche CAD/BIM-Programme die Möglichkeit, Bauteilen den gewünschten IFC-Typ zuzuordnen. Einige Hersteller von CAD/BIM-Software haben für Anwender zusätzlich BIM-Modellierungsregeln entwickelt, die sich teilweise an Richtlinien, etwa an der VDI-Richtlinie 2552, Blatt 3 orientieren. Diese erläutern, mit welchen Werkzeugen und Klassifizierungen Bauteile zu modellieren sind, damit man ein Modell erhält, das anderen Programmen für bestimmte Zwecke weiterverwendet werden kann. Ein Beispiel ist die Graphisoft-Modellierungsrichtlinie (Download: www.graphisoft.at/open-bim/open-bim-funktioniert).

 

Tragwerksplaner benötigen tragende Gebäudeelemente, Öffnungen oder Durchbrüche, EnEV- und Bauphysik-Software benötigten Informationen zur Gebäudehülle, zu Räumen und U-Werten. © Hottgenroth, ETU
Tragwerksplaner benötigen tragende Gebäudeelemente, Öffnungen oder Durchbrüche, EnEV- und Bauphysik-Software benötigten Informationen zur Gebäudehülle, zu Räumen und U-Werten. © Hottgenroth, ETU

 

Tipps für den IFC-Export und ­-Import

Die Qualität des IFC-Datenaustausches hängt neben der Modellqualität natürlich auch von der Qualität der IFC-Schnittstelle ab, von der IFC-Version, von den programmspezifischen Export-Einstellungen, von den Modell View Definitions und so weiter. Eine gewisse Sicherheit für den Anwender über die Qualität einer IFC-Schnittstelle geben auch die seit 2010 nach dem überarbeiteten Verfahren 2.0 durchgeführten buildingSMART-Zertifizierungen für die Version IFC 2×3, die nach IFC-Import und ‑Export, beim Export zusätzlich nach Fachdisziplinen unterschieden werden. Eine aktuelle Übersicht über bisher zertifizierte Softwareprodukte finden Sie hier: buildingsmart.org/compliance/certified-software.

Für die Wahl der richtigen Einstellungen beim Exportieren einer IFC-Datei ist entscheidend, dass bereits vorher der Verwendungszweck feststeht: Wird sie „nur“ für Koordinationszwecke eingesetzt oder muss sie in einer anderen BIM-Software weiterbearbeitet werden? Auch der Detaillierungsgrad spielt eine Rolle. Bauteile sollten nur in speziellen Fällen mit einem hohen geometrischen Detailierungsgrad exportiert werden, da der Datenumfang dann erheblich ansteigt. In den meisten Fällen genügt ein niedriger Detailierungsgrad. Für die Planung und Koordination von Durchbrüchen hat sich die Nutzung von Platzhaltern bewährt, den sogenannten „Provision for Void“-Objekten. Diese lassen sich zwischen Fachmodellen inklusive aller notwendigen Informationen sowie Abmessungen austauschen. Für die Übertragung komplexer Geometrien empfiehlt sich die Design Transfer View der Version IFC 4 mit Verbesserungen im Bereich der Geometrieübersetzung. Die IFC 4 Reference View wurde speziell für Referenz-Arbeitsabläufe konzipiert, beispielsweise für Kollisionskontrollen.
Grundsätzlich gilt: bevor eine IFC-Datei an Planungspartner weitergeben wird, ist es sinnvoll, das Exportergebnis vorher zu überprüfen. Dazu werden spezielle IFC-Viewer angeboten, mit denen die Bauwerksstruktur, An- oder Aufsichten, das 3D-Modell und die Eigenschaften von Bauteilen betrachtet werden können (z.B. Autodesk Navisworks, BIM Vision, FZK Viewer, Solibri Model Viewer oder Tekla BIM-Sight). Die Einstellungsmöglichkeiten beim IFC-Import beschränken sich auf den Import in das native Format des jeweiligen BIM-Programms oder als Referenz, respektive Link. Während ersteres eine Weiterbearbeitung der Importdaten ermöglicht, aber auch länger dauert, aufwendiger und fehleranfälliger ist, wird der schnellere und fehlertolerantere Link-Import vor allem für die Koordination von BIM-Fachmodellen genutzt. Manche BIM-Programme bieten zusätzlich die Möglichkeit, Teile des verlinkten Modells nativ zu importieren und weiterzubearbeiten. Diese und weitere Hinweise zum IFC-Export und Import sind teilweise auch auf Hersteller-Webseiten oder in Handbüchern der jeweiligen CAD/BIM-Programme enthalten.

 

In der Praxis wird IFC weniger für den Datenaustausch, sondern eher für die Koordination von Fachmodellen und für Kollisionsprüfungen genutzt. © Building Smart
In der Praxis wird IFC weniger für den Datenaustausch, sondern eher für die Koordination von Fachmodellen und für Kollisionsprüfungen genutzt. © Building Smart

 

Fazit: Open BIM kann funktionieren, …

… wenn sich alle an die Regeln halten. Zwar ist der Datenaustausch per IFC – wie über alle anderen Austauschformate auch – kein idealer Prozess, da Bauwerksmodelle beim Export in das IFC-Format einen Teil ihrer Intelligenz einbüßen. Außerdem werden beim IFC-Export Daten dupliziert, was Redundanzfehler begünstigt. Dennoch kann ein importiertes IFC-Modell eine brauchbare Grundlage für die weitere Planung sein, wenn Modellier-Regeln und IFC-Exporteinstellungen beachtet werden. Dass Open BIM per IFC funktionieren kann, hat auch der CAD-AVA-Datenaustausch-Test von Graphisoft belegt, der fast ausschließlich über das IFC-Austauschformat realisiert wurde. Schwächen hat das IFC-Format im Austausch zwischen Programmen unterschiedlicher Kategorien und Fachdisziplinen, aber auch zwischen Programmen derselben Disziplin, etwa zwischen zwei unterschiedlichen Architektur-CAD, TGA-CAD- oder CAFM-Programmen. Deshalb wird IFC derzeit weniger für den Datenaustausch, sondern eher für die Koordination und den Abgleich von Fachmodellen sowie für Kollisionsprüfungen genutzt. Die Entwicklung neuer IFC-Versionen, die sukzessive Optimierung der programmspezifischen IFC-Schnittstellen lassen aber auf Besserung hoffen.

 

Links, Literaturhinweise und Quellen

IFC-Basisinfos
https://blogs.autodesk.com/bimblog/if  

Baunetz Wissen BIM
www.baunetzwissen.de/bim                  

buildingSmart Österreich
www.buildingsmart.co.at                       

buildingSmart International
www.buildingsmart.org                       

Autodesk (Hrsg.): Revit IFC Handbuch. Ausführliche Anleitung für den Umgang mit IFC-Dateien, Eigenverlag, München 2018, Download: www.autodesk.de/campaigns/interoperability/ifc-handbuch
Hausknecht, K., Liebich, T.: BIM-Kompendium. Building Information Modeling als neue Planungsmethode, Fraunhofer IRB Verlag, 2. überarbeitete und erweiterte Auflage, Stuttgart 2020
Köbler, K.: Untersuchung der IFC-gestützten Modellübertragung zur Ableitung von Modellierempfehlungen für Architekten, Masterarbeit an der TU München, 2017, Download: https://publications.cms.bgu.tum.de/theses/2017_Koebler.pdf

 

Text: Marian Behaneck

 

 

Kategorie: EDV, Kolumnen