definition der ifc-modellinhalte von infrastrukturbau ... · revit, and edit it in the original...

Technische Universität München

Ingenieurfakultät Bau Geo Umwelt

Lehrstuhl für Computergestützte Modellierung und Simulation

Definition der IFC-Modellinhalte von Infrastrukturbau-werken mithilfe von Autodesk Revit

Bachelorthesis

für den Bachelor of Science Studiengang Bauingenieurwesen

Autor: Johannes Bulla

Matrikelnummer:

1. Betreuer: Prof. Dr. André Borrmann

2. Betreuer: Simon Vilgertshofer M. Sc., Cornelius Preidel M. Sc.

Ausgabedatum: 09. November 2017

Abgabedatum: 09. April 2018

Abstract II

As in any industry, technology in AEC is steadily evolving. Currently the industry is

changing from working with paper-based and two-dimensional digital plans to Building

Information Modeling (BIM). The basic structure of this method is a digital building data

model that provides the opportunity to manage and coordinate all project data and

processes on one central model. The next step in this evolution is Big Open BIM, which

is the consistent application of a BIM model throughout the lifecycle of the building

using independent formats.

The Industry Foundation Classes (IFC) are the key for widespread use of this method.

IFC is an open, royalty-free, vendor-neutral format for building information models. It

primarily serves the exchange of data and the evaluation of the model. The geometry

of the IFC file cannot be edited directly, but simplebim, for example, offers a solution

that at least modifies properties and trims geometry by unnecessary objects. Never-

theless, it is possible to import the model into an editing software, such as Autodesk

Revit, and edit it in the original format of the program. However, the import process is

very likely to result in errors in the geometry.

This thesis is especially aimed at explaining the IFC export function of Autodesk Revit

and its settings. More specifically, it deals with handling custom property sets to extend

the model to non-standard IFC classes and properties. The utilization of parameter

mapping will be explained in more detail based on an example model.

Abstract

Zusammenfassung III

Wie in jedem Industriezweig, entwickelt sich auch die Technologie im Bauwesen stetig

weiter. Momentan befindet sich die Branche im Wandel von der Arbeit mit papierba-

sierten beziehungsweise zweidimensionalen digitalen Plänen zu Building Information

Modeling (BIM). Die Grundlage dieser Methode stellt ein digitales Gebäudedatenmo-

dell dar, welches die Möglichkeit eröffnet alle Projektdaten und -prozesse an einem

zentralen Modell zu verwalten und zu koordinieren. Der nächste Schritt dieser Entwick-

lung ist Big Open BIM, also die durchgängige Nutzung eines BIM-Modells über den

gesamten Lebenszyklus des Gebäudes unter Verwendung von herstellerneutralen

Formaten.

Zur flächendeckenden Ausbreitung dieser Methode sind die Industry Foundation Clas-

ses (IFC) die Schlüsselkomponente. IFC ist ein offenes, gebührenfreies und herstel-

lerneutrales Format für Gebäudedatenmodelle. Es dient primär dem Datenaustausch

und der Auswertung des Modells. Die Geometrie der IFC-Datei kann nicht direkt bear-

beitet werden, jedoch bietet zum Beispiel simplebim eine Lösung an, mit der zumindest

Eigenschaften verändert werden können und die Geometrie um unnötige Objekte ge-

trimmt wird. Dennoch ist es möglich, das Modell in eine Bearbeitungssoftware, etwa

Autodesk Revit, zu importieren und dort im Format des Programms zu bearbeiten. Der

Import-Vorgang führt jedoch mit hoher Wahrscheinlichkeit zu Fehlern in der Darstel-

lung der Geometrie.

Diese Arbeit zielt besonders darauf ab, die IFC-Export-Funktion von Autodesk Revit

und deren Einstelllungen zu erläutern. Spezieller behandelt sie den Umgang mit be-

nutzerdefinierten Property-Sets. Diese erweitern das Modell um nicht standardisierte

IFC-Klassen und Eigenschaften. Die Anwendung des Parameter-Mappings soll an-

schließend anhand eines Beispielmodells nähergebracht werden.

Zusammenfassung

Inhaltsverzeichnis IV

Abbildungsverzeichnis VI

Tabellenverzeichnis VIII

Abkürzungsverzeichnis IX

1 Einführung und Motivation 1

1.1 Einführung ....................................................................................................1

1.2 Motivation und Ziel ........................................................................................1

1.3 Aufbau ..........................................................................................................2

2 BIM – Building Information Modeling 3

2.1 Definition von BIM .........................................................................................3

2.1.1 Litte/BIG BIM und Closed/Open BIM ............................................................4

2.1.2 LOD ..............................................................................................................6

2.2 Ursprung und Entwicklung ............................................................................6

2.2.1 BIM-Reifegradstufen .....................................................................................7

2.2.2 Stand der Einführung ....................................................................................8

2.3 Vorteile und Herausforderungen ...................................................................8

2.3.1 Herausforderungen und Probleme .............................................................. 10

3 IFC – Industry Foundation Classes 12

3.1 Entwicklung ................................................................................................. 12

3.2 Nutzung von IFC ......................................................................................... 13

3.2.1 Model View Definition (MVD) ...................................................................... 13

3.3 Aufbau ........................................................................................................ 15

3.3.1 EXPRESS ................................................................................................... 16

3.3.2 Layer ........................................................................................................... 17

3.4 Klassen und Typen ..................................................................................... 19

3.4.1 Property Sets .............................................................................................. 20

3.4.2 Proxies ........................................................................................................ 22

3.5 Ausblick ...................................................................................................... 22

Inhaltsverzeichnis

Inhaltsverzeichnis V

4 Parameter Mapping mit Autodesk Revit 24

4.1 Grundlagen des IFC-Exports ...................................................................... 24

4.1.1 Zuordnungstabellen .................................................................................... 24

4.1.2 IFC-Exporter ............................................................................................... 26

4.1.3 Exportparameter ......................................................................................... 35

4.2 Shared Parameters – Gemeinsam genutzte Parameter ............................. 37

4.3 User Defined Property Sets – Benutzerdefinierte Eigenschaftensätze ....... 38

5 Beispiel 41

5.1 Erstellen der Familien ................................................................................. 43

5.2 Vergleich des Modells in Revit und IFC (in Solibri Model Viewer) .............. 44

6 Zusammenfassung und Fazit 46

Literaturverzeichnis 48

Anhang A 49

Abbildungsverzeichnis VI

Abbildung 1 - Zusammenfassung der Begriffe litte/BIG closed/open BIM (Borrmann et al. 2015) ............................................................................................ 5

Abbildung 2 - Zeitliche Einordnung der IFC-Versionen (Niedermaier und Bäck 2014) ........................................................................................................ 13

Abbildung 3 - Header einer IFC-Datei ...................................................................... 14

Abbildung 4 - Baumstruktur des IFC-Formats (Autodesk 2018) ............................... 15

Abbildung 5 - Definition eines Entity-Typs mithilfe der Datenmodellierungssprache EXPRESS (Borrmann et al. 2015) ................................................... 16

