the information delivery manual and model view definition · automatisierung von abläufen. um die...

Faculty of Civil, Geo and Environmental Engineering Chair of Computational Modeling and Simulation Prof. Dr.-Ing. André Borrmann Faculty of Architecture Chair of Architectural Informatics Prof. Dr.-Ing. Frank Petzold

The Information Delivery Manual and Model View Definition

27. Juli 2018

Report

Advanced Topics in Building Information Modeling

Jaser Heideri

Verena Hölzlwimmer


Seite 2

Chair of Computational Modeling and Simulation Chair of Architectural Informatics

I Inhaltsverzeichnis

1. Einleitung .............................................................................................. 3

2. Prozessgestützte Bauabläufe ......................................................................... 4

3. IDM – fachliche Anforderungen............................................................. 6

3.1. IDM allgemein ....................................................................................... 6

3.2. Prozessdiagramme ............................................................................... 8

3.3. Exchange Requirement (ER) ................................................................ 9

4. Industry Foundation Classes .............................................................. 11

4.1. IFC – Datenstruktur ............................................................................ 12

4.2. Export IFC .......................................................................................... 16

5. MVD – technische Umsetzung ............................................................ 22

5.1. MVD allgemein ................................................................................... 22

5.2. Vordefinierte MVDs ............................................................................. 23

5.3. mvdXML ............................................................................................. 24

6. Reference View vs. Design Transfer View .......................................... 29

7. Zusammenfassung ............................................................................. 37

A. Abkürzungsverzeichnis ....................................................................... 38

B. Literaturverzeichnis ............................................................................. 39

C. Abbildungsverzeichnis ........................................................................ 41


Seite 3


1. Einleitung

Die Baubranche durchlebt mit fortschreitender technischer Entwicklung einen rasanten

Wandel von der zweidimensionalen Planung bis hin zur computergestützten

Gebäudemodellierung. Der technische Fortschritt betrifft nicht nur die Vereinfachung

der reinen Zeichentätigkeit durch Computer-Aided-Design (CAD) -Programme, im

Rahmen des Building Information Modeling1 können zudem neben geometrischen

Informationen auch nichtparametrische Informationen in einem zentralen Modell

gespeichert werden. Spätestens mit der Einführung des „Stufenplan Digitales Bauen

und Planen“ im Jahr 2015, der die Anwendung der Arbeitsmethode BIM ab 2020 für

alle öffentlichen Verkehrs- und Infrastrukturprojekte vorsieht (BMVI 2015), erhält diese

Entwicklung eine immer größer werdende Wichtigkeit bei vielen planenden

Ingenieurbüros.

Die Anwendung der Arbeitsmethode BIM beinhaltet die Bearbeitung und

Zusammenführung der Teilaufgaben verschiedenster Fachdisziplinen in einem

gemeinsamen Modell. Ein wesentlicher Vorteil, den diese Arbeitsweise mit sich bringt,

ist die ständige Verfügbarkeit aktueller Pläne für die Projektbeteiligten. Somit kann

verhindert werden, dass auf Grundlage verschiedenster Arbeitsstände geplant wird

und Änderungen übersehen werden. Des Weiteren können Kollisionen und Fehler

bereits in der Planung entdeckt werden.

Doch BIM stellt die Baubranche auch gleichzeitig vor neue Herausforderungen.

Aufgrund der Vielfältigkeit eines Bauprojektes gilt es, sowohl örtliche, als auch

softwaretechnische Distanzen zu überwinden. Der Austausch von intelligenten Daten,

wie sie in dem zentralen BIM-Modell zur Verfügung stehen, muss somit als

herstellerunabhängige Schnittstelle ermöglicht werden. Die technische Lösung hierfür

entwickelte die Organisation buildingSMART mit der Einführung der Industry

Foundation Classes (IFC) (buildingSMART 2018). Diese Schnittstelle ist heute bereits

ein gängiges Austauschformat in vielen CAD-Programmen (Autodesk 2018).

Doch die Zusammenarbeit in einem Modell beinhaltet zudem, dass die Bearbeitung

der Aufgaben verschiedenster Fachdisziplinen als Teil eines ganzheitlichen Prozesses

gesehen werden muss. Die Koordination der einzelnen Prozesse, bzw. das

Prozessmanagement ist somit unabdingbar bei der Arbeit mit BIM (Borrmann, et al.

2015), um eine reibungslose Zusammenarbeit zu ermöglichen. Es ist wichtig,

Informationsaustauschflüsse effizient, transparent und wirtschaftlich zu gestalten.

Ziel dieser Projektarbeit soll somit die Darstellung der durch BIM entstandenen

Herausforderungen in der Prozessmodellierung und die entwickelten Lösungen hierfür

sein.

1 kurz: BIM


Seite 4


2. Prozessgestützte Bauabläufe

Bei der computergestützten Modellierung von Gebäuden entstehen Prozesse, in

denen digitale Bauwerksinformationen erstellt, verändert oder weitergegeben werden.

Wie bereits eingangs erwähnt, ist es bei der Arbeit mit BIM von großer Bedeutung,

diese Prozesse zu planen und zu koordinieren. (Borrmann, et al. 2015) Die

Prozessmodellierung beinhaltet somit allgemein gesehen die formale Beschreibung

der Geschäftsprozesse, sowie die softwaregestützte Verbesserung und

Automatisierung von Abläufen. Um die formalen Festlegungen abzubilden, werden

grafische Notationen und Diagrammsprachen wie z.B. die Business Process Modeling

Notation (BPMN) verwendet. (Funk, et al. 2010)

Im Konkreten legt man im Rahmen des Prozessmanagements fest, „wer (Akteure)

macht was (Aufgaben), wann (zeitliche Abfolge), wie (Qualität), womit (Ressourcen)

und zu welchem Zweck (Unternehmensziele)“ (Funk, et al. 2010). Des Weiteren

werden Schnittstellen definiert und Freigabeprozesse geplant. Das

Prozessmanagement beinhaltet somit nicht nur die Organisation des digitalen

Datenaustausches, es bedeutet zudem die Zusammenarbeit neu zu strukturieren.

(Borrmann, et al. 2015)

Um die Abläufe im Bauwesen prozessgestützt umsetzen zu können, müssen an die

Beschaffenheiten von BIM angepasste Spezialisierungen des Prozessmanagements

eingeführt werden. Eine wesentliche Besonderheit von Prozessabläufen in der

Baubranche im Rahmen von BIM ist die Vielfalt der unterschiedlichen Schnittstellen.

Wie bereits eingangs erwähnt, wurde ein herstellerneutrales Datenformat eingeführt,

um Datenverluste zwischen einzelnen Prozessen zu vermeiden, die IFC-Schnittstelle.

Diese offene Schnittstelle ist in der Bauplanung besonders wichtig, da die Konstellation

der Partner hier häufig wechselt (Eastman, et al. 2010).

Die IFC-Datenstruktur zerlegt das Gebäude in seine Bestandteile und beschreibt die

Geometrie, Eigenschaften und Beziehungen dieser Elemente detailliert. Dabei ist

dieses Schema sehr komplex. In einem IFC-Modell lässt sich beispielsweise die ein-

und dieselbe dreidimensionale Geometrie auf unterschiedliche Art und Weisen

darstellen. Dies rührt daher, dass mit einem Modell möglichst alle Aspekte des Bauens

abgebildet werden sollen und alle Downstream-Tools unterstützt werden sollen. So

wird z.B. der Informationsschwerpunkt für Kostenberechnungen anders gesetzt als für

thermische Berechnungen. (Borrmann, et al. 2015) Wie genau die Datenstruktur der

IFC aufgebaut ist, wird im Kapitel 4 genauer gezeigt.

Aufgrund der Komplexität der IFC-Datenstruktur ist es notwendig, das vorhandene

Modell für bestimmte Prozesse einzuschränken. Dies bedeutet, dass der

Datenaustausch hinsichtlich spezifischer Inhalte und den Entwicklungsgraden genau

zu definieren ist, um Fehler zu vermeiden. (Eastman, et al. 2010) Hierfür wurde von


Seite 5


Building SMART die IDM2 / MVD3 - Methode eingeführt. Die IDM – Methode beschreibt

mithilfe einer grafischen Notation die Teilprozesse, die im Rahmen einer

Prozessmodellierung ermittelt wurden und leitet daraus Anforderungen ab, die

beschreiben, welche Modellinhalte auszutauschen sind (Exchange Requirements

(ER)). Die MVD beinhaltet anschließend die technische Umsetzung der ER und legt

fest, welche Entitäten und Attribute des IFC-Modells festgelegt werden müssen, um

ein bestimmtes Austauschszenario zu verwirklichen. (buildingSMART 2018)

Hierdurch werden Interpretationsspielräume verkleinert und die

Schnittstellenimplementierung vereinfacht (Borrmann, et al. 2015).

2 kurz für: Information Delivery Manual 3 kurz für: Model View Definition

