Das openBIM-Austauschformat IFC

Szenen aus dem Planeralltag: Der Statiker erhält vom Architekten Projektdaten, die sich allerdings nicht oder nur fehlerhaft in das eigene CAD-
Programm einlesen lassen. Deshalb werden sie neu erstellt und mit statisch relevanten Informationen ergänzt. Diese gehen an den Architekten zurück, werden von ihm geprüft und wichtige Informationen manuell in das eigene CAD-Programm übernommen. Ein Szenario aus prähistorischen EDV-
Zeiten? Leider nicht! In digitaler Form transferierte Pläne werden von Tragwerks-, TGA- oder anderen Fachplanern häufig neu gezeichnet. Weil Fehler beim Import entstehen oder Daten verloren gehen und eine Anpassung der Importdaten an das eigene Programm aufwendiger wäre als eine Neueingabe. Jahr für Jahr geschieht das viele tausend Mal. Schätzungen zufolge könnten bis zu 20 % an Planungskosten eingespart werden, gäbe es leistungsfähigere Schnittstellen und Datenaustauschformate.

Keine Kooperation ohne Datenaustausch

Datenaustauschformate sorgen dafür, dass ein Programm eines bestimmten Herstellers die Daten eines anderen Programms eines anderen Herstellers lesen, gegebenenfalls kommentieren und ändern kann. Austauschformate haben allerdings ein Problem: Sie müssen sich als „Vermittler“ zwischen zwei unterschiedlichen Programmwel­ten auf den kleinsten gemeinsamen Nenner einigen, damit der Datenaustausch klappt. 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“ Ob­jekten wie Wänden, Decken, Treppen und anderen Bauteilen. Sie sind parametrisierbar, kennen ihre wechselseitigen Beziehungen, wissen, was sie sind, welche technischen Kenn­werte sie haben, was sie kosten und so weiter. Überträgt man diese Bauteile mit den herkömmlichen CAD-­Aus­tausch­formaten wie DXF, DWG oder DGN, gehen diese Informationen verloren, weil diese Datenformate nur geometrische 2D- und 3D-Informationen speichern.

Vom Geometrie- zum Objektdatenaustausch

Mit der BIM-Planungsmethode stehen keine Pläne mehr 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 Standard für den softwareübergreifenden Austausch von Bauwerksdatenmodellen vorgestellt, ursprünglich von der Industrieallianz für Interoperabilität, heute bekannt als buildingSMART International. Hervorgegangen ist das IFC-Datenformat aus dem 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 auch offiziell das europäische Datenformat für den Austausch von Geometrien und Daten eines BIM-­Modells zwischen Softwareanwendungen verschiedener Hersteller. Vom IFC-­Datenformat abgebildet werden Gebäudestrukturen und logische Wechselbeziehungen, zugehörige Eigenschaften (Attribute) sowie Geo­me­trien. Ausgetauscht werden IFC-Informationen über Dateien mit der Endung IFC. Gebräuchlich sind auch gezipte IFC-Dateien (IFCZIP) und IFC-Dateien im XML-Standard (IFCXML). Seit Einführung des IFC-Standards wurden sukzessive neue Versionen entwickelt, wovon erst die Version „IFC 2x3“ 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 derzeit 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 „IFC2x3“ aber sukzessive ablösen. In Vorbereitung ist bereits die Version „IFC 5“, die Erweiterungen vor allem für den Infrastrukturbau enthalten soll.

Wie sind IFC-Daten aufgebaut?

