Die Zukunft ist offen
Da es wahrscheinlich nie eine ganzheitliche Lösung geben wird, mit der sich die komplette Prozesslandschaft auf dem Weg von einer ersten Grundlagenermittlung bis in die Bewirtschaftung eines Gebäudes abbilden lässt, bedarf es offener Schnittstellen. Die Idee, den gesamten Lebenszyklus eines Bauwerks digital abzubilden, kann nur als erfolgreiche Zusammenarbeit mehrerer Softwareumgebungen funktionieren. Diese Erkenntnis führte in der Vergangenheit dazu, dass sich die wichtigsten Hersteller BIM-fähiger Softwarelösungen (für bspw. CAD, AVA und CAFM) für nicht-proprietäre Technologien wie IFC und BCF geöffnet haben. Zweifelsohne eine wichtige Basis für die grundsätzliche Machbarkeit offener Prozessstrukturen. Jedoch verrät der Realitätscheck, dass die praktische Implementierung der nötigen Anwendungsfälle vielerorts noch als Zukunftsvision auf dem Flipchart hängt.
Exakt dies wird sich in den kommenden Jahren ändern müssen. Wo heute noch Insellösungen wie „little BIM“ oder „closed BIM“ gerade so als Stand der Technik durchgehen, stehen zukünftig die Zeichen auf „big open BIM“, einer interdisziplinären Zusammenarbeit auf Basis neutraler Austauschformate. Dies lässt sich zum einen aus konkreten Handlungen prominenter Softwarehersteller ableiten, ganz aktuell etwa dem Beitritt von Autodesk zur Open Design Alliance. Zum anderen wird in Richtlinien zum Informationsaustausch in BIM-Projekten zunehmend Bezug auf die IFC nach DIN EN ISO 16739 und BCF genommen. Als Beispiele seien hier die Entwürfe VDI 2552 Blatt 9 (Klassifikationssysteme) und VDI 2552 Blatt 11.2 (Informationsaustauschanforderungen: Schlitz- und Durchbruchsplanung) genannt. Auch die DIN EN ISO 19650, obwohl weitgehend formatneutral geschrieben, lässt beim Leser zwischen den Zeilen wenig Zweifel daran, auf welcher Basis die Umsetzung der enthaltenen Konzepte empfohlen wird.
BIM-Anwendungsfälle und Model-View-Definition
Erhält man eine IFC-Datei von einem anderen Projektteilnehmer oder liefert man eigene Arbeitsstände, dann sollte zunächst geklärt sein, welchem Zweck diese Informationsübermittlung dient. Bestenfalls wurde in einem BIM-Abwicklungsplan eine konkrete Informationsbedarfstiefe definiert, sodass der Informationsbereitsteller dem Informationsempfänger exakt die benötigten Informationen für den angestrebten Anwendungsfall übermitteln kann. Gibt man nur eine Teilmenge eines Modells an den Empfänger, dann spricht man von einer Model-View-Definition (kurz: MVD, etwa Modellansichtsdefinition). Im Gegensatz zu einfachen Ansichtsfiltern, wie sie aus CAD-Anwendungen bekannt sind, lässt sich über eine MVD nicht bloß eine Ansicht auf das Modell generieren, sondern im Wesentlichen auch Art und Umfang der zu exportierenden geometrischen und alphanumerischen Informationen definieren. Beispielsweise kann so die Beschreibung einer Bauteilgeometrie in eine explizite Form (planare Randflächen) überführt werden oder die Menge der zu exportierenden Attribute auf die benötigten und bereits gesicherten Informationen begrenzt werden. Sagt man also, dass man für einen bestimmten Anwendungsfall eine IFC erwartet, dann ist damit eigentlich eine MVD gemeint.
Im Zuge der IFC-Entwicklung wurden einige standardisierte MVDs veröffentlicht, so zum Beispiel das prominente IFC 2x3 Coordination View 2.0, welches die zu Koordinationszwecken notwendige Teilmenge des IFC 2x3-Schemas definiert. Die meisten Umgebungen lassen darüber hinaus den Export mit vorgeschalteten Modellfiltern sowie die Verwendung von optionalen Export-Einstellungen zu, welche es in eingeschränkter Form erlauben, eigene MVDs zu definieren. Weiterhin kann der Nutzer über eine (manuelle) Klassifizierung die IFC-Klassen und Typen sowie eine Zuordnung typspezifischer Attributsätze feinabstimmen, sofern die verwendete Autorenumgebung sich nicht widerspruchsfrei auf das verwendete IFC-Schema abbilden lässt. Dieser Schritt stellt für die meisten Anwender jedoch aufgrund der Komplexität der Schnittstellen eine Herausforderung dar. Auch wenn eine gewisse Mächtigkeit der Schnittstellen nötig ist, um einen möglichst großen Umfang an Anwendungsfällen abzudecken, so reduzieren sich in der Praxis die Ein- und Ausgabeschritte auf die Verwendung vorher definierter Konfigurations-Profile. Letztlich ist es wie bei der Projektvorlage auch: Es muss einmal jemand im Unternehmen definieren, wie es aussehen soll. Die anderen Mitarbeiter verwenden diese Schablone dann einfach. Was den Umgang mit architektonischen Modellen betrifft, existieren bereits Abstimmungen verschiedener Autoren-Plattformen (beispielsweise das AddIn „IFC Model Exchange“ für den vereinfachten Austausch zwischen Archicad und Revit). Auf der TGA-Seite verstehen jedoch nach wie vor lediglich einige wenige fortgeschrittene Anwender die IFC-Schnittstelle von Revit in der nötigen Tiefe, um offene Planungsprozesse damit zu realisieren.
Warum ist also die Verwendung von IFC-basierten Workflows in der TGA so schwierig?
Nun, hat man den Anspruch ein semantisches bzw. durchgängig klassifiziertes Gebäudemodell abzubilden, bieten die IFC hunderte von standardisierten Klassen, Typen und Eigenschaftensätzen an, mit denen dies nahezu widerspruchsfrei bewerkstelligt werden kann. Eine Autorenumgebung wie Revit hat diesen Anspruch in der Tiefe erst einmal nicht. Hier reicht es aus, dass Bauteile aufgrund ihres groben Einsatzzwecks und ihres Editierverhaltens in Kategorien eingeteilt werden (beispielsweise als Wände, Decken, Rohrzubehör, HLS-Bauteile usw.). Aber genau dieser Umstand der nicht-eindeutigen maschinellen Übersetzbarkeit von IFC-Typen und deren Parametrik in Autorenumgebungen erfordert erhöhte Aufmerksamkeit, sowohl bei der Verwendung einer IFC als Konstruktions-Unterlage als auch beim Export einer IFC zur Weitergabe.
Damit ein Austausch von Informationen über offene Standards gelingt, müssen die Modelle also einer vereinbarten MVD genügen, d.h., Bauteile müssen korrekt klassifiziert und mit den benötigten Attributen versehen sein. Und die eingesetzte Software auf Sender- wie Empfängerseite muss in der Lage sein, die vorhandenen Informationen zu verarbeiten.
TGA-Modelle mit IFC koordinieren
Bevor wir erläutern, wie eigene IFC-Ausgaben erzeugt werden können, lassen Sie uns zunächst in das Thema einsteigen, indem wir zwei übliche Anwendungsfälle diskutieren, bei denen der TGA-Planer eine IFC als Planungsgrundlage empfängt.
Koordination unterschiedlicher Gewerke
Plant ein Büro nicht alle Gewerke in demselben Autorensystem oder sind an einem Projekt gar unterschiedliche TGA-Planer beteiligt, dann kann es vorkommen, dass als gemeinsamer Nenner IFC als Koordinationsgrundlage vereinbart wird. In diesem Fall sind Revit-Anwender in der Situation, dass sie den Planstand eines anderen TGA-Gewerks in die eigene Planung referenzieren müssen. Dazu bietet sich der Weg an, eine IFC-Datei zu verknüpfen. Bei diesem Vorgang erzeugt die IFC-Schnittstelle von Revit im Hintergrund ein Revit-Projekt, welches die Endung „.ifc.rvt“ trägt. Außerdem wird daneben eine Protokoll-Datei zur Fehlereingrenzung sowie eine gemeinsam genutzte Parameterdatei mit der Endung „.ifc.sharedparameters.txt“ erzeugt, die sich in Revit einstellen lässt, um gemeinsam genutzte Parameter-Definitionen im Projekt bekanntzumachen.
In unserem Beispiel betrachten wir eine Heizzentrale, welche mit LINEAR Design 3D Pipe&Power in AutoCAD konstruiert und als IFC 2x3 Coordination View 2.0 exportiert wurde. Unmittelbar nach der Verknüpfung in Revit sieht das Resultat zunächst enttäuschend aus. Wo im IFC-Betrachter noch leuchtende Farben die Rohrleitungssysteme unterscheidbar gemacht haben (Abbildung 2), sehen wir nach der Verknüpfung ein scheinbar vollständig schwarz eingefärbtes Netz (Abbildung 3). Allerdings ist diese Schwarzfärbung lediglich ein Darstellungsproblem. Betrachtet man einzelne Elemente aus der Nähe, dann offenbart sich, dass sich diese Färbung aus den Kanten der expliziten Geometriegenerierung ergibt. Nun ist es in Revit nicht möglich die Gitternetzlinien importierter Objekte über einen zentralen Mechanismus zu verstecken. Allerdings gibt es die Möglichkeit, Revit über die Verwendung von Filtern dazu zu bewegen, die Systeme entsprechend Ihrer System-Klassifizierung einzufärben.
Hierzu stellt man zunächst die eingangs erwähnte Parameter-Definitionsdatei mit der Endung „.ifc.sharedparameters.txt“ als gemeinsam genutzte Parameterdatei ein. Anschließend macht man den darin enthaltenen Parameter „IfcSystem“ als Exemplarparameter für die relevanten Kategorien bekannt. Die Klassifizierung in Revit-Kategorien sowie die konkrete Systemkennung eines Bauteils lässt sich durch Inspektion der Objekteigenschaften bewerkstelligen. Im vorliegenden Fall sollen Systeme mit den Bezeichnungen „Vorlauf“ und „Rücklauf“ gefiltert werden. In den Revit-Ansichtsüberschreibungen erstellt man hierzu regelbasierte Filter für die Rohrkategorien. Als Bedingung trägt man ein, dass das Attribut „IfcSystem“ dem Wert „Vorlauf“ bzw. „Rücklauf“ entsprechen muss. Ebenfalls überschreibt man die Linienfarbe für diese Filter nach Belieben.
Im Anschluss an die Definition der Filter sind nicht bloß die Farben der Kanten angenehmer, es ist auch möglich einzelne Systeme durch die Sichtbarkeits-Steuerung des zugehörigen Filters gezielt ein- und auszublenden (siehe Abbildung 4). In einer ähnlichen Art und Weise lassen sich auch Bauteillisten erstellen, bei denen Elemente in Verknüpfungen samt ihrer gemeinsam genutzten Parameter aufgelistet werden.
In Kürze
Nutzen Sie die automatisch generierte Textdatei mit der Endung „.ifc.sharedparameters.txt“ als Basis für die Erstellung von Ansichtsfiltern.
1. Machen Sie einen geeigneten Filter-Parameter an den relevanten Kategorien bekannt, z. B.
| Parameter | Bedeutung |
| IfcSystem | Systemzugehörigkeit („Vorlauf“, „Abluft“ etc.) |
| IfcExportAs | IFC-Klassifizierung („IfcPipeSegment“, „IfcBoiler“, „IfcTank“ etc.) |
| IfcSpatialContainer | Strukturell übergeordnetes Element (z. B. „Erdgeschoss“) |
2. Stellen Sie die Anzeige Ihrer Verknüpfung auf die Einstellung „nach Basisbauteilansicht“.
3. Erstellen Sie regelbasierte Filter, um die Sichtbarkeit und Darstellung klassifizierter Modellinhalte zu steuern.
IFC-Architektur als Unterlage
Ein weiterer Anwendungsfall, bei dem ein Modell via IFC als Unterlage referenziert wird, ist die Entwicklung eines TGA-Modells auf Basis einer vorhandenen Architektur. In diesem Fall dient die Architekturzeichnung mehreren Zwecken: Zum einen schafft das zugrunde liegende Modell ein Bezugssystem für die TGA-Modellierung und nachfolgende Koordinationsaufgaben wie die Schlitz- und Durchbruchsplanung. Zum anderen dient die Architektur als Raumbegrenzung für die MEP-Räume, welche benötigt werden, um Randbedingungen für die Auslegung anzugeben.
Bei der Arbeit mit IFC-Architekturen müssen zwei wesentliche Punkte beachtet werden: Zum einen müssen alle relevanten Bauteile sowie die Rauminformationen tatsächlich exportiert werden. Zum anderen müssen die exportierten Bauteile auch über korrekt eingestellte IFC-Klassen und Typen verfügen. Modelle, in denen lediglich korrekt aussehende Geometrien vorliegen, bei denen sich das Wesen und die Funktion der dargestellten Bauteile nicht aus einer Klassifizierung ableiten lässt, sind keine gute Ausgangsbasis.
Informationen
Für die meisten Anwendungsfälle auf Basis einer IFC-Architektur reicht es aus, wenn das Modell alle raumbegrenzenden Bauteile mit entsprechender Klassifizierung (z. B. IfcWalls) beinhaltet und Öffnungen bei Fenstern (IfcWindow) und Türen (IfcDoor) mit exportiert wurden. Sofern die IFC-Unterlage auch Raumobjekte (IfcSpace) mitbringt, lassen sich auf Basis einer IFC-Architektur mit der LINEAR-Lösung auch leicht MEP-Räume generieren und Daten aus dem Architekturmodell übertragen. So können die raumweisen Bedarfswerte (z. B. Luftmengen, thermische Lasten usw.) an die entsprechenden Raumobjekte geschrieben werden, sei es aus extern ermittelten Entwurfsvorgaben oder detaillierten Lastberechnungen (siehe LINEAR aktuell 1-2020, S. 22 ff. für Details).
Will man also eine aufwendige Nachmodellierung des Gebäudes vermeiden, dann ist eine wichtige Voraussetzung – neben den benötigten Geometrien – auch das Vorhandensein semantischer Informationen, z. B. IFC-Klasse und -Typ. Den Mindestumfang gilt es vor Beginn des Vorhabens zu vereinbaren.
Damit die oben angesprochene semantische Information nicht dem Import-Vorgang zum Opfer fällt, ist es wichtig, die Tabelle der IFC-Import-Zuordnungen korrekt einzustellen. Diese Tabelle macht IFC-Klassen und Typen mit entsprechenden Revit-Kategorien bekannt, dient also der Import-Funktion als Nachschlagewerk. Die angesprochene Tabelle wird zwar bei einer Revit-Installation mit sinnvollen Vorschlägen gefüllt angelegt, je nach verwendeter Architektur-Plattform und Exporteinstellungen kann es aber nötig sein, Einträge zu ergänzen oder Zuordnungen zu verändern. Ferner ist es möglich, nicht benötigte Modellinhalte über Angabe von „DontImport“ statt einer Revit-Kategorie für den Import zu ignorieren.
Nach einer Verknüpfung der IFC-Architektur-Unterlage fällt zunächst auf, dass die Fenster-Öffnungen, die eigentlich als Abzugskörper gedacht sind, in der Verknüpfung explizit als Objekte der Kategorie „Allgemeines Modell“ dargestellt werden. Öffnet man die Ansichtseigenschaften der Verknüpfung, dann stellt man weiterhin fest, dass diese Öffnungen von der Import-Routine auf der Unterkategorie „IfcOpeningElement“ abgelegt werden, welche leider nicht im übergeordneten Projekt exponiert ist (Abbildung 6).
Nun gibt es zwei Möglichkeiten, die Öffnungen zu verstecken. Zum einen kann man die Ansicht der Verknüpfung mit benutzerdefinierten Einstellungen überschreiben. Zum anderen kann man die Basisbauteilansicht verwenden und einen Sichtbarkeitsfilter, wie zuvor gezeigt anlegen, der Objekte der Kategorie „Allgemeines Modell“ mit dem Wert „IfcOpeningElement“ für das Klassifikations-Attribut „IfcExportAs“ filtert.
Zur MEP-Raumerstellung auf Basis einer IFC-Verknüpfung bietet sich die MEP-Räume-Funktionalität aus dem liNear Desktop an. Dieser ermittelt auf Basis der IfcSpace-Elemente die Raumkonturen und übernimmt Parameter wie Name/Nummer und beliebige IFC-Attribute in die korrespondierenden MEP-Räume. Weitere technische Randbedingungen lassen sich anschließend entweder über die Eigenschaftsdialoge eingeben oder mithilfe der LINEAR-Excel-Schnittstelle aus einem externen Raumbuch in das TGA-Modell übertragen.
TGA-Modelle nach IFC exportieren
Die Ausgabe einer IFC-Datei kann aus unterschiedlichen Motiven erfolgen. Beispiele wären unter anderem Dokumentationszwecke, die Modellkoordination, Visualisierungsaufgaben oder die Datenübergabe in verschiedenen Prozessschritten (z. B. frühe Kommunikation des übergeordneten Platzbedarfs für die TGA, Schlitz- und Durchbruchsplanung, Übergabe an GU, Leistungsverzeichnisse oder Mengenermittlungen). Aus diesem Grund ist es wichtig, dass die Anforderungen an die Inhalte und Qualitäten bereits im Vorfeld verabredet wurden. Die Revit-seitige IFC-Export-Schnittstelle bietet nun einen Satz an Möglichkeiten, die sich den Anwendern nicht unbedingt sofort erschließen. Im Folgenden wollen wir auf drei wichtige Punkte eingehen: Klassifizierungen, Eigenschaftensätze und Export-Einstellungen.
TIPP
Verwenden Sie Bauteillisten zur schnellen Überprüfung Ihrer MEP-Raumerzeugung.
- Übernehmen Sie Raumdaten mit liNear-Desktop aus Ihren IFC-Räumen in die korrespondierenden MEP-Räume.
- Erstellen Sie Bauteillisten mit den entsprechenden Feldern (z. B. Name, Nummer, Fläche).
- Verwenden Sie berechnete Spalten und bedingte Formatierungen, um Abweichungen sichtbar zu machen.
Beispiel: Prozentuale Abweichung der Raumflächen zwischen MEP- und Architektur-Räumen
Die Klassifizierungskaskade
Revit bietet standardmäßig diverse Mechanismen an, um Bauteile zu klassifizieren. Die einfachste Form der Klassifizierung bilden die Kategorien, in die Bauteile eingeordnet werden. Diese eher pragmatische Art der Unterscheidung ist eigentlich nur für die Autorenumgebung gedacht, da sich beispielsweise ein Fenster anders als ein Rohrzubehör verhält. Diese sehr grobe Einteilung stößt an ihre Grenzen, wenn es darum geht, eine feingliedrigere Zuordnung vorzunehmen, in diesem Fall für den korrekten IFC-Export.
Man erkennt die Schwierigkeit, wenn man sich die Tabelle der IFC-Exportklassen in Revit anschaut, die eine grobe Abbildung von Revit-Kategorien auf IFC-Klassen vornimmt. Die für TGA-Planer äußerst wichtige Revit-Kategorie „HLS-Bauteile“ wird hier beispielsweise standardmäßig auf „IfcBuildingElementProxy“ abgebildet, dem IFC-Äquivalent des „Allgemeinen Modells“. Damit fehlt einer wichtigen Klasse von Objekten eine konkrete semantische Zuordnung. Korrekterweise müsste man ebendiese HLS-Bauteile auf eine große Teilmenge der übergeordneten Klasse „IfcDistributionElement“ (haustechnische Komponenten) abbilden, welche unter anderem verschiedene Arten von Erzeugern, Speichern, Verbrauchern und Reglern umfasst.
Um das Export-Modell semantisch anzureichern, empfiehlt es sich also, eine genauere Klassifizierung vorzunehmen. Der hierfür reservierte Parametername ist „IfcExportAs“. Neuere Versionen der IFC-Schnittstellen verstehen weiterhin die Definition „IfcExportAs[Type]“, was dem Anwender ermöglicht, sowohl auf Exemplar- als auch auf Typ-Ebene zu klassifizieren. In jedem Fall ist darauf zu achten, dass jeder dieser Parameter nur einmal im Projekt vorkommt. Werden Familien aus verschiedenen Quellen verwendet, kann es vorkommen, dass diese Parameter bereits voreingestellt sind, sich jedoch in ihrer eindeutigen Kennung (GUID) unterscheiden. Auch vor dem Hintergrund, dass die IFC sich stetig weiterentwickelt, ist solch eine Vorklassifizierung durch den Anwender zu überprüfen, da man dem „IfcExportAs“-Attribut nicht die zugrunde liegende IFC-Version ansehen kann und mitunter neue Klassen hinzugefügt oder obsolete Klassen entfernt werden können.
Es empfiehlt sich also, eine Vereinbarung über die zu verwendenden Klassifizierungsparameter zu treffen und die im Projekt zu verwendenden Familien nach einem einheitlichen Schema zu klassifizieren. Optimalerweise richtet sich die Definition der Parameter nach dem oben genannten Schema, was die Einführung von sowohl einem Typ-Parameter als auch einem Exemplar-Parameter bedingt. Die Kaskade der Ermittlung im Revit-IFC-Exporter ist in Abb. 8 dargestellt.
Hierbei wird der erste nicht-leere Parameter in der Kaskade verwendet. Weiterhin verarbeitet der Exporter aus historischen Gründen mögliche Varianten der Groß- und Kleinschreibung in den Parameternamen. So kann auch eine Angabe von „IFCExportAs“ oder „IFCEXPORTAS“ verstanden werden.
Für die überwiegende Mehrheit der Bauteile genügt eine Typ-Klassifizierung. Bei dieser Aufgabe hilft Ihnen das neue Klassifikations-Werkzeug von LINEAR, das im neuesten Feature-Pack enthalten ist und neben IFC um weitere Klassifizierungs-Schemata erweitert werden kann.
Eigenschaftssätze
Neben der Klassifizierung sind die Eigenschaftensätze von entscheidender Bedeutung für eine passgenaue Informationsübermittlung. Die Gliederung von Attributen in Eigenschaftensätze (engl. property sets, daher oft kurz als „Pset“ bezeichnet) ermöglicht es Ihnen gezielt zu steuern, welche Informationen in die resultierende IFC-Datei kommuniziert werden sollen und welche nicht. Hierbei können Sie eigene Attribute gliedern oder standardisierte Eigenschaftensätze, wie sie z. B. im Rahmen der ISO 16739-1:2018 oder des buildingSMART Data Dictionary (bsDD) definiert werden, exportieren. Eine wesentliche Voraussetzung dafür ist die erfolgte Klassifizierung Ihrer Bauteile.
Revit bietet Ihnen mehrere Einstellmöglichkeiten an, mit denen Sie den Export von Eigenschaftensätzen steuern können.
Revit-Eigenschaftensätze
Dieser Modus exportiert für jedes Element sämtliche Revit-Eigenschaften. Diese Einstellung erfordert keine Vorbereitung im Projekt, folgt aber auch keiner speziellen Konvention, da sie lediglich generische Eigenschaftensätze ungefiltert exporiert. Die resultierenden IFC-Dateien enthalten in der Regel viele nicht benötigte Attribute, die zudem die Dateigröße negativ beeinflussen. Von einer Verwendung in produktivem Umfeld wird daher abgeraten.
Allgemeine IFC-Eigenschaftensätze
Beinhaltet die Standard-Eigenschaftensätze der IFC-Spezifikation, sofern der Exporter diese identifizieren kann. Halten sich Ihre Parameter nicht an das Benennungsschema der IFC, dann lässt sich der korrekte Bezug über eine Parameterzuordnungstabelle herstellen.
Basismengen
Exportiert Mengensätze (engl. quantity take off, kurz „Qto“), die beispielsweise Eigenschaften wie Außenmaße beinhalten. Zum jetzigen Zeitpunkt scheinen diese für TGA-relevante Bauteile (z. B. Qto_SpaceHeaterBaseQuantities) noch nicht implementiert zu sein.
Benutzerdefinierte Eigenschaftensätze
Diese Option nutzt eine externe Textdatei, die gleichzeitig die zu exportierenden Eigenschaftensätze definiert und die Möglichkeit bietet, Parameter nach eigenem Benennungsschema den Standard-Attributen zuzuordnen. Dieser Weg ist sehr flexibel, bedingt aber die Pflege einer externen Textdatei, welche sich vom eigentlichen Modell entkoppelt.
Abbildung unterschiedlicher Informationsbedarfstiefe
Letztendlich lässt sich noch ein undokumentiertes Feature der Export-Schnittstelle nutzen, um übersichtlich zu organisieren, welche Eigenschaftensätze wann exportiert werden sollen.
Wir definieren dazu einfach den Exemplarparameter „IfcExportAs“ für die Kategorie Bauteillisten. Dieser hat einen speziellen Wert „DontExport“, der dafür sorgt, dass die übergeordnete Bauteilliste nicht exportiert wird, selbst wenn wir die Option zum Export der PSet-Bauteillisten aktiviert haben. Weiterhin eignet sich dieser Wert praktischerweise auch dazu, die Darstellung im Projektbrowser zu filtern. Wir können also nach dem WYSIWYG-Prinzip Bauteillisten ausblenden, die für den anstehenden Export nicht relevant sind.
Treibt man das Spiel noch weiter, so kann man auch Ja/Nein-Angaben in den globalen Parametern dazu nutzen, bei mehreren Listen den entsprechenden Parameter auf den Wert „DontExport“ zu setzen, wie das Beispiel in Abbildung 13 verdeutlicht.
Durch diesen Mechanismus lässt sich beispielsweise auch die Anforderung nach einer einstellbaren Informationsbedarfstiefe (Level of Information, LoI) für den Export umsetzen. Das bedeutet, der Planer ist in der Lage nur die Daten zu liefern, die laut BIM-Abwicklungsplan in der aktuellen Phase benötigt werden. Beispielsweise können zu Ausschreibungszwecken so Eigenschaftensätze zurückgehalten werden, die Herstellerangaben preisgeben würden. Zu einem späteren Zeitpunkt lässt sich diese Information dann durch Erhöhen der Informationstiefe mit in den IFC-Export aufnehmen.
In Kürze
Verbessern Sie Ihren IFC-Export durch kreative Nutzung von Revit-Bordmitteln:
- Filtern Sie Bauteile anhand der IFC-Exportklassifikation zur gezielten Erstellung von Eigenschaftensätzen.
- Organisieren Sie Ihre Eigenschaftslisten durch Angabe von Filtern und Gliederungsparametern im Projektbrowser.
- Steuern Sie gezielt, welche Informationen Sie wann ausgeben über die IFC-Exportklassifizierung der Bauteillisten.
- Binden Sie die IFC-Exportklassifizierung an globale Parameter zur komfortablen Aktivierung/Deaktivierung mehrerer Eigenschaftensätze.
Export-Einstellungen
Sollen nur gewisse Anteile des Modells exportiert werden, dann empfiehlt es sich eine Ansicht zu Export-Zwecken zu erstellen und die entsprechende IFC-Exporteinstellung zu aktivieren. So werden nur die Elemente exportiert, die in ebendieser Ansicht sichtbar sind. Auch sollte dieselbe Ansicht zur Erstellung der Geometrie verwendet werden, was über eine weitere Option gesteuert wird. Weiterhin empfiehlt es sich, die IFC-GUIDs nach dem Export in einem Elementparameter zu speichern, da so die bidirektionale Verbindung zwischen IFC-Entitäten und den entsprechenden Revit-Elementen dokumentiert wird.
Eine weitere entscheidende Frage ist die nach dem korrekten Basis-MVD – in den Revit-Einstellungen als IFC-Version bezeichnet. Revit ist aktuell in der Lage mehrere Versionen des IFC-Schemas zu bedienen, von denen aktuell IFC 2x3 und IFC 4 die relevantesten darstellen.
Die Wahl zwischen diesen beiden Versionen ist keine einfache, da es gute Argumente für beide gibt. Während sich die IFC 2x3 aktuell breiter praktischer Anwendung und vollständig zertifizierter Schnittstellen erfreut, enthalten die IFC 4 einige sinnvolle Neuerungen. So werden unter anderem die Typen „Provision for Space“ (provisorischer Raumbedarf) und „Provision for Void“ (provisorische Aussparung) eingeführt, welche sich hervorragend zu Koordinationszwecken zwischen den Gewerken eignen.
Neben der Einführung neuer nützlicher Klassen und Typen und weiteren Verbesserungen wurden insbesondere auch die Möglichkeiten der geometrischen Repräsentation von Bauteilen deutlich verbessert. In der obenstehenden Grafik zeigen wir die Export-Resultate zweier geometrischer Entwicklungsstufen eines einfachen Behälters unter Anwendung unterschiedlicher MVDs. Während die Resultate der „Coordination View 2.0“ und der „Reference View“ explizite Geometrien basierend auf planaren Vielecken generieren, so ermöglicht die „Design Transfer View“ die weitgehend verlustfreie Abbildung der in Revit modellierten Behälterböden.
Eine Triangulierung dieser Rotationskörper und des zylindrischen Behältermantels geschieht nur zu Darstellungszwecken in einem IFC-Betrachter (hier: Open IFC Viewer 21.10). Während also die implizite Darstellung bei hoher geometrischer Präzision eine vergleichsweise geringe Datenmenge produziert, so ist die Interpretation auf der empfangenden Seite mit deutlich mehr Aufwand verbunden. Aus diesem Grund und aufgrund der noch nicht finalisierten Zertifizierung der Revit-Schnittstellen eignet sich die Verwendung der vorteilhaften „Design Transfer View“ in Produktivumgebungen nur, wenn die Kompatibilität zwischen der erzeugenden und der konsumierenden Plattform eingehend überprüft wurde.
FAZIT
Dieser Artikel zeigt grundlegende Schritte hin zu einer Implementierung offener Workflows mit Revit und den IFC auf. Durch die Verwendung fortgeschrittener Filter-Mechanismen auf Basis gemeinsam genutzter Parameter sowie durch geeignete Klassifizierung der Bauteile im Projekt wird sowohl die Verwendung einer IFC-Unterlage als auch der Export einer IFC-Datei mit definiertem Informationsschema dargestellt.
Um aus den gezeigten Techniken nun einen funktionierenden Prozess zu gestalten, bedarf es fortgeschrittener Revit-Anwender, die den technisch-administrativen Teil in der nötigen Tiefe verstehen, um eine entsprechende Basis zu schaffen. Hierbei sollte nach Möglichkeit nicht gleich das nächste Großprojekt herhalten, um den Sprung in die Praxis zu wagen. Vielmehr ist es sinnvoll, dass zunächst alle Beteiligten den Umgang mit den gezeigten Techniken in einem kleinen „Testballon“ erproben.
Wir als LINEAR begleiten Sie auf diesem Weg, indem wir durch intelligente Weiterentwicklung unserer Desktops den Weg ebnen. Es ist heute bereits einiges möglich, es ist relativ aufwendig loszulegen, aber es müssen auch nicht direkt 100 % erreicht werden. Wichtig ist, dass heute die Weichen korrekt gestellt werden, um den digitalen Anschluss nicht zu verpassen.
Christian Waluga
Literaturempfehlungen
Wir haben uns bemüht einen möglichst umfassenden Überblick für IFC-Workflows in der TGA zu geben. Dadurch mussten aus Gründen der Übersichtlichkeit Details verkürzt dargestellt werden, die bereits an anderer Stelle ausführlich dokumentiert sind. Weiterführende Informationen finden Sie in den folgenden Quellen:
- Revit IFC-Handbuch: Ausführliche Anleitung für den Umgang mit IFC-Dateien, Autodesk, 2018. www.autodesk.de/campaigns/interoperability/ifc-handbuch
- IFC Specifications Database, buildingSMART, 2021. technical.buildingsmart.org/standards/ifc/ifc-schema-specifications/
- liNear aktuell 2-2020: Das Wesentliche im Auge behalten – integrale Workflows von Anfang an
- liNear aktuell 1-2020: Workflow auf Basis von IFC-Architekturen