kommunikation in bim-projekten auf grundlage von *.bcf-daten · advanced topics in building...

Ingenieurfakultat Bau Geo Umwelt

Lehrstuhl fur computergestutzte Modellierung und Simulation

Prof. Dr.-Ing. Andre Borrmann

Fakultat fur Architektur

Lehrstuhl fur Architekturinformatik

Prof. Dr.-Ing. Frank Petzold

Kommunikation in BIM-Projekten auf

Grundlage von *.bcf-Daten

15. Juli 2018

Report

Advanced Topics in Building Information Modeling

Sebastian Esser

Advanced Topics in Building Information ModelingKommunikation in BIM-Projekten auf Grundlage von *.bcf-Daten

Inhaltsverzeichnis

1 Motivation fur neuartige Kommunikationsmethoden im Planungsprozess 4

1.1 BIM als Werkzeug in Planung und Betrieb . . . . . . . . . . . . . . . . . . . . 4

1.2 Inhalte dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Das Building Collaboration Format 6

2.1 Idee und Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1 Projektkommunikation innerhalb eines Bauwerkmodells . . . . . . . . 6

2.1.2 Verwendung des BCF-Formates zur Projektkommunikation . . . . . . 7

2.2 Vorgesehener Ablauf/Kommunikationsstruktur . . . . . . . . . . . . . . . . . 8

2.3 Historie und Versionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4 Technische Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.5 Umgang mit Aktualisierungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.5.1 Hinzufugen eines neuen Kommentars . . . . . . . . . . . . . . . . . . . 12

2.5.2 Aktualisierung des Attributs ’Status’ . . . . . . . . . . . . . . . . . . . 13

2.5.3 Festlegung von Wertebereichen . . . . . . . . . . . . . . . . . . . . . . 14

3 Erstellung und Weitergabe von BCF-Dateien 16

3.1 BCF-Dateien als Ergebnis von Modellprufungen . . . . . . . . . . . . . . . . . 16

3.2 Online Plattformen zum Austausch von IFC- und BCF-Dateien . . . . . . . . 18

3.2.1 Plugin-Losungen fur BIM-Editor-Programme . . . . . . . . . . . . . . 19

3.3 Lokale Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Lehrstuhl fur computergestutzte Modellierung und SimulationLehrstuhl fur Architekturinformatik

Seite 1

4 Problemstellungen und Ausblick 23


Abkurzungsverzeichnis

BIM Building Information Modeling

XML Extensible Markup Language

XSD XML Schema Definition

IFC Industry Foundation Classes

BCF BIM Collaboration Format

API Application Programming Interface

bSi buildingSMART international

GUID Globally Unique Identifier

CDE Common Data Environment


Seite 3


Kapitel 1

Motivation fur neuartige

Kommunikationsmethoden im

Planungsprozess

1.1 BIM als Werkzeug in Planung und Betrieb

Die fortschreitende Digitalisierung halt wie in anderen Industriezweigen auch im Baugewerbe

zunehmend Einzug. Als zentraler Begriff hat sich dabei das Building Information Mode-

ling (BIM) im Sprachgebrauch etabliert. Fur BIM existieren zahlreiche Definitionen, die ein-

zelne Aspekte unterschiedlich stark gewichten - vielen gemeinsam sind aber die Grundanfor-

derungen von gesteigerter Datenkonsistenz und dem Datenaustausch zwischen verschiedenen

Planern.

BIM kann dabei nicht die Planungstatigkeit eines Ingenieurs an sich ersetzen, sondern

lediglich neue Arbeitsweisen und Werkzeuge eroffnen, um wiederkehrende und standardisier-

bare Problemstellungen schneller losen zu konnen. Welches Werkzeug fur einen bestimmten

Anwendungsfall das am besten Geeignete ist, kann in den meisten Fallen nicht pauschal

beantwortet werden und hangt von vielfaltigen Faktoren ab.

Zusatzlich zu der Entwicklung von immer machtigeren Programmen, die sich von zeich-

nungsbasierten Strukturen losen und immer mehr objektorientierte Ansatze beinhalten,

mussen sich mit der zunehmenden Anwendung von BIM-Methoden auch die Kommunika-

tionsprozesse zwischen verschiedenen Projektbeteiligten weiterentwickeln. Wie auch bei der

Wahl des richtigen Werkzeugs gilt der Grundsatz, dass die fachspezifische Kommunikation

zwischen den Projektbeteiligten nicht vollkommen automatisiert ablaufen kann (und soll) -


Seite 4


dennoch lassen sich diverse Strukturen innerhalb der Kommunikation in Bauprojekten erken-

nen, die durch den Einsatz eines Datenschemas standardisiert werden konnen.

Dieses Ziel verfolgt das BIM Collaboration Format (BCF). Dabei handelt es sich um ein

Hersteller-neutrales Format, welches den Dialog zwischen verschiedenen Projektbeteiligten

direkt in einem BIM-Modell ermoglicht. Entwickelt wird BCFvon buildingSMART interna-

tional (bSi). Diese Organisation versteht sich dabei als treibende Kraft, die die Erschaffung

und Erweiterung von offenen, internationaler Standardisierungen im Bausektor vorantreibt

(BuildingSMART, 2018a). Zu den gehosteten Formaten gehoren neben dem BCF-Format

auch das Austauschformat Industry Foundation Classes (IFC), welches zur Weitergabe digi-

taler Bauwerksmodelle genutzt wird.

1.2 Inhalte dieser Arbeit

Folgender Bericht behandelt zuerst die technischen Grundlagen des BCF-Dateiformates und

gibt eine Ubersicht uber die zugrundeliegende XML-Struktur. Darauf aufbauend werden im

Rahmen einer kleinen Marktstudie Programme aufgezeigt, die derzeit die Projektkommuni-

kation auf der Grundlage von BCF unterstutzen. Abschließend werden Problemstellungen

und mogliche sinnvolle Erweiterungen erortert, die mit der aktuellen Version 2.1 noch nicht