IFC-Daten beschreiben Gebäudemodelle nach einer vordefinierten, logisch aufgebauten, baumartigen Struktur: ifc
Project (Projekt), ifcSite (Grundstück), ifcBuilding (Gebäude), ifcBuildingStorey (Geschoss), ifcBuildingElements (Gebäudebauteile). Gebäude­bau­teile 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 z.B. ifcBuildingElementProxy für nicht definierte, beliebige 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. Sie dienen dazu, die in der Praxis auftretenden unterschiedlichen Austausch­szenarien zu unterstützen. Eingesetzt werden sie in Form von Einstellungen beim Export- und Import von IFC-Daten. MVD entscheiden darüber, für welchen Zweck eine IFC-Datei verwendet wird. Für die Tragwerksplanung werden beispielsweise Informationen zu tragenden Gebäudeelementen, Öffnungen oder Durchbrüchen benötigt, thermische Simulationen setzen Daten zu Raumvolumen, Außenwänden und Wärmedämmwerten, CAFM-Systeme vor allem Raum- und Bauteilinformationen zu Nutzungsflächen, zum Brandschutz oder zur Wartung voraus. MVD werden gemeinsam mit der IFC-­Version für den Datenaustausch festgelegt. Die aktuell am häufigsten ver-
wendete MVD ist die „IFC 2x3 Coordination View 2.0“ für den Austausch von Gebäudemodellen zwischen Architekten, Gebäudetechnikern und Tragwerksplanern.

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. Häufig resultieren Fehler allerdings nicht aus den durchaus vorhandenen Unzulänglichkeiten des IFC-Datenformats, sondern aus unsauber modellierten oder editierten Bauteilen. Das fängt schon bei der Wand an: Wo beginnt, wo endet sie? Wie sieht der Wandanschluss 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 Standardbauteils kann schnell zu Fehlern führen. Geometrien werden dann beim IFC-Export oder ­-Import falsch interpretiert und sind dadurch nicht mehr mit den gewohnten Werkzeugen bearbeit- oder auswertbar. Häufig fehlen BIM-Programmen auch wichtige Standardbauteile, die vom Anwender dann durch andere Bauteile oder frei definierte Objekte ersetzt werden. Als Folge werden beim IFC-Export falsche Elementtypen übertragen. Deshalb bie­ten manche CAD-/BIM-Programme die Möglichkeit, Bauteilen den gewünschten IFC-Typ zuzuordnen. Einige CAD-/BIM-Hersteller 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 in den anderen Programmen weiterverwendet werden kann.

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

Die Qualität des IFC-Datenaustausches hängt neben der Modellqualität auch von der Qualität der IFC-Schnittstelle ab, von der IFC-Version, von den programmspezifischen Exporteinstellungen, von den MVD 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 2x3“, die nach IFC-Import und ‑Export, beim Export zusätzlich nach ­Fachdisziplinen, unterschieden werden. Eine aktuelle Übersicht über bislang zertifizierte Softwareprodukte gibt es unter www.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 Detaillierungsgrad exportiert werden, da der Datenumfang sonst erheblich ansteigt. In den meisten Fällen genügt ein niedriger Detaillierungsgrad. 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 aus-
tauschen. 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 Referenzarbeitsablä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 Refe-
renz, 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 sind meist auch in den Hand­büchern der jeweiligen CAD-/BIM-Programme enthalten, inklusive mehr oder weniger umfang- und hilfreichen Tipps und Tricks zum IFC-Export und -Import.

Beispielhaft sei hier das „Revit IFC-­Handbuch“ von Autodesk genannt, aus dem auch die meisten Abbildungen des Beitrags stammen.

Fazit: openBIM mit IFC funktioniert!

Der IFC-Datenaustausch ist kein idealer Prozess, da das ursprüngliche Bauwerksmodell bereits beim Export in das IFC-Format einen Teil seiner „Intelligenz“ einbüßt. Außerdem werden Daten dupliziert, was Redundanzfehler befördert. Dennoch ist in vielen Fällen ein importiertes IFC-Modell eine gute Grundlage für die weitere Planung. Dass openBIM und der IFC-Datenaustausch funktionieren kann, hat kürzlich auch der CAD-AVA-Datenaustausch-Test von Graphisoft eindrucksvoll belegt, der fast ausschließlich über das IFC-Austauschformat realisiert wurde (www.
graphisoft.de/open-bim/open-bim-funktioniert).

Tatsächlich hat das IFC-Format Stärken vor allem im Austausch zwischen Programmen unterschiedlicher Kategorien und Fachdisziplinen.

Schwächen hat es dagegen beim Austausch zwischen Programmen derselben Disziplin, etwa zwischen verschiedenen Architektur-CAD-Programmen, mit CAFM-Programmen oder mit Tiefbau-CAD.

Mit der Entwicklung neuer IFC-Versionen und Modellierungsrichtlinien ist aber Besserung in Sicht.