Abbildung 1 IDM / MVD-Methode (eigene Darstellung)


Seite 6


3. IDM – fachliche Anforderungen

3.1. IDM allgemein

Wie bereits erwähnt, beinhaltet die IDM die formale Beschreibung und

softwaretechnische Unterstützung von Prozessen, sowie fachliche Anforderungen für

ein bestimmtes Austauschszenario aus dem Gesamtmodell. Ziel ist es, Informationen

für spezielle Anforderungen innerhalb des Lebenszyklus eines Gebäudes zu

spezialisieren und gleichzeitig offene Standards zu ermöglichen. So kann die

Informationsqualität innerhalb bestimmter Prozesse verbessert werden und ein

gesicherter Austausch erfolgen. (Wix, Information Delivery Manual 2011)

Abbildung 2 Übersicht IDM und seine Bestandteile (Wix, Information Delivery Manual 2011)

Das National Institute of Building Sciences erstellte 2007 einen nationalen BIM-

Standard, den NBIMS (National BIM Standard). Hiermit sollen Standards erstellt

werden können, um verschiedene Datenaustauschszenarien zu dokumentieren und

somit praxisnahe Lösungen zu liefern (NBIMS 2018). So spezifizieren eine Gruppe von

Experten IDMs, nach denen dann MVDs entwickelt werden können.

Softwareentwickler können diese anschließend in ihren Schnittstellen zur Verfügung

stellen (Eastman, et al. 2010).

Kapitel 5 des NBIMS beschreibt, wie oben genannte Standards entwickelt werden.

Zum Entwicklungsprozess gehören im Wesentlichen 4 Phasen, welche in Abbildung 3

zu sehen sind. Phase 1 beschreibt den Zusammenschluss von Experten zu einer

Arbeitsgruppe, um ein Prozessdiagramm (grafische Notation) und hier inbegriffene

Austauschanforderungen (ER) zu erstellen. Phase 2 beinhaltet das Design. Hier

werden MVD Konzepte anhand des IDM erstellt und in Phase 3 technisch umgesetzt.


Seite 7


Die letzte Phase, Phase 4, ist die Bereitstellung und letztlich die Nutzung der MVDs.

Auf die Rolle der MVDs wird in Kapitel 5 genauer eingegangen.

Abbildung 3 Überblick des NBIMS Entwicklungsprozesses (NBIMS 2018)


Seite 8


3.2. Prozessdiagramme

Prozessdiagramme sind, wie aus Abbildung 2 ersichtlich ist, ein wesentlicher

Bestandteil der IDM. Sie zeigen eine Übersicht eines gewählten Teilprozesses im

Rahmen der Prozessmodellierung der Bauplanung, Ausführung oder Nutzung von

Bauwerken mithilfe von grafischer Notation (Borrmann, et al. 2015). Dies erfolgt mit

der Notationssprache BPMN, die es ermöglicht, Geschäftsprozesse besser

darzustellen und mehrere Akteure zu berücksichtigen (Wix, Process Mapping 2015) .

Im Konkreten wird ein Prozessdiagramm dazu verwendet, die Aufgaben, die in einem

Geschäftsprozess ausgeführt werden zu verstehen. Hierunter fallen Themen wie die

Reihenfolge, in der sie ausgeführt werden, die Teilnehmer oder Akteure der Prozesse,

sowie die Informationen, die zwischen den Teilnehmern als Ergebnisse ausgetauscht

werden. Außerdem können Anfangs- und Endtermine des Prozesses dargestellt

werden, sowie Entscheidungen innerhalb der Abläufe. (Wix, Process Mapping 2015)

Um den vollständigen Informationsaustausch zwischen den Teilnehmern zu

gewährleisten, können Anforderungen an den Datenaustausch (ER) zu einzelnen

Prozessschritten zugeordnet werden (Borrmann, et al. 2015).

Um den Aufbau eines Prozessdiagrammes genauer darzustellen, wird ein Beispiel der

Energiebedarfsermittlung herangezogen. Das zugehörige Prozessdiagramm ist

Abbildung 4 zu entnehmen.

Abbildung 4 Prozessdiagramm nach Energy-Analysis IDMl (Borrmann, et al. 2015)


Seite 9


Grundlegende Struktur eines Prozessdiagramms, welches wie bereits erwähnt mithilfe

der Notationssprache BPMN erstellt wird, bildet der sogenannte „swimming pool“, der

horizontal in verschiedene Bahnen unterteilt wurde. Somit werden in vertikale Richtung

die Teilnehmer den Bahnen zugeordnet, wohingegen in horizontaler Richtung eine

Einteilung des Planungsablaufs erfolgt. Nachdem das Start- und Endereignis,

abgebildet als Kreise, festgelegt und eingetragen wurde, können die verschiedenen

Aufgaben, die für die Erfüllung des Teilprozess notwendig sind, den Akteuren in

richtiger Reihenfolge zugeordnet werden. In der BPMN werden Ereignisse in

Rechtecken mit abgerundeten Ecken dargestellt. Im nächsten Schritt werden die

Aktivitäten mithilfe von Pfeilen miteinander verbunden, um Informationsflüsse

darzustellen. Hierbei können Entscheidungspunkte eingefügt werden, welche über

den Ablauf des weiteren Prozessablaufs bestimmen. Diese werden als Rauten

dargestellt. Um die Informationsflüsse genauer zu definieren, werden ERs angelegt

und im Diagramm den entsprechenden Schritten zugeordnet. Wie genau ein ER

aussieht soll im nächsten Kapitel behandelt werden. (Wix, Process Mapping 2015)

3.3. Exchange Requirement (ER)

Mit den Exchange Requirements wird ein tabellarischer Anforderungskatalog für den

Informationsaustausch zwischen den einzelnen Prozessschritten erstellt (Borrmann,

et al. 2015). Dabei sind diese Anforderungen vom gewählten Austauschformat

unabhängig, jedoch beschreiben sie fachliche Themen. (Wix,

IDM_ExchangeRequirements 2015) Mit diesen ERs ist es anschließend möglich, ein

bestimmtes Austauschszenario unter Berücksichtigung der für den Planer relevanten

grafischen und inhaltlichen Informationen zur Verfügung zu stellen. Zum Beispiel

werden für eine thermische Simulation Informationen über Belichtungsflächen in einer

Wand und in einem Raum benötigt, wohingegen für ein Facility-Management-System

nur grundlegende geometrische Informationen und spezifische Bauteil-Attribute wie

Anlageninformationen und Brandschutzeigenschaften übergeben werden müssen.

(Autodesk 2018)

Es wird also eine Art Pflichtenheft erstellt, welches nach Bauteilen gegliedert ist und

die erforderlichen Eigenschaften, Datentypen, Einheiten, zulässige Wertebereiche,

Relationen zu anderen Elementen etc. festlegt (Borrmann, et al. 2015). Somit ist es

möglich, angeforderte Informationen formell zu beschreiben um daraus ein gefiltertes

Teilmodell zu erstellen.

Anknüpfend an oben genanntes Beispiel, wird in Abbildung 5 ein Ausschnitt aus dem

„IDM BIM Based Energy Analysis Modell“ gezeigt.


Seite 10


Abbildung 5 Ausschnitt aus IDM BIM Based Energy Analysis Modell (Borrmann, et al. 2015)

In den nächsten Schritten wird diese für den Nutzer lesbare Form der ER mithilfe von

MVD-Diagrammen formalisiert, anhand derer dann die technische Implementierung

der Model View Definition auf Basis der herstellerunabhängigen Schnittstelle IFC

erfolgen kann. Dies soll in Kapitel 4.2 genauer erläutert werden. Um einen

vollumfänglichen Einblick in den Aufbau von MVDs zu erhalten, soll in Kapitel 4.1

zunächst ein Einblick in die Datenstruktur von den Industry Foundation Classes

gegeben und anschließend die Gliederung von IFC-Dateien untersucht werden.


Seite 11


4. Industry Foundation Classes

Die Industry Foundation Classes gelten als herstellerunabhängiges Datenformat für

den Austausch von digitalen Gebäudemodellen, in welchen das Gebäude sowohl

geometrisch als auch semantisch beschrieben werden kann. Wesentliche Vorteile von

neutralen Exportdateien sind unter anderem die garantierte Lesbarkeit nach längerer

Zeit (Borrmann, et al. 2015). Das Datenformat wird stets weiterentwickelt, weswegen

es verschiedenste Versionen gibt. Die aktuellste Version der IFC-Schnittstelle ist die

Version IFC4, welches aufgrund der Komplexität der Implementierung noch nicht von

allen Anbietern angeboten wird. IFC 2x3 wird jedoch von den meisten Anbietern

unterstützt. (Autodesk 2018)

Um bestimmte technische Implementierungen anhand eines Beispiels zu zeigen, wird

eine einfache einschalige Wand, Stahlbeton 25 cm in Autodesk Revit 2017 erstellt und