abgedeckt sind. Zudem werden mogliche zusatzliche Anforderungen benannt, die mit dem

Einsatz von BIM-Methoden im Infrastrukturbereich entstehen konnen.


Seite 5


Kapitel 2

Das Building Collaboration Format

2.1 Idee und Funktionen

Die Abwicklung von Bauprojekten erfordert neben dem technischen Know-How uber kon-

struktive Aspekte auch ein hohes Maß an interdisziplinarer Zusammenarbeit. Beispielhaft

seien hier die Gewerke der Architektur, der Tragwerksplanung, der Haus- und Klimatechnik,

des Grunanlagenplaners und vielen weiteren Akteuren genannt, die im Verlauf von Hoch-

bauprojekten Planungsleistungen erbringen und mit anderen Beteiligten in Kontakt treten.

Dabei gibt es in nahezu jedem Projekt Aufgaben, die es in der Zusammenarbeit verschie-

denster Fachdisziplinen zu losen gilt (Schwerdtner, 2006).

Heutzutage erfolgt die Kommunikation in einem Bauprojekt haufig auf Basis von Email-

Verkehr und zahlreichen Tabellen, welche die Verantwortlichkeiten und Aufgaben wahrend

des Planungs- und Bauprozesses erfassen. Diese Herangehensweise erfordert das standige Ver-

senden aktualisierter Dokumente an alle Beteiligten und fuhrt haufig zu Inkonsistenzen. Mit

dem zunehmenden Einsatz von zentralen Projektspeichern, die dem Konzept des Common

Data Environment (CDE) zuzuordnen sind, findet der Austausch der Tabellen zum Teil uber

diese Plattformen statt, Probleme bei der Aktualisierung treten dennoch haufig auf.

2.1.1 Projektkommunikation innerhalb eines Bauwerkmodells

Eine mogliche Losung, die der beschriebenen fehleranfalligen und zeitaufwendigen Kommu-

nikation uber Email und Tabellen entgegenwirken konnte, ist die Verwendung bestimm-

ter Speicherslots innerhalb des IFC-Formates. Besonders fur die Weitergabe von digita-

len Gebaudemodellen ist dieses Datenformat bereits sehr ausgereift und wird von zahlrei-

chen Programmen unterstutzt. Neben zahlreiche Produkten, die IFC-Dateien exportieren

und importieren konnen, gibt es eine Vielzahl an Programmen, die IFC-Daten fur weiterge-


Seite 6


hende Analysen und Planungsgrundlagen verwenden konnen und nutzerfreundliche Viewer-

Funktionalitaten zur Verfugung stellen. Mit der Veroffentlichungen der Versionen IFC 4 sowie

IFC 4.1 wurden Objekte in die Klassenstruktur hinzugefugt, die die Georeferenzierung von

Objekten in einem globalen Koordinatensystemen ermoglichen und die Grundlage fur die

Abbildung von Verkehrswegen und den dafur notwendigen Objekten legen. In Planung sind

derzeit die Erweiterungen IfcBridge, IfcRoad sowie IfcRail, die weitere Klassen fur Speiche-

rung von infrastruktur-spezifischen Elementen und Eigenschaften ermoglichen werden (Mar-

kic et al., 2018).

IFC ist ein hierarchisches Format, welches einen enormen Umfang an vordefinierten At-

tributen und Beziehungen zwischen einzelnen Bauteilen oder Eigenschaften erfassen kann.

Daher ware es naheliegend, die bereits definierten Attribute in der IFC-Struktur fur den Dia-

log zwischen den Planern zu verwenden. Dies hatte den Vorteil, dass Probleme und Hinweise

direkt an ein Bauteil angehangt werden konnen. Die IFC-Klassen IfcOwnerHistory, IfcAppro-

val und die Definition von eigenen IfcPropertySets mit ihren Key-Value-Beziehungen seien

an dieser Stelle beispielhaft genannt, die die Belange des Informationsaustausches zwischen

verschiedenen Planern abbilden konnten, ohne ein Zusatzformat zu verwenden (van Berlo &

Krijnen, 2014).

Dagegen sprechen allerdings gleich mehrere Grunde. Die direkte Speicherung von Aufga-

ben und Problemen in einem Bauwerksmodell wurde bedeuten, dass jeder Projektbeteilig-

te uber eine Softwareumgebung mit Import- und Exportfunktion fur IFC-Dateien verfugen

musste, um uberhaupt an der Kommunikation teilnehmen zu konnen. Dies ist besonders bei

Auftraggebern nicht immer der Fall, da hier haufig nur fertige Modelle betrachtet werden

sollen und die Bearbeitung der Modelldaten nicht angestrebt wird (oder auch aus recht-

lichen Grunden gar nicht vorgesehen ist). Daruber hinaus musste mit jeder Antwort oder

zusatzlicher Information eine neue IFC-Datei erzeugt und verteilt werden. Dies wurde dazu

fuhren, dass selbst fur eine Antwort, die aus wenigen Worten besteht, enorme Datenmengen

bewegt werden mussen, die in keinem Verhaltnis zu dem eigentlichen Ziel der Kommunikation

stehen. Zahlreiche Programme bieten außerdem nur Betrachtungsfunktionen einer IFC-Datei

an und sind nicht fur die Bearbeitung eines Modells ausgelegt. Zuletzt sei darauf hingewiesen,

dass die Erstellung und Befullung von benutzerdefinierten PropertySets von der gewahlten

Modellierungsumgebung abhangt und dafur fortgeschrittene Kenntnisse notwendig sind, die

nicht von allen Beteiligten erwartet werden konnen.

2.1.2 Verwendung des BCF-Formates zur Projektkommunikation

All diese Grunde haben dazu gefuhrt, dass das BCF entwickelt und eingefuhrt wurde. Die-

se Datenstruktur ermoglicht den gegenseitigen Austausch von Aufgaben, Fehlern und all-