Abbildung 6 - Die Schichten des IFC-Datenmodells (buildingSMART 2013, http://www.buildingsmart-tech.org/ifc/IFC4/Add2/html/img/IFC4_layered_architecture.png) ... 17

Abbildung 7 - Visualisierung der Beschreibung eines Objekts in IFC (Autodesk 2018) ........................................................................................................ 19

Abbildung 8 - Beziehungen der Typen-Definition (buildingSMART 2017) ................ 21

Abbildung 9 - Ausschnitt aus der Standard-Zuordnungstabelle ................................ 24

Abbildung 10 - Pfad zu den Zuordnungstabellen ...................................................... 25

Abbildung 11 - Pfad zum IFC-Exporter ..................................................................... 26

Abbildung 12 - IFC Exporter: Hauptdialog ................................................................ 26

Abbildung 13 - IFC Exporter: Allgemeine Einstellungen ........................................... 27

Abbildung 14 - IFC Exporter: Zusätzliche Inhalte ..................................................... 29

Abbildung 15 - IFC Exporter: Eigenschaftensätze .................................................... 30

Abbildung 16 - Beispiel der Parameterzuordnungstabelle (Autodesk 2018) ............. 31

Abbildung 17 - IFC Exporter: Detailgenauigkeit ........................................................ 32

Abbildung 18 - IFC Exporter: Erweiterte Einstellungen ............................................. 33

Abbildung 19 - Beispiel für die Anwendung von Teilelementen (Autodesk 2018) ..... 33

Abbildung 20 - Vergleich: Feine Darstellung und mittlere Darstellung (Autodesk 2018) ........................................................................................................ 34

Abbildung 21 - Gemeinsam genutzte Parameter in der Projektansicht .................... 37

Abbildung 22 - Gemeinsam genutzte Parameter über Familientypen ...................... 37

Abbildungsverzeichnis

Abbildungsverzeichnis VII

Abbildung 23 - Ausschnitt aus der "DefaultUserDefinedParameterSets.txt"-Datei mit einer Ergänzung in Deutsch (in blau) .............................................. 38

Abbildung 24 - Unterstützte Datentypen des Revit IFC Exporters ............................ 39

Abbildung 25 - Beispiel für den Einsatz des #-Symbols: Die ersten beiden Rauten markieren ein neues Property-Set, die Dritte ist ein Kommentar ..... 39

Abbildung 26 - Ansicht im Solibri Model Viewer (links: fehlerhaft, wegen falscher Kodierung, rechts: mit UTF-8 ohne BOM kodiert) ........................... 39

Abbildung 27 - Gemeinsam genutzte Parameter ...................................................... 41

Abbildung 28 - Definition des Eigenschaftensatzes .................................................. 42

Abbildung 29 - Ansicht des Widerlagers im Familieneditor ....................................... 43

Abbildung 30 - Familientypen in der Familienansicht von Revit ................................ 43

Abbildung 31 - Gruppenauswahl der gemeinsam genutzten Parameter .................. 44

Abbildung 32 - Beispielmodell in Revit mit Kennzeichnung der einzelnen Klassen .. 44

Abbildung 33 - Widerlager im Detail (Revit) .............................................................. 45

Abbildung 34 - Widerlager im Detail (IFC) ................................................................ 45

Tabellenverzeichnis VIII

Tabelle 1 - Gegenüberstellung der LOD Standards von Österreich und Schweiz mit den deutschen HOAI-Leistungsphasen (Autodesk 2018) .................. 6

Tabelle 2 - Wichtige Klassen der IFC Layer (Autodesk 2018, Borrmann et al. 2015) 18

Tabelle 3 - Standardeigenschaften für IFC-Wände aus dem Property-Set Pset_Wallcommon (Autodesk 2018) ............................................... 20

Tabelle 4 - Anschauungsbeispiel für überschriebene Attribute (buildingSMART 2017) ........................................................................................................ 21

Tabelle 5 - Systemfamilien und deren alternative Klassen (Autodesk 2018) ............ 36

Tabellenverzeichnis

Abkürzungsverzeichnis IX

AEC Architecture, Engineering, Construction

BIM Building Information Modelling

CAD Computer-aided Drawing, Computer-aided Design

IFC Industry Foundation Classes

LOD Level of Development, Level of Detail (Differenzierung s. Kapitel

2.1.2)

MVD Model View Definition

Abkürzungsverzeichnis


1.1 Einführung

Der Einfluss der Digitalisierung hält wie in allen Bereichen unseres Alltags auch im

Bauwesen Einzug. Nach zwei- und dreidimensionalen CAD folgt nun Building Informa-

tion Modeling mit Gebäudedatenmodellen, welche neben 3D-Geometriedaten auch In-

formationen zu den Eigenschaften der Bauteile und deren Beziehungen enthalten. Die-

ses Modell wird im Optimalfall über den ganzen Lebenszyklus des Bauwerks bis zum

Rückbau für die zentrale Verwaltung der Daten und Prozesse verwendet. Am besten

eignet sich das offene Format IFC für den Datenaustausch zwischen Projektbeteilig-

ten. Die Industry Foundation Classes werden von dem internationalen Konsortium buil-

dingSMART entwickelt und stellen ein herstellerneutrales Format für den Austausch

von BIM-Modellen dar. Für die Einführung und Ausbreitung von Big Open BIM stellt

IFC somit eine Schlüsselkomponente dar.

1.2 Motivation und Ziel

Mit Revit stellt Autodesk ein mächtiges Werkzeug zum Erzeugen und Bearbeiten von

Gebäudemodellen zur Verfügung. Dabei kommt die Infrastrukturmodellierung in die-

sem Programm zu kurz. Möchte man trotzdem Projekte dieses Bereichs in Revit er-

stellen, ist es dem Benutzer möglich eigene Bauteile als Familien zu erstellen. Dem

nächsten Problem wird man spätestens begegnen, wenn das Projekt in das IFC-For-

mat exportiert werden soll. Standardmäßig werden die benutzerdefinierten Objekte

nämlich nicht korrekt vom IFC-Exporter erkannt, beziehungsweise gibt es diese Art

Bauteil in IFC überhaupt nicht.

Diese Arbeit beschäftigt sich gerade mit der Lösung dieses Problems. Für Revit-User

besteht die Möglichkeit mit Parameter-Mapping die selbsterstellten Bauteile mit allen

erforderlichen Eigenschaften in das IFC-Modell zu übertragen. Im Zusammenhang mit

dem Parameter Mapping wird der IFC-Exporter von Revit untersucht und dessen Funk-

tionen aufgezeigt. Weiterhin soll besonders das Property-Set erläutert werden und vor

allem auf die Definition von benutzerdefinierten Eigenschaftensätzen eingegangen

werden. Dabei handelt es sich für ein Kernstück des Parameter-Mappings.

1 Einführung und Motivation


Im Anschluss wird die Funktion dieser Methode noch an einem Beispiel demonstriert,

um das Parameter Mapping in der Praxis zu veranschaulichen.

1.3 Aufbau

Zuerst soll in Kapitel 2 ein Überblick über die BIM-Methode und einige Begriffe, die

damit in Zusammenhang stehen, verschafft werden. Vor allem der Aspekt von Open

BIM spielt in dieser Arbeit eine wichtige Rolle. Im darauffolgenden Kapitel wird darauf

eingegangen, was die Industry Foundation Classes sind, wie sie aufgebaut sind und

was sie zu dem Apparat des Bauwesens beizusteuern haben.

Anschließend wird das Parameter Mapping mit dem Modellierungsprogramm Revit

vom Softwareentwickler Autodesk beschrieben. Dabei werden zuerst die grundlegen-

den Funktionen des IFC-Exporters erklärt und im Anschluss speziell benutzerdefinierte

Eigenschaftensätze genauer erläutert. Darauf folgt ein Kapitel, welches sich mit einem

Beispielprojekt beschäftigt, wodurch die praktische Funktion von Parameter Mapping

dargelegt werden soll.


Der Begriff Building Information Modeling (BIM), auf Deutsch Gebäudedaten-Modellie-

rung, beschreibt eine digitale Arbeitsmethode der Baubranche, die ein zentrales Bau-

werksmodell als primäres Mittel der Verwaltung und Koordination von Projektinforma-

tionen nutzt. Zusätzlich zu dreidimensionalen Geometriedaten pflegt man nicht-geo-

metrische Zusatzinformationen, wie z.B. Typeninformationen, technische Eigenschaf-

ten und Kosten, über den gesamten Lebenszyklus des Bauwerks ein. Idealerweise

kann so ein und das selbe Modell über alle Phasen, vom Entwurf über die Errichtung

bis zum Betrieb und letztendlich auch zum Rückbau, verwendet werden. Obwohl aus

technischer Sicht die meisten Hürden bereits überwunden wurden, bestehen bei der

flächendeckenden Einführung weiterhin einige Herausforderungen, welche es zu

meistern gilt. (Borrmann et al. 2015, Egger et al. 2013, Eastman et al. 2011, Nieder-

maier und Bäck 2014)

2.1 Definition von BIM

Definition (NIBS 2012): „Building Information Modeling (BIM) is a digital rep-

resentation of physical and functional characteristics of a facility. A BIM is a

shared knowledge resource for information about a facility forming a reliable

basis for decisions during its life-cycle; defined as existing from earliest con-

ception to demolition.

A basic premise of BIM is collaboration by different stakeholders at different

phases of the life cycle of a facility to insert, extract, update or modify infor-

mation in the BIM to support the roles of that stakeholder. “

Diese Definition des National Building Information Model Standard Project Committee

trifft zwar zu, allerdings werden noch weitere Aspekte neben den physikalischen und

funktionalen Eigenschaften betrachtet. So ist eine zentrale Organisation möglichst al-

ler Projektinformationen, zum Beispiel Ressourcen, Prozesse und schriftliche Doku-

mentationen, letztendlich das Ziel von BIM. In den deutschen BIM-Richtlinien soll eine

präzisere Definition des Begriffs BIM formuliert werden (Egger et al. 2013).

Allgemeiner kann man BIM als eine digitale Arbeitsmethode der Baubranche beschrei-

ben, die durch Zusammenwirken von Menschen, Prozessen und Werkzeugen über

2 BIM – Building Information Modeling


den gesamten Lebenszyklus eines Bauwerks zu verbesserter Transparenz, Qualität

und Kosten- und Terminsicherheit für das Projekt führt (Niedermaier und Bäck 2014).

So werden Abläufe optimiert, da maßgebende Entscheidungen bereits in der Pla-

nungsphase durch Simulationen am Modell besser getroffen werden können und

sämtliche Prozesse virtuell dargestellt werden.

Ein wichtiger Unterschied zu einem reinen 3D-Gebäudemodell besteht darin, dass in

einem BIM-Modell mit bauspezifischen Objekten, also Bauteilen deren Geometrie

meist parametrisch beschrieben wird, und Beziehungen zu anderen Objekten gearbei-

tet wird-Somit können auch Analyse- und Simulationswerkzeuge eingesetzt werden.

(Borrmann et al. 2015)

Um Verwechslungen oder Fehlinterpretationen zu vermeiden, folgen nun einige Bei-

spiele von Modellierung, die nicht als BIM gelten. 3D-Gebäudemodelle, die keine oder

nur wenige Objektattribute besitzen, welche ausschließlich zur visuellen Darstellung

dienen, sind keine BIM-Modelle, da keine weitergehende Analyse möglich ist. Modelle,

welche Parametrik nicht unterstützen, zählen nicht zu BIM. Eine Kombination aus meh-

reren zweidimensionalen CAD-Dateien, aus welcher ein dreidimensionales Modell ent-

steht. Dieses kann keine Konsistenz garantieren, jedoch handelt es sich dabei um ein

Kriterium für vollwertige BIM-Modelle. Ein weiteres Kriterium ist die Eigenschaft, dass

sich Änderungen, die in einer Dimension stattfinden, automatisch in allen anderen Di-

mensionen angepasst werden. Somit fallen Methoden der Modellierung, welche dieses

Merkmal nicht besitzen, nicht in den Bereich von Building Information Modeling. (East-

man et al. 2011)

2.1.1 Litte/BIG BIM und Closed/Open BIM

Durch den fließenden Übergang von zeichnungsgestützter auf modellgestützte Arbeit,

ist es nötig die Technologien in unterschiedliche Stufen einzuteilen. So entstanden die

Begriffe „little bim“ und „BIG BIM“.

Bei little BIM handelt es sich um die Nutzung von BIM-Lösungen in einzelnen Abschnit-

ten der Projektabwicklung. Zum Beispiel kann ein Programm zum Modellieren des Ge-

bäudes verwendet werden, um konsistente (zweidimensionale) Pläne aus dem Modell

abzuleiten. Bei dieser Arbeitsweise wird allerdings nicht das volle Potential der BIM-

Methode ausgeschöpft. (Niedermaier und Bäck 2014, Borrmann et al. 2015)


Big BIM verkörpert wiederum eine modellbasierte Verwaltung und Kommunikation

über den gesamten Lebenszyklus des Bauwerks. Dabei sind vor allem bei großen,

internationalen Projekten Internetplattformen und Datenbanklösungen für einen rei-

bungslosen Informationsaustausch von Vorteil. (Borrmann et al. 2015)

Das beste Ergebnis zur Weiterverarbeitung und Auswertung wird erreicht, wenn die

Daten bei der Übergabe 1:1 übernommen werden können (Niedermaier und Bäck

2014). Dieser Grundsatz gilt allerdings auch bei einer Projektabwicklung, bei welcher

der Fokus nicht auf BIM gelegt wird.

Das Ausmaß des Einsatzes von BIM sollte beim Projektstart mit allen beteiligten Part-

nern klar vereinbart und schriftlich festgehalten werden. (Niedermaier und Bäck 2014)

Open und Closed BIM beziehen sich auf die Nutzung der Software eines oder mehre-

rer Hersteller. Bei Closed BIM, also dem System eines einzigen Herstellers, kann man

meist das ursprüngliche Format der Dateien beibehalten, um das Modell auszuwerten

oder Analysen durchzuführen. (Borrmann et al. 2015)

Da kaum ein Entwickler Software-Lösungen für alle Bereiche der Projektabwicklung

im Angebot hat, wird oft auf offene Formate und Programme anderer Softwareanbieter

zurückgegriffen, um Daten auszutauschen, obwohl herstellerneutrale Formate nicht

immer einwandfrei funktionieren. Diese Arbeitsweise bezeichnet man als Open BIM.


Abbildung 1 - Zusammenfassung der Begriffe litte/BIG closed/open BIM (Borrmann et al. 2015)


2.1.2 LOD

LOD steht sowohl für Level of Detail als auch für Level of Development, jedoch sind

diese Begriffe keineswegs als Synonyme zu verwenden. Level of Detail beschäftigt

sich lediglich mit der grafischen Repräsentation eines Objekts, während Level of De-

velopment den geforderten Fertigstellungsgrad eines Modells beschreibt (Autodesk

2018). Dieser wird anhand der Geometrie und dem Informationsgehalt ermittelt und ist

außerdem von der Leistungsphase und der Fachdisziplin abhängig. Die Anforderun-

gen unterscheiden sich dabei für die unterschiedlichen Gewerke im Bauwesen und

sind normalweise in den nationalen BIM-Richtlinien definiert. In Deutschland gibt es

noch keine offiziellen Richtlinien bezüglich BIM und LOD, daher orientiert man sich im

Allgemeinen an anderen Standards, wie zum Beispiel den Definitionen von buildingS-

MART USA (http://bimforum.org/LOD/) oder dem NATSPEC BIM Paper

(https://bim.natspec.org), die auch als Grundlage für die österreichischen und Schwei-

zer BIM-Standards gelten.

Tabelle 1 - Gegenüberstellung der LOD Standards von Österreich und Schweiz mit den deutschen HOAI-Leistungs-phasen (Autodesk 2018)

International übliche LOD-Bezeichnung

Deutschland Österreich Schweiz

Entspricht grob der HOAI-Leistungsphase

Detaillierungsgrade nach ÖNORM A 6241 (Anhang C)

Fertigstellungsgrade nach Grund-zügen einer open BIM Methodik

LOD 100 Vorentwurfsplanung Projektinitiierung (1) Konzeptionelle Darstellung

LOD 200 Entwurfsplanung Planung (2) Dimension und Größe maßgebli-cher Bauelemente

LOD 300 Genehmigungsplanung Vergabe (3) Ausschreibungsreife Angaben mit Spezifikationen

LOD 400 Ausführungsplanung Ausführung (4) Fabrikationsreife Ausführungspla-nung

LOD 500 Bestandsdokumentation Nutzung/CAFM (5) Dokumentation des ausgeführten Elementes

2.2 Ursprung und Entwicklung

Die Idee der digitalen Datenverarbeitung und virtuellen Gebäudemodellen reicht bis in

die 1970er Jahre zurück, wobei sie anfangs aufgrund mangelnder Rechenleistung nur

Theorie blieb (Borrmann et al. 2015). Die Weiterentwicklung der Technik schuf der

Idee der digitalen Bauwerksmodellierung mit moderner mächtiger Software ein

Sprungbrett in die Industrie, aus der sie heute nicht mehr wegzudenken ist.

Der Begriff „Building Information Modeling“ wurde erstmals 1992 in einem Paper er-

wähnt und wurde durch den Softwarehersteller Autodesk weiterverbreitet (Borrmann

http://bimforum.org/LOD/


et al. 2015). BIM entwickelte sich mit der Zeit vom „Buzzword“ einiger Früheinsteiger

zum Herzstück des Bauwesens, in dem BIM-Lösungen mittlerweile zur Schlüsseltech-

nologie gelten (Eastman et al. 2011). Die Entwicklung von Addons erweitert die Soft-

ware um nützliche Funktionen.

Dieser Fortschritt von BIM bedeutet nicht nur einen Technologiewandel, sondern auch

einen Wandel in der Herangehensweise an die Prozesse des Bauwesens. Dies erfor-

dert ein Umdenken bei der Projektabwicklung und eine erhöhte Kommunikation unter

den Beteiligten (Niedermaier und Bäck 2014). BIM muss als langfristiger Optimie-

rungsprozess im Unternehmen, sowie als Kulturwandel in der Projektabwicklung an-

gesehen werden, der durch schrittweisen Aufbau der Kompetenzen und eine kontinu-

ierliche Anpassung der Erwartungshaltung erreicht wird (Egger et al. 2013).

2.2.1 BIM-Reifegradstufen

Die gängigen BIM-Reifegradstufen wurden von der britischen BIM Task Group als Rei-

fegradmodell (engl. BIM Maturity Model) veröffentlicht. Dieses Modell zeigt die schritt-

weise Einführung von Big Open BIM in vier Stufen:

Level 0 BIM: Auf dieser Stufe wird mit 2D-CAD gearbeitet und der Datenaustausch

geschieht über Papierpläne oder digitale Plots. Die meisten Unternehmen sind dieser

Stufe um einiges voraus (McPartland 2017).

Level 1 BIM: Typischerweise entsteht hier eine Mischung aus dreidimensionaler CAD-

Arbeit für Entwürfe und zweidimensionalen Modellen, um gesetzlich vorgeschriebene

Unterlagen und Produktionsinformationen zu erstellen. Der Datenaustausch findet

über eine gemeinsame Datenumgebung (engl. common data evironment, CDE) statt.

Auf diesem Level arbeiten heutzutage viele Unternehmen und Organisationen.

Level 2 BIM: Diese Stufe wird durch Zusammenarbeit ausgezeichnet. Hier benutzt jede

beteiligte Partei 3D-Modelle, aber sie arbeiten nicht zwangsweise an einem einzigen

gemeinsamen Modell (engl. „shared model“). Die Kollaboration besteht aus dem Da-

tenaustausch in einem gemeinsamen Dateiformat und dem Zusammenfügen in einem

föderierten Modell, welches zur Überprüfung und für Analysen verwendet wird.

Level 3 BIM: Level 3 stellt die Umsetzung von BIG Open BIM dar, ist aber momentan

kaum erreicht (McPartland 2017). Die Verwaltung und Koordination aller Projektdaten


läuft über ein zentrales Modell ab. Alle Beteiligten können auf die selben Daten zugrei-

fen, wodurch Konflikte durch veraltete oder fehlerhafte Informationen minimiert werden

können. (Borrmann et al. 2015)

2.2.2 Stand der Einführung

Als Vorreiter der BIM-Bewegung gelten unter anderem Singapur, Finnland, die USA,

Großbritannien und Australien (Borrmann et al. 2015). In diesen Ländern spielt der

Staat als Auftraggeber die Schlüsselrolle bei der Einführung von Building Information

Modeling, da dies für öffentliche Bauvorhaben verbindlich ist. Auch viele andere Län-

der in Europa setzen BIM-Methoden bei der Bearbeitung von öffentlichen Projekten

verpflichtend voraus.

In Deutschland ist die Entwicklung von BIM noch nicht so weit, wie in vielen anderen

europäischen Ländern. Nichtsdestotrotz verwenden einige innovative Unternehmen

bereits BIM-Lösungen, um auf dem internationalen Markt nicht in Rückstand zu gera-

ten. Im Ausland sind bereits viele Richtlinien vorhanden, die vor allem von öffentlichen

Auftraggebern initiiert werden. Im Gegensatz dazu dominieren im Inland noch Richtli-

nien privater Auftraggeber. Die deutsche Rechtslage bremst die BIM-Bewegung et-

was, da einige Aspekte nicht klar geregelt sind, trotzdem kann man eine flächende-

ckende Einführung von BIM-Methoden in naher Zukunft erwarten (Egger et al. 2013).

Bei der Verbreitung von BIM in Deutschland spielt die öffentliche Hand eine maßgeb-

liche Rolle.

2.3 Vorteile und Herausforderungen

Obwohl die BIM-Methode noch nicht vollständig ausgereift ist, sind signifikante Ver-

besserungen im Vergleich zu traditionellen Arbeitsweisen, also 2D-CAD und Papier-

plänen, erkennbar (Eastman et al. 2011). Besonders der Umgang mit Kosten und Zeit

wird durch BIM optimiert. Durch mehr Intelligenz, Transparenz und höhere Effizienz

der Prozesse über den gesamten Lebenszyklus, führt die richtige Nutzung von BIM zu

Planungs-, Termin- und Kostensicherheit und zu einem vereinfachten Risikomanage-

ment. Gleichzeitig rücken komplexere Designs und eine verbesserte Qualität des Bau-

werks in Reichweite (Egger et al. 2013). Das bedeutet, dass Änderungen in der Pla-

nung konsequent in das BIM-Modell eingepflegt werden müssen und diese Informati-

onen zur weiteren Bearbeitung des Projekts verwendet werden. Dies folgt unter ande-

rem aus der Möglichkeit schon in frühen Phasen der Projektabwicklung mit Planern


aus unterschiedlichen Disziplinen zusammen zu arbeiten. Durch die simultane Arbeit

an einzelnen Teilmodellen, die gemeinsam geprüft werden, können Kollisionen ver-

schiedener Sparten behoben werden, bevor sie ein Problem darstellen (Egger et al.

2013).

Die genaue 3D-Visualierung in der frühen Entwurfsphase vereinfacht die Prüfung der

funktionalen Konsistenz eines Gebäudes (Eastman et al. 2011). Dadurch kann ein Teil

der Fehler und Versäumnisse bereits vor dem Errichten festgestellt werden. Diese

hochwertigen Planungsdaten erlauben eine frühzeitige und belastbare Entscheidungs-

findung (Egger et al. 2013).

Aus dem Gebäudemodell können genaue und konsistente zweidimensionale Pläne

erstellt werden. Außerdem kann bei einem BIM-Modell besser auf Planänderungen

eingegangen werden, als bei herkömmlichen Papierplänen, auch weil automatische

Korrekturen kleinerer Fehler oder Veränderungen möglich sind (Niedermaier und Bäck

2014). Wenn ein zentrales Modell für alle Phasen gepflegt wird, spart man Ressour-

cen, da nicht alle Daten für jede Leistungsphase neu erstellt werden müssen und die

Planunterlagen durchgehend konsistent sind, wodurch es keine unterschiedlichen Pla-

nungsstände oder veraltete Pläne gibt. Zudem ist es auch machbar einzelne Bauteile,

zum Beispiel Fertigteile aus Beton oder Fassadenelemente, zu exportieren und diese

an Subunternehmer für eine präzise Produktion weiterzugeben (Eastman et al. 2011).

Weiterhin kann mit der richtigen Software ein 4D-Modell, also ein dreidimensionales

Modell mit einem Baufortschrittsplan, erstellt werden. Damit erreicht man eine opti-

mierte Zeitplanung, indem Fehler früh erkannt und behoben werden oder der Baufort-

schritt parallel zum Errichten geprüft wird. Doch ein gutes BIM-Modell ermöglicht nicht

nur Simulationen bezüglich der Zeit, sondern auch Analysen der Energieeffizienz, Un-

tersuchungen der Tragwerke oder Kostenrechnungen zu jeder Phase des Projektes.

(Eastman et al. 2011, Egger et al. 2013)

Auch nach der Fertigstellung des Bauwerks kann das Modell dem Bauherrn im Ge-

gensatz zu einer „toten“ Zeichnung noch von Nutzen sein. Dieses hilft bei der Inbe-

triebnahme und der Verwaltung von Einrichtungen. Das Modell enthält Informationen

zu allen verbauten Materialien, zur Instandhaltung der verbauten Anlagen und Syste-

men im Gebäude. Die Daten des Modells können bei Umbauten oder Austausch von

Teilen noch ergänzt werden. Spätestens beim Rückbau kommt das BIM-Modell wieder

zur Geltung. Wenn alle Änderungen am Gebäude auch in das Modell übernommen


wurden, kann man bestimmen, welche Bauteile weiterverwendet, recycelt oder ent-

sorgt werden. (Eastman et al. 2011, Borrmann et al. 2015)

2.3.1 Herausforderungen und Probleme

Eine große Herausforderung stellt die oft vorliegende grundlegende Ablehnung gegen-

über Gebäudedaten-Modellierung dar. Ein offensichtlicher Grund dafür ist, dass die

gewohnte Arbeitsweise verändert wird und neuer Wind in die Definition der Bürostan-

dards, Ressourcen und Vorgaben kommt. Außerdem besteht die Befürchtung, dass

das Erstellen und Pflegen des BIM-Modells einen zusätzlichen Aufwand bedeutet. Ge-

rade in der (Vor-)Entwurfsphase müssen mehr Ressourcen investiert werden, als bei

der traditionellen Projektabwicklung, dafür übertrifft der Nutzen über die gesamte Lauf-

zeit den anfänglichen Einsatz bei weitem. Um diese nicht völlig unbegründeten Beden-

ken zu kompensieren, ist es erforderlich bezüglich Bauwerksdaten umzudenken und

Mitarbeiter in Hinblick auf BIM zu schulen und zu sensibilisieren. (Niedermaier und

Bäck 2014)

BIM kann einige der Probleme von traditionellen Methoden verhindern, jedoch treten

damit neue Herausforderungen ans Tageslicht und es entstehen dadurch neue Bezie-

hungen. Außerdem muss der Kontakt zwischen Architekten, Auftragnehmer und Fach-

planern verstärkt in den frühen Entwurfsphasen gesucht werden. Bei dieser Zusam-

menarbeit muss ein besonderes Augenmerk auf eine effektive Teambildung gelegt und

ein reibungsloser Datenaustausch entwickelt werden. Selbst wenn der Austausch der

Informationen gut funktioniert, kann es zu Problemen wegen ungenügendem Detail-

grad des Architektenmodells oder durch verschiedene Dateiformate der einzelnen

Fachplaner. Hier würde sich als Austauschformat das herstellerneutrale Format IFC

anbieten. Mit der Implementierung des zentralen Datenmodells, oder auch „shared

building model“, kann es daher zu Schwierigkeiten kommen. Jedoch ist die Einführung

erforderlich, da dieses die Grundlage aller weiteren Arbeitsvorgänge darstellt. (East-

man et al. 2011)

Ein weiteres Problem bleibt die rechtliche Grundlage, bis dazu eine klare Regelung in

Kraft tritt (Eastman et al. 2011).

Gerade während der Einführungsphase von BIM, kann es zu Fehleinschätzungen

kommen, was den Aufwand und auch die Leistung von Gebäudedatenmodellen an-

geht. So gibt es sowohl die Erwartung, dass die Software von alleine alle benötigten

Ergebnisse auf Knopfdruck liefert, als auch die Vorstellung, dass alle Daten per Hand


eingegeben werden müssen und der Aufwand des Erstellens mit der Menge der aus-

zugebenden Informationen deutlich ansteigt. (Egger et al. 2013)

Wie jede bedeutende Entwicklung der Technologie wird auch dieser Wandel Zeit und

Ausbildung der Nutzer in Anspruch nehmen. Der Umstieg auf BIM erfordert mehr als

nur neue Software und Umschulung. Es sind Veränderungen in jeder Ebene der Pro-

jektabwicklung notwendig, da alle Prozesse mit BIM zusammenhängen. (Eastman et

al. 2011)


Die Industry Foundation Classes, kurz IFC, ist ein offenes Dateiformat, das speziell für

den Informationsaustausch im Bauwesen und Facility Management entwickelt wurde

(Borrmann et al. 2015). IFC ist nicht für die Weiterverarbeitung des Modells optimiert,

sondern für die Visualisierung, Analyse, Berechnungen und Simulationen. (Autodesk

2018) Wer beabsichtigt das IFC-Modell zu verändern, sollte es zuvor in ein Bearbei-

tungsprogramm seiner Wahl importieren. Es besteht auch die Möglichkeit IFC-Dateien

direkt zu verändern, jedoch stellt diese Variante nicht unbedingt die selbe Mächtigkeit

der Werkzeuge zur Verfügung wie Programme, welche IFC in das ursprüngliche For-

mat umwandeln. Die Herstellerneutralität, Transparenz und kostenfreie Lizenz des Da-

tenmodells resultiert in einer schnellen Verbreitung und enormen Reichweite. Somit

stellt es die Grundlage für Open BIM dar. (Niedermaier und Bäck 2014,)

3.1 Entwicklung

Bereits in den 1970er Jahren entwickelte man einheitliche Schnittstellen für CAD-Sys-

teme, um einen möglichst verlustfreien Datenaustausch der Geometrie zu erlangen.

Etwa ein Jahrzehnt später stieg die Nachfrage nach einem Format, mit welchem man

die Geometrie und Semantik beschreiben und teilen kann. (Borrmann et al. 2015)

Die erste Version von IFC, „IFC 1.0“, wird 1997 von der International Alliance for In-

teroperability (IAI) veröffentlicht (Borrmann et al. 2015). Die IAI ist ein internationales

Konsortium, dessen Ziel es ist, die Standardisierung des Datenaustausches zu be-

schleunigen. Es handelt sich dabei um eine offene Initiative, in der Firmen, darunter

maßgebend der Softwarehersteller Autodesk, Forschungs- und Bildungseinrichtungen

und Gruppen von Privatpersonen vertreten sind. Seit 2005 heißt die IAI buildingS-

MART (Niedermaier und Bäck 2014).

Man unterscheidet IFC hinsichtlich des Aufbaus, der Aktualität und des Inhalts. Die

momentan relevanten Formate sind IFC2x2, IFC2x3, IFC2x4 (IFC4) und IFC-XML

(Niedermaier und Bäck 2014). Obwohl die aktuell gültige Version IFC4 ist, findet

IFC2x3 weiterhin Verwendung, da noch nicht alle Programme Unterstützung für IFC4

anbieten. Empfohlen werden deshalb die Formate IFC2x3 und IFC4, da mindestens

eines der Formate von jedem Programm mit IFC-Schnittstelle gelesen werden kann.

3 IFC – Industry Foundation Classes


IFC-XML stellt eine Möglichkeit dar, Berechnungen mit Programmen durchzuführen,

selbst wenn diese das IFC-Format nicht unterstützen (Autodesk 2018).

Abbildung 2 - Zeitliche Einordnung der IFC-Versionen (Niedermaier und Bäck 2014)

3.2 Nutzung von IFC

Optimal funktioniert IFC als Koordinationsmittel in einem IFC-Viewer oder als Referenz

in einer BIM-Bearbeitungssoftware. Falls man das Modell bearbeiten möchte, sollte

man im Idealfall die Originaldatei verwenden, da es bei dem Import einer IFC-Datei zu

Datenverlusten kommen kann (Autodesk 2018). Aktuelle Entwicklungen zeigen Ver-

suche diese Verluste zu minimieren. Zum Beispiel, in dem die Model View Definition

angepasst wird (s. Kapitel 3.2.1).

Weiterhin wird IFC benutzt, um verschiedene Analysen und Simulationen am Gebäude

durchzuführen. Beispielsweise können thermische Simulationen oder statische Analy-

sen des Tragwerks berechnet werden.

3.2.1 Model View Definition (MVD)

Die Model View Definition entscheidet welche Daten aus einem Modell beim Export zu

IFC übertragen werden. Bei der Implementierung muss allerdings auf das „Implemen-

ters‘ Agreement“ geachtet werden, um die Homogenität und Kompatibilität bei der

Übertragung zu gewährleisten (Borrmann et al. 2015). Je nach Datenaustausch-Sze-

nario kann so eine Definition sehr hilfreich sein, da IFC für verschiedene Anwendungen

passende MVDs bereitstellt. Diese legen ihren Schwerpunkt beispielsweise auf

Rauminformationen oder spezifische Bauteil-Attribute, wie Brandschutz oder Nut-

zungsfläche. (Autodesk 2018)


Mit IFC 4 wurden die Model View Definitions Model Reference View und Design Trans-

fer View eingeführt. Das IFC-Modell, welches mit Model Reference View erstellt wurde,

dient als Grundlage für die Koordination und Mengenermittlung. Es kann nicht für die

Weiterverarbeitung verwendet werden, da nur die wichtigsten geometrischen Informa-

tionen übertragen werden. Für den Import zwecks Bearbeitung wird der Design Trans-

fer View empfohlen, wobei es selbst bei dieser MVD zu Datenverlusten kommt, da

Parametrik und komplexe Zusammenhänge nur eingeschränkt übermittelt werden.

Weitere häufig verwendete Definitionen sind der Coordination View Version 2.0 und

Basic FM Handover View, welche bei aus IFC 2x3 stammen. Der Coordination View

2.0, der auch CV 2.0 genannt wird, dient dem Austausch zwischen den Hauptdiszipli-

nen im Bauwesen und ist die momentan noch am meisten genutzte MVD. CV 2.0 un-

terstützt ansatzweise parametrische Ableitung von Bauteilen. Für die Weiterverwen-

dung in Gebäudebewirtschaftungs- und Verwaltungssystemen eignet sich der Basic

FM Handover View, da wenig grafische Informationen und maßgebend alphanumeri-

sche Attribute benötigt werden. (Autodesk 2018)

Aus dem Header der IFC-Datei erkennt man die verwendete MVD, die IFC-Version

und mit welchem Programm gearbeitet wurde. In der folgenden Abbildung ist ein Hea-

der dargestellt, aus welchem man lesen kann, dass die MVD CV 2.0 verwendet wurde

und das Projekt als IFC 2x3 aus Autodesk Revit 2018 exportiert wurde. (Autodesk

2018)

Abbildung 3 - Header einer IFC-Datei

FILE_DESCRIPTION(('ViewDefinition [CoordinationView_V2.0]'),'2;1'); FILE_NAME('Projektnummer','2018-03-03T14:49:08',(''),(''),'The EXPRESS Data Manager Version 5.02.0100.07 : 28 Aug 2013','20170223_1515(x64) - Exporter 18.0.0.420 - Alternate UI 18.0.0.420',''); FILE_SCHEMA(('IFC2X3')); ENDSEC; DATA; #1= IFCORGANIZATION($,'Autodesk Revit 2018 (DEU)',$,$,$); #5= IFCAPPLICATION(#1,'2018','Autodesk Revit 2018 (DEU)','Revit');


3.3 Aufbau

Das IFC-Format ordnet die Objekte hierarchisch nach ihrem Typ an. Diese vordefi-

nierte Struktur ist in der unten gezeigten Grafik veranschaulicht. (Autodesk 2018)

Abbildung 4 - Baumstruktur des IFC-Formats (Autodesk 2018)


3.3.1 EXPRESS

Da das IFC-Format auf dem STEP-Standard, vor allem auf der Datenmodellierungs-

sprache EXPRESS aus dem STEP-Standard Teil 11, basiert, ist es wie EXPRESS

eine deklarative Sprache. Das bedeutet, dass Modelle objektorientiert definiert wer-

den, also gibt es ein Vererbungssystem aus Klassen, die jeweils Attribute und Bezie-

hungen haben, welche an Subtypen vererbt werden. Eine Besonderheit von EX-

PRESS ist dabei, dass inverse Relationen explizit deklariert werden können. EX-

PRESS dient ausschließlich zur Definition der Schemata, beschreibt aber nicht kon-

krete Instanzen. (Borrmann et al. 2015)

Abbildung 5 - Definition eines Entity-Typs mithilfe der Datenmodellierungssprache EXPRESS (Borrmann et al. 2015)


3.3.2 Layer

Um eine bessere Wartbarkeit und Erweiterbarkeit zu erreichen, ist das IFC-Format in

Schichten, bzw. Layer, aufgeteilt. Die obenliegenden Elemente können auf die Schich-

ten darunter zugreifen, aber die unteren Layer haben nicht die Zugriffsrechte nach

oben. Dies führt zu einer Unabhängigkeit der Kernelemente. (Borrmann et al. 2015)

Abbildung 6 - Die Schichten des IFC-Datenmodells (buildingSMART 2013, http://www.buildingsmart-tech.org/ifc/IFC4/Add2/html/img/IFC4_layered_architecture.png)

Der Domain Layer, die höchste Ebene, enthält Schemata mit Entity-Definitionen, die

Spezialisierungen von Produkten, Prozessen oder Ressourcen sind, welche einer spe-

zifische Fachdisziplin angehören (Borrmann et al. 2015). Diese Definitionen finden nor-

malerweise beim Informationsaustausch innerhalb von Domänen Verwendung (buil-

dingSMART 2013).


Der nächste Layer, der Interoperability Layer, beschreibt spezifische Entitätsdefinitio-

nen für ein allgemeines Produkt, einen Prozess oder eine Ressourcenspezialisierung,

welche interdisziplinär Anwendung finden (Borrmann et al. 2015). Diese Schemata

verwendet man für den Transfer zwischen Domänen und für die gemeinsame Nutzung

von Konstruktionsinformationen (buildingSMART 2013).

Darunter liegt der Core Layer, in dem das Kernelschema und die Kernerweiterungs-

schemata, welche die allgemeinsten Entity-Definitionen enthalten, liegen. Alle im Core-

oder einem darüberliegenden Layer definierten Entitäten erben von IfcRoot, haben

eine eindeutige ID, Namen, Beschreibung und optional Besitzer- und Verlaufsinforma-

tionen. Dieser Layer liefert die grundlegenden Strukturen, Beziehungen und Konzepte

für alle weiteren Spezifikationen (buildingSMART 2013).

Der Resource Layer ist die niedrigste Ebene. Hier liegen alle individuellen Schemata,

die Ressourcen definieren. Diese Definitionen können nicht als eigenständige Objekte

existieren, sondern müssen von einem oder mehreren Objekten, die von IfcRoot ab-

leiten, referenziert werden. Ressourcen haben kein Konzept einer Identität, deshalb

stehen mehrere Objekte, welche die selbe Ressource referenzieren, nicht in einer Be-

ziehung. (Borrmann et al. 2015)

Tabelle 2 - Wichtige Klassen der IFC Layer (Autodesk 2018, Borrmann et al. 2015)

Layer Beispielklassen/ wichtige Klassen

Dom

ain

La

yer

IfcArchitectureDomain, IfcBuildingControlsDomain, IfcConstructionMgmtDomain, IfcElectrical-Domain, IfcHvacDomain, IfcPlumbingFireProtectionDomain, IfcStructuralAnalysisDomain, IfcStruc-turalElementsDomain

Inte

rope

rabi

lity

La

yer

Wichtige Bauteilklassen wie IfcWall, IfcColumn, IfcBeam, IfcPlate, IfcWindow

Core

La

yer

Basis-Klassen aus dem Kernel-Schema: IfcRoot, IfcObject, IfcActor, IfcProcess, IfcProduct, IfcProject, IfcRelationship Physische Objekte, Räume und Beziehungsklassen aus Product Extension: IfcBuilding, IfcBuild-ingStorey, IfcSpace, IfcElement, IfcBuildingElement, IfcOpeningElement, IfcRelAssociatesMaterial, IfcRelFillsElement, IfcRelVoidsElement Prozesse, Abläufe und Abhängigkeiten dieser zu Ressourcen aus Process Extension: IfcProcedure, IfcEvent, IfcTask Basisklassen für Steuerungsobjekte aus Control Extension: IfcControl, IfcPerformanceHistory

Reso

urce

La

yer

IfcGeometricModelResource: Beschreibung von geometrischen Modellen IfcGeometryResource: geometrische Basiselemente IfcTopologyResource: Abbildung der Topologie eines Körpers IfcMaterialResource: Elemente zur Beschreibung von Materialien


3.4 Klassen und Typen

Klassen oder Entitäten (engl. Entity) definieren welche Standardattribute und Abhän-

gigkeiten ein Objekt erhält. Eine Typendefinition beschreibt ein Objekt noch spezifi-

scher. Zum Beispiel kann ein Bauteil der Klasse Fundament (IfcFooting) durch den

IfcType PILE_CAP als Köcherfundament definiert werden.

Beim Export des BIM-Modells ist auf die Wahl der richtigen Klasse zu achten, damit

andere Programme die Objekte bei weiteren Operationen am Modell korrekt interpre-

tieren können. (Autodesk 2018)

Abbildung 7 - Visualisierung der Beschreibung eines Objekts in IFC (Autodesk 2018)

Unabhängig von den intern genutzten Bezeichnungen für Attribute, erkennt jede Soft-

ware allgemeingültige Standardattribute von IFC. Viele Programme übersetzen beim

Export eigene Attribute automatisch in das IFC-Äquivalent, um sicherzustellen, dass

Objekte ausreichend beschrieben werden. Neben notwendigen Informationen wie

Klassifizierung, globaler Lage und geometrische Beschreibung werden also klassen-

bzw. typabhängige Standardattribute in ein IFC-Modell geschrieben. Damit ein Attribut

übertragen wird, muss es allerdings einen Wert besitzen, da leere Eigenschaften beim

Export ausgelassen werden, um eine möglichst geringe Speichergröße zu erreichen.

(Autodesk 2018)


3.4.1 Property Sets

Unter anderem sind die Standardparameter von IFC in Property-Sets gruppiert. Diese

enthalten jeweils Eigenschaften zu einer Bauteilklasse. (Autodesk 2018)

Der offizielle deutsche Begriff für Property-Set ist laut buildingSMART „frei definierbare

Merkmalsliste“, jedoch benutzt Autodesk stattdessen „Eigenschaftensatz“ (buildingS-

MART 2017, Autodesk 2018). IfcPropertySet ist eine Container-Klasse, in welcher Ei-

genschaften (IfcProperty) gruppiert sind. Jedes einzelne Attribut hat einen eindeutigen

Namen (IfcProperty.Name), nach welchem es interpretiert wird. Alle Property-Sets der

IFC-Spezifikation werden „Pset_Xxx“ benannt und tragen diese Bezeichnung ebenfalls

im Attribut „Name“. In dieser Namenskonvention wird nach dem Präfix „Pset_“ die Ca-

melCase-Notation verwendet. Dabei wird jedes neue Wort mit einem Großbuchstaben

begonnen und die Wörter werden direkt ohne Leerzeichen oder Unterstrich aneinan-

dergereiht. (buildingSMART 2017)

Zum Beispiel gibt es für Wände das Property-Set Pset_WallCommon. (Autodesk 2018)

Tabelle 3 - Standardeigenschaften für IFC-Wände aus dem Property-Set Pset_Wallcommon (Autodesk 2018)

Attributname Beschreibung

Reference Bauteiltyp (Typname) FireRating Feuerwiderstandsklasse (Typparameter) ThermalTransmittance U-Wert (Typparameter) IsExternal Außenbauteil (Typparameter) LoadBearing Tragendes Bauteil (Exemplarparameter) ExtendToStructure Fixiert oben (Verhalten) AcousticRating Schallschutzklasse Combustible Brennbares Material SurfaceSpreadOfFlame Brandverhalten Compartmentation Brandabschnittsdefinierendes Bauteil

Die im IFC-Format integrierten Property-Sets berücksichtigt der IFC-Exporter, ohne

dass weitere Einstellungen nötig sind. Wichtig ist dabei allerdings, dass Name und Typ

(also Text/Zahl/Boolean) genau übereinstimmen und die Attribute unter der Gruppe

IFC-Parameter zusammengefasst sind (Autodesk 2018).

Um die Standard-Schemata nicht unnötig aufzublähen, sind einige nicht immer ver-

wendete Parameter in Property-Sets ausgegliedert. So kann man sie bei Bedarf ohne

großen Aufwand einfügen. (Borrmann et al. 2015)

Zusätzlich ist es möglich mit benutzerdefinierten Property-Sets eigene Attribute in das

IFC-Format zu übertragen, obwohl diese ursprünglich nicht implementiert wurden.


Wenn man diese Funktion nutzt, sollten alle Beteiligten darauf achten identische Defi-

nitionen für die Parameter zu verwenden (Borrmann et al. 2015). Bei Property-Sets,

die nicht Teil der IFC-Spezifikation sind, wird bei der Namensgebung auf das Präfix

„Pset_“ verzichtet. (buildingSMART 2017)

Abbildung 8 - Beziehungen der Typen-Definition (buildingSMART 2017)

Property-Sets können entweder direkt einer Instanz eines Objekts (IfcObject) zugewie-

sen werden, indem man die objektivierte Beziehung IfcRelDefinesByProperties be-

nutzt, oder durch die direkte Beziehung HasPropertySets einem Objekttypen (IfcType-

Object) übertragen werden. Das Property-Set wird vom Objekttypen über eine weitere

objektivierte Beziehung, IfcRelDefinesByType, an alle Instanzen dieses Typs weiter-

gegeben. (buildingSMART 2017)

Attribute, die vom Objekttypen, zugewiesen werden, können durch Property-Sets mit

direktem Bezug zur Instanz, überschrieben werden. Dazu müssen die Namen der At-

tribute identisch sein. (buildingSMART 2017)

Tabelle 4 - Anschauungsbeispiel für überschriebene Attribute (buildingSMART 2017)

Bezogen auf IfcWall Bezogen auf IfcWallType Maßgebender Attributwert für eine individuelle Wand Pset_WallCommon Pset_WallCommon

ExtendToStructure = TRUE TRUE ThermalTransmittance = 0.375 0.375 ExtendToStructure = FALSE ExtendToStructure = TRUE FALSE


3.4.2 Proxies

Ein Proxy ist eine Spezialisierung einer Objektinstanz, die keine spezifische Informa-

tion eines Objekttypen enthält. Ihr können jedoch Attribute und Beziehungen zugewie-

sen werden. (buildingSMART 2017)

Proxies stellen damit Platzhalter dar, mit denen man eine Vielzahl semantischer Er-

weiterungen ermöglicht und eine weite Palette an Anwendungsmöglichkeiten abdeckt.


In IFC gibt es ein IfcProxy, welches ein Stellvertreter für alle Objekte ist, für die in IFC

noch keine passende Typdefinition existiert. Da IfcProxy sehr allgemein ist, sollte es

möglichst nicht verwendet werden, sondern das am besten passende Pendant aus der

Liste der Objekttypen gewählt werden. Oft ist es möglich Objekte durch Bearbeiten der

Eigenschaften zu modifizieren, um einen Typen zu erstellen, der die gewünschten An-

forderungen erfüllt. Bauteile, die keine Typendefinition haben, kann man mit IfcBuildin-

gElementProxy ersetzen. (Niedermaier und Bäck 2014)

3.5 Ausblick

IFC stellt Mittel zum Datenaustausch zur Verfügung, durch die es möglich ist eine Zu-

sammenarbeit aller Beteiligten der Projektabwicklung zu verwirklichen, obwohl unter-

schiedliche Software genutzt wird (Autodesk 2018). Trotz einiger Schwächen des IFC-

Formats, ist es für die flächendeckende Einführung von Big Open BIM hauptverant-

wortlich. Die Schwächen äußern sich etwa als Anfälligkeit für Fehler oder als hoher

Aufwand bei der Softwareherstellung, um volle IFC-Kompatibilität zu erreichen (Borr-

mann et al. 2015). Fehler entstehen etwa, wenn in dem Modellierungsprogramm Ob-

jekte verwendet, die IFC nicht unterstützt oder jene nicht korrekt übertragen werden,

obwohl es ein Pendant in IFC existiert. Die Industry Foundation Classes stellen ein

herstellerneutrales, offenes, lizenzfreies Format dar, wodurch Wettbewerbsverzerrung

bestmöglich verhindert werden kann. Das hat zur Folge, dass auch staatliche Organi-

sationen großes Interesse an IFC und der verbindlichen Verwendung des Formats für

öffentliche Bauprojekte zeigen. Dieser Ansatz ist schon in einigen Vorreiter-Nationen,

wie Singapur, Finnland, den USA und Großbritannien, zu beobachten (Borrmann et al.

2015).


Eine Langzeitarchivierung der Projektdaten ist durch IFC sichergestellt, da das offene

Format eine Lesbarkeit in Zukunft ermöglicht. Sogar mehrere Jahre nachdem der Le-

benszyklus des Gebäudes überschritten ist, sollte es kein Problem darstellen die In-

formationen einzusehen (Borrmann et al. 2015). Das stellt einen Ersatz zu Papierplä-

nen dar, die gestempelt und unterzeichnet aufbewahrt werden.

Mit der Möglichkeit aller Mitglieder von buildingSMART über die Entwicklung von IFC

mit zu entscheiden, wird es sich auch in Zukunft zu einem noch mächtigeren offenen

Format für das Bauwesen entfalten. (Borrmann et al. 2015)


Für einen erfolgreichen Export des Projekts ist es ratsam sich im Vorherein schon Ge-

danken zu machen, wie der weitere Verwendungszweck der IFC-Datei aussieht. Die-

ses Kapitel behandelt die grundlegenden Einstellungen, die Revit beim Exportieren

anbietet, und geht vor allem beim Umgang mit benutzerdefinierten Eigenschaftensät-

zen in die Tiefe.

4.1 Grundlagen des IFC-Exports

4.1.1 Zuordnungstabellen

Die Zuordnungstabelle (engl. Mapping Table) dient dazu Revit-Kategorien eine IFC-

Klasse und optional auch einen IFC-Typ zuzuweisen. Die Werte der Tabelle werden

in einer Textdatei gespeichert und können entweder direkt in Revit oder manuell mit

einem Textbearbeitungsprogramm editiert werden. (Autodesk 2018)

Abbildung 9 - Ausschnitt aus der Standard-Zuordnungstabelle

Die linke Spalte zeigt alle Kategorien und Unterkategorien, die im Projekt zur Verfü-

gung stehen. Die Werte dieser Spalte stehen fest und können nicht verändert werden.

In der mittleren Spalte sind die korrespondierenden IFC-Klassen aufgelistet. Beim Ein-

geben der Namen ist unbedingt auf eine richtige Schreibweise zu achten und zu prü-

fen, dass die Klasse von Revit unterstützt wird. Falls eine (Unter-)Kategorie nicht ex-

portiert werden soll, wird in die entsprechende Zeile der IFC-Klasse-Spalte „Nicht ex-

portiert“ eingegeben.

4 Parameter Mapping mit Autodesk Revit


Optional kann man noch den IFC-Typ festlegen. Dies entspricht etwa der Unterkate-

gorie in Revit, mit der eine Kategorie genauer unterteilt werden kann. Zum Beispiel ist

ROOF, also Dach, ein IFC-Typ, der die Klasse IfcSlab präzisiert (Autodesk 2018).

Eine vollständige Liste der in Revit verfügbaren IFC-Klassen und Typen kann man hier

einsehen: http://blogs.autodesk.com/bimblog/ifc.

Man erreicht die Zuordnungstabelle über: Revit > Exportieren > Optionen > IFC-Opti-

onen.

Abbildung 10 - Pfad zu den Zuordnungstabellen

http://blogs.autodesk.com/bimblog/ifc


4.1.2 IFC-Exporter

Den IFC-Exporter erreicht man über Datei > Exportieren > IFC.

Abbildung 11 - Pfad zum IFC-Exporter

Hauptdialog

Dazu öffnet sich ein neues Fenster, in dem sich Einstellungen zur Übergabe in das

IFC-Format finden. Dies ist der Hauptdialog des Exporters. Die aktuelle Version des

Exporter Plugins ist nur auf Englisch verfügbar, also werden die deutschen Begriffe

verwendet und in Klammern jeweils die englischen Bezeichnungen dafür vermerkt.

Abbildung 12 - IFC Exporter: Hauptdialog


In der Eingabezeile Dateiname: (File name) wird der Dateiname und der Speicherort

angegeben.

Über Aktuell ausgewählte Einrichtung: (Current selected setup) kann man eine vorge-

fertigte Konfiguration der Exporteinstellungen laden. Diese Wahl beeinflusst maßge-

bend den Inhalt der IFC-Datei. Für unterschiedliche Verwendung des exportierten Pro-

jekts gibt es andere Schwerpunkte, die dadurch in den Fokus gerückt werden können.

Der Button Einrichtung ändern (Modify setup) führt zu einem Untermenü, in dem Ein-

stellungen zur Einrichtung individuell angepasst werden können.

In der Liste Zu exportierende Projekte: (Projects to export) werden alle aktuell in Revit

geöffneten Projekte angezeigt. Die markierten Projekte exportiert Revit mit identischen

Einstellungen und speichert sie in einzelnen IFC-Dateien ab.

(Autodesk 2018)

Einrichtung ändern

Das Fenster zu Einrichtung ändern weist fünf Registerkarten auf: Allgemein, Zusätzli-

che Inhalte, Eigenschaftenätze, Detailgenauigkeit und Erweitert. Hier kann auch eine

vorhandene Model View Definition ausgewählt und angewendet werden. (Autodesk

2018)

Allgemeine Einstellungen

Die Einstellungen unter Allgemein (General) beziehen sich vor allem auf das Dateifor-

mat und entscheiden grob welche Inhalte übertragen werden.

Abbildung 13 - IFC Exporter: Allgemeine Einstellungen


Die Einstellung bei IFC-Version (IFC version) entscheidet welches IFC-Schema (IFC

2x3 oder IFC4) und welche Model View Definition genutzt wird.

Weiterhin wird ausgewählt als welcher Dateityp (File type) das Projekt gespeichert

werden soll. Für große Projekte empfiehlt es sich die komprimierte Version .ifczip zu

verwenden. Das Format wird von den meisten IFC-Viewern problemlos gelesen und

kann bei Bedarf entpackt werden, um die standardmäßige .ifc-Datei zu erhalten.

Zu exportierende Phase (Phase to export) bietet eine Auswahl über die zu exportie-

rende Phase. Diese entsprechen dabei zeitlichen Grenzen während dem Bau bis hin

zum Abriss des Gebäudes (Autodesk 2017). Zum Beispiel kann bei einem Umbau

Phase 1 für den Abriss einzelner Bauteile stehen, während in Phase 2 neue Teile ein-

gesetzt werden.

Die Optionen beim Export von Raumbegrenzungsflächen (Space boundaries) sind in

drei Ebenen, „Keine“, „1. Ebene“ und „2. Ebene“, geteilt. Je nach Verwendungszweck

ist es sinnvoll genauere oder vereinfachte Detailstufen einzusetzen.

Die Option Keine exportiert lediglich Referenzumfang und Verweise auf angrenzende

Objekte. Informationen zu Begrenzungsflächen fallen komplett weg.

Mit 1. Ebene gibt Revit Begrenzungsflächen zur Mengen- und Massenauswertung aus.

Raumbegrenzungen werden unter Berücksichtigung von angeschlossenen Bauteilflä-

chen erzeugt, wobei Löcher und Aussparungen vernachlässigt werden.

Die 2. Ebene exportiert alle für energetische oder thermische Berechnungen relevan-

ten Informationen. Zu beachten ist hierbei die Projektphase, welche man in den Ener-

gieeinstellungen auswählen kann.

Projektursprung (Project Origin) gibt an, auf welche Koordinaten sich der Ursprung des

Projektes bezieht. Diese Funktion wurde mit der Version 18.3.1 der IFC-Exporter App

für Revit 2018 eingeführt. Zur Auswahl stehen die gemeinsam genutzten Koordinaten

(Current shared Coordinates), der Vermessungspunkt (Site survey point), der Projekt-

Basispunkt (Project base point) und das interne Koordinatensystem (Internal Coordi-

nates). (Autodesk 2017, Autodesk 2018)

Gemeinsam genutzte Koordinaten sind nötig, wenn mehrere Modelle in einem Projekt

nicht unabhängige Koordinaten nutzen, sondern miteinander verknüpft sind. Das Ko-

ordinatensystem wird dann von einem Modell geteilt, damit alle importierten Dateien

auf dieses zugreifen können.


Der Vermessungspunkt entspricht einem Punkt in der Realität, zum Beispiel einem

geodätischen Messpunkt. (Autodesk 2017)

Der Ursprung des Projektkoordinatensystems ist der Projekt-Basispunkt. Alle Positio-

nen und Höhenkoten werden relativ zu diesem Punkt angezeigt. (Autodesk 2017)

Der Ursprung des internen Koordinatensystems, auch Startpunkt genannt, bleibt im-

mer unverändert. Am Startpunkt können das Projektkoordinatensystem und das Ver-

messungskoordinatensystem ausgerichtet werden. Beim Erstellen des Modells liegen

Projekt-Basispunkt und Vermessungspunkt im internen Ursprung. (Autodesk 2017)

Mit angekreuztem Kästchen bei Wände, Stützen, Luftkanäle nach Ebene teilen (Split

Walls, Columns, Ducts by Level) erfolgt eine geschossweise Trennung dieser Bauteile,

falls sie sich über mehrere Gebäudegeschossebenen erstrecken. Diese Ebenen soll-

ten im Optimalfall angepasst werden, damit eine übersichtliche Struktur der IFC-Datei

erreicht wird (Autodesk 2018).

Die Kopfzeileninformation (File Header Information) und Projektadresse (Project

Address) passen allgemeine Projektinformationen der IFC-Datei an.

Zusätzliche Inhalte

Der Zusätzliche Inhalte-Reiter (Additional Content) zeigt folgende Optionen

Abbildung 14 - IFC Exporter: Zusätzliche Inhalte

Ist 2D-Draufsichtselemnte exportieren (Export 2D plan view elements) aktiviert, über-

gibt der Exporter 2D-Elemente wie Raster, Texte und Linien, die allerdings nicht von

allen IFC-Viewern angezeigt werden können. Den 2D-Elementen müssen die richtigen


IFC-Klassen zugewiesen werden. Diese sind IfcAnnotation und IfcGrid (Autodesk

2018).

Verknüpfte Dateien als separate IFCs exportieren (Export linked files as separate

IFCs) bedeutet verlinkte Revit-Dateien als eine IFC-Dateien zu exportieren. Der Export

von Revit-Links bleibt ganz aus, wenn diese Option nicht aktiviert ist (Autodesk 2018).

Nur in der Ansicht sichtbare Elemente exportieren (Export only elements visible in

view) bezieht sich auf Elemente, die durch die aktuellen Sichtbarkeitseinstellungen,

Filter und Phasen zu sehen sind.

Wird das Häkchen bei Räume in 3D-Ansichten exportieren (Export rooms in 3D views)

gesetzt, erstellt der Exporter 3D-Volumina in IFC-Räumen, die im IFC-Viewer anwähl-

bar sind.

Eigenschaftensätze

Die Einstellungen dieser Registerkarte bestimmen welche Eigenschaftensätze (Pro-

perty Sets) exportiert werden.

Abbildung 15 - IFC Exporter: Eigenschaftensätze

Die Funktion Revit-Eigenschaften exportieren (Export Revit property sets) sollte nur

verwendet werden, wenn man unbedingt alle Eigenschaften benötigt, da es das Da-

tenmodell unnötig aufquellen lässt. Durch den Export aller Revit-Eigenschaften kann

die Dateigröße um bis zu 70% höher sein, also ohne diese (Autodesk 2018).


Allgemeine IFC-Eigenschaftensätze exportieren (Export IFC common property sets)

sollte immer aktiviert sein, da dadurch die Standardeigenschaften des IFC-Schemas

übernommen werden.

Durch Basismengen exportieren (Export base quantities) werden Basismengen expor-

tiert, die als Grundlage für Berechnungen dienen. Diese „Base Quantities“ sind von

buildingSMART fest definierte Eigenschaftensätze, die allen Elementen zugeordnet

werden (Autodesk 2018).

Eigenschaften aus Bauteillisten können mit Bauteillisten als Eigenschaftensätze ex-

portieren (Export schedules as property sets) in die IFC-Datei übertragen werden. Um

nicht unerwünschte Bauteillisten als Eigenschaften zu exportieren, kann man Nur Bau-

teillisten mit IFC, Pset oder Allgemein im Titel exportieren (Export only schedules con-

taining IFC, Pset, or Common in the title) aktivieren und die Listen entsprechend be-

nennen.

Benutzerdefinierte Eigenschaftensätze exportieren (Export user defined property sets)

wird genutzt, um gezielt Eigenschaften in IFC zu übersetzen. Diese Property-Sets wer-

den in einer Textdatei definiert.

Durch Parameterzuordnungstabelle exportieren (Export parameter mapping table) ist

es möglich vom IFC-Schema definierte Standardattribute zu überschreiben. So kön-

nen beispielsweise deutsche Begriffe verwendet werden, um die standardmäßig eng-

lischen zu ersetzen, oder IFC-Attribute auf einen Büro-Standard angepasst werden

(Autodesk 2017). Die Definition erfolgt ebenfalls in einer Textdatei. Folgende Konven-

tion muss beachtet werden:

Abbildung 16 - Beispiel der Parameterzuordnungstabelle (Autodesk 2018)

Klassifizierungseinstellungen (Classification Settings) erlauben es die Uniformat-Klas-

sifizierung nach einem landesspezifischen System einzustellen. Die Unterstützung von

eindeutigen Schlüsselnummern für Bauteileigenschaften ermöglicht die maschinelle

Verarbeitbarkeit und Verknüpfung der Daten.

IFC_Common_PropertySet_Name <tab> IFC_Property_Name <tab> Revit_Property_Name

Beispiel: Pset_WallCommon Compartmentation Brandabschnitt Pset_WallCommon Combustible Entflammbar


Detailgenauigkeit

Die Einstellungen in der Registerkarte Detailgenauigkeit (Level of Detail) beschränken

sich auf die Detailgenauigkeit für einige Geometrieelemente (Level of detail for some

element geometry) und tessellierte Geometrie als Triangulation zu behalten (Keep tes-

sellated geometry as triangulation).

Abbildung 17 - IFC Exporter: Detailgenauigkeit

Diese beeinflusst vor allem die Dateigröße und die korrekte Interpretation. Da jeder

Punkt in einem Vielfachnetz beschrieben werden muss, ist es nur selten sinnvoll den

hohen Detailierungsgrad zu wählen. Meistens reicht „Niedrig“ völlig aus. (Autodesk

2018)


Erweiterte Einstellungen

Zu den erweiterten Einstellungen (Advanced) gehört lediglich eine Reihe von An/Aus-

Optionen.

Abbildung 18 - IFC Exporter: Erweiterte Einstellungen

Teile als Gebäudeelemente exportieren (Export parts as building elements) sorgt da-

für, dass Teilelemente, zum Beispiel Schichten einer Wand, als IfcBuildingElementPart

ausgegeben werden und somit zu dem grundlegenden Bauteil zugeordnet werden

können. Wenn ein Programm die Teilelemente nicht korrekt interpretieren kann, wer-

den sie als eigene Bauteile angezeigt.

Abbildung 19 - Beispiel für die Anwendung von Teilelementen (Autodesk 2018)

Durch Verwendung der kombinierten Körpermodelldarstellung zulassen (Allow is of

mixed „Solid Model“ representation) können Objekte aus einer Kombination von

Swept-Solid und BREP-Modellen dargestellt werden. Das ist in IFC standardmäßig

nicht möglich und kann bei komplexen Objekten zu enormen Dateigrößen oder Fehlern

führen. Da dies nicht mehr vollständig dem IFC-Standardschema entspricht, muss


man sich unter allen Beteiligten auf diese Einstellung einigen, um Probleme zu ver-

meiden.

Aktive Ansicht beim Erstellen von Geometrie verwenden (Use aktive view when crea-

ting geometry) beeinflusst die Darstellung von Haustechnik-Elementen, deren Modell-

geometrie sich von der dargestellten Geometrie unterscheidet.

Abbildung 20 - Vergleich: Feine Darstellung und mittlere Darstellung (Autodesk 2018)

Familien- und Typennamen als Referenz verwenden (Use family and type name for

reference) ändert die Referenzierung von standardmäßig nur auf Basis des Typen zu

einer Referenz basierend auf Revit-Familie und Typ.

Mit 2D-Raumbegrenzungen für Raumvolumen verwenden (Use 2D room boundaries

für room volume) werden Raumvolumen anhand der zweidimensionalen Raumbegren-

zungen berechnet anstatt die Raumgeometrie aus Revit als Grundlage der Berech-

nung zu benutzen (Autodesk 2018).

Mit der Einstellung IFCSITE-Höhe in lokalen Platzierungsursprung auf Grundstück be-

ziehen (Include IFCSITE elevation in the site local placement origin) wird der Höhen-

wert des Projektes ausgegeben. Der Coordination View 2.0 wird setzt die Höhe stan-

dardmäßig auf „0“, wodurch bei einigen älteren Programmen Fehler entstehen können

(Autodesk 2018).

Um die Fachmodellkoordination zu vereinfachen, kann man IFC-GUIDs im Parameter

IfcGUID speichern. Dies geschieht nach dem erfolgreichen Export, wenn IFC-GUID

nach dem Export in einem Elementparameter speichern (Store the IFC GUID in an

element paramenter after export) aktiviert ist.

Statt einer zu komplexen Geometrie darzustellen oder um Abstandsflächen zu ermit-

teln, kann ein Element durch die Bounding Box bzw. dem Begrenzungsrahmen ersetzt

werden, damit die Darstellung simplifiziert bzw. überhaupt möglich wird. Begrenzungs-

rahmen exportieren (Export bounding box) überträgt nur Bounding Boxes statt den

geometrischen Elementen. (Autodesk 2018)


4.1.3 Exportparameter

IFC-Exportparameter bestimmen welcher Klasse bzw. welchen Typen Revit-Objekte

oder Klassen in IFC entsprechen. Sie erfüllen somit sie selbe Funktion wie die Zuord-

nungstabelle, werden aber als Attribut in der Familie hinterlegt. Dabei ist zu beachten,

dass Exportparameter gegenüber der Zuordnungstabelle Vorrang haben. (Autodesk

2018, Autodesk 2017)

Es gibt drei dieser Parameter: IfcExportAs, IfcExportType und ObjectTypeOverride. Es

besteht die Möglichkeit diese Parameter auf Typen oder Exemplare anzuwenden, wo-

bei es sich empfiehlt, den Bezug auf Typen zu nutzen, wenn man davon ausgehen

kann, dass sich die Werte einzelner Exemplare dieses Typs nicht unterscheiden. (Au-

todesk 2017, Autodesk 2018)

IfcExportAs bestimmt die IFC-Klasse eines Bauteils beim Export. Genauer kann der

Parameter auch den Typen festlegen, indem nach dem Klassennamen ein Doppel-

punkt und der Typenname geschrieben wird. Beispielsweise wird mit dem Wert

IfcSlab:ROOF der Klasse „Decke“ noch der Typ „Dach“ mitgegeben. Wie bei der Zu-

ordnungstabelle können auch bei IfcExportAs Bauteile vom Export ausgeschlossen

werden. Für diese Funktion steht der Wert „DontExport“. (Autodesk 2018, Autodesk

2017)

IfcExportType legt den zu exportierenden Typ fest. Da auch IfcExportAs diese Funk-

tion abdecken kann, findet IfcExportType wenig Anwendung. (Autodesk 2018)

ObjectTypeOverride führt nur eine rein textliche Überschreibung der Revit-Bauteilty-

pen durch, also entspricht er nicht wirklich der Kategorie der Exportparameter (Auto-

desk 2018). Da er trotzdem fähig ist, den zugeordneten Typen zu überschreiben, wird

der Parameter als in einer Reihe mit IfcExportAs und IfcExportType aufgezählt.


Systemfamilien stellen grundlegende Gebäudeelemente wie Wände, Geschossde-

cken, Decken und Treppen zur Verfügung. Sie können nicht erstellt, kopiert, gelöscht

werden und Exportparameter haben nur eingeschränkten Zugriff auf die Klassen und

Typenzuweisung (Autodesk 2017). Das folgt aus der beschränkten Auswahl an alter-

nativen Klassen für jede Kategorie, zu welchen jeweils nur einige Typen passen (Au-

todesk 2018).

Tabelle 5 - Systemfamilien und deren alternative Klassen (Autodesk 2018)

Revit Kategorie

Standardklasse Standardtyp (Predefined Type)

Alternative Klassen (IfcExportAs)

Mögliche Typen (IfcExportType)

Wand IfcWallStabdardCase für alle Wände, die durch eine einfache Extrusion beschrieben werden können

NOTDEFINED IfcFooting (Fun-dament)

PAD_FOOTING (Einzelfunda-ment) PILE_CAP (Köcherfundament) STRIP_FOOTING (Streifenfun-dament) FOOTING_BEAM (Fundament-balken)

IfcWall für unregelmä-ßige Wände

STANDARD IfcFooting(Fun-dament)

Geschossde-cke

IfcSlab FLOOR FLOOR (Standard) ROOF (Dach) LANDING (Podest) BASESLAB (Grundplatte)

IfcFooting (Fun-dament)

PAD_FOOTING (Einzelfunda-ment) PILE_CAP (Köcherfundament) STRIP_FOOTING (Streifenfun-dament) FOOTING_BEAM (Fundament-balken)

IfcCovering (Fußboden / Decke)

CEILING (Decke) FLOORING (Fußboden) CLADDING (Verkleidung) ROOFING (Dach)

IfcRamp (Rampe)

Decke IfcCovering - - CEILING (Abhangdecke) FLOORING (Bodenbelag) CLADDING (Verkleidung) ROOFING (Dach)

Rampe IfcRamp - - - Treppe IfcStair - - -

Projektfamilien, also benutzerdefinierte Familien, hingegen können jede IFC-Klasse

annehmen, die in Revit verfügbar ist. (Autodesk 2018)

Ladbare Familien ähneln bezüglich Exportparameter den Projektfamilien. Ihnen kön-

nen also auch alle von Revit unterstützten Klassen zugewiesen werden. Weiterhin

können die Klassen und Typen der verschachtelten Klassen variieren. Allerdings muss

die Option „Gemeinsam genutzt“ aktiviert sein. Abzugskörper erhalten automatisch die

Klassenbezeichnung OpeningElement. (Autodesk 2018)


4.2 Shared Parameters – Gemeinsam genutzte Parameter

Gemeinsam genutzte Parameter sind Eigenschaften, die man mehreren Familien oder

Projekten hinzufügen kann. Die Definitionen werden getrennt von Familien oder Pro-

jekten in einer Textdatei aufbewahrt, also stehen sie allen Projekten gleichermaßen

zur Verfügung. Allerdings ist es nur möglich eine Shared-Parameter-Datei in einem

Projekt zu verwenden (Autodesk 2017). Falls es erforderlich ist Eigenschaften aus ei-

ner anderen Datei abzurufen, können diese jedoch exportiert, beziehungsweise auch

importiert, werden.

Es ist möglich eine beliebige Anzahl an Gruppen zu erstellen, um die Parameter zu

gliedern. Auch diese Gruppen sind für alle Benutzer und Projekte sichtbar, die das

selbe Shared-Parameter-File verwenden. (Autodesk 2017)

Es gibt mehrere Wege, um auf Gemeinsam genutzte Parameter zuzugreifen, diese

werden hier aufgezeigt.

In der Projektansicht befindet sich das Menü unter dem Reiter „Verwalten“.

Abbildung 21 - Gemeinsam genutzte Parameter in der Projektansicht

Das Menü zum Einfügen von Eigenschaften in eine Familie, bietet bei der Auswahl der

Shared Parameters die Möglichkeit diese zu bearbeiten.

Abbildung 22 - Gemeinsam genutzte Parameter über Familientypen


Es wäre rein theoretisch auch möglich die Shared Parameters manuell zu bearbeiten,

weil es sich nur um eine unverschlüsselte Textdatei handelt. Allerdings wird davon

abgeraten, da das Risiko Fehler zu erzeugen relativ hoch ist.

4.3 User Defined Property Sets – Benutzerdefinierte Eigenschaftensätze

Benutzerdefinierte Eigenschaftensätze bieten die Möglichkeit einzelne Eigenschaften

oder Eigenschaften, welche im IFC-Format nicht definiert sind, zu exportieren. (Auto-

desk 2018)

Die Definition der Property-Sets findet in einer Textdatei (.txt) statt. Es gibt eine Stan-

darddatei von Revit, welche eine Erklärung der grundlegenden Formatierung enthält.

Diese ist durch die #-Symbole am Zeilenbeginn auskommentiert, damit sie nicht als

Inhalt des Eigenschaftensatzes interpretiert wird. Diese ist normalerweise unter folgen-

den Pfad zu finden: C:\ProgramData\Autodesk\Application-

Plugins\IFC2018.bundle\Contents\2018\DefaultUserDefinedParameterSets.txt

Abbildung 23 - Ausschnitt aus der "DefaultUserDefinedParameterSets.txt"-Datei mit einer Ergänzung in Deutsch (in blau)

Die einzelnen „Eingabefelder“ unterteilt ein Tabulator, somit stellt es kein Problem dar,

wenn Leerzeichen in den Namen der Eigenschaften auftreten.

Das Property-Set beginnt mit „PropertySet:“. Danach steht an der Stelle von

Pset_Name der Name des Datensatzes (Autodesk 2018). Dabei ist zu beachten, dass

dieser kein „Pset_“-Präfix enthält, da dies laut IFC-Konvention den Standard-Property-

Sets aus dem IFC-Schema vorbehalten ist (buildingSMART 2017).

Der Eigenschaftensatz kann sich auf einen Typen oder eine Instanz beziehen. Für den

Typen steht ein „T“, für Instanz ein „I“. Dahinter folgt die Angabe der IFC-Klasse, be-

ziehungsweise der Typen. Mehrere Eingaben trennt ein Komma.

Ab der darauffolgenden Zeile stehen die zu exportierenden Parameter. Zuerst nennt

man den IFC-Parameter, nach einem Tab folgt der Datentyp und rechts steht der

# # User Defined PropertySet Definition File # # Format: # PropertySet: <Pset Name> I[nstance]/T[ype] <element list separated by ','> # <Property Name 1> <Data type> <[opt] Revit parameter name, if different from IFC> # <Property Name 2> <Data type> <[opt] Revit parameter name, if different from IFC> # <IFC Name> <Datentyp> <bei Abweichung vom IFC Namen, Name in Revit>


Name des Revit-Attributs. Falls die Namen des Attributes in Revit und IFC identisch

sind, kann die rechte Spalte leer gelassen werden. Die unterstützten Typen sind eben-

falls in der Standarddatei aufgelistet. Es ist allerdings nicht möglich berechnete Werte,

zum Beispiel die nicht verknüpfte Höhe einer Wand, zu übertragen (Autodesk 2018).

Bei der Eingabe der Datentypen muss unbedingt auf Groß- und Kleinschreibung ge-

achtet werden, da die Zeile sonst nicht richtig erkannt wird.

Abbildung 24 - Unterstützte Datentypen des Revit IFC Exporters

Ist es erforderlich mehrere Property-Sets zu definieren, markiert eine Raute den An-

fang eines neuen Eigenschaftensatzes (Autodesk 2018). Weiterhin bedeutet eine

Raute am Anfang einer Zeile, dass diese nicht als Inhalt des Property-Sets gezählt

wird, sondern einen Kommentar.

Abbildung 25 - Beispiel für den Einsatz des #-Symbols: Die ersten beiden Rauten markieren ein neues Property-Set, die Dritte ist ein Kommentar

Beim Erstellen der Textdatei ist es wichtig, dass die Kodierung auf „UTF-8 ohne BOM“

konfiguriert ist, da Parameter deren Namen einen Umlaut enthalten sonst nicht expor-

tiert beziehungsweise fehlerhaft angezeigt werden.

Abbildung 26 - Ansicht im Solibri Model Viewer (links: fehlerhaft, wegen falscher Kodierung, rechts: mit UTF-8 ohne BOM kodiert)

# Data types supported: Area, Boolean, ClassificationReference, ColorTemperature, Count, Currency, # ElectricalCurrent, ElectricalEfficacy, ElectricalVoltage, Force, Frequency, Identifier, # Illuminance, Integer, Label, Length, Logical, LuminousFlux, LuminousIntensity, # NormalisedRatio, MassDensity, PlaneAngle, PositiveLength, PositivePlaneAngle, PositiveRatio, # Power, Pressure, Ratio, Real, Text, ThermalTransmittance, ThermodynamicTemperature, Volume, # VolumetricFlowRate

# PropertySet: Eigenschaftensatz 1 T IfcBuildingElementProxy Bauelementklassifikation Text # PropertySet: Eigenschaftensatz 2 T IfcWall Phase Text Phase erstellt # Diese Zeile ist nur ein Kommentar


Der Aufwand beim manuellen Erstellen der Textdatei ist recht hoch. Zusätzlich besteht

dabei das Risiko durch Tippfehler oder eine Verwechslung einzelner Attributnamen

eine fehlerhafte Definition der Eigenschaftensätze zu erzeugen. Es gibt zwar keine

offiziellen Tools von Autodesk, um diese Arbeit zu erledigen, jedoch steht die Möglich-

keit offen eine Applikation mit einer übersichtlichen Bedienoberfläche zu entwickeln.

Gerade bei Verwendung von gemeinsam genutzten Parametern, empfiehlt es sich

eine Liste aller Attributnamen zu speichern, um falschen Bezeichnungen aus dem Weg

zu gehen.

5 Beispiel 41

Da Revit keine Infrastrukturmodellierung unterstützt, bietet es sich an, ein Bauwerk

aus diesem Bereich als Beispiel zu verwenden. Daher wurde eine simplifizierte Brücke

gewählt, um zu zeigen, wie für das Programm unbekannte Bauteile erstellt und in die

IFC-Datei übertragen werden können. Der Detaillierungsgrad wurde dabei auf ein Mi-

nimum reduziert, weil der Fokus auf dem Parameter Mapping liegt. Alle Bauteile wur-

den als eigene Revit-Familien erstellt. Die Eigenschaften stammen aus den gemein-

sam genutzten Parametern, die speziell für das Beispiel angelegt wurden.

Abbildung 27 - Gemeinsam genutzte Parameter

5 Beispiel

5 Beispiel 42

Alle Attribute haben in Revit und IFC den gleichen Namen, daher kann die rechte

Spalte in allen Zeilen leer bleiben. Außer IfcExportAs werden alle Shared Parameters

in die IFC-Datei übertragen. Hier reicht ein Property-Set für das gesamte Modell aus,

weil alle Typen als IfcBuildingElementProxy überschrieben werden und somit diesem

Set zugeordnet werden. Wenn Eigenschaften in der Revit-Familie nicht vorhanden

sind, lässt der Exporter sie einfach aus, also stellt es kein Problem dar, dass nicht jede

Klasse über alle Attribute aus dem Property-Set verfügt.

Abbildung 28 - Definition des Eigenschaftensatzes

5 Beispiel 43

5.1 Erstellen der Familien

Als Grundlage der unterschiedlichen Familien dient die Standardvorlage „M_Allgemei-

nes Modell.rft“. Die Geometrie der Objekte ist durch Extrusion und Abzugskörper ent-

standen. Da die Familien nur als Platzhalter für den Export in die IFC-Datei dienen,

wurde auf realistische Maße und Formgestaltung verzichtet.

Die Wiederlager bestehen beispielsweise aus einem Quader, von dem ein kleinerer

Quader abgezogen wurde, um die Auflage für die Träger zu schaffen.

Abbildung 29 - Ansicht des Widerlagers im Familieneditor

Anschließend werden die passenden Eigenschaften aus den gemeinsam genutzten

Parametern hinzugefügt.

Abbildung 30 - Familientypen in der Familienansicht von Revit

5 Beispiel 44

Durch die Gruppen in den Shared Parameters, ist es leicht die benötigten Eigenschaf-

ten zu finden. Zum Beispiel befinden sich Eigenschaften wie „Betongüte“ und „Art des

Betonstahls“ in der Gruppe „Stahlbeton-Teile“

Abbildung 31 - Gruppenauswahl der gemeinsam genutzten Parameter

5.2 Vergleich des Modells in Revit und IFC (in Solibri Model Viewer)

Die Brücke besteht aus den Bauteilen Widerlager, Träger, Stütze, Fundament, Über-

bauelement, Fahrbahn und Kappe. In der folgenden Abbildung sind diese nochmal

visualisiert.

Abbildung 32 - Beispielmodell in Revit mit Kennzeichnung der einzelnen Klassen

5 Beispiel 45

Wie man in den beiden folgenden Bildern erkennen kann, wurden alle Eigenschaften

und Werte aus Revit übertragen. Lediglich IfcExportAs bleibt aus, weil es in der IFC-

Datei nicht als Attribut benötigt wird und deshalb nicht im Property-Set zum Export

definiert ist.

Abbildung 33 - Widerlager im Detail (Revit)

Abbildung 34 - Widerlager im Detail (IFC)


Obwohl sich der flächendeckende Einsatz von Building Information Modeling noch

nicht international durchsetzen konnte, stellt diese Methode der Projektabwicklung ein

Schlüsselelement der Digitalisierung des Bauwesens dar. BIM setzt auf ein Gebäude-

datenmodell, welches im Zentrum der Verwaltung und Organisation der Prozesse und

Auswertungen steht. Der Einsatz an Ressourcen ist hoch um diese Arbeitsweise um-

zusetzen, aber das Ergebnis kann diesen bei korrekter und konsequenter Verwendung

von BIM-gestützter Projektabwicklung wett machen. Diesem technologischen Wandel

stehen noch einige Hürden im Weg, wobei diese meist aus Fehlinformation und der

„Macht der Gewohnheit“ an das traditionelle System mit zweidimensionalen Plänen

folgen. Diesen Hindernissen wirkt in vielen Ländern unter anderem der Staat mit ver-

pflichtenden Maßnahmen bei der Abwicklung von Projekten aus öffentlicher Hand ent-

gegen. Auch die Bemühungen ein offenes Format für Gebäudedatenmodelle zu ent-

wickeln bringen BIM in den Fokus des öffentlichen Auftraggebers, auch weil so die

Garantie für Unabhängigkeit gegenüber Softwareentwicklern beim Ausschreiben des

Projektes besteht. Bei diesem offenen, herstellerneutralen Format handelt es sich um

IFC. Es wird von einem internationalen Konsortium entwickelt, an welchem Software-

entwickler, Firmen aus dem Bauwesen, Regierungen und auch Privatpersonen Mit-

spracherecht haben. buildingSMART, so heißt dieser Zusammenschluss, verbessert

und erweitert IFC stetig und dokumentiert diese Entwicklung in einer Online-Bibliothek.

Da sich Autodesk Revit größtenteils auf dem Hochbau beschränkt, kann man hier

durch das Erzeugen von Klassen und dem Parameter Mapping das Spektrum auf den

Infrastrukturbereich erweitern. Parameter Mapping bedeutet, dass man Eigenschaften

aus dem Revit-Modell mittels benutzerdefinierter Property-Sets in die IFC-Datei über-

tragen kann, obwohl diese nicht in standardisierten Schemata des Formats enthalten

sind. Den Schritt der Definition dieser Eigenschaftensätze muss man momentan noch

manuell ausführen, doch der Effizienz wegen wäre es von Vorteil auch diesen Prozess

zumindest teilweise zu automatisieren. Beispielweise sollte es in naher Zukunft mög-

lich sein die Textdatei, in welcher die Definitionen gespeichert werden, durch eine Ap-

plikation mit einer grafischen Benutzeroberfläche zu erstellen. Optimalerweise steht

6 Zusammenfassung und Fazit


dabei eine Auswahl der Eigenschaften aus den Shared Parameters zur Verfügung,

sodass Eingabefehler so gut wie unmöglich werden.

Literaturverzeichnis 48

Literaturverzeichnis

Borrmann, A.; König, M.; Koch, C.; Beetz, J. (2015): Building Information Modeling.

Technologische Grundlagen Und Industrielle Anwendungen: Vieweg + Teubner

Verlag.

Eastman, Charles M.; Teicholz, Paul; Sacks, Rafael; Liston, Kathleen (2011): BIM

handbook. A guide to building information modeling for owners, managers, de-

signers, engineers and contractors. 2nd ed. Hoboken, NJ: Wiley.

Egger, M.; Hausknecht, K.; Liebich, T.; Przybylo, J. (2013): BIM-Leitfaden für Deutsch-

land

Niedermaier, A.; Bäck, R. (2014): Allplan. BIM-Kompendium. Theorie und Praxis

National Institute of Building Sciences (NIBS) (2012): Frequently Asked Questions

About the National BIM Standard-United States™ https://www.nationalbimstan-

dard.org/faqs#faq1 Zugriff am 28.02.2018

McPartland, R. (2017): BIM Levels explained. Definitions for levels of BIM maturity

from Level 0, through Level 1, Level 2 and Level 3 and beyond.

https://www.thenbs.com/knowledge/bim-levels-explained Zugriff am:

28.02.2018

Autodesk (2018): Revit IFC Handbuch. Ausführliche Anleitung für den Umgang mit

IFC-Dateien

buildingSMART (2013): Industry Foundation Classes, Version 4, Documentation,

http://www.buildingsmart-tech.org/ifc/IFC4/final/html/ Zugriff am: 05.03.2018

buildingSMART (2017): Industry Foundation Classes. Technical resources for software

developers (IFC4_ADD2_TC1 - 4.0.2.1 [Official]) http://www.buildingsmart-

tech.org/ifc/IFC4/Add2TC1/html/ Zugriff am 07.03.2018

Autodesk (2017): AUTODESK KNOWLEDGE NETWORK https://knowledge.auto-

desk.com/ Zugriff am 16.03.2018

Anhang A 49

• Der schriftliche Teil der Arbeit als Worddokument

• Die Daten des Projektes:

o Revit Projekt

o Revit Familien

o Gemeinsam genutzte Parameter als Textdatei

o Definition des Property-Sets als Textdatei

o IFC-Datei

Anhang A

Datenträger

Hiermit erkläre ich, dass ich die vorliegende Bachelor-Thesis selbstständig angefertigt

habe. Es wurden nur die in der Arbeit ausdrücklich benannten Quellen und Hilfsmittel

benutzt. Wörtlich oder sinngemäß übernommenes Gedankengut habe ich als solches

kenntlich gemacht.

Ich versichere außerdem, dass die vorliegende Arbeit noch nicht einem anderen Prü-

fungsverfahren zugrunde gelegen hat.

München, 16. April 2018

Vorname Nachname

Erklärung

definition der ifc-modellinhalte von infrastrukturbau ... · revit, and edit it in the original...

Documents