exportiert.

Abbildung 6 Beispiel Stahlbetonwand


Seite 12


4.1. IFC – Datenstruktur

Die IFC-Datenstruktur basiert auf STEP4, einer Vorgabe für den Aufbau von Daten

nach ISO 10303 und wird mithilfe der Modellierungssprache EXPRESS beschrieben.

EXPRESS gibt also vor, wie die geforderten Informationen gespeichert werden sollen.

Instanzen, also mit realen Werten belegte Attribute der Klassen, werden erst durch das

STEP Physical File generiert, kurz SPF, welches mit der Dateiendung „.ifc“ zu

erkennen ist (Liebich 2009). Zusätzliche Formate wie das „. ifcXML“ wurden speziell

für Programme entwickelt, die keine IFC-Schnittstelle besitzen (Niedermaier und Bäck

2014).

Das IFC-Datenmodell ist grundlegend in vier Stufen aufgeteilt. In diesen sogenannten

„Layer“ werden verschiedenste Klassen beschrieben, welche von der untersten bis zur

obersten Stufe immer spezifischer werden. Elemente aus der obersten Stufe können

auf Elemente der untersten Stufe zugreifen, dies gilt jedoch nicht in entgegengesetzter

Richtung. Das Gebäudedatenmodell wird somit durch eine Kombination der

verschiedenen Klassen aus den unterschiedlichen Layer beschrieben. In Abbildung 7

lässt sich der Aufbau der Layer-Struktur des IFC-Modells erkennen. (buildingSMART,

IFC 4 Official Release 2013)

4 Standard for the Exchange of Product model data


Seite 13


1

2

3

4

Abbildung 7 Layer-Struktur des IFC-Modells (buildingSMART, IFC 4 Official Release 2013)

Auf erster Stufe befinden sich somit Elemente, welche unabhängig vom

Anwendungsbereich von hierarchisch höheren Klassen benutzt werden können. In der

Entität „GeometricResource“ werden beispielsweise grundlegende Elemente zur

geometrischen Repräsentation von Objekten definiert. Hierunter fällt zum Beispiel die

Definition von Punkten, Kurven oder Oberflächen. (buildingSMART, IFC 4 Official

Release 2013)

Die nächste Ebene ist aus dem sogenannten Kernel und seinen Erweiterungen

aufgebaut. Das Kernel bildet den Kern des IFC-Datenmodells und legt fest, wie die

Instanzen des Gebäudemodells mit ihren Attributen und Beziehungen zueinander

beschrieben werden können. Hier werden ausgehend von der Wurzelklasse IfcRoot


Seite 14


durch Vererbungshierarchien die drei grundlegenden Entitäten und ihre

Spezialisierungen definiert. Diese drei Entitäten sind IfcObjectDefinition, die als

Superklasse für alle physischen Elemente gilt, IfcPropertyDefinition, welche als

Superklasse für Eigenschaftsdeklarationen gilt und IfcRelationship, durch welche sich

Beziehungen beschreiben lassen. IfcObjectDefinition unterteilt sich anschließend in

IfcTypeObject und IfcObject, welches wiederum durch Vererbung in 6 weitere Entitäten

wie IfcProduct oder IfcResources unterteilt wird. In den Erweiterungen des Kernels,

also den Control Extensions, Process Extensions oder Product Extensions, befinden

sich Entitäten, welche ausgehend von den Grundentitäten für weit gefächerte

Anwendungsbereiche benutzt werden können. So finden sich zum Beispiel in zuletzt

genannter Erweiterung Konzepte wie IfcElement oder IfcSpatialProjectStructure. In

IfcSpatialProjectStructure wird der Aufbau der Projektstruktur beschrieben, also in

welcher Reihenfolge das Gebäude beschrieben wird. (buildingSMART, IFC 4 Official

Release 2013) Dies wird in Abbildung 8 grafisch dargestellt.

Abbildung 8 grafische Darstellung IfcSpatialProjectStructure (Autodesk 2018)

Ein Element der Klasse IfcElement wird dieser Struktur zugeordnet und weiter

unterteilt, wie in das Element IfcBuildingElement oder IfcOpening. (buildingSMART,

IFC 4 Official Release 2013)

Hierarchisch höher liegt Stufe 3, auf welcher Entitäten definiert werden, die abgeleitet

von Stufe 2 spezifiziert sind. Hier finden sich zum Beispiel unter

IfcSharedBuildingElements grundlegende Elemente des Bauens wie IfcWall,

IfcColumn oder IfcWall. (buildingSMART, IFC 4 Official Release 2013)

Auf 4. Ebene finden sich Entitäten, die für spezielle Anwendungsbereiche wie

Architektur oder die Tragwerksplanung ausgebildet wurden. (buildingSMART, IFC 4

Official Release 2013)


Seite 15


Durch eine Analyse eines SPF-Skriptes einer einfachen Wand, konnte eine Grafik

erstellt werden, welche die wesentlichsten Beziehungen der Elemente der

unterschiedlichen Stufen genauer darstellt.

Abbildung 9 IFC-Datenmodell

Um die vielfältigen Anwendungsbereiche und Downstream-Möglichkeiten eines

digitalen Gebäudemodells abdecken zu können, wird im IFC-Datenmodell zwischen

semantischer und geometrischer Darstellung strikt unterschieden, wie aus Abbildung

9 ersichtlich wird (IfcProductDefinitionShape). So kann ein und dasselbe Objekt für

verschiedene Anwendungsbereiche unterschiedlich abgebildet werden.

Grundsätzlich stehen zwei Möglichkeiten zur Verfügung, ein dreidimensionales IFC-

Objekt geometrisch zu beschreiben: ein Sweep entlang einer Kurve oder Boundary

Representation (BREP). (Autodesk 2018) Beim Sweep wird „ein definiertes Profil

entlang eines Pfades zur Volumenerzeugung geführt.“ (Autodesk 2018). Dies hat zum

Vorteil, dass Speicherplatz gespart wird. Durch die Beschreibung der Geometrie durch

Grundlinie und Grundform können Veränderungen an Höhe, Breite oder Länge leicht

durchgeführt werden.

ObjectDefinition Layer 2 . . . Element Layer 2 . . .

IfcRelDefinesByProperties

PropertySet(…Pset_WallCommon…)

IfcProductDefinitionShape

#

IfcRelContainedinSpatialStruture

IfcBuildingStorey

Layer 2 . . . ObjectDefinition Layer 2

IfcAxis2Placement Layer 1

# #

#

IfcMaterialLayerSet Layer 1


Seite 16


Das BRep-Modell beschreibt das Bauteil mit Hilfe von Koordinaten und stellt diese

Koordinaten anschließend in Verbindung, um Kanten oder Flächen zu beschreiben.

Dies beansprucht mehr Speicherplatz. (Autodesk 2018) Veränderungen an Höhe,

Breite oder Länge sind oft fehlerhaft, da die einzelnen Koordinaten neu referenziert

werden müssten und so durch Verschiebung einzelner Punkte Lücken im Punktmodell

entstehen. Mengenermittlungen sind jedoch aufgrund der genauen Beschreibung der

Geometrie zuverlässiger. (Hölzlwimmer 2015)

Wie in Abbildung 10 gezeigt ist, werden dem Bauteil Eigenschaften wie

Trageigenschaften, Ausrichtungen oder spezifische Eigenschaften wie

Brandschutzklassen durch sogenannte PropertySets zugeteilt. Durch das Erstellen

eines Objektes, das einer bestimmten Klasse zugehörig ist, werden vordefinierte

Standardattribute mit den zugehörigen Werten belegt. Ein beispielhaftes PropertySet

ist das „Pset_WallCommon“, das eine allgemeingültige Wand beschreibt. (Autodesk

2018)

Abbildung 10 Pset_WallCommon (Autodesk 2018)

4.2. Export IFC

Das SPF-File, welches die allgemeine IFC-Datenstruktur instanziiert, wird beim Export

des digitalen Gebäudemodells erstellt. Durch eine Verweisstruktur wird somit das

Gebäudemodell mit allen geometrischen und nicht-grafischen Attributen abgebildet.

Doch die Qualität der zu exportierenden Datei hängt von den Exporteinstellungen, als

auch von der Modellierungsweise in der Ursprungssoftware ab. So wird in Revit

beispielsweise eine Geschossdecke über die Grundfläche und Extrusion über die

einzelnen Schichten hinweg generiert. Dieses Verfahren ist gleich zur Datenstruktur in

IFC (Sweep) und somit wird ein Export bestmöglich umgesetzt. (Autodesk 2018)


Seite 17


Neben den, dem Anwendungszweck des Exports angepassten Einstellungen zu den

MVDs, auf die in Kapitel 5 genauer eingegangen wird, kann die Qualität des IFC-

Modells jedoch auch über die sogenannten Export-Zuordnungstabellen beeinflusst

werden. Hier können Revit-Kategorien wie zum Beispiel Wände den IFC-