gemeinen Informationen zwischen den Projektbeteiligten direkt an einem 3D-Modell und


Seite 7


ist gleichzeitig leicht zu handhaben. Als Grundlage dient hierbei eine IFC-Datei, die das

digitale Modell eines Bauwerks beinhaltet und den Austausch zwischen den Planern di-

rekt in einer dreidimensionalen Umgebung ermoglicht. In der BCF-Datei werden neben den

Kommunikations-Informationen auch die Objekt-Identitaten der betroffenen Bauteile gespei-

chert (im Ifc-Schema als GlobalId benannt). Der Aufbau einer BCF-Datei wird in Kapitel 2.4

beleuchtet.

Wie bereits dargestellt, hat die Entkoppelung der Kommunikation von dem reinen Bau-

werksmodell mehrere Vorteile:

- Kommunikationsdaten konnen unabhangig vom IFC-Modell aktualisiert werden.

- Aufgrund der kleinen Datenmengen konnen sowohl serverbasierte Systeme als auch die

Verteilung der BCF-Dateien via Email sinnvoll eingesetzt werden.

- Zur Teilnahme an der Kommunikation reichen Programme mit reinen Viewer-Funktionen

aus, die BCF-Dateien in Verbindung mit den zugrundeliegenden IFC-Dateien darstellen

konnen. Eine Verwaltung der BCF-Daten ist allerdings auch ohne IFC-Modell moglich.

- Das Datenschema ist so aufgebaut, dass es unabhangig von dem Grad der Modell-

Genauigkeit einsetzbar ist. Somit konnen BCF-Daten sowohl fur den ersten architekto-

nischen Vorentwurf als auch fur den fachspezifischen Dialog zwischen den Planern eines

Gewerkes eingesetzt werden, die an einem hoch-detaillierten Modell arbeiten.

- Die Verwendung des Schemas erfolgt zumeist uber benutzerfreundliche Eingabemasken,

dennoch sind die Inhalte der BCF-Dateien menschenlesbar und leicht nachzuvollziehen.

Das BIM Collaboration Format (BCF) wurde ursprunglich von Solibri und Tekla entwi-

ckelt, wird aber mittlerweile auch von vielen anderen Herstellern unterstutzt und ist durch

buildingSMART international als internationaler Standard etabliert worden (Stangeland,

2011). Ein umfangreicher Uberblick uber Anwendungen und Hersteller, die BCF derzeit un-

terstutzen, findet sich in Kapitel 3.

2.2 Vorgesehener Ablauf/Kommunikationsstruktur

Ein Blick auf derzeitige BIM-Planungsprojekte zeigt, dass ein Gesamtmodell meistens aus

mehreren Teilmodellen zusammengesetzt wird, welche von verschiedenen Fachplanern erstellt

werden. Zum Planen eines Teilmodells werden haufig andere Teilmodelle als Planungsgrund-

lage in das Modellierungsprogramm importiert. Stellt der Planer nun fest, dass es einen

Widerspruch zwischen dem eigenen Teilmodell und dem Modell eines anderen Planers gibt,

sollte er diesen Missstand kommunizieren konnen. Fur die Beseitigung der Kollision ist in


Seite 8


den allermeisten Fallen der Ersteller des problemverursachenden Bauteils verantwortlich, der

in seiner eigenen Modellierumgebung den Konflikt behebt (Stangeland, 2011). Eine Auffor-

derung zur Fehlerbehebung kann entweder handisch definiert werden oder das Ergebnis einer

Modellprufung sein. Bekannte Anwendungen zur Modellprufung sind unter anderem Solibri

Model Checker, Tekla BIMSight und Autodesk Navisworks. All diese Aspekte konnen uber

das BIM Collaboration Format abgewickelt werden.

2.3 Historie und Versionen

Die erste BCF-Version wurde 2010 von den Softwareherstellern Tekla und Solibri angestoßen

und wird als bcfXML v1 bezeichnet. Im Oktober 2014 folgte die Veroffentlichung der Version

bcfXML v2, die durch eine bSi Arbeitsgruppe erarbeitet wurde. Dabei wurde neben der Er-

weiterung des XML-Schemas auch ein Application Programming Interface (API) eingefuhrt,

das einen standardisierten, serverbasierten Austausch von BCF-Daten ermoglicht. Die derzeit

aktuellen Versionen der XML-Definition bcfXML 2.1 sowie der ServerAPI bcfAPI 2.1 wur-

den im Marz 2017 veroffentlicht. Beide Implementationen konnen uber den Repository-Dienst

GitHub bezogen werden.

Das erklarte Ziel von BCF ist der Transport von Mitteilungen und Aufgaben zwischen

verschiedenen BIM-Anwendungen fur alle Gewerke bei gleichzeitig geringem Speicherbedarf

(BIMcollab, BIMcollab). Fur diese Idee eignet sich besonders eine textbasierte Speicherstruk-

tur, die im folgenden Kapitel naher beleuchtet wird.

2.4 Technische Grundlagen

Bei BCF handelt es sich um ein XML-basiertes Format. Die Extensible Markup Langua-

ge (XML) ist eine textbasierte Moglichkeit, mit der Informationen schnell zwischen verschie-

denen Anwendungen ausgetauscht werden konnen. Die Form, in welcher die Daten in einem

XML-Dokument gelistet sind, wird typischerweise in der XML Schema Definition (XSD) er-

sichtlich, die als separate Datei existiert (Schild & Mochol, 2007) (Hudeczek, 2017). In den

XSD-Dokumenten konnen unter anderem der Datentyp fur das jeweilige Attribut und Kar-

dinalitaten zwischen verschiedenen Elementen festgelegt werden, die beschreiben, wie oft ein

Kind-Element auftreten kann oder muss.

Eine Ansammlung von verschiedenen Hinweisen und Aufgaben wird als gezippter Contai-

ner weitergegeben, welcher die Dateiendung *.bcfzip aufweist. Im gezippten Ordner befinden

