TGA-Planung mit BIM-Objekten

BIM-Methode und Datenformate

Die BIM-Methode, die den Übergang von der zeichnungs- zur modellbasierten Planung darstellt, erfasst in Deutschland mittlerweile alle Gewerke im Bauhauptgewerbe. Erste Bauherren fordern bereits eine durchgängige BIM-Planung, und die NRW-Landesregierung hat im Koalitionsvertrag festgelegt, dass ab 2020 Bauprojekte des Landes (über den Bau- und Liegenschaftsbetrieb, BLB) mit BIM zu planen sind (2).

Der Bund fordert durch einen Runderlass vom 16. Januar 2017 die nachgelagerten Behörden auf, alle neuen Hochbauprojekte mit Baukosten von über fünf Millionen Euro auf Eignung der BIM-Methode zu überprüfen (BIM-Prüfverpflichtung) (3). Im Rahmen der Recherche haben die Autoren im Dezember 2018 bei dem (nun) zuständigen Ministerium des Innern, für Bau und Heimat den Status der Umsetzung angefragt. Die Antwort des Ministeriums klingt ernüchternd: „Die Zahl der inzwischen dem BMI vorgelegten Haushaltsunterlagen, die Aussagen zur BIM-Nutzung enthielten [sind] noch überschaubar“ (4).

Demgegenüber laufen die Infrastrukturprojekte mit der BIM-Methode des BMVI erfolgreich an (5).
Unabhängig von öffentlichen BIM-Projekten geraten Ingenieur- und Planungsbüros der TGA in Zugzwang und müssen Projekte mit den entsprechenden digitalen Werkzeugen und Methoden planen können. Dafür existieren zahlreiche Softwarelösungen, die alle Bereiche der TGA abdecken.
Am Markt haben sich dabei zwei Formate für den Datenaustausch etabliert. Aufgrund der weiten Verbreitung von Autodesk-Produkten haben viele Hersteller damit begonnen, ihre Modelle im Revit-Format (*.rvt) zur Verfügung zu stellen. Bei diesem Closed BIM-Ansatz arbeiten alle Beteiligten im Prozess mit demselben, proprietären Datenformat. Parallel bieten einige BIM-Softwarehersteller zusätzliche Konvertierungsprogramme an, die die RVT-Dateien in ihr eigenes Format umwandeln können.

Um einen softwareunabhängigen Austausch der Daten zu gewährleisten, hat sich das IFC-Format als weitgehender Standard etabliert. Eine Liste der IFC-zertifizierten Softwareprodukte findet sich auf der Seite von buildingSMART (6). Der „Open BIM“ Ansatz (offene BIM-Methode) ist softwareunabhängig. Der IFC-Datenaustausch lässt sich mit dem Dokumentenformat PDF vergleichen. Die Daten sind für alle Nutzer lesbar, Änderungen sind jedoch nur bedingt möglich.

Für die TGA-Branche hat sich gezeigt, dass die Priorität der Produkthersteller auf der Bereitstellung der Geometriedaten liegt. Weiterführende Metadaten und Attribute (z. B. Material, Masse, Preise, Leistungsdaten) sind oftmals nur in reduzierter Form oder gar nicht vorhanden. Beim Import der IFC-Datei in die BIM-Software können die vorhandenen Attribute zum Teil nicht korrekt aufgelöst werden. Am Ende steht der Nutzer mit einem importierten 3D-Modell da und muss die wichtigen Eigenschaften der Komponenten manuell einpflegen. Dies gilt für komplexe RLT-Anlagen (Zentralluftgeräte) genauso wie für standardisierte Komponenten wie Luftdurchlässe oder Brandschutzklappen.