Klassennahmen (IfcWall) zugeordnet werden. Die hier vorgesehenen

Grundeinstellungen können so einfach geändert werden. Ein Beispiel, bei dem eine

Änderung Sinn machen könnte, ist bei der Erstellung von Geschossdecken. Hier

werden zuerst die tragenden Elemente modelliert, um anschließend pro Raum den

Fußbodenaufbau als mehrschichtige Decken einzufügen. Beim Export wird der

Fußbodenaufbau somit automatisch der IFC-Klasse IfcSlab zugeordnet. Dies führt des

Öfteren zu Problemen bei der Auswertung im Rahmen der Mengenermittlung oder

Ausschreibung, da hier wichtige Eigenschaften des Bodenaufbaus nicht übertragen

werden. Indem man in der Zuordnungstabelle dem Fußbodenaufbau die Klasse

IfcCovering.FLOORING zuweist, können Attribute wie Entflammbarkeit und

Oberflächengüte mitberücksichtigt werden. (Autodesk 2018)

Abbildung 11 IFC-Exportklassen Revit

Wenn der Export anschließend erstellt wurde, kann das SPF-File mit der Dateiendung

„.ifc“ durch einen Texteditor geöffnet und analysiert werden. Die Datei ist in 2 Teile

unterteilt, dem Abschnitt „header“ und „data“. Beide beginnen mit der


Seite 18


Abschnittsbezeichung („HEADER/DATA;“) und enden mit „ENDSEC;“. Das SPF-File

beginnt mit dem Abschnitt „header“. Hier werden allgemeine Information zum

Gebäudemodell, zur IFC-Version, zur verwendeten Software und zur entsprechenden

MVD angegeben.

Als Beispiel wird nachfolgend ein Ausschnitt aus dem SPF-File der oben genannten

Wand aufgeführt.

ISO-10303-21; HEADER; /****************************************************************************************** * STEP Physical File produced by: The EXPRESS Data Manager Version 5.02.0100.07 : 28 Aug 2013 * Module: EDMstepFileFactory/EDMstandAlone * Creation date: Thu Jun 28 10:01:50 2018 * Host: Verena-THINK * Database: C:\Users\Verena\AppData\Local\Temp\{228987D0-733C-4EAB-A02B-74B10A55DE59}\ifc * Database version: 5507 * Database creation date: Thu Jun 28 10:01:48 2018 * Schema: IFC4 * Model: DataRepository.ifc * Model creation date: Thu Jun 28 10:01:49 2018 * Header model: DataRepository.ifc_HeaderModel * Header model creation date: Thu Jun 28 10:01:49 2018 * EDMuser: sdai-user * EDMgroup: sdai-group * License ID and type: 5605 : Permanent license. Expiry date: * EDMstepFileFactory options: 020000 ******************************************************************************************/ FILE_DESCRIPTION(('ViewDefinition [DesignTransferView_V1.0]'),'2;1'); FILE_NAME('Projektnummer','2018-06-28T10:01:50',('Verena'),('TU M\X2\00FC\X0\nchen _ Advanced Topis in BIM'), 'The EXPRESS Data Manager Version 5.02.0100.07 : 28 Aug 2013','20160225_1515(x64) - Exporter 17.0.416.0 - Alternate UI 17.12.14.0',''); FILE_SCHEMA(('IFC4')); ENDSEC;

Im zweiten Abschnitt, dem „data“-file, werden die eigentlichen Informationen des

Gebäudemodells aufgeführt, also alle geometrischen und nicht-grafischen

Informationen und deren Beziehungen, wie es in Kapitel 4.1 gezeigt wird. Hier werden

zum Beispiel grundlegende Klassen aus der ersten Hierarchieebene beschrieben,

ebenso wie Projektstruktur, Objekte und ihre Parameter, sowie die zugeordnete

Geometrie. Jede Instanz hat eine eigene STEP-ID und wird so eindeutig identifiziert.

Auch dieser Abschnitt soll anhand von Beispielen erklärt werden.


Seite 19


DATA; …

Im ersten Teil des „data“-files werden verstärkt Entitäten der Hierarchiestufe 1 definiert.