sich weitere Mappen, die die einzelnen Themen darstellen. Jede Mappe ist mit dem Globally

Unique Identifier (GUID) des entsprechenden Topics versehen und enthalt die zugehorigen

XML-Dokumente.


Seite 9


Abbildung 2.1: Ordnerstruktur eines BCFzip-Verzeichnisses

Ein Thema gliedert sich in 4 Hauptfelder auf, die mit Hilfe des XSD-Schemas leicht visua-

lisierbar sind. Fur die folgende Abbildung wurde das Online-Tool visualxsd.com verwendet.

Die zuvor angesprochenen Kardinalitaten werden als kleine Ziffern unter dem jeweiligen

Element dargestellt. So ist zum Beispiel festgelegt, dass eine markup-Datei exakt ein Topic-

Element enthalt, aber mehrere Kommentare moglich sind.

Abbildung 2.2: Hauptelemente einer Topic-XML-Datei


Seite 10


Die bisher vorgestellten Elemente konnen auch leicht in der XML-Datei erkannt werden:

Grundstruktur einer *.bcf-Datei

1 <?xml v e r s i on =”1.0” encoding=”utf−8”?>

2 <Markup xmlns : xsd=”http ://www. w3 . org /2001/XMLSchema”

3 xmlns : x s i=”http ://www. w3 . org /2001/XMLSchema−i n s t anc e”>

4 <Header>

5 <F i l e I f c P r o j e c t =”116lQLr5PBI8G7wzUTCBZJ”>

6 <Filename>

7 C:\ Users \ s e s s e \Desktop\BuI EK Ersatzmodel l Vers ion 2 . i f c

8 </Filename>

9 <Date> 2018−06−03T07 : 41 : 52 . 4202556Z </Date>

10 </Fi l e>

11 </Header>

12 <Topic Guid=”0c34ca7d−419d−4291−9422−9461 d14fe87b”>

13 <ReferenceLink>

14 p r o j e c t : // p r o j e c t s /807068b4−fad5−48bc−8164−91610 fd8a3 f6

15 </ReferenceLink>

16 <Tit l e>Kommentar</Ti t l e>

17 </Topic>

18 <Comment Guid=”0c34ca7d−419d−4291−9422−9461 d14fe87b”>

19 <VerbalStatus />

20 <Status> Unknown </Status>

21 <Date> 2018−06−03T08 : 53 : 11 . 6549843Z</Date>

22 <Author>Esser Sebast ian </Author>

23 <Comment>

24 Ein w e i t e r e r Kommentar

25 </Comment>

26 <Topic Guid=”0c34ca7d−419d−4291−9422−9461 d14fe87b ” />

27 </Comment>

28 </Markup>

In den ersten Zeilen (im Beispiel Zeilen 4 bis 11) werden Informationen angegeben, auf

welches IFC-Modell sich die BCF-Datei bezieht und wann die BCF-Datei erzeugt wurde. In

den Zeilen 12 bis 17 befinden sich Informationen, die das dargestellte BCF-Thema eindeutig

wiederfinden lassen. Daran schließen sich die eigentlichen Kommunikations-Informationen

an, die im Beispiel in den Zeilen 18 bis 27 zu finden sind. Aufgrund der im XSD-Schema

festgelegten Kardinalitaten konnen in diesem Block auch Antworten und weitere Kommentare

zu diesem Topic gespeichert werden (Eric van der Vlist, 2001).

Informationen uber die Ansicht der betroffenen Bauteile werden in einer separaten XML-

Datei erfasst, die die Endung *.bcfv aufweist. Darin werden die betroffenen Komponenten

mithilfe ihrer IfcGuid erfasst sowie die Kameraperspektive als dreidimensionaler Vektor ge-

speichert. Zusatzlich wird jedem Thema eine Bilddatei beigefugt, in der die aktuelle Ansicht


Seite 11


als Screenshot bereitgestellt wird. Diese dient lediglich der Voransicht und sollte nicht als

umfassende Orientierung im Modell herangezogen werden, da die Bilddatei in sehr niedriger

Auflosung transportiert wird. Zum Verstandnis des Problems ist daher die Kameraperspek-

tive sowie die Verortung im zugrundeliegenden IFC-Modell von großer Bedeutung.

Im obenstehenden Beispiel fallt auf, dass das IFC-Modell uber einen lokalen Pfad ver-

knupft wurde. Dies ist fur ein allgemeines Datenaustauschformat kritisch zu sehen, dennoch

funktioniert das Importieren und die Darstellung der BCF-Datei sowie des Modells in ande-

ren Plattformen, da die Referenzierung auf die IFC-Datei uber eindeutige Attribute erfolgen

kann (im Beispiel das Attribut IfcProject).

Der Einsatz von XML-basierten Datenaustausch ist besonders dann zu empfehlen, wenn

die Informationen von vielen verschiedenen Plattformen und Editoren unterstutzt werden

sollen und die Daten gleichzeitig einer einfachen Struktur folgen. Die Vielfalt verschiede-

ner Programme, die das BCF-Format mittlerweile unterstutzen, wird im folgenden Kapi-

tel ersichtlich. Auch die Integration von BCF-Dateien in CDE-Plattformen ist mit einem

uberschaubarem Programmieraufwand zu bewaltigen und wird bereits in der Praxis einge-

setzt.

2.5 Umgang mit Aktualisierungen

Der große Vorteil im Einsatz von BCF in der Projektkommunikation liegt in der konsistenten

Erfassung neuer Informationen, die in ein bestehendes Thema eingegliedert werden. Dabei

erfolgen vorrangig zwei Operationen, namlich das Einfugen neuer Blocke sowie die Aktualisie-

rung bestehender Informationen. In den nachsten Beispielen werden zwei Falle analysiert, in

denen zum Einem neue Informationen hinzugefugt werden und zum Anderen ein bestehender

Parameter aktualisiert wird.

2.5.1 Hinzufugen eines neuen Kommentars