Der große Vorteil des IFC-Formats liegt dennoch in der Datenstruktur, die sowohl die Geometrie als auch alphanumerische Daten beinhaltet. Zusammenfassend spricht man vom Level of Detail (LOD), der sich zusammensetzt aus dem Level of Geometry (LOG) und dem Level of Information (LOI).  Die ersten Ansätze, inhaltliche Vorgaben dem Planungsfortschritt entsprechend zu strukturieren und vorzugeben, wurden im Jahr 2008 vom US-amerikanischen Berufsverband der Architekten (AIA) erarbeitet und durch das BIM-Forum weiter ergänzt (7).

LOD = LOG + LOI

Die tatsächliche Struktur eines IFC ist deutlich komplexer, wie Abbildung 1 zeigt. Neben der eindeutigen Kennung des Bauteils und den Attributen (IfcPropertyDefinition) gehören die Beziehungen zu anderen Bauteilen und den allgemeinen Gebäudedaten dazu. Letztlich wird jedes Objekt in standardisierte Komponenten zerlegt (= Klassifizierung und Vererbung). So erbt z. B. eine als IfcWall klassifizierte Wand auch Attribute, die der Klasse IfcBuildingElement zugeordnet sind usw.

Abbildung 1: IFC-Struktur mit Klassifizierungen, in Anlehnung an Borrmann et al. (2016) (1), Bild: Borrmann/HUSS-MEDIEN GmbH

Die Klasse IfcRoot stellt dabei den Ausgangspunkt der Vererbungshierarchie aller Modellelemente dar. Sie enthält mit dem sogenannten Globally Unique Identifier (GUID) einen global einmaligen Primärschlüssel zur eindeutigen Identifikation und Unterscheidung des jeweiligen Objekts. Im internationalen Datenwörterbuch, dem sogenannten buildingSMART Data Dictionary (bsDD), werden Bauelemente in unterschiedlichen Sprachen aufgeführt und über Eigenschaftsgruppen (Attribute) bzw. PropertySets (kurz: PSets) miteinander verknüpft. Durch die mehrsprachige Verwaltung von Attributen und die Speicherung von standardisierten PSets wird zusätzlich sichergestellt, dass länderübergreifend stets das gleiche Objekt gemeint ist (8). Damit können prinzipiell TGA-Komponenten und Geräte mit geometrischen und semantischen Attributen integriert werden.

Die aktuelle Version IFC 4 besteht bereits aus fast 800 Klassen und ungefähr 400 Typdefinitionen. Dennoch reicht diese Standardklassifikation nicht aus, um alle semantischen Informationen zuverlässig und ganzheitlich zu hinterlegen. Damit beispielsweise auch bedarfsabhängig internationale Standards verfolgt werden können, die von deutschen Bauvorschriften abweichen (z. B. Brandschutz), wird grundlegend zwischen „statisch“ im Datenschema hinterlegten Attributen und „dynamisch“ erzeugbaren Eigenschaften differenziert (9).

Die PropertySets stellen dabei die „dynamische“ Ebene in der Spezifikation dar. Sie können standardisiert über das DataDictionary bezogen oder jederzeit individuell bzw. projektspezifisch angelegt und verändert werden. Darin werden verschiedene Eigenschaften der Klassen wie z. B. Schallschutzkennzahlen, U-Werte oder die Angabe über Innen- und Außenseite einer Wand zugewiesen. Aufgrund dieser Flexibilität werden sie als generische Strukturen dargestellt und nicht als hierarchische Klassen im Objektmodell verankert (10). Um das Objekt dennoch mit einer Eigenschaftsgruppe zu verbinden, wird die in Abbildung 1 dargestellte Klasse IfcPropertyDefiniton verwendet.

Aufgrund fehlender Standards werden solche Eigenschaftssätze allerdings international und von Software zu Software (noch) unterschiedlich definiert. Entscheidend für die Zuverlässigkeit des IFC-Datenaustauschs sind grundlegend die getroffenen Vorkehrungen der Softwarehersteller. Durch die Implementierung der IFC-Schnittstelle beeinflussen sie die Qualität des Datenaustauschs erheblich (11). Daher ist bei der Nutzung von Datenaustauschformaten im Allgemeinen zu überprüfen, wie sich die von buildingSMART veröffentlichten IFC-Spezifikationen zu den IFC-Schnittstellen der jeweiligen BIM-Software verhalten.