Beispielsweise werden hier Punkte (#6) oder Vektoren (#12) erstellt.

#6= IFCCARTESIANPOINT((0.,0.,0.)); #10= IFCCARTESIANPOINT((0.,0.)); #12= IFCDIRECTION((1.,0.,0.)); …

Mithilfe der Verweisstruktur von IFC können hierarchisch höher liegende Elemente auf

diese Elemente zugreifen und somit das IFC-Datenmodell aufbauen. #138 erstellt

einzelne Geschosse (hier Ebene 0) und platziert diese auf den dementsprechenden

Achsen.

#136= IFCAXIS2PLACEMENT3D(#6,$,$); #137= IFCLOCALPLACEMENT(#33,#136); #138= IFCBUILDINGSTOREY('3hMd8ACWzDlw4LNm7hoN8L',#42,'Ebene 0',$,$,#137,$,'Ebene 0',.ELEMENT.,0.); #140= IFCCARTESIANPOINT((0.,0.,3.)); …

#290 definiert die Verbindung zwischen #138, also dem jeweiligen Geschoss und

#192, hier die erstellte Wand. Durch IfcRelContainedInSpatialStructure wird das

Bauteil dem jeweiligen Geschoss zugeordnet.

#290= IFCRELCONTAINEDINSPATIALSTRUCTURE('13LV5dTeP3CAox54$56C1Z',#42,$,$,(#192),#138); …

Nachfolgender Abschnitt definiert die Geometrieabbildung der Wand. In #152 bis #159

wird die zweidimensionale Kurve beschrieben, anhand der anschließend durch einen

Sweep einer definierten Form entlang dieser Kurve die dreidimensionale

Repräsentation des Objektes erfolgen kann.

#173 definiert die Form, die entlang der Kurve gesweept wird. Die endgültige Form

wird aus Kombination von #159 und #183 in #186 beschrieben.

#152= IFCAXIS2PLACEMENT3D(#6,$,$); #153= IFCLOCALPLACEMENT(#137,#152); #155= IFCCARTESIANPOINT((6.,0.)); #157= IFCPOLYLINE((#10,#155)); #159= IFCSHAPEREPRESENTATION(#99,'Axis','Curve2D',(#157));


Seite 20


#166= IFCCARTESIANPOINT((3.,0.)); #168= IFCAXIS2PLACEMENT2D(#166,#26); #169= IFCRECTANGLEPROFILEDEF(.AREA.,$,#168,6.,0.25); #172= IFCAXIS2PLACEMENT3D(#6,$,$); #173= IFCEXTRUDEDAREASOLID(#169,#172,#20,3.); … #183= IFCSHAPEREPRESENTATION(#101,'Body','SweptSolid',(#173)); #186= IFCPRODUCTDEFINITIONSHAPE($,$,(#159,#183));

Das Bauteil Wand wird anschließend durch den Bezug auf die Geometriebeschreibung

erstellt.

#192= IFCWALLSTANDARDCASE('1rHsJnvX5BaOQ39rMj5N2z',#42,'Basiswand:STB 25.0:389274',$,'Basiswand:STB 25.0:3917',#153,#186,'389274',.NOTDEFINED.); …

Anschließend werden der Wand die entsprechenden Attribute zugeordnet. Hierzu

werden die einzelnen Attribute im ersten Schritt mit Werten belegt, um dann zu

PropertySets zusammengefasst zu werden (#248, #262). Im nächsten Schritt werden

Wand und PropertySets durch IfcRelDefinesByProperties in Verbindung gebracht.

#235= IFCPROPERTYSINGLEVALUE('Reference',$,IFCIDENTIFIER('STB 25.0'),$); #243= IFCPROPERTYSINGLEVALUE('LoadBearing',$,IFCBOOLEAN(.T.),$); #244= IFCPROPERTYSINGLEVALUE('ExtendToStructure',$,IFCBOOLEAN(.F.),$); #245= IFCPROPERTYSINGLEVALUE('IsExternal',$,IFCBOOLEAN(.T.),$); #246= IFCPROPERTYSINGLEVALUE('FireRating',$,IFCLABEL('F30'),$); #247= IFCPROPERTYSINGLEVALUE('ThermalTransmittance',$,IFCTHERMALTRANSMITTANCEMEASURE(4.184),$); #248= IFCPROPERTYSET('1rHsJnvX5BaOQ3BAYj5N2z',#42,'Pset_WallCommon',$,(#235,#243,#244,#245,#246,#247)); #261= IFCPROPERTYSINGLEVALUE('Manufacturer',$,IFCLABEL('AdvancedTopics'),$); #262= IFCPROPERTYSET('0ZT59xdC1EMPLgSUbwb4nE',#42,'Pset_ManufacturerTypeInformation',$,(#261)); #265= IFCRELDEFINESBYPROPERTIES('0XxTQ$wn5DEfZZ9Qf29ODp',#42,$,$,(#192), #248);


Seite 21


#269= IFCRELDEFINESBYPROPERTIES('2Je0xjEj55BxzmwBczHZkX',#42,$,$,(#192), #262); … ENDSEC; END-ISO-10303-21;


Seite 22


5. MVD – technische Umsetzung 5.1. MVD allgemein

Die Model View Definitions stellen die technische Lösung der erarbeiteten

Austauschanforderungen mehrerer Teilprozesse auf Basis von IFC dar und

ermöglichen somit einen anwendungsspezifischen Austausch eines Teilmodells vom

gesamten Gebäudemodell. Im Konkreten bedeutet dies, dass die im Pflichtenheft der

ER erstellten Informationen weiter formalisiert werden, indem Randbedingungen

getroffen und mithilfe eines MVD-Diagramms auf die Datenstruktur von IFC abgebildet

werden. (Borrmann, et al. 2015) Die Model Views bilden somit die technische

Unterstützung der Prozessabläufe.

Abbildung 12 MVD-Diagramm (Borrmann, et al. 2015)

Wie in Abbildung 12 abgebildet ist, wird durch die Erstellung des MVD-Diagramms

mithilfe farblicher Kennzeichnung geregelt, welcher Teil der IFC-Datenstruktur (bspw.

welche Klassen, Attribute, Beziehungen, usw.) für die Abbildung der erforderlichen

Informationen benötigt werden. Hierfür greift man auf so genannte Konzepte zurück,

in denen definiert ist, welche Attribute belegt und wie die Beziehungen untereinander

definiert werden müssen. Ein MVD kann aus mehreren Konzepten zusammengesetzt

sein. Anschließend kann dann auf dieser Grundlage die Softwareimplementierung

erfolgen, indem man das Diagramm in ein maschinenlesbares Format überführt.

Dieses Format ist das mvdXML-Format. (Borrmann, et al. 2015)

MVDs garantieren somit einen korrekten Import bzw. Export von IFC-Dateien und

bilden daher die Grundlage für die Zertifizierung vieler Softwareprodukte. (Eastman, et

al. 2010)


Seite 23


5.2. Vordefinierte MVDs

Wie bereits eingangs erwähnt, erfolgt der Austausch von Gebäudeinformationen über

die herstellerunabhängige Schnittstelle IFC mithilfe von Model Views, die ein

Teilmodell des nativen Formats abbilden können.

Da die MVDs im Kapitel 6 anhand eines konkreten Beispiels in der Softwareumgebung

von Revit genauer untersucht werden sollen, werden ausgewählte der hier

vordefinierten MVDs aufgeführt (vgl. Abbildung 13). Diese werden unterteilt in IFC 2x3

– und IFC4 – Versionen:

IFC 2x3:

- Coordination View 2.0: dient dem koordinierten Austausch von BIM-Modellen

zwischen den Hauptdisziplinen im Bauwesen (Architektur, Gebäudetechnik,

Ingenieurbau)

- Basic FM Handover View: für die Weiterverwendung in

Gebäudebewirtschaftungs- oder Verwaltungssystemen, hier werden wenige

grafische Informationen benötigt, entscheidender sind hier alphanumerische

Attribute für die Verwaltung in einer Datenbank

IFC4:

- Reference View: für die allgemeine Übergabe eines Referenzmodells für

Fachplaner mit Hauptaugenmerk auf die Anwendungszwecke der

Koordination und modellbasierten Mengenermittlung, somit notwendigste

geometrische Informationen, für die Weiterverarbeitung der Geometrie

ungeeignet

- Design Transfer View: Übergabe eines IFC-Modells mit dem Zweck der

Weiterverarbeitung in einer BIM-fähigen Software, es gilt hochparametrische

Eigenschaften übergeben werden

(Autodesk 2018)

Grundlegend sind die beiden MVDs aus der IFC4-Version eine Unterteilung der

Coordination View aus der IFC 2x3 -Version. Wie sich die verschiedenen MVDs in der

Softwareimplementierung voneinander unterscheiden, soll in Kapitel 6 genauer

betrachtet werden. (Graphisoft)


Seite 24


Abbildung 13 vordefinierte Model Views beim IFC-Export aus Revit

5.3. mvdXML

Das mvdXML-Format entspricht der maschinenlesbaren Umsetzung der MVD-

Diagramme. Dabei handelt es sich um ein Textformat, welches mithilfe bestimmter

Software wie z.B. IFC Documentation Generator IFCDOC.EXE erstellt werden kann.

(Chipman, Liebich und Weise 2012)

Das Hauptaugenmerk dieses Formats liegt auf folgenden Punkten:

- Definition von sub schema für MVD, basierend auf das Basisschema von IFC

- Unterstützung automatischer Validation von IFC Daten Sets für

Qualitätssicherung und Software Zertifizierung

- Generierung von Dokumenten für spezielle Model Views und IFC Spezifikation

- Unterstützung von Softwareherstellern für Filterung von IFC Daten basierend

auf Model Views

- Limitierung des IFC-Umfangs auf ein gut definierten Subset, anwendbar für

bestimmte Anwendungen

(T. Chipman 2013) (buildingSMART 2018)


Seite 25


Abbildung 14 mvdXML-Schema (Chipman, Liebich und Weise 2012)

Die Basisstruktur einer Model View Definition beinhaltet Root Konzepte, welche sich

auf eine spezifische IFC Entität also Klasse beziehen und als individuelles testbares

Element angesehen werden können. Jedes Root Konzept beinhaltet mehrere

Konzepte, welche Regeln für allgemeine Unterthemen von Informationen innerhalb der

Hauptwurzel beschreiben. Eine Model View beschreibt somit indirekt bestimmte IFC

Klassen. (Chipman, Liebich und Weise 2012)

Das mvdXML-Format als „only single valid root element“, besteht aus zwei „main sub

elements“, mvd:Templates und mvd:View. Siehe auch darauffolgende Abbildung.

Abbildung 15 Bestandteile mvdXML (buildingSMART 2018)


Seite 26


Mvd:Templates:

Mvd:Templates ist eine Liste von wiederverwendbaren „concept templates“. Dabei

definiert ein mvd:ConceptTemplate eine Baumstruktur, welche einen vom jeweiligen

Anwendungsfall abhängigen Teil des IFC Schemas beschreibt. (buildingSMART 2018)

Abbildung 16 Hauptbestandteile eines mvdXML für ConceptTemplate (buildingSMART 2018)

Diese beinhalten im Wesentlichen Folgendes:

- @applicableSchema (z.B. IFC2x3 or IFC4)

- @applicableEntity

- Description

- Rules (Entity, Attribute)

- SubTemplates

Mvd:ModelView:

Das mvd:ModelView Element beschreibt wie „concept templates“ in einem „view“

verwendet werden. (buildingSMART 2018) Eine visuelle Darstellung dessen ist in

folgender Abbildung zu sehen.


Seite 27


Abbildung 17 Hauptbestandteile eines mvdXML für ModelView (buildingSMART 2018)

Das mvdXML:ModelView beinhalten im Wesentlichen folgendes:

- @applicableSchema (z.B. IFC2x3 or IFC4)

- mvd:BaseView definition (nur wenn add-on)

- mvd:ExchangeRequirements

- mvd:Roots

- mvd:Defnitions

mvdXML Anwendungsfälle

Mithilfe des mvdXML-Formats sind:

• MVD Dokumentation:

Bei einer MVD Dokumentation wird ein Set von miteinander verknüpften

HTML Dateien generiert, dessen Fokus es ist, zu beschreiben, wie ein subset

eines IFC implementiert und verwendet werden muss, um bestimmte

Anforderungen zu erfüllen.

• Spezifizierung von subset Schemas: Es beinhaltet zusätzliche

Einschränkungen, welche die bestimmungsgemäße Nutzung eines subset


Seite 28


Schemas beschreibt, um somit nur entities und attributes zu selektieren, die

auch einen Bestandteil des subset shemas sein sollen.

• Datenfilterung: Filterung von bestimmten Instanzen für je nach

Anwendungsfall spezifische Model View Definitions möglich.

• Datenvalidierung: Überprüfung ob ein Datenpaket alle Bedingungen der

Austauschanforderungen erfüllt. Fehlt eine Datei oder ist es eine falsche

Datei, so misslingt die Validierung.

möglich.

(buildingSMART 2018)

Beispiel: Ausschnitt aus Concept template „Property Sets for Objects and Types”

Abbildung 18 Auszug eines mvdXML Skripts (buildingSMART 2018)


Seite 29


6. Reference View vs. Design Transfer View

Um die einzelnen Model View Definitions genauer zu betrachten und ihre

Eigenschaften herauszufiltern, wird ein einfaches Modell in Autodesk Revit 2017

angelegt. Anschließend wird dieses Modell in unterschiedlichen MVDs exportiert und

deren SPF-Files werden miteinander verglichen. So soll herausgefunden werden, wie

die Anforderungen an verschiedene Austauschszenarien aus Kapitel 5 technisch

umgesetzt werden. Anschließend werden die exportierten IFC-Dateien eingelesen und

auf ihre Auswertbarkeit überprüft.

Wie bereits in Kapitel 4 dargestellt, wird die in Revit 2017 erstellte Wand per IFC-

Schnittstelle exportiert. Um die Unterschiede der MVDs zu verdeutlichen, wurde die

einschalige Stahlbetonwand 25 cm in eine zweischalige Wand mit 12 cm

Wärmedämmung und Türöffnung geändert. Für den Export wurden zwei IFC4 Model

Views gewählt, die Reference View und die Design Transfer View.

Abbildung 19 exportierte Wand in Autodesk Revit

Um die dann wieder importierten IFC-Dateien auf ihre Vollständigkeit zu überprüfen,

wird vom Original-Modell eine Materialliste in Revit erstellt.

Abbildung 20 Wandmaterialliste Original-Gebäudemodell aus Revit 2017


Seite 30


Wie bereits in Kapitel 5.2 erwähnt, dient die Reference View der Übergabe eines

Referenzmodells für Fachplaner mit dem Hauptaugenmerk auf die

Anwendungszwecke der Koordination und modellbasierten Mengenermittlung. Es

werden somit nur die notwendigsten geometrischen Informationen übergeben, welche

für eine Weiterverarbeitung mit BIM-fähiger Software ungeeignet ist.

Die Design Transfer View hingegen dient dem Zweck, ein IFC-Modell zu übergeben,

welches dann in einer BIM-fähigen Software weiterverarbeitet werden kann. Es gilt

also, hochparametrische Eigenschaften zu übergeben.

Beide Model Views unterscheiden sich also hinsichtlich ihrer geometrischen

Verarbeitung. Dies soll nun im Folgenden durch die Skriptanalyse der jeweiligen SPF-

Dateien untermauert werden.

Design Transfer View:

Das SPF-Skript der Design Transfer View ist vergleichbar mit dem Skript, welches in

Kapitel 4.2. genauer analysiert wurde. Im Vergleich dazu wurde jedoch hier das Modell

aufgrund des Schichtaufbaus und der Öffnung erweitert. Wie sich diese

Veränderungen auf das IFC-Datenmodell auswirken, soll im Folgenden gezeigt

werden.

Im nachfolgendem Abschnitt wird das IFC Öffnungselement beschrieben. Ähnlich wie

die Wand selbst wird dessen Geometrie über IfcProductDefinitionShape (#353)

beschrieben. Mit IfcRelVoidsElement (#366) werden Wand und Öffnung in Relation

gebracht.

…

#361= IFCOPENINGELEMENT('106RIB6SDDf9D$gzSWzftY',#42,'Basiswand:STB 25.0 WD 12.0:388674',$,'Opening',#359,#353,$,.OPENING.); #359= IFCLOCALPLACEMENT(#153,#358);

…

#341= IFCCARTESIANPOINT((0.,-5.55111512312578E-17)); #343= IFCAXIS2PLACEMENT2D(#341,#24); #344= IFCRECTANGLEPROFILEDEF(.AREA.,'1010 x 2005',#343,2.005,1.01); #345= IFCCARTESIANPOINT((0.505000000000001,0.,1.0025)); #347= IFCAXIS2PLACEMENT3D(#345,#16,#22); #348= IFCEXTRUDEDAREASOLID(#344,#347,#20,0.369999999999997); #349= IFCSHAPEREPRESENTATION(#101,'Body','SweptSolid',(#348)); #351= IFCCARTESIANPOINT((0.599999999999999,-0.185000000000002,0.));


Seite 31


#353= IFCPRODUCTDEFINITIONSHAPE($,$,(#349)); #356= IFCCARTESIANPOINT((0.599999999999999,-0.185000000000002,0.)); #358= IFCAXIS2PLACEMENT3D(#356,$,$);

…

#366= IFCRELVOIDSELEMENT('1bDPoAPcvCoBS4BKUHLGl1',#42,$,$,#192,#361);

Die Zweischichtigkeit der Wand wird in der reinen Geometriebeschreibung noch nicht

sichtbar. Hier wird die Gesamtdicke von 0.37 m für das Profil, welches entlang der

Polylinie als Sweep die Gesamtform bildet, angegeben (#169).

#152= IFCAXIS2PLACEMENT3D(#6,$,$); #153= IFCLOCALPLACEMENT(#137,#152); #155= IFCCARTESIANPOINT((6.,0.)); #157= IFCPOLYLINE((#10,#155)); #159= IFCSHAPEREPRESENTATION(#99,'Axis','Curve2D',(#157)); #166= IFCCARTESIANPOINT((3.,0.)); #168= IFCAXIS2PLACEMENT2D(#166,#26); #169= IFCRECTANGLEPROFILEDEF(.AREA.,$,#168,6.,0.37); #172= IFCAXIS2PLACEMENT3D(#6,$,$); #173= IFCEXTRUDEDAREASOLID(#169,#172,#20,3.);

…

#183= IFCSHAPEREPRESENTATION(#101,'Body','SweptSolid',(#173)); #186= IFCPRODUCTDEFINITIONSHAPE($,$,(#159,#183)); #192= IFCWALLSTANDARDCASE('106RIB6SDDf9D$gyGWzeTB',#42,'Basiswand:STB 25.0 WD 12.0:388674',$,'Basiswand:STB 25.0 WD 12.0:3919',#153,#186,'388674',.NOTDEFINED.);

Die unterschiedlichen Schichten inklusive ihrer Schichtstärken werden erst durch die

Definition von Material-Layern (#240, #242) festgelegt. Durch

IfcRelAssociatesMaterial wird das Materiallayer-Set der Wand zugeordnet.

…

#240= IFCMATERIALLAYER(#207,0.12,$,$,$,$,$); #242= IFCMATERIALLAYER(#225,0.25,$,$,$,$,$); #243= IFCMATERIALLAYERSET((#240,#242),'Basiswand:STB 25.0 WD 12.0',$); #247= IFCMATERIALLAYERSETUSAGE(#243,.AXIS2.,.NEGATIVE.,0.185,$);

… #324= IFCRELASSOCIATESMATERIAL('2m4Z0EJVb1RAKak_j9FY0i',#42,$,$,(#192),#247);


Seite 32


Um den Datenaustausch, wie er in der Praxis stattfinden würde, abzubilden, wurde die

IFC-Datei wieder in Revit 2017 importiert. Dieser Vorgang verläuft ohne Probleme. Die

geometrische Abbildung stimmt mit dem Original überein, genauso wie Materialien und

Flächen aus der Materialliste. Am eingefügten Modell lässt sich weiter arbeiten.

Abbildung 21 Importierte IFC4 Design Transfer View in Revit 2017

Abbildung 22 Veränderung der Wandlänge der importierten IFC4 Design Transfer View in Revit 2017

Abbildung 23 Materialliste der importierten IFC4 Design Transfer View in Revit 2017


Seite 33


Reference View:

Der Aufbau des SPF-Skriptes der Reference View ist dem der Design Transfer View

sehr ähnlich. Aus diesem Grund werden nachfolgend nur wesentliche Unterschiede

aufgeführt.

Die Beschreibung der Öffnung in der mehrschichtigen Wand wird im Vergleich zur

Design Transfer View gleich gehandhabt. Es wird also auf die Geometriebeschreibung

durch einen Sweep zurückgegriffen.

…

#401= IFCOPENINGELEMENT('106RIB6SDDf9D$gzSWzftY',#42,'Basiswand:STB 25.0 WD 12.0:388674',$,'Opening',#399,#395,$,.OPENING.); #399= IFCLOCALPLACEMENT(#153,#398);

…

#385= IFCCARTESIANPOINT((0.,-5.55111512312578E-17)); #387= IFCAXIS2PLACEMENT2D(#385,#24); #388= IFCRECTANGLEPROFILEDEF(.AREA.,'1010 x 2005',#387,2.005,1.01); #389= IFCCARTESIANPOINT((1.105,-0.185,1.0025)); #391= IFCAXIS2PLACEMENT3D(#389,#16,#22); #392= IFCEXTRUDEDAREASOLID(#388,#391,#20,0.369999999999997); #393= IFCSHAPEREPRESENTATION(#101,'Body','SweptSolid',(#392)); #395= IFCPRODUCTDEFINITIONSHAPE($,$,(#393));

…

#406= IFCRELVOIDSELEMENT('3M3M2dNpz97ee2YHdRZNR7',#42,$,$,#242,#401);

Auch die Materialbeschreibung und somit die Beschreibung des Schichtaufbaus ist

vergleichbar.

#289= IFCMATERIALLAYER(#256,0.12,$,$,$,$,$); #291= IFCMATERIALLAYER(#274,0.25,$,$,$,$,$); #292= IFCMATERIALLAYERSET((#289,#291),'Basiswand:STB 25.0 WD 12.0',$);

…

#371= IFCRELASSOCIATESMATERIAL('0MgictUJfCIRjLTUumffnw',#42,$,$,(#242,#296),#292);


Seite 34


Ein wesentlicher Unterschied von der Reference View zur Design Transfer View liegt

jedoch in der Geometriebeschreibung. Wie im vorhergegangen Text ersichtlich, wird

in der Design Transfer View die Geometrie über einen Sweep beschrieben. In der

Reference View hingegen wird die Geometrie über die Body Tessellation dargestellt

(#233), also eine BRep-Beziehung wie sie im vorangegangen Text beschrieben wurde.

Hierzu wird im ersten Schritt eine Liste mit Punkten aufgeführt (#183), welche

anschließend über IfcTriangulatedFaceSet in Verbindung zueinander gebracht werden

um die Außenflächen des Körpers abzubilden (#201). Jegliche Parametrik geht in

diesem Schritt verloren.

… #183= IFCCARTESIANPOINTLIST3D(((6.,0.185,0.),(6.,-0.185,0.),(1.61,-0.185,0.),(1.61,0.185,0.),(6.,-0.185,3.),(-4.03399441129861E-24,-0.185,3.),(4.03399441129861E-24,-0.185,2.01699720564930E-24),(0.6,-0.185,-4.03399441129861E-24),(0.6,-0.185,2.005),(1.61,-0.185,2.005),(6.,0.185,3.),(1.61,0.185,2.005),(0.6,0.185,2.005),(0.6,0.185,2.01699720564930E-24),(8.06798882259721E-24,0.185,4.03399441129861E-24),(4.03399441129861E-24,0.185,3.))); #201= IFCTRIANGULATEDFACESET(#183,$,$,((2,3,4),(4,1,2),(7,8,9),(6,9,10),(9,6,7),(3,2,10),(10,5,6),(5,10,2),(1,4,12),(11,12,16),(12,11,1),(14,15,13),(13,16,12),(16,13,15),(8,7,15),(15,14,8),(5,2,1),(1,11,5),(6,5,11),(11,16,6),(7,6,16),(16,15,7),(12,9,13),(9,12,10),(4,10,12),(10,4,3),(8,13,9),(13,8,14)),$); #233= IFCSHAPEREPRESENTATION(#101,'Body','Tessellation',(#201)); #236= IFCPRODUCTDEFINITIONSHAPE($,$,(#159,#233)); #242= IFCWALL('106RIB6SDDf9D$gyGWzeTB',#42,'Basiswand:STB 25.0 WD 12.0:388674',$,'Basiswand:STB 25.0 WD 12.0:3919',#153,$,'388674',.NOTDEFINED.);

…

Wie jedoch in #242 bei der Definition von IfcWall zu erkennen ist, wurde das Objekt

nicht mit #236, IfcProductDefinitionShape verbunden. Vergleichend mit dem

Skriptausschnitt aus der Design Transfer View, müsste hier anstatt $ der Verweis auf

die geometrische Abbildung erfolgen.

Um auch hier den Datenaustausch, wie er in der Praxis stattfinden würde, abzubilden,

wurde die IFC-Datei wieder in Revit 2017 importiert. Hier wird dann das oben genannte

Problem deutlich, denn die Wand mit Öffnung wird nicht geometrisch abgebildet.

Außerdem wurden keine Materialien übergeben.


Seite 35


Abbildung 24 Materialliste der importierten IFC4 Reference View in Revit 2017

Dieses Problem ist Autodesk jedoch bekannt und verspricht die Fehlerbehebung in der

Revit-Version 2019. Demzufolge soll ein Export einer Wand ohne Öffnung in der

Reference View ohne Probleme möglich sein. (AutodeskSupport 2018) Um dies zu

überprüfen, wurde die Öffnung aus der Wand entfernt, als IFC4 Reference View

exportiert und anschließend wieder importiert. Wie im Autodesk HilfeCenter

angekündigt, funktioniert dies ohne Probleme. Um den Grund dafür herauszufinden,

wurde wieder ein Blick in das SPF-Dokument geworfen. Hier zeigt sich, dass die

Geometrie ohne Öffnung in der IFC4 Reference View durch einen Sweep beschrieben

wird, und nicht durch eine BRep -Beschreibung.

#183= IFCSHAPEREPRESENTATION(#101,'Body','SweptSolid',(#173));

#186= IFCPRODUCTDEFINITIONSHAPE($,$,(#159,#183));

#192=

IFCWALLSTANDARDCASE('106RIB6SDDf9D$gyGWzeTB',#42,'Basiswand:STB

25.0 WD 12.0:388674',$,'Basiswand:STB 25.0 WD

12.0:3919',#153,#186,'388674',.NOTDEFINED.);

Da das oben beschriebene Problem in der Version Autodesk Revit 2019 behoben

werden soll, erfolgt auch hier Export und Import der Wand mit Türöffnung. Bei der

Analyse des SPF-Dokuments wurde deutlich, dass nun eine Verbindung zwischen

Objektdefinition und geometrischer Abbildung herrscht (#243). Des Weiteren wurde

die Beschreibung der Punkte und deren Kombination zur Flächenbeschreibung

verändert.

...

#187= IFCINDEXEDPOLYGONALFACE((2,3,4,1)); #190= IFCINDEXEDPOLYGONALFACE((6,7,8,9,10,3,2,5)); #192= IFCINDEXEDPOLYGONALFACE((5,2,1,11)); #194= IFCINDEXEDPOLYGONALFACE((4,3,10,12)); #196= IFCINDEXEDPOLYGONALFACE((14,15,16,11,1,4,12,13)); #198= IFCINDEXEDPOLYGONALFACE((8,7,15,14)); #200= IFCINDEXEDPOLYGONALFACE((7,6,16,15)); #202= IFCINDEXEDPOLYGONALFACE((8,14,13,9)); #204= IFCINDEXEDPOLYGONALFACE((12,10,9,13)); #206= IFCINDEXEDPOLYGONALFACE((6,5,11,16)); #208= IFCCARTESIANPOINTLIST3D(((6.,0.185,0.),(6.,-0.185,0.),(1.61,-0.185,0.),(1.61,0.185,0.),(6.,-0.185,3.),(-4.03399441129861E-24,-


Seite 36


0.185,3.),(4.03399441129861E-24,-0.185,2.01699720564930E-24),(0.6,-0.185,-4.03399441129861E-24),(0.6,-0.185,2.005),(1.61,-0.185,2.005),(6.,0.185,3.),(1.61,0.185,2.005),(0.6,0.185,2.005),(0.6,0.185,2.01699720564930E-24),(8.06798882259721E-24,0.185,4.03399441129861E-24),(4.03399441129861E-24,0.185,3.))); #226= IFCPOLYGONALFACESET(#208,.T.,(#187,#190,#192,#194,#196,#198,#200,#202,#204,#206),$); #240= IFCSHAPEREPRESENTATION(#105,'Body','Tessellation',(#226)); #243= IFCPRODUCTDEFINITIONSHAPE($,$,(#163,#240)); #249= IFCWALL('106RIB6SDDf9D$gyGWzeTB',#42,'Basiswand:STB 25.0 WD 12.0:388674',$,'Basiswand:STB 25.0 WD 12.0:3919',#157,#243,'388674',.NOTDEFINED.);

…

Ob nun auch der Import des IFC-Dokuments funktioniert, soll im Folgenden betrachtet

werden.

Abbildung 25 3D-Darstellung der importierten IFC4 Reference View in Revit 2019

Abbildung 26 Materialliste der importieren Reference View in Revit 2019

Aus Abbildung 25 und Abbildung 26 ist ersichtlich, dass auch in dieser Version der

Import einer Wand mit Öffnung nicht erfolgen konnte, obwohl deutliche Veränderungen

an der Implementierung vorgenommen wurden.


Seite 37


7. Zusammenfassung

Mit der Einführung in die Arbeitsmethode BIM wurde im Rahmen dieser Arbeit deutlich,

wie wichtig hier ein strukturiertes Prozessmanagement ist. Da im Bauwesen eine

Vielzahl von Fachdisziplinen verschiedene Teilprozesse erfüllen, muss geklärt und

festgehalten werden, wer wann was und im welchem Umfang liefert, um den

Gesamtprozess des digitalen Gebäudemodells auszuführen. Die Besonderheit der

offenen Schnittstelle IFC wurde mit der Einführung in dessen Datenmodell deutlich.

Um ein auf den Anwendungszweck zugeschnittenes Teilmodell aus dem

Gesamtmodell abzuleiten wurde von Building SMART die IDM-/ MVD-Methode

entwickelt.

Das Information Delivery Manual beinhaltet somit die formale Beschreibung von

Prozessen und deren Abläufen und legt mit den Exchange Requirements fest, welche

Anforderungen an die auszutauschenden Daten zwischen den Prozessen zu stellen

sind. Diese formale Planung wird in sogenannten „process maps“ oder

Prozessdiagrammen grafisch abgebildet.

Die softwaretechnische Unterstützung der in den Prozessdiagrammen entwickelten

Prozessabläufe werden mit den Model View Definitions auf Basis von IFC umgesetzt.

Hier werden die im Pflichtenheft der ER erstellten Informationen technisch umgesetzt,

um somit einen anwendungsspezifischen Austausch eines Teilmodells vom gesamten

Gebäudemodell zu ermöglichen.

Wie aus den Vergleichen der IFC4 Model Views ersichtlich ist, unterscheidet sich die

technische Implementierung der verschiedenen MVDs je nach Anwendungszweck. So

ist die Design Transfer View geeignet, um am Modell weiter zu arbeiten, da hier die

Parametrik im Modell mit übergeben wird. In der Reference View hingegen, die mit

dem Zweck implementiert wurde, Mengenermittlungen zu generieren,

Kollisionsprüfungen auszuführen oder Planungen zusammenzuführen, wird die

Parametrik nicht mit übergeben und somit ist eine Weiterbearbeitung auch nicht mehr

möglich. Durch die genaue Beschreibung der einzelnen Oberflächen bildet dieses

Modell jedoch die Geometrien genauer ab.

Was aus den Untersuchungen jedoch auch deutlich wurde, ist, dass viele Software-

Anbieter die Schnittstelle IFC 4, insbesondere die Reference View, noch nicht

ausreichend implementiert haben. Gegenstand der Untersuchung war hier

hauptsächlich Autodesk Revit. So gibt es noch immer Probleme beim Import von

Wänden mit Öffnungen. Hier bedarf es noch an weiterer Entwicklung, um diese

Technik einwandfrei einsetzen zu können.


Seite 38


A. Abkürzungsverzeichnis

BIM Building Information Model(ing)

BPMN Business Process Management Notation

BREP Boundary Representation

CAD Computer Aided Design

ER Exchange Requirements

IDM Information Delivery Manual

IFC Industry Foundation Classes

MVD Model View Definition

NBIMS National BIM Standard

SPF Step Physical File

STEP Standard for the Exchange of Product model data


Seite 39


B. Literaturverzeichnis

Autodesk. „Revit IFC Handbuch.“ Die Nutzung von IFC in der Praxis. Februar 2018.

https://www.autodesk.de/campaigns/interoperability/ifc-handbuch.

AutodeskSupport. Revit export to Ifc. 12. April 2018.

https://knowledge.autodesk.com/support/revit-

products/troubleshooting/caas/sfdcarticles/sfdcarticles/IFC4-Reference-View-

from-Revit-missing-walls.html (Zugriff am 1. Juli 2018).

BMVI. Bundesministerium für Verkehr und digitale Infrastruktur. 15. 12 2015.

https://www.bmvi.de/goto?id=230208 (Zugriff am 28. Juni 2018).

Borrmann, André, Markus König, Christian Koch, und Jakob Beetz. Building

Information Modeling. Wiesbaden: Springer Vieweg, 2015.

buildingSMART. buildingSMART. 2018. http://www.buildingsmart.org/ (Zugriff am 02.

Juni 2018).

—. IFC 4 Official Release. 2013. http://www.buildingsmart-tech.org/ifc/IFC4/final/html/

(Zugriff am 30. Juni 2018).

Chipman, Tim, Thomas Liebich, und Matthias Weise. „mvdXML.“ buildingSMART. 14.

Mai 2012. (Zugriff am 15. Juni 2018).

Chipman, Tom. „Model View Definitions for Electrical and Plumbing Systems

Information Exchange.“ 10. Januar 2013.

https://portal.nibs.org/files/wl/?id=f7i9lJ8G3wHyuvZQf97L7NanfgPQBC9y


Eastman, C. M., Y.-S. Jeong, R. Sacks, und I. Kaner. „Exchange Model and

Exchange Object Concepts for Implementation of National BIM Standards.“

Journal of Computing in Civil Engineering, Vol. 24, No. 1, Januar/Februar

2010: 25-34.

Funk, B., J. Marx Gomez, P. Niemeyer, und F. Teuteberg.

„Geschäftsprozessmanagement und Prozessmodellierung.“ In

Geschäftprozessintegration mit SAP, 7-53. Springer Vieweg, 2010.

Graphisoft. Modelldarstellungs-Definitionen. kein Datum.

https://helpcenter.graphisoft.de/handbuecher/handbucher-zu-archicad-20/hilfe-

zu-archicad-


Seite 40


20/interoperabilitat/dateihandhabung_und_austausch/arbeiten_mit_ifc/modelld

arstellungs-definitionen/ (Zugriff am 22. Juni 2018).

Hölzlwimmer, Verena. „Analyse des Datenaustausches zwischen dem

Modellierungs- und AVA-Prozess auf Basis von Building Information

Modeling.“ Bachelorarbeit, München, 2015.

Liebich, Thomas. IFC 2x Edition 3. 2009.

NBIMS. National BIM Standard. 2018. https://www.nationalbimstandard.org/ (Zugriff

am 02. Juni 2018).

Niedermaier, Anke, und Robert Bäck. „Allplan_BIM_Kompendium.“ Dezember 2014.

http://www.allplan.com/de/links/bim-leitfaden.html (Zugriff am 22. April 2015).

Wix, Jeff. „IDM_ExchangeRequirements.“ buildingSMART. 26. Juni 2015.

http://iug.buildingsmart.org/idms/training-

material/IDM_ExchangeRequirements_20110703.pptx/view (Zugriff am 25.

Juni 2018).

—. „Information Delivery Manual.“ buildingSMART. 01. Juli 2011.

http://iug.buildingsmart.org/idms/training-material/IDM_Generally_0.pptx/view


—. „Process Mapping.“ buildingSMART. 27. November 2015.

http://iug.buildingsmart.org/idms/training-

material/IDM_ProcessMapping_20110703.pptx/view (Zugriff am 22. Juni

2018).


Seite 41


C. Abbildungsverzeichnis

Abbildung 1 IDM / MVD-Methode (eigene Darstellung) .............................................. 5

Abbildung 2 Übersicht IDM und seine Bestandteile (Wix, Information Delivery Manual

2011) .......................................................................................................................... 6

Abbildung 3 Überblick des NBIMS Entwicklungsprozesses (NBIMS 2018)................. 7

Abbildung 4 Prozessdiagramm nach Energy-Analysis IDMl (Borrmann, et al. 2015) .. 8

Abbildung 5 Ausschnitt aus IDM BIM Based Energy Analysis Modell (Borrmann, et al.

2015) ........................................................................................................................ 10

Abbildung 6 Beispiel Stahlbetonwand ...................................................................... 11

Abbildung 7 Layer-Struktur des IFC-Modells (buildingSMART, IFC 4 Official Release

2013) ........................................................................................................................ 13

Abbildung 8 grafische Darstellung IfcSpatialProjectStructure (Autodesk 2018) ........ 14

Abbildung 9 IFC-Datenmodell .................................................................................. 15

Abbildung 10 Pset_WallCommon (Autodesk 2018) .................................................. 16

Abbildung 11 IFC-Exportklassen Revit ..................................................................... 17

Abbildung 12 MVD-Diagramm (Borrmann, et al. 2015)............................................. 22

Abbildung 13 vordefinierte Model Views beim IFC-Export aus Revit ........................ 24

Abbildung 14 mvdXML-Schema (Chipman, Liebich und Weise 2012) ...................... 25

Abbildung 15 Bestandteile mvdXML (buildingSMART 2018) .................................... 25

Abbildung 16 Hauptbestandteile eines mvdXML für ConceptTemplate

(buildingSMART 2018) ............................................................................................. 26

Abbildung 17 Hauptbestandteile eines mvdXML für ModelView (buildingSMART

2018) ........................................................................................................................ 27

Abbildung 18 Auszug eines mvdXML Skripts (buildingSMART 2018) ....................... 28

Abbildung 19 exportierte Wand in Autodesk Revit .................................................... 29


Seite 42


Abbildung 20 Wandmaterialliste Original-Gebäudemodell aus Revit 2017 ............... 29

Abbildung 21 Importierte IFC4 Design Transfer View in Revit 2017 ......................... 32

Abbildung 22 Veränderung der Wandlänge der importierten IFC4 Design Transfer

View in Revit 2017 ................................................................................................... 32

Abbildung 23 Materialliste der importierten IFC4 Design Transfer View in Revit 2017

................................................................................................................................. 32

Abbildung 24 Materialliste der importierten IFC4 Reference View in Revit 2017 ...... 35

Abbildung 25 3D-Darstellung der importierten IFC4 Reference View in Revit 2019 .. 36

Abbildung 26 Materialliste der importieren Reference View in Revit 2019 ................ 36

the information delivery manual and model view definition · automatisierung von abläufen. um die...

Documents