Wie zuvor beschrieben kann mithilfe eines XSD-Schemas vorgegeben werden, wie oft ein

bestimmtes Element in einer XML-Datei enthalten sein darf. Ein Beispiel fur ein Element,

welches haufiger als einmal auftreten kann, ist der Kommentar. Gibt es einen neuen Hinweis

oder antwortet ein Bearbeiter auf ein bereits angelegtes Problem, wird diese neue Information

als weiterer comment in die XML-Datei angefugt.


Seite 12


2.5.2 Aktualisierung des Attributs ’Status’

Im Verlauf der Planung und Bearbeitung eines benannten Problems durchlauft dieses Thema

in der Regel verschiedene Zustande. Zur Speicherung dieser Information stellt das Topic-

Element die Kindelemente TopicType sowie TopicStatus zur Verfugung, deren Werte bei der

Aktualisierung in der betreffenden BCF-Datei uberschrieben werden.

XML-Code VOR der Aktualisierung des TopicStatuses

1 <?xml v e r s i on =”1.0” encoding=”UTF−8” standa lone=”yes”?>

2 <Markup xmlns : x s i=”http ://www. w3 . org /2001/XMLSchema−i n s t anc e ” x s i :

noNamespaceSchemaLocation=”markup . xsd”>

3 <Header>

4 [ . . . ]

5 </Header>

6

7 <Topic

8 Guid=”ca222989−504c−464d−a303−053 c8 f200 fbd ”

9 TopicType=”Error ”

10 TopicStatus=”Offen”>

11 [ . . . ]

12 </Topic>

13

14 <Viewpoints Guid=”76 fe0eab −685d−455e−859c−8f34ec29437 f”>

15 [ . . . ]

16 </Viewpoints>

17 </Markup>

XML-Code NACH der Aktualisierung des TopicStatuses

1 <?xml v e r s i on =”1.0” encoding=”UTF−8” standa lone=”yes”?>

2 <Markup xmlns : x s i=”http ://www. w3 . org /2001/XMLSchema−i n s t anc e ” x s i :

noNamespaceSchemaLocation=”markup . xsd”>

3 <Header>

4 [ . . . ]

5 </Header>

6

7 <Topic

8 Guid=”ca222989−504c−464d−a303−053 c8 f200 fbd ”

9 TopicType=”Error ”

10 TopicStatus=”Geschlossen”> <!−− E d i t i e r t e r Attr ibutwert −−>11 [ . . . ]

12 </Topic>

13

14 <Viewpoints Guid=”76 fe0eab −685d−455e−859c−8f34ec29437 f”>

15 [ . . . ]


Seite 13


16 </Viewpoints>

17 </Markup>

Durch das Uberschreiben bestehender Werte ist es nicht moglich, eine Historie uber den

Bearbeitungsverlauf zu fuhren. Das Topic-Element enthalt zwar auch die Kind-Elemente Mo-

difiedDate und ModifiedAuthor, allerdings gibt es keine Beziehung zwischen diesen Feldern

und den tatsachlich veranderten Werten. Sofern also eine Dokumentation der Veranderungen

in Elementen erfolgen soll, die nicht eingefugt, sondern aktualisiert werden, sind zusatzliche

Funktionalitaten auf Seiten der verwendeten Software oder der Projektplattformen notwen-

dig.

2.5.3 Festlegung von Wertebereichen

In einem XSD-Schema wird neben der hierarchischen Struktur der einzelnen Elemente auch

festgelegt, welcher Datentyp fur die Attribute zulassig ist. Beispielhaft ist im nachsten Code-

Beispiel die Definition fur einige Topic-Elemente dargestellt:

XSD-Definitionen fur Taskstatus

1 <xs : simpleType name=”TopicStatus”>

2 <xs : r e s t r i c t i o n base=”xs : s t r i n g ”/>

3 </xs : simpleType>

4

5 <xs : simpleType name=”TopicType”>



8

9 <xs : simpleType name=”TopicLabel”>



12

13 <xs : simpleType name=”P r i o r i t y”>



16

17 <xs : simpleType name=”UserIdType”>



20

21 <xs : simpleType name=”Stage”>



24


Seite 14


25 <!−− Auszug aus : https : // github . com/buildingSMART/BCF−XML/ blob /

r e l e a s e 2 1 /Schemas/markup . xsd ; abgerufen am 08 . J u l i 2018−−>

Mithilfe von XSD-Daten konnen neben der Festlegung des zu verwendenden Datentyps

auch die moglichen Wertebereiche mithilfe zusatzlicher Definitionen von eigenen Typen oder

Enumerationen eingeschrankt werden. Es ist kritisch zu sehen, dass eine Vielzahl der im BCF-

Datenschema definierten Attribute lediglich dem Datentyp ’string’ folgen mussen, was fur die

tatsachliche Befullung dieser Elemente sehr großen Interpretationsraum lasst. Die Einfuhrung

von Limitierungen ware an dieser Stelle sehr wunschenswert, um den Datenaustausch uber

verschiedene Sprachbereiche hinweg zu vereinheitlichen. In den gezeigten Code-Ausschnitten

fallt auf, dass einige Attribute in deutscher Schreibweise und in anderen Fallen in englischer

Schreibweise belegt werden. Dies kann durchaus problematisch werden, da es neben moglichen

Problemen in der Lesbarkeit auch keine einheitliche Moglichkeit gibt, Filterfunktionen zu

verwenden.


Seite 15


Kapitel 3

Erstellung und Weitergabe von

BCF-Dateien

Shafiq et al. (2013) haben in ihrem Paper eine umfangreiche Ubersicht uber verschiedene Soft-

warelosungen erarbeitet, die BCF-Daten verarbeiten konnen und zum damaligen Zeitpunkt

auf dem Markt verfugbar waren. Da die Palette BCF-fahigen Anwendungen mittlerweile ex-

trem umfangreich ist, werden im Folgenden einige Produkte exemplarisch herausgegriffen, die