Die Entwicklung der LOD und die zugehörigen Attribute der IFC-Datei sollen am Beispiel eines Zentralluftgerätes veranschaulicht werden.

Anforderungen an RLT-Anlagen im BIM-Prozess

Der grundlegende Aufbau beginnt mit der Klasse IfcProject, wodurch dem Bauteil generelle Informationen zum Bauvorhaben bereitgestellt werden. Dieser folgt das IfcBuilding-Objekt, bevor für das eigentliche Zentralluftgerät die Entität IfcBuildingStorey definiert wird. Mit der Unterklasse IfcSpace werden die Luftströme räumlich voneinander getrennt, damit zwischen Abluft- und Zuluftstrang differenziert werden kann.

Bei genauer Betrachtung der veröffentlichten IFC-Klassifikationen wird allerdings deutlich, dass mit IfcBuildingStorey ursprünglich das Stockwerk eines Gebäudes (IfcBuilding) und mit der Klasse IfcSpace ein Raum in einem Gebäude beschrieben wird. Aufgrund mangelnder Alternativen wird die angedachte Spezifizierung an dieser Stelle aber zweckentfremdet und häufig für die Klassifizierung des RLT-Gerätes verwendet.

Um eine Verbindungsmöglichkeit zu anderen Gewerken herzustellen, werden alle Anschlüsse als IfcFlowFitting deklariert. Damit wird der IFC-Struktur vorgegeben, dass ein Übergang zu einem Strömungsverteilsystem vorliegt (12). Im jeweiligen Kubus (IfcSpace) erfolgt eine Aufteilung des Luftstrangs in die modularen Einheiten Gehäuse und Bauteile.

Die Bauteile mit Einfluss auf den Luftstrom (z. B. Schalldämpfer, Ventilator, Filter und WRG) sind mit sämtlichen Eigenschaftsgruppen ausgestattet. Zusätzlich zu geometrischen Daten sind Informationen zu Volumenströmen, Geschwindigkeiten, Gewichten, Leistungen und Schallwerten enthalten. Das IFC-Modell des Zentralluftgerätes besteht aus einzelnen RLT-Teilelementen, deren hinterlegte Produktdaten auch nach Einbindung in das Gebäudemodell bestehen bleiben. Der Anwender kann einzelne Teilelemente gezielt auswählen, um sich die Modellinformationen unter den jeweiligen IFC-Eigenschaften anzeigen zu lassen.

Die untenstehende Tabelle gibt einen generellen Überblick über die benötigten Daten entlang der HOAI-Leistungsphasen. In der Praxis¬ kann diese Aufteilung abweichen und ist vom Bauherrn und den projektbezogenen Auftraggeber-Informationsanforderungen (AIA) abhängig. Das individuelle Zentralluftgerät wird in Tabelle 1 für die beispielhaften Ausarbeitungsgrade als zusammenhängende Funktionseinheit betrachtet.

Der Mehrwert der Daten aus dem RLT-Gerätemodell wird exemplarisch am Filter, Schalldämpfer und Ventilator in Tabelle 2 gezeigt.

Für die Klassifikation von RLT-Anlagen besteht derzeit jedoch kein allgemeingültiger Standard, der den Aufbau und die konkrete Typisierung der verknüpften Einzelkomponenten regelt. Aus diesem Grund werden z. B. herstellerspezifische Gruppenzuweisungen verschieden interpretiert und nicht von jeder BIM-Software erkannt.

Ein Test zur Schnittstellenkompatibilität der IFC-Daten hat gezeigt, dass, abgesehen von den 3D-Geometrien, sehr oft mit einem Datenverlust im semantischen Informationsgehalt zu rechnen ist. Die teilweise enthaltenen und individuellen Eigenschaftsgruppen müssen daher händisch geprüft und ggf. ergänzt werden. Daraus resultierend können Berechnungen, Auslegungen und Simulationen mit BIM-Modellen im IFC-Format zum jetzigen Zeitpunkt nicht umgesetzt werden.