als wichtige Vertreter im deutschsprachigen Raum angesehen werden konnen.

Die Zahl der Anwendungen, die das BCF-Format direkt unterstutzen, wachst stetig. Daruber

hinaus gibt es zunehmend serverbasierte Dienste, die haufig Plugin-Losungen fur lokale Pro-

gramme anbieten und daruber die direkte Synchronisation mit den Servern ermoglichen (BIM-

collab, 2018).

Wie bereits im Kapitel uber die technischen Grundlagen angedeutet, sind BCF-Dateien

menschen-lesbar und verstandlich. In den allermeisten Fallen erfolgt die Erstellung dieser

Daten allerdings uber Programmoberflachen, die die eingegebenen Inhalte in den entspre-

chenden Feldern anschließend im richtigen Syntax in die XML-Datei parsen oder Daten wie

die Ansichts-Vektor automatisch aus der aktuellen Modellperspektive ableiten. Einige Ober-

flachen werden auf den nachsten Seiten vorgestellt.

3.1 BCF-Dateien als Ergebnis von Modellprufungen

Die in BCF-Datensatzen enthaltenen Informationen konnen entweder ausgehend von eigenen

Feststellungen definiert oder auf Grundlage von Modellprufungen teil-automatisiert generiert

werden. Als haufig eingesetzte Anwendung zur Modelluberprufung wird auf die Erstellung

von BCF-Tasks mithilfe von Solibri Model Checker detaillierter eingegangen.


Seite 16


Die Auswahl der betroffenen Bauteile und die Erstellung von Topics gliedert sich in

Solibri Model Checker in zwei Teile: Zum einen kann uber den Reiter ’Modell’ durch das

Gebaudemodell navigiert werden und einzelne Komponenten oder Bauteilgruppen in ihrer

Darstellung gesteuert werden (ein- und ausblenden, einfarben, transparent darstellen, ...).

Zur Erstellung eines neuer neuen Aufgabe oder eines neuen Problems wechselt man in den

Reiter ’Kommunikation’, in dem einerseits bereits bestehende Themen eingesehen werden

konnen und zum anderen neue Probleme und Prasentationen angelegt werden (Lehrstuhl fur

computergestutzte Modellierung und Simulation - Technische Universitat Munchen, 2015).

Mit Solibri konnen entweder bestehende Aufgaben und Probleme in BCF-Dateien bear-

beitet (zum Beispiel das Hinzufugen neuer Kommentare, Statusveranderungen, ...) oder neue

Topics erstellt werden. Neue Probleme speichert der Nutzer entweder in eine bestehende oder

in eine neue Prasentation. Zur Eingabe offnet sich ein eigenes Fenster, in das alle relevanten

Informationen eingetragen werden konnen. Es ist daruber hinaus auch moglich, die Ergeb-

nisse der Modellprufung automatisch in bestimmte Felder ubertragen zu lassen. Der Nutzer

kann diese im Anschluss noch anpassen.

Abbildung 3.1: Solibri: Ubernahme der Fehlerbeschreibung in die Problemdefinition

Die mit Solibri generierten BCF-Dateien entsprechen den Vorgaben der XSD-Schema-

Definition und konnen in alle anderen BCF-fahigen Umgebungen importiert werden. Dabei

entspricht die Erstellung einer ”Prasentation”der Generierung eines BCFzip-Ordners, der

verschiedene Topics als Unterordner enthalt.


Seite 17


3.2 Online Plattformen zum Austausch von IFC- und BCF-

Dateien

Aufgrund der zunehmenden Vernetzung verschiedener Planer und der Zusammenarbeit be-

reits wahrend der Entwurfs- und Planungsprozesse werden zunehmend serverbasierte Platt-

formen eingesetzt, um fruhzeitig Daten fur die gemeinsame Nutzung bereitstellen zu konnen.

Die Funktionalitaten dieser Plattformen unterscheiden sich zum Beispiel in den Belangen Li-

zenzierung, Anzahl der moglichen Nutzer pro Projekt, Speicherkapazitat pro Nutzer, Stand-

ort der Server oder rechtlicher Fragestellungen. Die Verarbeitung der BCF-Daten ist aber

aufgrund der Standardierung des BCF-Formates bei allen betrachteten Online-Plattformen

sehr ahnlich. Deshalb wird hier nun exemplarisch die Plattform BimPlus von Nemetschek

vorgestellt.

Die Erstellung eines Themas erfolgt uber eine ubersichtliche Weboberflache:

Abbildung 3.2: Eingabe eines neuen Themas in die BimPlus-Oberflache

Die Oberflache von BimPlus ermoglicht eine intuitive Bedienung: Links werden alle be-

reitgestellten IFC-Modelle sowie diverse Filtermoglichkeiten angezeigt, um verschiedene Ob-

jektgruppen ein- und auszublenden. Im mittleren Teil des Fensters werden die IFC-Modelle

in einer 3D-Umgebung dargestellt, deren Ansicht uber die Maus gesteuert werden kann. Im

unteren Teil des Viewers stehen außerdem weitere Funktionen zum Messen und zur Steuerung

der Modellvisualisierung zur Verfugung. An dieser Stelle kann auch ein neues Thema erstellt

werden, wodurch das Kontextmenu auf der rechten Seite erscheint.


Seite 18


In dieser Maske konnen die Informationen eingetragen werden, die spater in eine BCF-Datei

exportiert werden konnen.

Wechselt man in der Navigationsleiste am linken Rand in das vierte Symbol ”Task Board

anzeigen”, konnen alle Themen in einer Listendarstellung betrachtet und modifiziert werden.

Uber diese Ansicht kann sich der Anwender auch einen schnellen Uberblick verschaffen, welche

Aufgaben und Probleme derzeit den Status ’offen’ besitzen und welche Meldungen bereits

korrigiert wurden.

Abbildung 3.3: BimPlus: Task Board Ansicht

BimPlus verfugt wie viele andere Produkte sowohl uber eine Import- als auch Export-