In der Praxis bedeutet dies, dass Planer manuell eigene Bibliotheken anlegen müssen und diese dann, wenn möglich, in folgenden Projekten weiternutzen werden. Dadurch ist die Vielfalt in den Projekten reduziert, da Planungsalternativen immer mit dem Mehraufwand der Modellintegration und Datenanreicherung verbunden sind.

Fazit

Da es sich bei IFC-Modellen grundsätzlich um geometrisch unveränderbare Austauschmodelle handelt, werden diese zurzeit hauptsächlich zur hochdetaillierten Darstellung von herstellerspezifischen Bauteilen genutzt. Falls erweiternde semantische Informationen verfügbar sind, fehlt es an geeigneten Schnittstellen, um diese seitens der Software technologisch zu verarbeiten. Daher kann das volle Potenzial der IFC-Herstellermodelle nicht ganzheitlich ausgeschöpft werden. Zur Berechnung von BIM-Modellen müssen stattdessen softwareinterne und neutrale Bauteile verwendet werden. Die vollumfängliche Möglichkeit einer stufenweisen¬ Datenanreicherung bleibt demnach aus.

Im Aufbau des IFC-Modells ist im Allgemeinen erkennbar, dass das Datenschema strikt zwischen führenden semantischen und geometrischen Beschreibungen getrennt wird. Dadurch kann das (semantische) Objekt mit mehreren geometrischen Detaillierungsformen (unterschiedliche LOG) verknüpft werden. Damit das jeweilige Bauteil weiterhin seine Identität behält, muss die hinterlegte GUID nach Kopplung und Datenanreicherung zwingend gleichbleiben. Dies ist heute noch nicht sichergestellt, weshalb es für den Anwender ebenso wenig möglich ist, ein Bauteil entsprechend LOD-Konzept in der geometrischen Detaillierung weiter zu optimieren.

LOD-Beispiele eines RLT-Gerätes. Oben: LOD 200, unten: LOD 300 (Bilder: Howatherm GmbH)

Auch wenn zusätzliche Informationen wie im Fall der RLT-Anlage enthalten sind, können¬ diese für typische TGA-Berechnungen nicht direkt verwendet werden. Die geeigneten Schnittstellen sind zum Teil fehlerhaft. Für Berechnungen und Auswertungen müssen stattdessen softwarebezogene Lösungen in Form von generischen Bauteilen hinzugezogen werden.

Insgesamt ist aktuell eine durchgängige BIM-Planung lediglich als theoretischer Prozess durchführbar; IFC-Daten dienen heute eher der Koordination als dem Datenaustausch.

Bei weiteren Prozessoptimierungen sollte die Planungseffizienz für den Anwender im Vordergrund stehen. Sobald alle Beteiligten verlustfrei mit ihrer Software auf die Daten desselben Gesamtmodells zurückgreifen können, ermöglicht das eine enorme Zunahme der Flexibilität und somit eine Erleichterung für den Planungsprozess und den Beteiligten. Da es zurzeit keinen übergreifenden Standard in der Nutzung von BIM-Modellen gibt, werden die betreffenden Festlegungen individuell in der AIA und im BAP getroffen.

Parallel werden die Objektdaten der Hersteller direkt in der Softwaredatenbank der BIM-Programme hinterlegt. Dies gilt in erster Linie für standardisierte Komponenten, für modulare und individuell konfigurierbare RLT-Geräte ist diese Lösung jedoch nicht praktikabel.

In jedem Fall muss die Praxis zeigen, wie weit und wie detailliert BIM-Objekte automatisiert eingebunden werden können. Der Auftrag an die Softwarehersteller ist damit klar definiert.

Lesen Sie auch den Fachartikel "IFC – endlich verständlich"