schnittstelle fur BCF. Wie bereits bei Solibri vorgestellt, werden mehrere BCF-Topics in einen

BCFzip-Ordner gespeichert, welche in anderen Programmen als ”Prasentation”bezeichnet

werden.

3.2.1 Plugin-Losungen fur BIM-Editor-Programme

Ein bekannter und weit verbreiteter Anbieter, der die BCF-basierte Kommunikation in lo-

kale BIM-Anwendungen integriert, ist BIMcollab. Diese Plattform ist ein Produkt des nie-

derlandischen Unternehmens KUBUS und bezeichnet sich selbst als den ersten Anbieter, der

eine BCF-basierte Verbindung zu allen großen BIM-Anwendungen herstellen kann (BIMcol-

lab, 2018).

BIMcollab versteht sich als reine Kommunikationsplattform und unterstutzt ausschließlich

den Austausch von BCF-Dateien. Es konnen keine IFC-Dateien hinterlegt werden, was dazu

fuhrt, dass die IFC-Daten an einer anderen Stelle gespeichert und gepflegt werden mussen.


Seite 19


Mit BIMcollab konnen BCF-Dateien innerhalb der Standalone-App BCF Manager und

den Plugins einerseits erstellt und andererseits als BCFzip-Ordner importiert sowie exportiert

werden. Weiter besteht die Moglichkeit, die Verteilung der BCF-Dateien uber einen Server

abzuwickeln, wodurch alle Projektbeteiligten jederzeit Zugang zu der aktuellen Informationen

haben. Alternativ kann die Weitergabe aber auch als lokale Datei erfolgen, die uber andere

Kommunikationswege weitergegeben werden kann.

Im Rahmen dieser Arbeit wurde sowohl das Standalone-Tool als auch das Plugin fur

Autodesk Revit 2019 getestet. Beide Anwendungen konnen BCF-Daten lesen, bearbeiten

und schreiben. Aufgrund der fehlenden Einbindung des IFC-Modells wird die geometrische

Darstellung in der Standalone-Anwendung lediglich uber das Snapshot-Bild realisiert, welches

wie bereits erlautert eine sehr geringe Auflosung aufweist und sich nur im sehr begrenzten

Maße zur Orientierung innerhalb großer Modelle eignet.

Das Plugin fur Revit erfullt die grundsatzlichen Anforderung, BCF-Daten auch in drei-

dimensionalen Umgebung zu verorten. Problematisch ist allerdings, dass die entsprechende

Ansicht (ausgehend von den Viewport-Informationen) nur dann angezeigt werden kann, wenn

sich das ausgewahlte Thema auf das Revit-Modell referenzieren lasst. Wird hingegen ein IFC-

Modell in Revit importiert, konnen die Ansichtsinformationen, die in der BCF-Datei gespei-

chert sind, nicht dargestellt werden. Dies stellt insbesondere dann eine Einschrankung dar,

wenn Konflikte gewerkeubergreifend behoben werden mussen und Teilmodelle anderer Pla-

ner als IFC-Modell in das eigene Revitprojekt integriert werden. Um zwischen verschiedenen

Topics einer Prasentation zu wechseln, muss daruber hinaus immer die aktuelle 3D-Ansicht

’BCF Manager’ geschlossen werden, was fur den Nutzerkomfort nicht gerade forderlich ist.

Das Erzeugen neuer Themen lasst sich uber das Revit-Plugin problemlos realisieren.


Seite 20


Abbildung 3.4: BCF Manager: Kameraperspektive kann nur fur echte Revit-Projekte reproduziertwerden

Trotz dieser Einschrankungen ist die schlanke und dennoch umfassende Integration von

BCF-Daten in verschiedenste Anwendungen uber Herstellergrenzen hinweg ein sehr zu be-

grußender Schritt. Auch die Tatsache, dass BIMcollab in der Basisversion kostenlos bezogen

werden kann, ist ein nicht zu unterschatzendes Kriterium, um sich in einem wachsenden

Markt behaupten zu konnen.

BIMcollab hat zudem in einem Nutzer-Newsletter angekundigt, im Sommer 2018 ein Soft-

ware Development Kit zu veroffentlichen, welches die Einbindung der bestehenden Funktionen

in jegliche Programmumgebungen ermoglichen wird (BIMcollab, 2018).

3.3 Lokale Anwendungen

Neben cloudbasierten Diensten, die dem Konzept des Common Data Environment (CDE)

folgen, existieren auch zahlreiche Desktopanwendungen, die BCF-Dateien zusammen mit den

IFC-Dateien darstellen und verwalten konnen. Ein Beispiel ist hierfur Tekla BIMsight. Dabei

handelt es sich um einen IFC-Viewer, der mehrere Modelle darstellen und fur einfache Kol-

lisionsprufungen genutzt werden kann. Das kostenlose Tool ist daruber hinaus in der Lage,

BCF-Dateien zu importieren, zu bearbeiten und wieder zu exportieren.

Es ist zu erkennen, dass BCF genauso wie IFC zunehmend Beachtung und Anwendung

in der Praxis findet. Daher wird die Produktpalette an unterstutzenden Applikationen in


Seite 21


Abbildung 3.5: Nutzeroberflache Tekla BIMsight

Zukunft immer weiter wachsen. Auch die umfangreichere Einbindung in stark spezialisierte

Programme ist zu erwarten.


Seite 22


Kapitel 4

Problemstellungen und Ausblick

Die Untersuchung der vorgestellten Anwendungen hat gezeigt, dass das BCF-Format einen

ausgereiften Standard fur die Kommunikation innerhalb eines BIM-Projektes ermoglicht.

Dennoch gibt es Einschrankungen im Nutzerkomfort, sobald die BCF-Dateien in verschie-

denen Viewern betrachtet werden. Daher ware es wunschenswert, wenn neben der Kamera-

perspektive zusatzliche Informationen zu moglichen Schnittebenen oder eingeblendeten Ele-

menten in der unmittelbaren Umgebung des Problems uber das Datenschema transportiert

werden konnten.

Vergleicht man BCF-Daten, die von verschiedenen Programmen und Plattformen gene-

riert wurden, so fallt auf, dass die Befullung des Datenschemas sehr unterschiedlich implemen-

tiert ist. Dieses Problem ist der mangelnden Einschrankung der Datentypen im XSD-Schema

zuzuordnen. Um dieses Problem zu losen, sollten die Kardinalitaten fur bestimmte Elemente

so angepasst werden, dass diese auf jeden Fall befullt werden mussen (Parameter MinOc-

curs). Daruber hinaus sollten die moglichen Attributwerte von einigen Elementen durch die

Einfuhrung und Verfeinerung eigener Datenklassen eingeschrankt werden, um eine konsis-

tente Ubergabe und Darstellung der Daten in verschiedenen Viewern und Plattformen zu

gewahrleisten. Dies ware vor allem fur die Erstellung von Filterfunktionen von großem Vor-

teil. Denkbar ware hier auch eine Zertifizierung der Programme, wie sie fur die Import- und

Exportschnittstellen des IFC-Formates bereits vorgenommen wird (BuildingSMART, 2018b).

Der Ansatz von der Standalone-Variante von BIMcollab, lediglich BCF-Dateien zu ver-

walten und das verknupfte IFC-Modell nicht direkt darzustellen, kann positiv wie negativ

gesehen werden. Fur diesen Ansatz spricht, dass die Speicherorte der Gebaudemodelle un-

abhangig von der Kommunikation sind. Daher ist es zum Beispiel moglich, den Austausch

der IFC-Daten auf einem buro-internen Server abzuwickeln, ohne dabei eine komplette BCF-

Datenstruktur auf dem gleichen Server installieren zu mussen. Andererseits erfordert dieser

Ansatz zwingend den Einsatz einer zweiten Plattform zum Austausch der Gebaudemodelle.


Seite 23


Dies ist zum Beispiel bei Bimplus in einer nutzerfreundlicheren Weise gelost, da sowohl die

Kommunikationsdateien als auch die Gebaudeinformationen an einem zentralen Ort abrufbar

sind und dort aktualisiert werden konnen.

Die Zusammenarbeit auf Grundlage von BCF-Dateien erfordert eine hohe Disziplin bei

dem Verandern der IFC-Modelle. Nur wenn ein zu veranderndes Element erhalten bleibt,

kann es durch die Referenzierung in der BCF-Datei wieder aufgefunden werden. Wird das zu

bearbeitende Element geloscht und anschließend neu erstellt, so erhalt das neue Bauteil eine

neue GUID, die nicht mehr zu der in der BCF-Datei gespeicherten ID der betroffenen Kom-

ponenten passt. Sollte das Loschen unumganglich sein, da das Aktualisieren der bestehenden

Elemente zu groß ist, sollte die Referenzierung auf die betroffenen Bauteile in der BCF-Datei

angepasst werden.

Abbildung 4.1: BIMsight: Wande geloscht oder Modellierung neuer Wande anstatt der Anpassungbestehender Elemente. Folge: BCF-Datei kann referenzierte Elemente nicht mehr auffinden

Mit dem wachsenden Einsatz der BIM-Technologie im Infrastrukturwesen wird es in den

nachsten Jahren unumganglich sein, eine Erweiterung des BCF-Formates zu schaffen, mit

der Probleme und Aufgaben an linienartigen Projekten effektiver erfasst werden konnen.

Viele mogliche Anliegen, die bei der Planung von Straßen- oder Eisenbahnprojekten auftreten

konnen, sind bereits mit den bestehenden Moglichkeiten in BCF beherrschbar, aber gerade

fur Fragestellungen, die die linienartige Struktur von Infrastrukturvorhaben betreffen, sollten

passende Erweiterungen fur das BCF-Schema entwickelt werden.

Ein Datenformat kann die personliche Kommunikation nicht ersetzen - aber es kann helfen,

auf gleicher Grundlage mit einander ins Gesprach zu kommen.


Seite 24


Literaturverzeichnis

BIMcollab. BIMcollab R© about BCF. Zuletzt aufgerufen am 02.07.2018.

BIMcollab (2018). About KUBUS. Zuletzt aufgerufen am 04.06.2018.

BuildingSMART (2018a). About - buildingSMART. Zuletzt aufgerufen am 13.07.2018.

BuildingSMART (2018b). Software Certification - buildingSMART. Zuletzt aufgerufen am

14.07.2018.

Eric van der Vlist (2001). Using W3C XML Schema. Zuletzt aufgerufen am 04.06.2018.

Hudeczek, D. (2017). Formalisierung von Normen mithilfe von Auszeichnungssprachen fur

die automatisierte Konformitatsuberprufung.

Lehrstuhl fur computergestutzte Modellierung und Simulation - Technische Universitat

Munchen (2015). BIM Tutorial Model Checking.

Markic, S., Donaubauer, A. & Borrmann, A. (2018). Enabling Geodetic Coordinate Reference

Systems in Building Information Modeling for Infrastructure.

Schild, K. & Mochol, M. (2007). DTDs und XML - Schemata.

Schwerdtner, P. (2006). Erfolgsfaktor Kommunikation im Bauwesen.

Shafiq, M. T., Matthews, J. & Lockley, S. R. (2013). a Study of Bim Collaboration Re-

quirements and Available Features in Existing Model Collaboration Systems. Journal of

Information Technology in Construction (ITcon) 18(18), S. 148–161.

Stangeland, B. (2011). BIM Collaboration Format. buildingSMART 1, S. 1–3.

van Berlo, L. & Krijnen, T. (2014). Using the BIM Collaboration Format in a Server Based

Workflow. Procedia Environmental Sciences 22, S. 325–332.


Seite 25

kommunikation in bim-projekten auf grundlage von *.bcf-daten · advanced topics in building...

Documents