André Borrmann
Markus König
Christian Koch
Jakob Beetz Hrsg.
Building
Information
Modeling
Technologische Grundlagen
und industrielle Praxis
VDI-Buch
André Borrmann Markus König
Christian Koch Jakob Beetz
Herausgeber
Building Information
Modeling
Technologische Grundlagen und
industrielle Praxis
Herausgeber
André Borrmann Christian Koch
Technische Universität München The University of Nottingham
München, Deutschland Nottingham, Großbritannien
Springer Vieweg
© Springer Fachmedien Wiesbaden 2015
Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung, die nicht aus-
drücklich vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen Zustimmung des Verlags. Das
gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen, Mikroverfilmungen und die Ein-
speicherung und Verarbeitung in elektronischen Systemen.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk be-
rechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der
Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann
benutzt werden dürften.
Der Verlag, die Autoren und die Herausgeber gehen davon aus, dass die Angaben und Informationen in
diesem Werk zum Zeitpunkt der Veröffentlichung vollständig und korrekt sind. Weder der Verlag noch
die Autoren oder die Herausgeber übernehmen, ausdrücklich oder implizit, Gewähr für den Inhalt des
Werkes, etwaige Fehler oder Äußerungen.
Springer Fachmedien Wiesbaden GmbH ist Teil der Fachverlagsgruppe Springer Science+Business Media
(www.springer.com)
Vorwort
Building Information Modeling (BIM) steht für die Idee der durchgängigen Nutzung
digitaler Bauwerksmodelle für alle Bereiche des Bauwesens – angefangen bei der Pla-
nung über die Ausführung und den Betrieb bis hin zum Abriss. Diese Idee, die bereits
seit den 1990er Jahren von der deutschen und internationalen Bauinformatik-Forschung
propagiert und vorangetrieben wurde, findet seit einiger Zeit zunehmend Eingang in die
Praxis und leitet dabei einen umfassenden Wandel der Arbeitstechniken und Arbeitswei-
sen im Bauwesen ein. BIM basiert auf der konsequenten Weiternutzung digitaler Daten
und verspricht dadurch eine signifikante Steigerung der Produktivität bei gleichzeitiger
Verringerung von Fehlern, da diese frühzeitig erkannt und behoben werden können. Wich-
tige Vorteile liegen in der direkten Verwendbarkeit der Modelle für unterschiedlichste
Berechnungs- und Analysewerkzeuge sowie in der nahtlosen Weiternutzung der digitalen
Informationen für die Bewirtschaftungsphase. Mit den heute verfügbaren leistungsfähigen
und ausgereiften Softwareprodukten für das BIM-gestützte Arbeiten steht der Umsetzung
der BIM-Methodik in der Baupraxis grundsätzlich nichts mehr im Wege.
Stellt man die Frage nach dem Stand des praktischen Einsatzes von BIM, lohnt sich ein
Blick über den Atlantik. In den USA wird die Einführung von BIM in der Bauindustrie
bereits seit Mitte der 2000er Jahre konsequent vorangetrieben. Große Teile der ameri-
kanischen Bauindustrie setzen die BIM-gestützte Planung und Ausführung heute bereits
erfolgreich um. Zudem gibt es neben dem National BIM Standard, der bereits in einer
überarbeiteten zweiten Version vorliegt, eine Vielzahl lokaler Richtlinien, die die Ausge-
staltung von digitalen Gebäudemodellen für die unterschiedlichsten Anwendungsbereiche
im Detail regeln.
Vorreiter in Europa sind die skandinavischen Länder. Seit 2001 wurden in Finnland er-
folgreich mehrere BIM-Pilotprojekte zur Einführung von Produktmodellen im Bauwesen
durchgeführt. Auf Basis dieses Erfolges hat der Finnische Senat 2007 beschlossen, BIM
in allen seinen Projekten einzusetzen. In Norwegen wurden von 2007 bis 2009 ebenfalls
Pilotprojekte durchgeführt, bevor 2010 die BIM-Nutzung für bindend erklärt wurde.
Von der britischen Regierung wurde im Jahr 2011 die „UK BIM Initiative“ ins Leben
gerufen. Erklärtes Ziel dieser Initiative ist es, mithilfe digitaler Technologien die britische
Bauindustrie so umfassend zu modernisieren, dass ihr damit ein entscheidender Vorsprung
im internationalen Wettbewerb verschafft wird. Bis zum Jahr 2016 soll BIM flächende-
V
VI Vorwort
Wir danken allen Autoren für die hervorragende Mitwirkung an diesem Buch, ohne
die seine Herausgabe nicht möglich gewesen wäre. Ganz besonders möchten wir uns bei
Simon Vilgertshofer bedanken, der die technische Koordination des Buchs übernommen
und in hervorragender Weise umgesetzt hat.
1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...... 1
André Borrmann, Markus König, Christian Koch und Jakob Beetz
1.1 Building Information Modeling – Warum? . . . . . . . . . . . . . . . . . 2
1.2 Building Information Modeling – Was? . . . . . . . . . . . . . . . . . . . 4
1.3 Building Information Modeling – Wie? . . . . . . . . . . . . . . . . . . . 7
1.3.1 little bim vs. BIG BIM, Closed BIM vs. Open BIM . . . . . . 7
1.3.2 BIM-Reifegradstufen . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.3 Vertragliche Vereinbarungen . . . . . . . . . . . . . . . . . . . . 10
1.3.4 Neue Rollen und Berufsbilder . . . . . . . . . . . . . . . . . . . 12
1.4 Stand der Einführung – international und in Deutschland . . . . . . . . 13
1.4.1 Stand der Einführung international . . . . . . . . . . . . . . . . . 13
1.4.2 Stand der Einführung in Deutschland . . . . . . . . . . . . . . . 15
1.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.6 Aufbau des Buchs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
XIII
XIV Inhaltsverzeichnis
2.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3 Objektorientierte Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Christian Koch
3.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2 Digitale Modelle als Abstraktionen der Wirklichkeit . . . . . . . . . . . 44
3.3 Objektorientierte Modellierung . . . . . . . . . . . . . . . . . . . . . . . . 45
3.3.1 OOM-Methodik . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.3.2 OOM-Konzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.4 Herausforderungen bei der Modellierung von Bauwerksinformationen 55
Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4 Prozessmodellierung . . . . . . . . . . . . . . . . . . . . . . . . .......... 57
Markus König
4.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2 Workflow-Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.3 Prozessmodellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.3.1 Integration Definition for Function Modeling . . . . . . . . . . 62
4.3.2 Business Process Modeling and Notation . . . . . . . . . . . . . 63
4.4 Workflow-Management-Systeme . . . . . . . . . . . . . . . . . . . . . . . 68
4.5 Ausführungsprozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.6 Zusammenfassung und Ausblick . . . . . . . . . . . . . . . . . . . . . . . 72
Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Teil II lnteroperabiliät
9 Ordnungssysteme im Bauwesen:
Terminologien, Klassifikationen, Taxonomien und Ontologien . . . . . . . 163
Jakob Beetz
9.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
9.2 Anwendungen von Ordnungssystemen in der Praxis . . . . . . . . . . . 165
9.3 Grundlagen von Ordnungssystemen . . . . . . . . . . . . . . . . . . . . . 167
9.3.1 Gemeinsame Fachvokabulare . . . . . . . . . . . . . . . . . . . . 167
9.3.2 Klassifikationssysteme . . . . . . . . . . . . . . . . . . . . . . . . 167
9.3.3 Ontologien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
9.4 Technische Implementierung von Ordnungssystemen . . . . . . . . . . 169
9.4.1 Klassifikationstabellen . . . . . . . . . . . . . . . . . . . . . . . . 169
9.4.2 ISO 12006 und bSDD . . . . . . . . . . . . . . . . . . . . . . . . 169
9.4.3 DIN SPEC 91400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
9.4.4 Semantic Web und Linked Data . . . . . . . . . . . . . . . . . . 172
9.5 Diskussion und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
11 BIM-Programmierwerkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Julian Amann, Eike Tauscher und André Borrmann
11.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
11.2 Verfahren für den Zugriff auf Daten im STEP-Format . . . . . . . . . . 194
Inhaltsverzeichnis XVII
13 BIM-Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Jan Tulke und Dirk Schaper
13.1 BIM-Manager als neue Rolle . . . . . . . . . . . . . . . . . . . . . . . . . 237
13.2 Erfolgsfaktor BIM-Manager . . . . . . . . . . . . . . . . . . . . . . . . . . 239
13.3 Aufgaben des BIM-Managers . . . . . . . . . . . . . . . . . . . . . . . . . 241
XVIII Inhaltsverzeichnis
39 5D Initiative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555
Konstantinos Kessoudis, Jochen Teizer, Jan Lodewijks und Frank Schley
39.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556
39.2 Prozessintegration durch Entwicklung spezifischer Softwarelösungen
für die Bauindustrie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557
Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559
Autorensteckbriefe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567
Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581
Sachverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
Die Herausgeber
XXVII
XXVIII Die Herausgeber
Zusammenfassung
Building Information Modeling (BIM) basiert auf der Idee einer durchgängigen Nut-
zung eines digitalen Gebäudemodells über den gesamten Lebenszyklus eines Bauwerks
– vom Entwurf, über die Planung und Ausführung bis zum Betrieb des Gebäudes.
Sie geht einher mit dem Gedanken eines deutlich verbesserten Datenaustauschs und
der dadurch erzielbaren Steigerung der Planungseffizienz durch Wegfall der aufwändi-
gen und fehleranfälligen Wiedereingabe von Informationen. Dank der Verfügbarkeit
von modernen Softwarewerkzeugen steht der Umsetzung dieser Vision in der Pla-
nungspraxis aus technischer Sicht heute nichts mehr im Wege. Während einzelne,
besonders innovative Planungsbüros und Baufirmen BIM bereits konsequent einsetzen,
steht in Deutschland die flächendeckende Einführung noch bevor. Eine maßgebliche
André Borrmann
Technische Universität München, Lehrstuhl für Computergestützte Modellierung und Simulation,
Arcisstr. 21, 80333 München, Deutschland
e-mail: andre.borrmann@tum.de
Markus König
Ruhr-Universität Bochum, Lehrstuhl für Informatik im Bauwesen, Universitätsstraße 150,
44780 Bochum, Deutschland
e-mail: koenig@inf.bi.rub.de
Christian Koch
The University of Nottingham, Department of Civil Engineering, University Park, NG7
2RD Nottingham, Großbritannien
e-mail: christian.koch@nottingham.ac.uk
Jakob Beetz
Technische Universiteit Eindhoven, Department of the Built Environment, Urban Science and
Systems, P.O. Box 513, 5600 Eindhoven, Niederlande
e-mail: J.Beetz@bwk.tue.nl
Rolle kommt dabei der öffentlichen Hand zu, die in vielen anderen Ländern die Nut-
zung von BIM in der Bauplanung bereits verbindlich vorgeschrieben hat.
Die Digitalisierung hat im vergangenen Jahrzehnt weite Bereiche der Wirtschaft erfasst
und für einen immensen Zugewinn an Produktivität in den unterschiedlichsten Industrie-
sektoren gesorgt. Zwar werden auch im Bauwesen für die Planung, Errichtung und den
Betrieb von Gebäuden digitale Werkzeuge eingesetzt, der Grad der Weiternutzung einmal
erzeugter digitaler Informationen bleibt jedoch weit hinter dem anderer Branchen zurück.
Viel zu häufig gehen wertvolle Informationen infolge der vorherrschenden Informati-
onsübermittlung durch gedruckte Baupläne oder nur eingeschränkt weiterverwendbare
Digitalformate verloren. Derartige Informationsbrüche treten über den gesamten Lebens-
zyklus eines Bauwerks auf: angefangen bei den verschiedenen Phasen der Planung, über
die Ausführung und die lange Phase der Bewirtschaftung bis hin zum Um- bzw. Rückbau
des Bauwerks.
Die Planung und Realisierung von Bauwerken ist ein komplexer Vorgang mit einer
Vielzahl von Beteiligten aus unterschiedlichen Fachdisziplinen. Für das Gelingen eines
Bauvorhabens sind eine kontinuierliche Abstimmung und ein intensiver Informationsaus-
tausch erforderlich. Dieser Informationsaustausch basiert heute zu einem überwiegenden
Teil auf dem Austausch von technischen Zeichnungen, die Gebäudeinformationen vor al-
lem in grafischer Form von Schnitten, Grundrissen und Detailzeichnungen wiedergeben.
Die eingesetzten Softwareprodukte zum Erstellen derartiger Zeichnungen imitieren dabei
die Jahrhunderte alte Arbeitsweise mit dem Zeichenbrett.
Strichzeichnungen können aber in der Regel nicht vom Computer interpretiert, d. h. die
darin enthaltenen Informationen können zum großen Teil nicht automatisiert erschlossen
und verarbeitet werden. Dadurch bleibt das große Potenzial, das die Informationstech-
nologie zur Unterstützung der Projektabwicklung und Bewirtschaftung bietet, so gut wie
ungenutzt. Eines der schwerwiegendsten Probleme liegt darin, dass die Konsistenz der
verschiedenen technischen Zeichnungen heute häufig nur manuell geprüft werden kann.
Daraus ergibt sich eine massive Fehlerquelle, vor allem angesichts der Tatsache, dass die
Gebäudeinformationen über eine Vielzahl von Plänen verstreut vorliegen und diese von
unterschiedlichen Fachplanern erstellt werden. Besonders bei auftretenden Änderungen –
die heute i. d. R. mithilfe einer „Umwolkung“ im betreffenden Plan gekennzeichnet wer-
den – können sich schnell Unstimmigkeiten und Fehler ergeben, die häufig erst während
der Bauausführung entdeckt werden und dann zu enormen Folgekosten führen.
Eine weitere signifikante Einschränkung infolge der mangelnden Informationstiefe der
Baupläne besteht darin, dass Gebäudeinformationen für Simulationen, Analysen und Be-
rechnungen nicht auf direktem Wege übernommen, sondern in den entsprechenden Soft-
warewerkzeugen erneut eingegeben werden müssen. Ebenso problematisch ist die Über-
gabe von Bauplänen an den Bauherrn nach der Fertigstellung des Gebäudes: Dieser muss
1 Einführung 3
Verlust
Digitale Informationen
Zeit
mit viel Aufwand die notwendigen Informationen für den Betrieb des Gebäudes extrahie-
ren und in ein Facility-Management-System überführen. Bei allen genannten Übergabe-
punkten gehen bereits vorliegende digitale Informationen wieder verloren (Abb. 1.1).
Die Idee des Building Information Modeling setzt genau hier an. Durch die BIM-Me-
thode bestehen viel tiefgreifender Möglichkeiten zur Computerunterstützung bei Planung,
Bau und Betrieb von Bauwerken, da Bauwerksinformationen nicht in Zeichnungen abge-
legt, sondern in Form eines umfassenden digitalen Bauwerksmodells erstellt, vorgehalten
und weitergegeben werden. Die Koordination der Planung, die Anbindung von Simula-
tionen, die Steuerung des Bauablaufs und die Übergabe von Gebäudeinformationen an
den Betreiber kann dadurch deutlich verbessert werden. Durch den Wegfall von Neuein-
gaben und der konsequenten Weiternutzung digitaler Informationen werden aufwendige
und fehleranfällige Arbeiten vermieden und ein Zuwachs an Produktivität und Qualität
erzielt.
Andere Industriezweige wie beispielsweise die Automobilindustrie setzen schon länger
auf eine durchgängige modellgestützte Produktentwicklung und -fertigung und konnten
dadurch erhebliche Effizienzgewinne erzielen (Heindorf 2010). Dabei ist allerdings zu
beachten, dass das Bauwesen anderen, zum Teil sehr schwierigen Randbedingungen un-
terworfen ist: Die Prozess- und Wertschöpfungskette liegt beispielsweise nicht in der Hand
eines einzelnen Unternehmens, sondern ist über eine Vielzahl von Unternehmen (Archi-
tekturbüros, Fachplaner, Baufirmen) verteilt. Die Zusammenarbeit dieser Unternehmen
wird i. d. R. immer für einzelne Bauvorhaben und nicht über längere Zeiträume hinweg
vereinbart. Diese Randbedingungen führen dazu, dass vielfältige Schnittstellen zwischen
verschiedenen Unternehmen existieren, an denen digitale Informationen übergeben wer-
den müssen. Da eine zentrale Steuerung des Informationsflusses nicht gegeben ist, kommt
im Bauwesen dem Kunden, also dem Bauherren, eine besondere Rolle zu. Er muss die
Nutzung von BIM fordern, definieren und überwachen.
4 A. Borrmann et al.
Unter einem Building Information Model (BIM) versteht man ein umfassendes digitales
Abbild eines Bauwerks mit großer Informationstiefe. Dazu gehören neben der dreidimen-
sionalen Geometrie der Bauteile vor allem auch nicht-geometrische Zusatzinformationen
wie Typinformationen, technische Eigenschaften oder Kosten. Der Begriff Building Infor-
mation Modeling beschreibt entsprechend den Vorgang zur Erschaffung, Änderung und
Verwaltung eines solchen digitalen Bauwerkmodells mithilfe entsprechender Software-
werkzeuge.
Im erweiterten Sinne wird dieser Begriff jedoch auch verwendet, um damit die Nut-
zung dieses digitalen Modells über den gesamten Lebenszyklus des Bauwerks hinweg
zu beschreiben – also von der Planung, über die Ausführung bis zur Bewirtschaftung
und schließlich zum Rückbau (Abb. 1.2). Vor allem hierin liegt das enorme Potenzial
der BIM-Technologie: Wenn über die einzelnen Phasen hinaus Daten konsequent weiter-
genutzt werden, kann die bislang übliche aufwendige und fehleranfällige Wiedereingabe
von Informationen auf ein Minimum reduziert werden.
Im US-amerikanischen National Building Information Modeling Standard wird BIM
wie folgt definiert (NIBS 2012): „Building Information Modeling (BIM) is a digital re-
presentation of physical and functional characteristics of a facility. A BIM is a shared
Entwurf
Planung
Raumprogramm
Gewerkekoordination
Variantenstudien
Kostenermittlung
Konzeptionelles Design
Simulationen, Berechnungen
Rückbau
Ausführung
Umbau
Building Information Model Bauablaufsimulation
Recycling
Baufortschrittskontrolle
Revitalisierung
Baustellenlogistik
Abrechnung
Bewirtschaftung
Facility Management, Wartung, Betriebskosten
Abb. 1.2 Building Information Modeling beruht auf der durchgängigen Nutzung und verlustfreien
Weitergabe eines digitalen Gebäudemodells über den gesamten Lebenszyklus
1 Einführung 5
knowledge resource for information about a facility forming a reliable basis for decisions
during its life-cycle; defined as existing from earliest conception to demolition. A basic
premise of BIM is collaboration by different stakeholders at different phases of the life
cycle of a facility to insert, extract, update or modify information in the BIM to support
and reflect the roles of that stakeholder.“
Das BIM-Konzept ist nicht neu. In der Tat wurden bereits in den 1970er-Jahren die
ersten Forschungsarbeiten zum Aufbau und zum Einsatz virtueller Gebäudemodelle ver-
öffentlicht (Eastman et al. 1974). Der Begriff Building Information Modeling wurde das
erste Mal 1992 in einem Paper der Wissenschaftler van Needervan und Tolman (1992)
verwendet. Eine weite Verbreitung erlangte der Begriff jedoch erst nach seiner Verwen-
dung durch die Firma Autodesk in einem White Paper im Jahr 2003 (Autodesk 2003).
Mittlerweile stehen äußerst leistungsfähige Softwarewerkzeuge zur Verfügung, sodass die
zunächst nur theoretisch entwickelten Konzepte heute Eingang in die industrielle Praxis
gefunden haben.
Augenfälligstes Merkmal eines Building Information Model ist die dreidimensionale
Modellierung des Bauwerks, die das Ableiten von konsistenten 2D-Plänen für Grundrisse
und Schnitte ermöglicht. Wesentlich ist aber, dass BIM-Entwurfswerkzeuge im Unter-
schied zu reinen 3D-Modellierern einen Katalog mit bauspezifischen Objekten anbieten,
der vordefinierte Bauteile wie Wände, Stützen, Fenster, Türen etc. beinhaltet. Diese Bau-
teilobjekte kombinieren die meist parametrisierte 3D-Geometriedarstellung mit weiteren
beschreibenden Merkmalen und definierten Beziehungen zu anderen Bauteilen. Die Ar-
beit mit diesen Bauteilen ist unter anderem deshalb notwendig, damit später Pläne aus
dem BIM abgeleitet werden können, die den geltenden Vorschriften und Normen entspre-
chen. Daneben erlaubt die bauteilorientierte Modellierung eines Bauwerks vor allem auch
die unmittelbare Anwendung unterschiedlichster Analyse- und Simulationswerkzeuge.
BIM im Planungsprozess
Mit der Umsetzung der BIM-Methodik ergibt sich bereits für den Planungsprozess ei-
ne Vielzahl von Vorteilen. Alle technischen Zeichnungen, einschließlich der verschiede-
nen Ansichten, Grundrisse und Schnitte werden direkt aus dem Modell abgeleitet und
sind damit automatisch untereinander widerspruchsfrei. Es können Kollisionskontrollen
zwischen den Teilmodellen der verschiedenen Gewerke durchgeführt werden, um auf
diese Weise Konflikte frühzeitig zu erkennen. Des Weiteren können verschiedene Berech-
nungs- und Simulationsprogramme angeschlossen werden, die eine Vielzahl von Infor-
mationen wie beispielsweise zur Gebäudegeometrie direkt aus dem Modell übernehmen.
Dazu gehören statische Nachweise ebenso wie Wärmebedarfsberechnungen, Evakuie-
rungssimulationen und Beleuchtungsanalysen. Durch die enorme Informationstiefe, die
ein Building Information Model bietet, kann der überwiegende Teil der benötigten Ein-
gangsinformationen direkt aus dem Modell abgeleitet werden. Zum Teil kann das Modell
zudem auf Einhaltung von gesetzlichen Vorschriften, Normen und Richtlinien geprüft
werden. Und schließlich erlaubt das BIM-Modell eine äußert präzise Mengenermittlung,
was die Grundlage für eine zuverlässige Kostenschätzung bildet und darüber hinaus das
Erstellen des Leistungsverzeichnisses für die Ausschreibung erheblich beschleunigt.
6 A. Borrmann et al.
BIM-gestützter
Planungsprozess
Konvenoneller
Planungsprozess
Abb. 1.3 Building Information Modeling führt zu einer Vorverlagerung von Planungs- und Ent-
scheidungsprozessen. Dies erlaubt eine umfassendere Einflussnahme auf die Gestaltung und die
Kosten des entstehenden Gebäudes bei gleichzeitig verringerten Kosten bei Planungsänderungen
(nach MacLeamy 2004)
Durch den Einsatz von BIM in der Planung ergibt sich gegenüber den bisherigen
Abläufen eine Aufwandsverlagerung, die mit Abb. 1.3 illustriert wird. Bei der konventio-
nellen Planung wird der Hauptaufwand zur Ausarbeitung des Entwurfs in späten Phasen
geleistet. Das führt dazu, dass die Anwendung verschiedener Analyse- und Simulations-
werkzeuge und eine umfassende Bewertung des Entwurfs erst zu einem fortgeschrittenen
Zeitpunkt möglich sind. Dann sind die Möglichkeiten zur Änderung des Entwurfs aller-
dings bereits sehr begrenzt bzw. führen zu erheblichen zusätzlichen Kosten.
Im Gegensatz dazu verlagert der BIM-gestützte Planungsprozess den Planungsaufwand
in die frühen Phasen, in dem bereits hier ein umfassendes digitales Modell des Entwurfs
geschaffen wird. Daraus ergibt sich der Vorteil, dass dieses Modell bereits in diesen frü-
hen Phasen für erste Simulationen und Berechnungen verwendet werden kann. Auf diese
Weise können unterschiedliche Entwurfsoptionen eingehend untersucht werden, was zu
einem verringerten Aufwand in späten Planungsphasen und einer erhöhten Entwurfsqua-
lität führt.
Aufwandsermittlung für die Angebotsabgabe und ermöglicht später die präzise Abrech-
nung. Mithilfe eines 4D-BIM, das durch Kombination der Bauteilobjekte mit den ge-
planten Fertigstellungszeiträumen erzeugt wird, kann der Bauablaufs geprüft, etwaige
Unstimmigkeiten bzw. räumliche Kollisionen frühzeitig erkannt und die Baustellenlogis-
tik koordiniert werden. Und schließlich kann die Abrechnung von Bauleistungen sowie
das Mängelmanagement wiederum anhand eines BIM realisiert werden.
BIM im Gebäudebetrieb
Weitere ganz wesentliche Vorteile des BIM-Ansatzes ergeben sich aus der Nutzung des
digitalen Gebäudemodells über die vergleichsweise lange Nutzungs- bzw. Bewirtschaf-
tungsphase. Voraussetzung hierfür ist die Übergabe des BIM-Modells vom Planer an
den Bauherrn, ggf. ergänzt um Informationen aus der Ausführung. Werden dem Bau-
herrn anstelle von „toten“ Zeichnungen hochwertige digitale Informationen in Form eines
Building Information Models übergeben, kann er diese direkt für das Facility Manage-
ment verwenden und dabei beispielsweise Informationen zu den Raumgrößen, Elektro-
und Haustechnikanschlüssen direkt übernehmen. Für den Betrieb des Gebäudes besonders
hilfreich sind Zusatzinformationen zu den verbauten technischen Geräten einschließlich
der Wartungsintervalle und Garantiebedingungen. Wichtig ist die kontinuierliche Pflege
des digitalen Gebäudemodells, d. h. dass alle Änderungen am realen Gebäude auch im
digitalen Abbild entsprechend nachgeführt werden müssen. Kommt es zu größeren Um-
baumaßnahmen oder wird das Gebäude am Ende seines Lebenszyklus zurückgebaut, kann
das Modell genauen Aufschluss über die verbauten Materialien geben und ermöglicht so
eine umweltgerechte Entsorgung bzw. das Recycling von Bauteilen.
1.3.1 little bim vs. BIG BIM, Closed BIM vs. Open BIM
Der Umstieg von der herkömmlichen zeichnungsgestützten auf die modellgestützte Arbeit
macht Änderungen an den unternehmensinternen und unternehmensübergreifenden Pro-
zessen notwendig. Um die Funktionstüchtigkeit der Abläufe nicht zu gefährden, ist ein
schrittweiser Übergang sinnvoll. Entsprechend unterscheidet man bei der Umsetzung von
BIM verschiedene technologische Stufen.
Die einfachste Unterscheidung wird mit den Begriffen „BIG BIM“ und „little bim“
vorgenommen (Jernigan 2008). Dabei bezeichnet little bim die Nutzung einer spezifi-
schen BIM-Software durch einen einzelnen Planer im Rahmen seiner disziplinspezifi-
schen Aufgaben. Mit dieser Software wird ein digitales Gebäudemodell erzeugt und Pläne
abgeleitet. Die Weiternutzung des Modells über verschiedene Softwareprodukte hinweg
geschieht nicht. Ebenso wenig wird das Gebäudemodell zur Koordination der Planung
zwischen den beteiligten Fachdisziplinen herangezogen. BIM wird in diesem Fall also
als Insellösung innerhalb einer Fachdisziplin eingesetzt, die Kommunikation nach außen
8 A. Borrmann et al.
Open BIM
Es werden Softwareprodukte little open BIM big open BIM
verschiedener Hersteller und
offene Formate für den
Datenaustausch eingesetzt.
Closed BIM
Es werden Softwareprodukte little closed BIM big closed BIM
eines einzelnen Herstellers und
proprietäre Formate für den
Datenaustausch eingesetzt.
Abb. 1.4 Die Breite des BIM-Einsatzes unterschiedet „little bim“ von „BIG BIM“. Je nachdem,
ob herstellerneutrale Datenaustauschformate zum Einsatz kommen, spricht man von „Closed BIM“
oder „Open BIM“. Die Kombination dieser beiden Aspekte ergibt die hier gezeigt Matrix
wird weiterhin zeichnungsgestützt abgewickelt. Zwar lassen sich mit little bim bereits
Effizienzgewinne erzielen, das große Potenzial einer durchgängigen Nutzung digitaler
Gebäudeinformationen bleibt jedoch unerschlossen. Im Gegensatz dazu bedeutet BIG
BIM die konsequente modellbasierte Kommunikation zwischen allen Beteiligten über al-
le Phasen des Lebenszyklus eines Gebäudes hinweg. Für den Datenaustausch und die
Koordination der Zusammenarbeit werden in umfassender Weise Internetplattformen und
Datenbanklösungen eingesetzt (siehe Abb. 1.4).
Orthogonal dazu steht die Frage, ob ausschließlich Softwareprodukte eines Herstellers
eingesetzt und für den Datenaustausch entsprechende proprietäre Schnittstellen genutzt
werden, oder ob offene, herstellerneutrale Datenformate zum Einsatz kommen, die den
Datenaustausch zwischen Produkten verschiedener Hersteller ermöglichen. Zwar bieten
einzelne Softwarehersteller eine erstaunliche Palette von Softwareprodukten für das Bau-
wesen an und können damit eine große Bandbreite der Aufgaben in Planung, Bau und
Betrieb abdecken. Allerdings wird es auch weiterhin Lücken geben, bei denen Produkte
anderer Hersteller zum Einsatz kommen müssen. Die Heterogenität der Softwareland-
schaft ergibt sich darüber hinaus insbesondere aus der Vielzahl der beteiligten Fachdiszi-
plinen und der Verteilung der Aufgaben über verschiedene Unternehmen.
Das sich daraus ergebende Problem der mangelnden Interoperabilität verursacht enor-
me Kosten: 2004 führte das US-amerikanische Institut für Standards und Technologie
(NIST) eine Studie durch, die die im Jahre 2002 bei Planung, Ausführung und Betrieb
anfallenden Mehrkosten infolge mangelnder Interoperabilität zwischen den eingesetzten
1 Einführung 9
Softwaresystemen mit 15,8 Mrd. US-Dollar bezifferte (Gallagher et al. 2004). Diese Si-
tuation hat sich bis heute nicht grundlegend geändert.
Um dieser enormen Verschwendung von Wirtschaftskraft zu begegnen und den Da-
tenaustausch zwischen Softwareprodukten des Bauwesens zu verbessern, gründete sich
Anfang der 1990er-Jahre die Internationale Allianz für Interoperabilität (IAI), eine in-
ternationale Non-Profit-Organisation, die sich 2003 in buildingSMART umbenannt hat.
Ihr ist es gelungen, ein herstellerunabhängiges Datenformat zur umfänglichen Beschrei-
bung von Bauwerksmodellen zu schaffen, das den Namen Industry Foundation Classes
(IFC) trägt. Das Datenmodell beinhaltet umfangreiche Datenstrukturen zur Beschreibung
von Objekten aus nahezu allen Bereichen des Hochbaus. Es wurde 2013 in einen ISO-
Standard überführt (ISO 2013) und bildet die Grundlage einer Vielzahl nationaler Richt-
linien zur Umsetzung von Open BIM. Kapitel 6 widmet sich ausführlich diesem Daten-
format.
Einschränkend ist jedoch zu bemerken, dass die Nutzung herstellerneutraler Forma-
te heute noch nicht immer einwandfrei funktioniert und der Datenaustausch zum Teil
fehlerbehaftet ist. Dies liegt vor allem darin begründet, dass sowohl die Schaffung von
Neutralformaten als auch deren korrekte Implementierung durch die Softwarehersteller
technisch äußerst anspruchsvoll sind. Es gibt jedoch genügend Grund für die Annahme,
dass die verbleibenden technischen Probleme bald gelöst werden, wenn dieses Ziel von
den Softwareherstellern mit der nötigen Ernsthaftigkeit verfolgt wird. Diese wird insbe-
sondere davon abhängen, wie stark der Markt (bzw. die Bauherren) die Nutzung von Open
BIM einfordert. Bedenkt man jedoch die negativen Auswirkungen, die eine zu große
Marktdominanz eines einzelnen Softwareherstellers mit sich bringt, ist die Philosophie
des Open BIM in jedem Fall der richtige Weg.
1.3.2 BIM-Reifegradstufen
Die Bauindustrie kann den Umstieg auf die durchgängig modellgestützten Arbeiten im
Sinne von BIG Open BIM nicht in einem Zug bewältigen, stattdessen ist eine schrittwei-
se Einführung dieser neuen Technologie sinnvoll. Von der britischen BIM Task Group
wurde in diesem Zusammenhang ein BIM-Reifegradmodell (engl. BIM Maturity Model)
eingeführt, das vier verschiedene Stufen der Umsetzung von BIM definiert (Abb. 1.5).
Stufe 0 beschreibt dabei das konventionelle Arbeiten mit 2D-CAD und den Austausch
von papiergedruckten Plänen. Stufe 1 beinhaltet das Erzeugen von 3D-Modellen für kriti-
sche Bereiche des geplanten Gebäudes, die mit herkömmlichen 2D-Zeichnungen koexis-
tieren. Der Datenaustausch geschieht durch das Versenden einzelner Dateien, eine zentrale
Projektplattform existiert nicht.
Level 2 sieht die Nutzung von BIM-Software zum Erstellen digitaler Gebäudemodel-
le vor. Dabei wird davon ausgegangen, dass die Fachplaner jeweils eigene, voneinander
unabhängige Modelle erzeugen, die jedoch regelmäßig miteinander abgeglichen werden
(s. Abb. 1.6). Der Datenaustausch basiert auf dem Austausch von Dateien, es kommen
10 A. Borrmann et al.
iBIM
BIMs
BSIM
BRIM
AIM
SIM
FIM
IDM, IFC, IFD
2D 3D
Proprietäre Proprietärformate ISO-Standards Austauschformate
CAD Formate COBie
Abb. 1.5 Die BIM Maturity Ramp der britischen BIM Task Group definiert vier verschiedene Rei-
fegradstufen. Bis zum Jahr 2016 soll in Großbritannien Level 2 umgesetzt werden (Diagramm nach
Bew und Richards 2008)
Eine wesentliche Voraussetzung für die erfolgreiche Umsetzung von BIM sind ver-
tragliche Vereinbarungen hinsichtlich der Modellinhalte, der Modellqualität und der
Prozessabläufe, letzteres insbesondere in Bezug auf die Übergabe von Modellen. Ein
1 Einführung 11
Zusammengeführtes
Modell
Prüfung,
Koordination
PDF
Nave Nave Nave vertragliche COBie
Dateien Dateien Dateien 2D-Zeichnungen Spreadsheet
und Spezifikaonen
Abb. 1.6 Die auf Level 2 vorgesehene Arbeitsweise beruht auf der Verwendung von nativen Dateien
durch die einzelnen Fachplaner und der regelmäßigen Zusammenführen in ein gemeinsames Mo-
dell zur Prüfung und Koordination der Gewerke. Aus dem zusammengeführten Modell werden die
vertraglichen 2D-Zeichnungen und Spezifikationen abgeleitet und in PDF-Dateien abgelegt. Eine
wichtige Rolle spielen COBie-Tabellenblätter, die Informationen zum Gebäude und zur Haustech-
nik in strukturierter Form beinhalten und an den Bauherrn übermittelt werden müssen
genereller rechtlicher Rahmen wird durch ein BIM-Protokoll festgelegt, wie es beispiels-
weise vom britischen Construction Industry Council herausgegen wurde (Construction
Industry Council 2013). Darin werden die zu verwendende Terminologie und allgemeine
Verantwortlichkeiten festgelegt.
Des Weiteren wurden im englischsprachigen Raum die Begriffe Employer’s Informa-
tion Requirement (EIR) und BIM Execution Plan (BEP) geprägt. Dabei handelt es sich
um Dokumente, die vom Auftraggeber bzw. Auftragnehmer ausgearbeitet werden und
Bestandteil der vertraglichen Vereinbarungen sind. Im EIR legt der Auftraggeber im Rah-
men der Ausschreibung fest, welche Ziele mit der Nutzung von BIM verfolgt werden
und auf welche Weise die digitale Projektabwicklung umgesetzt werden soll (BIM Task
Group 2013). Dabei werden detaillierte Festlegungen zu Verantwortlichkeiten, Übergabe-
zeitpunkten, verwendeter Software und einzusetzender Datenaustauschformate getroffen.
Zur Beschreibung der Modellinhalte wird auf klar definierte Modell-Ausarbeitungsgrade
verwiesen, die in den verschiedenen Richtlinien mit den Begriffen Level of Development,
Level of Detail oder Level of Model Definition bezeichnet werden.
Im BEP beschreibt der potenzielle Auftragnehmer, wie er die Anforderungen des EIR
umsetzen möchte. Erhält der Bieter den Zuschlag für den Auftrag wird ein zweites, de-
tailliertes BEP aufgesetzt. Sowohl EIR als auch BEP werden immer projektspezifisch
ausgearbeitet. Von verschiedenen Institutionen werden entsprechende Vorlagen zur Verfü-
gung gestellt (AEC UK 2012b; Richards et al. 2013; Construction Industry Council 2013;
PennState 2011).
12 A. Borrmann et al.
Mit der Abwicklung von BIM-Projekten entstehen vielfältige neue Aufgaben in Bezug auf
die Verwaltung digitaler Bauwerksmodelle und der Koordination der Informationsflüsse.
Damit entstehen auch neue Rollen und damit in letzter Konsequenz neue Berufsbilder. Der
BIM-Leitfaden für Deutschland definiert in diesem Zusammenhang die Rollen des BIM-
Managers und des BIM-Koordinators (Abb. 1.7) (Egger et al. 2013).
Aufgabe des BIM-Managers ist es, eine Strategie für die Qualitätssicherung im Ge-
samtprojekt auszuarbeiten und die notwendigen Arbeitsabläufe festzulegen. Der BIM-
Manager übernimmt die regelmäßige Zusammenführung der Fachmodelle und darauf auf-
bauend die Koordination der verschiedenen Planungsdisziplinen. Nach der erfolgten Prü-
fung und Kollisionsbereinigung werden die einzelnen Fachmodelle bzw. das Gesamtmo-
dell durch den BIM-Manager freigegeben und zur Dokumentation des Planungsprozesses
archiviert.
Für jede Fachdisziplin gibt es einen eigenen BIM-Koordinator. Er ist für die Qualität
des bereitzustellenden Fachmodells verantwortlich und muss die Einhaltung von BIM-
Standards und -Richtlinien, Datensicherheit und Datenqualität überwachen. Insbesondere
muss er sicherstellen, dass das Modell im vereinbarten Ausarbeitungsgrad zu jeweiligen
Meilenstein bereitgestellt wird.
Der BIM-Manager und die einzelnen BIM-Koordinatoren müssen im Laufe des Pro-
jekts eng zusammenarbeiten, insbesondere wenn sie unterschiedlichen Unternehmen an-
gehören.
Abweichend von diesen Definitionen wird die Rolle des BIM-Managers in anderen
Richtlinien häufig mit rein strategischen Aufgaben belegt, die Modellzusammenführung
und -prüfung übernimmt dagegen der BIM-Koordinator (AEC UK 2012a).
Gesamt-
projektleitung
BIM
Manager
Abb. 1.7 Aufgabenverteilung zwischen BIM-Manager und BIM-Koordinatoren (Egger et al. 2013)
1 Einführung 13
Corporate Objecves
Model Coordinaon
Drawing Producon
Process + Workflow
Content Creaon
Implementaon
Exceuon Plan
Model Audit
Standards
Modelling
Research
Training
Role
BIM Manager Y Y Y Y Y Y Y N N N N N
BIM Coordinator N N N N N Y Y Y Y Y Y N
BIM Modeler N N N N N N N N N Y Y Y
Die Richtlinien des britischen Construction Industry Council (CIC) definieren hinge-
gen die Rolle des Information Manager (CIC 2013). Er übernimmt nicht die Aufgabe der
Modellzusammenführung oder der Koordination der Gewerke, sondern ist allein für das
Festlegen und Überprüfen der Datenaustauschprozesse sowie das fristgerechte Liefern der
vereinbarten Modellinhalte und Modellqualitäten verantwortlich. Darüber hinaus betreibt
er das Common Data Environment und achtet auf dessen Integrität.
Abbildung 1.8 zeigt die Aufgabenverteilung zwischen BIM-Manager, BIM-Koordina-
tor und BIM-Modeler, wie sie vom britischen AEC BIM Protocol vorgesehen ist.
In vielen Ländern ist die Einführung der BIM-Methode bereits weit vorangeschritten. Als
Vorreiter sind hier insbesondere Singapur, Finnland, die USA, Großbritannien und Austra-
lien zu nennen. Herauszuheben ist, dass in allen genannten Ländern der Staat als größter
Auftraggeber eine Schlüsselrolle bei der Einführung von BIM einnimmt.
In Singapur gibt es bereits seit 2004 die Pflicht, Bauunterlagen für öffentliche Bau-
vorhaben über eine Internet-Plattform elektronisch einzureichen (Khemlani 2005). Dabei
müssen digitale Bauwerksmodelle im Neutralformat IFC übergeben werden. Sie werden
anschließend automatisiert auf die Einhaltung bestimmter Normen und Vorgaben, z. B.
zum Brandschutz, geprüft. Die Durchdringung der Bauwirtschaft in Singapur mit BIM
ist entsprechend weit fortgeschritten. Die BIM-Richtlinien der Building and Construction
Authority sind 2013 bereits in der zweiten Version erschienen (BCA Singapore 2013).
14 A. Borrmann et al.
In Finnland wird seit 2007 für alle von der öffentlichen Hand in Auftrag gegebenen
Bauvorhaben mit einem Volumen von über einer Million Euro die Bereitstellung eines
digitalen Gebäudemodells vorgeschrieben (Senate Properties 2007). Inzwischen konnten
umfangreiche Erfahrungen in der Abwicklung von BIM-Projekten gesammelt werden.
Diese haben Eingang gefunden in die Richtliniensammlung „Common BIM Require-
ments“, die 2012 veröffentlicht wurde (RTS 2012). Die finnischen Richtlinien setzen sehr
stark auf offene Datenaustauschformate wie die IFC.
In den USA verlangen große staatliche Auftraggeber wie die General Service Ad-
ministration (GSA) und das US Army Corps of Engineers (USACE) ebenfalls bereits
seit mehreren Jahren die Übergabe von BIM-Modellen (GSA 2007). Die amerikanischen
Gaststreitkräfte haben auch für ihre Neubauten in Deutschland mit der Einführung von
BIM begonnen und die USACE BIM-Richtlinie für Deutschland erstellen lassen (Haus-
knecht und Liebich 2011). Aber auch von privaten Auftraggebern wird zunehmend eine
BIM-gestützte Projektabwicklung verlangt. Mit dem National BIM Standard wurde vom
National Institute of Building Sciences (NIBS) ein Dokument veröffentlicht, das eine gan-
ze Reihe von anderweitig definierten Standards zu BIM bündelt, u. a. zu den Datenforma-
ten IFC und COBie, aber auch zur formalen Spezifikation von Datenaustauschprozessen
(NIBS 2012). Darüber hinaus gibt es in den USA BIM-Richtlinien bis zu den unteren
staatlichen Verwaltungsebenen – als Beispiel seien die BIM-Richtlinien von New York
City genannt (NYC DDC 2012). Eine wichtige Rolle bei der praktischen Umsetzung
von BIM nimmt das American Institute of Architects (AIA) ein. Es stellt beispielsweise
Vorlagen für vertragliche Vereinbarungen in BIM-Projekten zur Verfügung und hat insbe-
sondere detaillierte Spezifikationen zur Beschreibung des Ausarbeitungsgrades (Level of
Development) eines Modells verabschiedet (AIA 2013).
Besonders bemerkenswert ist die BIM-Strategie der britischen Regierung, die 2007
ins Leben gerufen wurde und deren erklärtes Ziel es ist, mithilfe digitaler Technologi-
en eine Kostenreduzierung von 15 % bis 20 % und eine Reduktion der Treibhausgase um
50 % zu erzielen (Cabinet Office 2011). Zudem soll die britische Bauindustrie mit der
breiten Einführung von BIM auf ein neues technologisches Niveau gehoben werden, so-
dass ihr signifikante Wettbewerbsvorteile auf dem internationalen Markt entstehen. Ab
April 2016 soll für alle öffentlichen Bauvorhaben BIM Level 2 verbindlich vorgeschrie-
ben werden. Zur Umsetzung dieses ambitionierten Ziels wurde eine BIM Task Group
eingesetzt, die in umfassender Weise die Erarbeitung der notwendigen Richtlinien und
Standards koordiniert (BIM Task Group 2011). Eines der Schlüsseldokumente ist die
von der British Standards Institution (BSI) herausgegebene, öffentlich verfügbare Spe-
zifikation (Publicly Available Specification) PAS 1192-2 „Specification for information
management for the capital/delivery phase of construction projects using building in-
formation modelling“. Darin werden die grundlegenden Abläufe in einem BIM-Projekt
festgelegt und insbesondere sogenannte Data Drops spezifiziert, bei denen zu bestimmten
Zeitpunkten Projektdaten an den Bauherrn übergeben werden. Die PAS bleibt dabei auf
einem weitgehend generischen Niveau und überlässt Details der Modellinhalte und Aus-
arbeitungsgrade dem zwischen Auftraggeber und Auftragnehmer zu vereinbarenden BIM
1 Einführung 15
Im Vergleich mit anderen europäischen Ländern ist die verbindliche Einführung von BIM
in Deutschland noch nicht sehr weit fortgeschritten. Zwar gibt es eine Reihe von inno-
vativen Unternehmen, die BIM bereits erfolgreich einsetzen, dies jedoch vornehmlich für
Projekte im Ausland. In Deutschland fehlt es bislang an dringend benötigten Vorgaben
und Richtlinien für die Abwicklung von BIM-Projekten. In jüngerer Zeit konnten aber
verstärkt Aktivitäten in dieser Richtung verzeichnet werden.
Bereits 2010 wurde der BIM-Beirat unter dem Vorsitz des Bundesministeriums für Ver-
kehr, Bau und Stadtentwicklung mit dem Ziel gegründet, den Umstieg auf BIM-gestützte
Planungsverfahren in Deutschland vorzubereiten. Er dient vornehmlich als Diskussions-
plattform zur Abstimmung zwischen den betroffenen Verbänden und Interessengruppen.
Die Reformkommission Bau von Großprojekten, die im Auftrag der Bundesregierung
Vorschläge für eine zuverlässigere Abwicklung von großen Bauvorhaben erarbeitet, hat
in ihrem Zwischenbericht die Nutzung von BIM empfohlen, um zukünftig Großprojek-
16 A. Borrmann et al.
1.5 Zusammenfassung
Building Information Modeling basiert auf der durchgängigen Nutzung eines digitalen
Gebäudemodells über den gesamten Lebenszyklus eines Bauwerks. Das Modell beinhal-
tet dabei neben der 3D-Geometrie der Bauteile und Räume auch umfängliche Zusatz-
informationen, u. a. zum Material, zur Funktion der Bauteile und zu ihren wechselseiti-
gen Beziehungen. Dies ermöglicht einen hochwertigen Datenaustausch und eine optimale
Weiterverwendung einmal erfasster digitaler Informationen. Durch die vielfältige Anwen-
dung digitaler Prüf- und Analysewerkzeuge werden Planungsfehler vermieden und eine
Erhöhung der Effizienz in Planung, Ausführung und Betrieb erzielt.
Dank der Verfügbarkeit von modernen Softwarewerkzeugen steht der Umsetzung der
BIM-Methode in der Planungspraxis aus technischer Sicht heute nichts mehr im Wege.
Für eine erfolgreiche Abwicklung von BIM-Projekten ist jedoch eine detaillierte Festle-
gung der Arbeitsabläufe und Verantwortlichkeiten erforderlich, insbesondere hinsichtlich
der zu liefernden Modellinhalte und Modellqualitäten. Eine BIM-Richtlinie bildet in der
Regel die Basis derartiger Festlegungen.
International ist die Einführung von BIM zum Teil schon sehr weit vorangeschritten.
Besonders herausstechend ist die britische BIM-Initiative, die eine verbindliche Nutzung
der BIM-Methodik ab April 2016 für alle öffentlichen Bauvorhaben vorsieht und bereits
in umfassender Weise BIM-Normen und Richtlinien erarbeitet hat.
In Deutschland setzen zwar einzelne, besonders innovative Planungsbüros und Bau-
firmen BIM bereits erfolgreich ein. Die flächendeckende Einführung steht jedoch noch
aus. Insbesondere sind die Ausarbeitung einer BIM-Richtlinie, die Bereitstellung entspre-
18 A. Borrmann et al.
chender Ausschreibungs- und Vertragsvorlagen und Anpassungen bei der Vergütung von
Planungsleistungen erforderlich. Die Entwicklungen der jüngeren Zeit, wie die Gründung
der planen-bauen 4.0 GmbH als deutsche BIM Task Group, lassen erwarten, dass diese
Aufgaben in naher Zukunft angegangen werden.
Das vorliegende Buch vermittelt die methodischen und technischen Grundlagen des Buil-
dings Information Modeling. Diese Kenntnisse sind nach Auffassung der Herausgeber
notwendig, um ein vertieftes Verständnis der BIM-Methodik aufbauen und diese richtig
anwenden zu können. Das Buch komplementiert die methodischen Grundlagen mit Erfah-
rungen aus der Praxis und lässt eine Reihe von Unternehmen zu Wort kommen, in denen
BIM bereits erfolgreich eingesetzt wird.
Das Buch richtet sich sowohl an das interessierte Fachpublikum aus allen Bereichen
des Bauwesens als auch an Studierende der Fachrichtungen Architektur und Bauinge-
nieurwesen.
Der Inhalt ist in 6 Teile gegliedert.
Teil 1 beschreibt die Grundlagen der BIM-Technologien und geht dabei insbesondere
auf die geometrische und die objektorientierte Modellierung von Gebäuden sowie die
Prozessmodellierung ein.
Teil 2 behandelt den wichtigen Aspekt der Interoperabilität von Softwareprodukten und
stellt u. a. im Detail das herstellerneutrale Datenaustauschformat „Industry Foundation
Classes“ vor, beleuchtet die verschiedenen Klassifizierungssysteme im Bauwesen und
geht auf das Datenformat CityGML zur Modellierung von 3D-Stadtmodellen ein.
Teil 3 befasst sich mit der Philosophie, der Organisation und der technischen Umset-
zung der BIM-gestützten Zusammenarbeit und behandelt dabei die Rolle des BIM-
Managers ebenso wie die Auswirkungen auf das Bauvertragsrecht.
Teil 4 widmet sich dem breiten Spektrum der Nutzung von BIM in den verschiedenen
Phasen des Lebenszyklus eines Gebäudes, angefangen beim architektonischen Entwurf
über die Energiebedarfsermittlung, die baustatische Berechnung und die Mengener-
mittlung bis hin zur Nutzung für Navigation und Brandschutz.
In Teil 5 berichtet eine Vielzahl von Autoren aus Architekturbüros, Planungsbüros und
Baufirmen über den aktuellen Stand der Einführung von BIM-Technologie in ihrem
Unternehmen und geht dabei auf Herausforderungen beim Umstieg und die noch ver-
bleibenden Probleme ein.
Schließlich fasst Teil 6 die Inhalte des Buchs zusammen und gibt einen Ausblick auf
zukünftige Entwicklungen.
1 Einführung 19
Literatur
Verwendete Literatur
AEC UK (2012a): AEC (UK) BIM Protocol V2.0, AEC (UK) CAD & BIM Standards, Verfügbar
unter: https://aecuk.wordpress.com/documents/ Zugegriffen: 7.2.2015
AEC UK (2012b): AEC (UK) BIM Protocol – BIM Execution Plan V 2.0, AEC (UK) CAD & BIM
Standards, https://aecuk.wordpress.com/documents/ Zugegriffen: 7.2.2015
AIA (2013) AIA Contract Document G202-2013, Building Information Modeling Protocol Form,
American Institute of Architects, Washington DC, USA
Austrian Standards (2015): Building Information Modeling, https://www.austrian-standards.
at/infopedia-themencenter/infopedia-artikel/building-information-modeling-bim/ Zugegriffen:
7.2.2015
Autodesk (2003). Building Information Modeling. San Rafael, CA, Autodesk, Inc, http://www.
laiserin.com/features/bim/autodesk_bim.pdf Zugegriffen: 7.2.2015
BCA Singapore (2013): Singapore BIM Guide V2, Building and Construction Authority, Singapur,
https://www.corenet.gov.sg/integrated_submission/bim/BIM_Guide.htm Zugegriffen: 7.2.2015
Bew, M., and Richards, M., (2008): BIM Maturity Model, UK Government Construction Cli-
ent Group (GCCG) report, London, Großbritannien, http://www.bimtaskgroup.org/wp-content/
uploads/2012/03/BIS-BIM-strategy-Report.pdf Zugegriffen: 8.6.2015
BIM Alliance (2015): BIM Alliance Sweden Website, http://www.bimalliance.se Zugegriffen:
7.2.2015
BIM Task Group (2011): Building Information Modelling (BIM) Working Party Strategy Paper,
A report for the Government Construction Client Group, http://www.bimtaskgroup.org/wp-
content/uploads/2012/03/BIS-BIM-strategy-Report.pdf Zugegriffen: 7.2.2015
BIM Task Group (2013): Employer’s Information Requirements, Version 07, http://www.
bimtaskgroup.org/bim-eirs/ Zugegriffen: 7.2.2015
BMVI (2014): Zwischenbericht der Reformkommission Bau von Großprojekten, Bundesministe-
rium für Verkehr und Digitale Infrastruktur. http://www.bmvi.de/SharedDocs/DE/Artikel/UI/
reformkommission-bau-von-grossprojekten.html Zugegriffen: 7.2.2015
British Standard Institution (2013): PAS 1192-2:2013 Specification for information management
for the capital/delivery phase of construction projects using building information modelling,
The British Standards Institution, London, Großbritannien
Cabinet Office (2011): Government Construction Strategy, Cabinet Office, London, Großbrit-
tanien, https://www.gov.uk/government/publications/government-construction-strategy Zuge-
griffen: 7.2.2015
CIC (2013): Building Information Model (BIM) Protocol – Standard Protocol for use in projects
using Building Information Models, Construction Industry Council, Großbritannien, http://
www.bimtaskgroup.org/bim-protocol/ Zugegriffen: 7.2.2015
Eastman, Charles; Fisher, David; Lafue, Gilles; Lividini, Joseph; Stoker, Douglas; Yessios, Chri-
stos (September 1974). An Outline of the Building Description System. Institute of Physical
Planning, Carnegie-Mellon University. http://eric.ed.gov/?id=ED113833 Zugegriffen: 7.2.2015
Egger, M., Hausknecht, K., Liebich, T., Przybylo, J. (2013): BIM-Leitfaden für Deutschland. Ab-
schlussbericht. Bundesinstitut für Bau-, Stadt- und Raumforschung (BBSR), http://www.bbsr.
bund.de/BBSR/DE/FP/ZB/Auftragsforschung/3Rahmenbedingungen/2013/BIMLeitfaden/01_
start.html Zugegriffen: 7.2.2015
20 A. Borrmann et al.
Zusammenfassung
Eine der wichtigsten Voraussetzungen für das Building Information Modeling ist die
Arbeit mit dreidimensionaler Geometrie. Dieses Kapitel geht auf die Grundlagen der
Abbildung von Geometrie im Rechner ein. Dabei werden explizite und implizite Ver-
fahren zur Beschreibung von Volumenmodellen ebenso behandelt wie die Grundlagen
der parametrischen Modellierung zur Schaffung flexibler, leicht anpassbarer Modelle.
Ein weiterer Schwerpunkt des Kapitels liegt auf Freiformkurven und -flächen und der
ihnen zugrundeliegenden mathematischen Beschreibung.
Ein Building Information Model beinhaltet alle für die Planung, den Bau und den Betrieb
eines Gebäudes relevanten Informationen. Die dreidimensionale Gebäudegeometrie zählt
dabei zu den wichtigsten Informationen, ohne viele der BIM-Anwendungen nicht mög-
lich wären. Die Verfügbarkeit eines 3D-Modells bietet wesentliche Vorteile gegenüber der
konventionellen zeichnungsgestützten Planung:
Die Planung und Konstruktion wird grundsätzlich am 3D-Modell und nicht an einzel-
nen Grundrissen und Schnitten durchgeführt. Die entsprechenden Zeichnungen werden
André Borrmann
Technische Universität München, Lehrstuhl für Computergestützte Modellierung und Simulation,
Arcisstr. 21, 80333 München, Deutschland
e-mail: andre.borrmann@tum.de
Volker Berkhahn
Leibniz Universität Hannover, Institut für Bauinformatik, Callinstr. 34,
30167 Hannover, Deutschland
e-mail: berkhahn@bauinf.uni-hannover.de
aus dem 3D-Modell abgeleitet. Auf diese Weise kann sichergestellt werden, dass die
abgeleiteten Pläne zueinander passen, d. h. untereinander konsistent sind. Damit wer-
den Fehlerquellen beim Erstellen und vor allem bei Änderungen deutlich reduziert.
Ein reines geometrisches Modell reicht für die Generierung normgerechter Pläne aller-
dings nicht aus. Darüber hinaus sind semantische Zusatzinformationen beispielsweise
zum Bauteiltyp oder zum Material erforderlich, da Baupläne zu großen Teilen die Ver-
wendung von symbolhaften bzw. vereinfachten Darstellungen vorsehen, die nicht aus
der reinen 3D-Geometrie gewonnen werden können.
Mithilfe des 3D-Modells ist das Durchführen von Kollisionsanalysen möglich. Dabei
wird getestet, ob das Modell (bzw. seine Teilmodelle) Bauteile enthält, deren Geome-
trie sich überlagert. Dies deutet in der Regel auf einen Fehler bzw. ein Versäumnis
in der Planung hin. Das Erkennen derartiger Kollisionen ist besonders wichtig für die
Koordination der gewerkeübergreifenden Zusammenarbeit, wie sie beispielsweise bei
der Durchbruchplanung für die technische Gebäudeausrüstung erforderlich ist (siehe
Kap. 16).
Ein 3D-Modell erlaubt eine präzise Mengenermittlung (engl. Quantity Take-Off), da
Volumen und Oberflächen direkt berechnet werden können. Für die normgerechte Men-
genermittlung sind jedoch zusätzlich Sonderregelungen („Übermessen“ etc.) zu be-
rücksichtigen (siehe Kap. 21).
Die Verfügbarkeit von 3D-Geometrie hat eine besondere Bedeutung für den Anschluss
von Berechnungs- und Simulationsverfahren (siehe Kap. 17 und 18). Das dafür not-
wendig mechanische bzw. physikalische Modell kann häufig direkt aus dem geome-
trischen Modell abgeleitet werden. Die bislang übliche, sehr aufwendige und fehler-
anfällige erneute Eingabe von geometrischen Daten kann damit entfallen. Bei vielen
Simulationsverfahren sind jedoch Vereinfachungen bzw. Umformungen sinnvoll und
notwendig. So wird beispielsweise in der baustatischen Berechnung vielfach mit di-
mensionsreduzierten Modellen gerechnet.
Das 3D-Modell erlaubt eine photorealistische Visualisierung des Gebäudeentwurfs
(engl. Rendering), einschließlich der Berechnung des Schattenwurfs und von Spie-
gelungseffekten (vgl. Abb. 2.1). Dies ist besonders für die Kommunikation mit dem
Bauherrn von Bedeutung, dient entwerfenden Architekten aber auch zur Prüfung der
Raumwirkung und der Beleuchtungssituation. Für die Visualiserungs-Berechnung sind
neben der 3D-Geometrie Informationen zu den Materialien und zur Oberflächenbe-
schaffenheit notwendig.
Die Abbildung von dreidimensionaler Geometrie im Rechner bildet somit eine der
wichtigsten Grundlagen für das Building Information Modeling. Um die Fähigkeiten von
Modellierungstools und Austauschformaten einschätzen zu können, ist es notwendig, die
Grundlagen der rechnergestützten geometrischen Modellierung zu kennen, die in die-
sem Kapitel überblicksartig behandelt werden. Dabei wird zunächst auf die verschiede-
nen Ansätze zur Beschreibung dreidimensionaler Geometrie im Computer eingegangen.
Dies wird ergänzt um Verfahren zur parametrischen Modellierung, mit deren Hilfe flexi-
2 Grundlagen der geometrischen Modellierung 27
Abb. 2.1 Ein 3D-Modell bildet die Grundlage für das Rendering, also dem Erzeugen fotorea-
listischer Visualisierungen des Gebäudemodells. (Abbildung mit freundlicher Genehmigung von
Cornelius Preidel)
ble Geometrien erzeugt werden, die schnell auf veränderte Randbedingungen angepasst
werden können. Schließlich wird die Modellierung von Freiformkurven und -flächen be-
handelt, da diese zunehmend im Bauwesen an Bedeutung gewinnen.
Wesentlich für die Fähigkeiten eines BIM-Modellierwerkzeugs sind die Fähigkeiten
des eingesetzten Geometrie-Kernels. Dabei handelt es sich um einen Softwarebaustein,
der elementare Datenstrukturen und Operationen zur Repräsentation und Verarbeitung
geometrischer Informationen zur Verfügung stellt. Häufig werden Geometrie-Kernels über
verschiedene Softwareprodukte hinweg eingesetzt und mitunter sogar an andere Software-
hersteller lizensiert. Typische Beispiele für sehr weit verbreitete Geometrie-Kernel sind
ACIS (Spatial 2015) und ParaSolid (Siemens 2015).
Zur Modellierung der Geometrie von Körpern gibt es zwei grundlegend verschiedene An-
sätze: Die expliziten Verfahren beschreiben einen Körper über seine Oberfläche. Sie wer-
den daher häufig als Randdarstellungsverfahren (engl. Boundary Representation, BRep)
bezeichnet. Die impliziten Verfahren basieren hingegen darauf, dass eine Folge von Kon-
struktionschritten zur Beschreibung des Körpers aufgezeichnet wird. Sie werden daher
häufig als prozedurale Verfahren bezeichnet. Beide methodischen Ansätze kommen im
Bereich der BIM-Software und den entsprechenden Datenaustauschformaten zum Einsatz
28 A. Borrmann und V. Berkhahn
und sind beispielsweise in der IFC-Spezifikation enthalten (siehe Kap. 6). Sie werden im
folgenden im Detail beschrieben.
v4
f1 f2 f3 f4
e5
e6 e4
e1 e2 e3 e4 e5 e6
v1 e3 v3 v1 v2 v3 v4
e2
e1
v2
Abb. 2.2 Eine einfache BRep-Datenstruktur gefüllt mit Daten zur Beschreibung einer Pyramide.
Der Vertex-Edge-Face-Graph beschreibt die Beziehungen zwischen Knoten, Kanten und Flächen
und damit die Topologie des Körpers
Topology
Eine weitere Besonderheit liegt darin, dass die Kantenzüge nicht direkt auf Kanten
verweisen, sondern auf sogenannte CoEdges, die eine zur jeweiligen Fläche konsistente
Orientierung aufweisen. Diese sind dann mit der eigentlichen Kante (Edge) verknüpft, die
auf den Anfangs- und Endknoten verweist. Der untere Teil der Abbildung zeigt die geo-
metrischen Informationen, die mit Flächen, Kanten und Knoten assoziiert werden können.
30 A. Borrmann und V. Berkhahn
Das sich ergebende Datenmodell ist äußerst mächtig, d. h. es können nahezu beliebige
Körper beschrieben werden. Es wird direkt im ACIS-Austauschformat umgesetzt, das von
einigen BIM-Systemen unterstützt wird, und kommt in leicht abgewandelter Form auch
im IFC-Datenmodell zum Einsatz (siehe Kap. 6).
Triangulierte Oberflächenbeschreibung
Eine stark vereinfachte Variante der Boundary Representation besteht darin, die Ober-
fläche eines Körpers mithilfe eines Dreiecksnetzes zu beschreiben. Gekrümmte Flächen
können dabei nicht präzise beschrieben, aber durch eine Verfeinerung des Netzes mit der
gewünschten Genauigkeit angenähert werden. Die dreiecksnetzbasierte Beschreibung von
Körpern kommt häufig bei visualisierungsnahen Anwendungen zum Einsatz, aber auch
beispielsweise bei der Beschreibung der Geländeoberfläche (siehe Abb. 2.4) oder als Ein-
gangsgröße für numerische Berechnungen und Simulationen. Nicht zu vernachlässigen ist
der deutlich erhöhte Speicheraufwand bei der Beschreibung gekrümmter Oberflächen im
Vergleich mit einer analytischen Beschreibung (Abschn. 2.4).
Als zugrundeliegende Datenstruktur wird häufig das sogenannte Indexed Face Set ver-
wendet. Dabei werden die Koordinaten der Eckpunkte in einer geordneten und numme-
rierten (indizierten) Liste gespeichert. Für die Definition der Dreiecke wird dann lediglich
auf die Indizes der Punkteliste verwiesen. Auf diese Weise wird die mehrfache (red-
undante) Speicherung der Punktkoordinaten und daraus resultierende Geometriefehler
(Überlappungen, Spalten) infolge von Ungenauigkeiten vermieden.
Das Indexed Face Set ist eine Datenstruktur, die aufgrund ihrer Einfachheit sehr ro-
bust und schnell interpretierbar ist. Sie wird unter anderem von den reinen Geometrie-
Formaten VRML, X3D und JT eingesetzt, aber auch vom BIM-Format IFC unterstützt
(siehe Kap. 6). Das ebenfalls sehr weit verbreitete Geometrie-Format STL basiert eben-
falls auf einer triangulierten Beschreibung von Körpern. Die verwendete Datenstruktur
beruht aber im Unterschied zum Indexed Face Set auf einer expliziten Angabe der Koor-
dinaten für jedes einzelne Dreieck, was zu größerem Speicherbedarf führt. Bedingt durch
die fehlende Topologieinformation im STL-Format besteht die Gefahr, dass die abgelegte
Geometrie fehlerhaft ist, d. h. Lücken oder Überlappungen zwischen den einzelnen Drei-
ecken auftreten.
Abb. 2.4 Digitale Geländemodelle werden in der Regel mithilfe eines triangulierten Oberflächen-
netzes beschrieben
Primitive Resultat
von komplexen dreidimensionalen Objekten. Im BIM-Bereich spielt vor allem die Defi-
nition von Abzugskörpern zur Modellierung von Aussparungen und Durchbrüchen eine
wichtige Rolle.
In Hinblick auf den Datenaustausch haben implizite Verfahren eine Reihe von Vorteilen
gegenüber expliziten Repräsentationen, darunter die Nachvollziehbarkeit der Modellie-
rungsschritte, die einfache Modifizierbarkeit der übertragenen Geometrie (durch Editieren
der Konstruktonsschritte) auf der Empfängerseite sowie einen deutlich geringeren Um-
fang an zu übermittelnden Daten. Ein wesentliches Problem der Nutzung einer impliziter
Beschreibung beim Datenaustausch liegt jedoch darin, dass vom Zielsystem alle vom
Ausgangssystem verwendeten Operationen zur Geometrieerzeugung und -bearbeitung un-
terstützt und in gleicher Weise ausgeführt werden müssen. Dies führt zu einer enormen
Erhöhung der Komplexität bei der Implementierung einer entsprechenden Schnittstelle
durch die Softwarehersteller.
Das Editieren von Konstruktionsschritten erfordert bei den impliziten Verfahren immer
eine automatisierte Rekonstruktion des Bauteils. Auch wenn hierbei in der Regel keine
manuelle Interaktion durch den Anwender erforderlich ist, so kann dieser Prozess bei
komplexen Bauteilen sehr rechenintensiv sein. Darüber hinaus kann es vorkommen, dass
durch das Editieren eines Konstruktionsschritts die folgenden Konstruktionsschritte nicht
fehlerfrei durchgeführt werden können und ebenfalls editiert werden müssen.
Bei den expliziten Repräsentationen ist das direkte Editieren der Geometrie möglich.
Hierdurch wird beispielsweise ein zielgerichtetes Manipulieren von Kontrollpunkten er-
möglicht, um Stetigkeitsbedingungen zwischen Flächen zu erfüllen oder um Flächenver-
läufe an die jeweiligen Anforderungen anzupassen.
34 A. Borrmann und V. Berkhahn
Ein äußerst wichtiger Trend im Bauwesen ist die parametrische Modellierung, die es
erlaubt, geometrische Modelle so mit Abhängigkeiten und Zwangsbedingungen zu ver-
sehen, dass ein flexibles Modell entsteht, dass schnell und aufwandsarm an veränderte
Randbedingungen angepasst werden kann.
Als Parameter können dabei die Abmessungen geometrischer Objekte verwendet wer-
den, also beispielsweise die Höhe, Breite, Länge, Position und Ausrichtung eines Quaders.
Zwischen den Parametern können mithilfe von frei definierbaren Formeln Abhängigkei-
ten definieren werden. Auf diese Weise kann zum Beispiel erzwungen werden, dass alle
Wände einer Etage die gleiche Höhe wie das zugehörige Geschoss haben. Beim Ändern
der Höhe des Geschosses werden dann alle anderen Wände automatisch angepasst.
Das Konzept parametrischer CAD-Systeme kommt aus dem Bereich des Maschi-
nenbaus und wurde dort bereits in den 1990er-Jahren eingeführt. Diese Systeme setzen
meist eine Herangehensweise um, die auf dem Einsatz parametrisierter Skizzen be-
ruht. Dabei legt der Nutzer zunächst eine 2D-Zeichnung (die Skizze) an, die alle
gewünschten geometrischen Elemente enthält und grob den endgültigen Abmessungen
entspricht. Anschließend werden diese geometrischen Elemente mit Zwangsbedingun-
gen (engl. Constraints) versehen. Dabei wird zwischen geometrischen Constraints und
Abmessungs-Constraints (engl. dimensional constraints) unterschieden (Abb. 2.7). Mit-
hilfe von geometrischen Constraints kann beispielsweise erzwungen werden, dass sich
zwei Linien in ihren Endpunkten berühren, dass sie senkrecht aufeinander stehen oder
dass sie parallel zueinander liegen. Abmessungs-Constraints beziehen sich hingegen auf
rein geometrische Informationen wie Längen, Distanzen und Winkel. Sie erlauben die
Angabe von Formeln, um das Verhältnis verschiedener Parameter zueinander festzulegen
(Abb. 2.8 ). Die auf diese Weise parametrisierte Skizze dient im nächsten Schritt als
Grundlage für Extrusions- oder Rotationsoperationen, wodurch ein entsprechend para-
metrisierter dreidimensionaler Körper entsteht. Auf diese Weise erzeugte Körper können
anschließend mithilfe von CSG-Operationen miteinander kombiniert werden. In einer
weitergehenden Funktionalität können sogenannte Features wie beispielsweise Abkan-
tungen oder Bohrlöcher auf die entstehenden Körper angewendet werden. Diese Features
bündeln eine Reihe von Geometrieoperationen und besitzen entsprechende Parameter, um
diese zu steuern.
Die Kombination von parametrisierten Skizzen und prozeduraler Geometriebeschrei-
bung ergibt einen äußerst mächtigen Mechanismus zur Definition flexibler 3D-Modelle,
der dem Nutzer sehr große Freiräume und gleichzeitig präzise Kontrolle über das erzeugte
Modell einräumt.
Diese Form der parametrischen Modellierung wird bislang nicht von BIM-Produkten
angeboten, sondern lediglich von reinen 3D-Modellierern ohne Unterstützung für das se-
mantische Modellieren, darunter beispielsweise SolidWorks, CATIA und Siemens NX.
Eine Ausnahme bildet hierbei Digital Project von Gehry Technologies, bei dem ein vollpa-
2 Grundlagen der geometrischen Modellierung 35
Abb. 2.8 a Mithilfe des Parameter-Managers ist es möglich, über die Angabe von Formeln das
Verhältnis verschiedener Parameter zueinander festzulegen. Im hier gezeigten Beispiel sorgt die
Parameter-Bedingung dafür, dass Rechteck und Kreis immer den gleichen Flächeninhalt besitzen.
b Eine parametrische Skizze mit den definierten geometrischen und Abmessungs-Randbedingungen
Abb. 2.9 Bei der Definition einer Bauteilfamilie in Revit können Abmessungen mit Parametern
verknüpft werden
Bei der Erstellung des Gebäudemodells selbst können keine neuen Parameter definiert
werden, sondern nur auf diejenigen zurückgegriffen werden, die für die Familien bzw. für
das Projekt definiert wurden. Allerdings können folgende Constraints angewendet werden,
um Bauteile auszurichten:
Körper mit geraden Kanten und Flächen lassen sich recht einfach durch die Boundary-
Representation-Methode (BRep-Methode) darstellen. Für den konzeptionellen Entwurf
architektonisch anspruchsvoller, moderner Gebäude ist darüber hinaus jedoch bei die Mo-
dellierung von beliebig gekrümmten Kurven und Flächen erforderlich. Diese gekrümm-
ten Geometrien werden als Freiformkurven und -flächen bezeichnet. Freiformgeometrien
werden durch eine parametrische Formulierung dargestellt, die gegenüber approximieren-
den Darstellungen (z. B. Approximation mit Polygonen oder Dreiecken) eine sehr genaue
Darstellung der zu modellierenden Kurve oder Fläche ermöglichen. Darüber hinaus ist
das erforderliche Datenvolumen für Freiformgeometrien in parametrischer Formulierung
deutlich geringer als bei approximierenden Darstellungen.
Im Folgenden werden zunächst Verfahren zur Beschreibung gekrümmter Kurven vor-
gestellt werden, um im zweiten Schritt die Darstellung gekrümmter Flächen zu behandeln.
2.4.1 Freiform-Kurven
Freiform-Kurven werden auch als Splines bezeichnet. Dabei handelt es sich um eine
Kurve, die stückweise aus Polynomen zusammengesetzt ist. Um die Glattheit der resul-
tierenden Kurve zu gewährleisten, müssen an den Nahtstellen der Segmente bestimmte
Stetigkeitsbedingungen eingehalten. Dabei werden drei verschiedene Stufen unterschie-
den, die als C 0 -, C 1 - und C 2 -Stetigkeit bezeichnet werden (vgl. Abb. 2.10):
Krümmungsstetikeit - C1
den. Das Verschieben eines Kontrollpunkts wirkt sich auf den Verlauf der Kurve aus.
Dadurch kann dieser intuitiv vom Nutzer gesteuert werden. Die Kontrollpunkte spannen
das charakteristische Polygon auf, dessen erster und letzter Schenkel die Tangente der
Kurve im Anfangs- und Endpunkt bestimmt (Abb. 2.11).
Mathematisch sind alle drei Kurventypen als Summe der Multiplikation von Kontroll-
punkten mit Basisfunktionen definiert. Diese Basisfunktionen unterscheiden sich für die
drei Kurventypen. Da sie das Herz der jeweiligen Kurvenbeschreibung bilden, sollen sie
im folgenden kurz vorgestellt werden.
Bézier-Kurven. Bei Bézier-Kurven werden die Basisfunktionen durch die sogenannten
Bernstein-Polynome gebildet. Der Grad p der entstehenden Kurve ist fest gekoppelt mit
der Anzahl der Kontrollpunkte n und es gilt p D n 1. Dadurch kann sich bei sehr vielen
Kontrollpunkten ein extrem hochgradiges Polynom ergeben. Ein weiterer Nachteil liegt
darin, dass der Einfluss des Verschiebens eines Kontrollpunkts nicht lokal begrenzt bleibt,
sondern sich auf die gesamte Kurve erstreckt.
BSplines. BSplines wurden entwickelt, um die oben genannten Einschränkungen der
Bézier-Kurven zu überwinden. Der wesentliche Vorteil liegt darin, dass bei BSplines der
Grad der Kurve weitgehend unabhängig von der Anzahl der Kontrollpunkte gewählt wer-
den kann. Es muss lediglich die untere Schranke p < n eingehalten werden. Auf diese
P0 P3
2 Grundlagen der geometrischen Modellierung 39
Weise können die Vorteile eines glatten Verlaufs von Polynomen geringen Grades (typi-
scherweise p = 3) mit einer beliebig hohen Zahl von Kontrollpunkten kombiniert werden.
Umgesetzt wird dies, indem ein BSpline stückweise aus Polynomen des gewählten Grades
zusammengesetzt wird, wobei an den Nahtstellen die Stetigkeit c D p 1 gilt. Grundlage
dafür bilden ein hierarchischen Basisfunktionen, die rekursiv definiert sind.
NURBS. Die Non-Uniform Rational BSplines (NURBS) basieren auf BSplines, er-
lauben es aber darüber hinaus, jedem Kontrollpunkt ein Gewicht zuzuweisen. Dadurch
kann der Verlauf der Kurve zusätzlich beeinflusst werden. Dies ist notwendig, um regu-
läre Kegelschnitte (Kreise, Ellipse, Hyperbeln) exakt abzubilden. NURBS-Kurven bilden
aus diesem Grund heute den Standard in der Beschreibung gekrümmter Kurven und wer-
den von vielen BIM-Systemen bzw. Geometrie-Kernels umgesetzt.
2.4.2 Freiform-Flächen
Größere Flächen werden in der Regel aus einzelnen „Patches“ zusammengesetzt, denen
eine geschlossene mathematische Beschreibung zugrunde liegt. An den Nahtstellen der
Patches muss sichergestellt werden, dass entsprechende Stetigkeits-Randbedingungen ein-
gehalten werden. In der Regel wird hier C2 -Stetigkeit gefordert, das heißt ein Anschluss
ohne Änderung in der Krümmung der Oberfläche realisiert.
Das Gebiet der geometrischen Modellierung ist sehr umfangreich und konnte hier nur
oberflächlich angerissen werden. Für Leser mit tiefergehendem Interesse an dieser The-
matik empfehlen wir die folgenden Bücher:
Pottmann et al. (2010) geben einen sehr guten Überblick über die verschiedenen For-
men der Geometriemodellierung und gehen insbesondere auf die Bedeutung für den ar-
chitektonischen Entwurf ein. Mortenson (2006) ist ein Klassiker im Bereich der com-
putergestützten Geometriemodellierung, der bereits in der dritten Auflage erschienen ist.
Das Buch von Shah und Mäntylä (1995) bildet ein weiteres Standardwerk, das vor allem
auf die parametrische Modellierung eingeht und dabei ausführlich die zugrunde liegende
Mathematik und die verwendeten Datenstrukturen beschreibt. In Hinblick auf die mathe-
matische Beschreibung von Freiformflächen ist insbesondere das NURBS-Buch von Piegl
und Tiller (1997) zu empfehlen.
2.6 Zusammenfassung
Die geometrische Modellierung bildet eine wichtige Grundlagen für die digitale Gebäude-
modellierung. Die Abblidung des Gebäudes als 3D-Volumenmodell erlaubt die Ableitung
von konsistenten Schnitten und Grundrissen, das Durchführen von Kollisionsanalysen,
die automaisierte Mengenermittlung sowie den Anschluss von Berechnungs- und Simula-
tionsverfahren.
Bei der geometrischen Modellierung gibt es zwei grundlegend verschiedene Ansätze:
Bei der expliziten Geometriebeschreibung wird der Körper über seine Oberfläche be-
schrieben – das zugehörige Verfahren nennt sich Boundary Representation und bildet die
Hierarchie von Berandungsbeziehungen zwischen Körper, Fläche, Kanten und Knoten ab.
Einen Spezialfall bilden dabei rein dreiecksbasierte Oberflächenbeschreibungen. Bei den
impliziten Verfahren, die auch als prozedurale Verfahren bezeichnet werden, wird hinge-
gen die Entstehungsgeschichte des modellierten Körpers festgehalten. Typische Vertreter
sind das Verfahren der Constructive Solid Geometry sowie Extrusions- und Rotations-
verfahren. Da explizite und implizite Geometriebschreibungen jeweils spezifische Vor-
und Nachteile haben, wird von BIM-Systemen häufig ein hybrider Ansatz verfolgt, bei
dem dem Nutzer prozedurale Methoden zur Geometrieerzeugung angeboten werden und
2 Grundlagen der geometrischen Modellierung 41
Literatur
Zusammenfassung
Zur umfassenden digitalen Modellierung eines Bauwerks sind neben geometrischen
Eigenschaften auch semantische Informationen erforderlich. Hierzu zählen beispiels-
weise Angaben zum Herstellungsverfahren, zu Baustoffen und Materialen sowie zu
Nutzungseigenschaften von Räumen. Zur Beschreibung und Strukturierung dieser In-
formationen wird derzeit das objektorientierte Modellierparadigma verwendet. Dieses
Kapitel beschreibt in Vorbereitung auf nachfolgende Kapitel die wesentlichen objek-
torientierten Modellierungskonzepte, wie Objekte und Klassen, Attribute und Metho-
den, Vererbung, Assoziationen, Aggregationen und Kompositionen. Abschließend wer-
den aktuelle und künftige Herausforderungen bei der objektorientierten Modellierung
von Bauwerksinformationen zusammengefasst.
3.1 Einführung
In der Informatik versteht man unter dem Begriff Semantik die Bedeutung von Daten
oder Informationen. Beispielsweise hat eine Zufallsfolge von natürlichen Zahlen zwar
einen hohen Informationsgehalt, aber keine Bedeutung oder Semantik. Andererseits ist
einem erfahrenen Architekten oder Bauingenieur klar, dass es sich bei einer strichlierten
Linie auf einer Bauzeichnung in der Regel um eine verdeckte Bauteilkante handelt. Somit
ist die Bedeutung oder Semantik dieser Art von Information bzw. dieser Symbolik klar
definiert und bekannt.
In Bezug auf die Modellierung von Bauwerksinformationen stellt sich die Frage,
warum Informationen zur dreidimensionalen Geometrie eines Bauwerks (s. Kap. 2) nicht
Christian Koch
The University of Nottingham, Department of Civil Engineering, University Park, NG7
2RD Nottingham, Großbritannien
e-mail: christian.koch@nottingham.ac.uk
Ein reales Bauwerk steckt voller komplexer Informationen und Zusammenhänge, die wir
für unterschiedliche Aufgaben im Rechner abbilden wollen. Vor diesem Hintergrund bil-
det ein digitales Bauwerksmodell eine rechnerinterne Abstraktion dieses realen Bauwerks
und stellt damit eine vereinfachte, reduzierte Sicht auf einen relevanten Ausschnitt der Ge-
samtinformationsmenge dar. Eine komplexe Planungs-, Ausführungs- oder Bewirtschaf-
tungsaufgabe ist nur dann lösbar, wenn man sich nacheinander auf ausgewählte Aspekte
konzentrieren kann. Digitale Bauwerksmodelle ermöglichen daher einen Überblick über
ein sonst unüberschaubares, komplexes System. Mithilfe von digitalen Bauwerksmodellen
können wir Informationen und Erfahrungen im Rechner sammeln, strukturieren, analysie-
ren, Schlüsse ziehen, Vergleiche anstellen, Alternativen bewerten, Entscheidungen treffen,
Strategien entwickeln, welche für die Planung, Ausführung und Bewirtschaftung des rea-
len Bauwerks von Nutzen sind.
Im Allgemeinen unterscheidet man verschiedene Arten von digitalen Modellen. Zum
einen existieren sogenannte Nachbildmodelle, wie zum Beispiel in der Geografie (digita-
3 Objektorientierte Modellierung 45
3.3.1 OOM-Methodik
Ziele der OOA sind die Analyse des Problemraums mit anschließender Definition von
Anforderungen an das Modell. Es wird geklärt, WAS betrachtet wird, das heißt, wel-
ches Problem eigentlich gelöst bzw. welches Naturphänomen untersucht wird und welche
Funktionalität dabei von der Software bzw. vom objektorientierten Modell erwartet wird.
In der OOD-Phase wird definiert, WIE das untersuchte Problem konzeptionell gelöst wer-
den soll. Dabei wird festgelegt, wie das Modell strukturiert ist, das heißt welche Objekte
das Modell hat, welche Beziehungen es zwischen einzelnen Modellobjekten gibt und wie
sich die Objekte verhalten. In der letzten Phase, der OOP-Phase, wird die eigentliche
Software bzw. das eigentliche Modell implementiert bzw. programmiert. Dazu wird un-
ter anderem entschieden, welche Programmiersprache zum Einsatz kommt und welche
konkreten Datenstrukturen und Algorithmen verwendet werden.
Die Unified Modeling Language (UML) ist als standardisierte Notation (ISO/IEC
19505) eine Sammlung bzw. Vereinbarung von bestimmten textuellen und grafischen
Symbolen, auf deren Basis objektorientierte Modelle im Rahmen der OOA und des OOD
mittels verschiedenster Diagrammarten formal beschrieben werden können (Oestereich
2009). Dazu wird zwischen Diagrammen zur Beschreibung
unterschieden.
Während zur formalen Beschreibung von objektorientierten Datenaustauschformaten
überwiegend Strukturdiagramme zum Einsatz kommen, werden im Rahmen des objekt-
orientierten Softwareentwurfs sowohl Struktur- als auch Verhaltensdiagramme verwendet.
Nichtsdestotrotz wirkt die Vielfalt der Beschreibungsmöglichkeiten mittels UML häufig
3 Objektorientierte Modellierung 47
erdrückend, ein tieferes Verständnis für die UML-Konstrukte in allen Facetten erfordert
demnach einigen Einarbeitungsaufwand. In einer ersten Annäherung kann man sich daher
auf die wesentlichen Elemente beschränken. Neben der UML existieren weitere Daten-
beschreibungssprachen, mit denen man objektorientierte Modelle spezifizieren und doku-
mentieren kann. An dieser Stelle sei auf das Kap. 6 verwiesen, in welchem die Sprache
EXPRESS vorgestellt wird. In diesem Kapitel dient die UML als grafische Notation zur
Veranschaulichung der zentralen objektorientierten Modellierungskonzepte.
3.3.2 OOM-Konzepte
Öffnung
Wand
Auflager
48 C. Koch
Symbole
Objekt- W1 O1 O2 A1 L1
diagramme
Abb. 3.3 Objekte des Beispielmodells. UML-Objektdiagramme (oben), gedankliche Symbole (un-
ten)
instanceOf-
Beziehung
ein Exemplar bzw. eine Instanz der Klasse Wand. Ferner ist zu erkennen, dass die Ob-
jekte O1 und 2 derselben Klasse Oeffnung zugeordnet bzw. aus dieser hervorgegangen
sind. Abbildung 3.4 veranschaulicht die UML-Klassendiagramme (oben), die Instanziie-
rungsbeziehungen (instanceOf ) (mittig) und die um den Klassennamen erweiterten UML-
Objektdiagramme (unten).
turierte oder zusammengesetzte Typen) unterschieden. Ein komplexer Typ setzt sich aus
mehreren, unterschiedlichen Typen zusammen, welche wiederum Standardtypen, Aufzäh-
lungstypen oder andere strukturierte Typen sein können. Tabelle 3.1 zeigt einige Beispiele
für Datentypen.
In Bezug auf unser Beispielmodell definieren wir unterschiedliche Attribute für die
jeweiligen Klassen und weisen den entsprechenden Objekten Attributwerte zu. Diesen
Sachverhalt veranschaulicht die Abb. 3.5 mithilfe der um Attribute erweiterten Klassen-
und Objektdiagramme. Beispielsweise hat die Klasse Oeffnung ein Attribut breite vom
Typ Gleitpunktzahl (double), welches die Werte 1.26 für das Objekt O1 und 1.01 für das
Objekt O2 annimmt. Ein Beispiel für die Verwendung des Feldtyps stellt das Attribut posi-
tion der Klasse Wand dar. Hier wird davon ausgegangen, dass die Positionskoordinaten x,
y, z des 3D-Einfügepunktes der Wand in einem Feld bzw. Array des Typs Gleitpunktzahl
(double[]) gespeichert werden sollen.
50 C. Koch
instanceOf-
Beziehung
Objekt- W1 : Wand O1 : Oeffnung A1 : Auflager L1 : Last
diagramme laenge : double = 5.74 breite : double = 1.26 typ : string = "Streifenfundament" typ : string = "Linienlast"
hoehe : double = 2.75 hoehe : double = 1.385 material : string = "Stahlbeton" wert : double = -5.0
dicke : double = 0.24 position = [2.99, 0.874] position : double = 0.0
position = [0.0, 0.0, 0.0] typ : string = "Fenster" laenge : double = 5.74
material : string = "Ortbeton"
O2 : Oeffnung
breite : double = 1.01
hoehe : double = 2.26
position = [1.49, 0.0]
typ : string = "Tür"
Vererbung
Neben den Attributen spielen die Beziehungen zwischen Objekten eine entscheidende
Rolle für die Semantik eines Objektmodells. Ein wesentliches objektorientiertes Kon-
zept zur Modellierung von Beziehungen zwischen Objekten ist die Vererbung. Verer-
3 Objektorientierte Modellierung 51
bung bedeutet, dass eine spezialisierte Klasse (auch Unter-, Kind-, oder Subklasse) über
Eigenschaften (Attribute) einer oder mehrerer allgemeiner Klassen (auch Ober- oder Su-
perklasse) verfügen kann, diese erbt. Unterklassen besitzen somit in der Regel zusätzliche
Informationen, stellen daher Spezialisierungen dar und sind von Oberklassen abgelei-
tet. Im Gegensatz dazu sind Oberklassen Generalisierungen der Unterklassen. Durch das
Konzept der Vererbung kann im objektorientierten Modell ein hierarchisches Klassifika-
tionsschema bzw. eine Taxonomie definiert werden.
Abstrakte Klassen sind Klassen, auf deren Basis keine Objekte erzeugt werden kön-
nen. Sie werden nur modelliert, um ihre Informationen an spezialisierte Klassen zu verer-
ben und sinnvolle Klassifikationshierarchien aufzubauen. Die Einfachvererbung ist eine
Vererbungsstruktur, in der jede Klasse (mit Ausnahme der Wurzelklasse) genau eine di-
rekte Oberklasse besitzt. In diesem Fall entsteht eine Baumstruktur. Im Gegensatz dazu
ist die Mehrfachvererbung eine Vererbungsstruktur, in der jede Klasse mehrere direkte
Oberklassen besitzen kann. Dabei kann es allerdings vorkommen, dass eine Subklasse von
ihren Oberklassen mehrere Attribute gleichen Namens erbt. Hier muss gesondert festge-
legt werden, welche (unterschiedliche) semantische Bedeutung jedes dieser Attribute hat
und wie diese Konflikte programmiertechnisch gelöst werden können.
In unserem Beispiel sehen wir, dass die Objekte O1 und O2 gleiche Eigenschaften
haben, sich jedoch im Hinblick auf die Art der Öffnung unterscheiden. Wie in der Abb. 3.5
dargestellt, kann dieser Sachverhalt durch ein Attribut typ modelliert werden. Allerdings
ist dann lediglich dem Objekt selbst bekannt, ob es eine Tür oder ein Fenster repräsentiert.
Das Objektmodell hingegen trägt diese semantische Information nicht. Eine wesentlich
bessere Art der Klassifizierung von Öffnungen bietet hier das Konzept der Vererbung. In
diesem Zusammenhang stellt eine Öffnung eine Generalisierung von Türen und Fenstern
dar. Folglich werden zwei neue Klassen Tuer und Fenster eingeführt, welche von der
abstrakten Oberklasse Oeffnung abgeleitet werden. Diesen Sachverhalt veranschaulicht
Abb. 3.6 (links), wobei mittels der UML eine Vererbungsbeziehung durch einen offenen
Pfeil in Richtung der Oberklasse dargestellt wird. Die eigentlichen Objekte T1 und F1
werden dann auf Basis der Unterklassen instanziiert (Abb. 3.6 links).
Ein anderes Beispiel betrifft die Modellierung und Klassifizierung von Lasten. Im Zu-
sammenhang mit Tragsicherheitsnachweisen werden im Bauwesen unterschiedliche Arten
von Lasten definiert. Ein mögliches Klassifikationskriterium stellt dabei die geometri-
sche Ausdehnung einer Last dar. Punktlasten greifen im Allgemeinen nur an einem Punkt
an, während Strecken- und Flächenlasten entsprechend entlang einer Strecke bzw. auf
einer Fläche wirken. Abbildung 3.6 (rechts) zeigt den hierarchischen Zusammenhang zwi-
schen den Klassen Last, Punktlast, Streckenlast und Flaechenlast. Kennzeichnend an
dieser Hierarchie ist, dass alle Arten von Lasten über die Eigenschaften wert und po-
sition verfügen, welche dementsprechend in der abstrakten Oberklasse Last modelliert
werden. Spezialisierungen hingegen bilden die Klassen Streckenlast mit zusätzlichem
Attribut laenge und Flaechenlast mit weiterem, zusätzlichem Attribut breite. Die Klasse
Flaechenlast ist eine Unterklasse der Klasse Streckenlast. Das eigentliche Lastobjekt in
unserem Beispiel ist ein Exemplar der Klasse Streckenlast und heißt L1.
52 C. Koch
Oeffnung Last
#breite : double #wert : double
#hoehe : double #position : double
#position : double[]
Assoziationen
Im Gegensatz zur Vererbung, welche Klassen miteinander in Beziehung setzt, modelliert
eine Assoziation Beziehungen (oder Relationen) zwischen Objekten gleichrangiger Klas-
sen. Sie ist auch zwischen Objekten derselben Klasse zulässig (reflexive Assoziation). Die
Modellierung einer Assoziation ist beispielsweise notwendig, wenn ein Objekt Informa-
tionen bzw. Daten für ein anderes Objekt zur Verfügung stellt (Datenabhängigkeit) oder
wenn ein Objekt eine bestimmte Funktionalität eines anderen Objektes benötigt (funktio-
nale Abhängigkeit).
Im Regelfall werden sogenannte binäre Assoziationen, das heißt die Beziehungen
zwischen genau zwei Objekten, betrachtet. Die Wertigkeiten bzw. Kardinalitäten (oder
Multiziplitäten) einer Assoziation geben dabei an, wie viele Objekte der einen Seite mit
wie vielen Objekten der anderen Seite dieser Relation in Beziehung stehen. Zusätzlich
wird zwischen gerichteten (unidirektionalen) und ungerichteten (bidirektionalen) Asso-
ziationen unterschieden. Im ersten Fall kennt nur eines der beiden in Beziehung stehenden
Objekte das andere Objekt, im letzteren Fall kennen sich beide beteiligen Objekte.
Umgesetzt werden Assoziationen als Attribute eines komplexen Typs (s. Tab. 3.1), ent-
weder mit direktem Verweis auf die Klasse des anderen Objekts oder mit Verweis auf eine
sogenannte Assoziationsklasse (oder assoziative Klasse), welche explizit die Beziehung
als zusätzliches Objekt modelliert. Eine Assoziationsklasse bietet somit die Möglichkeit,
der Beziehung selbst weitere Semantik zu geben, zum Beispiel in Form von zusätzlichen
Eigenschaften.
In unserem Beispiel steht das Wandobjekt mit Objekten der Klassen Oeffnung, Aufla-
ger und Last in Beziehung. Abbildung 3.7 stellt diesen Sachverhalt in Form eines UML-
Klassendiagramms grafisch dar. Assoziationen werden dabei als durchgezogene Linien
3 Objektorientierte Modellierung 53
1 -besitzt
1 -lagert
Auflager
-besitzt -belastet
Belastung
Assoziations-
-staendig : bool
klasse
Aufgelöste Assoziationsklasse
Abb. 3.8 Assoziative Klasse (oben) und deren Auflösung (unten) im Beispielmodell. UML-Klas-
sendiagramme
Eine Komposition ist eine Art „starke“ Aggregation, bei der im Gegensatz zur „einfachen“
Aggregation die Einzelteile nicht ohne das Ganze existieren können.
Beispielsweise können zwei Stützen und ein Balken auch unabhängig von der Exis-
tenz des zusammengesetzten Rahmens als Einzelbauteile existieren. Hier würden die
zwei Assoziationen Rahmen—Stütze und Rahmen—Balken als Aggregationen modelliert
(s. Abb. 3.9). Das Klassendiagramm in Abb. 3.9 sagt demnach aus, dass ein Rahmen
aus genau zwei (2) Stützen und einem (1) Balken besteht, Stützen zu keinem oder genau
einem (0..1) Rahmen gehören und ein (1) Balken zu keinem oder genau einem (0..1)
Rahmen gehört.
In Bezug auf unser Beispiel soll die Wand aus mehreren Wandschichten aufgebaut sein.
Diese Aggregation kann sinnvoll auch als Komposition modelliert werden, da einzelne
Wandschichten wie z. B. die Dämmschicht nicht ohne das Ganze – die Wand – existieren
können. Abbildung 3.10 stellt diesen Sachverhalt in Form eines UML-Klassendiagramms
grafisch dar. Zusätzlich zeigt dieses Diagramm eine Vererbungshierarchie, mit der un-
terschiedliche Unterklassen (Putz-, Trag-, Dämm- und Vorsatzschicht) von Wandschicht
modelliert werden können.
3 Objektorientierte Modellierung 55
Wandschicht
Wand
#dicke : double
#material : string
1 1..*
Die Möglichkeit einer Komplexitätsreduktion des realen Phänomens ist ein wesentlicher
Vorteil der objektorientierten Denkweise im Gegensatz zu prozeduralen, datenorientierten,
deklarativen und funktionalen Paradigmen. Allerdings erfordern viele Anwendungsfälle
im Bauwesen gerade sehr detaillierte Modelle, z. B. bei möglichst realistischer Echtzeit-
Visualisierung von Bauwerken. In diesem Zusammenhang stellt sich die Frage nach dem
Detaillierungs- (engl. Level of Detail) bzw. Ausarbeitungs-/Reifegrad (engl. Level of
Development), das heißt, wie weit muss ein Bauwerk in seine Einzelteilte zerlegt wer-
den, um eine bestimmt Aufgabe computergestützt zu erledigen. Genügt es, eine Tür durch
ihren Rahmen und ihr Blatt zu repräsentieren, oder ist es erforderlich, die Zarge, die Zier-
blende, das Schloss und den Drücker im Detail zu modellieren? Analog stellt sich die
Frage, wie detailliert die Beziehungen zwischen Bauteilen modelliert werden müssen.
Wann muss beispielsweise eine neue Kindklasse erzeugt werden, um die Struktur des
Modells zu verbessern? Zusammenfassend ist zu konstatieren, dass hier Vorsicht geboten
ist, da mit zunehmender Detaillierungstiefe sehr schnell auch wieder die Komplexität des
Gesamtmodells steigt (Booch 1994).
Eine weitere Herausforderung stellt die Modellierung unterschiedlicher Sichten auf
ein und dasselbe Objekt dar. Beispielsweise spielt für einen Architekten die Farbe einer
Stahlbetonwand eine entscheidende Rolle im Hinblick auf die Ästhetik des Bauwerks. Für
den Tragwerksplaner ist die Farbe uninteressant, Materialeigenschaften wie der Elastizi-
tätsmodul sind von weitaus größerer Bedeutung. Vor diesem Hintergrund stellt sich die
Frage, ob ein ganzheitliches Modell, welches alle Sichten abbildet sinnvoll ist, oder ob es
zweckmäßiger und zielführender wäre, einzelne Teilmodelle zunächst separat zu erstellen
und anschließend miteinander zu verknüpfen. Eine Art der Herangehensweise an diese
Fragestellung wird in den Kap. 5 und 6 vorgestellt.
56 C. Koch
Literatur
Balzert, Helmut (2001), Lehrbuch der Software-Technik, Bd. 1.: Software-Entwicklung, 2. Aufl.,
Heidelberg; Berlin: Spektrum Akademischer Verlag, 2001.
Booch, Grady (1994), Objektorientierte Analyse und Design: Mit praktischen Anwendungsbeispie-
len, 1. Aufl., Bonn u. a.: Adisson-Wesley, 1994.
Hartmann, Dietrich (Hrsg.) (2000), Objektorientierte Modellierung in Planung und Konstruktion,
Forschungsbericht zum DFG-Schwerpunktprogramm 1103, Weinheim: Wiley-VCH, 2000.
Oestereich, Bernd (2009), Analyse und Design mit UML 2.3 – Objektorientierte Softwareentwick-
lung, 9. Aufl., München: Oldenbourg Verlag, 2009.
Prozessmodellierung
Markus König
4
Zusammenfassung
Ein wichtiger Bestandteil der BIM-Methodik ist die Betrachtung der Prozesse, bei de-
nen digitale Bauwerksinformationen erstellt, verändert, verwendet und weitergeben
werden. Die Planung und Koordination dieser BIM-Prozesse ist unter anderem eine
wichtige Aufgabe des BIM-Managers. Es muss festgelegt werden, welche Aufgaben
von welchen Personen in welcher Reihenfolge bearbeitet werden sollen. Hierbei sind
auch die einzelnen Schnittstellen genau zu spezifizieren. Eine schlanke und transparen-
te Prozessdefinition kann die Einführung von BIM-Methoden wesentlich unterstützen.
Im Rahmen dieses Kapitels wird eine Einführung in die formale Prozessmodellierung
gegeben. Hierbei wird insbesondere auf die Modellierungssprachen Integration Defini-
tion for Function Modeling (IDEF) und Business Process Model and Notation (BPMN)
eingegangen, die heutzutage im Bereich der BIM-Prozessmodellierung am häufigsten
angewendet werden.
4.1 Einführung
Ein wichtiger Bestandteil der BIM-Methodik ist die Betrachtung der Prozesse, bei de-
nen digitale Bauwerksinformationen erstellt, verändert, verwendet und weitergeben wer-
den. In der Regel führen verschiedene Fachplaner und Unternehmen diese Prozesse aus
und sollten entsprechend koordiniert werden. Bei großen Bauprojekten kann diese Pro-
zesslandschaft sehr komplex werden. Die Prozesslandschaft in der BIM-basierten Pro-
jektabwicklung umfasst unter anderem Planungs-, Kommunikations,- Datenaustausch-,
Geschäfts-, Controlling-, Ausführungs- und Bewirtschaftungsprozesse. Für eine erfolgrei-
Markus König
Ruhr-Universität Bochum, Lehrstuhl für Informatik im Bauwesen, Universitätsstraße 150,
44780 Bochum, Deutschland
e-mail: koenig@inf.bi.rub.de
che Einführung von BIM-Technologien müssen diese Prozesse und deren Zusammenspiel
systematisch und korrekt beschrieben werden. Neben dem Umfang der verschiedenen
Prozesse spielt auch die dynamische Ergänzung und Änderung von Prozessen und entspre-
chenden Prozessabläufen eine wichtige Rolle. Häufig ist eine vollständige Definition aller
Prozesse zu Projektstart noch nicht möglich. Eine kontinuierliche Prüfung, Anpassung
und Verbesserung der Prozesse ist somit zwingend erforderlich. Diese Randbedingungen
und neue technologische Möglichkeiten sollte eine ganzheitliche und zielgerichtete Pro-
zessmodellierung im Bauwesen berücksichtigen.
Building Information Modeling umfasst somit nicht nur die Einführung von neuen
Technologien. Vielmehr handelt es sich auch um eine Neuorganisation bzw. Optimie-
rung der Projektabwicklung und der damit verbundenen Prozesse. Durch die Definition
von transparenten Prozessen kann eine integrierte, partnerschaftliche Arbeitsweise ermög-
licht werden. Die BIM-Methoden ermöglichen auch eine ganz neuartige Verwaltung der
vielfältigen Bauwerksinformationen (vgl. Kap. 12) Diese haben wiederum Auswirkungen
auf die Gestaltung der Prozesse und Zusammenarbeit der Fachplaner. Das Prozessma-
nagement unterscheidet sich dabei häufig durch die Art der Projektabwicklung, die Ver-
tragsform und die Projektgröße. Daher sollte neben der Festlegung von möglichen BIM-
Technologien auch der Umfang der Prozessunterstützung in Abhängigkeit von den indi-
viduellen Projektanforderungen festgelegt werden. Erst durch auf die Organisationsform
abgestimmte Prozesse können BIM-Methoden und Werkzeuge erfolgreich eingesetzt wer-
den.
Die Prozessmodellierung ist eine wesentliche Aufgabe der BIM-Manager (vgl.
Kap. 13). Bei der BIM-Prozessmodellierung geht es im Prinzip darum, welche Aufga-
ben von welchen Personen mit welchen Tools in welcher Reihenfolge bearbeitet werden
sollen. Hierbei müssen die einzelnen Schnittstellen genau definiert sein. Neben der
Festlegung des Datenaustauschs, des Datenumfangs, der zeitlichen Abfolge und von Ver-
antwortlichkeiten sollten auch Freigabeprozesse spezifiziert und geplant werden. Eine
schlanke und transparente Prozessdefinition kann die Einführung von BIM-Methoden
wesentlich unterstützen.
Die Modellierung von Prozessen im Bauwesen kann natürlich unabhängig von der
BIM-Methode angewendet werden. Prozesse im Lebenszyklus eines Bauwerks werden
schon heutzutage sehr genau und systematisch geplant. Auch in anderen Industrie- und
Wirtschaftsbereichen erfolgt eine sehr umfangreiche Definition und Abstimmung von Pro-
duktions- und Informationsprozessen. An dieser Stelle soll hier auf die vielfältige Literatur
zum Thema Prozessmanagement hingewiesen werden (z. B. Allweyer 2005; Becker et al.
2012; Bayer und Kühn 2013). Abgestimmte und gut dokumentierte Prozesse sind auch ein
wesentliches Element des Qualitätsmanagements nach ISO 9001. Das größte Hemmnis
bei der Anpassung von Prozessen sind traditionelle eher funktional-orientierte hierarchi-
sche Organisationsstrukturen, die auch häufig bei der Projektabwicklung im Bauwesen
vorherrschen (vgl. Gadatsch 2012). Insbesondere bei Projekten mit vielen Beteiligten aus
unterschiedlichen Unternehmen steht nicht der Gesamtprozess, sondern die einzelne Auf-
gabe im Kontext des eigenen Aufgabenbereiches im Vordergrund. Die funktionale Orga-
4 Prozessmodellierung 59
Bauunternehmen Subunternehmer
Kalkulaon Controlling Kalkulaon Controlling
Bauprojekt A
Bauherrn
Bauherrn
Bauprojekt B
Bauprojekt C
4.2 Workflow-Management
Prozesse Werkzeuge
Workflow
4 Prozessmodellierung 61
Strukturierte Prozesse
Prozesse und strukturierte Da-
ten
Dokumenten- Workflow-
management Management
Unstrukturierte Prozesse
Aufgaben-
Fallmanagement
management
Workflow-Managements. Hierzu sind wie schon erwähnt strukturierte Prozesse und Da-
ten erforderlich (siehe Abb. 4.3). Das Strukturieren von Daten im Kontext des Building
Information Modeling wird in den Kap. 7 und 9 behandelt. Auf das Strukturieren der Pro-
zesse der Projektabwicklung und deren Modellierung wird im Folgenden eingegangen.
An dieser Stelle wird auf weiterführende Literatur zum Thema Workflow-Management
verwiesen (z. B. Müller 2005; Wittges 2005; Richter-von-Hagen 2004; Gadatsch 2012).
4.3 Prozessmodellierung
Im Rahmen der Prozessmodellierung werden alle wesentlichen Elemente, die zur Aus-
führung der einzelnen Aufgaben notwendig sind, formal beschrieben und übersichtlich
dargestellt. In den letzten Jahrzehnten wurde eine Vielzahl von Modellierungsansätzen
für Prozesse entwickelt. Häufig werden für unterschiedliche Aspekte verschiedene Sich-
ten verwendet. In vielen Ansätzen wird mindestens zwischen Prozess-, Organisations- und
Informationssicht unterschieden (vgl. Österle 1995; Scheer 1998; Gadatsch 2012).
Prinzipiell werden in den einzelnen Sichten die Aufgaben, der Ablauf, Verantwortlich-
keiten, Bearbeiter, Werkzeuge und Informationen dargestellt. Die betrachteten Elemen-
te und unterschiedlichen Sichten lassen sich mithilfe von formalen Methoden beschrei-
ben. Häufig werden hierzu grafische Notationen oder Diagrammsprachen verwendet. In
Abb. 4.4 sind ausgewählte Diagrammsprachen dargestellt. Heutzutage werden im Bauwe-
sen sehr häufig Integration Definition for Function Modeling (IDEF), erweiterte Ereignis-
gesteuerte Prozessketten (eEPK) oder die Business Process Modeling Notation (BPMN)
verwendet. Natürlich können auch andere Modellierungsansätze zur Beschreibung von
Prozessen unter Berücksichtigung von BIM-Methoden verwendet werden. Nähere Infor-
62 M. König
Kontrollfluss-
Datenfluss-orienert Objektorienert
orienert
Erweiterte
Acvity Diagram
IDEF-Diagramme Petri-Netze Ereignisgesteuerte State Chart Diagram
(UML)
Prozesskeen (eEPK)
Buisness Process
Datenfluss- Use Case Diagram Objektorienerte
Struktogramme Modeling Notaon
diagramme (SSA) (UML) EPK
(BPMN)
Wertschöpfungs-
Flussdiagramme Interakons-
keendiagramme
(SADT) diagramme (SOM)
(WKD)
Integration Definition for Function Modeling (IDEF) wurde Ende der 1970er-Jahre von
der US Air Force entwickelt. Die zwei wesentlichen Grundelemente zur Modellierung von
Prozessen sind in der IDEF0-Methode definiert. Es existiert auch eine Erweiterung zur
Modellierung von Workflows (IDEF3), welche jedoch wenig verwendet werden. IDEF0-
Diagramme umfassen nur Tätigkeitsboxen und Pfeile, wobei die Pfeile beliebige Objekte
oder Informationen darstellen können. Die Orientierung der Pfeile bzgl. der Tätigkeitsbox
besitzen verschiedene Bedeutungen, die in Abb. 4.5 dargestellt sind.
In der Abb. 4.6 ist ein möglicher Prozessablauf zur automatisierten Kollisionsunter-
suchung unter Verwendung von digitalen Bauwerksmodellen dargestellt. Für einfache
Prozesse und wenige verknüpfte Objekte ist die IDEF0-Methode sehr gut geeignet. Ist
jedoch eine Vielzahl von Personen beteiligt und sollen die verwendeten Informationen
und der Datenaustausch im Detail beschrieben werden, sind andere Modellierungsansätze
4 Prozessmodellierung 63
Die Business Process Model and Notation (BPMN) ist eine standardisierte grafische
Spezifikationssprache zur Modellierung von Geschäftsprozessen und Workflows, welche
durch die Object Management Group (OMG) gepflegt und weiterentwickelt wird. OMG
ist eine in der Informationstechnologie federführende Standardisierungsorganisation, die
zum Beispiel auch die Unified Modeling Language (UML) und andere internationale
verbindliche Standards spezifiziert. In vielen Bereichen wird BPMN bereits als Standard
verwendet. Auch die buildingSMART Alliance verwendet diese Spezifikationssprache
zur Formalisierung von Prozessen im Bereich des Building Information Modeling (siehe
Kap. 7). BPMN stellt verschiedene Symbole bereit, mit denen die Abbildung und Verar-
beitung von Prozessen dokumentiert werden kann. Die grafischen Symbole sind unterteilt
in Flow Objects, Pools und Swimlanes, Connecting Objects, und Artifacts. Die einzelnen
Elemente werden im Folgenden kurz vorgestellt. Detaillierte Informationen können der
einschlägigen Literatur zu BPMN entnommen werden (z. B. Allweyer 2009; Freund und
Rücker 2014).
Flow Objects
Flow Objects beschreiben die Aktivitäten (Activity), Entscheidungspunkte bzw. Koordi-
nierungspunkte (Gateway) und Ereignisse (Event) in einem Prozess. Eine Aktivität be-
64
Abb. 4.6 IDEF0-Diagramm zur automatisierten Kollisionsuntersuchung. (In Anlehnung an Wang und Leite 2012)
M. König
4 Prozessmodellierung 65
schreibt eine Aufgabe. Eine nicht teilbare Aktivität wird Task genannt. Eine Aktivität,
die aus Unteraktivitäten bzw. Unteraufgaben besteht, wird als Subprocess bezeichnet. Die
entsprechenden Symbole sind in Abb. 4.7 dargestellt.
Mithilfe von Entscheidungspunkten (Split/Fork) und Koordinierungspunkten (Join/
Merge) kann der Ablauf eines Prozesses gesteuert werden (Abb. 4.8). Wichtig dabei ist
eine korrekte Zusammenführung von alternativen und parallelen Teilabläufen.
Ereignisse stellen im Wesentlichen externe Ereignisse dar, die einen Einfluss auf den
betrachteten Prozess besitzen. Durch ein Ereignis kann z. B. eine Aktivität gestartet oder
ein gesamter Prozess beendet werden. In Abb. 4.9 sind einige Beispiele für Ereignisse
dargestellt.
Connecting Objects
Die Reihenfolge von Aktivitäten (Sequence Flow) und Informationen (Message Flow)
werden mithilfe von Connections beschrieben. Die Verbindungen zwischen Aktivitäten
beschreiben nur die logische Reihenfolge und beinhalten in der Regel keine Arbeitsdauern
(Abb. 4.11). Abgabetermine werden mithilfe von externen Ereignissen beschrieben, die
wiederum eine weitere Aktivität anstoßen.
Die Reihenfolge von Aktivitäten wird nur für einen Beteiligten definiert. Zwischen
verschiedenen Pools dürfen keine zwei Aktivitäten verknüpft werden. Zwischen zwei un-
terschiedlichen Pools können jedoch Informationsflüsse definiert werden, die Aktivitäten
anstoßen können (Abb. 4.12).
Artefacts
Mithilfe von sogenannten Artefakten können zusätzliche Informationen beschrieben wer-
den. Insbesondere zur Organisation des Informationsflusses im Bereich des Building In-
formation Modeling sind diese Möglichkeiten sehr wichtig. Beispielsweise können das
Datenformat, Detaillierung und Inhalte eines Bauwerksmodells spezifiziert werden. Je
genauer solche Artifacts beschrieben werden, umso besser lassen sich auch komplexe
Prozesse kontrollieren und steuern. Prinzipiell gibt es zwei Möglichkeiten, Artifacts zu
definieren. Zum einen können Datenobjekte definiert und an Aktivitäten und Verbindun-
gen angeheftet werden. Durch die Angabe eines Pfeils kann auch spezifiziert werden, ob
ein Datenobjekt verwendet bzw. benötigt oder erzeugt wird (Abb. 4.13).
Annotationen bieten die Möglichkeit, weitere Informationen für die Anwender der
BPMN Beschreibung bereit zu stellen. Eine Annotation ist eine verbale Information und
kann jedem beliebigen Element zugeordnet werden. Häufig werden Annotationen verwen-
det, um einzelne Aktivitäten zu erläutern oder mögliche Probleme bei der Ausführung zu
dokumentieren. In Abb. 4.14 wird die Zuordnung einer Annotation zu einer Aktivität dar-
gestellt.
68 M. König
BPMN-Diagramme wurden schon sehr erfolgreich zur Modellierung von Prozessen für
das Building Information Modeling verwendet. In Abb. 4.15 werden nach Eastman et al.
(2009) die Aufgabe und Schnittstellen zwischen Architekt, Konstrukteur und Fertigteil-
hersteller während verschiedener Planungsphasen beschrieben. Auf Basis des entstehen-
den Prozessdiagramms können Datenaustauschpunkte und die zugehörigen Modellinhalte
eindeutig spezifiziert werden. Häufig macht es Sinn, den Datenaustausch durch die Model
View Definition zu ergänzen (siehe Kap. 7).
4.4 Workflow-Management-Systeme
Die Umsetzung eines Workflows kann in unterschiedlicher Art und Weise erfolgen. Die
einfachste Realisierung liegt darin, dass die Personen mit ihren bisherige Werkzeugen und
Datenquelle arbeiten. Die Kommunikation erfolgt dann konventionell über direkte und pa-
pierbasierte Kommunikation, E-Mails oder zentrale Austauschplattformen. Die Steuerung
erfolgt dann manuell durch verantwortliche Personen. In vielen Bereichen (z. B. Ban-
ken, Versicherungen oder Behörden) werden schon seit langem die definierten Prozesse
in einem Workflow-Management-System instanziiert und mithilfe einer Workflow-Engi-
ne ausgeführt, gesteuert und überwacht (Abb. 4.16). Mit der Einführung von Workflow-
Management-Systemen werden im Allgemeinen folgende Ziele verfolgt:
Die weitreichendste Unterstützung erfordert eine zentrale Datenbasis und die direk-
te Anbindung verschiedener Applikationen. Jedoch kann auch eine eher lose Anbindung
umgesetzt werden, bei der nur Informationen über den Status der geplanten Aktivitäten
zurückgemeldet werden. Somit wird der Workflow nur übergeordnet gesteuert und der
4
Prozessmodellierung
Abb. 4.15 BPMN-Diagramm zur Darstellung von Aufgaben und Schnittstellen zwischen Architekt, Konstrukteur und Fertigteilhersteller im Zuge der
69
Soware / Tool
Prozess-
modellierung Interne System Daten
Benutzer und
Referenzen auf Prozesse Referenzen auf Applikaonen
Rollen
Workflow Status-
informaonen
Engine aktualisiert
verwendet
Relevante
Worklist
Daten
Datenaustausch bzw. die Datenhaltung erfolgt nicht zentral. Die verschiedenen Realisie-
rungen eines sogenannten Worklist Handler sind in Abb. 4.17 dargestellt. Diese Funk-
tionalitäten werden heutzutage schon von vielen Projektmanagementsystemen zur Verfü-
gung gestellt (vgl. Kap. 12).
Durch Bereitstellung von zentralen BIM-Servern und neuartigen Planungstools ist zu
erwarten, dass Workflow-Management-Systeme in Zukunft auch im Bauwesen immer
häufiger eingesetzt werden. Trotz aller technischen Möglichkeiten ist die wesentliche
Grundlage weiterhin eine korrekte und detaillierte Beschreibung der Prozesse.
4.5 Ausführungsprozesse
Die Definition, Strukturierung, Analyse und Steuerung der Ausführungsprozesse ist ei-
ne Hauptaufgabe der Arbeitsvorbereitung und der Projektsteuerung. Hierzu wird in der
Praxis im Allgemeinen die Netzplantechnik verwendet. An dieser Stelle wird nicht näher
4 Prozessmodellierung 71
Worklist
Worklist
Worklist
Zugriff
Worklist
Worklist
Workflow
Applikaon
Abb. 4.17 Realisierung der Kommunikation zwischen Workflow Engine und Anwendungssystem
auf die einzelnen Elemente und Methoden der Netzplantechnik eingegangen. Es wird auf
entsprechende Literatur verwiesen (z. B. Noosten 2013; Schwarze 2014). Vielmehr sollen
einige Potenziale diskutiert werden.
Durch die Möglichkeiten des Building Information Modeling stehen viel umfangrei-
chere Informationen zu Verfügung, sodass die Ausführung schon in frühen Phasen genau-
er und detaillierter geplant werden kann. Des Weiteren kann die Planung der Produktion
und Logistik mithilfe von speziellen Simulationsansätzen im Detail analysiert werden.
Bei sehr umfangreichen Bauablaufplänen (z. B. mehre tausende Vorgänge) stößt die Netz-
plantechnik sehr schnell an ihre Grenzen. Die Definition der einzelnen Vorgänge und
Anordnungsbeziehungen ist sehr aufwendig, die Übersichtlichkeit nimmt sehr stark ab
und Anpassungen sind sehr fehleranfällig. Ein weiterer Nachteil ist, dass gewisse Infor-
mationen wie Ressourcen, Liefertermine, Dokumente und andere Randbedingungen nur
sehr schwer beschrieben werden können. Diese Informationen sind jedoch für eine realis-
tische und robuste Ausführungsplanung notwendig.
72 M. König
Aus den genannten Gründen werden auch im Bereich der Ausführungsplanung immer
häufiger Prozessmodelle auf Basis von IDEF0 oder BPMN verwendet (Benevolenskiy
et al. 2012). Dies erfolgt in der Regel unter Verwendung von sogenannten Prozessvor-
lagen, die Bauverfahren generalisiert beschreiben. Aktuell existieren noch keine standar-
disierten Prozessvorlagen. Prozessvorlagen werden daher meist unternehmens- und pro-
jektspezifisch definiert. Diese Prozessvorlagen werden anschließend für die Aufstellung
eines Bauablaufplans verwendet. Die Verknüpfung der Vorgänge mit Personal, Maschi-
nen und logistischen Randbedingungen ermöglicht anschließend die Implementierung von
Modellen zur Simulation der Ausführung. Entsprechende Ansätze wurden im Rahmen
von Forschungsprojekten (z. B. BMBF-Projekt Mefisto, Scherer und Schapke 2014) er-
folgreich validiert und werden in Zukunft sicherlich auch im Rahmen der Baupraxis an
Bedeutung gewinnen.
Literatur
Allweyer, Thomas (2009). BPMN 2.0 – Business Process Model and Notation: Einführung in den
Standard für die Geschäftsprozessmodellierung. Books on Demand, 2. Auflage, 2009
Bayer, Franz; Kühn, Harald (2013). Prozessmanagement für Experten – Impulse für aktuelle und
wiederkehrende Themen, Springer Gabler Verlag, 1. Auflage, 2013
Becker, Jörg; Kugeler, Martin; Rosemann, Michael (2012). Prozessmanagement – Ein Leitfaden zur
prozessorientierten Organisationsgestaltung, Springer Gabler Verlag, Auflage 7, 2012
Benevolenskiy, Alexander; Roos, Ksenia, Katranuschkov, Peter; Scherer, Raimar J. (2012). Con-
struction processes configuration using process patterns. Advanced Engineering Informatics,
Volume 26, Issue 4, October 2012, Pages 727–736
Desel, Jörg; Oberweis, Andreas (1996). Petri-Netze in der Angewandten Informatik – Einführung,
Grundlagen und Perspektiven. Wirtschaftsinformatik, 38, (4), pages 359–367, 1996
Eastman, Charles; Sacks, Rafael; Panushev, Ivan; Aram, Shiva; Yagmur, Elif (2009) Information De-
livery Manual for Precast Concrete, PCI-Charles Pankow Foundation, http://www.blis-project.
org/IAI-MVD/IDM/PCI-001.pdf, Zugegriffen: 9.6.2015
Freund, Jakob; Rücker, Bernd (2014). Praxishandbuch BPMN 2.0. Carl Hanser Verlag GmbH & Co.
KG, 4. Auflage, 2014
Gadatsch, Andreas (2012). Grundkurs Geschäftsprozess-Management: Methoden und Werkzeuge
für die IT-Praxis: Eine Einführung für Studenten und Praktiker. Springer Vieweg Verlag, 7. Auf-
lage, 2012
Hollingsworth, David (1995). Workflow Management Coalition – The Workflow Reference Model
WFMC-TC-1003, 19-Jan-95
Müller, Joachim (2005). Workflow-based Integration: Grundlagen, Technologien, Management.
Springer Verlag, 2005
Noosten, Dirk (2013). Netzplantechnik – Grundlagen und Anwendung im Bauprojektmanagement.
Springer Vieweg, 2013
Österle, Hubert (1995). Business Engineering. Prozeß- und Systementwicklung: Band 1: Entwurfs-
techniken. Springer Verlag, 2. Auflage, 1995
Richter-von-Hagen, Cornelia (2004). Business-Process- und Workflow-Management: Prozessver-
besserung durch Prozess-Management. Vieweg+Teubner Verlag, 2004
Scheer, August-Wilhelm (1998). ARIS – Vom Geschäftsprozeß zum Anwendungssystem. Springer
Verlag, 3. Auflage, 1998
Scheer, August-Wilhelm; Jost, Wolfram (1996). Geschäftsprozeßmodellierung innerhalb einer Un-
ternehmensarchitektur, in: Vossen, G. und Becker, J. (Hrsg.):, Geschäftsprozeßmodellierung
und Workflow-Management – Modelle, Methoden, Werkzeuge, Springer Verlag, 1. Aufl., 1996
Scherer, Raimar J., Schapke, Sven-Eric (2014). Informationssysteme im Bauwesen 1: Modelle, Me-
thoden und Prozesse. Springer Vieweg, 2014
Schwarze, Jochen (2014). Projektmanagement mit Netzplantechnik. Nwb Verlag, 11. Auflage, 2014
Wang, Li.; Leite, Fernanda (2012). Towards Process-aware Building Information Modeling for Dy-
namic Design and Management of Construction Processes. In: Proceedings of the 19th Annual
Workshop of the European Group for Intelligent Computing in Engineering (EG-ICE). Herr-
sching, Germany: Technische Universität München
Wittges, Holger (2005). Verbindung von Geschäftsprozessmodellierung und Workflow-
Implementierung. Springer Gabler Verlag, 2005
Teil II
lnteroperabiliät
Software-Interoperabilität im Bauwesen
– Hintergrund und Motivation 5
André Borrmann und Christian Koch
Zusammenfassung
Im Rahmen von Planung, Errichtung und Betrieb eines Bauwerks kommt eine Vielzahl
von unterschiedlichen Softwarelösungen zum Einsatz. Um einen möglichst verlust-
freien digitalen Datenfluss auf hohem inhaltlichem Niveau im Sinne des BIG-BIM-
Ansatzes zu realisieren, ist es notwendig, Interoperabilität zwischen diesen Software-
produkten herzustellen. Das Kapitel geht auf die spezifischen Randbedingungen ein,
die die Bauindustrie von anderen Wirtschaftszweigen unterscheidet. Eine der wichtigs-
ten Konsequenzen hieraus ist, dass nur herstellerneutrale, offene Datenformate die Rea-
lisierung von weitreichender und nachhaltiger Interoperabilität gewährleisten können.
Mit den Industry Foundation Classes steht ein standardisiertes, offenes Datenformat
zum hochwertigen Austausch digitaler Bauwerksmodelle zur Verfügung, das Interope-
rabilität ermöglicht und damit die Basis für die Umsetzung von BIG Open BIM bildet.
Die Idee des Building Information Modeling basiert auf einer durchgängigen Verwen-
dung eines umfassenden digitalen Bauwerksmodells als Grundlage für alle Datenaustau-
schoperationen (siehe Kap. 1). Auf diese Weise wird die manuelle und fehleranfällige
Neueingabe von einmal erzeugten Daten bzw. Informationen vermieden. Dies gilt vor al-
lem für die zahlreichen Datenaustauschszenarien zwischen den Beteiligten der Planungs-
phase, aber ebenso für die Übergabe von Planungsdaten an die Baufirmen zur Nutzung
André Borrmann
Technische Universität München, Lehrstuhl für Computergestützte Modellierung und Simulation,
Arcisstr. 21, 80333 München, Deutschland
e-mail: andre.borrmann@tum.de
Christian Koch
The University of Nottingham, Department of Civil Engineering, University Park, NG7
2RD Nottingham, Großbritannien
e-mail: christian.koch@nottingham.ac.uk
Abb. 5.1 Automatisierungsinseln im Bauwesen, Darstellung aus dem Jahr 1998 (Matti Hannus)
digitaler Daten in der Ausführungsphase und das „Handover“ der Daten nach Abschluss
der Bauarbeiten an die Betreiber des Gebäudes.
Für die zahlreichen Aufgaben, die bei der Planung und Errichtung von Bauwerken
anfallen, gibt es heute eine Vielzahl hochspezialisierter Softwarewerkzeuge. Dies bein-
haltet Applikationen für den geometrischen Entwurf, für die Durchführung verschiedener
Analysen und Simulationen (Statik, Wärmebedarf, Kosten etc.), für den Betrieb des Ge-
bäudes (Facility Management) und für weitere Anwendungen, die in Teil 4 dieses Buches
aufgeführt werden. Diese Softwarewerkzeuge sind für ihren jeweiligen Einsatzbereich im
Allgemeinen sehr gut geeignet und weitgehend ausgereift.
Problematisch ist allerdings, dass diese Programme heute zum überwiegenden Teil
immer noch Automatisierungsinseln bilden (Abb. 5.1). Das bedeutet, dass der Datenaus-
tausch zwischen den einzelnen Anwendungen nicht oder nur unzureichend funktioniert,
sodass manuelle und damit aufwendige und fehleranfällige Neueingaben von eigentlich
bereits digital vorliegenden Informationen notwendig werden.
Um diesen Zustand zu überwinden, ist ein Datenaustauschformat notwendig, mit des-
sen Hilfe ein weitgehend verlustfreier Transport von Bauwerksdaten über die Grenzen
einzelner Softwareprodukte hinweg realisiert werden kann. Ein derartiges Format muss
zum einen eine einheitliche und eindeutige Beschreibung von geometrischen Informatio-
5 Software-Interoperabilität im Bauwesen – Hintergrund und Motivation 79
nen beinhalten, die Fehlinterpretationen weitgehend ausschließt (siehe Kap. 2). Ebenso
wichtig ist aber auch eine detaillierte Beschreibung der semantischen Informationen, ein-
schließlich der Klassifizierung der Bauteile anhand einer einheitlichen Typhierarchie, der
Beschreibung von Beziehungen zwischen ihnen, sowie die Definition von relevanten Ei-
genschaften (Material, Bauzeiten etc., siehe Kap. 3).
Hier kommt der Begriff der Interoperabilität ins Spiel, der bedeutet, dass Daten ver-
lustfrei zwischen den Softwareprodukten verschiedener Hersteller ausgetauscht werden
können. Gerade die Vielfalt der eingesetzten Produkte und der am Markt agierenden Soft-
warehersteller stellt eine Besonderheit des Bauwesens dar. In anderen Branchen (wie
beispielsweise der Automobil- und Luftfahrzeugindustrie) gibt es genaue Vorgaben des
Hauptproduzenten gegenüber den Zulieferern hinsichtlich der einzusetzenden Software-
produkte. Gleichzeitig bieten große und weltweit agierende Softwarehäuser Komplett-
lösungen für diese Industriezweige an, die einen großen Teil der anfallenden Design-
und Engineering-Prozesse unterstützen. Für diese Softwarehersteller ist es deutlich einfa-
cher, Interoperabilität zwischen den eigenen Produkten herzustellen, da hierfür proprietäre
Formate zum Einsatz kommen können und aufwendige und langwierige Standardisie-
rungsverfahren entfallen.
Im Vergleich zur stationären Industrie herrscht im Bauwesen eine Reihe von spezi-
fischen Randbedingungen, die dem Erreichen des Zieles verlustfreien Datenaustauschs
erschwerend entgegenstehen:
In der Summe ergibt sich damit ein sehr stark fragmentierter Prozess mit einer Vielzahl
von Beteiligten aus vielen verschiedenen Unternehmen. Im Hinblick auf die Frage der
Software-Interoperabilität bedeutet das, dass viele unterschiedliche Softwarewerkzeuge
zum Einsatz kommen und einheitliche Vorgaben nur schwer umzusetzen sind. Im Ge-
genteil: Bei öffentlichen Bauvorhaben verbietet sich aus wettbewerbsrechtlichen Gründen
die Festschreibung von zu verwendenden Softwareprodukten. Für private und öffentliche
Bauherren gleichermaßen gilt es zudem, die Abhängigkeit von einzelnen Softwareherstel-
lern auf ein Minimum zu reduzieren, um ein Vendor Lock-In zu verhindern.
80 A. Borrmann und C. Koch
Für einen Teil der Datenaustauschszenarien hat sich in der heutigen Praxis die vertrag-
liche Festlegung von weitverbreiteten, aber letztlich proprietären Formaten etabliert, die
auf diese Weise den Status eines Pseudo-Standards erlangt haben. Mit derartigen Forma-
ten werden im Regelfall ausschließlich 2D-Zeichnungen transportiert, ergänzt um einge-
schränkte semantische Informationen durch Nutzung einer vorgegebenen Layer-Struktur.
Zur Umsetzung von BIG BIM im Sinne der durchgängigen Nutzung hochwertiger digi-
taler Bauwerksinformationen (siehe Kap. 1) ist die Nutzung proprietärer Formate jedoch
nicht zielführend. Proprietäre Datenformate sind auf spezifische Anwendungsfälle zuge-
schnitten und können weder der Vielfalt der Datenaustauschszenarien im BIM-Kontext
noch der benötigten Informationstiefe gerecht werden. Stattdessen hat sich bereits seit
langem die Erkenntnis durchgesetzt, dass die Realisierung von BIG BIM nur durch die
Schaffung von neutralen, offenen und standardisierten Datenaustauschformaten gelingen
kann.
Dieser Ansatz, der als der nachhaltigere, aber schwierigere und deshalb langwierigere
Weg gesehen werden muss, wird mit der Entwicklung des Datenformats Industry Founda-
tion Classes (IFC) durch die internationale Organisation buildingSMART verfolgt. Dabei
handelt es sich um ein komplexes Datenmodell, mit dessen Hilfe die Geometrie und Se-
mantik eines Gebäudes in objektorientierter Weise repräsentiert werden kann. Hierbei
wird das Bauwerk in seine Bauteile und Räume aufgelöst und diese samt ihrer gegen-
seitigen Beziehungen detailliert beschrieben. Dank seiner umfassenden Beschreibung ist
das IFC-Format für nahezu jedes beliebige Datenaustauschszenario im Lebenszyklus ei-
nes Bauwerks einsetzbar. Das IFC-Datenmodell hat daher immense Bedeutung für die
Umsetzung des BIM-Konzepts und bildet den Gegenstand einer Vielzahl von Standardi-
sierungsinitiativen im internationalen, aber auch im europäischen und deutschsprachigen
Raum. Es wird im Detail in Kap. 6 vorgestellt.
Der Weg zur Etablierung eines neutralen Datenaustauschstandards ist allerdings lang-
wierig. Zwar liegt mit Version 4 der IFC ein weitgehend ausgereifter Standard vor, jedoch
muss ein solcher Standard von den Softwareherstellern in den verschiedenen Programmen
als Import- oder Exportschnittstelle implementiert werden, damit er tatsächlich Eingang
in die Baupraxis finden kann. Hierbei hat sich gezeigt, dass insbesondere die Qualität der
Implementierung eine entscheidende Rolle für die Akzeptanz des Datenaustauschformats
in der Industrie spielt. Fehler in den Im- oder Exportmodulen, die zum Austausch fehler-
hafter Daten oder zum Datenverlust führen, haben das IFC-Format in der Vergangenheit
in Diskredit gebracht und die Marktakzeptanz verzögert.
Ein Grund für die mangelhafte Implementierung der Im- bzw. Exportfunktionalitäten
seitens der Softwarehersteller ist die Komplexität des IFC-Datenmodells. Ein Beispiel
hierfür ist die Möglichkeit, 3D-Geometrie auf viele unterschiedliche Weisen in einem
IFC-Modell abzulegen. Für die Softwarehersteller bedeutet dies, dass für eine vollständige
IFC-Kompatibilität alle diese Geometrierepräsentationen unterstützt werden müssen, was
einen immensen Implementierungsaufwand mit sich bringt.
Um dieses Hindernis zu überwinden, hat buildingSMART das Konzept der Model View
Definitions eingeführt, die genau festlegen, welche Teile des IFC-Datenmodells für eine
5 Software-Interoperabilität im Bauwesen – Hintergrund und Motivation 81
Zusammenfassung
Mit den Industry Foundation Classes (IFC) steht ein umfassendes und standardisiertes
Datenformat für den herstellerneutralen Austausch von digitalen Gebäudemodellen zur
Verfügung. Es bildet damit eine wesentliche Grundlage für die Umsetzung von Big
Open BIM. Das Kapitel beschreibt im Detail den Aufbau des Datenmodells und geht
ausführlich auf dessen Verwendung zur semantischen und geometrischen Beschreibung
eines Gebäudes und seiner Bauteile ein. Es schließt mit einer Diskussion der Vor- und
Nachteile des IFC-Datenmodells.
Bereits in den späten 1980er Jahren begannen Wissenschaftler sich mit der Frage ausein-
anderzusetzen, auf welche Weise ein höherwertiger Datenaustausch im Bauwesen reali-
André Borrmann
Technische Universität München, Lehrstuhl für Computergestützte Modellierung und Simulation,
Arcisstr. 21, 80333 München, Deutschland
e-mail: andre.borrmann@tum.de
Jakob Beetz
Technische Universiteit Eindhoven, Department of the Built Environment, Urban Science and
Systems, P.O. Box 513, 5600 Eindhoven, Niederlande
e-mail: J.Beetz@bwk.tue.nl
Christian Koch
The University of Nottingham, Department of Civil Engineering, University Park, NG7
2RD Nottingham, Großbritannien
e-mail: christian.koch@nottingham.ac.uk
Thomas Liebich
AEC3 Deutschland GmbH, Wendl-Dietrich-Straße 16, 80634 München, Deutschland
e-mail: tl@aec3.de
siert werden kann. Damals entstand die Idee der „Produktmodellierung“ als umfassende
digitale Beschreibung eines Produkts, die sowohl die Geometrie als auch die Semantik
seiner Bestandteile beinhaltet (Eastman 1999).
Angestoßen von großen Interessengruppen wie dem US-amerikanischen Verteidi-
gungsministerium und dem Dachverband der deutschen Automobilindustrie (VDA)
begannen in den 1970er Jahren Entwicklungen einheitlicher Schnittstellen zwischen
heterogenen CAD-Systemen, die einen verlustfreien Austausch von geometrischen Daten
erlauben sollten. Die aus diesen Entwicklungen entstandenen und teils bis heute ge-
brauchten Datenaustauschformate wie IGES (Initial Graphics Exchange Specification)
waren jedoch zunächst auf reine Geometriebeschreibungen beschränkt. Bestrebungen zu
weiterführenden Vereinheitlichungen mündeten in den 1980er Jahren im Standardisie-
rungsrahmenwerk „STEP – Standard for the Exchange of Product model data“ (Standard
für den Austausch von Produktmodelldaten). Durch das Technische Komitee 184, Un-
terkomitee 4 „Industrial Data“ (ISO TC 184/SC 4) der Internationalen Organisation für
Normierung (ISO) wurden im Standard ISO 10303 eine Vielzahl von Teilnormen durch
eine breite Allianz verschiedener Industriezweige erarbeitet (ISO 2002). Diese umfassen
heute neben grundlegenden Vereinbarungen zur Beschreibung von Schemata von Da-
tenmodellen (ISO 10303 Teil 11) samt grafischer Notationen, der Speicherformate für
Instanzen (Serialisierung) in verschiedenen syntaktischen Varianten und der einheitlichen
programmatischen Bearbeitungsschnittstellen auch semantische Aspekte zu einzelnen
Produktkategorien. Einzelne Industriezweige fassten ihre jeweils relevanten Produkte und
Datenaustauschszenarien in sogenannten Verwendungsprotokollen (Application Proto-
col – AP) zusammen. Neben Objektmodellen für Ölbohrplattformen, Flugzeug-, Auto-
und Schiffskomponenten entstand dabei auch ein Modell für Gebäude, das AP 225 zur
Beschreibung von „Gebäudeteilen mit expliziten Formbeschreibungen“.
Das Verfahren, mit dessen Hilfe Konsens über die einheitliche Modellierung von Ge-
bäuden und ihren Austausch erreicht werden sollte, wurde jedoch von vielen als zu lang-
wierig empfunden: die bürokratischen Randbedingungen zur Standardisierung unter dem
Dach der ISO galten als Hemmschuh für die seinerzeit prosperierende Bauindustrie. An-
geregt durch zahlreiche wissenschaftliche (oft EU-finanzierte) Forschungsvorhaben und
die Industrie beschloss eine Gruppe von Ingenieurbüros, Baufirmen und Softwareherstel-
lern mit maßgeblicher Beteiligung der Firma Autodesk die Standardisierungsbemühun-
gen effizienter zu gestalten und gründete 1995 die International Alliance for Interopera-
bility – IAI, um die Standardisierung zu beschleunigen. Die Organisation wurde 2005
in den griffigeren Namen „buildingSMART“ umgetauft und ist derzeit in 18 regiona-
le Verbände (Chapter), wie etwa dem deutschen „buildingSMART e. V.“, aufgegliedert.
buildingSMART gehören insgesamt über 800 Organisationen, Firmen und Einrichtungen
an, die die Standardisierungsbemühungen im Interesse aller vorantreiben. Eine erste Ver-
sion 1.0 wurde 1997 als „Industry Foundation Classes – IFC“ veröffentlicht und ab der
Version 1.5.1 in bauspezifischen Softwarepaketen implementiert (Laakso und Kiviniemi
2012).
6 Industry Foundation Classes 85
Seit dieser ersten Version entstanden in rascher Folge Revisionen und Erweiterungen
des Modells (siehe Abb. 6.1), die jeweils kurz darauf von Herstellern als Austausch-
schnittstellen in ihren jeweiligen Produkten implementiert wurden. Die Veröffentlichung
des Standards geschah dabei unabhängig von der ISO, kostenlos, herstellerneutral und
frei zugänglich (buildingSMART 2013). Auch wurden im Gegensatz zu proprietären,
herstellerabhängigen Objektmodellen wie etwa den damals populären Erweiterungsmög-
lichkeiten des Autodesk-Formate DWG und ARX für die Verwendung des IFC-Modells
keinerlei Lizenzgebühren erhoben. Diese Offenheit sorgte für eine rasche Zunahme der
Softwareprodukte, die das IFC-Modell implementierten. Heute gibt es über 160 Imple-
mentierungen des Standards in einzelnen Softwarelösungen, wobei die Version 2 × 3 der-
zeit am weitesten verbreitet ist, jedoch nach und nach durch die IFC 4 abgelöst werden
wird (Stand Ende 2014). Durch eine zusätzliche Normierung als ISO Standard 16739 (ISO
2013) gewinnt der Standard darüber hinaus zunehmende Bedeutung für die Öffentliche
Hand und ist bereits in einigen Ländern als verbindliches Austauschformat für Vergabe-
und Genehmigungsverfahren etabliert.
In den vergangenen Jahren hat sich das IFC-Format als das Format schlechthin für die
Realisierung von Open BIM etabliert. Es wird bereits von zahlreichen BIM-Programmen
unterstützt, angefangen bei den BIM-Modellierungswerkzeugen, über Programme für die
statische Berechnung und die Wärmebedarfsanalyse bis hin zur Software für das Facility
Management.
Dank der offen zugänglichen Definition der Datenstruktur und der damit verbundenen
Neutralität des IFC-Formats ist es zudem Grundlage für nahezu alle Initiativen im staatli-
chen Sektor, die zum Ziel haben, die Verwendung von BIM für öffentliche Bauvorhaben
verbindlich vorzuschreiben. Vorreiter sind dabei Singapur, Finnland, die USA und Groß-
britannien.
Das offene Format verspricht die Lesbarkeit der entsprechenden Dateien auch nach
sehr langer Zeit. Dies ist besonders vor dem Hintergrund der Lebensdauer von Gebäuden
äußerst wichtig, die in der Regel mehrere Jahrzehnte beträgt.
Momentan liegt der Schwerpunkt des IFC-Datenmodells auf der Beschreibung von Ge-
bäuden. Erweiterungen zur Abbildung von baulichen Anlagen des Infrastrukturbereichs
befinden sich aber bereits in der Entwicklung.
86 A. Borrmann et al.
Obwohl die Entwicklung der IFC aus der ISO-Standardisierung STEP herausgelöst wurde,
wurden dennoch die zugrunde liegenden Technologien beibehalten. Dazu zählt vor allem
die Datenmodellierungssprache EXPRESS, die im STEP-Standard Teil 11 definiert ist
(ISO 2004b).
Bei EXPRESS handelt es sich um eine deklarative Sprache, mit deren Hilfe objektori-
entierte Datenmodelle definiert werden können (Schenck und Wilson 1993). Das heißt, es
werden die in Kap. 3 beschriebenen objektorientierten Prinzipien umgesetzt, wie die Ab-
straktion von Objekten der realen Welt in Klassen (in EXPRESS als Entitäten bezeichnet),
die Attribute und Beziehungen zu anderen Klassen aufweisen können.
EXPRESS bietet das Konstrukt des Entitytyps1 als Äquivalent zur Klasse in der objek-
torientierten Theorie. Für jeden Entitytyp werden Attribute und Beziehungen zu anderen
Entitytypen definiert. Zudem wird das objektorientierte Konzept der Vererbung umgesetzt,
wodurch Attribute und Beziehungen an Subtypen weitergegeben werden.
Eine Beziehung (Assoziation) zwischen einem Objekt vom Typ A mit einem Objekt
vom Typ B wird dadurch ausgedrückt, dass der Entitytyp A ein Attribut vom Typ des
Entitytypen B erhält. Eine Besonderheit des EXPRESS-Standards ist, dass Attribute an-
gelegt werden können, die die inverse Beziehung explizit deklarieren. Dabei wird keine
neue Information modelliert, sondern lediglich die Navigation entlang der Beziehung in
der entgegengesetzten Richtung ermöglicht.
Eine weitere Besonderheit ist, dass Aggregations-Datentypen wie List, Array, Set und
Bag fest in die Sprache eingebaut sind, was die Definition von Beziehungen mit Gruppen
von Objekten erleichtert. Das Konstrukt der abstrakten Datentypen erlaubt es, Oberklassen
zu definieren, die selbst nicht instanziiert werden können.
EXPRESS bietet die Möglichkeit, in einem optionalen WHERE-Block algorithmische
Bedingungen festzulegen, um damit Regeln für die Konsistenz der Daten zu beschrei-
ben. Der WHERE-Block beinhaltet einen booleschen Ausdruck, der als Wahr ausgewertet
werden muss, damit die jeweilige Instanz als gültig eingestuft wird.
Abbildung 6.2 zeigt einen Ausschnitt aus dem Datenmodell des IFC-Standards, der
mittels EXPRESS definiert ist.
Mit dem Selektionstyp bietet EXPRESS neben der Vererbungshierarchie ein weiteres
Spracheelement an, um mehreren Entitytypen einem Oberkonstrukt zuzuordnen. Dieses
Oberkonstrukt kann dann als Platzhalter z. B. bei der Festlegung des Typs eines Attributs
dienen. Ein Beispiel aus dem IFC-Datenmodell ist der Selektionstyp IfcUnit, der die Aus-
wahl zwischen den Typen IfcDerivedUnit, IfcNamedUnit und IfcMonetaryUnit erlaubt.
Attribute, die ausschließlich Werte aus einer festgelegten Menge von vordefinierten
Strings annehmen können, werden in EXPRESS mithilfe des Aufzählungsdatentyps (Enu-
meration type) modelliert. Beispielsweise wird IfcBooleanOperator als Aufzählung von
UNION, INTERSECTION und DIFFERENCE definiert.
1
Im Rahmen dieses Kapitels wird der Begriff Klasse synonym zu Entitytyp verwendet.
6 Industry Foundation Classes 87
Abb. 6.3 Beispiel für ein EXPRESS-G Diagramm. Der Entitytyp Person ist ein abstrakter Supertyp
für die beiden Entitytypen Male und Female. Dies wird durch die dicke Verbindungslinie angegeben,
wobei der Kreis am Ende die Richtung der Vererbungsbeziehung angibt. Person hat ein Attribut
name vom Typ String sowie die beiden optionalen Attribute father und mother vom Typ Male bzw.
Female. Die Optionalität wird durch die gestrichelten Verbindungslinien gekennzeichnet
Neben der textuellen Notation bietet EXPRESS auch die Möglichkeit, ein Datenmo-
dell grafisch zu beschreiben. Die zugehörige Sprache wird als EXPRESS-G bezeichnet.
Abbildung 6.3 stellt die Elemente der grafischen Sprache anhand eines Beispiels vor.
Es ist wichtig, festzuhalten, dass EXPRESS dazu dient, ein Datenmodell (auch als
Schema bezeichnet) zu definieren. Es ist nicht möglich, mittels EXPRESS konkrete In-
stanzen des Datenmodells zu beschreiben. Hierfür kommen unterschiedliche Möglichkei-
ten infrage, von denen die Nutzung eines STEP Physical File (definiert in STEP Teil 21)
die am weitesten verbreitete ist. Weitere Optionen sind die Nutzung von XML-Instanzen
oder die Speicherung in einer Datenbank. Weitere Informationen hierzu sind Kap. 11 zu
entnehmen.
88 A. Borrmann et al.
Da das IFC-Datenmodell sehr umfangreich und komplex ist, wurde es zur besseren Wart-
und Erweiterbarkeit in mehrere Schichten (engl. Layers) aufgeteilt (Abb. 6.4). Generel-
les Prinzip dabei ist, dass Elemente der weiter oben liegenden Schichten auf Elemente
der weiter unten liegenden Schichten verweisen dürfen, aber nicht umgekehrt. Auf diese
Weise wird die Unabhängigkeit der Kernelemente sichergestellt.
Core Layer
Der Core Layer beinhaltet die grundlegendsten Klassen des Datenmodells. Sie können
von allen darüber liegenden Schichten referenziert werden. Hier werden Basisstrukturen,
grundlegende Beziehungen und allgemeine Konzept festgelegt, die in höher liegenden
Schichten wiederverwendet und konkretisiert werden.
Das Kernel-Schema stellt den Kern des IFC-Datenmodells dar und stellt abstrakte
Basis-Klassen wie IfcRoot, IfcObject, IfcActor, IfcProcess, IfcProduct, IfcProject, IfcRe-
lationship zur Verfügung. Darauf bauen direkt die drei Erweiterungsschemata Product
Extension, Process Extension und Control Extension auf, die ebenfalls zum Core Layer
gehören.
Das Schema Product Extension dient zur Beschreibung von physischen und räumli-
chen Objekten eines Gebäudes sowie deren Beziehungen. Es beinhaltet Subklassen von
IfcProduct wie IfcBuilding, IfcBuildingStorey, IfcSpace, IfcElement, IfcBuildingElement,
IfcOpeningElement sowie die Beziehungsklassen IfcRelAssociatesMaterial, IfcRelFills-
Element und IfcRelVoidsElement.
Das Schema Process Extensions beinhaltet Klassen zur Beschreibung von Prozessen
und Abläufen. Darüber hinaus stellt es grundlegende Möglichkeiten zur Definition von
Abhängigkeiten zwischen Prozesselementen zur Verknüpfung mit Ressourcen zur Verfü-
gung.
Das Schema Control Extension deklariert die Basisklassen für Steuerungsobjekte wie
IfcControl und IfcPerformanceHistory und stellt Möglichkeiten zur Zuweisung dieser Ob-
jekte an physische und räumliche Objekte zur Verfügung.
Shared Layer
Direkt oberhalb des Core Layer ist der Shared Layer angeordnet. Er stellt eine Zwischen-
ebene zwischen dem grundlegenden Kern des Datenmodells und den domänenspezifi-
schen Schemata dar. Darin werden Klassen definiert, die von Klassen aus dem Core Layer
abgeleitet und für eine Mehrzahl der Anwendungsschemata verwendet werden. Beispiels-
weise werden hier wichtige Bauteilklassen wie IfcWall, IfcColumn, IfcBeam, IfcPlate,
IfcWindow usw. definiert.
Domain Layer
Die domänenspezifischen Schemata beinhalten Klassen, die so spezialisiert sind, dass sie
nur einer Domäne zugeordnet werden können. Sie bilden die Blattknoten in der Verer-
bungshierarchie. Die hier definierten Klassen können nicht von einem anderen Layer oder
von einem anderen domänenspezifischen Schema referenziert werden.
Die in IFC4 definierten Domänen sind: Architektur, Gebäudesteuerung (engl. Buil-
ding Control), Bauausführung (engl. Construction Management), Elektrik, Heizungs-,
Lüftungs-, Klimatechnik (engl. HVAC – Heating, Ventilation, Air Conditioning), Sani-
tärtechnik und Brandschutz sowie konstruktive Elemente (engl. Structural Elements, wie
Gründungen, Pylone, Bewehrung etc.) und Strukturanalyse (engl. Structural Analysis).
90 A. Borrmann et al.
Resource Layer
Auf der untersten Ebene, dem Ressource Layer, liegen Schemata, die grundlegende Da-
tenstrukturen bereitstellen, die über das gesamte IFC-Datenmodell hinweg Verwendung
finden.
Die Klassen dieser Ebene sind nicht von IfcRoot abgeleitet, was bedeutet, dass sie nicht
über eine Identität verfügen (siehe Abschn. 6.4.1). Damit können sie – im Gegensatz zu
den Klassen der anderen Ebenen – nicht als eigenständige Objekte in einem IFC-Modell
existieren, sondern müssen von einem Objekt referenziert werden, das eine Subklasse von
IfcRoot instanziiert.
Zu den wichtigsten Ressourcen-Schemata gehören:
Daneben gibt es noch eine ganze Reihe weiterer Schemata auf der Ressourcenebene
(Cost, Measure, DateTime, Representation), auf die hier jedoch nicht im Detail eingegan-
gen werden soll.
Wie in jedem objektorientierten Datenmodell spielt auch in den IFC die Vererbungshier-
archie eine äußerst wichtige Rolle. Sie legt Spezialisierungs- bzw. Generalisierungsbezie-
hungen fest und damit, welche Attribute von welcher Klassen an welche vererbt werden.
Abbildung 6.5 zeigt einen Ausschnitt aus der Vererbungshierarchie.
Die Vererbungshierarchie folgt der semantischen Sichtweise, d. h. die Bedeutung ei-
nes Objekts bildet die Grundlage für die Modellierung der Vererbungsbeziehungen. Im
Folgenden sollen die wichtigsten Klassen dieser Vererbungshierarchie vorgestellt werden.
6 Industry Foundation Classes 91
IfcRoot
Abb. 6.5 Ausschnitt aus dem IFC-Datenmodell mit den wichtigsten Entitys der obersten Ebenen
der Vererbungshierarchie
Den Ausgangspunkt und die Wurzel des Vererbungsbaums bildet die Klasse IfcRoot. Al-
le Entitys, die nicht zum Resource Layer gehören, sind direkt oder indirekt von IfcRoot
abgeleitet. IfcRoot stellt dabei grundlegende Funktionalitäten zur eindeutigen Identifikati-
on mithilfe eines Unique Identifier (GUID), zur Beschreibung der Eigentümerschaft und
Herkunft eines Objekts sowie zur Abbildung der Modifikationshistorie (Identität des Er-
stellers und weiterer Bearbeiter, Versionsgeschichte etc.) zur Verfügung. Zusätzlich kann
jedes Objekt mit einem Namen und einer Beschreibung versehen werden.
Von IfcRoot werden direkt die Klassen IfcObjectDefinition, IfcPropertyDefinition und
IfcRelationship abgeleitet. Sie bilden die nächste Stufe in der Vererbungshierarchie.
Die Klasse IfcObjectDefiniton ist die abstrakte Superklasse aller Klassen, die physi-
sche Objekte (Bauteile etc.), Raum-Objekte (Aussparungen, Spaces) oder konzeptionelle
Elemente (Prozesse, Kosten etc.) repräsentieren. Sie deckt zudem Definitionen für Be-
schreibung der Beteiligten am Bauvorhaben ab. Die drei Subklassen von IfcObjectDefi-
nition sind IfcObject (einzelne Objekte des Bauvorhabens), IfcTypeObject (Objekttypen)
und IfcContext (allgemeine Projektinformation).
Die Klasse IfcRelationship und ihre Subklassen dienen zur Abbildung objektifizier-
ter Beziehungen (engl. objectified relationship). Auf diese Weise wird die Semantik der
Beziehung von den Objektattributen entkoppelt und es können beziehungsspezifische Ei-
genschaften direkt am Beziehungsobjekt gespeichert werden. Dieses Konzept wird aus-
führlich in Abschn. 6.5 erläutert.
92 A. Borrmann et al.
Die Klasse IfcPropertyDefiniton dient zur Definition von Eigenschaften eines Objektes,
die nicht fest im IFC-Datenmodell verankert sind. Näheres hierzu wird in Abschn. 6.7
ausgeführt.
Ein IfcObject repräsentiert ein individuelles Objekt (ein Ding) als Teil eines Bauprojekts.
Es bildet die abstrakte Superklasse für sechs wichtige Klassen des IFC-Datenmodells:
Die Aufteilung in die Bereiche Produkt, Prozess, Kontrollelement und Ressource ent-
sprechen dabei dem prinzipiellen Herangehen an die Modellierung von Geschäftsprozes-
sen, die bereits in den 1980er Jahren durch die IDEF-Initiative aufgestellt wurde.
IfcProduct ist die abstrakte Repräsentation aller Objekte, die in einen geometrischen oder
räumlichen Kontext eingeordnet werden können. Alle für die Beschreibung eines virtuel-
len Gebäudemodells benötigten Klassen sind Subklassen von IfcProduct. Mit ihrer Hilfe
können sowohl konkrete Bauteile als auch Raum-Objekte (Spaces) beschrieben werden.
IfcProduct-Objekten kann eine geometrische Repräsentation und eine Lage zugeordnet
werden (siehe Abschn. 6.6).
Die Subklasse IfcElement ist Superklasse einer ganzen Reihe von wichtigen Basisklas-
sen, darunter IfcBuildingElement, welche die Superklasse für alle Bauteil-Klassen wie
IfcWall, IfcColumn, IfcWindow usw. bildet.
Die IfcElement-Subklasse IfcSpatialStructureElement dient hingegen der Beschrei-
bung von nicht-physischen räumlichen Objekten. Subklassen sind IfcSite, IfcBuilding,
IfcBuildingStorey und IfcSpace. Der Aufbau einer entsprechenden Beziehungsstruktur
zwischen diesen Elementen wird im Abschn. 6.5.2 näher vorgestellt.
6 Industry Foundation Classes 93
Die IfcProduct-Subklasse IfcProxy stellt einen Platzhalter bereit, um ein Objekt, das
keinem der definierten semantischen Typen entspricht, dennoch im IFC-Modell repräsen-
tieren und ihm eine geometrische Repräsentation zuweisen zu können. Daneben besitzt
IfcProduct weitere Subklassen zur Beschreibung von Objekten, die in einen räumlichen
Kontext eingebettet werden, wie IfcAnnotation, IfcGrid und IfcPort.
6.5 Objektbeziehungen
Objektbeziehungen machen einen wichtigen Teil des IFC-Datenmodells aus. In der Tat
bilden die mächtigen Funktionen zur detaillierten Beschreibung von Beziehungen ein
Alleinstellungsmerkmal des IFC-Standards. Die Beschreibung von Beziehungen gehört
neben der semantischen Klassifizierung zu den Kernbestandteilen eines „intelligenten“
Bauwerksinformationsmodells, das Bauteile nicht nur als isolierte Körper auffasst, son-
dern ihre Funktion und ihr Zusammenspiel mit anderen Objekten in den Vordergrund
rückt. Typische Beziehungen sind etwa Teil-Ganzes-Beziehungen (Meronymie, „Südflü-
gel ist Teil des Gesamtgebäudes“), Verbindungen („Decke verbunden mit Stütze“) oder
Typendefinitionen („Träger mit HE-A 140 Profil“).
Das IFC-Datenmodell folgt dem Prinzip objektifizierter Beziehungen (vgl. Ab-
schn. 3.3.2). Das bedeutet, dass die aus semantischer Sicht relevanten Beziehungen
zwischen Objekten nicht über eine direkte Assoziation abgebildet werden, sondern
mithilfe eines gesonderten, dazwischengeschalteten Objekts, das die Beziehung selbst
repräsentiert (siehe Abb. 6.6). Ein wichtiges Prinzip der Datenmodellierung, das in den
IFC umgesetzt wurde, besteht darin, dass die Vorwärtsbeziehungen (die definierten Attri-
bute) immer vom Beziehungsobjekt ausgehen und auf die in Beziehung gesetzten Objekte
zeigen. Die entsprechenden Attribute am Beziehungsobjekt tragen immer Namen nach
dem Schema related . . . Element und relating . . . Element. Von den in Beziehung ste-
henden Objekten zum Beziehungsobjekt lässt sich über dazugehörige inverse Attribute
navigieren.
Beziehungsobjekte sind immer Instanzen einer Subklasse von IfcRelationship. Der
Vererbungsbaum der Objektbeziehungen ist in Abb. 6.7 dargestellt. Das Element IfcRe-
IfcVoidsElement IfcFillsElement
Abb. 6.6 Das Prinzip der objektifizierten Beziehungen illustriert anhand des Beispiels Wand-Öff-
nung-Fenster
94 A. Borrmann et al.
IfcRelationship
IfcRelContained IfcRelReferenced
IfcRelAssociatesMaterial IfcRelFillsElement
InSpatialStructure InSpatialStructure
lationship bildet die Wurzel. Jede Beziehung kann eine informelle Beschreibung tragen,
die den genauen Zweck der Anwendung dieser Beziehung wiedergibt.
Die folgenden sechs Beziehungstypen haben grundlegende Funktionen im IFC-Daten-
modell:
Der Einsatz und die Verwendung der einzelnen Beziehungstypen werden in den fol-
genden Unterabschnitten erläutert.
Ein wichtiges grundlegendes Konzept der Beschreibung von Gebäuden mittels IFC ist
die Abbildung der Aggregationsbeziehungen zwischen Raum-Objekten auf unterschied-
lichen Hierarchiestufen. Alle Klassen mit räumlicher Semantik erben Attribute und Ei-
genschaften von der Klasse IfcSpatialStructureElement. Im Einzelnen sind das IfcSite zur
6 Industry Foundation Classes 95
Eine Reihe von Anwendung im BIM-Kontext benötigt den Zugriff auf die Beziehung
zwischen einem Raum-Objekt und den Objekten, die diesen Raum umgrenzen (Wände,
Decken). Dazu gehören beispielsweise Programme für die Mengenermittlung (s. Kap. 21),
aber auch Anwendungen für die Berechnung des Energiebedarfs (s. Kap. 18). Zur Model-
lierung dieser Beziehung wird im IFC-Datenmodell die Beziehungsklasse IfcRelSpace-
Boundary eingesetzt (Weise et al. 2009). Sie verweist über das Attribut RelatingSpace auf
das Raum-Objekt und über RelatedBuildingElement auf das Bauteil (siehe Abb. 6.10).
Zusätzlich ist es möglich, das Beziehungsobjekt mit einem Objekt der Klasse Ifc-
ConnectionGeometry zu verknüpfen, das die Berührungsfläche zwischen Raum und Bau-
teil beschreibt. Dies kann für bestimmte Berechnungen und Simulationen eine wertvolle
Informationsquelle darstellen.
96 A. Borrmann et al.
Abb. 6.8 Beispiel für die Abbildung der hierarchischen Aggregationsbeziehungen zwischen
Raum-Objekten im IFC-Modell (Instanz-Diagramm) (IFC-Dokumentation)
6 Industry Foundation Classes 97
#6=IfcBuilding
RelatingObject
#2=IfcRelAggregates
#10 = Second floor
#8=IfcBuildingStorey
#9=IfcBuildingStorey
#9 = First floor
#10=IfcBuildingStorey
#13=IfcRelContainedIn
SpatialStructure
#14=IfcRelReferenced
InSpatialStructure
RelatedElements
#8 = Ground floor #15=IfcRelReferenced
InSpatialStructure
#11=IfcCurtainWall
Level 1 Space Boundary: Umgrenzung des Raums ohne Berücksichtigung des Wech-
sels von Bauteilen bzw. Räumen auf der anderen Seite,
Level 2 Space Boundary: Umgrenzung des Raums mit Berücksichtigung des Wechsels
von Bauteilen bzw. Räumen auf der anderen Seite,
– Level 2, Typ A: Auf der anderen Seite befindet sich ein Space,
– Level 2, Typ B: Auf der anderen Seite befindet sich ein Bauteil.
IfcWallStandardCase
Abb. 6.10 Die Beziehungen zwischen einem Raum-Objekt und den begrenzenden Bauteilen wer-
den über Instanzen der Beziehungsklasse IfcRelSpaceBoundary abgebildet (IFC-Dokumentation)
Die Angabe von Materialien ist ein wichtiger Bestandteil eines digitalen Gebäudemo-
dells. Nur wenn Informationen zu Materialien der einzelnen Bauteile hinterlegt sind,
ist beispielsweise eine sinnvolle automatisierte Mengenermittlung möglich. Aber auch
Berechnungen und Simulationen wie die statischen Nachweise oder Energiebedarfsbe-
rechnungen benötigen die Informationen zu den verwendeten Baumaterialen und ihren
Parametern. Eine wichtige Fähigkeit des IFC-Modells ist es, Bauteile abzubilden, die
aus mehreren Materialien bestehen. Typisches Beispiel hierfür ist eine mehrschichtige
Wand.
Materialien werden mithilfe der Beziehungsklasse IfcRelAssociatesMaterial mit einem
Bauteil (einer beliebigen Subklasse von IfcElement) verknüpft. Das Attribut RelatingMa-
terial verweist dabei üblicherweise auf ein Objekt der Klasse IfcMaterialDefinition, die
mehrere Unterklassen besitzt, von denen die wichtigsten im Folgenden aufgeführt wer-
den:
6 Industry Foundation Classes 99
Abb. 6.11 Unterschiede zwischen den Space Boundaries auf Level 1, Level 2a und Level 2b. Auf
Level 1 wird die Umgrenzung des Raums ohne Berücksichtigung des Wechsels von Bauteilen bzw.
Räumen auf der anderen Seite modelliert, Level 2 berücksichtigt diese Wechsel und unterteilt die
Flächen entsprechend. Level 2 Typ A beinhaltet alle Flächen, bei denen sich auf anderen Seite ein
Space befindet, Typ B beinhaltet alle Flächen, bei denen sich auf der anderen Seite ein Bauteil
befindet (IFC-Dokumentation)
IfcRelAssociatesMaterial
IfcWall IfcMaterialLayerSet
IfcMaterialLayer
IfcMaterial
Abb. 6.12 Beispiel der Verknüpfung eines Bauteils mit seinen Materialien mithilfe der Beziehungs-
klasse IfcRelAssociatesMaterial anhand einer mehrschichtigen Wand
Die Klasse IfcMaterial stellt das Attribut Name für die eindeutige Bezeichnung zur
Verfügung und erlaubt die Klassifikation des Materials anhand eines externen Klassifika-
tionssystems durch Verknüpfung via IfcExternalReferenceRelationship.
Des Weiteren ist die Angabe von Materialparametern durch Verknüpfung mit einem
oder mehreren Objekten des Typs IfcMaterialProperties möglich, die über das inver-
se Attribut HasProperties erreicht werden können. Die Klasse IfcMaterialProperties
beschreibt einen Satz von Materialeigenschaften in Form einer Name-Wert-Liste (sie-
he Abschn. 6.7). Dabei gibt es eine Reihe von vordefinierte Eigenschaftssätzen (Property
Sets) für mechanische Eigenschaften (PSet_MaterialMechanical), optische Eigenschaften
(Pset_MaterialOptical), thermische Eigenschaften (Pset_MaterialThermal), Parameter
für die Energiebedarfsberechnung (Pset_MaterialEnergy) usw. Spezifische Parametersät-
ze wurden für die weit verbreiteten Baustoffe Beton, Stahl und Holz definiert.
Mit einem IfcMaterial können auch Darstellungsinformationen assoziiert werden.
Hierfür verweist das inverse Attribut HasRepresentation auf ein Objekt vom Typ IfcMa-
terialDefinitionRepresentation, welches die Festlegung von Linientyp und -dicke sowie
Schraffur (für die 2D-Darstellung) bzw. von die Bereitstellung von Information für das
Rendering der Oberfläche (für die photorealistische 3D-Darstellung) erlaubt.
Das IFC-Datenmodell trennt strikt zwischen der semantischen Beschreibung eines Bau-
teils und seiner geometrischen Repräsentation. Dabei ist die semantische Repräsentation
führend, d. h. ein wie auch immer geartetes Objekt eines Bauvorhabens wird zunächst als
semantische Entität beschrieben und kann anschließend mit einer oder mehreren geome-
6 Industry Foundation Classes 101
IfcProduct IfcProductRepresentation
IfcBuildingElement IfcGeometricRepresentationItem
Abb. 6.13 Das IFC-Datenmodell trennt strikt zwischen semantischer und geometrischer Beschrei-
bung. Dies erlaubt es, dass ein semantisches Objekt flexibel mit einer oder mehreren geometrischen
Repräsentationen gekoppelt werden kann
trischen Repräsentationen verknüpft werden (Abb. 6.13). Das Konzept der Identität greift
entsprechend nur für die semantischen Objekte, nicht jedoch für die geometrischen Re-
präsentationen.
Durch die Möglichkeit, verschiedene geometrische Repräsentationen mit einem Objekt
zu verknüpfen, wird dem Umstand Rechnung getragen, dass verschiedene Anwendungs-
szenarien unterschiedliche Geometriebeschreibungen benötigen. Beispielsweise brauchen
reine Visualisierungsprogramme in der Regel nur eine einfache dreiecksbasierte Beschrei-
bung, während BIM-Modellierwerkzeuge, eine hochwertige BRep- bzw. CSG-Beschrei-
bung benötigen, um Änderungen am Modell vornehmen zu können. Darüber hinaus ist
es auch möglich ist, eine 2D-Repräsentation mit einem semantischen Objekt zu verknüp-
fen, um damit das Vorhalten einer normgerechten Bauzeichnung in einem IFC-Modell zu
realisieren.
Die Konsistenz zwischen den einzelnen Repräsentationen müssen die modellerzeu-
genden Programme sicherstellen. Das IFC-Datenmodel selbst stellt keine entsprechenden
Funktionalitäten zur Verfügung.
Das IFC-Modell setzt ein weites Spektrum der in Kap. 2 vorgestellten Geometriemodelle
um. In diesem Abschnitt sollen die wichtigsten geometrischen Repräsentationen erläutert
werden.
Alle für die Geometriemodellierung benötigten Klassen gehören zu einer der drei Sche-
mata Geometric Model Resource, Geometry Resource, oder Topology Ressource. Zum
großen Teil wurden die Definitionen und Datenstrukturen unverändert vom STEP-Stan-
dard Teil 42 übernommen, im Bereich der indizierten Geometriebeschreibungen auch vom
X3D Standard ISO (2004a).
102 A. Borrmann et al.
Kurven in 2D und 3D
Für die Modellierung von linienförmigen Objekten stehen die Klasse IfcCurve mit den
Unterklassen IfcBoundedCurve, IfcConic, IfcLine zur Verfügung. Mithilfe der Klasse Ifc-
BSplineCurve können dabei auch Freiform-Kurven modelliert werden (vgl. Kap. 2). Mit-
tels IfcCompositeCurve können komplexe Kurven aus beliebig vielen Teilkurven zusam-
mengesetzt werden.
Das IFC-Datenmodell sieht explizit vor, dass neben der 3D-Geometrie auch 2D-Reprä-
sentationen der semantischen Objekte für die Plandarstellung vorgehalten werden können.
In diesem Fall muss die Dimensionalität der entsprechenden IfcCurve-Objekte auf 2 fest-
gelegt werden. Auf diese Weise lassen sich auch Profile als Grundlage für Extrusionsope-
rationen u. ä. modellieren.
Bounding Box
Die Bounding Box stellt eine extrem vereinfachte Geometrierepräsentation für dreidi-
mensionale Objekte dar, die häufig nur als Platzhalter bzw. in Kombination mit einer
detaillierten Beschreibung verwendet wird. Die Klasse IfcBoundingBox erlaubt die An-
gabe eines Eckpunktes und der drei Kantenlängen des umhüllenden Quaders.
Flächenmodelle
Flächenmodelle bieten die Möglichkeit, aus mehreren ebenen Teilflächen zusammenge-
setzte Oberflächen zu beschreiben. Sie finden Anwendung, um flächige Objekte (z. B. eine
Geländeoberfläche) oder sehr flache Körper (z. B. Bleche) zu modellieren. Darüber hin-
aus können auch 3D-Körper abgebildet werden. In diesem Fall liegt der Vorteil gegenüber
der BRep-Modellierung in der einfacheren Datenstruktur, der Nachteil liegt in der ein-
geschränkten Prüfbarkeit der Korrektheit des modellierten Körpers z. B. in Hinblick auf
Spalten und Überlappungen in der Oberfläche.
Es gibt zwei verschiedene Varianten von Flächenmodellen im IFC-Datenmodell
(Abb. 6.14). Das IfcFaceBasedSurfaceModel erlaubt die Modellierung von einfachen
Körpern ohne Hohlräume, das IfcShellBasedSurfaceModel hingegen ermöglicht die Mo-
dellierung von Körpern mit Hohlräumen durch Zwischenschalten einer beliebigen Zahl
6 Industry Foundation Classes 103
von IfcShell-Objekten. Hierbei wird zwischen offenen Schalen (IfcOpenShell) und ge-
schlossenen Schalen (IfcClosedShell) unterschieden.
Triangulierte Flächenbeschreibung/Tessellation
Eine in der Computergrafik recht weit verbreitet Methode ist zur Beschreibung von Geo-
metrie ist die Nutzung von Dreiecksnetzen. Diese sehr allgemeine und einfache Form
der Geometriebeschreibung kann von nahezu allen Visualisierungsapplikationen interpre-
tiert werden. Einschränkend ist zu erwähnen, dass gekrümmte Flächen damit nicht präzise
sondern nur angenähert abgebildet werden können, dass der Speicherverbrauch sehr hoch
ist und die Modifizierbarkeit der Geometrie durch die empfangende Anwendung stark
eingeschränkt ist. Die Nutzung dieser Geometrierepräsentation für die Übertragung von
Gebäudegeometrie muss also sorgfältig abgewogen werden. Ein unproblematische An-
wendung liegt in der Beschreibung der Geländeoberfläche (engl. Digital Terrain Model,
DTM).
Das IFC-Datenmodell stellt hierfür die Klasse IfcTriangulatedFaceSet zur Verfügung.
Sie ist von der Klassen IfcTessellatedFaceSet abgeleitet, die das allgemeine Prinzip tes-
sellierter Flächenbeschreibungen repräsentiert, also auch Polygone mit beliebiger Kanten-
zahl umfasst. IfcTessellatedFaceSet ist nicht von IfcSolidModel abgeleitet, sondern erbt
von IfcTesselatedItem.
Die IFC-Modell setzt hier das in Kap. 2 beschriebene Verfahren Indexed Face Set
um. Hierzu verweist die Klasse IfcTriangulatedFaceSet mit dem Attribut Coordinates auf
ein Objekt vom Typ IfcCartesianPointList3D, welches eine Liste von Punkten beinhaltet
(Abb. 6.15). Ein weiteres Attribut CoordIndex verweist für jedes Dreieck auf die Indizes
der drei Eckpunkte in der Koordinatenliste. Optional können mithilfe des Attributs Nor-
mals auch die Normalen für jedes Dreieck angegeben werden. Darüber hinaus ist auch die
indexbasierte Verknüpfung mit Farbwerten oder Texturen möglich.
104 A. Borrmann et al.
IfcGeometric
RepresentationItem
IfcTesselatedItem
IfcTesselatedFaceSet IfcCartesianPointList3D
IfcTriangulatedFaceSet
Solid Modeling
Das IFC-Datenmodell bietet unterschiedliche Verfahren zur Darstellung massiver 3D-
Körper. Sie werden durch die abstrakte Superklasse IfcSolidModel und ihre Kindklassen
IfcCsgSolid, IfcManifoldSolidBRep, IfcSweptAreaSolid und IfcSweptDiskSolid repräsen-
tiert (Abb. 6.16). Im Folgenden sollen die einzelnen Verfahren im Detail beschrieben
werden.
(ABS)
IfcSolidModel
(ABS)
IfcSweptAreaSolid IfcCsgSolid IfcManifoldSolidBrep
IfcExtrudedAreaSolid
IfcFacetedBrep IfcAdvancedBrep
IfcRevolvedAreaSolid
IfcFacetedBrepWithVoids IfcAdvancedBrepWithVoids
IfcSurfaceCurve
SweptAreaSolid
IfcFixedReference
SweptAreaSolid
Abb. 6.16 Das IFC-Datenmodell stellt eine Vielzahl von Möglichkeiten zur Modellierung von Vo-
lumenkörpern (Solids) zur Verfügung
6 Industry Foundation Classes 105
IfcFacetedBrep
IfcClosedShell
IfcFace
IfcFaceOuterBound IfcFaceBound
IfcPolyLoop
IfcCartesianPoint
Abb. 6.17 Datenstruktur zur Abbildung von Körper mit ebenen Flächen und geraden Kanten (IFC-
Dokumentation)
106 A. Borrmann et al.
Zunächst soll die mit der Klasse IfcFacetedBrep assoziierte Datenstruktur betrach-
tet werden, die zur Modellierung von Körpern mit ebenen Berandungsflächen dient
(Abb. 6.17). Den Ausgangspunkt bildet ein IfcFacetedBrep-Objekt, dessen Attribut Outer
ein Objekt vom Typ IfcClosedShell referenziert, welches wiederum auf eine Menge von
IfcFace-Objekten verweist. Jedes der IfcFace-Objekte kann beliebig viele Berandungen
(IfcFaceBound) besitzen, wobei ein Polygonzug als IfcFaceOuterBound modelliert sein
muss, um die äußere Berandung zu markieren. Jedes IfcFaceBound-Objekt verweist auf
ein IfcLoop-Objekt, welches auf eine geordnete Liste von Punkten (die Eckpunkte des
Körpers) verweist. Wichtig ist, dass gleiche Objekte (Punkte, Kanten) nicht mehrmals
instanziiert, sondern lediglich mehrfach referenziert werden.
Die Datenstruktur zur Beschreibung von Körpern mit gekrümmten Oberflächen er-
weitert diese weitgehend topologische Datenstruktur um Elemente zur Modellierung des
geometrischen Verlaufs von Flächen und Kanten (Abb. 6.18). Der Ausgangspunkt ist
hierbei die Klasse IfcAdvancedBrep. Auch diese wird wiederum mit einem IfcClosed-
Shell-Objekt verknüpft. Dieses verweist nun aber auf Flächen-Objekte vom Typ IfcAd-
vancedFace. Diese werden – im Gegensatz zu den einfachen IfcFace-Objekten – mit
einer expliziten Geometriebeschreibung versehen. Dabei kann es sich um eine NURBS-
Fläche handeln, die als IfcBSplineSurface modelliert wird. Objekte dieser Klasse verwei-
sen auf die entsprechenden Kontrollpunkte und stellen alle notwendigen Parameter zur
mathematischen Beschreibung einer NURBS-Fläche zur Verfügung (siehe Kap. 2). Zur
Modellierung des (gekrümmten) Verlaufs von Kanten können diese mit IfcBSplineCurve-
Objekten verknüpft werden, welche wiederum auf die Kontrollpunkte und die entspre-
chenden Parameter verweisen.
IfcAdvancedBrep
IfcClosedShell
IfcBSplineSurface
IfcAdvancedFace
WithKnots
IfcCartesianPoint
IfcFaceOuterBound IfcFaceBound
IfcEdgeLoop
IfcOrientedEdge
IfcBSplineCurve
IfcEdgeCurve
WithKnots
IfcCartesianPoint
IfcVertexPoint IfcVertexPoint
IfcCartesianPoint IfcCartesianPoint
Abb. 6.18 Datenstruktur zum Abbildung von Körper mit gekrümmten Flächen und Kanten (IFC-
Dokumentation)
Clipping
Mit dem Clipping können Körper modelliert werden, die an einer Ebene abgeschnitten
(gekappt) werden. Umgesetzt wird das Clipping als eine spezielle Form des CSG-An-
satzes. Dabei ist der erste Operand immer ein Volumenkörper (IfcSolidModel) und der
zweite Operand ein Halbraum-Körper (IfcHalfSpaceSolid), der über eine Ebene und eine
Richtung definiert wird. Der angewendete Operator ist immer DIFFERENCE. Das Clip-
ping kann an beliebiger Stelle als Knoten in einem CSG-Baum auftauchen. Clippings
werden u. a. eingesetzt, um an der Oberkante abgeschrägte Wände zu modellieren (siehe
Abb. 6.20).
108 A. Borrmann et al.
IfcCsgSolid IfcCsgSelect
IfcBooleanResult IfcBooleanOperand
IfcBooleanOperator IfcHalfSpaceSolid
IfcCSGPrimite3D
IfcBooleanClippingResult IfcSolidModel
Abb. 6.19 Datenstruktur für Beschreibung von Körper auf Basis des CSG-Verfahrens
Abb. 6.20 Clippings werden häufig eingesetzt, um an der Oberkante abgeschrägte Wände zu mo-
dellieren (IFC-Dokumentation)
Bei Verwendung der Klasse IfcExtrudedAreaSolid dient dieses Profil als Grundlage für
eine Extrusionsoperation entlang einer gegebenen Richtung (Attribut ExtrudedDirection)
über eine gegebene Weglänge (Attribut Depth). Bei Nutzung der Klasse IfcRevolvedArea-
Solid wird das Profil um eine gegebene Achse (Attribut Axis) bis zu einem gegebenen
Winkel (Attribut Angle) rotiert.
Die Klasse IfcFixedReferenceSweptAreaSolid erlaubt es, ein Objekt als Ergebnis des
Sweepings eines Profils entlang einer beliebigen Raumkurve (Attribut Directrix) darzu-
stellen. Das Besondere an dieser Repräsentation ist, dass sich das Profil während des
Sweeps nicht verdreht, sondern an einer vorgegebenen Referenzachse (Attribut FixedRe-
ference) ausgerichtet bleibt.
Mithilfe von Instanzen der Klasse IfcSectionedSpine ist es möglich, Objekte zu be-
schreiben, die durch lineare Interpolation zwischen hintereinander angeordneten Profilen
entstehen (Abb. 6.22a). Dabei verweist das Attribute auf ein IfcCompositeCurve-Objekt,
das eine zusammengesetzte Kurve beschreibt, deren Segmente jeweils zwischen zwei
Profilen liegen. Das Attribut CrossSections verweist auf eine Liste von Profilen, deren
Positionen durch das Attribut CrossSectionPositions festgelegt sind.
Die Klasse IfcSweptDiskSolid ist nicht von IfcSweptArea abgeleitet, sondern direkt von
IfcSolidModel. Das zugrundeliegende Profil ist immer eine kreisförmige Scheibe. Sie wird
entlang einer beliebigen Raumkurve (Attribut Directrix) geführt (Abb. 6.22b). Im Unter-
schied zu IfcFixedReferenceSweptAreaSolid bleibt das Kreisprofil nicht fix ausgerichtet,
sondern wird während des Sweeps so gedreht, dass es immer senkrecht zur Raumkurve
steht.
110 A. Borrmann et al.
a b
Die geometrische Modellierung im IFC-Datenmodell basiert sehr stark auf der Verwen-
dung eines lokalen Koordinatensystems. Auf diese Weise werden beispielsweise die Eck-
punkte eines Wandobjekts nicht global gesetzt, sondern in Bezug auf das Koordinatensys-
tem der zugehörigen Etage. Diese wird wiederum in Bezug auf das Koordinatensystem des
Gebäudes modelliert usw. Die hierarchische Einbettung des Koordinatensystems ermög-
licht eine große Flexibilität bei Änderungen. So müssen bei Modifikation der Höhenlage
des Gebäudes nur an einer Stelle Koordinaten neu gesetzt werden, alle relativen Koordi-
naten bleiben unverändert.
Im IFC-Datenmodell wird dieses Konzept mit dem Begriff Local Placement bezeich-
net. Hierfür werden zwei Klassen zur Verfügung gestellt, die von IfcObjectPlacement
erben (Abb. 6.23). Die Klasse IfcLocalPlacement ist von IfcObjectPlacement abge-
leitet und stellt zwei Attribute zur Verfügung: Das optionale Attribut PlacementRelTo
verweist auf das IfcObjectPlacement, das das Eltern-Koordinatensystem bereitstellt. Ist
es nicht gesetzt, wird das betreffende Objekt absolut im Weltkoordinatensystem plat-
ziert. Das Attribut RelativePlacement verweist auf ein IfcAxis2Placement-Objekt, dass
die Transformation zwischen dem Eltern-Koordinatensystem und dem eingebetteten
lokalen Koordinatensystem festlegt. Dabei kann es sich entweder um eine 2D-Trans-
formation (IfcAxis2Placement2D) oder eine 3D-Transformation (IfcAxis2Placement3D)
handeln.
Abbildung 6.24 zeigt die Funktionsweise des IfcAxis2Placement3D-Objektes. Die La-
ge des Ursprungspunktes des lokalen Koordinatensystems in Bezug auf das Eltern-Ko-
ordinatensystem wird über das Attribut Location festgelegt. Die Verdrehung des lokalen
Koordinatensystems wird über zwei Vektoren angegeben: Der Vektor Axis legt die Rich-
tung der lokalen Z-Achse fest, während der Vektor RefDirection die Richtung der lokalen
X-Achse festlegt. Die beiden Vektoren müssen senkrecht aufeinander stehen. Die Klas-
6 Industry Foundation Classes 111
IfcGeometricRepresentationItem IfcObjectPlacement
Abb. 6.23 Die Vererbungshierarchie der Entitys zur Beschreibung von Lagebeziehungen
Einige grundlegende Merkmale von Objekten, wie zum Beispiel Tür- und Wandelemen-
ten, sind im IFC-Modell mithilfe von Attributen in einer Entity-Definition direkt im Sche-
112 A. Borrmann et al.
Abb. 6.26 Verschiedene Formen von Grids, an denen Bauteile ausgerichtet werden können
ma abgelegt. Für Standardtüren sind dies beispielsweise die absolute Höhe und Breite
der Tür, die mit den Attributen OverallWidth und OverallHeight bei der Instanziierung
eines Türobjektes angegeben werden können. Die vielen weiteren wichtigen und wün-
schenswerten Merkmale von Türen (Brandschutz, Sicherheit, Wärmeschutz etc.) würden
das ohnehin umfangreiche Schema weiter aufblähen und Implementierungen langwieri-
ger machen. Auch wären alle nicht vorhergesehenen oder international standardisierten
Merkmale, deren Gebrauch vom Nutzer gewünscht wird, ohne Änderungen am Schema
kaum möglich.
Um diesen Probleme zu begegnen, wurde im IFC-Modell eine Zweiteilung von Merk-
malsdefinitionen vorgenommen: Die statisch im Schema definierten Attribute und die
dynamisch erzeugbaren Eigenschaften (engl. properties). Solche Eigenschaften können
mithilfe der Subklassen der IfcProperty (meist IfcPropertySingleValue) frei definiert und
in beliebiger Anzahl im Instanzmodell hinzugefügt werden. Die Definition einer neu-
en Objekteigenschaft geschieht dabei über einfache Name-Wert-Datentyp-Einheit Tupel,
wie beispielsweise: „Name: ,Feuerfestigkeitsklasse‘; Wert: ,F30‘; Datentyp: ,IfcLabel‘“.
6 Industry Foundation Classes 113
IfcDoor
IfcRelAssignsProperties
IfcPropertySet IfcPropertySet
Archicad parametric Pset Door Common
IfcPropertySingleValue 2.6
Thermal Transmittance
IfcPropertySingleValue W/(m2K)
Materiaalsoort IfcPropertySingleValue
Is External True
Hout
IfcPropertySingleValue IfcPropertySingleValue
Omniclass Nummer Fire Rating F560
23.30.10.00
Abb. 6.27 Beispielhafte Verwendung von Properties (Eigenschaften). Links Ad hoc auf Instanze-
bene zugewiesene Eigenschaften. Rechts Eigenschaften aus einem standardisierten Property Set
Der Nachteil dieser Dynamisierung und Auslagerung der Semantik ist die große An-
zahl und Beliebigkeit der Objekte und Eigenschaften, die so von verschiedenen Parteien
für denselben Zweck definiert werden können: Was bei einem Nutzer „Feuerfestigkeits-
klasse“ heißt, wird vom anderen „Brandschutzkennzahl“ genannt. Um diese Mehrfachde-
finition zu vermeiden, (die ja das ursprüngliche Dilemma und der Grund für den Man-
gel an Interoperabilität sind, dem der IFC-Standard zu begegnen versucht) werden die
gebräuchlichsten Eigenschaften ebenfalls gemeinsam von Anwendern und Entwicklern
standardisiert.
Statt sie jedoch fest im Schema zu verankern, werden sie als separate Dateien, einge-
bettet in die Dokumentation des Modells, auf den Webseiten der buildingSMART-Orga-
nisation bereitgestellt. Diese PropertySet Definitionen werden als einfache XML-Dateien
gespeichert, die der Namensgebung „Pset_*.xml“ folgen, also bspw. ,Pset_DoorCommon.
xml‘. Vielen Objektklassen wie den Bauelementen (Dach, Wand, Stütze etc.) sind um-
fangreiche Sammlungen dieser standardisierten Eigenschaften zugeordnet. Der Türklas-
sen IfcDoor bzw. IfcDoorType etwa sind neben der Sammlung PSet_DoorCommon mit
16 Eigenschaften (etwa „Schallschutzklasse“ und „Notausgang“) auch Pset_DoorWindow
GlazingType und Pset_DoorWindowShadingType (Verglasungs- und Verschattungseigen-
schaften) zugeordnet. Zusammen mit den Tür-spezifischen Eigenschaften für Zargen, Fut-
ter und Blätter, und den für alle Bauelemente geltenden Eigenschaften (Umweltschutza-
spekte, Garantie- und Serviceeigenschaften, Herstellerinformationen etc.) stehen zur Be-
schreibung von Türen mehr als 135 Eigenschaften zur Verfügung.
Da die Verwaltung und Pflege dieser wachsenden Zahl von Zusatzinformationen mittels
einzelner loser Dateibestände ineffektiv wird, ist die buildingSMART-Organisation seit
der Version 2 × 3 dazu übergegangen, die standardisierten PropertySet-Definitionen in der
Datenbank des buildingSMART Data Dictionary (bSDD, siehe auch Kap. 9) zu verwalten.
Neben der leitenden englischen Definition sind für viele Eigenschaften darüber hinaus
auch Übersetzungen in anderen Sprachen erhältlich, etwa Deutsch, Französisch, Japanisch
und Chinesisch.
Zusätzliche Erweiterungsmöglichkeiten des IFC-Modells stehen mit direkten Verwei-
sen auf Eigenschaften in externen Klassifikations- und Produktbibliotheken wie dem
bSDD zur Verfügung. Ihnen ist im Kap. 9 ein eigener Abschnitt gewidmet.
Zukünftige Entwicklungen etwa im Bereich des „Semantic Web“ lassen weitere Dyna-
misierungen und damit noch flexiblere Erweiterungsmöglichkeiten erwarten.
IfcRelDefines
IfcObject IfcTypeObject
ByType
IfcRelDefines
ByProperties
IfcPropertySet IfcPropertySet
IfcProperty IfcProperty
IfcObjectPlacement
IfcProductDefinitionShape
IfcShapeRepresentation IfcRepresentationMap
IfcMappedItem IfcAxis2Placement3D
IfcShapeRepresentation
IfcCartesianTransformation
Operator3D
Abb. 6.29 Beispiel für die Verwendung von Objekttypen in IFC – ein Instanzobjekt wird mit einem
Typobjekt assoziiert, das eine geometrische Repräsentation vorhält, die mithilfe des MappedItem-
Konzepts für das Instanzobjekt verwendet wird (IFC-Dokumentation)
erreicht werden (siehe Abb. 6.29). Ähnlich dem aus dem CAD-Bereich bekannten Block-
Konzept wird dabei zunächst eine geometrische Repräsentierung der Form (IfcShape-
Representation) erzeugt und zusammen mit einem lokalen Koordinatensystem in einem
IfcRepresentationMap Objekt abgelegt. Diese wird dann, wie die semantischen IfcProper-
tySets, dem Typobjekt (IfcTypeObject) – z. B. also einem Türtyp zugeordnet. Bei der Er-
zeugung einer Türinstanz wird anschließend auf diese IfcRepresentationMap verwiesen.
Die räumliche Positionierung der Elementinstanz wird durch eine lokale Transformati-
on (IfcCartesianTransformationOperator) bestimmt. Mithilfe dieser Transformation kann
neben Position und Rotation dabei auch die Skalierung der Instanz verändert werden. Da-
von ist jedoch in der Praxis meist abzusehen, da es leicht zu Inkonsistenzen kommen kann
und einfache Skalierungen nicht parametrisch sind, d. h. bspw. ein in der Breite über sol-
che Transformation skalierte Fenster skaliert ebenso ungewünscht Profile und Beschläge,
6 Industry Foundation Classes 117
statt sie, wie bei einem vollwertigen parametrischen Objekt, entsprechend neu anzuord-
nen.
Im Folgenden dient eine Wand mit einem Fenster als einfaches Beispiel für ein Bauwerks-
modell, welches auf Basis der IFC modelliert und in der Datei HelloWall.ifc gespeichert
wird.2 Abbildung 6.30 zeigt das Beispielmodell in einem IFC-Viewer. Zur Speicherung
einer IFC-Datei wird das im Teil 21 des STEP-Standards definierte alphanumerische Da-
teiformat verwendet (ISO 2002). Generell ist eine IFC-Datei aus zwei Abschnitten aufge-
baut: (1) HEADER-Abschnitt für Dateiinformationen und (2) DATA-Abschnitt für Pro-
jektinformationen. Dateiinterne Objektidentifikatoren werden im STEP P21 Dateiformat
durch eine natürliche Zahl mit vorangestelltem #-Zeichen angegeben.
Die erste Zeile gibt an, dass es sich um eine Datei des im STEP-Standard ISO 10303
Part 21 definierten physischen Dateiformates handelt. Anschließend folgt der Abschnitt
HEADER. Die Dateibeschreibung (FILE_DESCRIPTION) zeigt an, welcher Model View
2
Das Beispiel ist verfügbar unter: http://www.buildingsmart-tech.org/implementation/get-started/
hello-world/example-1. Zugriff am 09.06.2015.
118 A. Borrmann et al.
Definition (vgl. Kap. 7) diese Datei genügt; hier dem Coordination View mit zusätzlichen
Elementen des Quantity Take-off Views. Der Eintrag FILE_NAME beinhaltet Informa-
tionen zum Dateinamen, zum Datum der Dateierstellung, zum Benutzer, zur Organisation
des Benutzers, zur verwendeten Software und zur bevollmächtigten bzw. weisungsbefug-
ten Person. Abschließend wird die Version des verwendeten IFC-Schemas definiert, hier
die Version IFC 2 × 3.
ISO-10303-21;
HEADER;
FILE_DESCRIPTION ((’ViewDefinition [CoordinationView,
QuantityTakeOffAddOnView]’), ’2;1’);
FILE_NAME (’HelloWall.ifc’, ’2014-10-20T17:02:56’, (’Architect’),
(’Building Designer Office’), ’My IFC tool’, ’My IFC tool’,
’Max Mustermann’);
FILE_SCHEMA ((’IFC2X3’));
ENDSEC;
Der nächste Abschnitt beinhaltet Informationen zum Projekt. Zunächst wird das IFC-
Projekt (#1) mit global eindeutigem Identifikator (0YvctVUKr0kugbFTf53O9L) als Wur-
zelelement für den Dateiaustausch im Rahmen des Coordination Views festgelegt. Fer-
ner werden Angaben zur Besitzerhistorie (#2), zu Grundmaßeinheiten (#7-#19) und zum
Kontext der verwendeten geometrischen Repräsentationsart (#20-#22), inkl. einer Genau-
igkeitsanforderung (0.00001) und des relativen Einfügepunkts (0, 0, 0), gemacht.
DATA;
#1 = IFCPROJECT(’0YvctVUKr0kugbFTf53O9L’, #2, ’Default Project’,
’Description of Default Project’, $, $, $, (#20), #7);
#2 = IFCOWNERHISTORY(#3, #6, $, .ADDED., $, $, $, 1217620436);
#3 = IFCPERSONANDORGANIZATION(#4, #5, $);
#4 = IFCPERSON(’ID001’, ’Mustermann’, ’Max’, $, $, $, $, $);
#5 = IFCORGANIZATION($, ’MF’, ’Musterfirma’, $, $);
#6 = IFCAPPLICATION(#5, ’0.10’, ’My IFC tool’, ’TA 1001’);
#7 = IFCUNITASSIGNMENT((#8, #9, #10, #11, #15, #16, #17, #18, #19));
...
#11 = IFCCONVERSIONBASEDUNIT(#12, .PLANEANGLEUNIT., ’DEGREE’, #13);
#12 = IFCDIMENSIONALEXPONENTS(0, 0, 0, 0, 0, 0, 0);
#13 = IFCMEASUREWITHUNIT(IFCPLANEANGLEMEASURE(1.745E-2), #14);
...
#20 = IFCGEOMETRICREPRESENTATIONCONTEXT($, ’Model’, 3, 1.000E-5,
#21, $);
#21 = IFCAXIS2PLACEMENT3D(#22, $, $);
#22 = IFCCARTESIANPOINT((0., 0., 0.));
ein Stockwerk (#35) existieren. Die Ebenen für Gebäude und Stockwerke sind jeweils
optional. Die Baustelle befindet sich im globalen Weltkoordinatensystem an der Positi-
on 24° 280 000 Nord, 54° 250 000 West. Das lokale Baustellenkoordinatensystem hat seinen
Ursprung im Punkt (0.0, 0.0, 0.0) und ist nicht rotiert (#24-#28). Sowohl das Gebäude als
auch das Stockwerk sind in Bezug zur Baustelle unverschoben und unverdreht positioniert
(#30–#34 bzw. #36–#40).
Im nächsten Abschnitt werden die oben definierten Level der Projektstruktur hierar-
chisch in Aggregationsbeziehung (vgl. Kap. 3) gesetzt. Das Gebäude (#29) besteht aus
einem Stockwerk (#35), die Baustelle (#23) besteht aus einem Gebäude (#29) und das
Projekt (#1) besteht aus einer Baustelle (#23). Abschließend wird eine hierarchische,
räumliche Beziehung (#44) definiert, mit der festgelegt wird, dass sowohl die Wand (#45)
als auch das Fenster (#124) dem einzigen Stockwerk (#35) im Gebäude zugeordnet sind.
Im nächsten Teil werden die Wandschichten und deren Material definiert. Die Beispiel-
wand besteht aus genau einem Materiallayer (#77) des Materials ,Reinforced concrete
C30/37‘ und der Breite 0,3 m. Dieser Materiallayer ist in Bezug auf die Wandachse (#79)
mittig positioniert, was durch den negativen Versatz von 0,15 m ausgedrückt wird (#75).
Der folgende Abschnitt legt alphanumerische Eigenschaften sowie Maß- und Mengen-
angaben fest. Dafür wird jeweils ein Satz an Eigenschaften (IfcPropertySet, #52) und ein
Satz an Maß- und Mengenangaben (IfcElementQuantity, #64) definiert und dem Wand-
objekt durch Beziehungsobjekte (IfcRelDefinesByProperties, #63 bzw. #73) zugeordnet.
In den Zeilen #53 bis #62 werden Eigenschaftswerte, wie zum Beispiel der Wärme-
durchlasskoeffizient (#58), und in den Zeilen #65 bis #72 werden Werte für Maß- und
Mengenangaben, wie zum Beispiel das Bruttovolumen (#69), spezifiziert. Die Namen ,P
set_WallCommon‘ und ,BaseQuantities‘ weisen darauf hin, dass die definierten Eigen-
schaften und Maß- und Mengenangaben Bestandteil der IFC-Spezifikation sind.
Weiterhin wird ein Satz an Maß- und Mengenangaben festgelegt (#104) und dem Öff-
nungsobjekt (#97) durch die Beziehung #108 zugeordnet.
Im folgenden Abschnitt wird das Fensterobjekt vom Typ IfcWindow erzeugt (#124)
und relativ im lokalen Koordinatensystem der Öffnung positioniert (#125 zeigt auf #98).
Für das Fensterobjekt wird als geometrische Repräsentation (#130) ein dreidimensiona-
ler Volumenkörper als ,SweptSolid‘ definiert (#150, #151). Dieser Körper entsteht durch
die Extrusion der Grundfläche (#152), die durch eine geschlossene Polylinie (#153) be-
schrieben wird. Das Fensterobjekt (#124) hat die Beziehung IfcRelFillsElement (#131)
zur Öffnung (#97), welche angibt, dass das Fenster die Öffnung ausfüllt.
7.500E-1);
#125 = IFCLOCALPLACEMENT(#98, #126);
#126 = IFCAXIS2PLACEMENT3D(#127, #128, #129);
#127 = IFCCARTESIANPOINT((0., 1.000E-1, 0.));
#128 = IFCDIRECTION((0., 0., 1.));
#129 = IFCDIRECTION((1., 0., 0.));
#130 = IFCPRODUCTDEFINITIONSHAPE($, $, (#150));
#131 = IFCRELFILLSELEMENT(’1CDlLMVMv1qw1giUXpQgxI’, #2, $, $,
#97, #124);
#150 = IFCSHAPEREPRESENTATION(#20, ’Body’, ’SweptSolid’,
(#151));
#151 = IFCEXTRUDEDAREASOLID(#152, #159, #163, 1.400);
#152 = IFCARBITRARYCLOSEDPROFILEDEF(.AREA., $, #153);
#153 = IFCPOLYLINE((#154, #155, #156, #157, #158));
...
Analog zur Wand legt der nächste Abschnitt alphanumerische Eigenschaften sowie
Maß- und Mengenangaben für das Fenster fest. Dafür wird jeweils ein Satz an Eigenschaf-
ten (#132) und ein Satz an Maß- und Mengenangaben (#146) definiert und dem Fenster
durch Beziehungsobjekte (IfcRelDefinesByProperties, #145 bzw. #149) zugeordnet. In
den Zeilen #133 bis #144 werden Eigenschaftswerte, wie zum Beispiel der Wärmedurch-
lasskoeffizient (#139), und in den Zeilen #147 und #148 werden Werte für Maß- und
Mengenangaben, hier für die Höhe (#147) und die Breite (#148) des Fensters, spezifiziert.
Die vorletzte Zeile beendet den Datenabschnitt (DATA) der IFC-Datei und die letzte Zeile
schließt die gesamte ISO-Standarddatei.
6.10 ifcXML
Die Beschreibungssprache des IFC-Schemas ist EXPRESS (ISO 10303-11), eine speziell
für die Produktmodellierung entwickelte Datenmodellierungssprache. Wie im vorange-
gangenen Abschnitt eingeführt, wird das dazugehörige Austauschformat für Modellin-
stanzen in Teil 21 de STEP-Spezifikation definiert. Das heute weit verbreitete Format
XML, welches vom W3C definiert wird (W3C 2015), stand zu Beginn der IFC-Entwick-
lungen noch nicht zur Verfügung.
Zu Beginn der 2000er Jahre hat die eXensible Modeling Language, XML, eine verein-
fachte und optimierte Version das SGML-Standards, große Verbreitung erlangt (W3C).
Viele Entwicklungstools wurden bereitgestellt und XML wurde der Mainstream bei den
Sprachen zur formalen Beschreibung von strukturierten Daten.
Aus diesem Grund wurde der Wunsch an buildingSMART herangetragen, IFC-Daten
auch im XML-Format bereitzustellen. Daraus entwickelten sich ab 2001 verschiedene
Ansätze, das IFC EXPRESS-Schema in eine XML-kompatible Form zu übersetzen, um
gültige IFC-XML-Dokumente zu ermöglichen.
2001 – erste Version einer XML-Übersetzung des IFC2.0 Schemas als eine XDR (XML
Data Reduced) Schema Definition, die Übersetzungsvorschrift von EXPRESS nach
XDR war eine individuelle Entwicklung.
2002 – erste Version einer XML-Übersetzung des IFC2x Schemas als eine XSD (XML
Schema Definition), die Übersetzungsvorschrift von EXPRESS nach XSD war eine
individuelle Entwicklung, die später als ein Vorschlag in die ISO-Gruppe ISO/TC
184/SC 4 aufgenommen wurde, um einen allgemeinen Standard zum Mapping von
EXPRESS nach XSD zu beschreiben.
2005 – neue Methode der XML-Übersetzung des IFC2 × 2 Schemas nach dem damali-
gen Entwicklungsstand (working draft) des Standards ISO 10303:28-ed2, welcher für
die standardmäßige Übersetzung von EXPRESS zu XSD entwickelt wurde. Es wurde
eine default-Konfiguration gewählt, welches zu sehr umfangreichen XML-Datenmen-
gen führte.
2007 – Anwendung derselben Methodik für das IFC2 × 3 Schema.
2013 – Generelle Neuentwicklung von ifcXML im Rahmen der IFC4-Entwicklung, die
Übertragung von IFC EXPRESS nach XSD wurde auf der Basis des endgültigen Stands
der ISO 10303-28:ed2 und einer optimierten Konfiguration der Mapping-Regeln durch-
geführt. Dazu werden die XSD-Definitionen, gleichberechtigt zu den EXPRESS-De-
finitionen in offiziellen IFC4 Dokumentation aufgeführt. Die neue Konfiguration der
ISO 10303-28:ed2-Regeln erlaubt eine viel effizientere Übertragung, diese Methode
wird auch als Simple ifcXML bezeichnet.
Generell erlaubt die XML-Serialisierung von IFC-Daten exakt die gleiche Informati-
onstiefe wie die Part21-Serialisierung. IFC XML-Daten können gegen das online verfüg-
bare ifcXML XSD-Schema geprüft werden. Nur die tiefere Prüfung gegen die in EX-
6 Industry Foundation Classes 125
Das IFC-Datenmodell ist ein offenes, ausgereiftes und international standardisiertes Da-
tenmodell. Es erlaubt den Austausch digitaler Gebäudemodelle über die Grenzen einzelner
Anwendungen und verschiedener Softwarehersteller hinweg und unterstützt dabei unter-
schiedlichste Anwendungsszenarien.
Mit dem IFC-Datenmodell können Gebäude sehr detailliert digital modelliert wer-
den: Es erlaubt die umfassende semantische Beschreibung eines Gebäudes, einschließlich
der Modellierung von Bauteilen, Räumen und deren wechselseitigen Beziehungen. Mit
jedem semantischen Gebäudeobjekt können zudem eine oder mehrere geometrische Re-
präsentationen assoziiert werden, wodurch unterschiedliche Bedürfnisse hinsichtlich der
geometrischen Darstellung von Gebäudeinformationen abgedeckt werden.
Das IFC-Datenmodell ist ein äußerst mächtiges und gleichzeitig sehr komplexes Daten-
modell. Das hat zwar den Vorteil, dass Gebäude sehr umfassend und auf unterschiedliche
Weisen beschrieben werden können, bringt aber auch Nachteile mit sich. Beispielswei-
se sind für verschiedene Planungsschritte unterschiedliche geometrische Repräsentatio-
nen, etwa als Flächenmodell oder als Finite-Elemente-Netz notwendig, die jeweils unter-
schiedlich modelliert werden können. Einen typischen Stolperstein stellt die Modellierung
durchgängiger Außenwände statt geschoßweiser Einzelabschnitte dar. Beide Varianten
sind zulässig und haben in verschiedenen Anwendungsfällen ihre Daseinsberechtigung,
können aber selten voneinander abgeleitet oder parallel beschrieben werden.
Dadurch ergibt sich ein nicht zu unterschätzender Aufwand für Softwarefirmen, die
ihre Produkte kompatibel zum IFC-Standard machen wollen. Viele Softwarehersteller
entscheiden sich, nur einen Teil des Datenmodells für ihre Im- und Exportmodule zu
implementieren. Um dadurch auftretende Inkompatibilitäten zu vermeiden, hat building-
SMART das Konzept der Model View Definitions (MVD) entwickelt (Kap. 7), mit deren
Hilfe für konkrete Datenaustauschszenarien spezifiziert wird, welche Teile des IFC-Daten-
modells implementiert werden müssen. MVDs bilden entsprechend auch die Grundlage
für die Zertifizierung der IFC-Kompatibilität – Softwareprodukte werden also nicht gegen
das gesamte Datenmodell zertifiziert, sondern nur gegen wohldefinierte Teile (Kap. 8).
Trotz der formalen Mechanismen des Datenschemas und der MVDs ist die Flexibilität
des Modells weiterhin so hoch, dass weitere Absprachen für homogene und kompatible
Implementierungen notwendig sind. Diese in den sogenannten „Implementers’ Agree-
ments“ getroffenen umfangreichen Absprachen werden jedoch zunehmend in teilautoma-
126 A. Borrmann et al.
Literatur
Verwendete Literatur
buildingSMART (2013): Industry Foundation Classes, Version 4, Documentation, http://www.
buildingsmart-tech.org/ifc/IFC4/final/html/ Zugriff am: 13.01.2015
Eastman, C. (1999). Building Product Models: Computer Environments Supporting Design and
Construction. CRC Press
ISO (2002) ISO 10303-21:2002 Industrial automation systems and integration – Product data repre-
sentation and exchange – Part 21: Implementation methods: Clear text encoding of the exchange
structure, International Organization for Standardization, Genf, Schweiz
ISO (2004a) ISO/IEC 19775-1:2004, Information technology – Computer graphics and image pro-
cessing – Extensible 3D (X3D), International Organization for Standardization, Genf, Schweiz
ISO (2004b) ISO 10303-11:2004: Industrial automation systems and integration – Product data
representation and exchange – Part 11: Description methods: The EXPRESS language reference
manual, International Organization for Standardization, Genf, Schweiz
ISO (2013): ISO 16739:2013: Industry Foundation Classes (IFC) for data sharing in the construc-
tion and facility management industries, International Organization for Standardization, Genf,
Schweiz
Laakso, M., & Kiviniemi, A. (2012). The IFC Standard – A Review of History, Development and
Standardization. ITcon Journal of Information Technology in Construction, 17, 134–161. http://
www.itcon.org/data/works/att/2012_9.content.01913.pdf, Zugriff am 13.01.2015
D.A. Schenck and P. R. Wilson (1993), Information Modeling the EXPRESS Way, Oxford University
Press
M. Weise, T. Liebich, R. See, V. Bazjanac, and T. Laine (2009): IFC Implementation Guide:
Space Boundaries for Thermal Analysis. BuildingSmart, http://www.buildingsmart-tech.org/
downloads/accompanying-documents/agreements, Zugriff am 11.11.2014
W3C (2015), XML Standard, Word Wide Web Consortium (W3C), http://www.w3.org/standards/
xml/, Zugriff am 22.1.2015
Weiterführende Literatur
Liebich, T. (2009): IFC 2x Edition 3 Model Implementation Guide, http://www.buildingsmart-tech.
org/implementation/ifc-implementation/ifc-impl-guide, Zugriff am 14.1.2015
Prozessgestützte Defintion von Modellinhalten
Jakob Beetz, André Borrmann und Matthias Weise
7
Zusammenfassung
Das Datenmodell Industry Foundation Classes (IFC) stellt einen umfassenden her-
stellerneutralen Standard zur Beschreibung von digitalen Gebäudemodellen zur Ver-
fügung. Dabei handelt es sich jedoch zunächst nur um eine Datenstruktur. Für eine
sinnvolle Nutzung im Rahmen von Planungsprozessen ist darüber hinaus festzulegen,
welche Informationen von wem wann welchem Projektbeteiligten wie zur Verfügung
gestellt werden sollen. Hierzu wurde von buildingSMART die Methode Information
Delivery Manual (IDM) entwickelt, die vorsieht, die Datenaustauschprozesse mithilfe
einer grafischen Notation zu beschreiben, um daraus Anforderungen hinsichtlich der
auszutauschenden Modellinhalte (Exchange Requirements) abzuleiten. Die technische
Umsetzung dieser Anforderungen wird mit einer Model View Definition (MVD) rea-
lisiert, die genau festlegt, welche Entitäten und Attribute des IFC-Modells verwendet
werden dürfen bzw. müssen. Das Kapitel beschreibt im Detail die Herangehensweise
der IDM. Daneben wird das Datenaustauschformat COBie vorgestellt, das speziell der
Übergabe von Bauwerksdaten an den Betreiber dient. Das Kapitel schließt mit einer
Diskussion der Verfahren zur Festlegung von Ausarbeitungsgraden für Modellinhalte
Jakob Beetz
Technische Universiteit Eindhoven, Department of the Built Environment, Urban Science and
Systems, P.O. Box 513, 5600 Eindhoven, Niederlande
e-mail: J.Beetz@bwk.tue.nl
André Borrmann
Technische Universität München, Lehrstuhl für Computergestützte Modellierung und Simulation,
Arcisstr. 21, 80333 München, Deutschland
e-mail: andre.borrmann@tum.de
Matthias Weise
AEC3 Deutschland GmbH, Wendl-Dietrich-Straße 16, 80634 München, Deutschland
e-mail: mw@aec3.de
7.1 Übersicht
Wie in Kap. 6 vorgestellt, ist das IFC-Datenmodell sehr umfangreich. Die Fülle an In-
formationen, die in Eigenschaften, Attributen und auf geometrischem Niveau festlegbar
sind, übersteigt meist den jeweils beabsichtigten Nutzen zu einer bestimmten Phase des
Bauvorhabens. Darüber hinaus ist es durch die gewünschte Flexibilität vergleichsweise
aufwendig, die benötigten Informationen aus dem Modell auszulesen, da diese häufig auf
unterschiedliche Weise im Modell abgebildet werden können.
Um die daraus entstehenden Probleme beim Informationsaustausch zu vermeiden, soll-
ten einheitliche, standardisierte Vereinbarungen hinsichtlich des Modellinhalts getroffen
werden. Diese legen fest, welche Informationen von wem wann welchem Projektbeteilig-
ten wie zur Verfügung gestellt werden sollen. Für eine solche Präzisierung wurde von
buildingSMART die IDM/MVD-Methode entwickelt, die die beabsichtigte Anwendung
von IFC im Detail festlegt. Interpretationsspielräume werden dadurch verkleinert und
7 Prozessgestützte Defintion von Modellinhalten 131
A 1 4 5 7
B 2 8
C 3 6
Austauschanforderung Nr. 1 A 1 4 5 7
B 2 8
Austauschanforderung Nr. 2
Austauschanforderung Nr. 3
C 3 6
4 Auszutauschende Informaon
fachlich festlegen 3 Benögte Informaonen
ermieln
Auszutauschende
Model View (Schemafilter)
5 Informaonen auf Datenmodell
abbilden 6 erstellen
Abb. 7.1 Überblick über die IDM/MVD-Methode, die zur Konkretisierung des IFC-basierten Da-
tenaustauschs von buildingSMART verwendet wird
132 J. Beetz et al.
Vor Beginn der Spezifikationsarbeit sollte geklärt sein, welche Verbesserungen erreicht
werden sollen und welche Aspekte des Planungsprozesses betrachtet werden. Hieran an-
schließend stehen die fachlichen Anforderungen mit folgenden Zielen im Fokus:
1. Die Erzeugung einer Übersicht eines gewählten Teilprozesses der Planung, Ausfüh-
rung oder der Nutzung von Bauwerken unter anderem in standardisierten Prozessdia-
grammen (Process Maps – PM).
2. Die Erstellung eines tabellarischen Anforderungskataloges für den Informationsaus-
tausch (Exchange Requirements – ER).
3. Die Abbildung der geforderten Informationen in ein konkretes Datenmodell wie den
IFC (Model View Definitions – MVD).
Diese ersten beiden Schritte (PM, ER) werden dabei von Experten der am jeweili-
gen Teilprozess beteiligten Fachgebiete ausgeführt und stützen sich auf die Erfahrungen
aus vergangenen Projekten, gängigen Konventionen der Zusammenarbeit in der Praxis
sowie allgemeinen Richtlinien oder Normen. Die einzelnen Bestandteile eines Prozes-
ses, wie zum Beispiel der Ermittlung des Energiebedarfes eines Gebäudes in den frühen
Entwurfsphasen, werden in Dokumenten festgelegt, die mithilfe einfacher Werkzeuge
(Diagrammeditor, Tabellenkalkulation, Textverarbeitung) erzeugt werden können.
Bereits diese Stufe der Formalisierung kann für transparente und deutliche Strukturen
sorgen, die eine reibungslosere Zusammenarbeit aller Beteiligten fördert. Die in natürli-
cher Sprache verabredeten Festlegungen und Randbedingungen, etwa „Alle raumbegren-
zenden Bauteile müssen (überschlägliche) Wärmedurchgangskoeffizienten haben“ oder
„Alle Räume müssen mit einer Nutzungsart ausgezeichnet sein“ erlauben die manuelle
Kontrolle der übertragenen Informationen in eingeschränktem Umfang (etwa durch Stich-
proben) und dienen als Grundlage für die Automatisierung. Da die Erstellung solcher
Exchange Requirements je nach Phase, beteiligten Akteuren, Anzahl der Teilprozesse
etc. sehr aufwendig sein kann, ist es sinnvoll, diese gemeinsam zu erstellen, zu teilen
und wiederzuverwenden. Viele Initiativen zur Erstellung solcher Exchange Requirements
stehen bereits heute zur Nutzung bereit. Die buildingSMART Organisation stellt aus-
führliche Anleitungen und Vorlagen zur Erstellung solcher Dokumente zur Verfügung
(buildingSMART 2012) und eine Anzahl von aktuellen, ausgearbeiteten IDMs können
in den Archiven des BLIS Projektes gefunden werden (BLIS 2014).
Für die Implementierung und eine teilautomatisierte Qualitätskontrolle der erzeugten
und ausgetauschten Informationen auf Grundlage des Anforderungskataloges müssen die
im „Pflichtenheft“ der Exchange Requirements erstellten Festlegungen weiter formalisiert
werden. Randbedingungen, die in tabellarischer Form durch Fachleute festgelegt wurden,
werden dabei auf eine Datenstruktur wie IFC abgebildet und so dokumentiert, dass sie in
Software implementiert werden können. Mehrere Exchange Requirements werden dabei
7 Prozessgestützte Defintion von Modellinhalten 133
IFC Spezifikaon
Abb. 7.2 Gegenseitige Abdeckung von Process Maps, Exchange Requirements, Model Views und
IFC-Modellen
Um eine Übersicht über einen betrachteten Teilprozess zu erhalten sowie die verschie-
denen Szenarien für Informationsübertragungen zu strukturieren, wird in diesem Schritt
mithilfe der im Kap. 4 vorgestellten BPMN-Notation ein Prozessdiagramm aufgestellt
(Abb. 7.3). Dabei wird eine Reihe von Merkmalen des Prozesses übersichtlich struktu-
riert:
134 J. Beetz et al.
Für die Energiebedarfsermittlung beispielsweise werden etwa die drei Akteure Bau-
herr, Architekt und Energieberater zueinander in Beziehung gebracht: Es wird festgelegt,
dass der Bauherr auf Grundlage eines Vorentwurfs des Architekten die Erstellung einer
Energiebedarfsberechnung in Auftrag gibt. Dazu wird verabredet, neben externen Do-
kumenten wie Klimadaten, Energiekostendaten und einer entsprechenden Berechnungs-
grundlage (DIN 4108, DIN EN ISO 6946, EnEV etc. in späteren Stadien DGNB, BREE-
AM, LEED etc.) auch ein Gebäudemodell im IFC-Format zu übergeben.
Die entstehende Process Map erlaubt die klare Zuordnung von Anforderungen an den
Datenaustausch (Exchange Requirements) zu einzelnen Prozessschritten. Dies ist notwen-
dig, da zu unterschiedlichen Zeitpunkten völlig unterschiedliche Anforderungen an die zu
übertragenden Modellinhalte vorliegen können.
Energiebedarf und
Bewertung Gutachten
-verbrauch
Energieanalyse Energieanalyse
berechnen
Energieberater
ER ER Energieanalyse
Energie- Ergebnis
analyse
Input
Daten-
BIM Daten
Weer-Energie-Analyse- ER Energieanalyse
Referenzdaten
austausch
daten tarife Methode Ergebnis
Ja
Externes
Nein Bewertung Gesamt- Beurteilung,
Gutachten /
Beratung
Energiebilanz, und Entwurf und
einholen? resulerende Kosten Planung
Ja
Nein Validierung BIM für
BIM für Energieanalyse
Auraggeber / Bauherr
Energieanalyse
Prozessgestützte Defintion von Modellinhalten
befriedigend?
Weer-Energie- Analyse-
ER daten tarife Methode ER ER
Energie- ER Energie- Energie- ER Energie- Bewertung
analyse analyse analyse analyse Energieanalyse
Daten-
BIM Daten
Input Ergebnis Input Ergebnis (falls abgelehnt)
Referenzdaten
austausch
BIM
abgelehnt
Ausarbeitung Entwurf
und Planung
BIM für Energieanalyse Energiebedarf und Ja Vorbereitung Ja
BIM für Analyse Bewertung
vorbereiten -verbrauch Bewertung
exporeren Energieanalyse Resultat
Architekt
berechnen Bauherr Energieanalyse
Vorentwurf Nein akzeptabel? Nein
akzepert?
ferg
Versionsmanagement Architekt
Abb. 7.3 Die Process Map erfasst die Prozesse, die im betrachteten Anwendungsszenario relevant sind und kennzeichnet insbesondere Datenüber-
135
gabepunkte und die mit ihnen verbundenen Anforderungen (Exchange Requirements). Dies bildet die Grundlage für die Spezifikation entsprechender
MVDs. Dargestellte Process Map nach Energy-Analysis IDM, ausgearbeitet von GSA (USA), Byggforsk (Norwegen) und Senatii (Finnland)
136 J. Beetz et al.
Ein entsprechend definierter Model View kann sich von der Wertbelegung spezifischer
Attribute über die Festlegung von zu verwendenden Property Sets bis hin zur Festlegung
der zu verwendenden Geometrierepräsentation erstrecken. Gerade letzterem kommt in
konkreten Datenaustauschszenarien enorme Bedeutung zu, da, wie in Kap. 6 dargestellt,
die Industry Foundation Classes eine große Menge von alternativen Geometrierepräsen-
tationen unterstützen, von denen aber in den allermeisten Fällen ein bis zwei für ein
konkretes Datenaustauschszenario ausreichend sind. Darüber hinaus bilden entsprechend
definierte MVDs eine hervorragende Grundlage für die Zertifizierung von Softwarepro-
dukten (siehe Kap. 8).
Die Version 2x3 der Industry Foundation Classes beinhaltet die folgenden vordefinier-
ten MVDs (buildingSMART 2014a):
Coordination View: beinhaltet alle Gebäudeinformationen, die für den Austausch zwi-
schen den drei Hauptdisziplinen Architektur, Tragwerksplanung und technische Ge-
bäudeausrüstung notwendig sind. Dabei ist die Modifizierbarkeit durch die empfan-
gende Applikation gegeben.
– Quantity Take-Off Add-on: beinhaltet zusätzlich Mengenangaben für alle Bauteile
und Räume, die im allgemeinen Modell nicht oder nur implizit beschrieben sind.
So ist bspw. die Höhe einer Wand im Standardexport nur durch ihre geometrische
Beschreibung erfasst. Durch die Einbindung des Quantity Take-Off Add-ons wird
eine explizite Höhenangabe an die entsprechende Instanz gehängt.
– Space-Boundary Add-on: beinhaltet zusätzliche Formen von Raumbegrenzungen
(Space Boundaries), wie sie etwa für die thermische Gebäudesimulation benötigt
werden.
7 Prozessgestützte Defintion von Modellinhalten 137
Diese vordefinierten Views bilden in der Regel die Grundlage für die Zertifizierung
eines Softwareprodukts hinsichtlich seiner Fähigkeit zum korrekten Import bzw. Export
von IFC-Daten (siehe Kap. 8). Neben diesen heute (Stand 2015) noch am häufigsten in der
Praxis anzutreffenden Sichten werden zukünftig auch die neuen auf dem mvdXML-Stan-
dard basierenden Views der Version IFC 4 eine zunehmende Rolle spielen. Grundsätzlich
wird dabei zwischen dem Reference View und dem Design Transfer View unterschieden.
Dsas Reference View ist vor allem für die Koordination und Zusammenführung verschie-
dener Fach- und Teilmodelle etwa zur Kollisionserkennung geometrischer Repräsentation
bestimmt. Änderungen werden dabei in den jeweiligen Fachwerkzeugen und Teilmodellen
vorgenommen und erneut zur Verfügung gestellt. Dagegen werden in der Design-Trans-
fer-Sicht Modelle vollständig übergeben und Änderungen im gesamten geteilten Modell
vorgenommen.
Zur Festlegung eines Model Views bedient man sich häufig eines zweistufigen Ver-
fahrens. Zunächst werden spezielle MVD-Diagramme erzeugt, in denen durch farbliche
Kennzeichnung festgelegt wird, welche Teile des Datenmodells belegt sein müssen. Dabei
wird von sogenannten Konzepten (engl: concepts) Gebrauch gemacht. Ein Konzept fasst
die Belegung von Attributen bzw. die Modellierung von Beziehungen (ggf. über mehrere
Zwischeninstanzen) zusammen. Diese Konzepte werden so definiert, dass sie in möglichst
vielen MVDs wiederverwendet werden können. Dabei kann auch das Konzept der Kom-
position eingesetzt, d. h. komplexere Konzepte aus einfacheren zusammengesetzt werden.
Durch die Einführung der Konzepte wird verhindert, dass Festlegungen für MVDs auf
dem zu feingranularen Niveau einzelner Attribute gemacht werden müssen. Darüber hin-
aus wird durch diese Kapselung die Wiederverwendung von Versatzstücken unterstützt,
die die Entwicklungen der MVDs selbst und der sie unterstützenden Software erleichtert.
Typische Beispiele für Konzepte sind „GUID“, „Name“, „Building Element Assignment“.
Abbildung 7.5 zeigt die Definition eines entsprechenden Konzepts.
Abbildung 7.6 zeigt einen Ausschnitt eines MVD-Diagramms für die Klasse IfcBeam
im Rahmen der MVD Energy Analysis. Im Diagramm wird beispielsweise festgelegt, wie
die Brandschutzklasse für jeden Träger anzugeben ist. Des Weiteren wird festgelegt, dass
als Geometrierepräsentationen die Konzepte Brep, Swept Solid und Clipped Solid zum
Einsatz kommen dürfen (für Details hierzu siehe Kap. 6).
Im zweiten Schritt können derartige MVD-Diagramme in ein maschinenlesbares For-
mat übertragen werden. Bei diesem Format handelt es sich um mvdXML, einem XML-
Schema, das die Beschreibung eines Model Views erlaubt (Chipman et al. 2012). Zu-
sätzlich zu den weiter oben vorgestellten Festlegungen in den grafischen Formaten lassen
sich mithilfe von mvdXML auch weiterführende Konstrukte wie Verknüpfungen, Wenn-
138 J. Beetz et al.
Abb. 7.5 Die Definition des Konzepts „Column Construction Type“ beschreibt die Zuweisung der
Konstruktionstypen und einer Brandschutzklasse zu einem IfcColumn-Objekt. Dieses Konzept wird
beispielsweise im Energy Analysis View gebraucht
Abb. 7.6 Ein MVD-Diagramm legt für einen Entitytyp fest, welche Konzepte verpflichtender Be-
standteil des betrachteten Model Views sind. Hier gezeigt ist das Diagramm für den Entitytyp
IfcBeam im MVD Concept Design to Building Energy Analysis. In der Abbildung ist die Definition
des in diesem Diagramm verwendeten Konzeptes Column Construction Type dargestellt
Bei COBie handelt es sich um eine Spezifikation, die speziell die Übergabe von Gebäu-
deinformationen an den Betreiber adressiert. Dabei werden geometrische Informationen
weitgehend außen vor gelassen, der Fokus liegt vielmehr auf der Beschreibung der Räume
und der technischen Gebäudeausrüstung, insbesondere mit dem Ziel der Unterstützung des
Betriebs und der Wartung der Geräte. COBie-Daten werden in der Regel in der Form von
Tabellenblättern wiedergegeben. Typische mit COBie übertragene Informationen sind der
Typ eines Geräts, sein Hersteller, die Seriennummer und das Wartungsintervall. COBie-
Daten werden i. d. R. durch elektronische Dokumente wie Betriebs- und Wartungsanlei-
tungen sowie technische Zeichnungen einzelner Geräte ergänzt.
COBie kann auf unterschiedliche Weise technisch umgesetzt werden. Eine Möglich-
keit besteht in der Nutzung des IFC-Datenformats und der darauf aufbauenden COBie
Model View Definition (BuildingSMART 2013). Um die Lesbarkeit der übertragenen In-
formationen auch für nicht IFC-Experten zu gewährleisten, wird als alternative Variante
die Nutzung von vordefinierten Vorlagen für Tabellenkalkulationsprogramme vorgesehen
(siehe Abb. 7.7) (WBDG 2014). Die Brücken zwischen diesen Welten bilden Konverter,
die die notwendigen Daten aus IFC-Modellen extrahieren und die entsprechenden CO-
Bie-Tabellenblätter befüllen können. Eine dritte Möglichkeit liegt in der Nutzung von
COBieLite, einem eigens definierten XML-Format (NIBS 2014). Abbildung 7.8 gibt die
generelle Struktur der COBie-Daten wieder.
Im Laufe der Planung und Realisierung eines Bauvorhabens sind von verschiedenen
BIM-Richtlinien (u. a. vom britischen Standard BS 1192-2) mehrere sogenannte COBie
Data Drops vorgesehen, für die jeweils eine unterschiedliche Informationstiefe verlangt
wird.
140 J. Beetz et al.
Abb. 7.7 Ausschnitt eines COBie-Tabellenblattes zur Beschreibung von technischer Gebäudeaus-
rüstung mit farblicher Kennzeichnung der verschiedenen Informationsbestandteile. Beispiel aus
dem Duplex-Appartement Referenzdatensatz der Common BIM Files (East 2012)
Allgemein
Kontakt
Arbeit
Bauwerke
Resource
bestehend aus versorgt durch
Ersatz
Geschosse Typ
befindlich in Allgemein
Räume Komponente Koordinaten
Technische
Räumliche Lage Vermerke Verbindungen
Ausrüstung
COBie wurde seit 2006 zunächst in den USA aus der Notwendigkeit heraus entwickelt,
die großen Mengen anfallender Daten der Liegenschaften des US-Amerikanischen Mili-
tärs einheitlich zu verwalten und gleichzeitig die Komplexität der seinerzeit verfügbaren
IDM-MVD-Technologien zu reduzieren. Seit 2012 ist COBie Teil des United States Na-
tional Building Information Model Standard (NBIMS-US V2). In Großbritannien wurden
diese Entwicklungen aufgegriffen und COBie in die britische Standardisierung integriert
(BIM Taskgroup 2012). Der COBie-Standard wird bereits von einer größeren Zahl von
Softwareprodukten in den Bereichen Planung und Facility Management unterstützt.
7 Prozessgestützte Defintion von Modellinhalten 141
Ein zur Verwendung von IDM/MVD alternativer bzw. ergänzender Ansatz liegt in der Spe-
zifikation von Ausarbeitungsgraden (auch als Fertigstellungsgrade bezeichnet), die zum
einen den geforderten Modellinhalt und zum anderen die Zuverlässigkeit der übermittelten
Modellinformationen festlegen. Dabei arbeitet man in Analogie zu den Planmaßstäben der
konventionellen zeichnungsbasierten Welt: Eine grober Maßstab (bspw. 1:200) beinhaltet
Informationen, die mit einer gewissen Unschärfe verbunden sind, eine Detailzeichnung
(1:10) hingegen enthält alle zur Herstellung notwendigen Informationen mit höchster Zu-
verlässigkeit.
Im englischen Sprachraum wird ein Ausarbeitungsgrad als „Level of Development“
(LOD) bzw. „Level of Model Definiton“ (LOMD) bezeichnet.
Die klare Zuordnung von LODs zu einem Modell bzw. zu Modellelementen erlaubt
dem Empfänger, die Zuverlässigkeit und die Einschränkungen dieses Modells zu be-
werten. Um dies zu ermöglichen, wurden in verschiedenen Ländern Standardisierungen
des jeweiligen Detaillierungs- und Definitionsgrades von Bauteilen vorgenommen. Das
American Institute of Architects (AIA) hat in Zusammenarbeit mit dem amerikanischen
BIMforum beispielsweise die folgenden sechs LODs formal definiert (AIA 2013; BIMfo-
rum 2013):
LOD 100: Das Modellelement wird im Modell grafisch repräsentiert durch ein Sym-
bol oder eine andere generische Repräsentation. Elementbezogene Informationen (wie
Kosten pro m2 , etc.) können von anderen Modellelementen abgeleitet werden.
LOD 200: Das Modellelement wird im Modell grafisch repräsentiert durch ein gene-
risches Objekt, das mit ungefähren Abmessungen, Position und Orientierung versehen
ist.
LOD 300: Das Modellelement wird im Modell grafisch repräsentiert durch ein spezifi-
sches Objekt in Bezug auf Größe, Abmessungen, Form, Position und Orientierung.
LOD 350: Das Modellelement wird im Modell grafisch repräsentiert durch ein spezi-
fisches Objekt in Bezug auf Größe, Abmessungen, Form, Position und Orientierung
sowie Schnittstellen zu anderen Gebäudesystemen.
LOD 400: Das Modellelement wird im Modell grafisch repräsentiert durch ein spezi-
fisches Objekt in Bezug auf Größe, Abmessungen, Form, Position und Orientierung
sowie auf Informationen zu Herstellung, Zusammenbau und Installation.
LOD 500: Das Modellelement wurde auf der Baustelle hinsichtlich seiner Größe, Ab-
messungen, Form, Position und Orientierung überprüft.
Abbildung 7.9 zeigt eine grafische Darstellung dieser verschiedenen Grade anhand ei-
ner Stahlstütze und ihrer angrenzenden Bauteile.
LOD-Definitionen beziehen sich nicht primär auf IFC-Modelle, sondern können auch
mit proprietären BIM-Modellen beliebiger Softwarehersteller umgesetzt werden. Eine
Verknüpfung des LOD-Konzepts mit dem herstellerneutralen IFC-Modell wurde bei-
142 J. Beetz et al.
LOD 100 LOD 200 LOD 300 LOD 350 LOD 400
Abb. 7.9 Grafische Darstellung des verschiedenen Levels of Development, wie sie vom Ameri-
can Institute of Architects (AIA) definiert wurden. Das Beispiel zeigt eine Stahlstütze und seinen
Anschluss an das darunterliegende Bauteil. LOD 500 wird hier nicht gezeigt
spielsweise vom NATSPEC National BIM Guide umgesetzt (NATSPEC 2011). Dabei
werden mit der NATSPEC BIM Object/Element-Matrix umfangreiche Tabellenblätter be-
reitgestellt, die Vorgaben zu den IFC-Modellinhalten auf den einzelnen LOD vornehmen
(Abb. 7.10).
In der heutigen Praxis wird in entsprechenden vertraglichen Vereinbarungen zwischen
den Planungsbeteiligten festgehalten, in welcher Planungsphase welcher Ausarbeitungs-
Abb. 7.10 Die hier stark verkürzt dargestellte BIM Object/Element Matrix des australischen
NATSPEC-Standards gibt für die Ausarbeitungsgrade eines Bauteils die jeweils geforderten Pa-
rameter an und verknüpft diese mit Attributen des IFC-Datenmodells (NATSPEC 2011)
7 Prozessgestützte Defintion von Modellinhalten 143
Abb. 7.11 In der Model Progression Specification wird festgelegt, zu welcher Phase für welchen
Bauteiltyp welcher Level of Development vorliegt. Eine derartige Matrix ist häufig Bestandteil der
vertraglichen Vereinbarungen zwischen den Planungsbeteiligten. PD = Prime Designer, DC = De-
sign Consultant, TC = Trade Contractors (nach AIA E202 2008)
grad für einzelne Modellbestandteil vorliegen muss (siehe Abb. 7.11). Für die entstehende
Matrix gibt es je nach dem entsprechenden Standard unterschiedliche Bezeichnungen,
wie bspw. „Model Progression Specification“, „Model Element Table“ oder „LOD Table“
(AEC UK 2012).
Das LOD-Konzept hat eine sehr große Bedeutung für die modellgestützte Zusam-
menarbeit über die Grenzen einzelner Unternehmen hinweg und die dafür notwendigen
vertraglichen Vereinbarungen zu Modellinhalt und -beschaffenheit. Für die Zukunft ist
eine weitere Formalisierung der Detaillierungsstufen zu erwarten, die dann Eingang in
entsprechende Normenwerke finden wird.
Das BIM Collaboration Format (BCF) ist das Äquivalent zu einer Revisionswolke oder
ähnlichen Markierungen in einer 2D-Bauzeichnung für objekt-orientierte Gebäudeinfor-
mationsmodelle mit 3D-Repräsentationen. Wesentliches Merkmal des Formats ist, dass
damit keine Bauwerksmodelle übertragen werden, sondern lediglich Informationen dazu,
welche Bauteile betroffen sind, sowie entsprechende Markierungen und Annotationen.
In den meisten Planungsprozessen werden Ausarbeitungen und die Verfeinerung ei-
nes gemeinsam von verschiedenen Fachplanern erarbeiteten Modelles in iterativen Zyklen
vorgenommen (siehe Kap. 12). Dabei werden etwa beim Zusammenführen von Teilmodel-
len oder der Erstellung neuer Modellrevisionen teilautomatisierte und manuelle Prüfungen
des Gebäudemodells durchgeführt. Dies wird durch sogenannte Model Checker unter-
144 J. Beetz et al.
Abb. 7.12 Das BIM Collaboration Format (BCF) erlaubt die strukturierte Beschreibung von
Modellkonflikten bzw. -mängeln. Dabei werden für die Darstellung im 3D-Modell u. a. die Kamera-
position und die Blickrichtung übertragen. Hier sind die Ergebnisse einer Modellprüfung auf Basis
einer Model View Definition in einem Webbrowser des BCFServer dargestellt (Berlo und Krijnen
2014)
Mangel (in BCF als „Thema“, engl. topic, bezeichnet) wird ein eindeutiger Bezeichner
(Universally Unique ID) erzeugt und ein gleichnamiges Verzeichnis. In diesem Verzeich-
nis werden folgende Dateien abgelegt:
Eine kurze XML-Datei mit strukturierter Information zum jeweiligen Mangel: Name
und Beschreibung des Mangels, die Globally Unique Identifier (GUID) des Objektes
im IFC-Modell sowie weitere optionale Informationen wie Geschoss des Bauteiles,
Datum, Autor und Priorität des Mangels, der zugeordnete Verantwortliche und der
aktuelle Status der Bearbeitung. Hier können auch Verknüpfungen mit externen Do-
kumenten wie Mängelberichten und Bauabnahmeprotokollen eingefügt und so eine
einfache Koppelung zwischen modell- und dokumentbasierten Systemen geschaffen
werden.
Eine XML-Datei mit Angaben zur Visualisierung wie Kameraposition und -richtung,
mit der das betreffende Bauteil im 3D-Modell dargestellt werden kann, die zu verwen-
dende Farbe zur Markierung des Elements und geometrische Linien zur zusätzlichen
grafischen Kennzeichnung.
Eine Rastergrafik oder ein Foto des betreffenden Mangels im PNG- oder JPEG-Format,
die die erzeugende Anwendung erstellt. Damit können auch einfache Softwarewerk-
zeuge ohne aufwendige 3D-Visualisierungsmöglichkeiten BCF anzeigen und weiter-
verarbeiten.
Die IFC-Datei, in der sich die bemängelten Elemente befinden, kann ganz oder aus-
schnittsweise im BCF-Container beigelegt oder extern vorgehalten werden. Eine ebenfalls
standardisierte Programmierschnittstelle (API) erlaubt so beispielsweise das Referenzie-
ren einzelner Elemente in einem externen Produktmodellserver (vgl. auch Kap. 12).
In Planungs- und Ausführungsprozessen, in denen eine große Anzahl detaillierter Mo-
dellinhalte kontrolliert geprüft und überarbeitet werden müssen, kommt dem BIM Colla-
boration Format eine Schlüsselrolle in der herstellerneutralen, strukturierten Projektkoor-
dination, Mängelverwaltung und -beseitigung zu. Der Einsatz von BCF ist in der heutigen
Praxis bereits effizient möglich und wird bereits von einer Vielzahl verbreiteter Werkzeu-
ge unterstützt.
Zur Organisation der modellgestützten Zusammenarbeit ist es essenziell, sich mit der
Frage zu beschäftigen, zu welchem Zeitpunkt von welchen Beteiligten welche Daten in
welchem Detaillierungsgrad bereitgestellt werden müssen. Die Methode des Information
Delivery Manual (IDM) sieht hierfür vor, zunächst die zugrundeliegenden Geschäftspro-
zesse in Form einer grafischen Process Map festzuhalten und darin die Datenüberga-
bepunkte zu identifizieren. Für diese Datenübergabepunkte werden im nächsten Schritt
Anforderungen (Exchange Requirements) formuliert. Wird bei einem Übergabepunkt der
146 J. Beetz et al.
Austausch von IFC-Modellen vorgesehen, kann daraus anschließend eine Model View
Definition (MVD) abgeleitet werden, die die Anforderungen an den Modellinhalt formal
festhält. Derartige MVDs erlauben es, den Inhalt eines IFC-Modells auf Übereinstim-
mung mit den Anforderungen des jeweiligen Datenübergabepunktes festzuhalten. COBie,
als ein Vertreter eines MVD, regelt die Übergabe von Daten an den Betreiber und fo-
kussiert dabei auf Informationen zu den verbauten Geräten und Anlagen. Ergänzend zur
MVD-Entwicklung wurden vom American Institute of Architects (AIA) „Levels of De-
velopment“ spezifiziert, die den Reifegrad eines Modells ausdrücken. Diese sind auch auf
Nicht-IFC-Modelle anwendbar. Die bei der prozessgestützten Entwicklung gemeinsam er-
stellter Bauinformationsmodelle auftretenden Konflikte bzw. Mängel können sinnvoll und
strukturiert mithilfe des BIM Collaboration Formats verwaltet und kontrolliert werden.
Die hier vorgestellten semi-formalen grafischen Methoden der IDM/MVD-Erstellung
werden in den nächsten Jahren schrittweise durch die formal deutlichere und mithil-
fe des mvdXML Formates komplett maschinenlesbare Methode ersetzt. Mittelfristig ist
zu erwarten, dass eine Vielzahl weiterer Information Delivery Manuals entwickelt und
für wiederkehrende Szenarien in einzelnen Ländern, auf europäischen oder internationa-
len Ebenen standardisiert werden. Dies wird langfristig zu einer Steigerung der Qualität
und Verlässlichkeit der ausgetauschten Daten führen, da eindeutige Absprachen getrof-
fen werden können. Der Erfolg dieser Methoden zur Strukturierung und Optimierung
von Abläufen ist stark von der Verfügbarkeit geeigneter und leicht verwendbarer Soft-
warewerkzeuge abhängig. Diese Software wird jedoch nur auf Nachfrage des Marktes
entstehen.
Wenn sich der Gebrauch von prozessgestützten Modellinhalten in der Praxis durchsetzt
und etabliert, werden auch unternehmensspezifische Datenaustauschszenarien zu erwar-
ten sein, die darauf abzielen, den Datenaustausch innerhalb eines Unternehmens oder in
der Kommunikation mit externen Partnern zu vereinheitlichen und damit effektiver zu ge-
stalten. Die Festschreibung von Datenaustauschszenarien in Verträgen nach dem IDM-
Verfahren beginnt sich bereits in einigen Ländern zu etablieren. In Deutschland kann
die Verankerungen solcher formal geregelten Datenaustauschszenarien etwa in Gebühren-
und Honorarordnungen eine Steigerung von Effizienz und Sicherheit bei der Ausarbeitung
von BIM-Verträgen bedeuten.
Literatur
Verwendete Literatur
AEC UK (2012): AEC (UK) BIM Protocol – Implementing UK BIM Standards for the Ar-
chitectural, Engineering and Construction industry, http://aecuk.files.wordpress.com/2012/09/
aecukbimprotocol-v2-0.pdf, Zugegriffen: 4. November 2014
AIA (2013) AIA Contract Document G202-2013, Building Information Modeling Protocol Form,
American Institute of Architects, Washington DC, USA
7 Prozessgestützte Defintion von Modellinhalten 147
AIA E202 (2008) AIA Document E202 – Building Information Modeling Protocol. http://www.aia.
org/contractdocs/training/bim/aias078742 Zugegriffen: 4. November 2014
Berlo L. van & Krijnen T.F. (2014). Using the BIM Collaboration Format in a server based work-
flow. Proceedings of 12th International Conference on Design and Decision Support Systems in
Architecture and Urban Planning, Eindhoven University of Technology, The Netherlands
BIM Taskgroup (2012): COBie UK 2012, http://www.bimtaskgroup.org/cobie-uk-2012/ Zugegrif-
fen: 4. November 2014
BIMforum (2013): Level of Development Specification, http://bimforum.org/wp-content/uploads/
2013/08/2013-LOD-Specification.pdf Zugegriffen: 4. November 2014
BLIS (2014): IFC Solutions Factory – The Model View Definition site, BLIS project, http://www.
blis-project.org/IAI-MVD/ Zugegriffen: 4. November 2014
buildingSMART (2012): An Integrated Process for Delivering IFC Based Data Exchange, http://
iug.buildingsmart.org/idms/methods-and-guides/Integrated_IDM-MVD_ProcessFormats_14.
pdf/view Zugegriffen: 4. November 2014
buildingSMART (2013): Construction Operations Building Information Exchange, MVD definition
for IFC4, http://docs.buildingsmartalliance.org/MVD_COBIE/, Zugegriffen: 4. November 2014
buildingSMART (2014a): Model View Definition Summary, http://www.buildingsmart-tech.org/
specifications/ifc-view-definition, Zugegriffen: 4. November 2014
buildingSMART (2014b): BIM Collaboration Format v2.0 Technical Documentation. https://github.
com/BuildingSMART/BCF/tree/master/Documentation. Zugegriffen: 4. November 2014
Chipman, T., Liebich, T., Weise, M. (2012): Specification of a standardized format to define
and exchange Model View Definitions with Exchange Requirements and Validation Rules,
buildingSMART, http://www.buildingsmart-tech.org/downloads/accompanying-documents/
formats/mvdxml-documentation/mvdXML_V1-0.pdf Zugegriffen: 4. November 2014
East, B (2012): Common Building Information Model Files and Tools, National Institute for
Building Sciences, http://www.nibs.org/?page=bsa_commonbimfiles, Zugregriffen 4. Novem-
ber 2014
NATSPEC (2011): NATSPEC National BIM Guide, NATSPEC, Australien. http://bim.natspec.org/
index.php/natspec-bim-documents/national-bim-guide Zugegriffen: 4. November 2014
NIBS (2014): Construction-Operations Building Information Exchange (COBie), National Institu-
te of Building Sciences, Washington DC, http://www.nibs.org/?page=bsa_cobie, Zugegriffen:
4. November 2014
WBDG (2014): Construction-Operations Building Information Exchange (COBie), The Wole Buil-
ding Design Guide (WBDG), National Institute of Building Sciences, Washington DC, USA,
http://www.wbdg.org/resources/cobie.php, Zugegriffen: 4. November 2014
Weiterführende Literatur
Teicholz (2013): „BIM for Facility Managers“, Wiley
Zertifizierung von BIM-Software
Rasso Steinmann
8
Zusammenfassung
Ein wichtiger Datenstandard zum Austausch von Daten zwischen BIM-Software ist
IFC – Industry Foundation Classes, der von buildingSMART entwickelt wird. Die
IFC-Schnittstellen von BIM-Software sollten zur Sicherstellung eines möglichst ho-
hen Qualitätsniveaus von un-abhängiger Seite überprüft und zertifiziert werden. buil-
dingSMART hat ein entsprechendes Verfahren entwickelt und implementiert. In die-
sem Kapitel werden die Ziele dieser Zertifizierung, unterschiedliche Erwartungshal-
tungen daran, das Verfahren sowie die Bedeutung im Gesamtprozess BIM beschrieben.
In einem Ausblick werden mögliche künftige weiterführende BIM-Zertifikate (Model-
lierungsqualität von BIM-Daten, BIM-Kenntnisse, BIM-Prozesse) vorgestellt, die über
die Überprüfung der Datenschnittstellen von BIM-Software hinausgehen.
Eine wesentliche Aufgabe von buildingSMART ist die Entwicklung von Datenforma-
ten, die den Informationsaustausch in Projekten unterstützen, die mit BIM-Methoden
durchgeführt werden. Das heute bekannteste Datenformat, das buildingSMART entwi-
ckelt hat, ist das Format Industry Foundation Classes (IFC), ein semantisches Produkt-
Datenmodell, mit dem man Bauwerke umfassend beschreiben kann (siehe Kap. 6). Ei-
ne Vielzahl von BIM-Softwaresystemen unterstützt inzwischen dieses Datenformat mit
Export- und Import-Schnittstellen, und buildingSMART hat zur Sicherstellung und Über-
prüfung der Qualität eine Zertifizierung entwickelt. Neben dem IFC-Format entwickelt
buildingSMART auch noch weitere Datenformate, für die aber zum Zeitpunkt dieser Ver-
öffentlichung noch keine Zertifizierung angeboten wird.
Rasso Steinmann
Hochschule München Fakultät Bauingenieurwesen, Karlstr. 6, 80333 München, Deutschland
e-mail: rasso.steinmann@steinmann-consult.de
Das wesentliche Ziel dieser Zertifizierung ist, ein hohes und nachweisbar erreichtes
Qualitätsniveau der IFC-Datenschnittstellen sicherzustellen. Für die Anwender von BIM-
Software sind diese Zertifikate eine wichtige Orientierungshilfe, um erkennen zu können,
welche Softwareanbieter die Umsetzung des IFC-Formates als wichtiges Ziel verfolgen.
Für die Softwareanbieter wiederum ist diese Zertifizierung eine wertvolle Hilfe zur
Unterstützung der eigenen Qualitätssicherung. Durch eine webbasierte Zertifizierungs-
Plattform (siehe Abschn. 1.3.3) können die Softwarehäuser ihren eigenen Testfortschritt
überwachen, was insbesondere für international operierende Softwarehäuser von Vorteil
ist, deren Entwicklungs- und Qualitätssicherungsteams häufig auf mehrere Länder verteilt
sind. Die zur Verfügung gestellten Testfälle rekrutieren sich aus langjähriger Erfahrung
früherer manueller Tests und stellen somit eine wertvolle Messlatte dar. Darüber hinaus
bekommen die Softwareanbieter Zugriff auf hunderte von IFC-Dateien, die von ihren Mit-
bewerbern erstellt wurden.
Bei jeder Zertifizierung stellt sich die Frage, was man von ihr erwarten kann und wo die
Grenzen ihrer Aussagekraft erreicht sind. Grundsätzlich kann keine Zertifizierung absolu-
te Fehlerfreiheit garantieren. Es ist immer eine Frage des Aufwands, dem ein bestimmter
Nutzen gegenübersteht, und ab wann der Aufwand den wirtschaftlichen Nutzen übersteigt.
Die Gegenüberstellung der IFC-Softwarezertifizierung mit dem Qualitätsmanagement
in der Automobilindustrie soll die Problematik von Zertifikaten aufzeigen. Auch ein TÜV-
Zertifikat für ein Auto ist keine Garantie für absolute Fehlerfreiheit oder dafür, dass nicht
etwa ein sicherheitsrelevantes Bauteil, z. B. durch Materialermüdung, schon kurz nach der
Überprüfung versagt. Ein TÜV-Zertifikat basiert auf Erfahrungswerten, die eine gewisse
Sicherheit geben, dass man nach Durchlauf einer bestimmten Überprüfungsprozedur da-
von ausgehen kann, dass sicherheitsrelevante Komponenten bis zum nächsten Testtermin
standhalten werden. Unzählige Beispiele und Rückrufaktionen von Herstellern beweisen
allerdings, dass die TÜV-Tests nicht alle Eventualitäten abdecken können, die in der Pra-
xis auftreten. Eine Zertifizierung kann also nur ein definiertes Qualitätsniveau zu einer
bestimmten Zeit überprüfen und dokumentieren, nicht aber alle Eventualitäten abdecken.
In Fällen, wo Menschenleben von Qualität abhängen, ist die Bereitschaft, in entsprechen-
de Prüfprozeduren zu investieren, sehr hoch, in anderen Fällen ist es eine wirtschaftliche
Abwägung.
Softwarehersteller wie Automobilhersteller verfügen über aufwendige interne Quali-
tätssicherungssysteme (siehe Abb. 8.1). Automobile werden nach ihrer Serienreife u. a.
den Überprüfungen des TÜVs und den Crashtests des New Car Assessment Program
(NCAP) unterworfen. Trotzdem stellen Automobilzeitschriften oder Autoclubs mit ihren
eigenen Tests manchmal noch erhebliche Mängel fest – es sei hier nur an das prominente
Beispiel des „Elchtests“ erinnert.
8
Zertifizierung von BIM-Software
151
Ähnlich verhält es sich mit der Zertifizierung der IFC-Datenschnittstellen: Das Zer-
tifikat von buildingSMART entspricht einer TÜV-Prüfung oder einem NCAP-Crashtest.
Weitere unabhängige Tests, z. B. durch öffentliche oder private Bauherrn, die spezifische
Anforderungen überprüfen, sind hilfreich und auch sie werden immer wieder Proble-
me offenlegen, die durch die Zertifizierung von buildingSMART nicht entdeckt wurden.
Letztendlich kann ein sehr hohes Qualitätsniveau nur durch die Summe der unabhängigen
Tests erreicht werden.
buildingSMART hat mit der IFC-Softwarezertifizierung langjährige Erfahrung gesam-
melt: In einem ersten Ansatz ging man davon aus, dass die Softwarehersteller im Rahmen
ihrer Produkthaftung eigenständig für das erforderliche Qualitätsniveau sorgen würden.
Mit der Version 1 der IFC-Zertifizierung (zuletzt 2005 durchgeführt) wurde lediglich – im
Sinne einer ISO 9000-Zertifizierung – festgestellt, ob ein Softwareanbieter in der Lage ist,
qualitativ hochwertige IFC-Datenschnittstellen zu entwickeln. Das tatsächlich erreichte
Qualitätsniveau wurde nur stichprobenhaft überprüft. Bald stellte ich jedoch heraus, dass
dieser Ansatz zu kurz griff. Einige Softwarehersteller nahmen die Angelegenheit schlicht
auf die leichte Schulter, andere, die ernsthaft an einer hohen Qualität interessiert waren,
waren mit der Aufgabe überfordert, geeignete Testfälle und eine leistungsfähige Testum-
gebung zu entwickeln (Kiviniemi 2008).
Die Anwendergruppe in buildingSMART war vom Ergebnis dieser Version 1 ent-
täuscht. Zwar konnte bei einigen Softwaresystemen eine spürbare Qualitätssteigerung der
IFC-Schnittstellen festgestellt werden, aber so lange andere Systeme den IFC-Datenaus-
tausch durch mangelhafte Qualität torpedierten, konnten die Anwender nicht zufrieden
sein.
buildingSMART beauftragte deshalb im September 2008 Dr. Thomas Liebich und
den Autor, eine Version 2 der Zertifizierung zu entwickeln, die ein tatsächlich erreichtes
Qualitätsniveau nachweisen kann. Nachdem das Konzept stand und von den buildingS-
MART-Gremien verabschiedet war, wurden die Firma AEC3, das iabi-Institut an der
Hochschule München und das Institut für Angewandte Informatik am Karlsruher Insti-
tut für Technologie (KIT) damit beauftragt, das Konzept umzusetzen und die Audits für
ersten Zertifizierungen durchzuführen.
Das Ergebnis überzeugte: Die Softwaresysteme, die durch die Prozedur der Versi-
on 2 gingen, haben in ihren IFC-Datenschnittstellen einen erheblichen und nachweisbaren
Qualitätssprung nach oben vollzogen (buildingSMART 2015a).
Waren die Anwender jetzt zufrieden? Viele sprachen anerkennendes Lob aus, aber es
gab und gibt immer noch Kritik. Einerseits tauchten in der Praxis, wie zu erwarten, immer
wieder Fälle auf, die durch Testfälle der Zertifizierung nicht abgedeckt waren und des-
halb zu Problemen führten. Das war aber in der Regel nicht wirklich problematisch, weil
die Softwarehäuser (meist) schnell darauf reagierten. Die eigentlichen Probleme ergaben
sich aus der Tatsache, dass Anwender sich vom IFC-Datenaustauch Dinge erwarteten, die
technisch nicht eindeutig spezifiziert wurden.
Hier offenbart sich ein Grundproblem, das allen IFC-Spezialisten bewusst ist, der brei-
ten Anwenderschaft jedoch nicht: Das IFC-Datenmodell kann ein Bauwerk umfassend
8 Zertifizierung von BIM-Software 153
Zur einheitlichen Beschreibung von BIM-Prozessen und den darin enthaltenen Informa-
tions-Austausch-Anforderungen wurde von buildingSMART die standardisierte Methode
Information Delivery Manual (IDM, ISO 29481) entwickelt (siehe Kap. 7). Durch vorge-
gebene, vereinheitlichte Strukturierung und Darstellung von Prozessmodellen ist es An-
wendern möglich, BIM-Prozesse zu entwickeln, gegenseitig abzustimmen und verständ-
lich zu dokumentieren. Die technische Antwort auf einzelne IDM-Spezifikationen sind
sogenannte Model View Definitions (MVD), die jeweils genau die Teilbereiche des um-
fassenden IFC-Datenmodells spezifizieren, die bestimmte Austauschanforderungen (sog.
Exchange Requirements) der IDMs unterstützen können (siehe Abb. 8.2).
MVDs kann man also als technische Pflichtenhefte für Softwarehäuser verstehen, die
IFC unterstützen wollen. Im User-Interface der IFC-Schnittstellen von BIM-Software soll-
ten die unterstützten MVDs den Anwendern zur Auswahl angeboten werden. Da jedoch
in der breiten Anwenderschaft das Wissen zu MVD kaum verbreitet ist, wäre es hilfreich,
wenn die User-Interfaces das Verständnis unterstützen würden – man könnte z. B. anstel-
le technischer und schwer verständlicher MVD-Terminologie Begriffe wie „Austausch-
Zweck“ verwenden.
MVDs geben auch den Rahmen für den fachlichen Umfang der Software-Zertifizierung
vor, sie sind quasi die Messlatte. Auf ihrer Grundlage werden die Testbeispiele aufgebaut
und sie sind Vorlage für Checklisten, die systematische Tests unterstützen.
154 R. Steinmann
Weitere wichtige Grundlagen der Zertifizierung sind die Testbeschreibungen für die
Exporttests und die Kalibrierungsdateien für die Importtests (siehe Abb. 8.3). Die Testbe-
schreibungen geben exakt vor, wie in den zu zertifizierenden BIM-Programmen Gebäu-
dekomponenten und auch ganze Gebäude modelliert werden müssen, die dann als IFC-
Datei exportiert werden.
Zur Aufdeckung spezifischer Probleme und zur Ergründung ihrer Ursachen sind um-
fassende Gebäudemodelle aufgrund ihrer Komplexität wenig hilfreich. Hier helfen kleine
Testszenarien (sog. „Unit-Tests“), die spezifische Fälle abdecken und mit denen versucht
wird, systematisch eine Vielzahl von Varianten abzudecken. Für die Entwicklung dieser
Tests bedarf es großer Erfahrung, um potenzielle Schwächen aufdecken zu können. Für
die hier beschriebene Version 2 der Software-Zertifizierung konnte auf die langjährige
Erfahrung der Version 1 zurückgegriffen werden, unterstützt durch Input von Anwendern
sowie auch von Softwareherstellern selber, deren Anliegen ein hohes Niveau der am Markt
angebotenen IFC-Schnittstellen ist.
Neben den spezifischen Testfällen wurden aber auch Modelle von ganzen Gebäuden
in den Testrahmen aufgenommen. Damit versucht man das Verhalten der Software bei
größeren Datenmengen zu untersuchen.
Die auf Basis der Testbeschreibungen exportierten IFC-Dateien werden nach gründli-
cher Überprüfung als Kalibrierungsdateien für den Importtest verwendet. Die IFC-Spe-
zifikation bedingt, dass selbst bei exakter Umsetzung der Testbeschreibungen, IFC-Da-
teien aus unterschiedlicher Software niemals vollkommen identisch sind. Zwar muss die
Geometrie optisch möglichst deckungsgleich sein, IFC erlaubt aber unterschiedliche Re-
8 Zertifizierung von BIM-Software 155
präsentationen in der Datenstruktur (siehe Kap. 6). Insofern ist die Sammlung sämtlicher
von den unterschiedlichen Programmen exportierten IFC-Dateien ein wertvolles Reposi-
tory für die importierenden Programme, weil sie damit den vollen Umfang der am Markt
auftretenden und erlaubten Variabilität zur Verfügung haben.
8.3.3 GTDS-Webplattform
Die hier vorgestellte Zertifizierung birgt einige große Herausforderungen, denen durch
die Entwicklung einer webbbasierten Anwendung begegnet wurde. Hierfür wird am iabi-
Institut der Hochschule München der Global Testing and Documentation Server (GTDS)
betrieben (siehe Abb. 8.4), der nach folgenden Prinzipien funktioniert:
156 R. Steinmann
1. Die Testbeschreibungen müssen in ihrer Vielzahl von Experten entwickelt und den
Testern gezielt zur Verfügung gestellt werden, wobei alle Beteiligten an unterschiedli-
chen Orten und in verschiedene Zeitzonen arbeiten. Dabei muss sichergestellt werden,
dass tatsächlich alle von den MVDs vorgegebenen IFC-Bereiche durch Tests abge-
deckt werden. Zur Unterstützung dieser Aufgaben wurde eine webbasierte Datenban-
kanwendung aufgebaut, mit der Tests entwickelt, strukturiert zur Verfügung gestellt
und abgewickelt werden können und die für die erforderliche Transparenz sorgt.
2. Exportierte IFC-Dateien sollen, soweit möglich, automatisch getestet werden. Dazu
wurde ein Prüfwerkzeug entwickelt und in GTDS eingebunden, das beim Hochladen
von IFC-Dateien diese automatisch gegen die technische Spezifikation prüft.
3. Da die automatische Prüfung von IFC-Dateien bei Weitem nicht alles abdecken kann,
was geprüft werden muss, erfolgt darüber hinaus eine ausführliche händische Über-
prüfung. Die Ergebnisse dieser Untersuchungen werden detailliert auf der Ebene der
einzelnen IFC-Strukturen dokumentiert. Eine Checkliste, die alle wesentlichen Kom-
ponenten der IFC2 × 3 beinhaltet, wäre über 700 Einträge lang, und ein ständiges
Blättern in so einer langen Liste extrem zeitaufwendig und fehleranfällig. Jedes Test-
8 Zertifizierung von BIM-Software 157
szenario wird deshalb automatisch konfektioniert, sodass pro Szenario immer nur eine
fokussierte Checkliste zur Verfügung steht, die eine Schnittmenge aus IFC-Modell,
MVD und den im Szenario tatsächlich vorkommenden IFC-Elementen darstellt.
4. Jeder zu zertifizierenden Anwendung wird bei der Registrierung ein spezifischer Satz
von Testfällen zugeordnet, der zur entsprechenden MVD passt, die unterstützt werden
soll.
5. Die Softwarehersteller können zur Vorbereitung der Zertifizierung in einem eigenen
geschlossenen Bereich von GTDS ihre Mitarbeiter registrieren, die Tests umsetzen,
überprüfen, die Ergebnisse dokumentieren und den Fortschritt für sich überprüfen.
Besonders für große, international arbeitende Teams ist diese Funktion eine wertvolle
Unterstützung.
6. Die Auditoren, die mit unabhängigen Tests die Ergebnisse der Softwarehersteller über-
prüfen, dokumentieren die Ergebnisse ihrer Untersuchungen in GTDS begleitend mit
dem Testfortschritt der Softwarehäuser, wobei diese die Einträge des fortlaufenden
Audits ständig einsehen und damit zeitnah reagieren zu können.
7. Sobald ein Testfall vom Softwarehersteller als fertiggestellt deklariert wird, bekommt
das Team der Auditoren über GTDS automatisch eine entsprechende Nachricht, um
zeitnah mit dem Audit beginnen zu können.
8. Auswertetools vermitteln Übersichten über den Testfortschritt aller registrierten BIM-
Anwendungen.
9. Ein integriertes Abrechnungstool unterstützt die kaufmännische Abwicklung der Zer-
tifizierungen.
10. Nach erfolgreichem Abschluss einer Zertifizierung wird automatisch ein Report mit
den Testergebnissen generiert. Darüber hinaus erfolgt automatisch ein Eintrag in der
öffentlichen Liste der erfolgreich zertifizierten BIM-Anwendungen auf der buildingS-
MART-Website, wo auch der Abschlussreport veröffentlicht wird (buildingSMART
2015b).
Der Workflow einer Zertifizierung bindet die Tester und Entwickler der Softwarehäuser
sowie die unabhängigen Auditoren ein. Dabei unterscheiden sich naturgegeben die Ex-
port- und Import-Zertifizierungen. Begleitend zu den Tests der Zertifizierungen werden
regelmäßige Telefonkonferenzen angeboten, in denen Fragen der Softwarehersteller be-
antwortet werden und in denen sie ihre Erfahrung austauschen können.
8.4.1 Export-Zertifizierung
abdecken, und die eine Vielzahl an Variationen enthalten, um möglichst viele der in
der Praxis auftretenden Fälle zu simulieren.
2. Diese Vorgaben müssen von den Softwarehäusern modelliert, das Ergebnis als IFC-
Datei exportiert und auf die GTDS-Plattform hochgeladen werden.
3. Beim Hochladen werden die IFC-Dateien durch ein integriertes Prüftool automatisch
gegen die Spezifikation getestet.
4. Dateien, die den automatischen Test erfolgreich durchlaufen haben, müssen von
den Softwareherstellern darüber hinaus manuell überprüft werden. Die kompilierten
Checklisten geben gezielt vor, was überprüft werden muss.
5. Sobald ein Softwarehersteller eine IFC-Datei als aus seiner Sicht fehlerfrei deklariert
hat, werden die unabhängigen Auditoren davon automatisch in Kenntnis gesetzt.
6. Die Auditoren prüfen mit eigenen Methoden, z. B. durch Verwendung unterschied-
licher BIM-Anwendungen, die exportierten IFC-Dateien manuell und dokumentie-
ren ihre Prüfergebnisse detailliert in GTDS. Die vorgegebenen Checklisten helfen
zu erkennen, dass auch tatsächlich auf jede IFC-Komponente geachtet wurde. Aus-
wertetools zeigen an, dass tatsächlich alle maßgeblichen IFC-Komponenten getestet
wurden. Sehr häufig unterstützen die Auditoren die Softwarehersteller bei der Suche
nach dem Grund von Fehlern.
7. Werden keine Fehler mehr festgestellt, wird der betreffende Testfall als erfolgreich ab-
solviert deklariert. Auswertungen zeigen den Fortschritt der Zertifizierung einer BIM-
Anwendung an, sodass man erkennt, wie viele Testfälle noch unbearbeitet im Testlauf
der Softwareherstellhersteller und der Auditoren sind, wie viele zurückgewiesen und
wie viele fertiggestellt wurden.
8. Nachdem alle Testfälle erfolgreich absolviert wurden, muss das Team der Auditoren
sowie das Businessmanagement von buildingSMART die letzte Zustimmung abgeben,
dann ist eine Export-Zertifizierung abgeschlossen. Automatisch erfolgt die Veröffent-
lichung auf der buildingSMART-Website und der Softwarehersteller bekommt das
Zertifikat ausgehändigt.
8.4.2 Import-Zertifizierung
Die Import-Zertifizierung verwendet die erfolgreich zertifizierten Dateien aus der Export-
Zertifizierung als Kalibrierungsdateien. Leider können bei dieser Zertifizierung keine au-
tomatischen Tests erfolgen, die Tests müssen komplett manuell erfolgen. Somit ergibt sich
folgender Workflow:
1. Die Softwarehäuser laden aus GTDS die Kalibrierungsdateien herunter, um sie in ihre
Anwendungen zu importieren. Auch ihnen stehen die dazugehörigen Testbeschreibun-
gen zur Verfügung, damit sie überprüfen können, was bei ihnen ankommen muss.
Auch ihnen stehen für jeden Testfall gezielte Checklisten zur Verfügung.
8 Zertifizierung von BIM-Software 159
2. Nachdem sie ca. 20 % der Testfälle abgearbeitet haben, erfolgt ein erstes Vor-Audit,
das dem Softwarehersteller eine Orientierung für sein weiteres Vorgehen vermittelt.
3. Bei den Audits müssen die Softwarehersteller demonstrieren, welche Inhalte beim Im-
port von IFC-Daten in ihren Anwendungen angekommen sind. Mit geeigneten Funk-
tionen der Anwendungen werden die empfangenen Inhalte zur Überprüfung visuali-
siert, wobei dazu sowohl grafische Darstellungen, als auch alphanumerische Auswer-
tungen verwendet werden.
4. Beim Audit sind sowohl unabhängige Auditoren (mindestens zwei) als auch Vertre-
ter der Softwarehersteller anwesend, um etwaige Fehlbedienungen der Software und
daraus resultierende Fehlurteile auszuschließen. Die Audits erfolgen entweder in Web-
konferenzen oder in Meetings. Gerade bei umfangreichen Audits hat sich gezeigt, dass
Meetings vorzuziehen sind, da tagelange Webkonferenzen sehr anstrengend sind und
die Effizienz sinkt.
5. Nachdem alle Testfälle erfolgreich abgewickelt wurden, erfolgt das bereits beim Ex-
port beschriebene abschließende Prozedere.
8.5.1 Kosten
Die Gebühren für die Zertifizierung richten sich nach dem Aufwand für die Erstellung der
Testbeschreibungen und Durchführung der Tests. Außerdem muss die Entwicklung und
Pflege der GTDS-Plattform sowie des automatischen Prüfwerkzeuges anteilig finanziert
werden. Der erforderliche Aufwand hängt ab von der gewählten MVD und davon, ob der
Export und/oder Import zertifiziert wird.
8.5.2 Nachvollziehbarkeit
Ein wesentlicher Aspekt einer unabhängigen Zertifizierung ist, dass die Ergebnisse nach-
vollziehbar und wiederholbar sind. Dies wird in dem hier vorgestellten Verfahren mit
ausführlichen Dokumentation des Testfortschrittes auf der GTDS-Plattform sichergestellt.
Für alle Beteiligte ist transparent nachvollziehbar, was wann von wem mit welchem Er-
gebnis geprüft wurde. Bei eventuellen Zweifeln kann die Zertifizierung jederzeit von
autorisierten Supervisoren überprüft werden.
Zu Beginn der Entwicklung der hier vorgestellten Zertifizierung war mvdXML noch nicht
verfügbar. Zur automatisierten Auswahl derjenigen IFC-Elemente, die für die Zertifizie-
160 R. Steinmann
rung auf Basis einer bestimmten MVD maßgeblich sind, erkannte man allerdings, dass
eine mvdXML, wie wir sie heute kennen, wünschenswert wäre. Man behalf sich mit Ex-
cel-Tabellen einem datenbankgestützten Werkzeug, das in GTDS implementiert wurde.
Diese Mühe kann man sich für den Aufbau künftiger Zertifizierungen dank des inzwi-
schen verfügbaren mvdXML-Formates ersparen (siehe Kap. 6).
8.6 Ausblick
Zum Zeitpunkt der Drucklegung dieses Buchs wurden bereits eine Vielzahl von BIM-
Anwendungen auf Basis der IFC-Version 2 × 3 und des Coordination View 2.0 erfolg-
reich zertifiziert und die Vorarbeiten für die künftige Zertifizierung auf Basis der IFC4
und weiterer MVDs aufgenommen. Die Erfahrungen, die man bei der Entwicklung und
Durchführung des hier beschriebenem Zertifizierungsverfahren (Certification 2.0) gesam-
melt hat, fließen in die künftigen Zertifizierungen ein.
Über die IFC hinaus entwickelt buildingSMART weitere Datenstandards:
Über die Zertifizierung von IT-Anwendungen hinaus wurde auch der Bedarf weiterer
Zertifikate erkannt. Dazu gehören:
sowohl den fachlichen Umfang, die Beschreibung der Rollen und Verantwortlichkeiten
der BIM-Beteiligten als auch den zeitlichen Aufwand festlegen. Ausbildungsrichtlini-
en geben nicht nur den Rahmen für die Entwicklung von Ausbildungsangeboten vor,
sondern sind zugleich auch Grundlage für deren Akkreditieren. Nur Abschlüsse von
akkreditierten Ausbildungsangeboten können als seriös anerkannt werden.
BIM-Daten-Zertifikate überprüfen die erreichte Qualität von BIM-Modellen, die zwi-
schen den Beteiligten ausgetauscht werden. Im Gegensatz zur Qualität der Daten-
schnittstellen der Softwaresysteme geht es hier um die Modellierungsqualität, die durch
die Anwender erbracht wird. Wie oben beschrieben, werden in IDMs zur Unterstüt-
zung der Daten-Kommunikation zwischen Prozessschritten die Daten-Austauschanfor-
derungen, sogenannte „Exchange Requirements“, definiert. Um sich auf diese Daten
insbesondere im Rahmen vertraglicher Verpflichtungen tatsächlich verlassen zu kön-
nen, müssen sie unabhängig auf Vollständigkeit und Richtigkeit geprüft werden.
BIM-Prozess-Zertifikate überprüfen, ob ein Unternehmen in der Lage ist, BIM in der
erforderlichen Qualität umzusetzen. Bereits mit ISO 9000 wurden Zertifikate entwi-
ckelt, die prüfen, ob ein Unternehmen grundsätzlich befähigt ist, Qualität zu erzeugen,
ohne das tatsächlich erreichte Qualitätsniveau zu überprüfen. Während oben beschrie-
bene Zertifikate das tatsächlich erreichte Qualitätsniveau von Software, Menschen und
Daten überprüft, vermittelt das BIM-Prozess-Zertifikat einen wichtigen Hinweis, ob
die erforderlichen Rahmenbedingungen gegeben sind. Voraussetzung für diese Zertifi-
kate ist, dass BIM-Prozesse und Verfahren beschrieben und in allgemein anerkannten
Standards festgelegt wurden. Diese Standards sind darüber hinaus auch eine weitere
wichtige inhaltliche Grundlage für die BIM-Ausbildung.
Zum Zeitpunkt der Drucklegung wird über diese weiterführenden Zertifikate an un-
terschiedlicher Stelle bereits diskutiert. In einigen Ländern wurden sogar schon erste
rechtsverbindliche Standards entwickelt, die als künftige Grundlage für diese Zertifikate
dienen können. buildingSMART wird versuchen, die Weiterentwicklung und internatio-
nale Abstimmung zu moderieren.
Literatur
Zusammenfassung
Ordnungssysteme sind im Bauwesen ein wichtiges Mittel, um Bedeutungen von Be-
griffen eindeutig festzulegen und zu strukturieren, damit sie von allen Beteiligten kon-
sistent verwendet werden. In ihrer bewährten Form als Texte und Tabellen sind sie
für den Gebrauch von Experten bestimmt, um eindeutige und verbindliche Spezifi-
kationen, Anforderungen und Absprachen über Bauwerke, ihre Bauteile sowie deren
Eigenschaften zu erstellen. Für den Einsatz im Kontext von Building Information Mo-
deling können sie in maschinenlesbarer Form zu semantischen Auszeichnung von Mo-
dellobjekten verwendet werden und so den Informations- und Datenaustausch weiter
harmonisieren. In diesem Kapitel werden die Grundlagen, Anwendungen und techni-
schen Umsetzungen verschiedener Ordnungssysteme vorgestellt und erläutert.
9.1 Einleitung
Als der Ingenieur und Gelehrte Marcus Vitruvius Pollio etwa um das Jahr 15 vor unserer
Zeitrechnung erstmals ein umfangreiches Kompendium über die gebaute Umwelt vor-
legte, strukturierte er das gesammelte Wissen seiner Zeit in zehn Bänden, die jeweils in
einzelne Kapitel und Abätze untergliedert waren. Dieses Traktat, die Zehn Bücher über
die Architektur umfasste eine umfangreiche Sammlung des seinerzeitigen Standes der
Technik im Bauwesen. Das Spektrum des aus praktischen Beispielen gesammelten Wis-
sens reichte von den kleinsten Bestandteilen des antiken Betons, über Konstruktionsdetails
des Mauerwerks- und Holzbaus, der Planung von Heizungs- und Lüftungssystemen, den
formalästhetischen Gliederungen von Stützen und Säulen bis hin zu infrastrukturellen
Jakob Beetz
Technische Universiteit Eindhoven, Department of the Built Environment, Urban Science and
Systems, P.O. Box 513, 5600 Eindhoven, Niederlande
e-mail: J.Beetz@bwk.tue.nl
in der Unterstützung der Verknüpfung verschiedener Wissensbereiche, wie sie etwa kenn-
zeichnend für das Bauwesen sind.
Abb. 9.1 Verknüpfungen von Bauwerksmodellen, Klassifikationen und Herstellerdaten mit dem
buildingSMART Data Dictionary (bSDD) und IFC Instanzen
Eine einfache Ausprägung eines Ordnungssystems stellt das gemeinsame, formal definier-
te Fachvokabular, die sogenannte Nomenklatur und Terminologie eines Fachgebietes
dar: In ein- oder mehrsprachigen Listen werden dabei gebräuchliche Fachbegriffe mensch-
licher Sprache versammelt und (meist alphabetisch) geordnet. Neben der gebräuchlichen
Schreibweise (Syntax) einzelner Fachwörter wird dabei oft auch die Verwendung und
Bedeutung (Semantik) eines Begriffes (engl. concept) in kurzen Definitionen festgehal-
ten. Auch weitere Mittel wie Illustrationen und Beispiele dienen dabei dazu, den Raum
für Interpretationen eines Begriffes möglichst zu beschränken oder ihre unterschiedlichen
Bedeutungsebenen gegeneinander abzugrenzen.
Zwei- oder mehrsprachige Wörterbücher (engl. dictionary) können in entsprechend
einfache Datenmodelle übertragen und bereits zur Automatisierung eingesetzt werden:
Ein Anwendungsgebiet solcher Wörterbücher ist beispielsweise die fachgerechte, teil-
automatisierte Übersetzung etwa von Bauteilkatalogen, Dienstleistungsbeschreibungen
oder Angebotsabgaben in internationalen Projekten. Ein weiteres Anwendungsfeld ist die
automatische Übersetzung von Softwarewerkzeugen: Statt den Quellcode der Bedienober-
fläche eines Softwarewerkzeugs jeweils neu in natürliche Sprachen zu übersetzen, werden
alle Begriffe und Wörter in Bedienelementen wie Menüs, Dialogboxen, Wertefeldern und
Hilfstexten zur Laufzeit des Programmes dynamisch aus entsprechenden Wörterbüchern
ausgelesen.
9.3.2 Klassifikationssysteme
ander in Beziehung gesetzt und damit geordnet. Die Klassifizierung eines Bauteiles wie
beispielsweise einer Stütze kann dabei auf Basis unterschiedlicher Kategorien, Aspekte
oder Facetten geschehen: Nach ihrer Funktion („tragen“), ihrer Form („zylindrisch“), ihrer
Lage („vertikal“), ihres Materials („Stahlbeton“) oder ihres Gewerkes („Bauwerk – Bau-
konstruktionen“). Je nach entsprechender Achse ihrer Unterteilung werden unterschiedli-
che Relationen zwischen den einzelnen Elementen einer Klassifikation gewählt.
Eine der am häufigsten anzutreffenden Beziehungen ist die Spezialisierung: Vom All-
gemeinen ins Besondere werden dabei Kategorien von ähnlichen Begriffen zueinander ins
Verhältnis gesetzt: Ein HEA-Profil ist eine besondere Form des „Stahlträgers“, der eine
besondere Art des „Tragwerkselementes“ ist. Oft werden diese Spezialisierungsrelationen
mit einfachen Worten der natürlichen Sprache wie „ist-ein“ (engl. „is-a“) wiedergegeben.
Werden eine Vielzahl solcher Konzepte durch die gleichen Beziehungen geordnet, entste-
hen hierarchische Klassifikationsbäume, deren Knoten und Blätter die Konzepte und deren
Kanten die jeweilige Beziehung repräsentieren. Neben solchen Spezialisierungsbäumen
sind vor allem in den Ingenieursdisziplinen oft auch andere ordnende Beziehungen anzu-
treffen. Beispiele solcher Ordnungsachsen sind Teil-Ganzes-Beziehungen die als „Parto-
nomien“ bezeichnet werden. Ein einfaches Mittel der Trennung solcher unterschiedlichen
Ordnungsprinzipien stellen Tabellen dar, in denen die jeweiligen Konzepte in verschiede-
nen Ordnungen gruppiert werden.
Eine wichtige grundlegende Einteilung der im Bauwesen maßgeblichen Funktionen,
Elemente und Arbeiten entstand in den 1950er-Jahren in Schweden mit dem Titel „Sam-
arbetskomitten for Byggnadsfragor“ SfB (Arbeitskomitee für Gebäudefragen) (Giertz
1982). Dieses Klassifikationssystem stellt bis heute eine wichtige Grundlage der in ver-
schiedenen Ländern gebräuchlichen Klassifikationen wie OmniClass oder Uniclass dar.
Praxisrelevante Beispiele solcher Klassifikationen sind im Abschn. 9.4 näher beschrieben.
9.3.3 Ontologien
Klassifikationen von Begriffen sind auf jeweils eine einzelne Beziehung wie die Spe-
zialisierung beschränkt, d. h. sie werden nur anhand eines einzelnen Aspektes entlang
einer Achse (Allgemein-Besonders) geordnet. Mithilfe von Ontologien lassen sich meh-
rere Beziehungen und Aspekte gleichzeitig in einem einzelnen Modell beschreiben. Ob-
wohl der Begriff der Ontologie sowohl in seiner klassisch-philosophischen Definition
(„Lehre des Seienden“) als auch seiner modernen computerbezogenen Definition durch
Gruber („miteinander geteilte Konzeptualisierung“) (Gruber 1993) einfache Fachvokabu-
larien und Klassifikationen durchaus einschließt, wird in der Praxis „Ontologie“ häufig
jedoch mit ausdrucksstärkeren Wissensmodellen verbunden. Neben den oben erläuterten
Beziehungen der einzelnen Konzepte zueinander werden bei Ontologien meist mehre Be-
ziehungsarten verwendet. Ihre Modellierung ist auf den Prinzipien der Formalen Logik
aufgebaut, auf deren Basis Schlussfolgerungen aus einzelnen Elementaraussagen (Axio-
me) bestehen, etwa
9 Ordnungssysteme im Bauwesen 169
9.4.1 Klassifikationstabellen
Hervorgegangen aus dem schwedischen SfB-System steht mit den drei Teilen der
ISO 12006-Norm ein Rahmenwerk zur Definition von Klassifikationssystemen auf in-
ternationaler Ebene zur Verfügung. Dieses „International Framework for Dictionaries“
170 J. Beetz
Abb. 9.2 Schematische Übersicht des Teils 2 der ISO 12006, die die ursprüngliche konzeptionelle
Grundlage vieler Klassifikationssysteme und des buildingSMART Data Dictionary bildet
(IFD) ist – wie die IFC (Kap. 6) und MVD (Kap. 7) – offizieller Bestandteil der Stan-
dards der buildingSMART Organisation. Im Teil 2 dieses Standards wird eine allgemeine
Hauptstruktur der im Bauwesen zu beschreibenden Konzepte definiert, wie etwa die
Gliederung in „Produkt“, „Prozess“, „Ressource“, die aber lediglich den allgemeinen
konzeptionellen Rahmen bereitstellen, ohne bindend für die modellierbaren Gliederungen
zu sein. Eine Übersicht dieser Gliederung ist in Abb. 9.2 dargestellt.
Teil 3 der ISO 12006-Norm stellt ein konkretes Datenmodell zur Modellierung bau-
relevanter Konzepte zur Verfügung (ISO 12006-3:2007). Eine zentrale Bedeutung für die
Modellierung hat hierbei das Basisprinzip, dass alle Konzepte jeweils Bezeichner (engl.:
label) und Beschreibungen (engl. description) in unterschiedlichen Sprachen haben kön-
nen. Maßgeblich für die Identifizierung und Verwendung eines Konzeptes sind dabei nicht
die Bezeichnungen in einer bestimmten Sprache („Türgriff“, „door knob“), sondern sein
Globally Unique Identifier (GUID).
9 Ordnungssysteme im Bauwesen 171
Abb. 9.3 Browserinterface des buildingSMART Data Dictionaries (bSDD). Dargestellt sind die
Beschreibungen des Konzeptes mit dem deutschen Namen „Tür“, seinen Eigenschaften und Be-
standteilen (unten), sowie relevanter Normen und Vorschriften (rechts)
172 J. Beetz
künftig weiter an Bedeutung gewinnen wird. Abbildung 9.3 zeigt das Webinterface, mit
dem sich dieser Datensatz erschließen und durchsuchen lässt. Da jeweils nur bestimmte
lokale Normen, Ordnungen oder Begrifflichkeiten relevant sind, können diese im bSDD in
sogenannten Kontexten zusammengefasst werden, die dann als Filter verwendet werden
können, um etwa nur alle deutschsprachigen Konzepte und Beziehungen zu wählen.
Die kurz vor der Veröffentlichung stehende Klassifikation DIN SPEC 91400 ist ein weite-
rer Schritt in Richtung der umfassenden maschinenlesbaren Aufbereitung von Ordnungs-
systemen. Wie auch im bereits oben erwähnten internationalen buildingSMART Data
Dictionary sind viele Konzepte dieser umfassenden Klassifikation mit den jeweiligen
Klassendefinitionen des Datenmodells Industry Foundation Classes verlinkt. Während im
internationalen bSDD bislang jedoch vor allem Ordnungssysteme aus dem englischspra-
chigen, skandinavischen und niederländischen Raum verknüpft sind, ist das Alleinstel-
lungsmerkmal der DIN SPEC 91400 ihre Anlehnung an das in Deutschland verwendete
Standardleistungsbuch Bau (STLB-Bau), das seinerseits mit weiteren Normen, Vorschrif-
ten und Richtlinien wie der Vergabe- und Vertragsordnung für Bauleistungen (VOB) und
den Kostengruppen nach DIN 276 verbunden ist. Ähnlich dem bSDD ist auch der Inhalt
der DIN SPEC 91400 über verschiedene Schnittstellen, darunter Webinterfaces, verwend-
bar. Verbindungen zu Bauteilkatalogen namhafter Bauproduktehersteller befinden sich
ebenso in der Entwicklung wie die Verknüpfung zu Objekten und Eigenschafen innerhalb
von proprietären Objektmodellen und BIM-Formaten.
Ein grundlegendes Problem der Strukturierung von Information durch die maschinelle
Verwendung von Ordnungssystemen stellt die Heterogenität ihrer technischen Repräsen-
tationen dar. Die verschiedenen Vokabulare, Klassifikationen, Konzeptmodelle und On-
tologien wurden in der Vergangenheit durch viele unterschiedliche Modelliersprachen,
Datenformate, Datenbankschemata und Schnittstellen repräsentiert und erschlossen. Re-
levante Ordnungssysteme für BIM-Werkzeuge nutzbar zu machen, ist bis heute oft mit ei-
nem nicht unerheblichen Implementierungsaufwand der jeweiligen Hersteller verbunden.
Die verschiedenen Repräsentationen führen zu Schwierigkeiten beim Austausch seman-
tisch eindeutiger Information.
Um diesem Interoperabilitätsproblem zu begegnen, wurden bereits in den 1990er-Jah-
ren Methoden und Techniken der Verteilten Wissensmodellierung entwickelt, die unter
dem Begriff Semantic Web zusammengefasst sind (Berners-Lee et al. 2001). Die zentrale
Leitidee ist, generische Mittel der Wissensmodellierungen zur Verfügung zu stellen und
von der unabhängigen Organisation des World Wide Web Consortiums (W3C) standardi-
9 Ordnungssysteme im Bauwesen 173
sieren zu lassen, mit deren Hilfe sich beliebige Wissensdomänen auf eine einheitliche Wei-
se modellieren, erschließen und miteinander verknüpfen lassen. Dazu wird auf der tech-
nischen Ebene des Resource Description Framework (RDF) (W3C 2014) jede Aussage
in einem Modell, etwa einer Eigenschaft oder einer Beziehung eines Konzeptes, mithilfe
eines Tripletts aus Subjekt, Prädikat und Objekt dargestellt. Jeder dieser drei Bestandteile
kann durch einen Identifikator (Uniform Resource Identifier, URI) gekennzeichnet wer-
den, dessen gebräuchlichste Form eine Netzadresse (Uniform Resource Locator URL) ist.
Dadurch lassen sich Konzepte, Attribute, Modelle und Instanzen über Datei- und Rechner-
grenzen in Netzwerken verteilen und einheitlich wiederverwenden. Auch wiederkehrende
Basiskonzepte der Wissensmodellierung wie „Klasse“, „Eigenschaft“ und „Wert“ sind in
allgemeingültigen Sprachvokabularen wie RDF-Schema (RDFS), Web Ontology Langua-
ge (OWL) und Simple Knowledge Organisation System (SKOS) standardisiert, sodass sie
universell einsetzbar sind (Allemang und Hendler 2011). Für baurelevante Klassifikatio-
nen bedeutet das, dass das Konzept „Außentür“ seine Eigenschaft „einbruchhemmend“
sowie sein Wert „Klasse RC 4 nach EN 1627“ unzweideutig definiert, beschrieben, pu-
bliziert und wiederverwendet werden können. Jeder Kommunikationspartner und jedes
Werkzeug „versteht“ dann bei einem Informationsaustausch dasselbe, ohne die semanti-
sche Interpretation durch aufwendige und fehleranfällige Übersetzungen zu gefährden.
Für das Bauwesen gibt es bereits einige Vokabulare, Klassifikationen und Ontologien
die auf diese Art verfügbar gemacht wurden. Die freie Klassifikationsstruktur FreeClass
stellt ca. 2800 Klassen vornehmlich zu Baustoffen und -materialien zur Verfügung, die in
acht Sprachen übersetzt sind. Auf dieser Klassifikation aufbauend wurde ein beispielhaf-
ter Produktdatensatz erstellt, der ca. 2,2 Mio. Angebote von rund 70.000 Bauprodukten
von knapp 90 Herstellern mit ihren jeweiligen Verkaufsstandorten in Österreich mithilfe
einfacher, standardisierter Werkzeuge einheitlich durchsuchbar und von entsprechenden
Suchmaschinen indizierbar macht (Radinger et al. 2013). Die globale Vernetzung sol-
cher verlinkter Datensätze wird unter dem Sammelbegriff Linked Data zusammengefasst.
Neben allgemeinen Datensätzen wie der semantisch aufbereiteten Form des Wikipedia
Corpus DBPedia (DBPedia 2014; Auer et al. 2007) und Yago (Suchanek et al. 2007) ent-
stehen weitere bausemantische Klassifikationen und Vokabulare wie der Getty Arts and
Architecture Thesaurus (AAT) (Getty 2015).
Die Integration und Verknüpfung baurelevanter Ordnungssysteme und Gebäudeinfor-
mationsmodelle durch die standardisierten und etablierten Modellierungs-, Verbreitungs-
und Verarbeitungstechniken der Semantic Web Initiative sind ein wichtiger Schritt, um
von insulären Einzellösungen zu einer interoperablen und ,intelligenten‘ Informationsver-
arbeitung im Bauwesen und darüber hinaus zu kommen.
erlässlicher Bestandteil des Building Information Modeling. Ihre Funktion liegt darin,
durch semantisch eindeutige Begriffsdefinitionen, die auf vielfältige Weise zueinander in
Beziehung gesetzt werden, den Informationsaustausch zwischen den am Bau Beteiligten
und ihren Softwarewerkzeugen zu erleichtern, unmissverständlicher und damit weniger
fehleranfällig zu machen. Als Ergänzung zu fest vorgeschriebenen Modellschemata wie
den Industry Foundation Classes liegt ihr idealer Einsatzzweck in der zusätzlichen Aus-
zeichnung von Bauteilen und Elementen im räumlichen Gefüge eines Bauwerkes. Die
fortschreitende Digitalisierung und maschinenlesbare Aufbereitung etablierter Nomenkla-
turen, Klassifikationen, Normen und Regelwerke befindet sich derzeit in vollem Gange
und wird in der Praxis bereits vielfältig eingesetzt. Neuere Entwicklungen im Bereich
des Semantic Web und Linked Data werden die Integration und dynamische Verknüpfung
verschiedener, semantisch angereicherter Informationsressourcen in digitalen Gebäudein-
formationsmodellen weiter erleichtern.
Literatur
Verwendete Literatur
Allemang, D. & Hendler, J., (2011). Semantic Web for the Working Ontologist: Effective Modeling
in RDFS and OWL, Elsevier. ISBN 9780123859662
Auer, S. et al., 2007. Dbpedia: A nucleus for a web of open data. In: K. Aberer et al. (Hrsg.):
ISWC/ASWC 2007, LNCS 4825, pp. 722–735, 2007
Berners-Lee, T., Hendler, J. & Lassila, O. (2001). The semantic web. Scientific American, 284(5),
28–37
buildingSMART (2015) buildingSMART Data Dictionary – ISO 12006-3 based ontology for the
building and construction industry. http://bsdd.buildingsmart.org/, letzter Zugriff Januar 2015
CPIC – Construction Project Information Committee (2015) Uniclass2 Classification Tables, http://
www.cpic.org.uk/uniclass2/, letzter Zugriff Januar 2015
DBPedia (2014) The DBpedia Knowledge Base, http://dbpedia.org, letzter Zugriff Januar 2015
DIN SPEC 91400:2015-01 (2015) Building Information Modeling (BIM) – Klassifikation nach
STLB-Bau;
GAEB (2014). Standardleistungsbuch STLB-Bau. http://www.gaeb.de/de/produkte/stlb-bau/, letz-
ter Zugriff Januar 2015
Getty (2015) The Getty Research Institute Art & Architecture Thesaurus http://www.getty.edu/
research/tools/vocabularies/aat/, letzter Zugriff Januar 2015
Giertz, L. (1982). SFB and Its Development 1950-1980. CIB/SFB International Bureau; Foras For-
bartha distributor, Dublin, Ireland. ISBN 0906120918
Gruber, T. (1993). A translation approach to portable ontology specifications. Knowledge Acquisi-
tion, 5(2), 199–220
ISO 12006-3:2007 (2007) Building construction – Organization of information about construction
works – Part 3: Framework for object-oriented information
ISO 13567-1:1998 (1998) Technical product documentation – Organization and naming of layers
for CAD – Part 1: Overview and principles
9 Ordnungssysteme im Bauwesen 175
Lenat, D.B. & Guha, R.V., (1993). Building large knowledge-based systems: Representation and
inference in the CYC project. Artificial Intelligence, 61(1)
Studer, R., Benjamins, V.R. & Fensel, D., 1998. Knowledge engineering: Principles and methods.
Data & Knowledge Engineering, 25(1–2), pp. 161–197
Suchanek, F.M., Kasneci, G. & Weikum, G., (2007). Yago: a core of semantic knowledge. In Pro-
ceedings of the 16th international conference on World Wide Web. ACM, pp. 697–706.
Radinger, A. et al., (2013). BauDataWeb: the Austrian building and construction materials market
as linked data. In Proceedings of the 9th International Conference on Semantic Systems. ACM,
pp. 25–32
W3C (2014) RDF 1.1 Concepts and Abstract Syntax, W3C Recommendation 25 February 2014,
http://www.w3.org/TR/rdf11-concepts/, letzter Zugriff Januar 2015
Weiterführende Literatur
ISO 12006-2:2001 (2001). Building construction – Organization of information about construction
works – Part 2: Framework for classification of information
3D-Stadtmodellierung: CityGML
Thilo Brüggemann und Petra von Both
10
Zusammenfassung
Virtuelle 3D-Stadtmodelle gewinnen kontinuierlich an Bedeutung und werden be-
reits heute für vielfältige Anwendungszwecke eingesetzt. Ihr Einsatzspektrum reicht
dabei von der einfachen grafischen Visualisierung stadträumlicher Strukturen über
Telematik- und Navigationssysteme bis hin zu Augmented-Reality-Applikationen so-
wie komplexen Simulationen im urbanen Kontext. Als offenes und herstellerneutrales
Format für die Persistierung und den fachübergreifenden Austausch konnte sich der
internationale OpenGIS® Datenstandard CityGML etablieren. CityGML erlaubt ei-
ne vereinheitlichte Abbildung urbaner Strukturen mittels thematisch klassifizierter
Stadtobjekte und beschreibt neben Geometrie, Lage und Aussehen auch dedizier-
te semantische Eigenschaften sowie topologische Beziehungen. Ferner ermöglicht
der Standard die simultane Repräsentation des Abbildungsgegenstands in mehreren
kohärenten, aufeinander aufbauenden Detaillierungsgraden. Durch eine konvergen-
te Deklination der stadträumlichen Strukturen vom zweidimensionalen regionalen
Maßstab bis hin zu differenzierten architektonischen 3D-Gebäudemodellen realisiert
CityGML zudem auch eine integrative Funktion und verbessert die Interoperabilität
zwischen GIS-Applikationen und BIM im Kontext domänenübergreifender Kollabora-
tionen.
mulationen im urbanen Gefüge. Die stetig zunehmende Zahl der Anwendungen resultiert
zwangsläufig in differenzierten kontextuellen Anforderungen hinsichtlich des spezifischen
Umfangs und der Granularität sowie Skalierbarkeit und Interoperabilität der eingesetzten
Datenbasen. Dies erfordert gleichermaßen flexible wie integrative Ansätze bei ihrer Mo-
dellierung.
Als offenes und herstellerneutrales Format für die Darstellung, Persistierung und
den fachübergreifenden Austausch virtueller Stadtmodelle konnte sich der internationale
OpenGIS® Datenstandard CityGML etablieren. CityGML erlaubt eine vereinheitlichte
Abbildung urbaner Strukturen mittels thematisch klassifizierter Stadtobjekte und be-
schreibt neben Geometrie, Lage und Aussehen auch semantische Eigenschaften und
topologische Objektrelationen. Ferner ermöglicht der Standard die simultane Reprä-
sentation des Abbildungsgegenstands in mehreren kohärenten, aufeinander aufbauenden
Detaillierungsgraden. Durch eine konvergente Deklination der stadträumlichen Strukturen
vom zweidimensionalen regionalen Maßstab bis hin zu differenzierten architektonischen
3D-Gebäudemodellen realisiert CityGML zudem auch eine integrative Funktion und ver-
bessert – quasi als Lückenschluss – die Interoperabilität zwischen GIS-Applikationen und
BIM im Kontext domänenübergreifender Kollaborationen.
10.1 Geomodellierung
dards unter dem Label OpenGIS®, und dem für die Normenreihe 191xx zuständigen
technischen Komitee der ISO festgelegt wird (ISO 2005). Sie ist in XML-Notation ko-
diert und unterstützt sowohl die Darstellung dreidimensionaler Objektgeometrien als auch
die Abbildung nichtraumbezogener und topologischer Eigenschaften. Originär als neutra-
les Austauschformat für 3D-GIS-Applikationen vorgesehen, wurde GML schließlich als
übertragbares Meta-Anwendungsschema zur Generierung dedizierter Fachmodelle ausge-
legt. Folglich steht ein universelles Geo-Basisschema zur Verfügung, welches mittlerweile
Grundlage oder integraler Bestandteil verschiedener Standards ist und damit letztlich auch
die allgemeine Interoperabilität der Geomodellierung maßgeblich verbessert hat.
So findet das GML-Anwendungsschema u. a. in der Normbasierten Austauschschnitt-
stelle (NAS) des Deutschen amtlichen AFIS-ALKIS-ATKIS-Geoinformationssystems
(AAA) zur Verwaltung digitalisierter Topografie- und Liegenschaftskatasterdaten Ver-
wendung (AdV 2009, S. 78 ff.). Eine weitere verbreitete XML-Auszeichungssprache für
Geoinformationen ist die Keyhole Markup Language (KML). Sie wurde zunächst von
Google für die proprietäre Anwendung in Geobrowsern (bspw. Google Earth) entwickelt,
ist mittlerweile aber ein freier OpenGIS-Standard des OGC und wird von vielen Appli-
kationen, wie etwa moderner Navigationssoftware, unterstützt. Das 3D-Geometriemodell
der KML basiert weitestgehend auf dem GML-Schema, ist dabei jedoch lediglich auf gra-
fische Darstellung und geografische Verortung ausgelegt, semantische oder topologische
Eigenschaften können hingegen nur sehr eingeschränkt abgebildet werden (Wilson 2008).
Die Neutralität der GML kommt außerdem auch der Interoperabilität mit Modellen und
Formaten zugute, welche nicht auf den normativen Grundlagen der ISO 191xx aufbauen.
Der in den Fachdomänen Geodäsie und Tief- bzw. Trassenbau etablierte nichtproprie-
täre Austauschstandard LandXML ist bereits partiell mit GML interoperabel, verwendet
jedoch ein weniger umfangreiches Geometriemodell. Aktuelle Bestrebungen des OGC
beabsichtigen, die LandXML-Funktionalität mittelfristig in ein normkonformes GML-
Anwendungsschema zu überführen (OGC 2014).
180 T. Brüggemann und P. von Both
Bei der City Geography Markup Language (CityGML) handelt es sich ebenfalls um ein
ISO-konformes GML-Anwendungsschema. Der Standard baut direkt auf der GML-Ver-
sion 3.1.1 auf und erweitert bzw. konkretisiert deren Abbildungsgegenstand um die diffe-
renzierte Repräsentation urbaner Entitäten und Komplexe. Modelliert werden dabei eben-
so Landschafts- wie Stadtobjekte. Dies umfasst neben geografischen und topografischen
Strukturen auch Wasserflächen, Vegetation, Infrastrukturbauwerke und Verkehrsflächen
sowie Stadtmöblierung und Gebäude. Der Absicht folgend, eine möglichst universale De-
finition eines integrierten virtuellen Stadtmodells zu schaffen, finden in CityGML gleich-
sam die Aspekte Geometrie (räumliche Gestalt und Lage), Semantik (Thematik und Be-
deutung), Topologie (lokale Beziehungen und Nachbarschaften) sowie Aussehen (äußere
Erscheinung und Wirken) Berücksichtigung. Zudem erlaubt es das Modellkonzept, Ob-
jekte in multipler Granularität (Detailreichtum und Akkuratheit) zu beschreiben, um de-
zidierten Informationsbedarfen verschiedener Disziplinen zu entsprechen und gleichsam,
bei üblicherweise sehr komplexen Stadtmodellen von besonderer Bedeutung, eine effizi-
ente Handhabung zu gewährleisten.
Mit CityGML steht ein konvergentes semantisches Stadt-Informationsmodell für den
domänenübergreifenden Gebrauch zur Verfügung, welches sich in der Praxis zunehmend
etabliert. Aufgrund seiner Informationsdichte und Flexibilität kann der Standard in multi-
modalen Anwendungskontexten eingesetzt werden. Seine Funktionalität ist dabei vielfäl-
tig; von der Informationsintegration und -aggregation, über die grafische Visualisierung
bis hin zu komplexen Analysen und Simulationen in urbanen Systemen.
Entwicklung und Spezifikation der CityGML wurden 2002 durch Mitglieder der Special
Interest Group 3D (SIG 3D) eingeleitet. Die SIG 3D wurde im selben Jahr als ein offe-
nes Arbeitsgremium innerhalb der Geodateninitiative Nordrhein-Westfalen (GDI NRW)
gegründet und versammelt gleichermaßen Vertreter aus der öffentlichen Verwaltung, Wis-
senschaft und Wirtschaft. Ihre ursprüngliche Motivation lag dabei in der Diskussion und
Erarbeitung von Lösungen für eine vereinheitlichte, interoperable 3D-Geovisualisierung
(Altmaier und Kolbe 2003). Aufgrund des stetig steigenden überregionalen Interesses so-
wie nicht zuletzt auch der zunehmenden Verbreitung von CityGML wurde die SIG 3D
2010 schließlich als offizieller Arbeitskreis von der vom Bundesamt für Kartographie und
Geodäsie (BKG) koordinierten Geodateninfrastruktur Deutschland (GDI-DE) aufgenom-
men und fungiert seither als nationales sowie in zunehmendem Maße auch internationales
Netzwerk für die Repräsentation von 3D-Geodaten (Gröger et al. 2012, S. xiv f.).
Um die internationale Akzeptanz zu erhöhen und damit die Etablierung langfristig zu
befördern, entschied die SIG 3D bereits im Jahr 2004, CityGML in das Open Geospa-
tial Consortium zur Standardisierung einzubringen. 2008 wurde die Modellversion 1.0
10 3D-Stadtmodellierung: CityGML 181
schließlich offizieller OpenGIS Standard der OGC. Die Standardisierung der aktuell gül-
tigen Version 2.0 folgte im Jahr 2012 (Gröger et al. 2012).
2007 leitete die Europäische Union die Initiative Infrastructure for Spatial Information
in the European Community (INSPIRE) ein. Sie verfolgt das Ziel, langfristig eine europa-
weit einheitliche Geodateninfrastruktur zu schaffen, um eine transnationale Interoperabi-
lität sicherzustellen (EU 2007). Alle Mitgliedstaaten werden damit verpflichtet, uniforme
Geobasis- und -fachdaten bereitzustellen und anzuwenden. Zur Identifikation geeigneter
Konzepte für die Geodaten-Harmonisierung wurde ein internationales Arbeitsgremium
geschaffen, dem auch die GDI-DE und SIG 3D angehören. Das Gremium bestimmte
CityGML schließlich zum Referenzmodell für das Thema Gebäude. INSPIRE übernimmt
infolge dessen wesentliche Teile des CityGML-Schemas und erweitert diese gemäß kon-
kreter Informationsbedarfe (siehe Abb. 10.1). Zur Wahrung der Interoperabilität wird eine
analoge Erweiterung von CityGML in Betracht gezogen. Die Einführung von INSPIRE
ist jedoch erst für das Jahr 2019 avisiert.
10.2.2 Modellstruktur
Bei der CityGML handelt es sich um eine Implementierung des konzeptuellen GML3-
Anwendungsschemas. Sie übernimmt dessen Modellierungsregeln sowie die XML-Syn-
tax und basiert damit gleichermaßen auf den normativen Grundlagen der ISO 191xx-
Reihe. Ein wesentlicher Vorteil dieses Konformitätsprinzips liegt, neben der obligatori-
schen Schemakonsistenz, vor allem in der intendierten Interoperabilität des Standards
(vgl. Abb. 10.1). Im Speziellen verwendet CityGML 2.0 das 3D-Geometrie- sowie das
objektbezogene Fachinformationsmodell (General Feature Model) der GML (ISO 2005,
ISO 2006). Hieraus werden konkrete Regeln zur Definition und Repräsentation von Geo-
informationen und -objekten abgeleitet.
Das Modellschema der CityGML ist hierarchisch gegliedert und modular organi-
siert (Gröger et al. 2012, S. 17 ff.). Zentrales Modul ist der Schemakern, welcher das
grundlegende Modellierungskonzept in einer Basisklassenstruktur definiert, bei der es
sich im Wesentlichen um eine Erweiterung des GML-Anwendungsschemas handelt (sie-
he Abb. 10.2). Als CityGML-charakteristisches Merkmal ist hier beispielsweise das
„CityObject“ spezifiziert. Es stellt die abstrakte, d. h. selbst nicht instanziierbare Meta-
klasse aller raumbezogenen Fachobjekte des Standards dar, womit es sich folglich bei
jedem Stadtmodell um eine Aggregation dieses Merkmals handelt. Eine spezielle Ei-
genschaft der CityObject-Klasse besteht dabei in der Möglichkeit zur Notation externer
Referenzen. Auf diese Weise können bestimmte Datenbezugsquellen – konkrete Objekte
externer Datenbases (wie z. B. BIM-Ressourcen oder Kataster) – bei allen CityGML-
Fachobjekten direkt referenziert werden.
Die Basisklassen des Kernmoduls stellen gemeinsame Attribute und Assoziationen
für alle ihre Ableitungen bereit. Diese Ableitungen bzw. Spezialisierungen werden auf
der hierarchisch untergeordneten Ebene in verschiedenen Anwendungsmodulen katego-
182 T. Brüggemann und P. von Both
10.2.3 Geometrie
CityGML 2.0 verwendet eine Untermenge des GML3-Geometriemodells gemäß den nor-
mativen Vorgaben der ISO 19107 (ISO 2005). Hierbei handelt es sich um das sogenannte
Begrenzungsflächenmodell (Boundary Representation, B-Rep), bei dem abgebildete Vo-
lumenkörper und Flächen indirekt durch ihre begrenzenden Flächen bzw. Kanten be-
schrieben werden (siehe Kap. 1). Die Erzeugung dreidimensionaler Geometrie erfolgt
mittels Knoten-Kanten-Flächen-Graphen, die letztlich durch das elementare Basisprimi-
tiv Knoten bzw. Punkt festgelegt werden. Eine eindimensionale Kante wird durch zwei
Punkte definiert, die 2D-Geometrie Fläche wiederum durch einen geschlossenen Polygon
aus mindestens drei Kanten und ein Volumenkörper schließlich durch seine geschlosse-
ne Oberfläche bzw. Hülle, die wiederum aus mindestens vier Flächenprimitiven zusam-
mengesetzt ist (siehe Abb. 10.3). Das einzige konkrete geometrische Basisprimitiv stellt
demnach der Knoten dar, welcher durch seine Koordinaten definiert wird. Gemäß norma-
tiver Vorgaben müssen in CityGML, analog zu GML, dabei alle Punkte absolut verortet,
d. h. georeferenziert werden. Dies erfolgt stets mittels globaler Koordinatenreferenzsyste-
me (CRS) (ISO 2007).
Gebogene oder gekrümmte Formen wie Kurven oder Wölbungen lassen sich über
das Modell nicht direkt beschreiben. Neben den einfachen Basisprimitiven Knoten, Kan-
te, Fläche und Volumen stellt das GML-Anwendungsschema jedoch spezielle Klassen
für geometrische Sammlungen, Komplexe und Aggregate zur Verfügung (Gröger et al.
2012, S. 25 ff.). Über zusammengesetzte Geometrien lassen sich schließlich auch diffe-
renziertere Formen abbilden. Ungerade bzw. unebene Objekte werden auf diese Weise
184 T. Brüggemann und P. von Both
Abb. 10.3 Prinzip der indirekten Modellierung von Volumen-, Flächen- und Kantengeometrien
10.2.4 Topologie
CityGML 2.0 stellt dezidierte Methoden zur Repräsentation semantischer und raumbezo-
gener Topologie zur Verfügung.
Räumliche Nachbarschaftsbeziehungen von Objekten werden im Regelfall über ge-
meinsame Geometrien identifiziert. Das Grenzflächenmodell eignet sich aufgrund seiner
simplen Struktur, die letztlich auf elementaren Punktkoordinaten basiert, hierzu beson-
ders gut. Eine durchgängige Dekomposition des B-Rep-Modells von dreidimensionalen
Körpern bis zu nulldimensionalen Punkten wäre zur Identifikation topologischer Abhän-
gigkeiten aber wenig effizient. Der Standard definiert daher ein Prinzip zur Modellierung
gemeinsamer Geometrieobjekte (Gröger et al. 2012, S. 26 f.). Eine instanziierte Geome-
10 3D-Stadtmodellierung: CityGML 185
trie, beispielsweise ein Raumteil oder ein Flächenabschnitt, kann dabei prinzipiell nur
einmalig durch ein bezeichnendes Geometrieobjekt repräsentiert werden. Diese dürfen
sich demnach auch nicht überlagern bzw. überschneiden, können aber zu komplexeren
Geometrieobjekten aggregiert werden. Die raumbezogenen Fachobjekte referenzieren zur
Beschreibung ihrer Gestalt schließlich die sie definierenden oder begrenzenden Geome-
trieobjekte. Dabei kann ein Geometrieobjekt von mehreren Fachobjekten oder komplexe-
ren Geometrieobjekten verwiesen, d. h. geteilt werden. Durch dieses Prinzip lassen sich
raumtopologische Beziehungen zwischen Pfaden, Flächen und Volumenkörpern expli-
zit beschreiben. Außerdem werden Redundanzen sowie Fehlerpotenziale hinsichtlich der
geometrischen Konsistenz signifikant reduziert, da bei der Segmentierung bzw. Facettie-
rung eine Vielzahl gemeinsamer Geometrien entsteht.
Ein weiteres grundlegendes Prinzip von CityGML ist kohärente Modellierung von se-
mantischen und geometrischen Eigenschaften (Gröger et al. 2012, S. 12). Das Modell
lässt sich gleichsam sowohl hinsichtlich geometrischer, als auch semantischer Aspek-
te dekomponieren. Entitäten auf semantischer Ebene werden dabei durch Fachobjekte
wie z. B. Gebäude oder Räume repräsentiert, welche durch Attribute, Assoziationen und
Aggregationen spezifiziert sind. Da diese Spezifikation jedoch keine explizite Geome-
trie beinhaltet, können ihre topologischen Beziehungen (ein Raum ist bspw. Teil eines
bestimmten Gebäudes) über die semantische Dekomposition und unabhängig von geome-
trischen Anhängigkeiten beschrieben werden (siehe Abb. 10.4).
186 T. Brüggemann und P. von Both
Abb. 10.5 Die Detaillierungsskala des CityGML 2.0-Gebäudemodells. (Nach Gröger et al. 2012,
S. 67) (Karlsruher Institut für Technologie)
Bounding Boxes aggregiert werden. Die Blöcke lassen sich durch Extrusion der Grund-
oder Traufkantenflächen auf die jeweilige Objekthöhe erzeugen. Ein Gebäude wird auf
diese Weise ohne differenzierte Dach- und Fassadenstrukturen oder Oberflächentextu-
ren dargestellt. Diese Eigenschaften werden in der nächstfolgenden Stufe LOD2 ergänzt.
Das sogenannte Oberflächenmodell beschreibt demnach charakteristische Oberflächen-
strukturen. Bei Gebäuden werden Dachformen und markante Fassadenstrukturen wie bei-
spielsweise Balkone ausgeprägt. Zudem können Objekte mit Texturen belegt werden,
sodass sich mit dem LOD2 bereits sehr realistische 3D-Visualisierungen urbaner Sze-
nen darstellen lassen. Bei der nächsten Detaillierungsstufe LOD3 handelt es sich um das
sogenannte Architekturmodell. Es präzisiert die Oberflächenstrukturen von LOD2 und be-
schreibt dabei auch Öffnungen wie Fenster oder Türen. Bei LOD4, dem sogenannten
Innenraummodell, werden schließlich auch die inneren Bauwerksstrukturen repräsentiert.
Das LOD4-Gebäudemodell beschreibt demnach auch Räume und Stockwerke, innere Ge-
bäudeinstallationen sowie Gebäudeausstattung und Mobiliar.
CityGML und das BIM-Austauschformat Industry Foundation Classes (IFC) besitzen ei-
ne Reihe offensichtlicher Analogien. Bei beiden Standards handelt es sich beispielsweise
um objektorientierte Informationsmodelle, die Gebäude hinsichtlich geometrischer, (to-
po)logischer sowie semantischer Aspekte repräsentieren. Dennoch sind die Formate nur
eingeschränkt interoperabel. Zwar bestehen bereits einige Lösungen zur partiellen Trans-
formation bzw. Konversion von IFC-Daten in das CityGML-Schema (Nagel und Häfele
2007; de Laat und van Berlo 2010), jedoch soll im Folgenden vor allem auf wesentliche
Differenzen eingegangen werden (siehe auch Tab. 10.1).
Einer der augenscheinlichsten Unterschiede liegt in der Skaligkeit beider Modelle. Wäh-
rend CityGML raumbezogene Entitäten von großmaßstäblichen Regional- und Kommu-
nalstrukturen bis auf die Gebäudeebene dekliniert, fokussieren die IFC das Gebäude als
Produkt in seiner technischen und konstruktiven Beschaffenheit bis hinunter zur Materiali-
tät elementarer Bauteilkomponenten. Die Analogie von CityGML zu den IFC konzentriert
sich damit im Wesentlichen auf den LOD4, welcher differenzierte Gebäudestrukturen be-
schreibt.
Die Diversitäten bezüglich des Abbildungsgegenstands liegen originär in den jeweili-
gen Anwendungskontexten begründet. Vorrangige Funktion von CityGML ist es, stadt-
räumliche Szenerien abbildbar zu machen, um diese grafisch wiederzugeben oder für
sekundäre Analyse- und Planungsmethoden zur Verfügung zu stellen. Die IFC fungieren
hingegen als kollektive Datenbasis für die Planungs-, Ausführungs- und Bewirtschaf-
188 T. Brüggemann und P. von Both
tungsprozesse von Gebäuden, wobei sie die spezifischen Belange aller beteiligten Fach-
domänen adoptieren und integrieren. Aus dieser Pragmatik, den Paradigmen hinsichtlich
ihrer funktionalen Verwendung, leitet sich ein grundsätzlicher Unterschied zwischen bei-
den Modellen ab.
Planungsmodelle wie die IFC dienen als Vorlage, um Originale nach ihrem Vorbild zu
erschaffen. In diesem Sinne handelt es sich um präskriptive Modelle (Stachowiak 1973,
S. 269 ff.), da sie zumeist schon vor dem Original existieren. CityGML wurde hingegen
als Mittel zur Erfassung, Analyse und Präsentation eines Gegenstands konzipiert. Da hier
das Original im Regelfall bereits vor seinem virtuellen Abbild vorliegt, spricht man von ei-
nem deskriptiven Modell. Freilich können deskriptive Modelle auch zukünftige Zustände
beschreiben. Hierbei handelt es sich jedoch immer um Prognosen, also Projektionen de-
10 3D-Stadtmodellierung: CityGML 189
derum stets Teil eines Raumstrukturelements ist. Alle semantischen Raumobjekte stellen
letztlich Spezialisierungen der Produkt-Klasse dar, der eine Geometrie zugeordnet wer-
den kann (aber nicht muss). Zur Repräsentation der Geometrie stehen den IFC dabei auch
direkte Modellierungskonzepte zur Verfügung, welche die räumliche Gestalt sehr viel ex-
akter beschreiben als die B-Rep-Methode der CityGML.
Bei CityGML werden weder Raumstrukturelemente spezifiziert, noch lässt sich das
Schema ähnlich stringent anhand semantisch-topologischer Aggregationen dekomponie-
ren (siehe Abb. 10.6). Die Konstellation semantischer Objektstrukturen beschränkt sich
stattdessen auf die Allokation von Gebäudeabschnitten, (festen) Installationen und Räu-
men. Eine ausdrückliche Definition von Stockwerken fehlt hingegen, alternativ werden
Angaben zur Geschossigkeit mittels semantischer Attribuierung der Gebäudeklasse er-
gänzt. Auch auf eine explizite Beschreibung von Bauteilobjekten verzichtet CityGML,
sondern impliziert diese lediglich durch eine entsprechende Klassifizierung der Begren-
zungsflächen definierter Gebäudeobjekte (z. B. Wandfläche oder Dachfläche). Diese bau-
teilumschreibenden Hüllen können schließlich Öffnungsobjekte referenzieren. Im Gegen-
satz zum IFC-Schema handelt es sich bei den Öffnungen jedoch um planare Geometrie-
objekte, die als Fenster oder Türen ausgeprägt werden können. Bei den IFC sind Fenster
und Türen sowie Öffnungen separat als Bauteilobjekte bzw. Strukturelemente spezifiziert.
Dabei verweisen Fenster- und Türobjekte auf ihr jeweiliges Öffnungsobjekt, während
Öffnungen und geöffnete Bauteile sich reziprok referenzieren. Die IFC folgen bei der
semantischen Strukturierung des Gebäudes damit einer streng logischen Gliederung, Ci-
tyGML dagegen einer vornehmlich geometrischen.
10 3D-Stadtmodellierung: CityGML 191
Während die IFC ein Gebäude gemäß dem BIM-Konzept von Grund auf durch seine
einzelnen Komponenten zusammensetzen und damit von innen nach außen aufbauen,
entwickelt sich das CityGML-Gebäudemodell von außen nach innen. Da bei 3D-GIS-
Applikationen im Allgemeinen und auch bei CityGML im Speziellen die geometrische
Repräsentation pragmatisch im Vordergrund sowie historisch im Hintergrund steht, ba-
sieren die Schemata letztlich auf ihren Geometriemodellen. Dementsprechend ist die
geometrische Dekomposition dominant und der semantischen Hierarchie übergeord-
net. Die IFC hingegen behandeln Semantik und Geometrie separat und unabhängig
voneinander.
10.4 Ausblick
CityGML entwickelt sich rasant. Die fortschreitende Akzeptanz und Etablierung wird da-
bei auch in nicht unerheblichem Maße durch den strukturellen Erweiterungsmechanismus
der Application Domain Extensions befördert, der das Modell schrittweise für verschie-
dene Fachdomänen qualifiziert. So wird der Standard bereits in vielen verschiedenen
Anwendungskontexten eingesetzt und von zahlreichen Applikationen unterstützt (Grö-
ger et al. 2012, S. xiv; Kolbe et al. 2014, S. 42). Das multimodale Anwendungsspektrum
umfasst dabei die Bereiche Architektur und Städtebau, Stadtmarketing und Tourismus, Zi-
vilschutz und Katastrophenmanagement, Umweltsimulation und Energiebedarfsplanung
sowie Telematik und Navigation. Seine zunehmende Relevanz drückt sich im Besonde-
ren auch durch die Anwendung bei der Verwaltung amtlicher Kataster und kommunaler
Liegenschaften aus. So wurde CityGML schon in die amtlichen Geodateninfrastrukturen
einiger Länder integriert und dient zukünftig als Grundlage des INSPIRE-Datenmodells
innerhalb der Europäischen Union.
Obschon die aktuelle Version 2.0 erst im Jahr 2012 verabschiedet wurde, erarbeiten
die Entwicklungs- und Standardisierungsgremien SIG 3D und OGC bereits Konzepte,
CityGML in der Zukunft für neue Anwendungsbereiche zu öffnen (Kolbe et al. 2014,
S. 42 f.). Hierzu zählen eine sukzessive Nachverdichtung bestehender Modellstrukturen,
etwa durch Definitionen für Stockwerke oder Materialitäten, sowie die Ergänzung neuer
Themenmodule, z. B. für die Repräsentation leitungsgebundener Infrastrukturnetze. Au-
ßerdem werden auch systemischere Ansätze diskutiert. Diese beinhalten eine Erweiterung
des LOD-Konzepts um semantische Detaillierungsstufen sowie die Anreicherung des Mo-
dells um Metadaten, komplexe Attribute und zeitdynamische Größen.
Eine wichtige Rolle bei der aktuellen und zukünftigen Entwicklung nimmt die Kop-
pelung von Geoinformationssystemen mit konstruktiven Bauwerksmodellen ein. So er-
fordert beispielsweise eine energetisch nachhaltige Stadt- und Raumentwicklung die Ver-
fügbarkeit geeigneter Datenbasen, welche gebäudescharfe Informationen auf den urbanen
Maßstab aggregieren (Brüggemann und von Both 2014, S. 41 ff.). Um die Interoperabili-
tät zwischen dem Geodaten- und BIM-Bereich zu optimieren, wird auch das CityGML-
Gebäudemodell sukzessive konkretisiert. Wegen der grundlegenden konzeptionellen Un-
192 T. Brüggemann und P. von Both
terschiede geht es dabei jedoch nicht um eine Ein-, sondern vielmehr um die Anbindung
von BIM. Insofern handelt es sich bei CityGML und IFC/BIM auch nicht um konkurrie-
rende, sondern sich ergänzende Konzepte.
Literatur
AdV (2008) Dokumentation zur Modellierung der Geoinformationen des amtlichen Vermessungs-
wesens (GeoInfoDok) Hauptdokument Version 6.0.1, Arbeitsgemeinschaft der Vermessungs-
verwaltungen der Länder der Bundesrepublik Deutschland
Altmaier A, Kolbe TH (2003) Applications and Solutions for Interoperable 3d Geo-Visualization.
In: Fritsch D (Hrsg) Photogrammetric Week. Wichmann, Heidelberg
Brüggemann T, von Both P (2014) Semantisches Informationsmodell als kollektive Datenbasis für
eine nachhaltige Stadt- und Energieleitplanung. Koch MK, McKenna R (Hrsg) Wettbewerb
Energieeffiziente Stadt (Bd 2) Methoden und Modelle. LIT Verlag, Berlin, S 41–50
EU (2007) Richtlinie 2007/2/EG des Europäischen Parlaments und des Rates vom 14. März 2007
zur Schaffung einer Geodateninfrastruktur in der Europäischen Gemeinschaft (INSPIRE). In:
Amtsblatt der Europäischen Union, L108/1, ISSN 1725-2539
Gröger G, Kolbe TH, Nagel C, Häfele KH (2012) OGC City Geography Markup Language
(CityGML) Encoding Standard, Version 2.0.0, OGC Doc. No. 12-0019, Open Geospatial Con-
sortium
ISO (2005) Geographic information – Spatial schema (EN ISO 19107:2003), International Organi-
zation for Standardization, European Committee for Standardization
ISO (2006) Geographic information – rules for application schema (EN ISO 19109:2005), Interna-
tional Organization for Standardization, European Committee for Standardization
ISO (2007) Geographic information – Spatial referencing by coordinates (EN ISO 19111:2007),
International Organization for Standardization, European Committee for Standardization
Kolbe TH, Kutzner T, Gröger G, Casper E (2014) CityGML – Der OGC-Standard CityGML geht
in die nächste Runde. gis@work 1/2014, AED Solution Group, S 41–42
de Laat R, van Berlo L (2010) Integration of BIM and GIS – The Development of the CityGML
GeoBIM Extension. In: Kolbe TH, König G, Nagel C (Hrsg) Advances in 3D Geo-Information
Sciences. Springer Verlag, Heidelberg
Ludewig J (2002) Modelle im Software Engineering – Einführung und Kritik. In: Glinz M, Müller-
Luschnat G (Hrsg) Modellierung in der Praxis – Modellierung für die Praxis. GI, Bonn, S 7–
22
Nagel C, Häfele KH (2007) Generierung von Stadtmodellen auf Basis des IFC-Gebäudemodells.
In: Clemen C (Hrsg) Entwicklerforum Geoinformationstechnik. Shaker, Aachen, S 151–165
OGC (2014) Land and Infrastructure Standard Working Group (LandInfraSWG). http://www.
opengeospatial.org/projects/groups/landinfraswg. Zugegriffen: 11. Dezember 2014
Stachowiak H (1973) Allgemeine Modelltheorie. Springer Verlag, Wien
Wilson T (2008) OGC® KML. Project document OGC 07-147-r2, version 2.2.0. Open Geospatial
Consortium
BIM-Programmierwerkzeuge
Julian Amann, Eike Tauscher und André Borrmann
11
Zusammenfassung
In diesem Kapitel wird auf die verschiedenen Möglichkeiten zur Programmierung
von BIM-Applikationen eingegangen. Ein besonderer Schwerpunkt liegt dabei auf
der Verarbeitung von Daten im herstellerneutralen Austauschformat Industry Foun-
dation Classes (IFC). In diesem Zusammenhang werden der Zugriff auf Daten im
Format STEP Clear Text Encoding erläutert und dabei die Unterschiede zwischen dem
Early-Binding- und dem Late-Binding-Ansatz diskutiert. Da für den Austausch von
IFC-Daten das Format ifcXML eine zunehmend wichtigere Rolle einnimmt, wird auch
auf den Einsatz der entsprechenden Zugriffsvarianten SAX (Simple API for XML)
und DOM (Document Object Model) eingegangen. Im Anschluss wird auf verschie-
dene Geometrierepräsentationen der IFC und deren Interpretation Bezug genommen.
Schließlich wird kurz die Addin-Entwicklung behandelt, die es erlaubt, existierende
Software an die eigenen nutzerspezifischen Bedürfnisse anzupassen.
11.1 Einleitung
Werkzeuge effizient in der Wertschöpfungskette eingesetzt werden können, ist ein Da-
tenaustausch auf hohem semantischem Niveau erforderlich. Dies wird zunehmend durch
offene Datenformate wie den Industry Foundation Classes (IFC) realisiert (siehe Kap. 6).
Um die in einer IFC-Instanzdatei enthaltenen Informationen nutzen zu können, ist ein
Zugriff auf die Daten von der jeweiligen Programmiersprache her erforderlich. Die unter-
schiedlichen Methoden und Verfahren sollen in diesem Kapitel behandelt werden.
Das gebräuchlichste Format zur Speicherung von IFC-Instanzdaten stellt das Format
STEP Clear Text Encoding (ISO 10303-21), auch bekannt als STEP P21, dar. Verfahren
zum Lesen und Schreiben von STEP-Dateien lassen sich in zwei Kategorien einordnen:
das Early-Binding-Verfahren (frühe Bindung) und das Late-Binding-Verfahren (späte
Bindung).
Beim Early Binding werden durch ein geeignetes Mapping-Verfahren die Entitäten des
zur STEP P21-Datei gehörenden EXPRESS-Schemas in der Zielprogrammiersprache
(Hostsprache) abgebildet. Darüber hinaus gibt es beim Early Binding die Möglichkeit,
eine STEP-Datei auf die Entitäten der Hostsprache abzubilden, also eine STEP-Datei
zu lesen und in umgekehrter Weise die Hostentitäten wieder in eine STEP-Datei zu
überführen, d. h. eine STEP-Datei zu schreiben. Eine händische (manuelle) Early-
Binding-Implementierung ist theoretisch möglich, empfiehlt sich aber im Falle des
IFC-Datenmodells nicht, da dieses mehrere hundert Entitäten umfasst und eine händi-
sche Umsetzung sehr anfällig für Programmierfehler ist.
Im Regelfall wird ein Codegenerator verwendet, der als Eingabe ein EXPRESS-
Schema erhält und als Ausgabe Klassen der Zielsprache erzeugt. Dieses Mapping bzw. die
damit verbundene Codegenerierung wird für ein gegebenes EXPRESS-Schema einmalig
durchgeführt. Ändert sich das EXPRESS-Schema, so muss auch dieser Mapping-Prozess
wiederholt werden. Im Falle der IFC sind Änderungen am EXPRESS-Schema jedoch
relativ selten. Werden Änderungen am IFC-Schema vorgenommen, wird im Rahmen der
IFC auch jedes Mal eine neue Versionsnummer für das entsprechende EXPRESS-Schema
vergeben (wie z. B. IFC4, IFC2 × 3 TC1, IFC2 × 3, IFC2 × 2, usw.).
Technisch gesehen muss man, wenn man mehrere verschiedene IFC-Versionen pa-
rallel unterstützen will, für jede dieser Versionen ein gesondertes Early Binding erzeu-
gen. Abbildung 11.1 zeigt den Early-Binding-Prozess in der Übersicht. Der Codegene-
rator erzeugt für jede Entität eine entsprechende Abbildung in der Zielprogrammierspra-
che. Für die Programmiersprache C++ würde beispielsweise für die EXPRESS-Entität
IfcAddress die C++ Klasse IfcAddress erzeugt werden. Die genaue Abbildungs-
11 BIM-Programmierwerkzeuge 195
STEP/ISO 10303-21
Input
IfcAddress.cpp/h
ENTITY IfcAddress Code Generator IfcAddress.cs
IfcAddress.java
Output
STEP/ISO 10303-21
Abb. 11.1 Darstellung von Early Binding. Für jede Entität wird eine korrespondierende Klasse für
die Zielprogrammierspache erzeugt
vorschrift von EXPRESS-Entitäten auf eine Programmiersprache ist dabei nicht stan-
dardisiert. Hier hat der Entwickler des Codegenerators freie Hand. Im Regelfall werden
in objektorientierten Programmiersprachen EXPRESS-Entitäten auf Klassen abgebildet,
Vererbung wird mit der Vererbungssyntax realisiert und die Referenzen werden mit Zei-
gern, Smart Pointern (Zeiger, die sich um das Memory Management kümmern) oder
Referenzen der Zielsprache realisiert.
Ein Codegenerator sollte die EXPRESS-Grammatik parsen können. Das heißt, er soll-
te einen Lexer besitzen, der aus den Eingabesymbolen der STEP-Datei Token erzeugt
und anschließend mittels eines Parsers einen Syntaxbaum erstellt und die Syntax des
EXPRESS-Schemas auf Korrektheit validiert. Außerdem sollte es mit einem Codegene-
rator möglich sein, in einem Schritt aus dem EXPRESS-Schema ein valides Mapping
zu erzeugen, das ohne manuelle Eingriffe in der Zielsprache direkt verwendet werden
kann. In der Praxis findet man jedoch Codegeneratoren, die beispielsweise nicht jedes va-
lide EXPRESS-Schema umwandeln können und erst einen Vorverarbeitungsschritt oder
einen zusätzlichen manuellen Aufwand benötigen. Als Beispiel für Codegeneratoren kann
etwa das Programm IfcPlusPlusExtender (http://www.ifcplusplus.com/extender.php) für
die Programmiersprache C++ oder die Bibliothek JSDAI (http://www.jsdai.net) angeführt
werden.
Das folgende Listing zeigt die Verwendung von IfcPlusPlus mit dem IFC4-Schema:
std::ofstream textdatei("MeineDatei.ifc");
textdatei << stream.str().c_str();
Das Programm erzeugt eine Instanz der Entität IfcCartesianPoint mit den Koor-
dinaten (9.0, 10.0). Anschließend wird ein IfcStepWriter-Objekt erzeugt, das genutzt
wird, um das erzeugte Modell (ifc_model) in eine STEP P21-Datei umzuwandeln.
Im Unterschied zum Early Binding wird beim Late Binding eine fest definierte Schnittstel-
le, das Standard Data Access Interface (SDAI), verwendet. Das SDAI ist eine Program-
mierschnittstelle (API), die definierte Funktionen bzw. Methoden bereitstellt, um STEP-
Dateien zu lesen bzw. diese zu schreiben. Das SDAI ist in abstrakter Form in der Norm
ISO 10303-22 standardisiert. Darüber hinaus werden im Rahmen des STEP-Standards drei
verschiedene Bindings für drei unterschiedliche Programmiersprachen festgelegt: Part 23
(ISO 10303-23) definiert ein C++-Binding, Part 24 ein C-Binding und Part 27 ein Java-
Binding. Neben diesen Varianten wurden auch für andere Programmiersprachen wie bei-
spielsweise C# ähnliche Bindings von verschiedenen Softwareanbietern umgesetzt, die
zwar nicht standardisiert, aber den standardisierten Bindings nachempfunden sind.
Im Folgenden soll das C-Binding der SDAI näher betrachtet werden. Die grundlegen-
de Idee lässt sich einfach auch auf andere Bindings übertragen. Im C-Binding starten alle
Variablenbezeichner, Konstanten, Aliastypen (typdef) und Funktionsnamen mit dem
Prefix sdai. SDAI-Operationen werden immer im Rahmen einer SDAI-Session ausge-
führt. Die Daten der STEP-Datei werden dabei in SDAI-Modellen abgelegt, die selbst
wiederum Teil eines SDAI-Repositories sind.
Folgendes Listing veranschaulicht die Verwendung der C-SDAI-API:
Das oben stehende Programm erzeugt, ähnlich dem vorher gezeigten Programm, eine
IfcCartesianPoint-Entität, die in einer STEP-Datei gespeichert wird.
Beim Early-Binding wird für jede Entität des EXPRESS-Schemas ein entsprechendes
Äquivalent in der Host-Programmiersprache geschaffen. Bei Verwendung des Late Bin-
dings fällt dieser Zwischenschritt der Codegenerierung weg. Dadurch ist das Late Binding
flexibler gegenüber Änderungen des EXPRESS-Schemas. Diese Flexibilität wird durch
einen generischen Ansatz erreicht, der sowohl die Instanziierung als auch den Zugriff auf
Entitäten anhand des zugrunde liegenden EXPRESS-Schemas während der Laufzeit des
Programms ermöglicht.
Um dies zu bewirken, muss die Schnittstelle jedoch häufig unter Verwendung von
Strings angesprochen werden, die beispielsweise anzeigen, welche Entität erzeugt, wel-
ches Attribut gelesen oder welche Funktion angesprochen werden soll. Dies setzt ein
tiefes Verständnis des zugrundeliegenden EXPRESS-Schemas voraus, da beispielsweise
Auto-Codevervollständigungsfunktionalitäten moderner Entwicklungsumgebungen nicht
funktionieren. Weiterhin ist dieser Umstand aus Sicht des Programmierers sehr problema-
tisch, da beispielsweise Schreibfehler innerhalb eines solchen Strings nicht vom Compiler
erkannt werden und sich entsprechend erst zur Laufzeit des Programms auswirken.
Infolgedessen ist die Handhabung von IFC-Dateien mittels SDAI deutlich schwerer, da
man nicht wie bei einem Early Binding die gleichen Entitäten mit den gleichen Attributen,
Vererbungshierarchien und Relationen in der Hostsprache zur Verfügung hat und somit be-
reits während des Kompilierens derartige Fehler komplett ausschließen kann. Theoretisch
bietet SDAI den Vorteil, dass aufgrund der Standardisierung die SDAI-Implementierung
eines Herstellers durch die eines anderen ausgetauscht werden kann. In der Praxis gestal-
tet sich dies jedoch schwierig, da manche Hersteller weitergehende SDAI-Funktionen in
ihre APIs integrieren, die nicht Teil des Standards sind.
Tabelle 11.1 zeigt eine (nicht vollständige) Übersicht verschiedener Bibliotheken, die
es ermöglichen, STEP bzw. IFC-Dateien zu lesen bzw. zu schreiben.
198 J. Amann et al.
In den letzten Jahren hat sich die Extensible Markup Language (XML) als industrieüber-
greifender Standardansatz zur Beschreibung von Schemata und Instanzdaten etabliert.
Sowohl das .NET-Framework von Microsoft als auch die Java Standard Edition beinhal-
ten standardmäßig einen XML-Parser für die Handhabung von XML-Dateien. Auch für
C++ existieren zahlreiche Bibliotheken, die XML lesen und schreiben können. Beispiele
hierfür sind die Qt-Bibliotheken oder der Xerces-C++ XML Parser, welcher besonders für
sehr große XML-Dateien geeignet ist. Zusammenfassend ist die Unterstützung für das Le-
sen und Erzeugen von XML-Dokumenten bzw. das Angebot von Middleware wesentlich
umfangreicher für XML als für STEP.
Beginnend mit der Version 4 des IFC-Standards wird als Äquivalent zum EXPRESS-
Schema ein XML-Schema definiert. Als Beschreibungssprache kommt dabei XML Sche-
ma Definition (XSD) zum Einsatz. Dieses definiert die Struktur von XML-Instanzdateien
und erlaubt es, diese gegen das Schema zu validieren. Hierfür findet man in den gängigen
Frameworks sogenannte XSD-Validatoren.
Obwohl aus oben genannten Gründen der Datenzugriff mittels XML programmier-
technisch leicht zu realisieren ist, findet diese Variante jedoch bislang eine weniger weite
11 BIM-Programmierwerkzeuge 199
QXmlDefaultHandler
+startDocument()
+endDocument()
+startElement(namespaceURI : String, localName : String, qName : String, atts : QXmlAttributes)
+endElement(namespaceURI : String, localName : String, qName : String)
+characters(ch : String)
Abb. 11.2 Klassendiagramm, das einen Ausschnitt des Qt-SAX-Frameworks zeigt. Die Methoden
der Klasse QtXmlDefaultHandler sind nicht vollständig
Verbreitung als das STEP-Pendant. Dies ist zum einen der historischen Entwicklung der
IFC geschuldet, die auf STEP und der Datenmodellierungssprache EXPRESS aufbaut.
Eine wichtige Rolle spielt aber auch die Größe von ifcXML-Dateien, die aufgrund der
XML-Syntax (Tags) häufig ein Vielfaches des STEP-Pendants beträgt (vgl. Kap. 6). Bei
der Entwicklung von ifcXML4 wurde diesem Umstand Rechnung getragen und eine deut-
lich kompaktere Darstellungsweise realisiert. Dies lässt erwarten, dass das XML-Mapping
der IFC zukünftig deutlich an Bedeutung gewinnt. Einschränkend ist allerdings festzuhal-
ten, dass das XML-Schema der IFC weder inverse Attribute noch Regeln und Funktionen
abbildet, die im originären IFC-EXPRESS beinhaltet sind.
Für das Lesen und Schreiben von XML-Dateien gibt es im Wesentlichen drei gebräuch-
liche Varianten: SAX, DOM und Klassengeneratoren. SAX ist die Abkürzung für Simple
API for XML und war ursprünglich eine Java-Bibliothek für das sequenzielle Lesen von
XML-Daten. Die Softwarearchitektur der ursprünglichen SAX-Implementierung hat sich
zum De-facto-Standard entwickelt und Einzug in zahlreiche andere Frameworks gefun-
den. Abbildung 11.2 zeigt einen kleinen Ausschnitt der Klasse QtXmlDefaultHandler
aus dem Qt-SAX-Framework. Im Regelfall wird bei einer objektorientierten Program-
miersprache eine Basisklasse bzw. ein Interface (vgl. QtXmlDefaultHandler)
angeboten, das der Entwickler durch Vererbung seinen eigenen Bedürfnissen anpas-
sen kann. Der SAX-Parser liest das XML-Dokument und ruft bei jedem Auftreten eines
XML-Elements die entsprechende Methode auf. Beispielsweise wird beim Lesen des
Root-Tags als erstes die Methode startDocument aufgerufen. Entsprechend wird am
Ende die Methode endDocument aufgerufen. Ähnlich verhält es sich bei einem XML-
Element. Hierbei wird startElement bzw. am Ende endElemenet aufgerufen. Der
SAX-Parser kann jedoch erst während des Lesens eines XML-Dokuments feststellen, ob
es sich um ein valides XML-File handelt oder nicht.
Neben SAX gibt es noch die weit verbreitete Zugriffsart via DOM (Document Object
Model). DOM ist ähnlich wie SAX in vielen Frameworks enthalten. Das folgende Listing
zeigt die Verwendung von DOM in Qt:
//speichere Entität
QDomElement xmlAlignments = doc.createElement("Alignments");
root.appendChild(xmlAlignments);
Als letzte Variante ist auch eine Early Binding für XML denkbar. Hier gibt es eben-
falls einige Tools, die aus einem XML-Schema eine Klassenhierarchie generieren können
und Methoden zum Lesen und Schreiben einer entsprechenden XML-Datei zur Verfügung
stellen. Dabei hat man die gleichen Vor- bzw. Nachteile wie bei einem STEP-basierten
Early Binding.
Constructive Solid Geometry (CSG): Festkörper, die das Resultat boolescher Operatio-
nen bilden, die also durch Vereinigung, Differenz oder Schnitt von zwei oder mehreren
Festkörpern entstanden sind,
Halbraumfestkörper: Festkörper, die durch eine Fläche einseitig begrenzt werden,
Extrusionskörper: Festkörper, die durch Extrusion einer Fläche entlang eines Vektors,
einer oder mehrerer Polylinien, Kurven, Splines oder anderer mathematisch beschreib-
barer Funktionen entstehen,
11 BIM-Programmierwerkzeuge 201
Nachfolgend sollen zwei der genannten Modelle näher dargestellt werden, um die an-
gesprochene Komplexität der Geometrieinterpretation zu verdeutlichen.
Prinzipiell werden Geometriemodelle in zwei Kategorien unterteilt. Man spricht hier-
bei von ausgewerteten (expliziten) und nichtausgewerteten (impliziten) Modellen. Aus-
gewertete Modelle sind relativ einfach zu interpretieren, da alle für die Darstellung oder
auch Weiterverarbeitung relevanten geometrischen Informationen explizit innerhalb des
IFC-Datenmodells vorliegen. Als Beispiel hierfür kann das in den IFC verwendete BRep-
Modell herangezogen werden. Alle Eckpunkte (Vertices) eines Körpers liegen bereits mit
den richtigen Koordinaten vor und bedürfen keiner weiteren Berechnung. Die begrenzen-
den Flächen (Faces) ergeben sich hierbei aus der topologischen Beziehung zwischen den
Vertices und Kanten (Edges).
Nichtausgewertete Geometriemodelle erfordern zum Teil aufwendige geometrische
Operationen, da alle für die Darstellung notwendigen geometrischen Informationen nur
implizit vorliegen und zunächst berechnet werden müssen. Ein Beispiel hierfür ist Mo-
dellierung auf Basis des CSG-Ansatzes.
Wie in Kap. 2 ausführlich dargestellt, bildet die Grundlage des CSG-Modells der so-
genannte Konstruktionsbaum. Dieser bildet die Konstruktionshistorie des entstehenden
Objekts ab, wobei das Resultat aller booleschen Operationen an der Wurzel des Baumes
entsteht. An den Blättern des Baumes befinden sich in der Regel primitive Körper, die
durch die in den Knoten des Baumes befindlichen regularisierten booleschen Mengenope-
rationen miteinander kombiniert werden.
Für die Bildung der geometrischen Resultate sind sehr komplexe Berechnungen not-
wendig. Hierfür existieren wiederum verschiedene Berechnungsmodelle. Liegen die Ope-
randen beispielsweise als triangulierte Oberflächenkörper vor, kann die Berechnung nach
(Laidlaw et al. 1986) bzw. (Hubbard et al. 1990) erfolgen. Stark vereinfacht ausgedrückt
werden bei diesem Verfahren alle Dreiecke eines jeden Operanden gegeneinander auf
Schnitt geprüft. Sollten sich zwei Dreiecke schneiden, so entstehen neue Dreiecke, wel-
che anhand der Schnittkante gebildet werden. Anschließend werden die Dreiecke beider
Operanden gegeneinander dahingehend klassifiziert, ob sie sich innerhalb des anderen
Körpers, außerhalb des anderen Körpers, auf der Oberfläche des anderen Körpers mit
gleicher Oberflächennormale oder auf der Oberfläche des anderen Körpers mit entge-
gengesetzter Oberflächennormale befinden. Nach dieser Klassifizierung werden die Drei-
ecke entsprechend des angewendeten booleschen Operators nach Tab. 11.2 zusammen-
geführt.
202 J. Amann et al.
Tab. 11.2 Klassifikation von Dreiecken zur Flächenauswahl für den Ergebniskörper in Abhängig-
keit der booleschen Operation
Dreiecke von A Dreiecke von B
Operation Inner- Außer- Gleiche Entgegen- Inner- Außer- Gleiche Entgegen-
halb halb Nor- gesetze halb halb Nor- gesetzte
von B von B male Normale von A von B male Normale
A[B Nein Ja Ja Nein Nein Ja Nein Nein
T
A B Ja Nein Ja Nein Ja Nein Nein Nein
AnB Nein Ja Nein Ja Ja1 Nein Nein Nein
1
Dreiecke mit umgekehrter Orientierung
Hierbei können sich an den Blättern nicht nur geometrische Primitive (Kugel, Kegel,
Zylinder, usw.) befinden, sondern auch beliebig komplexe Festkörper. Voraussetzung ist,
dass ein gültiger Körper beschrieben wird, was gegeben ist, wenn an jede Körperkante
zwei Flächen angrenzen. In IFC-Modellen findet dieses Vorgehen sehr häufig Anwendung.
Ein typisches Beispiel hierfür ist das „Herausschneiden“ von Durchbrüchen aus Wänden
oder Decken.
Tabelle 11.3 zeigt eine kleine Auswahl verschiedener Bibliotheken, die verschiedene
Geometrierepräsentationen in eine Dreiecksdarstellung umwandeln können. Häufig sind
die Bibliotheken jedoch nicht auf eine Programmiersprache limitiert, da es viele Wrap-
per/Bindings gibt, die die Benutzung von einer anderen Programmiersprache wie z. B.
Java oder C# erlauben.
11.5 Addin-Entwicklung
Zahlreiche, für das Building Information Modeling relevante Programme erlauben die Im-
plementierung von Addins bzw. Plug-ins, die es ermöglichen, die vorhandene Funktiona-
lität dieser Programme zu erweitern. In der Regel werden dabei die Programmiersprachen
C++ sowie die verschiedenen Sprachen der Microsoft .NET-Plattform (C#, VisualBa-
sic.NET, J# etc.) zur Programmierung von Erweiterungen unterstützt.
In diesem Abschnitt soll kurz die Entwicklung eines einfachen C#-Add-ins für Auto-
desk Revit skizziert werden. Für eine vollständige Dokumentation und für Entwicklungs-
11 BIM-Programmierwerkzeuge 203
hilfen wird jedoch direkt auf die Autodesk-Webseite verwiesen, die verschiedene Formen
der Unterstützung für Programmierer anbieten.
Um eine C# basierte Revit-Erweiterung zu programmieren, bietet sich die Verwendung
von Microsoft Visual Studio an. Dort erstellt man eine Klassenbibliothek (Class Libra-
ry) als neues Projekt. Da dieses Add-in Zugriff auf die Revit-API benötigt, muss dieses
Projekt die entsprechenden Revit-Bibliotheken referenzieren (RevitAPI.dll und RevitA-
PIUI.dll). Wichtig ist auch, dass die richtige Zielplattform (Target framework) verwendet
wird. Visual Studio bietet hier im Regelfall unterschiedliche .NET-Versionen an, z. B.
.NET-Framework in der Version 2.0/3.0/3.5/3.5 Client Profile oder 4. Die von Revit ver-
wendete Zielplattform muss mit der von Visual Studio verwendeten übereinstimmen. Dies
ist ein typischer Fallstrick, den man vermeiden sollte. Ein minimales Add-in für Revit ist
im folgenden Listing dargestellt:
using System;
using System.Collections.Generic;
using System.Linq;
using Autodesk.Revit.DB;
using Autodesk.Revit.DB.Architecture;
using Autodesk.Revit.UI;
using Autodesk.Revit.UI.Selection;
using Autodesk.Revit.ApplicationServices;
using Autodesk.Revit.Attributes;
[TransactionAttribute(TransactionMode.Manual)]
[RegenerationAttribute(RegenerationOption.Manual)]
public class Lab1PlaceGroup : IExternalCommand
f
public Result Execute(
ExternalCommandData commandData,
ref string message,
ElementSet elements)
f
UIApplication uiApp = commandData.Application;
Document doc = uiApp.ActiveUIDocument.Document;
//Hier kann dann die Revit API verwendet werden
return Result.Succeeded;
g
g
Zusätzlich zu dieser Bibliothek muss noch ein Add-in-Manifest erstellt werden. Dabei
handelt es sich um eine XML-Datei, die globale Einstellungen des Add-ins speichert.
Diese Manifestdatei wird im Ordner Autodesk\Revit\Addins\2014\ abgelegt.
204 J. Amann et al.
Beim Start von Revit wird dann automatisch das Add-in geladen, das über die Toolbar
genutzt werden kann. Nähere Informationen dazu findet man in der Dokumentation.
11.6 Zusammenfassung
In diesem Kapitel wurde ein kurzer Überblick über Möglichkeiten zum Lesen und Schrei-
ben von IFC-Dateien gegeben. Die heute primär eingesetzte Variante zum Austausch von
IFC-Daten basiert auf der Nutzung des Formats STEP Clear Text Encoding, das in Teil 21
des STEP-Standards normiert ist. Grundsätzlich ist dabei zwischen dem Early-Binding-
Ansatz, bei dem die Entitäten des EXPRESS-Schemas auf Entitäten einer Hochsprache
abgebildet werden, und dem Late-Binding-Ansatz, bei dem ein generisches, datenmodell-
unabhängiges Interface zum Zugriff auf Instanzdaten verwendet wird, zu unterscheiden.
Der entscheidende Vorteil des Early-Binding-Ansatzes liegt darin, dass ein größerer Teil
von Programmierfehlern bereits zur Kompilierzeit erkannt wird. Nachteilig ist, dass mit-
hilfe entsprechender Codegeneratoren die Klassenstruktur in der Hostsprache erzeugt wer-
den muss und dieser Vorgang jedes Mal wiederholt werden muss, wenn eine Veränderung
des Schemas stattfindet.
Eine Alternative zur Verwendung von STEP-Part 21 zur Kommunikation von IFC-
Daten liegt in der Nutzung des XML-basierten Formats ifcXML. Für die programmier-
technische Umsetzung des Zugriffs stehen die Verfahren SAX und DOM zur Verfügung.
Die weite Verbreitung des XML-Formats und die gute Unterstützung durch Programmier-
werkzeuge lässt erwarten, dass ifcXML in Zukunft deutlich an Bedeutung gewinnen wird.
Ein wichtiger Aspekt der Verarbeitung von IFC-Daten liegt in der Interpretation von
Geometrieinformationen. Eine besondere Herausforderung liegt darin, dass sehr unter-
schiedliche Geometrierepräsentationen vom IFC-Datenmodell unterstützt werden, darun-
ter insbesondere eine Reihe von impliziten Repräsentationen. Diese müssen im Regelfall
in ein Dreiecksnetz überführt werden, um die Geometrie anzeigen und weiterverarbeiten
zu können.
Neben der Nutzung des neutralen Austauschformats IFC gibt es die Möglichkeit,
Add-ins für kommerziell verfügbare Softwareprodukte zu entwickeln, um auf BIM-
Informationen zugreifen zu können.
Literatur
Hubbard M, (1990) Constructive Solid Geometry for Triangulated Polyhedra. Department of Com-
puter Science, Brown University, Providence, Rhode Island 02912, CS-90-07.
Laidlaw D, Trumbore B & Hughes J (1986) Constructive Solid Geometry for Polyhedral Objects.
Proceedings of SIGGRAPH ’86, Computer Graphics, Vol. 2, ACM, New York, USA.
Teil III
BIM-gestützte Zusammenarbeit
Kooperative Datenverwaltung
Sven-Eric Schapke, Jakob Beetz, Markus König, Christian Koch und
12
André Borrmann
Zusammenfassung
Die Planung, Erstellung und auch der Betrieb von Bauwerken erfordern die Zusam-
menarbeit einer Vielzahl von Beteiligten, die untereinander im ständigen Informati-
onsaustausch stehen. Viele ihrer Arbeits- und Kommunikationsprozesse können durch
die einheitlich strukturierten Bauwerksinformationsmodelle direkt verbessert werden.
Darüber hinaus gilt es einen gemeinsamen Datenraum zu etablieren, in dem die Infor-
mationen aller Projektbeteiligten zusammengeführt werden. Die zentrale Verwaltung
der Modellinformationen bietet weitere Möglichkeiten, die Kommunikation und Koor-
Sven-Eric Schapke
think project! GmbH, Zamdorfer Straße 100, 81677 München, Deutschland
e-mail: sven-eric.schapke@thinkproject.com
Jakob Beetz
Technische Universiteit Eindhoven, Department of the Built Environment, Urban Science and
Systems, Den Dolech 2, 5612 Eindhoven, Niederlande
e-mail: J.Beetz@bwk.tue.nl
Markus König
Ruhr-Universität Bochum, Lehrstuhl für Informatik im Bauwesen, Universitätsstraße 150,
44780 Bochum, Deutschland
e-mail: koenig@inf.bi.rub.de
Christian Koch
The University of Nottingham, Department of Civil Engineering, University Park, NG7
2RD Nottingham, Großbritannien
e-mail: christian.koch@nottingham.ac.uk
André Borrmann
Technische Universität München, Lehrstuhl für Computergestützte Modellierung und Simulation,
Arcisstr. 21, 80333 München, Deutschland
e-mail: andre.borrmann@tum.de
dination zu vereinfachen, die Integrität der Informationen zu prüfen und einen Über-
blick über den aktuellen Projektstand zu erhalten.
Im Vergleich zu den Softwarewerkzeugen für die Modellierung und Prüfung von
Bauwerksinformationsmodellen gibt es jedoch heute keine etablierten Systeme für die-
se kooperative Datenverwaltung. Je nachdem welche Modell- und Dokumentinfor-
mationen, aus welchen Projektphasen und -bereichen, von welchen Projektbeteiligten
bearbeitet werden sollen, können unterschiedliche Kooperationsformen und -techniken
eigesetzt werden. Das vorliegende Kapitel stellt deshalb unterschiedliche methodische
Ansätze, praktische Verfahren und bestehende Softwaresysteme für die kooperative
Datenverwaltung vor. Als Diskussionsgrundlage werden die unterschiedlichen Infor-
mationsressourcen und möglichen Kooperationsformen der modellbasierten Zusam-
menarbeit beschrieben.
Aus technischer Sicht werden insbesondere die Methoden der Nebenläufigkeits-
kontrolle und Versionierung sowie der Rechte- und Freigabeverwaltung erläutert. An-
schließend werden unterschiedliche Softwaresysteme zur kooperativen Datenverwal-
tung, wie z. B. Produktmodellserver, vorgestellt und diskutiert, inwieweit diese die
vorgestellten Methoden einsetzen und die unterschiedlichen Kooperationsformen un-
terstützen. Das Kapitel schließt mit einem kurzen Ausblick auf zukünftige Herausfor-
derungen und Entwicklungen.
12.1 Einleitung
Die Bauplanung und -ausführung ist ein hochgradig arbeitsteiliger Prozess mit einer Viel-
zahl von Beteiligten. Die Abstimmung untereinander, die für das Gelingen eines Bau-
vorhabens essenziell ist, geschieht noch heute vorwiegend durch den Austausch von 2D-
Plänen. Gerade bei komplexen Bauvorhaben ist diese Form des Informationsaustausches
jedoch fehleranfällig und zeitaufwendig, da die jeweilig Kontrolle, Koordination und Ab-
stimmung nicht automatisierbar unterstützt werden kann. Durch den Gebrauch digitaler
Bauwerksinformationsmodelle und die Modellierung von abgestimmten Arbeitsabläufen
können verschiedene Formen der Zusammenarbeit in vielen Aspekten effektiv unterstützt
und verbessert werden. Von verschiedenen Planungsbeteiligten benötigte Informationen
können dadurch auf dem aktuellen Stand gehalten und angeboten werden, wobei der ge-
meinsame Datenraum aller Planungsbeteiligten teilautomatisiert überprüft und konsistent
gehalten werden kann. Dies erlaubt schnellere iterative Planungszyklen, eine verbesser-
te Kontrolle und Übersicht des Projektfortgangs und erleichtert die Kommunikation aller
Beteiligten durch gemeinsame verwendete Informationsressourcen. Um diese Vorteile di-
gital unterstützter Zusammenarbeit effektiv und effizient einzusetzen, sind jedoch einige
grundlegende Veränderungen gegenüber papierbasierten Arbeitsabläufen nötig.
In diesem Kapitel wird dargestellt, wie sowohl die Zusammenarbeit als auch die Ko-
ordination der Planung durch eine kooperative Datenhaltung erheblich verbessert werden
können. Dabei wird zunächst auf grundlegende Konzepte des gemeinsamen Datenraumes
12 Kooperative Datenverwaltung 209
12.2 BIM-Informationsressourcen
12.2.1 Metadaten
Die Grundlage für die einheitliche Organisation der Informationsressourcen bieten Meta-
datenschemas. Traditionell definieren diese eine Reihe einfacher Metadatenattribute, die
unterschiedliche Aspekte einer Ressource repräsentieren, um diese:
Für eine sehr viel detailliertere Beschreibung einzelner Datenobjekte und ihrer Be-
ziehungen innerhalb eines Modells werden darüber hinaus heute auch objektorientierte
Meta-Modelle erstellt und für die automatische Generierung von Softwarekomponenten
verwendet (vgl. Hambuch 2008).
Das wichtigste Metadatenattribut einer Informationsressource ist der Identifikator. Die-
ser bezeichnet eine eindeutige Kennung zur Identifikation einer Ressource, die durch die
Ressource selber oder das Verwaltungssystem definiert wird. In digitalen Bauwerksmo-
dellen haben in der Regel alle wichtigen Elemente einen global eindeutigen Identifikator
(Globally Unique Identifier, GUID oder Universally Unique Identifier UUID). Dieser er-
möglicht es, die Elemente einzeln zu verwalten und gleiche Elemente in unterschiedlichen
Modellversionen zu vergleichen sowie Elemente in externen Softwaresystemen zu refe-
renzieren. Voraussetzung ist jedoch, dass alle in der Zusammenarbeit genutzten Systeme
die GUIDs der Modelle erhalten, statt diese etwa bei jedem Export in ein neutrales Format
neu zu generieren. Die weitere Vereinheitlichung der Attribute wird durch Metadatenvoka-
bulare erreicht. Diese definieren eine Auswahl möglicher Attributwerte z. B. durch Listen,
Klassifikationen, Partonomien oder anderen Kennzeichnungssystemen.
In der Baupraxis werden Metadaten heute zuerst im Planmanagement genutzt. Im
Projekt wird hierfür ein Kennzeichnungsschlüssel, die Plancodierung, festgelegt, nach
der jeder Plan eindeutig gekennzeichnet wird. Die Plancodierung setzt sich aus mehre-
ren Klassifikationsfacetten mit vordefinierten Vokabularen z. B. für einzelne Teilprojekte
(Bauteil 1 . . . n, Los 1 . . . n, etc.), Gewerke (Architektur, Tragwerk, etc.), Darstellungs-
arten (Grundriss, Schnitt, etc.) und Projektphasen (Entwurfs-, Ausführungsplanung, etc.)
sowie laufenden Nummern z. B. für Versionen und Revisionen zusammen. Wie in Ab-
schn. 12.2.3 gezeigt, können weite Teile dieses Kennzeichnungsschlüssels auch für die
Verwaltung digitaler Bauwerksmodelle genutzt werden. Darüber hinaus können Kenn-
zeichnungsschlüssel aber auch für die Klassifikation einzelner Bauwerkselemente genutzt
werden. Hierfür können Metadatenvokabulare auf der Grundlage etalierter Baunormen,
wie z. B. der DIN 276 (2008), allgemeiner Bauklassifikationen und Objektkataloge, wie
z. B. OmniClass (2006), Uniclass2 (2013) oder auch KKS (2010) entwickelt werden. Wei-
tere Ausführungen dazu finden sich in Kap. 6.
12.2.2 Aggregationsgrad
Modells sind diese Datensätze untereinander abhängig und müssen entsprechend in einem
gemeinsamen System verwaltet werden.
Gesamtmodell Architektur
TGA
Struktur Teilmodelle Gliederungselemente
elements, wie z. B. die Zarge, das Blatt oder die Klinke einer Tür, dargestellt werden.
Gleichzeitig kann aber auch ein einfaches Geometrieobjekt eine detaillierte Elementbe-
schreibung beinhalten. Je nach Schwerpunkt der Klassifikationen wird die Detaillierung
deshalb auch als Level of Detail (BS PAS 1192-2:2013) oder Level of Development (AIA
Dokument E202) bezeichnet (vgl. Kap. 7).
Die Phase zeigt an, zu welchem Zeitpunkt und Zweck ein Modell erstellt wurde oder
welchen Status es aktuell hat. Phasenklassifikationen können auf der Grundlage ganz
unterschiedlicher Prozessgliederungen aufgebaut werden, in denen übergeordnete Pro-
jektphasen und Wertschöpfungsprozesse oder auch einzelne Bearbeitungsschritte und
dementsprechend der Bearbeitungsstatus festgelegt werden.
In der Modellverwaltung bewirken Phasenwechsel häufig Statusänderungen bei den
genutzten Informationsressourcen. Entsprechend sollten zuerst Zustände definiert wer-
den, welche durch Revision sowie durch die Anforderung, Prüfung, Filterung, Konver-
tierung, Verlinkung und Auswertung der Modelle entstehen. Zum anderen gilt es, Me-
chanismen für das Propagieren von Zustandsänderungen zu etablieren, von einzelnen
Informationsressourcen auf verlinkte, über- und untergeordnete Ressourcen sowie auf
Ressourcen, die benachbarte Zonen und Domänen abbilden.
3D Marker Teilmodell
Koordinations-
modell
Teilmodell
Teilmodell
Grundlegende Funktion einer Datenverwaltung ist die effiziente Bereitstellung aller In-
formationen, die von den Projektteilnehmern benötigt werden. In der kooperativen und
kollaborativen Zusammenarbeit sollen die Teilnehmer darüber hinaus umfassend infor-
miert werden, um ihre Abstimmung und die Ausrichtung ihrer Arbeiten auf gemeinsame
Ziele zu fördern. Gleichzeitig muss die Informationsmenge überschaubar bleiben und
die Kollaborationsprozesse koordiniert und kontrolliert werden können. Auftraggeber von
Planungs- und Ausführungsleistungen müssen sicherstellen können, dass wichtige Infor-
mationen von den zuständigen Projektteilnehmern in der erforderlichen Qualität erstellt,
sicher gespeichert, überprüfbar dokumentiert und zielgerichtet verteilt und ausgewertet
werden.
Die Anforderungen an die Verwaltung der modellbasierten Projektinformationen hän-
gen stark von der Projektorganisation, der Komplexität des Bauwerkes und der einge-
setzten Softwaresysteme ab. Zusätzlich zur Definition passender Ablagestrukturen und
Kennzeichnungsschlüssel für die unterschiedlichen Projektinformationen müssen auch
Regelungen für den Zugriff, die Bearbeitung und die Speicherung der Informationen
getroffen werden. Die folgenden fünf Abschnitte bieten einen Überblick über unterschied-
liche Formen der kooperativen Datennutzung und technische Verfahren, diese zu unter-
stützen. Die anwendbaren Verfahren und daraus resultierenden Anforderungen an die
Datenverwaltung hängen insbesondere von folgenden Aspekten ab:
Nebenläufigkeit: wann und in welchem Umfang die Integrität von parallel bearbeiteten
Informationen gewährleistet werden soll,
Rollen und Rechte: inwieweit Projektinformationen vertraulich und nur für bestimmte
Empfängerkreise bestimmt sind und inwieweit die Teilnehmer unterschiedliche Bear-
beitungsrechte und Koordinationsaufgaben haben und welche Urheber, Verfügungs-
und Verwertungsrechte dabei beachtet werden müssen,
Versionierung: wie detailliert die einzelnen Schritte zur Bearbeitung der Projektinfor-
mationen und die daraus resultierenden Änderungen und Varianten erfasst und verbind-
lich dokumentiert werden sollen,
Freigabe und Archivierung: wie bestimmte Planungsstände geschützt, verbindlich ab-
gelegt und veröffentlicht werden sollen.
gleichzeitig ungleichzeitig
synchron asynchron
Lösung und einer Datenverwaltung, welche jederzeit die Integrität, Vertraulichkeit und
Authentizität aller Projektdaten sicherstellt.
Voraussetzung für die Zusammenarbeit ist die Kommunikation zwischen den kooperie-
renden Partnern. Die Wahl des Kommunikationsmediums und der Kommunikationsart
beeinflussen dabei auch Form und Qualität der Zusammenarbeit. In Abhängigkeit von der
räumlichen und zeitlichen Verteilung der Akteure wird allgemein zwischen der zeitlich
synchronen und der zeitlich asynchronen Kommunikation sowie der örtlich lokalen und
der örtlich verteilten Kommunikation unterschieden. Durch die Kombination dieser Klas-
sifikationen ergeben sich vier Kommunikationsformen, die zumeist in einer Raum-Zeit-
Matrix wie in Abb. 12.3 dargestellt werden (Teufel et al. 1995).
Gleichzeitig können Informationen durch direkte und indirekte Kommunikation ausge-
tauscht werden (s. Abb. 12.4). Bei der direkten Kommunikation versenden die Kommuni-
kanten Informationen unmittelbar durch Nachrichten. Bei der indirekten Kommunikation
erfolgt der Informationsaustausch mittelbar durch die Bearbeitung gemeinsamer Informa-
tionsressourcen. Gemeinsame Informationsressourcen ermöglichen es, Kommunikations-
beiträge zusammenzuführen und bieten einen zentralen Bezugspunkt, um Lösungen und
Entscheidungen nachzuvollziehen.
Bei der Gestaltung der modellbasierten Zusammenarbeit sind zuerst die informati-
onstechnischen Lieferprozesse zu betrachten und zu bestimmen, welche Akteure, wann,
welche Informationen, von wem benötigen, erstellen und an wen weiterleiten müssen. Ziel
ist es, die Arbeitsprozesse und technischen Schnittstellen der Projektteilnehmer möglichst
optimal aufeinander abzustimmen und eine durchgängig effiziente Informationsverwen-
dung zu sichern (vgl. dazu auch Kap. 4 und 7).
218 S.-E. Schapke et al.
direkter Austausch
von Informationen
Abb. 12.4 Direkte und indirekte Kommunikation über gemeinsame Informationsressourcen (vgl.
Schrage 1990)
12.4.1 Nebenläufigkeitskontrolle
einen Teildatensatz, mit den für ihre jeweilige Aufgabe erforderlichen Informationen
aus dem Gesamtdatenbestand zu extrahieren (Extraktion),
ihre individuellen Änderungen und Ergänzungen im lokalen Teildatensatz vorzuneh-
men (Modifikation) und
den lokalen Teildatensatz wieder in den Gesamtdatenbestand zurückzuspielen und mit
anderen bearbeiteten Teildatensätzen zusammenzuführen (Integration).
Über den parallelen Verlauf dieser drei Arbeitsschritte bei mehreren Nutzern muss
sichergestellt werden, dass zum Koordinationspunkt am Ende der Phase wieder ein kon-
fliktfreier Gesamtdatenbestand erreicht wird.
220 S.-E. Schapke et al.
T0 T1 T2 T3 Ti
Teildatensatz Teildatensatz
Gesamt- Gesamt-
datensatz datensatz
Teildatensatz Teildatensatz
Beide Formen der Nebenläufigkeitskontrolle haben Vor- und Nachteile. Die pessimisti-
sche Nebenläufigkeitskontrolle vermeidet einerseits mit großer Sicherheit, dass Konflikte
bei der parallelen Bearbeitung entstehen. Andererseits muss ein Nutzer mitunter sehr lan-
ge warten, bis die aktuell bearbeitenden Modellteile oder Dokumente wieder freigegeben
sind. Abhängig vom Aggregationsgrad kann auch die Verwaltung der Freigaben schnell
unübersichtlich und zeitaufwendig werden.
Die optimistische Nebenläufigkeitskontrolle wiederum bietet viele Freiheiten bei der
Bearbeitung der Daten. Gleichzeitig kann die Verwaltung der Teildatensätze aber äußerst
komplex sein, insbesondere wenn die Teildatensätze wieder in einem integrierten Modell
zusammengeführt werden sollen (engl. Merging). So müssen für die Integration mehre-
rer Bauwerksmodelle sowohl die geometrischen Körper als auch die Eigenschaften der
Bauwerkselemente verglichen werden. Umfassende Lösungsstrategien sind erforderlich,
um z. B. die geometrischen Änderungen an einem veränderten, zusammengeführten oder
gelöschten Element auf andere Modelle zu übertragen und dabei alle Abhängigkeiten zu
anderen Elementen (z. B. eine aufliegende Decke) und Elementdaten (z. B. das Element-
volumen) zu berücksichtigen.
In der Praxis sind die Vor- und Nachteile unterschiedlicher Nebenläufigkeitskontrollen
im jeweiligen Anwendungsbereich zu bewerten. So werden Lösungen mit pessimistischer
Nebenläufigkeitskontrolle häufig innerhalb von Unternehmen eingesetzt, während in der
unternehmensübergreifenden Zusammenarbeit die optimistische Nebenläufigkeitskontrol-
le vorherrscht. Für die reibungslose Datenbearbeitung sind darüber hinaus weitere Regeln
in der Zusammenarbeit notwendig, z. B. um klare Zuständigkeitsbereiche der Bearbeiter
festzulegen.
Die in Kap. 5 erläuterten Grundlagen der Interoperabilität bei der Datenverarbeitung be-
treffen vor allem technische Aspekte der Informationsmodellierung. Bei der gemeinsamen
Erarbeitung ingenieurstechnischer Lösungen im Bauwesen mittels elektronischer Daten
sind jedoch auch etablierte Methoden und die heute gängige Praxis der Zusammenarbeit
neu zu überdenken. Bei papier- und dokumentbasierten Formen der Zusammenarbeit las-
sen sich die Verantwortlichkeiten aller Informationsfacetten heute meist eindeutig z. B.
über den Stempel und die Unterschrift auf dem jeweiligen Planungsdokument (Plan, Text
etc.) zuordnen. Bei gemeinsam erarbeiteten und integrierten digitalen Bauwerksmodel-
len gestaltet sich dies schwieriger: Zu diesen Aspekten gehören etwaige Formen des
Eigentums, der Rechte und der Verlässlichkeit. Hierfür müssen projektspezifische oder
branchenweite Vereinbarungen getroffen werden.
Die Autorenschaft kann innerhalb ein und desselben Informationsraumes (des Modells)
von Objekt zu Objekt oder gar von Attribut zu Attribut wechseln. In Metadaten zu den
jeweiligen Informationsressourcen muss daher festgehalten werden, wem die Verantwort-
lichkeit jeweils obliegt. Eigentümer einer Ressource kann beispielsweise der ursprüngli-
222 S.-E. Schapke et al.
che Ersteller (der Architekt, der ein Wandobjekt erstellt) oder der letzte Bearbeiter (der
Tragwerksplaner, der die Bewährung einfügt) sein. Auch die Zugriffsrechte auf einzelne
Aspekte müssen geklärt werden: Darf der Statiker die Betongüteklasse als Materialattribut
direkt in die vom Architekten erstellte Wand eintragen? Oder erschafft er ein unabhängiges
Materialobjekt, das mit der entsprechenden Wand verknüpft wird? Erstellt er ein eigen-
ständiges Objekt? Die jeweiligen Lese-, Schreib- und Löschrechte können dabei nicht nur
an einen bestimmten individuellen Nutzer vergeben werden, sondern auch an Gruppen
von Bearbeitern, die jeweils unterschiedliche Rollen einnehmen können wie etwa aller
Mitarbeiter eines beteiligten Unternehmens, einer Abteilung, alle Systemadministratoren
oder der jeweiligen Projektleiter. In vielen Systemen lassen sich hierfür hierarchische und
kaskadierende Rollen und Rechte auf unterschiedlichen Aggregationsstufen festlegen, die
durch Überlagerung (ein Nutzer mit mehreren Rollen) schnell unübersichtlich werden
können und mit hoher Sorgfalt angelegt und immer wieder geprüft werden müssen. Bei
kollaborativ erstellten Informationsressourcen und Modellen müssen neue Formen des Ei-
gentums, der Rechte und der Verlässlichkeit betrachtet und entsprechende Vereinbarungen
getroffen werden. Die sich daraus ergebenden rechtlichen Fragen z. B. im Gewährleis-
tungsfall sind für digitale Kooperation jedoch noch nicht abschließend geklärt.
12.4.3 Versionierung
X
Revision/ gelöschte
Version Variante
Freigabe X Version
Abb. 12.6 Versionsgraph einer Informationsressource mit einfachen Versionen (weiß), Revisionen
(dunkelgrau), Varianten (hellgrau) und nicht weiter verfolgte Varianten (schwarz mit Kreuz)
visionsbezeichnung werden in der Regel auch revisionssicher archiviert und können als
Freigabestände verwendet werden.
Ein weiterer wichtiger Aspekt bei der modellgestützten Zusammenarbeit ist die Ver-
wendung von Varianten (engl. branch). Wird eine vorhandene Informationsressource
durch zwei verschiedene Personen oder Systeme verändert und die Änderungen sind zwei
mögliche alternative Ausgestaltungen, z. B. eines konstruktiven Details, wird von einer
Variante gesprochen. Varianten können weiterentwickelt werden und man erhält zwei
parallele und in der Regel nicht kompatible Produktlinien. Im Laufe der Bearbeitung wird
dann meistens eine Variante ausgewählt bzw. übernommen. Varianten sind jedoch wich-
tig, um verschiedene Lösungen bewerten und diskutieren zu können. Auch für Varianten
werden häufig entsprechende Variantenbezeichnungen eingeführt. Varianten bilden im
Versionsgraph Verzweigungen und Zusammenführungen. In Abb. 12.6 wird noch einmal
der Zusammenhang zwischen Version, Revision und Variante anhand eines einfachen
Versionsgraphen dargestellt.
Die Granularität der Versionierung entspricht dem jeweiligen Aggregationsgrad der
Informationsressource (vgl. Abschn. 12.2.2). Für alle Arten von Informationsressourcen
kann somit ein Versionsgraph umgesetzt werden. So gibt es Versionen, Revisionen und
Varianten von gesamten Modell- und Dokumentensammlungen, von Modellen und Do-
kumenten, von Elementgruppen, von Elementen und auch von einzelnen Elementeigen-
schaften.
Zur Versionierung von Dateien können Dateinamenskonventionen, Systeme zur Versi-
onsverwaltung von Dateien und Verzeichnissen (z. B. CVS – Concurrent Versions System,
SVN – Subversion, Git), oder Dokumentmanagementsysteme verwendet werden (s. Ab-
schn. 12.4.2). Die einfachste Art ist die Verwendung von Dateinamen. Dies bedeutet, dass
die Version, Revision und Variante anhand eines Teils des Dateinamens identifiziert wer-
den (z. B. V11_R2_A1 für Version 11, Revision 2 und Alternative 1). Jede Änderung wird
als eine neue Datei mit einem neuen Namen gespeichert. Bei der Variantenbildung mit-
tels Dateien muss beachtet werden, dass beim Kopieren der Varianten jeweils sämtliche
Inhalte kopiert werden. Bei Bauwerksmodellen bedeutet dies, dass die enthaltenen Model-
224 S.-E. Schapke et al.
lelemente die gleichen Identifikatoren besitzen. Dies kann sehr sinnvoll sein, wenn zum
Beispiel die Wand versetzt wird und beide Varianten verglichen werden sollen. In eini-
gen Fällen kann es jedoch auch zu Inkonsistenzen führen, z. B. bei Referenzen auf andere
Modelldateien einer anderen Variante.
Programme zur Versionsverwaltung von Dateien und Verzeichnissen eignen sich in
der Regel sehr gut für Textdaten (z. B. Unicodedateien). Beim Einchecken einer neuen
Datei wird automatisch eine Versionsnummer vergeben. Gewisse Stände können gekenn-
zeichnet werden (z. B. als Revision). Bei Systemen zur Versionsverwaltung können auch
verschiedene Varianten verfolgt werden. Jedoch eigenen sich solche Systeme nicht sehr
gut für binäre Dateien, da hier meist die gesamte Variante platz- und zeitaufwendig kopiert
werden muss, während textbasierte Formate lediglich Differenzen zwischen Versionen
und Varianten verwalten und übertragen müssen. Bei einem Dokumentmanagementsys-
tem erfolgt neben der Verwaltung der Dateien auch eine meist datenbankbasierte Spei-
cherung von ergänzenden Metadaten. Mithilfe dieser Metadaten sind Dokumente über
zusätzliche Informationsfelder recherchierbar. In der Regel werden jedoch keine Varian-
ten unterstützt.
Die Verwaltung von Versionen von digitalen Bauwerksmodellen oder Teilmodellen
ist eine große Herausforderung. Eine Möglichkeit ist die Versionierung der vollständi-
gen Modelldateien, welche bei umfangreichen Bauwerksmodellen mehrere Gigabyte um-
fassen können (stark aggregierte Informationsressource). Häufig ändern sich jedoch nur
einzelne Objekte des Modells mit ihren Eigenschaften. Daher ist eine selektivere Ver-
sionierung, z. B. Elementgruppen- oder Elementversionierung, sinnvoller. Hierzu wird in
den meisten Fällen eine entsprechende Datenbank mit Möglichkeiten zum Sperren, Ein-
und Auschecken sowie zur Vergabe von speziellen Rechten verwendet. Hierbei können
proprietäre und offene Systeme unterschiedenen werden. Bei einem proprietären Sys-
tem erfolgt der Zugriff auf die Modelle über eine spezielle Fachsoftware. Nur mit dieser
Fachsoftware lassen sich die Modelle dann auch verteilt bearbeiten. Solche Systeme bie-
ten fast alle großen BIM-Hersteller an. Dabei müssen dann alle Fachplaner zwingend
mit der entsprechenden Software arbeiten. Auch das Bilden von Varianten wird teilweise
unterstützt. In der Regel werden auch nicht alle Versionen gespeichert. Im Maschinen-
bau kommen hier zum Beispiel Product Data Management-Systeme (PDM-Systeme) zum
Einsatz (s. Abschn. 12.4.4). Offene Systeme sind unter anderem Modellserver, die eine
Aktualisierung von Teilmodellen erlauben, die von unterschiedlichen Softwaretools be-
arbeitet wurden. Hierbei kommen dann entsprechende Datenstandards wie die Industry
Foundation Classes zum Einsatz. Weitere Informationen zu Modellservern können Ab-
schn. 12.5.5 und 12.5.6 entnommen werden.
Die Freigabe kennzeichnet einen Prozess, bei dem eine abgestimmte, in der Regel revisio-
nierte Informationsressource durch einen berechtigten Partner signiert, veröffentlicht und
12 Kooperative Datenverwaltung 225
weitergeben wird. Zum Beispiel wird bei der Planfreigabe eine geprüfte und abgestimm-
te Konstruktionszeichnung durch den Architekten unterschrieben. Durch die Unterschrift
soll gewährleistet sein, dass der freigegebene Plan aktuell sowie gültig ist und für weitere
Planungen verwendet werden soll.
Bei der Verwendung von digitalen Informationsressourcen kann die Freigabe auch
durch eine digitale Signatur bzw. elektronische Unterschrift erfolgen. Bei der Verwendung
von Dateien auf Basis einer gemeinsamen Dateiablage (Abschn. 12.5.1) gewährleistet die
digitale Signatur, dass sowohl der Urheber als auch die Unveränderbarkeit geprüft wer-
den kann. Auch Dokumentenmanagementsysteme und internetbasierte Projektplattformen
bieten in der Regel eine Möglichkeit zur Definition eines Freigabeprozesses sowie die Ver-
wendung von digitalen Signaturen (Abschn. 12.5.2 und 12.5.3). Werden hingegen digitale
Bauwerksmodelle verwendet, erfolgt die Freigabe in der Regel in Form eines Koordinati-
onsmodells. Jedoch können auch einzelne Fachmodelle freigegeben werden. In der Regel
handelt es sich dann dabei um Modelle, die in Form von Dateien gespeichert werden und
entsprechend digital signiert werden können.
In der Praxis werden noch häufig gedruckte Pläne auf Basis der digitalen Bauwerks-
modelle verwendet, die wiederum manuell unterschrieben werden. Jedoch sollte in diesem
Fall auch eine Freigabe des zugehörigen Bauwerksmodells erfolgen und der entsprechen-
de Bearbeitungsstand archiviert werden. Die Unterstützung der Freigabe und Archivie-
rungsprozesse in aktuellen Produktmodellservern bzw. BIM-Modellservern befinden sich
noch in der Entwicklung (Abschn. 12.5.5). Daher sollten bei der Verwendung von sol-
chen zentralen Systemen, die Modelle in Form von standardisierten Formaten (z. B. IFC)
gespeichert, digital signiert und freigegeben werden. Es ist jedoch zu erwarten, dass in
Zukunft die entsprechenden Funktionalitäten implementiert werden.
Die Sicherung der Daten, auch über lange Zeiträume hinweg, stellt eine Herausforde-
rung an technische Systeme und ihre Nutzer dar. Dabei ist nicht nur zu gewährleisten,
dass die Daten lesbar bleiben, sondern auch verwendbar sind. Durch den schnellen tech-
nologischen Wandel der sich im Bereich BIM und der damit assoziierten Software voll-
zieht, wachsen die Anforderung an die Sicherung und Archivierung der Daten. Die langen
Nutzungsdauern und Gewährleistungsfristen der Gebäude selbst stehen dabei in einem
eklatanten Missverhältnis zu den Halbwertzeiten der sie beschreibenden Daten und ihrer
Werkzeuge. Dabei stellt vor allem die Abhängigkeit von herstellerspezifischen, geschlos-
senen und unzureichend dokumentierten Datenformaten ein schwerwiegendes Problem
dar, das oft mit dem Begriff der „Digitalen Amnesie“ beschrieben wird: Produkte und
Anbieter verschwinden vom Markt, verarbeitende Software wird inkompatibel zu den ei-
genen Vorgängerversionen, Betriebssystemen und Hardware. In der Bauindustrie wie in
anderen ingenieurtechnischen Bereichen ist man daher zu der Erkenntnis gelangt, das her-
stellerunabhängige, selbstdokumentierende, und als Klartext beschreibbare Formate mit
branchenübergreifender, breiter Unterstützung wie bspw. STEP oder XML (siehe Kap. 6)
den digitalen Verfall stoppen oder zumindest bremsen können. Besondere Relevanz hat
die digitale Langzeitarchivierung vor allem für private und öffentliche Bauherren, da die-
se langfristig an die Daten gebunden sind.
226 S.-E. Schapke et al.
Die Umsetzung der in den vorherigen Abschnitten vorgestellten Formen und Methoden
der Zusammenarbeit ist heute mit einer Anzahl verschiedener Technologien und Soft-
warewerkzeugen möglich. In diesem Abschnitt werden die grundlegenden Kategorien,
Funktionsweisen und Anwendungsgebiete solcher Systeme vorgestellt.
12.5.2 Dokumentenmanagement-Systeme
… … … …
In DMS werden die Dokumente als Datencontainer behandelt, deren Inhalte mit ander-
weitigen Fachanwendungen bearbeitet werden. Abbildung 12.7 zeigt die typischen Kom-
ponenten eines DMS. Mittelpunkt eines DMS ist die Datenverwaltung, die eine Dateiab-
lage für die Dokumente und eine Datenbank ihrer Metadaten umfasst. Die einheitliche
Beschreibung der Inhalte, Formalisierungen, Erstellungs- und Nutzungskontexte werden
durch vordefinierte Metadatenschemas und -vokabulare sichergestellt. Ergänzt wird die
Dokumentenverwaltung durch eine Nutzer- und Zugriffsverwaltung sowie Eingabe- und
Ausgabemodule zum Erfassen und wieder Auffinden der Dokumente. Darüber hinaus bie-
ten DMS zumeist mehrere Module zur gezielten Verteilung der Dokumente z. B. über
Nachrichten und Workflows an.
DMS können mit End- oder Webanwendungen direkt und über entsprechende Konnek-
toren aus anderen Fachanwendungen genutzt werden. Bei der Bearbeitung der Dokumente
wird im Allgemeinen eine pessimistische Nebenläufigkeitskontrolle angewendet. Wird ein
Dokument vom DMS geladen (check-out), wird es dort gesperrt und kann von anderen
Nutzern lediglich gesichtet, aber nicht weiter bearbeitet werden. Nach der Bearbeitung
wird das Dokument in einer neuen Version im DMS gespeichert (check-in) und steht den
Nutzern entsprechend ihrer Zugriffsrechte mitsamt seiner Änderungshistorie zur Verfü-
gung.
DMS werden in einigen Unternehmen auch für die Verwaltung von BIM-Daten ver-
wendet. Hierdurch werden zunächst die unternehmerischen Vorgaben für die Ablage,
Verteilung, Freigabe und die sichere Speicherung für Pläne und Dokumente auch für BIM-
Modelle umgesetzt.
228 S.-E. Schapke et al.
12.5.4 Produktdatenmanagementsysteme
Projekt Projektmerkmale
Bauteil Bauteilmerkmale
Dokument Dokumentenmerkmale
Legende
Metadaten
Datei
Datei
Abb. 12.9 CAD-Baugruppe Rad, bestehend aus den Einzelbauteilen Felge und Reifen
Voraussetzung für die Nutzung eines PDM-Systems sind CAD-Systeme, mit denen
die Produktstrukturen definiert und kontextabhängig visualisiert werden können. Anhand
ihrer geometrischen Repräsentationen können somit die Strukturelemente, ihre Beziehun-
gen und ihre Sachmerkmalen sowie die Merkmale der zugehörigen Dokumente dargestellt
werden.
12.5.6 Produktmodellserver
Produktmodellserver dienen der zentralen Verwaltung von Produktmodellen, die mit ver-
teilten CAD- bzw. BIM-Anwendungen erstellt wurden. Im Gegensatz zu den PDM-Sys-
temen werden die Modelldaten der Elemente und ihrer Kompositionen jedoch nicht auf
mehrere Dateien verteilt, sondern vom Modellserver vollständig gelesen und in einer Da-
tenbank gespeichert (Schorr et al. 2011).
232 S.-E. Schapke et al.
Web-Interface
im Browser
Versionierung
API
Verwaltung, Rollen, 2D/3D Visualisierung
bimserver.org
Rechte und
Abfragesprachen Client z.B. als Plug-in in
Modellkern:
Objektschablonen und Webservice vorhandenen BIM
-filter basierend auf IDM/
MVD
IFC Export/Import Schnitstellen
(REST,
Anwendungen
Objekt-Datenbank Modell-Checker
Kopplung mit anderen
Produktmodellservern
...
Die in diesem Kapitel vorgestellten Methoden und Techniken der gemeinsamen Daten-
verwaltung gehören zu den vielversprechendsten, aber auch komplexesten Aspekten des
Building Information Modeling. Die Frage nach der bestmöglichen Form der Organisation
gemeinsamer Zusammenarbeit kann nicht einfach beantwortet werden und hängt entschei-
dend von den Anwendungsszenarien (z. B. innerbetrieblich oder firmenübergreifend), den
Leistungsphasen, Unternehmenskulturen und technischen Randbedingungen ab.
Obwohl erste Ansätze bereits in der Praxis umgesetzt werden, wie beispielsweise die
Erfahrungsberichte im fünften Teil dieses Buches schildern, gibt es noch eine Reihe offe-
234 S.-E. Schapke et al.
ner Fragen, die durch Forschung und Entwicklung beantwortet werden müssen. Während
beispielsweise rechtliche Fragen der Sicherheit, Gewährleistung und Haftung mit tra-
ditionellen Papierdokumenten gut handzuhaben sind, wird für die vornehmlich digitale
Zusammenarbeit noch nach entsprechenden Lösungsansätzen gesucht. Digitale Signa-
turen und Fingerabdrücke, Archivierungsstrategien und Sicherheitskonzepte in Hinblick
auf Rollen und Rechte müssen ausgiebig überdacht und entwickelt werden. Ansätze und
Verfahren aus anderen Industriezweigen wie etwa dem Product Lifecycle Management
(PLM), oder dem vor allem in der Luft- und Raumfahrt angewendeten Ansätzen des
Systems Engineering bieten viele interessante Konzepte, die in zukünftige Formen com-
putergestützter Zusammenarbeit im Bauwesen eine Rolle spielen könnten. Dafür müssen
jedoch alle Methoden entsprechend der kleinteiligen und heterogenen Zusammensetzung
der Projektverbünde im Bau angepasst werden.
Die gemeinsame Bearbeitung von Daten erfolgt heutzutage noch größtenteils auf den
lokalen Desktop-Rechnern und Workstations der jeweiligen Fachingenieure. Gründe dafür
liegen auch in den hohen Anforderungen an die Grafik-Hardware im Falle komplexer drei-
dimensionaler Modelle. Verschiedene Anwendungen wie die Verwaltung gemeinsamer
Gebäudemodelldaten, die dynamische Erweiterung von Speicherplatz oder rein numeri-
sche Berechnungen etwa für Simulationen können jedoch auf mehrere Maschinen verteilt
und ausgelagert werden. Die Verwaltung dieser verteilten und ausgelagerten Anwendun-
gen wird unter dem Begriff Cloud Computing zusammengefasst. In vielen Fällen muss
dabei die Software selbst (Datenverwaltung, Simulation etc.) nicht auf dem Desktop des
Anwenders laufen, sondern wird als Service über ein Netzwerk zu Verfügung gestellt
(Software as a Service). Der Internet-Browser wird dabei zusehends ein wichtiges Werk-
zeug als universelle grafische Benutzerschnittstelle.
Den großen Vorteilen der gemeinsamen Datenverwaltung und -bearbeitung in der
Cloud stehen aber auch Nachteile gegenüber: Erstens muss sichergestellt sein, dass ho-
heitliche Unternehmensdaten vom Cloud-Betreiber sicher und nachhaltig gespeichert
werden (Verschlüsselung und Archivierung) und über das Internet jederzeit zur Verfü-
gung stehen. Zweitens sind die vielen im Webbrowser laufenden Cloud-Anwendungen
häufig derzeit nicht so leistungsfähig wie die entsprechenden Desktop-Anwendungen.
Drittens stellt sich mit der zunehmenden Anzahl an speziellen Cloud-Lösungen die Frage,
wie die auf unterschiedlichen Servern verteilten Projekt- und Unternehmensdaten wieder
zusammengeführt, bereitgestellt und ausgewertet werden können. Technische Lösun-
gen für diese Integration der Softwareanwendungen bieten die relativ neuen Techniken
für das Semantic Web und Linked Data. Dabei kann jedes Objekt und jedes Attribut in
einem Gebäudemodell mit einer URL identifiziert an einem beliebigen Ort abgelegt,
miteinander verknüpft und verwendet werden, was einem minimalen Aggregationsgrad
entspricht. Die dadurch entstehenden Modelle sind gerichtete Graphen, die dynamisch
zusammengestellt und mit beliebigen anderen Informationsressourcen erweitert und ver-
knüpft werden können, etwa mit Sensordaten aus Gebäuden im Internet of Things. In
vernetzten Umgebungen wie der computergestützten Zusammenarbeit mit Gebäudeinfor-
12 Kooperative Datenverwaltung 235
Literatur
Verwendete Literatur
Beetz, J. (2009) Facilitating distributed collaboration in the AEC/FM sector using Semantic Web
Technologies. Dissertation, Eindhoven University of Technology
Beetz, J. et al., 2010. Bimserver.org – An Open Source IFC Model Server. In Proceedings of the
CIB W78 2010: 27th International Conference. CIB W78. Cairo, Egypt, pp. 325–332
DIN 276 (2008) Kosten im Hochbau, Beuth
Götz K., Schneiderath U., Maier B. & Komke T. (2004): Dokumenten-Management – Informationen
im Unternehmen effizient nutzen. 3. Aufl., dpunkt Verlag, Heidelberg
Loos P., Vanderhaegen D. (Hrsg.) (2007): Kollaboratives Prozessmanagement – Methoden, Werk-
zeuge und Anwendungsbeispiele, Logos-Verlag, 2007
Hambuch U. (2008): Erfolgsfaktor Metadatenmanagement: Die Relevanz des Metadatenmanage-
ments für die Datenqualität bei Business Intelligence. Vdm, Saarbrücken 2008
KKS (2010): KKS Kraftwerk-Kennzeichensystem. VGB PowerTech Servic, Essen, 2010
NBIS (2014) National Institute of Building Sciences: BIM Service interface exchange (BIMSie).
http://www.nibs.org/?page=bsa_bimsie, zuletzt abgerufen Januar 2015
OmniClass (2006): Construction Specifications Institute (CSI) and Construction Specifications Ca-
nada (CSC). Alexandria, VA, USA Verlag, Berlin
Pauwels, P., Tormä S., Beetz, J., Weise, M., Liebich, T. (2015) Linked Data in Achitecture and
Construction. Special Issue Automation in Construction, erscheint Juni 2015
Scherer R.J., Schapke S.-E. (2015): Multimodellbasierte Zusammenarbeit in Bauprojekten. In: In-
formationssysteme im Bauwesen 1 – Modelle, Methoden und Prozesse, Springer-Verlag Berlin
Heidelberg, 2014
Schorr, M.; Borrmann, A.; Obergriesser, M.; Ji, Y.; Günthner, W.; Euringer, T.; Rank, E. (2011):
Using Product Data Management Systems for Civil Engineering Projects – Potentials and
Obstacles, ASCE Journal of Computing in Civil Engineering 25 (6), pp. 430–441, DOI:
10.1061/(ASCE)CP.1943-5487.0000135
Schrage M. (1990): Shared Minds: The New Technologie of Collaboration. Random House, New
York
Teufel S., Sauter C., Mühlherr T., K. Bauknecht (1995): Computerunterstützung für die Gruppenar-
beit. Addison-Wesley, Bonn, 1995
Weise, M., Katranuschkov, P. & Scherer, RJ., (2004): Managing long transactions in model server
based collaboration. In: Ework and Ebusiness in Architecture, Engineering and Construction.
Leiden, The Netherlands: Balkema Publishers, S.187–194
Uniclass2 (2013): Uniclass2, the classification for the Construction Industry. Construction Project
Information Committee, UK, http://www.cpic.org.uk/uniclass/, zugegriffen Januar 2015
236 S.-E. Schapke et al.
Weiterführende Literatur
AIA (2013): AIA Document E202 – 2013, Building Information Modeling Protocol Form. Ame-
rican Institute of Architects, Washington DC, USA http://www.aia.org/aiaucmp/groups/aia/
documents/pdf/aiab099086.pdf Zugegriffen: 4. November 2014
British Standard Institution (2013): PAS 1192-2:2013 Specification for information management
for the capital/delivery phase of construction projects using building information modelling,
The British Standards Institution, London, Großbritannien
Curry E. O’Donnell J. Corry E., Hasan S., Keane M., O’Riain S. (2013): Linking building data
in the cloud: Integrating cross-domain building data using linked data, Advanced Engineering
Informatics, 27(2), 2013
McGrath J. E. (1984): Groups. Interaction and Performance. Englewood Cliffs, NJ, Prentice-Hall,
1984
Picot A., Reichwald R. & Rolf T.W. (2001): Die grenzenlose Unternehmung – Information, Orga-
nisation und Management. 4. Aufl., Gabler, Wiesbaden, 2001
Schreyögg G. (2008): Organisation. Grundlagen moderner Organisationsgestaltung. 5. Aufl.,
Gabler, Wiesbaden, 2008
Schwabe G., Streitz N. A., Unland R. (2001): CSCW-Kompendium. Springer, Berlin, 2001. (http://
ccs.mit.edu/papers/CCSWP157.html)
Searle J.R. (1983): Sprechakte – Ein sprachphilosophischer Essay. Orignalveröffentlichung 1969,
Suhrkamp, Frankfurt a. M. 1983
BIM-Manager
Jan Tulke und Dirk Schaper
13
Zusammenfassung
Der BIM-Manager ist eine Rolle, die sich innerhalb von Bauprojekten neu herausgebil-
det hat. Die Einführung und durchgängige Nutzung einer BIM-basierten Arbeitsweise
erfordert vorab Festlegungen bzgl. projektspezifischer Anwendungsfälle, verwende-
ter Technologien sowie von Prozessabläufen, Verantwortlichkeiten und spezifischen
Handlungsanweisungen für die Datenerstellung und -verarbeitung. Darüber hinaus ist
eine begleitende Koordination und Unterstützung während der gesamten Projektlauf-
zeit erforderlich. Aufgrund der Komplexität dieser Aufgabe und des erforderlichen
Querschnittswissens aus Ingenieurwissenschaft und Informationstechnologie kann die-
se Rolle nicht adäquat durch etablierte Rollen übernommen werden. Gleichzeitig ist sie
jedoch ein wesentlicher Erfolgsfaktor bei der Einführung und zweckmäßigen Nutzung
von Building Information Modeling auf einem Projekt. Jedoch hat sich bisher für die
Rolle des BIM-Managers noch keine einheitliche Beschreibung etabliert. In diesem Ka-
pitel werden sowohl die Gründe für diese neue Rolle als auch die mit ihr verbundenen
Verantwortlichkeiten, Aufgaben sowie die erforderlichen Fähigkeiten und Kenntnisse
betrachtet. Ebenso wird die Einbettung innerhalb der Projektorganisationsstruktur nä-
her beleuchtet.
Building Information Modeling (BIM) hat zum Ziel, dass alle Projektbeteiligten ihre
benötigten Informationen aus einem gemeinsamen Datenbestand beziehen und ihr Ar-
beitsergebnis dort für andere zur Weiterverwendung zur Verfügung stellen. Analog zu
traditionellen koordinierenden Funktionsstellen auf Planungs- und Bauausführungsebene
Abb. 13.1 BIM-Manager als zentraler Ansprechpartner und Schlüsselrolle für die fachdisziplin-
übergreifende Koordination der Einführung und Nutzung von BIM
dafür entwickeln, dass es im Kern darum geht, die traditionell getrennten Sichtweisen
und Informationsstrukturen der einzelnen Fachdisziplinen auf einen für alle brauchba-
ren und ineinandergreifenden, strukturierten Datenbestand abzubilden. Dies erfordert die
Bereitschaft und Unterstützung zur Abstimmung mit anderen Projektbeteiligten und ggf.
die Anpassung der eigenen Prozesse hinsichtlich Informationserstellung und -nutzung.
Die vereinbarten Vorgehensweisen sind aufbauend auf ggf. bereits existierenden Richt-
linien oder vertragliche Regelungen zu dokumentieren, um eine Überprüfbarkeit und
die Einbindung neuer Mitarbeiter sicherzustellen. Das heißt der BIM-Manager begleitet,
unterstützt und stellt sicher, dass die Komponenten Menschen, Prozesse, Richtlinien und
Technologien berücksichtigt und den Projektanforderungen entsprechend auf die BIM-
Nutzung ausgerichtet werden (Abb. 13.2).
Insbesondere der begleitende Charakter von Hilfestellung und Koordination über die
gesamte Projektlaufzeit hinweg ist wichtig, da Projektmitarbeiter unter der alltäglichen
Arbeitsbelastung und dem stets vorhandenen Zeitdruck dazu neigen, beim Auftreten
kleinster Probleme oder vorhandener Unsicherheit beim Umgang mit neuen Methoden
und Softwarewerkzeugen in alte, unkoordinierte Arbeitsweisen zurückzufallen. Hierdurch
entstehen schnell Nebenläufigkeiten und letztlich wird der Gesamterfolg der BIM-Einfüh-
rung gefährdet. Der BIM-Manager wirkt diesem als unmittelbar greifbarer, kompetenter
Ansprechpartner aber auch als prüfende Instanz entgegen. Er ist somit über das Aufsetzen
der BIM-Prozesse hinweg zentraler Ansprechpartner und treibende Kraft bzgl. Schulung,
Problembehebung, kontinuierlicher Verbesserung und Ausweitung der BIM-basierten
Arbeitsweise im Projekt. Letztendlich stellt er so den BIM-Nutzen für das Gesamtprojekt
bzw. im Namen des Auftraggebers sicher. Dabei hat er neben der technischen Koordi-
nation auch die Erreichung eines möglichst frühen Return on Investment aus der BIM-
Nutzung als Ziel.
13 BIM-Manager 241
Die Aufgaben eines BIM-Managers sind vielfältig, sie betreffen die projektbezogene Kon-
zeption, Einführung, Koordination und laufende Unterstützung der modellbasierten Da-
tenkommunikation. Dabei verschieben sich die Schwerpunkte der Arbeitsinhalte entlang
der Projektlaufzeit.
Zu Projektbeginn erfolgt gemeinsam mit dem Projektteam und ggf. mit projektüber-
greifendem BIM-Personal oder BIM-Beratungsdienstleister die Definition und Priorisie-
rung der BIM-Anwendungsfälle. Je nach Typ, Größe und Komplexität des Bauwerks,
der Kundenanforderungen, der vorhandenen BIM-Erfahrung sowie der örtlichen, softwa-
retechnischen und sonstigen Projektrahmenbedingungen wird festgelegt, welche spezi-
fischen Aufgaben im Projekt mithilfe des Bauwerksmodells unterstützt werden sollen.
Beispiele für BIM-Anwendungsfälle sind die modellbasierte Mengenermittlung und die
modellbasierte Dokumentation des Status von Bauteilabnahmen bzw. -prüfungen. Diese
Fokussierung auf BIM-Anwendungsfälle ist notwendig, um einerseits allen Beteiligten ei-
ne klare Vorstellung von der BIM-Nutzung zu geben und andererseits um sicherzustellen,
dass die erzeugten Modelldaten inhaltlich und strukturell sowie die eingesetzte Softwa-
re funktionell den Anforderungen genügen. Dadurch werden unnötige Aufwände für die
Erstellung unbrauchbarer Modelldaten oder dessen arbeitsintensiver Überarbeitung ver-
mieden. Ebenso können dadurch rollen- und anwendungsbezogene Schulungsmaßnahmen
konzipiert werden.
Die Aufgabe des BIM-Managers ist es, die Umsetzung des Katalogs der BIM-Anwen-
dungsfälle unter Berücksichtigung der gegenseitigen Abhängigkeiten zu führen und zu
überwachen. Nachfolgend wird, ohne einen Anspruch auf Vollständigkeit zu erheben, das
sich daraus ergebende Aufgabenspektrum des BIM-Managers umrissen:
Das Anforderungsprofil eines BIM-Managers setzt sich aus Erfahrung in der Gestal-
tung von Bauplanungsprozessen, spezifischem IT-Wissen und praktischen Fertigkeiten
der Softwarebedienung sowie der Führungskompetenz im Sinne von Koordination und
13 BIM-Manager 243
In einem Projekt oder Unternehmen werden je nach Größe und Anzahl der BIM-Anwen-
dungsfälle mehrere dedizierte BIM-Rollen vorhanden sein. Der Wirkungskreis dieser Rol-
len unterscheidet sich einerseits infolge ihrer organisatorischen Stellung auf Auftraggeber-
oder Auftragnehmerseite bzw. innerhalb eines Einzelunternehmens oder einer unterneh-
mensübergreifenden Projektorganisation (z. B. ARGE) sowie andererseits infolge ihrer
BIM-Verantwortlichkeit bezogen auf ein Einzelprojekt oder projektübergreifend innerhalb
einer Organisation (z. B. sog. BIM-Group-Manager). Weitere Unterscheidungsmerkmale
sind der Ort der Tätigkeit, der auf BIM verwendeten Arbeitszeitanteil sowie der Charakter
der eigenen Tätigkeit (Konzeption vs. selbst ausführende Tätigkeit). Für die Rollenbe-
zeichnung BIM-Manager hat sich die folgende Charakteristik etabliert:
Abb. 13.4 BIM-Management als eigenständige Fachdisziplin innerhalb des Technical Management
Teams
Alternativ, insbesondere auf Projekten mit BIM-erfahrenen Partnern, kann das BIM-
Management auch als eigene Fachdisziplin in das technische Management eingegliedert
werden (Abb. 13.4). Einfluss auf vertragliche Regelungen und das projektweite Change
Management, das in der Einführungsphase erforderlich ist, gehen hierbei jedoch erfah-
rungsgemäß verloren. Eine Eingliederung des BIM-Managements in das Design Team
erscheint angesichts der dort erfolgenden Modellerstellung naheliegend, ist jedoch nicht
ratsam, da hierdurch der fachdisziplin- und phasenübergreifende Charakter verloren geht.
Das Ergebnis sind 3D-Modelle, die im Bauprozess weder genutzt noch aktualisiert wer-
den.
Die Aufgabe des BIM-Managements erfordert neben der Platzierung im Organigramm
und der Einbindung eines BIM-Managers weitere BIM-bezogene Rollen innerhalb der
Projektorganisation. Nachfolgend soll die weitere Projektdurchdringung aufgezeigt wer-
den. Die dabei genannten Rollenbezeichnungen sind jedoch bisher ebenfalls nicht standar-
disiert und können daher innerhalb verschiedener Projekte bzw. Organisationen sowohl
anders benannt als auch mit unterschiedlicher Bedeutung belegt sein.
In der Konzeption und bei strategischen Entscheidungen wird der BIM-Manager durch
eine übergeordnete Rolle (sog. BIM Project Manager, BIM Group Manager oder bei
Rahmenverträgen sog. Framework BIM Manager, BIM Programm Manager) unterstützt,
die auch den Hauptansprechpartner für externe Vertragspartner darstellt und daher aus
Kundensicht zum Schlüsselpersonal zählt (Abb. 13.5). Diese Rolle betreut in der Regel
mehrere Projekte gleichzeitig und arbeitet eng mit der Projektleitung zusammen, ist je-
doch in die praktische Umsetzung im Einzelprojekt nur indirekt involviert.
Die weitere Projektdurchdringung erfolgt einerseits fachlich durch einen Verantwortli-
chen je BIM-Anwendungsfall (sog. Lead) und andererseits disziplinarisch durch vertrag-
lich benannte BIM-Verantwortliche (sog. BIM-Koordinatoren) mit entsprechender Ent-
scheidungsbefugnis je projektbeteiligtem Unternehmen. Diese Rollen werden oftmals in
Kombination mit klassischen bauausführungs- oder planungsbezogene Rollen bekleidet.
Die praktische Umsetzung der einzelnen BIM-Anwendungsfälle in Form der Daten-
erzeugung, -aufbereitung und -verarbeitung erfolgt durch die Rollen des BIM Engineer
oder des BIM Modeller, die durch Ausweitung der klassischen Tätigkeitsbereiche in Pla-
nung und Bauvorbereitung entstanden sind. Beispielsweise gehören hierzu Rollen für die
3D-Modellierung als Erweiterung der 2D-Planerstellung, für die Clash Detection als Un-
246 J. Tulke und D. Schaper
terstützung der Planungskoordination sowie für die 4D-Animation als Erweiterung der
Terminplanung. Hinzukommen das datenbezogene Qualitätsmanagement sowie die Ein-
bindung nachgelagerter Projektbeteiligter entlang der Lieferkette.
Steht (insbesondere in der Übergangsphase der BIM-Einführung) im Projekt oder Un-
ternehmen noch kein entsprechendes Personal zur Verfügung, so können einzelne BIM-
Rollen auch alternativ durch spezialisierte externe BIM-Dienstleister bzw. BIM-Berater
bekleidet werden.
13.7 Fazit
sowie der Umstand, dass die BIM-basierte Arbeitsweise zukünftig als Stand der Technik
anzusehen und damit sehr viel stärker standardisiert sein wird, dazu führen, dass die be-
schriebenen Aufgaben wieder weitestgehend von bestehenden Koordinationsrollen (z. B.
Architekt, Projektsteuerer) mit überschaubarem Zusatzwissen übernommen werden kön-
nen.
Auswirkungen auf das Bauvertragsrecht
Klaus Eschenbruch und Robert Elixmann
14
Zusammenfassung
Der Einsatz von BIM-Planungstechnologien wirft eine Vielzahl von rechtlichen Fra-
gestellungen auf. Im Kern ist es Aufgabe des Bauvertragsrechts, die bei dem Ein-
satz dieser Planungsmethodik erforderlichen Prozesse und die Rechte und Pflichten
der Vertragsparteien zu regeln. Die Autoren behandeln in diesem Kapitel nach ei-
ner einleitendenden Stellungnahme zu im internationalen Kontext diskutierten, neu-
en Vertragsstrukturen die Regelungsbereiche Arbeitsorganisation/Abwicklungsdetails,
Rechte an Daten, Haftung, BIM-Management und Vergütung. Herausgestellt werden
die nach Ansicht der Autoren bei der Vertragsgestaltung maßgeblich zu berücksich-
tigenden Interessenlagen. Dabei werden auch die Lösungsansätze international ge-
bräuchlicher Vertragsmuster (AIA, ConsensusDocs, nec3) vorgestellt und miteinander
verglichen. Die Autoren kommen zu dem Ergebnis, dass BIM weder ein neues Para-
digma der Vertragstypen, noch ein neues Haftungsregime erfordert. Einzelheiten zum
BIM-Einsatz können in BIM-spezifischen Vertragsanlagen, die zur Anlage sämtlicher
Einzelverträge gemacht werden, geregelt werden. Das HOAI-Preisrecht steht hierbei
einer aufwandsangemessenen Vergütung der durch die BIM-Prozesse entstehenden
Mehr- oder Minderaufwendungen nicht entgegen.
14.1 Einleitung
Qualitäten, verknüpft werden. In Deutschland gibt es bislang nur geringe praktische Er-
fahrungen mit dem Einsatz entsprechender Planungstechniken. Zum Teil arbeiten die
Planungsbeteiligten an einem einheitlichen virtuellen Gebäudemodell. Zum Teil entste-
hen bei Objekt- und Fachplanungsbeteiligten unterschiedliche Fachmodelle, die über eine
IFC-Schnittstelle zusammengeführt werden. BIM stellt tradierte Zusammenarbeitsformen
und das Vertragsrecht der Planungs- und Baubeteiligten auf den Prüfstand. Erfahrungen
mit der BIM-Anwendung sind international und erst recht national so jung, dass sich
noch keine einheitliche Vertragsstrategie zum Umgang mit der BIM-Anwendung heraus-
gebildet hat. Ein Recht der BIM-Anwendung existiert noch nicht. Die Vielgestaltigkeit
denkbarer BIM-Anwendungen und die inhaltlich noch nicht abschließend konkretisierten
BIM-Prozesse haben die Herausbildung einheitlicher Vertragslösungen bislang behindert.
Mit diesem Beitrag sollen erste Grundlagen für das neue Vertragsrecht der BIM-Anwen-
dung gelegt werden.
Bauprojekte sind grundsätzlich dadurch gekennzeichnet, dass eine Mehrzahl von zu-
vor unabhängigen Beteiligten sich für eine zeitlich begrenzte Aufgabe zusammenfinden.
Dies bringt es mit sich, dass die Rollen der jeweiligen Beteiligten und ihre Beiträge für
jedes Projekt neu organisiert werden müssen. Die wechselseitigen Rechte und Pflichten
der Projektbeteiligten werden typischerweise in Verträgen festgelegt. Die entsprechen-
de Festlegung widerspruchsfreier Projektrollen und das Funktionieren der Interaktion der
Projektbeteiligten auf Basis der Verträge sind für den Erfolg der Bauprojekte von großer
Bedeutung. Die BIM-Planungsmethode verändert die Art und Weise wie Bauprojekte
realisiert werden. Neue Leistungen sind zu beschreiben, Verantwortlichkeiten sind von-
einander abzugrenzen und neue, sich durch BIM stellende Rechtsfragen sind zu klären.
Es kursieren vielfältige Mustervertragsformulare, die eine sinnvolle Hilfestellung bei der
Vertragsgestaltung liefern. Zu dem Einsatz der BIM-Planungsmethode liegen auch be-
reits Mustervertragsklauseln aus dem amerikanischen und britischen Rechtskreis vor. Her-
ausgegriffen werden hier die ergänzenden Vertragsbedingungen des American Institute
Of Architects (AIA) und von ConsensusDOCS, ferner das CIC BIM Protocol in Ergän-
zung der nec3-Vertragsmuster. Mustervertragsklauseln können als eine Art Checkliste und
Anregung für die erforderliche Regelungstiefe eines Vertrags dienen. Sie helfen, rege-
lungsbedürftige Punkte nicht zu übersehen. Ihre unreflektierte, schematische Anwendung
verbietet sich allerdings, weil die Vertragsgestaltung immer die spezifischen Eigenarten
des konkreten Projekts berücksichtigen muss.
BIM ist noch nicht richtig in Deutschland angekommen. Basierend auf den Erfah-
rungen der Autoren bezüglich der Gestaltung von Verträgen für komplexe Bauvorhaben,
speziell auch bezüglich des Einsatzes von Planungsplattformen mit vielen Planungsbe-
teiligten sowie ersten Erfahrungen zu BIM-Projekten sollen nachfolgend unter Berück-
sichtigung der zuvor genannten, vornehmlich im internationalen Kontext verwendeten
Mustervertragsklauseln erste bauvertragliche Lösungsansätze aufgezeigt werden, die vor-
aussichtlich in der Zukunft die Grundlage für Projektabwicklungen bilden werden.
14 Auswirkungen auf das Bauvertragsrecht 251
14.2 Vertragssysteme
14.3 Arbeitsorganisation/Abwicklungsdetails
wer in welcher Form eine zentrale Planungsplattform vorhält und wer welche Software
stellt,
wer (Zugriffsrechte) Daten wann (Meilensteine) hochladen darf und abrufen kann
(Freigabevoraussetzungen),
wie die Daten beschaffen sein müssen (Dateiformate, Namenskonventionen, zu ver-
wendende Programme/Programmversionen, Detaillierungsgrad, Fertigstellungsgrade),
welche Prüf- und Hinweispflichten Projektbeteiligte hinsichtlich Vorleistungen Dritter
treffen,
wer welche Hol- und Bringschulden hat.
Der durch BIM geforderte und geförderte Austausch von Daten schafft ein gegenüber bis-
herigen Planer- und Bauverträgen erhöhtes Bedürfnis für vertragliche Vorgaben zum Da-
tenumgang, namentlich zu urheberrechtlichen Nutzungsrechten an Gebäudemodellen und
Verschwiegenheitspflichten hinsichtlich anderer Projektbeteiligten zugänglich gemachter
Daten.
Aus Sicht des Bauherrn ist sicherzustellen, dass er zu jedem Zeitpunkt im Lebenszy-
klus des Bauprojekts einen uneingeschränkten Zugriff auf das Gebäudedatenmodell hat.4
Sofern die Gebäudedaten auf einer Projektplattform bei einem anderen Projektbeteilig-
ten liegen, ist durch vertragliche Regelungen zu gewährleisten, dass ein Zugriff auch
möglich bleibt, wenn das Vertragsverhältnis vorzeitig beendet wird (Eschenbruch und
Grüner 2014, S. 408). Eine Datennutzung könnte des Weiteren durch Urheberrechte der
1
Art. 3 und 4 AIA Document E203-2013.
2
AIA Document G201-2013 und G202-2013.
3
Ziff. 4 ConsensusDOCS 301 BIM-Addendum.
4
Es wird nicht übersehen, dass es oftmals nicht ein 3D-Gebäudedatenmodell gibt, sondern Teil-
modelle unterschiedlicher Fachdisziplinen erstellt werden, die zum Zweck des Kollisionsabgleichs
zusammengeführt, aber im Übrigen getrennt gespeichert und bearbeitet werden. Wenn im Text von
dem 3D-Gebäudedatenmodell gesprochen wird, ist damit auch die Gesamtheit der vorhandenen 3D-
Gebäudedatenmodelle gemeint, die in ihrer Summe die vollständige Planung des Gebäudes abbil-
den.
14 Auswirkungen auf das Bauvertragsrecht 255
(„permitted purpose“) eingeräumt werden und verweist auf eine eng gefasste Defini-
tion dieses Zwecks (Ziff. 1.1.12). Gleichzeitig ist ein Widerruf von Lizenzen für den
Fall vorgesehen, dass Zahlungspflichten nicht nachgekommen wird (Ziff. 6.4). Schließ-
lich sind Änderungen urheberrechtlich geschützter Werke nur in engen Grenzen ohne
Zustimmung des Urhebers möglich (Ziff. 6.5). AIA Document E203-2013 enthält keine
umfassenden Urheberrechtsklauseln. Die Urheberrechtsthematik wird dem eigentlichen
Vertrag vorbehalten. Es begnügt sich mit dem Hinweis, dass urheberrechtliche Nutzungs-
rechte nur in dem für die Projektrealisierung zwingend erforderlichen Umfang einge-
räumt werden dürfen (Sec. 2.3). Klargestellt wird, dass Gebäudemodelldaten an Dritte
ausschließlich zur Erfüllung der vertraglich vereinbarten Planungsaufgabe oder aufgrund
einer bindenden, gerichtlichen Anordnung preisgegeben werden dürfen (Sec. 2.2.1). Das
ConsensusDOCS 301 BIM Addendum enthält umfassende Regelungen zu Urheberrechten.
Interessant ist, dass auch diese Musterklauseln einen Entzug von Nutzungsrechten bei der
Verletzung von Zahlungsverpflichtungen vorsehen, allerdings diese Rechtsfolge unter die
Voraussetzung stellen, dass eine Entscheidung eines Gerichts oder Schiedsgerichts über
die Berechtigung der Zahlungsforderung vorliegt (Ziff. 6.7). Derartige Regelungen sind
indessen nicht durchgängig sachangemessen. Es besteht überhaupt kein Grund dafür, dem
Auftraggeber die Rechte am Gebäudemodell zu entziehen, wenn es zu einer bloßen Zah-
lungsverzögerung kommt.
14.5 Haftung
Denkbar ist, dass Beiträge einzelner Planungsbeiträge mangelhaft sind und darauf auf-
bauende Leistungen deshalb zunächst nicht erbracht werden können. Möglich ist auch,
dass Planungsbeteiligte alleine deshalb eigene Leistungen mangelhaft erbringen, weil Pla-
nungsfehler in Vorleistungen übersehen worden sind. Fraglich ist, ob und in welchem
Umfang für Planungsbeiträge gehaftet werden soll. Ein sich zunehmend durchsetzender
Ansatz wäre es, dass sich durch die Arbeit an einem gemeinsamen Gebäudedatenmodell
an den Verantwortlichkeiten der einzelnen Beteiligten nichts ändert. Jeder haftet für sei-
ne Planungsbeiträge. Sofern eigene Leistungen auf Vorarbeiten anderer aufbauen, wird
für eine daraus resultierende Mangelhaftigkeit des eigenen Werks gehaftet, wenn die
Vorarbeiten nicht in dem gebotenen Umfang geprüft worden sind und nicht auf beste-
hende Mängel hingewiesen worden ist. In diesem Zusammenhang sollte im Rahmen der
Abwicklungsdetails hinreichend deutlich geregelt sein, wer die Verantwortung für die
Fortschreibung und Brauchbarkeit des Gebäudedatenmodels ab definierten Meilensteinen
trägt.
Ein anderer Ansatz wäre, Haftungsbeschränkungen zu vereinbaren, um die Zusammen-
arbeit der Projektbeteiligten zu fördern. Die deutsche Bauwirtschaft ist gegenwärtig davon
geprägt, dass sehr viel Energie in die Fehlersuche in den Beiträgen anderer Projektbetei-
ligter gesteckt wird, um daraus Behinderungsanzeigen und Nachträge zu generieren. In
dieser Atmosphäre sind viele Beteiligten in erster Linie darauf bedacht, keine Fehler zu
14 Auswirkungen auf das Bauvertragsrecht 257
machen und im Zweifel lieber zu wenig als zu viele Informationen mit Projektbeteiligten
zu teilen. Es wird angenommen, dass eine solche Atmosphäre Gift für die Realisierung
eines integrativen Planungsansatzes sei. Bezeichnend für diesen Zustand ist, dass augen-
scheinlich die großen Baukonzerne, die möglichst viele Leistungen aus einer Hand erbrin-
gen und dadurch Schnittstellen vermeiden, noch am weitesten bei der Implementierung
von BIM-Planungsprozessen zu sein scheinen. Die BIM-Anwendung wird dabei auf die
unternehmensinternen Arbeitsabläufe beschränkt (sog. „Closed BIM“). Die Vorteile von
BIM lassen sich, wie bereits wiedergegeben, nach einer vielfach vertretenen Auffassung
nur dann ausschöpfen, wenn mit der Verwendung von BIM-fähigen Planungswerkzeugen
ein Wandel der bisherigen Planungs- und Bauprozesse einhergeht hin zu einer verstärk-
ten Zusammenarbeit der Beteiligten untereinander. Unter diesem Blickwinkel können
Vereinbarungen über Haftungsbeschränkungen zu einem erfolgreichen „Kulturwandel“
beitragen.5 Die augenblickliche Planungspraxis ist aber durch vielfältige Nachlässigkeiten
und Fehler gekennzeichnet. Der Einsatz der BIM-Planungstechnologie soll – unter Ein-
satz neuer Instrumente wie der EDV-gestützten Kollisionsvermeidung und dem Model
Checking – das frühzeitige Aufdecken von Planungsfehlern ermöglichen und die Pla-
nungsqualität heben. Es kann schwerlich Zielstellung sein, durch die Reduzierung von
Verantwortlichkeiten von Planungsbeteiligten eine noch größere Sorglosigkeit bei der
Ablieferung von Planungsergebnissen, wie in der bisherigen Planungsprojektpraxis kenn-
zeichnend, zu unterstützen. Zielstellung von BIM sollte es gerade sein, die Planungsqua-
lität bei größeren Projekten deutlich zu heben. Eine Veranlassung, die Verantwortung der
Projektbeteiligten für ihre Planungsbeiträge zu reduzieren, besteht nach Auffassung der
Verfasser nicht. Dementsprechend setzt sich auch im internationalen Bereich zunehmend
die Tendenz durch, auch beim BIM-Einsatz in Bezug auf die grundsätzliche Verantwor-
tung der Projektbeteiligten für ihre Planungsbeiträge, wie immer diese auch aussehen,
keine Abstriche zu machen.
Ein weiterer Aspekt ist die Haftung für Software- und Datenübertragungsfehler
(Eschenbruch und Grüner 2014, S. 408). Ein Beispiel für einen Softwarefehler könnte
sein, dass aus dem Datenmodell Prognosen zu Kosten oder Terminen abgeleitet werden,
die aufgrund eines Softwarefehlers falsch berechnet und dadurch Entscheidungen auf-
grund falscher Sachverhaltsbasis getroffen werden. Sofern Bedienfehler auszuschließen
sind und der Auftraggeber eine bestimmte Software vorgegeben hat, dürfte er dieses
Risiko zu tragen haben. Anderes kann gelten, wenn es dem Auftragnehmer überlassen
war, welche Software er verwendet und wie er die von ihm geforderten Prognosen er-
mittelt. Eine Klarstellung, in welchem Umfang die Leistungspflicht des Auftragnehmers
die Plausibilisierung automatisch errechneter Prognosen oder sonstiger Werte erfasst,
ist erforderlich. Geregelt werden sollte außerdem die Frage, wer das Risiko trägt, dass
Daten im Rahmen einer Datenübertragung verloren gehen oder verändert werden. Eine
Spezialfrage in Bezug auf die Datenverlässlichkeit tritt auf, wenn in die Datenmodelle
5
Auf Haftungsrisiken als Hinderungsgrund für die Vereinbarung einer engeren Zusammenarbeit im
Rahmen eines BIM-Planungsprozesses hinweisend Lowe und Muncey (2009, S. 5 f.)
258 K. Eschenbruch und R. Elixmann
14.6 BIM-Management
allerdings auch, dass sich für diese Leistungen ein eigenes Berufsbild des BIM-Managers
entwickeln wird. Vermutlich wird es keine einheitliche Handhabung geben. Je nach den
Projektbedürfnissen werden die Aufgaben der BIM-Strategieberatung zu Projektbeginn,
der BIM-Koordination im Projektverlauf und der Bereitstellung der erforderlichen IT-
Infrastruktur durch unterschiedliche Projektbeteiligte, gebündelt oder getrennt, erbracht
werden. Tulke und Schaper stellen in Kap. 13 ihre Vorstellungen über den genauen Tä-
tigkeitsbereich des BIM-Managers vor. Die Verfasser dieses Beitrages haben in einem
Aufsatz das Leistungsbild des BIM-Managers vorgestellt (Eschenbruch und Elixmann
2015).
Das ConsensusDOCS 301 BIM Addendum benennt die Notwendigkeit der Bestimmung
eines sogenannten „Information Managers“ durch den Auftraggeber und listet die von
diesem zu erbringenden Leistungen detailliert auf (Ziff. 3). Das Musterdokument enthält
Ankreuzkästchen, in denen angegeben werden kann, ob dem Planer, dem Ausführenden
oder einem zu benennenden Dritten die Rolle des „Information Managers“ übertragen
wird. Die dort genannten Leistungen erschöpfen sich allerdings in rein administrativ-ver-
waltenden Aufgaben ohne inhaltlichen Einfluss auf den Planungsprozess (z. B. Nutzerkon-
ten und Zugriffsrechte verwalten, Datensicherheit gewährleisten, Zugriffe auf Datenbank
protokollieren). AIA Document E203-2013 sieht vor, dass der Architekt das „BIM Mana-
gement“ übernimmt (Sec. 4.8.1). Dieses beinhaltet ebenfalls weit überwiegend technisch-
administrative Aufgaben, erfasst aber auch inhaltliche Tätigkeiten, etwa die Durchfüh-
rung von Kollisionsprüfungen. Das CIC BIM Protocol enthält keine Regelungen zum
BIM-Manager. In dessen einleitenden Bemerkungen wird allerdings klargestellt, dass die
Benennung eines „Information Manager“ vorausgesetzt werde und hinsichtlich dessen
Leistungsumfang wird auf die Leistungsbeschreibung des CIC für den „Information Ma-
nager“ verwiesen („Outline Scope of Service for the Role of Information Management“).
Am Anfang der Leistungsbeschreibung wird klargestellt, dass nach dem Leitbild der Leis-
tungsbeschreibung die darin beschriebenen Tätigkeiten von einem der bereits involvierten
Projektbeteiligten zu übernehmen sind. Inhaltlich erfassen die Tätigkeiten u. a. den Betrieb
der Datenplattform und die Organisation des Datenaustauschs, aber auch die Überprüfung
der übermittelten Daten auf Kollisionen und die Einhaltung von Modellierungskonventio-
nen.
14.7 Vergütung
Interviews in Fachkreisen haben ergeben, dass ein Hemmschuh für die Vereinbarung
von BIM-Planungsleistungen die Unsicherheit ist, inwiefern das Preisrecht der Hono-
rarordnung für Architekten und Ingenieure (HOAI –Verordnung über die Honorare für
Architekten- und Ingenieurleistungen v. 10.7.2013, BGBl. I S. 2276). Vertragsparteien in
der freien Festlegung der Vergütungshöhe einschränkt (Eschenbruch et al. 2014, S. 25).
Relevant wird diese Fragestellung nur innerhalb der Grenzen des Anwendungsbereichs
der HOAI. Die HOAI ist zwingendes Preisrecht nur für in den Leistungsbildern als Grund-
260 K. Eschenbruch und R. Elixmann
6
Der BIM-Leitfaden für Deutschland (Egger et al. 2014) ist schon sehr detailliert und liefert wert-
volle Erkenntnisse, bildet jedoch auch noch nicht einen BIM-Planungsprozess vollständig ab.
14 Auswirkungen auf das Bauvertragsrecht 261
14.8 Zusammenfassung
1. Der Einsatz von BIM-Planungstechnologien wirft eine Vielzahl von rechtlichen Fra-
gestellungen auf. Im Kern ist es Aufgabe des Bauvertragsrechts, die bei dem Einsatz
dieser Planungsmethodik erforderlichen Prozesse und die Rechte und Pflichten der
Vertragsparteien zu regeln.
2. BIM erfordert weder ein neues Paradigma der Vertragstypen, noch ein neues Haftungs-
regime. Es kann daher bei den bisher tradierten Einzelverträgen der Projektpraxis,
ergänzt um BIM-spezifische und für alle Vertragsbeteiligten geltende Vertragsanla-
gen, genauso verbleiben, wie bei der Haftung der einzelnen Projektbeteiligten für ihre
Leistungsbeiträge.
3. Die Form der Zusammenarbeit der Beteiligten, die zum Einsatz kommenden Hard- und
Software-Tools, Hol- und Bringschulden, Meilensteine für die Modellzusammenfüh-
rung (etwa mit IFC-Standards), Aufgabenstellungen des BIM-Managers, des Model-
Checkings sowie der Fortschritts- und Meilensteinmodelle bedürfen einer vertragli-
chen Ausgestaltung. Im Rahmen der weiteren Projektabwicklung kann dann mittels
BIM-Protokollen die Fortentwicklung der Grundlagen anhand der konkreten Abstim-
mungen der Projektbeteiligten bei der Erarbeitung des Gebäudemodells erfolgen.
4. Die Vergütung der durch die BIM-Prozesse entstehenden Mehr- oder Minderaufwen-
dungen kann unbeschadet der Regelungen des HOAI-Preisrechts sachgerecht erfolgen.
Die Einschaltung neuer Planungsbeteiligter, wie BIM-Manager und BIM-Administra-
toren sowie die vertiefte Planung in den Frühphasen der Planung, würde zunächst mit
einer Verteuerung entsprechender BIM-Planungstechnologien einhergehen. Automa-
tisierungsprozesse in der weiteren Projektabwicklung, beginnend mit der Erstellung
von Leistungsverzeichnissen bis hin zu Termin- und Kostenkontrollen, und schließ-
7
BGH, Urteil v. 22.5.1997, Az. VII ZR 290/95.
262 K. Eschenbruch und R. Elixmann
lich der Einsatz des Gebäudemodells im FM, können diese Nachteile jedoch schnell
wettmachen.
5. Ein sachangemessenes Bauvertragsrecht kann den Einsatz von BIM-Planungstechno-
logien fördern. Ohne bauvertragliche Unterstützung wird sich Building Information
Modeling umso eher als ein Abenteuer für die Projektbeteiligten herausstellen.
Literatur
Zusammenfassung
Die Digitalisierung der Gesellschaft schreitet stetig voran und führt zu Veränderun-
gen im täglichen Leben und Arbeiten. Die Digitalisierung im Bauwesen – aktuell der
Übergang von CAD zu BIM – ist Chance und Herausforderung zugleich. Die Vorteile
von BIM können besonders effizient genutzt werden, wenn der gesamte Bauprozess
betrachtet wird. Dies setzt aber entsprechende Regularien und belastbare Kalkulatio-
nen voraus. Die Vorteile liegen nicht primär in der Vorentwurfs- und Entwurfsphase,
sondern vor allem in nachgelagerten Prozessen sowie beim Auftraggeber und müssen
als Sonderleistungen in der HOAI vergütet werden.
Dieser „Return-on-Investment“ in den späteren Planungs-, Bau- und Betriebspha-
sen muss erfolgreich kommuniziert werden, um einen breiten Paradigmenwechsel in
der Architekten- und Bauherrenschaft sowie in der Politik, der öffentlichen Hand und
den Körperschaften öffentlichen Rechtes zu erreichen. Durch den Einsatz von BIM
können kosten- und risikorelevante Entscheidungen bereits in frühen Phasen getroffen
werden. Jedoch fehlt es hier noch an Methoden und Fähigkeiten der einzelnen Akteu-
re, beispielsweise für die Einbindung von Analyse- und Simulationsmethoden, um mit
teilweise vagen und unvollständigen Bauinformationen interagieren zu können.
Die rasante Entwicklung digitaler Technologien in den letzten 30 Jahren führte zu immer
neuen Anwendungsmöglichkeiten in der Architektur. Computer-Aided Design (CAD),
Rendering, Animation und digital gestützter Modellbau sind heute etablierte Arbeitswerk-
zeuge im Büroalltag.
Betrachtet man die heutige Situation jedoch kritisch, so ist festzustellen, dass Computer
zwar erfolgreich Einzug in die meisten Architekturbüros gehalten haben, aber die meisten
Programmsysteme lediglich eine Übertragung etablierter Arbeitsweisen und Werkzeuge
auf den Computer sind – als digitales Zeichenbrett, als reines Präsentationsmedium. Diese
werden voneinander getrennt und sequenziell benutzt.
Mit dem Einzug vom BIM in den Büroalltag findet parallel eine Diskussion über den
Einfluss der Methodik auf den architektonischen Arbeitsprozess und auf die Architek-
tur selbst statt – ähnliche Diskussionen gab es bereits bei der Einführung von CAD und
computergestützter Visualisierung von Architektur.
Entsprechend der Entwurfsaufgabenstellung werden adäquate Methodiken und Werk-
zeuge ausgewählt, wie auch die BIM-Methodik und BIM-Werkzeuge. Durch eine durch-
gängige Bearbeitung von Projekten mit der BIM-Methodik bereits in frühen Entwurfs-
phasen kann – je nach Priorität – eine Steigerung der Qualität von Gebautem oder der
Effizienz des Prozesses erreicht werden.
Das Potenzial der BIM-Methodik kann die Beherrschung der Komplexität in frühen
Planungsphasen, insbesondere im Dialog mit Auftraggebern und Fachplanern, unterstüt-
zen. Vorteile sind beispielsweise die direkte Ableitung von Stück-, Massen- und Flä-
chenlisten, konsistente Planungsunterlagen (Planungsmodelle) und die Kommunikation
mit Fachplanern und Klienten mittels 3D-Modellen. Die Parametrisierung ermöglicht die
Bildung von Varianten, schnellere Änderungen und damit bessere Möglichkeiten, auf ver-
änderte Rahmenbedingungen zu reagieren. Durch die Einbeziehung von Analysen und
Simulationen bereits in der Vorentwurfs- und Entwurfsplanung können Entscheidungen
plausibel, objektivierbar und vor allem frühzeitig vorbereitet, getroffen und begründet,
nachvollzogen beziehungsweise zurückverfolgt werden.
Jedoch ist heute festzustellen, dass gerade in den frühen Phasen des Entwurfes nur
wenige entwurfsunterstützende, intuitiv zu bedienende Softwarewerkzeuge existieren, um
Kreativität zu fördern sowie die vagen und unvollständigen Informationen zu behandeln –
beispielsweise die Vorstellung des Bauherren oder fragmentarische städtebauliche Rah-
menbedingungen. Der Einsatz neuer Technologien erfordert vor allem eine Änderung
in den Arbeitsabläufen. Durch den Einsatz von BIM verlagern sich Aufgabenbereiche,
die aktuell noch in späteren Planungsphasen bearbeitet werden, zunehmend in frühere
Planungsphasen (Davis 2014). Dies beinhaltet auch die intensive Zusammenarbeit mit
Fachplanern und anderen am Bau Beteiligten beginnend bereits beim allerersten Gedan-
ken zum Projekt. Daraus ergeben sich neue Tätigkeitsfelder und Unternehmensaspekte für
Architekturbüros.
Der Architekt spielt nicht nur bei der Erstellung der Modelle eine Schlüsselrolle, son-
dern auch als Manager im BIM-basierten Entwurfsprozess. Diese Aufgaben werden büro-
15 BIM im architektonischen Entwurf 267
intern von BIM-Managern übernommen oder extern beauftragt und umfassen u. a. die Ko-
ordination der Arbeitsabläufe, den Austausch von Modellen und die Auswahl der Werk-
zeuge. Dies setzt wirtschaftliche, konstruktive und nicht zuletzt gestalterische Kompeten-
zen voraus – allesamt Kernkompetenzen eines Architekten.
Verschiedene Forschungsprojekte der letzten Jahre haben das Potenzial einer integrierten
BIM-gestützten Arbeitsweise gegenüber einer 2D-basierten Planung aufgezeigt. Seitens
der am Bau Beteiligten – wie Architekten, Ingenieure, Aufragnehmer – werden hohe Er-
wartungen an BIM hinsichtlich Effizienz und integrierter Zusammenarbeit gestellt (von
Both et al. 2013).
Nach Liebich fand die erste digitale Revolution im Bauwesen – der Übergang zum
2D CAD – von 1985 bis 2005 statt. Aktuell befinden wir uns in der Phase der zwei-
ten digitalen Revolution, dem Übergang zu BIM. Betrachtet man die heutige Situation,
so ist festzustellen, dass – neben verschiedenen Hindernissen (von Both et al. 2013) in
der Einführung von BIM in der Praxis gerade für die Vorentwurfs- und Entwurfsphasen
noch nicht ausreichend intuitive BIM-basierte Werkzeuge zur Verfügung stehen. Unter
BIM-Werkzeugen sind parametrische, raum- und bauteilorientierte Softwarewerkzeuge
zu verstehen sowie vielfältige Auswertungs- und Simulationswerkzeuge, die auf einem
semantischen Bauwerksmodell operieren.
Ein häufig genannter Kritikpunkt an BIM-Systemen ist die Komplexität der Funktio-
nalität und die gleichzeitige Begrenztheit bei der Auswahl an Bauteilen. BIM-Werkzeuge
wie beispielsweise Revit Architecture oder ArchiCAD ermöglichen jedoch die Erstellung
individualisierter Bauteile. Dies setzt jedoch umfassende Kenntnisse für deren Erstellung
und Verwaltung voraus (Egger et al. 2013). Da individualisierte Bauteile selten wieder
verwendet werden und der Modellieraufwand größer ist als bei non-BIM Tools, sind neue
Interaktions- und Modellierparadigmen für Softwarewerkzeuge notwendig.
Für die Konzeptmodellierung sowohl für die räumliche Gestalt als auch die räumli-
che Konfiguration werden heute häufig non-BIM Tools verwendet. Der Datenaustausch
erfolgt über proprietäre, geometriebasierte Schnittstellen. Ohne semantische Beschreibun-
gen – wie beispielsweise dass zwei Linien eine Tür symbolisieren – werden Informationen
missverständlich, nicht computerlesbar ausgetauscht und verhindern automatisierte Prü-
fungen und Analysen.
Verstärkt werden für die Unterstützung im Entwurfsprozess in den letzten Jahren „para-
metrische, visuelle Entwurfsprogrammierumgebungen“ genutzt, wie beispielsweise Gras-
shopper 3D – ein Aufsatz für Rhinoceros oder Generative Components (Bentley Systems,
Inc.). Beim parametrischen Entwerfen werden Verknüpfungen der Parameter verschiede-
ner geometrischer Objekte zur Abbildung komplizierter Abhängigkeiten, diese teilweise
als Ergebnis komplexer algorithmischer Berechnungen, eingesetzt. Durch die Erweiterung
der „Entwurfsumgebung“ können Analysen und Simulationen direkt in die Umgebung
268 F. Petzold et al.
Ecotect
Artra
Grasshopper Grevit CostX
Entwurfsprozess
eingebunden und die Ergebnisse als Parameter für die Abbildung komplexer Abhängig-
keiten herangezogen werden. Meist wird mit verschiedenen Softwareprodukten, wie bei-
spielhaft in Abb. 15.1 dargestellt, das iterative Arbeiten beim Entwerfen umgesetzt.
Ein durchgängiges BIM-basiertes Entwerfen ist heute in der Praxis nur selten anzu-
treffen, da die Voraussetzungen nur unzureichend gegeben sind. Gut strukturierte, geo-
metrisch weniger komplexe Aufgabenstellungen werden eher mit BIM-Werkzeugen ge-
plant. Für die Verknüpfung der Parameter verschiedener Raum- und Bauteilobjekte zur
Abbildung komplizierter geometrischer und algorithmischer Abhängigkeiten wurden in
den letzten Jahre verschiedenen Erweiterung für BIM-Werkzeuge zur Verfügung gestellt,
beispielsweise Dynamo für Autodesk Revit – eine „parametrische visuelle Programmier-
umgebung“.
Architekten denken und entwickeln ihre Ideen räumlich, sie nutzen 2D-Darstellungen
(wie Skizzen, Pläne, Schnitte) als vorübergehende Abstraktion (Buxton 2007) und als
Kommunikationsmittel mit am Bau Beteiligten. Ein momentan auftretendes Paradoxon
ist, dass auch bei einer durchgängigen BIM-Planung 2D-Repräsentationen für beispiels-
weise Bauantragstellungen eingereicht werden. Diese Problematik muss gelöst werden.
Neben rechtlichen Fragestellungen bei der Übergabe von Modellen an Fachplaner, Ämter
und Auftraggeber, umfasst das insbesondere Verantwortlichkeiten und Modellqualitäten.
Die Einführung der BIM-Arbeitsmethode wird über einen integrierenden Ansatz definiert
und bewirkt einen Kulturwandel im Bauwesen, eine lebenszyklus-übergreifende Betrach-
tung basierend auf digitalen semantischen Modellen.
15 BIM im architektonischen Entwurf 269
Die Motivation für die Einführung der BIM-Methodik im Architekturbüro kann extern
oder intern getrieben sein. Extern beispielsweise durch Projektvorgaben, Partner, Konkur-
renz oder Marketing beziehungsweise intern durch das Bestreben nach Optimierung von
Arbeitsabläufen und anderen Prozessen, Erschließung neuer Tätigkeitsfelder oder mehr
zeitlichem Freiraum für die Arbeit an der architektonischen Qualität.
Das Gelingen des BIM Entwurfs- und Planungsprozesses hängt im Wesentlichen von
den Rahmenbedingungen – Menschen, Prozessen, Technologien und Richtlinien – ab.
BIM ist in erster Linie Informationsstruktur und erfordert deshalb auch Struktur – ins-
besondere und zuerst bei der Organisation innerhalb der Architekturbüros.
Für die Einführung und Etablierung der BIM-Methode in der Unternehmensstruktur
ist die Abwägung der beschriebenen Parameter notwendig. Diese bestimmen beispiels-
weise den Umfang der Implementierung (ob nun „little bim“ oder „BIG BIM“) und die
gewünschten bzw. im Einzelfall möglichen Auswirkungen auf die Organisationsstruktur
in der Projektbearbeitung, beispielsweise externe BIM-Beratung oder die Bildung von
Arbeitsgemeinschaften.
Die Digitalisierung der Gesellschaft schreitet stetig voran und führt zu Veränderungen
im täglichen Leben und Arbeiten. Die Digitalisierung im Bauwesen – hier die zweite
digitale Revolution als Übergang von CAD zu BIM – ist Chance und Herausforderung
zugleich. Die Einführung und Etablierung der BIM-Methodik kann zu einem Wettbe-
werbsvorteil führen und zur Effizienzsteigerung beitragen. Die Vorteile von BIM können
besonders effizient genutzt werden, wenn der gesamte Bauprozess betrachtet wird. Dies
setzt aber entsprechende Regularien und belastbare Kalkulationen voraus. Die Vorteile
liegen nicht primär in der Vorentwurfs- und Entwurfsphase, sondern vor allem in nach-
gelagerten Prozessen sowie beim Auftraggeber und müssen als Sonderleistungen in der
HOAI vergütet werden. Für die Beurteilung der Kostenansätze fehlen aktuelle Aussagen.
Hier muss insbesondere die öffentliche Hand Referenzprojekte unterstützen, sodass be-
lastbare Aussagen getroffen werden können.
Der „Return-on-Investment“ in den späteren Planungs-, Bau- und Betriebsphasen muss
erfolgreich kommuniziert werden, um einen breiten Paradigmenwechseln in der Architek-
ten- und Bauherrenschaft sowie bei der Politik, der öffentlichen Hand und den Körper-
schaften öffentlichen Rechtes zu erreichen. Durch den Einsatz von BIM können kosten-
und risikorelevante Entscheidungen bereits in frühen Phasen getroffen werden. Jedoch
fehlt es hier noch an Methoden und Fähigkeiten der einzelnen Akteure, beispielsweise
für die Einbindung von Analyse- und Simulationsmethoden, um mit teilweise vagen und
unvollständigen Bauinformationen interagieren zu können. Es mangelt an Methoden, die
Variantenerzeugung und deren vergleichende Beurteilung zu unterstützen. Hier sind die
Forschungseinrichtungen und die Softwareindustrie gefragt, adäquate Methoden zu ent-
wickeln und Werkzeuge anzubieten.
270 F. Petzold et al.
Eine essenzielle Grundvoraussetzung im Umfeld von BIM ist die Qualifikation der Mit-
arbeiter, neben der Ausbildung an Berufsschulen, Hochschulen und Universitäten müssen
Weiterbildungsangebote durch Kammern und Bildungsträger angeboten werden. Die In-
itiative zur Einführung der BIM-Methodik im Architekturbüro muss von der Geschäftslei-
tung ausgehen, zumindest bei den Entscheidungen hinsichtlich der Kosten bei der Einfüh-
rung, Schulung und der Umgestaltung der Arbeitsprozesse. Die in Deutschland vorherr-
schende Kleinteiligkeit der Bürostrukturen erfordert es, neue Strategien der Zusammenar-
beit, der Spezialisierung und der Erschließung neuer Tätigkeitsfelder zu entwickeln.
Literatur
von Both, P.; Koch, V.; Kindsvater, A. (2013): BIM – Potentiale, Hemmnisse und Handlungsplan.
Analyse der Potentiale und Hemmnisse bei der Umsetzung der integrierten Planungsmethodik
Building Information Modeling – BIM – in der deutschen Baubranche und Ableitung eines
Handlungsplanes zur Verbesserung der Wettbewerbssituation. Stuttgart: Fraunhofer-IRB-Verlag
(Forschungsinitiative ZukunftBau, 2844).
Buxton, William (2007): Sketching user experience. Getting the design right and the right design.
San Francisco, Calif: M. Kaufmann.
Davis, D. (2014): The MacLeamy curve – Daniel Davis. Online verfügbar unter http://www.
danieldavis.com/macleamy/, zuletzt geprüft am 18.06.2014.
Egger, M.; Hausknecht, K.; Liebich, T.; Przybylo, J. (2013): BIM-Leitfaden für Deutsch-
land. http://www.bbsr.bund.de/BBSR/DE/FP/ZB/Auftragsforschung/3Rahmenbedingungen/
2013/BIMLeitfaden/Endbericht.pdf?__blob=publicationFile&v=2, zuletzt aktualisiert am
20.01.2014, zuletzt geprüft am 09.07.2014.
Holzer, D. (2011): BIM’s seven deadly sins. In: A. Brown (Hg.): IJAC, vol. 9 – no. 4, S. 463–480.
BIM zur Unterstützung der ingenieurtechnischen
Planung 16
Jan Tulke
Zusammenfassung
Der wesentlichste Beitrag von Building Information Modeling zur Umsetzung der
ingenieurtechnischen Planung ist die anschauliche, interaktive Visualisierung des ge-
planten Bauwerks in 3D samt der direkt damit verknüpften Informationen bzgl. Pro-
duktspezifikation, Erstellung und Betrieb. Hierdurch werden ein vertieftes Verständnis
des Bauprojektes sowie die Grundlage für eine verbesserte Koordination zwischen den
beteiligten Fachplanern und Bauausführenden geschaffen.
Aufbauend auf das Datenmodell und die neuen Visualisierungsmöglichkeiten ha-
ben sich darüber hinaus mit der Clash Detection, der 4D-Bauablaufanimation und dem
Model Checking drei Konzepte für die Unterstützung und Fehlerkontrolle der Planung
herausgebildet, die gegenüber der herkömmlichen Planungsmethodik eine zusätzliche
Automatisierung und Detailkoordination ermöglichen. In diesem Kapitel werden heuti-
ge Möglichkeiten, Nutzen und erforderliche Rahmenbedingungen dieser drei Konzepte
auf Basis von Praxiserfahrung mit marktüblicher Software im Detail beleuchtet.
Der Koordinierung der Planung kommt eine große Bedeutung zu, da, gerade auf größe-
ren Projekten, viele Planungsbeteiligte zunächst unabhängig voneinander verschiedene
Fachaspekte planen und Fachwissen der ausführenden Firmen eingebunden werden soll.
Die Koordination hat dabei die Aufgabe für eine zeitlich rechtzeitige Fertigstellung einer
fehlerfreien und qualitativ hochwertigen, integrierten Planung zu sorgen. Hierzu gehört
es, insbesondere bei der Zusammenführung der verschiedenen Planungen, auftretende
Jan Tulke
HOCHTIEF ViCon GmbH, Alfredstrasse 236, 45133 Essen, Deutschland
e-mail: jan.tulke@hochtief.de
Mit Clash Detection wird das automatisierte Auffinden von geometrischen Durchdrin-
gungen (Konflikten oder Clashes) verschiedener Bauteile im 3D-Modell bezeichnet. Hier-
durch soll die geometrische Baubarkeit des Endzustands des Bauwerks sichergestellt wer-
den. Konflikte ergeben sich dabei hauptsächlich zwischen Leitungen verschiedener Ge-
16 BIM zur Unterstützung der ingenieurtechnischen Planung 273
werke der technischen Gebäudeausrüstung sowie aus einer nicht abgestimmten Durch-
bruchsplanung (siehe Abb. 16.1). Auch wenn Planer stets für sich in Anspruch nehmen,
dass bei einer qualitativ hochwertigen Planung, d. h. bei erfahrenem Personal und ent-
sprechender Koordination, Konflikte erst gar nicht auftreten und somit der vermeintliche
Zusatzaufwand für eine Clash Detection eingespart werden kann, hat es sich in der Praxis
gezeigt, dass bei Gebäuden und Infrastrukturprojekten (abhängig von Größe und Kom-
plexität) bei der Durchführung einer Clash Detection oftmals mehrere Tausend Konflikte
identifiziert werden. Das offensichtliche Einsparungspotenzial und der damit verbundene
schnelle Return of Investment führte dazu, dass die Clash Detection heute weltweit eine
der häufigsten Anwendungsfälle für die BIM-Nutzung ist. Zudem sind die Anforderungen
an die Inhalte und Struktur des 3D-Modells sehr gering und leistungsfähige Software mit
vielfältigen Importschnittstellen für übliche CAD Programme ist am Markt verfügbar. Die
Herausforderungen liegen daher eher in der Verarbeitung, Koordination und Nachverfol-
gung der Lösung der zahlreichen identifizierten Konflikte. Schließlich ist der eigentliche
Zweck einer Clash Detection nicht das Auffinden der Konflikte bzw. Planungsfehler, son-
dern deren Koordination und Lösung.
Um die strukturierte und gewerkbezogene Bearbeitung der in der Regel hohen An-
zahl von Konflikten innerhalb einer Koordinationsbesprechung mit mehreren beteiligten
Fachplanern zu ermöglichen, ist es wichtig, die Menge der gefundenen Konflikte vor-
274 J. Tulke
Abb. 16.2 Planungsbesprechung mit dem 4D-Modell an interaktiven Projektionsboards auf der
Baustelle
Abb. 16.3 Einsatz von Clash Detection Software in Koordinationsbesprechungen und bei der Über-
arbeitung im Planungsbüro
sondere größere Projekte in der Regel in Planungsabschnitte unterteilt sind, für die eine
Planungsfertigstellung sukzessive erfolgt, ist auch die Clash Detection dem Planungsfort-
schritt folgend, abschnittsweise durchzuführen.
276 J. Tulke
Abb. 16.4 Prozess und Akteure der iterativen Planungskoordination mittels Clash Detection
Zuletzt sei noch angemerkt, dass die Clash Detection sowohl im Hochbau als auch
im Infrastrukturbau auf gleiche Weise angewendet werden kann. Ein Unterschied ergibt
sich lediglich darin, dass bei Infrastrukturbauwerken selbst beim Neubau die Lage existie-
render Leitungen im Untergrund oftmals nicht eindeutig bekannt ist. Ansonsten sind die
Dimensionen gefundener Konflikte im Infrastrukturbau meist größer und damit auch die
vermiedenen Folgekosten einzelner Konflikte.
16.3 4D-Bauablaufanimation
Ein 4D-Modell bzw. eine 4D-Bauablaufanimation entsteht durch die Verknüpfung des 3D-
Modells mit dem Bauablaufterminplan und der Angabe von Visualisierungsparametern
wie Farbe, Transparenz und Visualisierungstyp (z. B. erscheinen, verschwinden, temporär)
je Terminplanvorgang. Zweck ist die Visualisierung der Bauabläufe und der zeitlich ver-
änderlichen Baustelleneinrichtung. Dieses dient einerseits der visuellen Überprüfung des
Terminplans bzgl. Vollständigkeit und logischer Abfolge und andererseits dessen Kommu-
nikation in leicht verständlicher Weise gegenüber Projektbeteiligten und der Öffentlichkeit
zwecks Koordination. Gerade bei komplexen Bauzuständen, wechselnden Verkehrsfüh-
rungen, räumlich beengten Baustellen und komplexer Bauwerksgeometrie ermöglicht die
Visualisierung anhand des 4D-Modells eine schnellere und vollständigere Erfassung des
geplanten Bauablaufs. Dies dient der Abstimmung der beteiligten Firmen, der Fehlerver-
meidung durch das Erkennen räumlicher Abhängigkeiten sowie der Baustellensicherheit
(z. B. bei der Nutzung des 4D-Modells im Rahmen von Sicherheitseinweisungen). Auf
Basis eines 4D-Modells in der Planung kann eine sukzessive Verbesserung des Bauab-
laufs unterstützt werden. Die Detailtiefe und die Qualität der Bauablaufplanung werden
insgesamt deutlich erhöht.
Zur umfassenden Visualisierung des Bauablaufs muss das 3D-Modell des endgültigen
Bauwerks jedoch um weitere Elemente ergänzt werden. Hierzu gehören temporäre Bau-
teile, die Baustelle selbst samt Baustelleneinrichtungsobjekten (Terrainmodelle, Lager-,
Verkehrs- und Lieferflächen, Absturzsicherungen, wesentliche Baumaschinen, Sicher-
heitseinrichtungen und -flächen usw.) sowie angrenzende Verkehrsflächen. Um diese 3D-
Objekte entsprechend dem Bauablauf zeitlich zu schalten ist auch der Terminplan um
entsprechende Vorgänge zu ergänzen. Generell erfordert die Nutzung eines 4D-Modells
278 J. Tulke
Abb. 16.5 Unlogische 4D-Visualisierung infolge zu grober Terminplanung mit überlappenden Ter-
minplanvorgängen
zudem oftmals einen, gegenüber der traditionellen Nutzung in Form eines Balkendia-
grams, insbesondere nach räumlichen Aspekten detaillierter gegliederten Terminplan.
Dies ist erforderlich, um Bauabschnitte und sequenzielle Abfolgen von Vorgängen plau-
sibel darzustellen. Insbesondere Terminplanvorgänge, die sich im Balkenplan zeitlich
überlappen, können zu unlogischen Darstellungen führen. Beispielsweise werden oftmals
das Erstellen einer Geschossdecke und der darunter liegenden Stützen vereinfacht durch
zwei zeitlich überlappende Vorgänge geplant, ohne Betonierabschnitte zu berücksich-
tigen. (siehe Abb. 16.5). In der Folge werden im 4D-Modell für eine gewisse Zeit die
Stützen und die darüber liegende Decke gleichzeitig als im Bau befindlich visualisiert.
Dieses ist verwirrend und verhindert eine Plausibilitätsprüfung. Teilt man die Vorgänge
jedoch in die einzelnen Betonierabschnitte der Decke sowie in für den Deckenabschnitten
entsprechende Gruppen von darunter liegenden Stützen auf, so ergibt sich eine realitäts-
nahe Visualisierung des Bauablaufs, in dem jeweils zunächst die Stützen fertiggestellt
werden, bevor die darauf aufliegende Decke erstellt wird.
Um eine adäquate Visualisierung zu erreichen, ist es somit erforderlich, dass die Gra-
nularität von 3D-Objekten und Terminplanvorgängen ausreichend fein und mit einander
kompatibel sind. Dies führt oftmals zur Notwendigkeit, die Granularität des 3D-Modells
nachträglich an die des Terminplans anzupassen. Beispielsweise repräsentiert das 3D-
Modell einer Deckenplatte üblicherweise noch nicht die erst nachträglich während der
16 BIM zur Unterstützung der ingenieurtechnischen Planung 279
Innerhalb einer Planungsbesprechung bietet es sich an, das 4D-Modell nicht nur zur
Visualisierung des ursprünglich geplanten Bauablaufs zu verwenden, sondern inter-
280 J. Tulke
Trotz der genannten Schwierigkeiten kann bei geschickter, koordinierter Erstellung und
bedachtem Einsatz von 4D-Modellen mit vertretbarem Aufwand ein erheblicher Mehr-
wert bei der gemeinsamen Erarbeitung des Detailbauablaufs und dessen Kommunikation
geleistet werden sowie folgenschwere Fehler frühzeitig erkannt und vermieden werden.
Gerade bei größeren oder komplexen Projekten kann daher eine regelmäßige Nutzung
von 4D-Modellen ausdrücklich empfohlen werden. Eine adäquate Einbettung in die Pro-
zessabläufe zur Modell- und Terminplanerstellung sowie zur Nutzung in Besprechungen
und Workshops ist jedoch zu beachten.
16 BIM zur Unterstützung der ingenieurtechnischen Planung 281
Der Begriff Model Checking oder Code Checking meint die automatisierte, regelbasierte
Überprüfung des Modells. Dabei werden Geometrie, Semantik und verknüpfte Informa-
tionen des Modells ausgewertet, um die Einhaltung bestimmter Planungsprinzipien, Kun-
denanforderungen oder baurechtlicher Regelungen (Codes) zu überprüfen. Kernstück ist
dabei die Formulierung der zu überprüfenden Regeln in computerinterpretierbarer Form.
Um diese Regeln nicht für jedes Modell neu anpassen zu müssen, sondern wiederver-
wenden zu können, ist ein standardisiertes, stets gleich strukturiertes Datenmodell er-
forderlich, welches das automatisierte Auffinden der benötigten Modellinformationen an
standardisierter Stelle ermöglicht. Das Einsatzgebiet für das Model Checking ist viel-
fältig. Hierzu gehören beispielsweise das Überprüfen landesspezifischer, baurechtlicher
Regelungen im Rahmen der Baugenehmigung, das Auswerten von Anforderungen und
Entwurfscharakteristiken im Rahmen von Architekturwettbewerben sowie die Steuerung
einer sinnvoll anwachsenden Detailtiefe des Modells beim Übergang zwischen den Pla-
nungsphasen.
Für die Anwendung einer automatisierten Überprüfung der Planung sind somit einer-
seits standardisierte und mit vielfältigen Informationen versehene Bauteilbeschreibungen
und andererseits computerinterpretierbare Regelsätze erforderlich. Aufgrund der Vielzahl
von Bauteiltypen und zugehörigen Informationen sowie spezifischen Regelungen und An-
forderung ergibt sich ein hoher Komplexitätsgrad und Erstellungsaufwand. Daher ist eine
Bereitstellung in Form von Bibliotheken wünschenswert. So gibt es bereits verschiedene
Bauteilhersteller und spezialisierte IT-Anbieter, die 3D-Objektbibliotheken von Bauteilen
bereitstellen. Dieses dient nicht nur der automatisierten Modellprüfung, sondern auch der
Informationsbereitstellung für Beschaffung und Betrieb. Auf der anderen Seite könnten
Prüfregeln zukünftig beispielsweise von Bauämtern oder institutionellen Bauherren be-
reitgestellt und auch intern selbst zur Prüfung verwendet werden. Die Verwendung der
gleichen Prüfregeln seitens Bauherren, Behörden, Planern und Generalunternehmen er-
möglicht die kontinuierliche Sicherstellung der Konformitätsüberprüfung über die ganze
Planungsphase hinweg.
Heutzutage stellt die Verwendung unterschiedlicher Datenformate sowie die nicht stan-
dardisierte Informationstiefe der Modelle auf der einen Seite sowie begrenzt verfügbare
Prüfsoftware mit einfach, aber flexibel definierbaren Prüfregeln für komplexe Sachverhal-
te auf der anderen Seite die Haupthindernisse dar. Für vorab im Projekt genau definierte
Anwendungsfälle und unter der Voraussetzung entsprechender Modellierungsvorgaben
können bereits heute einzelne, für das Projekt wesentliche Entwurfskriterien sowie die
einheitliche Modellstruktur schnell, zuverlässig und objektiv ausgewertet werden. Der
Entwurfsprozess wird damit transparenter und die Einhaltung von Vorgaben konsequent
verfolgt. Für weiterführende Informationen zum Thema der automatisierten, inhaltlichen
Modellprüfung sei der interessierte Leser auf das Kap. 20 verwiesen.
282 J. Tulke
16.5 Fazit
Für die Koordination der Planung zwischen verschiedenen Fachdisziplinen unter Einbe-
ziehung von Aspekten der Bauausführung und des Betriebs ist das schnellere, präzisere
und umfänglichere Verständnis sowie die Kommunikation des geplanten Bauwerks zu-
nächst der offensichtlichste Vorteil einer BIM-Nutzung. Dies liegt an der vollständigen,
realistischen und interaktiven 3D-Visualisierung. Die Konzepte der Clash Detection, der
4D-Bauablaufanimation und des Model Checkings nutzen das Modell und die inhärenten
Informationen zusätzlich, um vorhandene Planungsfehler automatisiert aufzudecken bzw.
um die Vorteile der Visualisierung in gleicher Weise auch auf den Bauablauf bzw. die Bau-
stellenlogistik auszuweiten. Hierdurch kann erheblicher Mehrwert im Sinne der frühzeiti-
gen Fehlervermeidung und der verbesserten Planung von Bauwerk und dessen Erstellung
erzielt werden. Zu beachten ist allerdings eine adäquate Einbettung dieser Methoden in die
Planungs- und Koordinierungsprozesse sowie die Sicherstellung der erforderlichen Struk-
tur der Modelldaten. Grundsätzlich kann gesagt werden, dass, je mehr Inhalt und Struktur
der Modelldaten mit Bedacht auf die Nutzungsszenarien projektweit über verschiedene
Autoren hinweg standardisiert werden, desto mehr können Planungs- und Koordinierungs-
prozesse automatisiert sowie Daten übergreifend ausgewertet werden. Dieses wird sich
in Zukunft noch zunehmend auf die mit dem 3D-Modell verknüpften alphanumerischen
Daten verschiedener Fachdisziplinen erstrecken und somit das Gesamtverständnis von ge-
plantem Bauwerk, Bauprozessen und den damit verbundenen räumlichen und zeitlichen
Abhängigkeiten weiter vertiefen.
Die Gestaltung der entsprechenden Prozesse sowie die Festlegung von Inhalt und
Struktur der benötigten Modelldaten erfordern jedoch gewisse praktische Erfahrung so-
wie planungs- und informationstechnisches Wissen. Das Involvieren eines BIM-Managers
(siehe Kap. 13) für das Aufsetzen und die Begleitung der BIM-basierten Planungskoordi-
nation kann daher nur dringlich empfohlen werden, um Zusatzaufwand ohne Realisierung
des erwarteten Nutzens zu vermeiden.
Zusätzlich sei ausdrücklich darauf hingewiesen, dass die aufgezeigten Möglichkeiten
lediglich eine Unterstützung der ingenieurtechnischen Planung bzw. deren Koordination
in Teilbereichen darstellen. Eine Vollständigkeit in allen technischen Aspekten ist nicht
gegeben. Ebenso verbleibt die Verantwortung weiterhin bei den jeweiligen Fachplanern
und wird nicht an Automatisierungswerkzeuge abgetreten.
BIM für die Tragwerksplanung
Thomas Fink
17
Zusammenfassung
Das Kapitel beschreibt die Anwendung von BIM in der Tragwerksplanung. Der Un-
terschied zwischen geometrischem und analytischem Modell wird beschrieben. Aus-
führlich wird auf die Anwendung der Methode in den verschiedenen Planungsphasen,
vornehmlich Vorplanung, Genehmigungsplanung und Ausführungsplanung eingegan-
gen. Letztlich werden mögliche Entwicklungen in der Zukunft diskutiert.
17.1 Einführung
In diesem Kapitel soll dargestellt werden, wie durch konsequente Anwendung der BIM-
Philosophie in der Tragwerksplanung Informationsverluste vermieden und Qualitätsstei-
gerungen erzielt werden können. Hierfür hat sich der Fachbegriff „little bim“ eingebürgert.
Werden jedoch die Methoden und Werkzeuge hierfür konsequent und auch mit Blick über
den Tellerrand zu anderen an der Planung und Ausführung Beteiligten eingesetzt, so un-
terscheidet sich das „little bim“ nur wenig vom „BIG BIM“, bei dem alle Beteiligten mit
einem gemeinsamen Datenmodell für die verschiedenen Gewerke arbeiten können (siehe
auch Kap. 1).
Derzeit befindet sich Deutschland in der Phase des Lernens und auch in einer Phase
des Vervollständigens und Perfektionierens der eingesetzten BIM-Werkzeuge. So wie es
vor einer Orchesterprobe sehr sinnvoll ist, dass jedes Instrument seine Noten fehlerfrei
spielen kann, so muss erst einmal jeder Beteiligte seinen Prozess bürointern beherrschen,
bevor alle in den Orchestergraben steigen.
Die nachfolgenden Ausführungen beschränken sich beispielhaft auf den Massivbau,
sind jedoch für alle Disziplinen analog anwendbar.
Thomas Fink
SOFiSTiK AG, Bruckmannring 38, 85764 Oberschleißheim, Deutschland
e-mail: Thomas.Fink@sofistik.de
Für die Tragwerksplanung werden zwei unterschiedliche Modelle benötigt, die jedoch
miteinander in Bezug stehen. Dies kann entweder in einer gemeinsamen Datenbank reali-
siert werden oder die korrespondierenden Elemente müssen aufeinander referenziert sein.
Das geometrische Modell beinhaltet die exakte Geometrie jedes einzelnen Bauteils,
repräsentiert also die Schalung. Ein Unterzug besteht aus einem dreidimensionalen Volu-
menkörper mit Typ, Dicke, Material und weiteren Eigenschaften, den ein BIM-Programm
relativ einfach und sicher in Ansicht, Schnitt oder Perspektive darstellen kann. Das analy-
tische Modell repräsentiert ein geometrisch vereinfachtes (häufig dimensionsreduziertes)
Modell des Bauteils, das die Grundlage für die Berechnung von Spannungen und Verfor-
mungen mithilfe entsprechender mechanischer Modelle bietet. Ein Unterzug besteht aus
einer Systemlinie, einem Querschnitt, Randbedingungen und Belastungen (Abb. 17.1).
Sämtliche Berechnungsergebnisse beziehen sich auf das analytische Modell, daher ist es
für die spätere Konstruktion zwingend erforderlich, dass das analytische Modell einen
Bezug zur Geometrie hat.
Dieser Bezug ist auch mit dem analytischen View der IFC (siehe Kap. 7) darstellbar.
Es ist vorgesehen, dass ein analytisches Modell sowohl unabhängig von der Geometrie als
auch in sie eingebettet definiert werden kann.
Die verschiedenen Phasen der Planung mit BIM (Abb. 17.2) unterscheiden sich nicht vom
herkömmlichen Prozess, außer dass am Anfang immer eine Modellierung stehen muss.
Dieses Modell wird im Laufe der Zeit verfeinert und mit diesem Modell können dann bau-
technische Nachweise, die Ausführungs- und Abrechnungsunterlagen angefertigt werden.
17 BIM für die Tragwerksplanung 285
Vo
rbe
mes
sung
100%
DURCHGÄNGIGER
BIM-WORKFLOW IN
Bewe
DER BAUPLANUNG
g
nun
hru
ng
pla
sp
ns
lan
io
sit
un
Po
g
Sc
ha
lpl tik
anu Sta
ng ig e
Prüffäh
Für die Vorplanung und die Entwurfsplanung muss das analytische Modell aus dem geo-
metrischen Modell abgeleitet werden. Wurde in der Vergangenheit hierfür ein Architek-
tenplan in ein CAD-Programm eingespielt und auf dieser Basis die Systemlinien der
tragenden Bauteile eingegeben, so bieten die handelsüblichen BIM-Programme hier einen
größeren Komfort. Für Standardbauteile wie Wände, Decken, Stützen oder Balken kann
das analytische Modell automatisch generiert werden, je nach Benutzerdefinition erfolgt
eine Verschneidung der Systemlinien. Wesentlich für diesen Prozess ist, dass der Benutzer
möglichst volle Eingriffsmöglichkeiten hat und das vom Programm erzeugte System nach
seinen Vorstellungen anpassen kann, ohne dabei das geometrische Modell zu verändern.
Für die Ermittlung der Schnittgrößen und eine spätere Bemessung müssen weitere Ein-
gaben wie Lasten, Lastfälle, Einwirkungen und Auflagerbedingungen definiert werden.
Hier unterscheiden sich die am Markt verfügbaren Programmsysteme. So ist es unter
anderem mit Autodesk Revit möglich, diese zusätzlichen Angaben bereits in der BIM-
Software zu tätigen, was den Vorteil mit sich bringt, dass Änderungen an der Geometrie
automatisch in das analytische System übergeführt werden. Andere Programmanbieter
haben den Weg gewählt, aus dem BIM-Programm nur die Geometrie zu übernehmen um
dann das analytische Modell im Statikprogramm zu komplettieren. In beiden Fällen er-
hält man sehr schnell erste Berechnungsergebnisse (Abb. 17.3) und damit ein sehr gutes
Gefühl für das Tragverhalten im jeweiligen Planungsstand.
286 T. Fink
17.3.2 Genehmigungsplanung
Decken werden normalerweise als ebene Platte nachgewiesen. Es können mit den vor-
handenen Daten aus dem Gesamtsystem nicht nur starre oder elastische Auflager aus
Abb. 17.4 Statisches System eines Bürogebäudes und daraus abgeleitetes Finite Elemente Netz
17 BIM für die Tragwerksplanung 287
Abb. 17.5 Aus dem Gesamtsystem herausgelöste Geschoßdecke als 2D-System mit analytischem
Modell (a) und Ergebnissen (b)
Positionspläne können problemlos aus der Geometrie abgeleitet und beschriftet wer-
den.
17.3.3 Ausführungsplanung
Schalpläne
Ansichten, Schnitte und 3D-Ansichten können aus dem geometrischen Datenmodell von
einem Computerprogramm relativ einfach errechnet werden. Der Benutzer muss sich vor-
ab nur noch Gedanken machen, welche Sichten wie auf einem Plan dargestellt werden
sollen und diese mit Maßlinien und Beschriftungen ergänzen.
Ein wesentlicher Vorteil der Methode besteht darin, dass unabhängig davon, was im
Modell geändert wurde, die Pläne immer diesen Planungsstand wiedergeben.
288 T. Fink
Abb. 17.6 Erforderliche Bewehrung einer Decke und daraus automatisch generierte Bewehrungs-
führung
Bewehrungsmodell
Die herkömmliche Arbeitsweise bestand darin, in bereinigten Schalplänen, sogenannten
Bewehrungsrohlingen, die aus den Schalplänen abgeleitet wurden, symbolisch die einzu-
legende Bewehrung nach Position, Biegeform, Abmessungen und Stückzahl einzulegen.
Hierbei wurde jedes Eisen meist mehrfach dargestellt, durfte aber für die Stahlliste nur
einmal gezählt werden. Das Erstellen einer Stahlliste war vor Einführung von CAD ein
zeitraubender Prozess, potenzielle Fehlerquellen gab es auch danach genug. Im BIM-
Prozess wird jedes Eisen in das dreidimensionale Bauwerksmodell nur einmal eingelegt,
was Fehlerquellen enorm reduziert. Dies kann manuell durch den Benutzer passieren oder
mithilfe spezieller Software. Dadurch, dass die auf das analytische Modell bezogenen Be-
messungsergebnisse und die exakte Geometrie vorliegen, sind neuere Programme auch in
der Lage, für die statisch erforderliche Bewehrung weitgehend selbstständig Vorschläge
zu machen (Abb. 17.6).
Darüber hinaus ist es auch möglich den vorhandenen Bewehrungsgehalt grafisch mit
der statisch erforderlichen Bewehrung aus der Bemessung zu vergleichen und somit über-
bzw. unterbewehrte Bereiche zu visualisieren (Abb. 17.7).
17 BIM für die Tragwerksplanung 289
Abb. 17.7 Grafischer Vergleich zwischen erforderlicher Bewehrung (rot) und vorhandener Beweh-
rung (blau)
Bewehrungspläne
Im Gegensatz zum Bauteil selbst stellen Bewehrungspläne die Eisen nur symbolisch dar.
Eine 3D-Darstellung der Bewehrung ist zwar – speziell in Details – schön anzusehen,
hilft aber auf der Baustelle nur bedingt weiter. Auch auf einem Schnitt will man nicht
alle Bewehrungseisen sehen, die auf einem physikalischen Schnitt des Modells zu sehen
wären.
Eine wesentliche Herausforderung bei der Einführung von BIM in der Bewehrungs-
planung war es, aus dem Bewehrungsmodell Pläne zu erzeugen, die so aussehen wie es
die Beteiligten gewohnt waren (Abb. 17.8). Es dürfen nicht alle Eisen dargestellt werden
und in Mitteleuropa und vielen anderen Regionen ist es üblich, die beschriftete Biegeform
außerhalb der Schalung nochmals dazustellen.
Die Bauplanung mit BIM-Methoden und -Werkzeugen ist mittlerweile für weite Bereiche
des Bauwesens möglich. Die am Markt vorhandenen Programme sind einsatzfähig und
werden mit der zu erwartenden Zunahme der Anwender auch manche noch vorhandene
Kinderkrankheit ablegen.
Eine Umstellung erfordert möglicherweise Investitionen in Software, vor allem aber in
die Ausbildung der Beteiligten. Damit kann sich Firmen aber Wettbewerbsvorteile erar-
beiten. Die wesentlichen Vorteile einer BIM-gestützten Tragwerksplanung sind:
290 T. Fink
Zeitersparnis, da die Geometrie nicht mehr für jede Berechnung neu erfasst werden
muss,
geringere Fehlerquote, die Modelle sind konsistent zueinander,
bessere Abstimmung mit den anderen Planungsbeteiligten.
Wenn ein digitales Bauwerksmodell erst einmal vorhanden ist, ergeben sich viele neue
Möglichkeiten, es für andere Zwecke zu verwenden. So können Computerprogramme
relativ leicht Kollisionen zwischen verschiedenen Bauteilen feststellen. Es ist ausgespro-
chen sinnvoll, Kollisionen zwischen Bewehrungseisen und Elementen der Haustechnik
frühzeitig zu erkennen, man muss allerdings aufpassen, sich nicht Probleme zu schaffen,
die man früher nicht hatte. Jedes Mattenfeld mit ebenen Matten ergäbe mathematisch ei-
ne Kollision bei jeder Übergreifung. Um dies zu vermeiden müsste jede Matte gekröpft
werden, was in der Praxis sicher nicht erforderlich ist.
Ein weiterer Gedanke wäre, die Zusammenbaubarkeit von Bewehrungen vom Compu-
ter überprüfen zu lassen.
Anstatt aufwendig 2D-Pläne aus dem 3D-Modell abzuleiten, ist es auch möglich ein
3D-PDF zu erzeugen. Hier kann der Betrachter nicht nur die Blickrichtung frei wählen
und die Sichtbarkeit einzelner Elemente steuern, es können auch Informationen über die
einzelnen Bewehrungspositionen abgerufen werden. Mit der Möglichkeit, mithilfe von
BIM-Software Objekte zur besseren Darstellung aus dem Bauteil herauszuziehen und da-
mit die aus dem Maschinenbau bekannten Explosionszeichnungen wie in Abb. 17.9 zu
erzeugen, ergeben sich ganz neue Möglichkeiten für die Informationsübermittlung an die
Baustelle. So erscheint es möglich, Zusammenbauanleitungen als 3D-PDF auf Tablets
oder besser noch mit Datenbrillen auf die Baustelle zu bringen.
17 BIM für die Tragwerksplanung 291
Zusammenfassung
Das Kapitel setzt BIM in den Kontext der Energiebedarfsermittlung und der Gebäu-
desimulation. Es werden zunächst die verschiedenen Methoden der Energiebedarfser-
mittlung und TGA Fachplanung vorgestellt und Bezug auf die entsprechenden normati-
ven Vorschriften und Berechnungsgrundlagen genommen. Es werden Datenaustausch-
formate vorgestellt, die zum Austausch und zur Modellierung von energierelevanten
Gebäude- und Anlagendaten zur Verfügung stehen, wobei auch auf notwendige Anfor-
derungen und Definitionen aus Sicht der Geometrie, Zonierung und Semantik einge-
gangen wird. Das Kapitel diskutiert kurz den Stand der softwareseitigen Unterstützung
hinsichtlich ingenieurtechnischer Berechnung und Dimensionierung. Weiterhin wird
die für den BIM-Einsatz in der Energiebedarfsermittlung und Simulation notwendige
Prozesskette vorgestellt und kurz auf entsprechende Model-View-Definitionen der In-
dustry Foundation Classes eingegangen. Ein Ausblick auf laufende Forschungs- und
Entwicklungsarbeiten rundet das Kapitel ab.
Methoden der dynamischen Gebäude- und Anlagensimulation zur Auslegung und Opti-
mierung komplexer Gebäudeenergiekonzepte ein wichtiges Werkzeug darstellen, finden
diese gegenwärtig nur bei Bedarf Anwendung bzw. beschränken sich auf Sonderfälle.
Gleichzeitig kommt dem Einsatz digitaler Planungsmethoden im Zuge der Energiewen-
de eine sehr wichtige Rolle zu, wenn das Zusammenspiel von Systemen und Komponenten
zwischen Nutzern, Gebäuden, Anlagen und Netzen auf Stadtquartiersebene betrachtet
werden soll. Ohne digitale Methoden können beispielsweise zukunftsweisende Methoden
einer modellprädiktiven Regelung oder eines bedarfsorientierten Lastmanagements nicht
umgesetzt werden.
Auf der Gebäudeebene stellt BIM eine Methode dar, umfangreiche Datenmengen für
die energetische Betrachtung zu strukturieren und bzgl. des kompletten Lebenszyklus zu
verwalten (Eastman 2011; Egger et al. 2013). Die BIM-Technologie kann hierbei künf-
tig eine Basis als Datenmodell, als Arbeitsmethode und als Werkzeug zur Erstellung und
Verwaltung des digitalen, auch „energetischen Abbildes“ eines Gebäudes darstellen. Aus
Sicht der Technischen Gebäudeausrüstung (TGA) bietet der BIM-Ansatz in der Planung,
im Anlagenbau und im Betrieb immense Vorteile. Hochwertige Datenschnittstellen er-
möglichen beispielsweise die Übernahme von Geometrie und Anlagenparametern, womit
aufwendige Neueingaben entfallen.
Für den Datenaustausch zur Energiebedarfsermittlung bzw. -simulation muss eine hinrei-
chend notwendige Datentiefe betrachtet werden. Dies betrifft in erster Linie die Definition
der Gebäudegeometrie sowie der thermischen Zonen, welche zum einen Container für
thermisch ähnliche Räume darstellen, und zum anderen entsprechende thermisch-energe-
tisch relevante Parameter wie etwa Nutzungsprofile beinhalten. Zur Abbildung der An-
lagentechnik muss ein Austauschformat Objekte zur Beschreibung der Gebäudetechnik
unterstützen, d. h. komplette Systeme, einzelne Komponenten, die Hierarchie der Kom-
ponenten, deren funktional-topologischen Zusammenhänge und Abhängigkeiten sowie
energetische Parameter bzw. Kennlinien.
Neben dem in diesem Buch bereits vorgestellten Modell der Industry Foundation Clas-
ses (IFC) ist in diesem Zusammenhang das Green Building eXtensible Markup Language
Schema (gbXML) zu nennen (Roth 2014). gbXML ist ein Datenaustauschformat, das
ursprünglich zum Datenaustausch zwischen CAD-Programmen und Energiesimulations-
tools entwickelt worden ist. Heute kann es darüber hinaus zum Datenaustausch zwischen
verschiedenen Energie-Analyse-Tools verwendet werden. Dieses XML-basierte Format
bildet größtenteils geometrische Daten, Nutzungsprofile, Wetterdaten und einige weitere
energierelevante Daten ab, vernachlässigt jedoch einzelne Parameter, die für die Kompo-
nenten der Gebäudetechnik relevant sind (Dong et al. 2007).
Ein weiteres Austauschformat für die Energiebedarfsermittlung und -simulation ist
das ebenfalls XML-basierte Simulation Domain Model: SimModel oder SimXML
(O’Donnell et al. 2011). Dieses Format bildet die Daten unterschiedlicher Formate ab
und beinhaltet u. a. IFC- und gbXML-Repräsentationen. Dadurch eignet es sich als um-
fangreicher Datencontainer für die Simulation der Anlagentechnik. Das Format wurde
für den Austausch von Daten zwischen dem Simulationskern EnergyPlus (DOE 2014)
und BIM-Werkzeugen entwickelt und definiert eine Datenstruktur für gebäudetechnische
Komponenten und Nutzerprofile (O’Donnell et al. 2011).
Gegenwärtig befindet sich im Richtlinienausschuss des Vereins Deutscher Ingenieure
(VDI) ein Austauschformat zur Abbildung von gebäudetechnischen Daten in Entwick-
lung. Dieses Format entsteht aus der VDI Richtlinie 3805 (VDI 3805-1) und befindet sich
zurzeit in Überarbeitung als internationale Richtlinie ISO 16757. Das Format soll Herstel-
lern von gebäudetechnischen Komponenten eine einheitliche Vorlage zur Repräsentation
296 C. van Treeck et al.
Grundsätzlich stellt ein Raum ein zentrales Objekt der Energieberechnung dar. Mit ei-
nem Raum sind Gebäudeelemente anhand von thermischen Begrenzungsflächen verknüpft
(van Treeck und Rank 2007). Thermische Begrenzungsflächen können auf unterschiedli-
che Art und Weise berechnet werden. In einer detaillierten Vorgehensweise im Zuge der
Erstellung eines zonalen Modells werden diese Flächen als Schnittstelle der tatsächlichen
Innenflächen der Bauelemente mit dem Volumen des Raumes definiert und als Space
Boundaries (SB) bezeichnet. Für interne Bauelemente werden auch gegenüberliegende
Räume berücksichtigt. Solche Flächen, die zur Berechnung der Wärmeübertragung durch
Transmission zwischen zwei Räumen definiert werden, werden „2nd Level SB“ genannt
(Rose und Bazjanac 2013). 2nd Level SB entstehen aus sogenannten 1st Level SB, indem
im unten dargestellten Fall die gemeinsame Wand zwischen dem beheizten Raum und den
Nachbarräumen in zwei 2nd Level SB sowie eine weitere Restfläche unterteilt werden.
Mit diesen Definitionen können Transmissionswärmeströme über flächige Bauteile (Wär-
mestrom in eine Richtung) und Wärmebrückeneinflüsse eindeutig und unabhängig von
einer ggf. anderen Darstellung im Architektur- oder Statik-/Strukturmodell charakterisiert
werden. Für die Definition von Space Boundary Level wird auf Rose und Bazjanac (2013)
und van Treeck und Rank (2007) verwiesen.
Berechnungen, die auf der DIN V 18599 basieren (EnEV), verwenden eine ähnliche,
jedoch in der Regel vereinfachte Definition von Flächen, basierend auf Außenflächen und
gemittelten Flächen. Abbildung 18.1 veranschaulicht diese Unterschiede.
Neben der geometrischen Beschreibung sind zudem physikalische Parameter der
Wandaufbauten für die Energieberechnung notwendig. Wandaufbauten und Material-
schichten werden Bauelementen zugeordnet und notwendige physikalische Parameter
(z. B. Dichte, Wärmeleitfähigkeit, etc.) werden für einzelne Materialschichten definiert.
Thermisch ähnliche Räume werden zu Zonen zusammengefasst, um die Dateneingabe
zu vereinfachen. Für detaillierte Modelle kann dies raumweise erfolgen. Zusätzlich sind
Daten zu internen Lasten sowie zu Nutzungs- und Anlagenprofilen erforderlich. Zur Ener-
giebedarfsermittlung sind außer Standort- und Wetterdaten weitere Informationen über
die Anlagentechnik und deren Regelung erforderlich.
18 BIM für die Energiebedarfsermittlung und Gebäudesimulation 297
Für den Einsatz der BIM-Methode zur Energiebedarfsberechnung oder -simulation sind
mehrere Schritte erforderlich: Nach der Modellerstellung folgt der Datenexport, die Mo-
dellverifikation, die Modellkonvertierung, die Datenanreicherung, anschließend die Be-
rechnung bzw. Simulation, dann die Auswertung und zuletzt eine optionale Datenrück-
führung.
Angefangen mit der Modellierung der Gebäudehülle in einem BIM-System werden
diese Daten exportiert. Typischerweise wird das Produktmodell anschließend auf Fehler
überprüft. Diese Fehlerüberprüfung ist notwendig, da die Berechnung von Begrenzungs-
18 BIM für die Energiebedarfsermittlung und Gebäudesimulation 299
BIM
gbXML
IFC 2x3
Geometriedaten Geometriedaten
(Coordinaon View)
Energiebedarfs-
berechnung
flächen stark von der Qualität des Geometriemodells abhängt. Richtlinien zur Model-
lierung von BIMs für Energiesimulationen sind beispielsweise in (Maile et al. 2013)
dargestellt. Abbildung 18.2 fasst die Methodik des Datenaustauschs exemplarisch für die
beiden Datenformate IFC und gbXML zusammen. Zur Energiebedarfsberechnung werden
bisher in der Regel ausschließlich Geometriedaten verwendet; für die dynamische Gebäu-
desimulation sind zusätzliche Daten zur Beschreibung von thermischen Parametern von
Räumen, Zonen und weiteren Systemparametern (Anlagen) möglich bzw. notwendig.
Im gbXML-Format werden in erster Linie Geometriedaten transportiert. Zusätzlich
können thermische Raumdaten, beispielsweise interne Lasten, falls softwareseitig unter-
stützt, ausgetauscht werden. Für das IFC-Modell werden die auszutauschenden Geome-
triedaten in der Model View Definition (MVD) „Coordination View 2.0“ genauer definiert
(vgl. Kap. 7). Typischerweise berechnen Energiebedarfsprogramme die Begrenzungsflä-
chen selbst, da sie auf einer einfacheren Definition und damit Berechnung beruhen (siehe
Abb. 18.1). Für Simulationsprogramme können diese Begrenzungsflächen im IFC-Da-
tenmodel hinterlegt werden. Diese Begrenzungsflächen sind in dem sogenannten „Space
Boundary Add On“ View (buildingSMART 2010) geregelt.
Neben der rein geometrischen Beschreibung sind zudem physikalische Parameter der
Bauelemente für die Energieberechnung erforderlich. Diese wurden erstmals in der „BSA-
002“ MVD (OGC and buildingSMART 2009) definiert und innerhalb eines Forschungs-
projektes verfeinert (CDB 2010). Für thermische Berechnungen sind zudem thermische
Zonen notwendig. Falls die BIM-Applikation diese MVD unterstützt, können physikali-
300 C. van Treeck et al.
sche Materialparameter und interne Lasten somit im ersten Schritt bereits definiert wer-
den; anderenfalls müssen diese Daten vor der Konvertierung dem Datenmodell hinzuge-
fügt werden (CDB 2010).
Sind alle weiterhin notwendigen Daten vorhanden, können die Berechnung oder Simu-
lation durchgeführt und die Ergebnisse energetisch bewertet werden. Im Weiteren ist es
möglich, Ergebnisdaten teilweise in das Datenmodell zurückzuführen. Dies ist anschau-
lich nur für eine geringe Anzahl von Parametern sinnvoll, beispielsweise hinsichtlich
Volumenströmen, der berechneten Heiz- oder Kühllast auf Raum- oder Zonenebene. Ei-
ne Alternative bietet im IFC Datenmodell die externe Referenzierung von Ergebnissen.
Auch gbXML unterstützt die Speicherung von Ergebnisdaten sowie grundlegende Details
zu Komponenten und Systemen.
18.5 Ausblick
Zusammenfassend bietet die BIM-Technologie auch aus Sicht der TGA in der Planung,
im Anlagenbau und im Betrieb immense Vorteile. Die BIM-Technologie wird gegenwärtig
jedoch nur von einem kleinen Teil der am Markt etablierten TGA/EnEV Berechnungspro-
gramme unterstützt. Meist beschränkt sich die Unterstützung zudem auf den geometri-
schen Aspekt. Zudem weist der verfügbare Entwicklungsstand eine hohe Fehleranfällig-
keit und Interpretationsprobleme auf (Kaiser und Linsert 2013). Dies macht es bislang
erforderlich, Modelle zu überprüfen und umfangreiche manuelle Korrekturen vorzuneh-
men. Einzelne Softwaresysteme für die dynamische Gebäudesimulation unterstützen den
Datenimport von IFC-Modellen, jedoch auch Gebäudesimulationsapplikationen zeigen in
diesem Zusammenhang noch Verbesserungspotenzial.
Neben der anwendungsseitigen Unterstützung sind auch fehlerhafte bzw. unterschiedli-
che Exportfunktionen und -ergebnisse von unterschiedlichen BIM-Applikationen zu nen-
nen. Daneben steht ein herstellerbedingtes Interesse, proprietäre Formate zu unterstützen.
Für die erfolgreiche Etablierung des digitalen Austauschs von Produktmodelldaten für die
energetische Bedarfsberechnung bzw. Simulation sind entsprechende Anforderungen an
die Qualitätssicherung beim Export, Import und bei der Datenmodellierung zu stellen.
Im Kontext der IFC sind sogenannte „Model View“ Definitionen (MVDs) ein Mecha-
nismus zur Definition von Objekten und Parametern in einem spezifischen Anwendungs-
fall. Falls beide Applikationen import- und exportseitig eine MVD unterstützen, ist für
einen Anwender ersichtlich, dass diese Daten übertragbar sind. Während dieser Mecha-
nismus noch von mehr Softwareapplikationen unterstützt werden muss, gibt es bei anderen
Datenmodellen wie gbXML keine vergleichbaren Ansätze.
Gegenwärtig widmen sich mehrere internationale Forschungsprojekte der Thematik,
Datenrepräsentationsschemata aus energetischer Sicht zu definieren und zu vereinheitli-
chen. Die bereits erwähnten MVDs (BSA-002 und GSA-005) definieren im Wesentlichen
Daten auf der Raum- bzw. Zonenebene. Das europäisch geförderte HESMOS-Projekt
(Liebich et al. 2011) definiert Parameter auf der Systemebene, wobei Details auf der
18 BIM für die Energiebedarfsermittlung und Gebäudesimulation 301
Literatur
buildingSMART (2010): IFC2x3 space boundary implementation guide summary. URL http://
www.buildingsmart-tech.org/downloads/accompanying-documents/agreements/IFC2x3-
space-boundary-implSummary-2010-03-22.pdf/at_download/file –
Überprüfungsdatum 2014-08-22
buildingSMART (2014): Industrial Foundation Class IFC4: Official Release. URL http://www.
buildingsmart-tech.org/ifc/IFC4/final/html/index.htm – Überprüfungsdatum 2014-08-22
Cao J., Maile T., O’Donnell J., Wimmer R., van Treeck C. (2014): Model Transformation from Sim-
Model to Modelica for Building Energy Performance Simulation. In: Proc. BauSIM2014, 5th
IBPSA-Germany Conference, September 22–24, Aachen, Germany. ISBN 978-3-00-047160-5,
2014
CDB (2010): Concept Design BIM 2010. URL: http://www.blis-project.org/IAI-MVD/MVDs/
GSA-005/Overview.pdf – Überprüfungsdatum 2014-08-01
DIN 18017 Teil 3 (2009): Lüftung von Bädern und Toilettenräumen ohne Außenfenster – Teil 3:
Lüftung mit Ventilatoren. Beuth Verlag
DIN 1946 Teil 6 (2009): Raumlufttechnik – Teil 6: Lüftung von Wohnungen – Allgemeine Anforde-
rungen, Anforderungen zur Bemessung, Ausführung und Kennzeichnung, Übergabe/Übernahme
(Abnahme) und Instandhaltung. Beuth Verlag
DIN 1986 Teil 100 (2008): Entwässerungsanlagen für Gebäude und Grundstücke – Teil 100: Be-
stimmungen in Verbindung mit DIN EN 752 und DIN EN 12056. Beuth Verlag
DIN 1988 Teil 300 (2012): Technische Regeln für Trinkwasser-Installationen – Teil 300: Ermittlung
der Rohrdurchmesser; Technische Regel des DVGW. Beuth Verlag
DIN 4108 (2011):Wärmeschutz im Hochbau. Beuth Verlag
DIN EN 12056 (2001): Schwerkraftentwässerungsanlagen innerhalb von Gebäuden. Beuth Verlag
DIN EN 12831 (2003): Verfahren zur Berechnung der Norm-Heizlast. Beuth Verlag
DIN EN 752 (2008): Entwässerungssysteme außerhalb von Gebäuden; Deutsche Fassung EN
752:2008. Beuth Verlag
DIN V 4701 (2003): Energetische Bewertung heiz- und raumlufttechnischer Anlagen. Beuth Verlag
DIN V 18599 (2013): Energetische Bewertung von Gebäuden – Berechnung des Nutz-, End-
und Primärenergiebedarfs für Heizung, Kühlung, Lüftung, Trinkwarmwasser und Beleuchtung.
Beuth Verlag
302 C. van Treeck et al.
VDI 2078 (2012): Berechnung der Kühllast und Raumtemperaturen von Räumen und Gebäuden
(VDI-Kühllastregeln). VDI Richtlinie, Verein Deutscher Ingenieure, Düsseldorf
VDI 3805 Blatt 1 (2011): Produktdatenaustausch in der Technischen Gebäudeausrüstung, Grund-
lagen. VDI Richtlinie, Verein Deutscher Ingenieure, Düsseldorf
VDI 6007 (2012): Berechnung des instationären thermischen Verhaltens von Räumen und Gebäu-
den. VDI Richtlinie, Verein Deutscher Ingenieure, Düsseldorf
VDI 6030 (2002): Planung und Bemessung von Raumheiz- und Kühlflächen. VDI Richtlinie, Verein
Deutscher Ingenieure, Düsseldorf
Wimmer R., Maile T., O’Donnell J., Cao J., van Treeck C. (2014): Data-requirements specification
to support BIM-based HVAC-definitions in Modelica. In: Proc. BauSIM2014, 5th IBPSA-
Germany Conference, September 22–24, Aachen, Germany. ISBN 978-3-00-047160-5, 2014
BIM im präventiven Arbeits- und
Gesundheitsschutz 19
Jochen Teizer und Jürgen Melzner
Zusammenfassung
BIM findet im Hinblick auf den Arbeits- und Gesundheitsschutz in vielen Ländern noch
keine flächendeckende Berücksichtigung. Oftmals wird in der Baupraxis ein Plan zum
Sicherheits- und Gesundheitsschutz entweder kurz vor Eintritt in die Bauphase oder
während der Bauphase erstellt. Dies ist sicherlich zu wenig, um das volle Potenzial von
BIM als Prozess und in der Modellierung abzuschöpfen. Um den Sicherheitsstandard
auf Baustellen zu verbessern, müssen bereits in den frühen Projektphasen sowohl die
Sicherheitsmaßnahmen festgelegt als auch die Sicherheitsausrüstung vorbereitet und
bereitgestellt werden. Der Informationsverlust, z. B. durch wechselnde Planer oder feh-
lende Zustimmung in der Unternehmensführung sowie im Arbeitsablauf, kann vermie-
den werden, indem ein durchgängiges Bauwerksinformationsmodell (BIM) verwendet
wird, das neben statischen und bauphysikalischen Sachverhalten auch Informationen
für die Arbeitssicherheitsplanung enthält. Mit BIM können weiterführende Daten für
den gesamten Lebenszyklus eines Bauwerks integriert werden, z. B. Identifikation,
Vermeidung und bessere Kommunikation von Sicherheitsrisiken, 4D-Visualisierung
von Arbeitsabläufen und Sicherheitstraining sowie Schulungen. Dieses Kapitel be-
legt durch Statistiken, Erläuterungen und Anwendungsbeispiele, dass BIM im Arbeits-
und Gesundheitsschutz eine verbesserte Sicherheit, Gesundheit und höhere Motivation
der Arbeitnehmer, eine Verringerung der Versicherungsprämien und Haftungsrisiken,
einen ungestörten und termingerechten Projektablauf, eine Produktivitätssteigerung,
einen Wettbewerbsvorteil durch verbesserte Reputation, eine Beachtung der Gesetze
und anderer Regularien bewirkt.
Jochen Teizer
RAPIDS Construction Safety and Technology Laboratory, 76275 Ettlingen, Deutschland
e-mail: jochen@teizer.com
Jürgen Melzner
W. Markgraf GmbH & Co KG Bauunternehmung, Dieselstraße 9, 95448 Bayreuth, Deutschland
e-mail: juergen.melzner@markgraf-bau.de
19.1 Einführung
Die Bauindustrie hat in den vergangenen 25 Jahren einen großen Wandel erlebt. Nicht
nur die Größe und die Komplexität vieler Projekte nehmen zu, auch die Methoden in der
Bauplanung und Ausführung, wie auch die Hilfsmittel, die in der Kommunikation unter
den Projektbeteiligten Verwendung finden, haben sich dramatisch verändert. Gerade die
technischen Herausforderungen und Möglichkeiten beeinflussen das moderne Arbeiten
auf der Baustelle. In immer kürzerer Zeit soll eine hohe Bauqualität unter Einsatz neuester
Technologie gewährleistet werden.
Zwar ist der Arbeits- und Gesundheitsschutz durch entsprechende Richtlinien sehr
gut definiert und als fester Bestandteil in vielen Unternehmensphilosophien von Bauun-
ternehmen verankert, jedoch fehlen Strategien und innovative technische Konzepte, um
auf das veränderte Arbeitsumfeld und die gestiegenen Arbeitsanforderungen präventiv
einzugehen. Auf den Baustellen haben sich aufgrund zunehmender Digitalisierung und
Automatisierung die Anforderungen an die Beschäftigten sehr stark verändert. Arbeits-
anweisungen stehen oftmals digital zur Verfügung und werden zur direkten Steuerung
von Personen und Maschinen verwendet. Allerdings spielt der Arbeits- und Gesundheits-
schutz darin nur eine sehr kleine Rolle. Auch ist ein zunehmender Zeit- und Qualitätsdruck
zu erkennen, welcher sich wiederum direkt auf das Arbeitsumfeld auswirkt. Durch eine
immer schnellere und notwendige Anpassung der Arbeitsvorbereitung in der Bauausfüh-
rungsplanung werden Gesundheitsgefährdungen im Arbeitsbereich nicht immer erkannt
und vermieden. Dadurch steigen wiederum die Unfallgefahr und die langfristigen Aus-
wirkungen der zu hohen oder schädlichen körperlichen Beanspruchung von Arbeitern auf
Baustellen (Garrett und Teizer 2009).
Neue Technologien wie z. B. Building Information Modeling (BIM) und Sensoren er-
möglichen den Projektbeteiligten, integrierte Arbeitsschutzprogramme zu verwirklichen,
die den Bedürfnissen einer wettbewerbsintensiven Bauindustrie entsprechen (Zhang et al.
2013). Hierbei ist es besonders wichtig, dass der Arbeits- und Gesundheitsschutz noch
detaillierter und umfassender in der Planung im Sinne des „Prevention through Design“
verankert wird. Weil der moderne Arbeitsschutz integraler Bestandteil der Bauprozesse
geworden ist, wirken sich die Vorteile solcher Programme damit auch finanziell auf das
Unternehmensergebnis aus.
Ergebnisse einer Umfrage unter 263 planungs- und bauausführenden Unternehmen in den
USA verdeutlichen die positiven Auswirkungen, die ein exzellentes Arbeitsschutzpro-
gramm auf Bauprojekte hat: geringere Anzahl von Unfällen, verbesserte Reputation und
erhöhte Rendite (McGraw Hill Construction 2013). Diese Studie zeigt auch, dass größere
Firmen generell mehr in den Arbeitsschutz investieren und dementsprechend auch mehr
davon profitieren als kleinere Unternehmen. Weiterhin sind wichtige Industrietrends, u. a.
19 BIM im präventiven Arbeits- und Gesundheitsschutz 307
Abb. 19.1 a Vorteile eines exzellenten Arbeitsschutzprogramms (in % von Firmen, die eine positive
Auswirkung melden), b Finanzielle Vorteile erreicht durch ein exzellentes Arbeitsschutzprogramm,
c Auswirkungen von BIM auf den Arbeitsschutz einer Baustelle und d Auswirkung von Vorferti-
gung und Modularisierung auf den Arbeitsschutz
die Anwendung von BIM und ein hoher Vorfertigungsgrad von Bauteilen, maßgeblich
dafür verantwortlich, dass sich der Arbeitsschutz für Unternehmen, die sich mit diesen
Entwicklungen beschäftigen, positiv verändert. Die Studie hat weitere Vorteile, die mit
der Anwendung von exzellenten Arbeitsschutzprogrammen verbunden sind, hervorgeho-
ben:
Der Arbeitsschutz gehört national und international zu den wichtigsten Aufgaben eines
Bauprojekts. Statistiken der Arbeitsunfälle zeigen, dass Arbeitnehmer auf Baustellen welt-
weit höheren Gefahren ausgesetzt sind als in anderen Industriezweigen. Auch Unfälle in
der deutschen Bauindustrie ereignen sich im Durchschnitt doppelt so häufig wie in der
übrigen deutschen Wirtschaft (DGUV 2011).
Zu den häufigsten Unfallkategorien, die schwere oder tödliche Verletzungen nach sich
ziehen, gehören u. a. Abstürze von großen Höhen (ca. 33 % aller Todesfälle), der unsi-
chere oder ungeschützte Umgang mit oder zu nahe Arbeit an Baumaschinen (ca. 25 %
aller Todesfälle), der unsachgemäße Umgang mit Baumaterialien und Geräten und der
Kontakt zu gefährlichen Substanzen (Teizer et al. 2010). Des Weiteren müssen fast 23 %
der Erwerbstätigen in der Bauindustrie bei der Arbeit häufig schwere Lasten bewegen.
Durch Krankheiten des Muskel-Skelett-Systems und Bindegewebes entstehen allein in
Deutschland ca. 16 Mrd. C Ausfall in der Bruttowertschöpfung (Arbeitsproduktivität). Pro
Jahr scheiden deswegen 26.000 Menschen aus ihrem Berufsleben aus (BG Bau 2014).
Schwere Unfälle beschränken daher nicht nur die Lebensqualität, sondern auch die Ar-
beitsproduktivität. Außerdem ist ein Mangel an qualifizierten Arbeitskräften im Bauwesen
zu erkennen, da in Deutschland nur wenige Bauarbeiter das rentenfähige Alter erreichen.
Zu den Ursachenfaktoren, die zu einer solch schlechten Unfallstatistik im Baugewerbe
beitragen, gehören u. a. die oft schwierigen Arbeitsaufgaben, das komplexe, sich ständig
verändernde Arbeitsumfeld, die Verfügbarkeit und Anwendung unterschiedlichster Ar-
beitsverfahren und -methoden, die Organisationsstruktur des Unternehmens und mensch-
liches Fehlverhalten (Hinze und Teizer 2011).
Eine Vorgehensweise, um die Unfallraten auf Baustellen zur verringern, ist, sich vor-
rangig auf die vorhandenen Hauptunfallschwerpunkte zu beschränken (Melzner et al.
2013a). Gemessen an Häufigkeit und Schwere gehören Absturzunfälle zu den bedeu-
Abb. 19.2 Meldepflichtige und tödliche Absturzunfälle auf Baustellen (Melzner et al. 2013b)
19 BIM im präventiven Arbeits- und Gesundheitsschutz 309
tendsten Unfallgruppen (Schüler et al. 2011). Die Statistik der meldepflichtigen Unfälle
zeigt einen konstant hohen Anteil an Absturzunfällen (siehe Abb. 19.2). Obwohl die Ra-
ten geringfügig gesunken sind, verunglückten im Jahr 2011 immer noch 13.088 Arbeiter
durch einen Absturz auf deutschen Baustellen. Die Anzahl der tödlichen Absturzunfäl-
le ist zwar tendenziell rückläufig, jedoch starben in 2010 insgesamt 39 Arbeiter (DGUV
2011). Vergleichbare Zahlen anderer Länder, z. B. den USA, weisen im gleichen Zeitraum
einen starken Rückgang der Unfallzahlen aus, der jedoch mehr durch konjunkturbedingte
Umstände einer verringerten Bauaktivität und weniger durch Verbesserungen im Arbeits-
schutz zu begründen ist.
Obwohl größere Firmen mit mehr als 500 Beschäftigten es generell einfacher haben,
ein Arbeitsschutzprogramm aufzubauen, geben die relativ geringen Kosten der Einfüh-
rung eines konsequenten Arbeitsschutzmanagementsystems (AMS) besonders kleinen (1–
49 Mitarbeiter) oder mittelgroßen (50–499 Mitarbeiter) Firmen die Chance, ihre Wirt-
schaftlichkeit zu verbessern. Weil große Firmen im Allgemeinen im Bereich des Ar-
beitsschutzmanagements führend sind, ist die Einführung von innovativen Methoden und
Prozessen oftmals verpflichtend, um im starken Wettbewerb bestehen zu können. Obwohl
der Grad der Anwendung eines Arbeitsschutzmanagementsystems zwischen kleinen und
großen Firmen schwankt, sind sich die Unternehmen über die Effektivität der Methoden
einig (Garrett und Teizer 2009). Die drei wichtigsten traditionellen Methoden, um den
Arbeitsschutz im Bauwesen zu gewährleisten, sind:
Mit der zunehmenden Automatisierung des Bauwesens werden auch neuartige Konzep-
te zur Planung und Umsetzung des präventiven Arbeits- und Gesundheitsschutzes auf
Baustellen entwickelt. Der Einsatz von BIM im Zusammenhang mit der Verwendung
310 J. Teizer und J. Melzner
von mobilen Endgeräten und die Ablösung von manuellen Fertigungsprozessen auf der
Baustelle durch Vorfertigung im Werk, als Beispiel, üben direkt oder indirekt einen posi-
tiven Einfluss auf den Arbeitsschutz aus. Sie erlauben eine frühe Gefahrenerkennung und
-vermeidung, noch bevor ein Projekt in die Bauphase eintritt. Durch eine automatisier-
te Identifikation und Vermeidung von Gefahrenpotenzialen auf Grundlage einer digitalen
Projektabwicklung kann die präventive Planung des Arbeits- und Gesundheitsschutzes ef-
fizienter und dynamischer gestaltet werden. Auch gewinnt der Einsatz von interaktiven
Methoden im Sicherheitstraining besonders im Bereich der personalisierten Arbeiterschu-
lung immer mehr an Bedeutung. Personalisierte Arbeits- und Gesundheitsschutzmaßnah-
men müssen in Abhängigkeit vom Arbeitsumfeld, Arbeitsaufgaben, Qualifikation und
Alter der Mitarbeiter auf Baustellen realisiert werden. Durch die Verwendung von neuen
Technologien kann die proaktive Vermeidung von Arbeitsunfällen und Gesundheitsgefah-
ren auf Baustellen stattfinden.
Obwohl viele dieser Anwendungen bislang noch keine breite Anwendung in der Bau-
industrie gefunden haben, müssen diese auf den vorhandenen Kenntnissen der am Bau
Beteiligten aufbauen. BIM als Prozess bietet unter anderem die Möglichkeit einer techno-
logischen Daten- und Kommunikationsplattform als Lösung für alle Projektbeteiligte an.
Folgende Punkte fassen die Verantwortlichkeiten und die Vorteile der Umsetzung eines
konsequenten Arbeitsschutzprogramms für die einzelnen Projektbeteiligten zusammen:
Zur Umsetzung eines integrierten Konzepts für Maßnahmen zur Förderung des präven-
tiven Arbeits- und Gesundheitsschutzes müssen Bauunternehmen, Maschinen- und Bau-
gerätehersteller, Technologieanbieter, Datenschützer und Verbände gezielt zusammenar-
19 BIM im präventiven Arbeits- und Gesundheitsschutz 311
Die Ursachen von Arbeitsunfällen und Krankheiten in der Bauindustrie sind schon seit
langem bekannt. Viele effektive Lösungen existieren, um das Niveau der Arbeitssicherheit
zu erhöhen und die Unfallzahlen zu verringern. Dennoch sind Sicherheitsexperten und
Forscher enttäuscht, weil das Ziel einer unfallfreien Baustelle bisher nicht erreicht werden
konnte. Deshalb sind neue Methoden notwendig. Building Information Modeling (BIM)
bietet eine Lösung an, diese Problematik zu beherrschen.
Der Ausdruck BIM im Arbeitsschutz wird benutzt, um zwei Dinge zu verdeutlichen:
den Prozess der Arbeits- und Gesundheitsschutzplanung, -durchführung und -überwa-
chung unter Nutzung von BIM und die Anreicherung von BIM mit arbeitsschutztech-
nischen Inhalten. Der folgende Text erläutert das Konzept von BIM mit seinen Anwen-
dungen und Vorteilen im Arbeitsschutz. Der gegenwärtige Industrietrend zur Nutzung von
BIM führt auch zur Frage, inwieweit BIM den Arbeitsschutz beeinflussen wird.
Viele Studien belegen, dass Themen des Arbeitsschutzes eng mit den Phasen eines
Bauprojekts verbunden sind (Zhang et al. 2015a). Obwohl Unfälle erst während der Bau-
oder Wartungsphasen eines Projekts auftreten, werden Entscheidungen, die die Sicherheit
der Arbeiter beeinflussen, oftmals schon in der Entwurfs- oder Planungsphase getroffen.
Die Rolle des Bauherrn als Finanzinvestor spielt dabei eine zentrale Rolle, denn dieser
legt fest, wie der Arbeitsschutz eines Projekts gestaltet wird. Da der Bauherr oftmals nicht
der spätere Nutzer des Gebäudes ist, bestimmen drei wesentliche Punkte seine Rolle im
Hinblick auf den Arbeitsschutz:
Der Einfluss des Bauherrn auf die Arbeit der Architekten und Ingenieure hat maß-
gebliche Auswirkungen darauf, wie sicher Bau- und Wartungsarbeiten später ablaufen.
Obwohl der ganzheitliche, alle Projektphasen übergreifende Arbeitsschutz das allgemein
anerkannte Ziel ist, gibt es bisher Unstimmigkeiten darüber, wie intelligente Projektinfor-
mationen unter allen Projektbeteiligten kommuniziert werden. In Abb. 19.3 ist der Lebens-
zyklus des Arbeitsschutzes in einem Projekt dargestellt. Es zeigt, wie Bauherren, Archi-
tekten und Ingenieure, Bau- und Subunternehmen sowie Facility Manager gemeinsam ein
312 J. Teizer und J. Melzner
Die Planung von sicherheitstechnischen Einrichtungen ist eine komplexe Aufgabe, bei
der viele Randbedingungen zu berücksichtigen sind. Hinzu kommt, dass jedes Bauwerk
ein Unikat darstellt und deshalb alle Planungen immer neu erstellt und auch während der
Bauphase auf neustem Stand gehalten werden müssen. Die Praxis zeigt, dass die sicher-
heitstechnischen Planungen oft von der Arbeitsvorbereitung des Bauablaufs entkoppelt
durchgeführt werden. Diese Teilung der Aufgaben verursacht sowohl technische als auch
Koordinationsrisiken. Planungs- und Koordinierungsaufgaben im Bereich der Baustellen-
sicherheit basieren auf der individuellen Begutachtung von Ausführungsplänen (Melzner
et al. 2013b). Das bedeutet, dass derzeit nur ein Modell des fertigen Bauwerks analysiert
wird. Diese Arbeitsweise birgt das Risiko, Zwischenzustände im Bauablauf und temporä-
re Einrichtungen nicht ausreichend zu berücksichtigen. Der ganzheitliche Grundgedanke
der Baustellenverordnung als auch die Tatsache, dass der bisherige Arbeitsablauf in der
Arbeitsvorbereitung Gefahren durch Informationsverluste birgt, kann in Zukunft durch die
Verwendung von BIM zu einer verbesserten Sicherheitsplanung führen. Beispiele aus der
Praxis und Forschung zeigen dies.
19 BIM im präventiven Arbeits- und Gesundheitsschutz 313
Obwohl diese Anforderungen schon heute in der Praxis anzutreffen sind, sinkt das
Potenzial des effektiven Einsatzes von BIM in der Sicherheitsplanung stetig bis zum
Baubeginn eines Projektes (Szymberski 1997). „Design for Safety“-Konzepte sind daher
vielversprechend, um Gefahrenstellen und Sicherheitsrisiken vorab zu vermeiden (Gam-
batese et al. 2005; Sulankivi et al. 2013; Kim und Teizer 2014). Sie benötigen aber die
Bereitschaft aller Projektbeteiligten, permanente Gebäudeelemente zu modifizieren sowie
Pläne und Leistungsverzeichnisse zu ändern, um höhere Sicherheitsstandards zu errei-
chen.
Der Arbeitsschutz wird als pro-aktiv bezeichnet, wenn dieser das Produkt, die Produktion
und die Arbeitstaktplanung bereits vor der Bauausführung positiv beeinflusst. BIM erlaubt
es, 3D-Modelle zu erstellen, die durch entsprechende Attribute und Strukturen in der Si-
cherheitsanalyse und -simulation Anwendung finden. Daraus können dann visuelle und
quantitative Ergebnisse abgeleitet werden, z. B. die Position einer Gefahrenstelle, Stück-
listen von notwendigen sicherheitstechnischen Einrichtungen und deren Einsatzdauer im
Bauzeitenplan.
Da der Arbeitsschutz durch nationale und internationale Sicherheitsstandards regle-
mentiert ist, ergibt sich die Möglichkeit, diese effektiv an Bauwerksinformationsmodellen
anzuwenden. Eine Einteilung der Ansätze ist entsprechend der folgenden Kategorien mög-
lich:
Manuelle digitale Werkzeuge zur Planung der Maßnahmen für die Baustellensicher-
heit: Hinter diesen Ansätzen stehen jeweils Datenbanken, die durch Abfragen im
Checklistenformat eine Gefährdungsanalyse ermöglichen.
Verbesserung der Baustellensicherheit durch Visualisierung: Mithilfe von Visualisie-
rungstechniken werden Gefahrenstellen auf Baustellen in virtuellen Gebäudemodel-
len aufgezeigt und sicherheitstechnische Einrichtungen leicht verständlich dargestellt
(Cheng und Teizer 2010; Cheng und Teizer 2014; Siebert und Teizer 2014).
19 BIM im präventiven Arbeits- und Gesundheitsschutz 315
Eine Anwendung aus der automatischen regelbasierten Bauwerksanalyse ist das „BIM
Safety Tool“ (Zhang et al. 2013). Dabei werden die gewöhnlich textbasierten Richtlinien
und Normen im ersten Schritt maschinenlesbar interpretiert. Die Ausführung der Regelab-
frage stellt die Verbindung zwischen der Regelbasis und dem vorbereiteten Bauwerksin-
formationsmodell dar. Bei diesem Prozess werden die vordefinierten Regelsätze über die
Attribute der Objekte im Bauwerksinformationsmodell miteinander verknüpft. Dabei wer-
den Bauteile identifiziert und die dafür vorgesehenen Regeln angewendet. Die Regelaus-
führung wird in zwei Schritten vollzogen. Das Modell wird automatisch überprüft und die
Sicherheitseinrichtungen werden gemäß der Standarteinstellungen angewendet. Danach
kann der Nutzer auf Grundlage der eigenen Erfahrung individuelle Änderungen vorneh-
men, wenn Gründe für eine wirtschaftlichere Alternative vorliegen sollten.
Abb. 19.6 a Benutzeroberfläche der Software Module, b Job Hazard Analysis (JHA) Hinweise zur
sicheren Arbeitsanweisung im vorbeugenden Arbeitsschutz, c Prüfung der ergonomisch korrekten
Montagehöhe eines Ventilreglers in einer Raffinerie, d Automatisiertes Planen und Visualisieren von
Geländern im mehrgeschossigen Wohnungsbau, e Kontrolle ausreichender, unblockierter Arbeits-
und Fluchtwege auf einer Ölplattform und f Ergebnisse im Vergleich internationaler Normen (Zhang
et al. 2013, 2015a, 2015b; Melzner et al. 2013a, 2013b; Wang et al. 2015)
19 BIM im präventiven Arbeits- und Gesundheitsschutz 317
Die aktuellen Forschungsansätze zeigen auf, dass die Gefahrenstellen und Schutzein-
richtungen im 3D-Modell visualisiert werden können und tragen dadurch entscheidend
zur Verbesserung der Kommunikation zwischen den Projektbeteiligten bei. Dabei spielen
sowohl der Ausbildungsgrad als auch die Muttersprache der Anwender eine untergeord-
nete Rolle. Durch die Integration des Bauzeitenplans in das Bauwerksinformationsmodell
lassen sich bereits potenzielle räumliche Konflikte beteiligter Gewerke darstellen (siehe
Abb. 19.5).
Der Einsatz von BIM im Arbeitsschutz darf nicht nur auf der Planungsseite stattfinden,
sondern muss auch gezielt in der Schulung des Baustellenpersonals oder im Sicherheits-
training vermittelt werden. Abbildung 19.6 zeigt u. a. ein Sicherheitsprotokoll, das den
Arbeitsbereich einer Arbeitskolonne visualisiert und gleichzeitig auch alle bisher aufge-
tretenen Gefahrenstellen oder -potenziale aufzeigt. Gerade das Gespräch mit Bauarbeitern
und das Sicherheitstraining stellen die beiden effektivsten Methoden dar, um das Gefah-
renpotenzial von einzelnen Arbeitsschritten zu kommunizieren (Teizer et al. 2013). Des
Weiteren sind in Abb. 19.6 mehrere Anwendungsfälle illustriert, die den Arbeitsschutz
mithilfe von BIM ermöglichen.
Nur wenige Forschungsaktivitäten weltweit waren bisher auf die Nutzung von Bauwerks-
informationsmodellen bei der Planung von sicherheitstechnischen Einrichtungen gerich-
tet. Es existieren mehrere Herausforderungen, die eine Anwendung von BIM im Arbeits-
schutz im Augenblick begrenzen. Diese sind:
Normen und Standards: BIM ist neu in der Bauindustrie. In deutschsprachigen Ländern
gibt es bisher nur wenige Standards, die Anwendungen und Austauschformate regeln.
Investment vs. Kosten: Oftmals wird von einem Investment in den Arbeits- und Gesund-
heitsschutz gesprochen, nicht von Kosten. Obwohl Studien das Gegenteil beweisen,
können oder wollen sich nicht alle Baufirmen BIM-Software, Schulung und Wartung
leisten. Weil gerade bei kleinen Unternehmen hohe Unfallrisiken bestehen, wird der Ef-
fekt von Arbeits- und Gesundheitsschutz mit BIM verzögert. Eine offene, kostengüns-
tige Plattform oder Alternative ist notwendig, um den Arbeits- und Gesundheitsschutz
durch BIM in kommerziellen Produkten plattformübergreifend zu gestalten.
Supply Chain: Um BIM im Arbeitsschutz effektiv anzuwenden, müssen auch Subun-
ternehmer, Hersteller und Zulieferer BIM anwenden. Dabei müssen Sicherheitsdaten
(u. a. Statistiken zu Todesfälle, Unfälle, Beinahe-Unfälle) in der gesamten Wertschöp-
fungskette gesammelt werden. Dies kann unter Umständen zu Veränderungen in der
Vergabe von Projekten bis hin zur Gestaltung von Verträgen führen.
Wissen im Arbeitsschutz: Viele Projektbeteiligte haben geringe oder keine Kenntnisse
im Arbeitsschutz. Diese müssen erlernt oder vermittelt werden, um den Arbeitsschutz
im BIM-Entwicklungsprozess zu integrieren.
318 J. Teizer und J. Melzner
Der Einsatz von BIM im Arbeitsschutz kann nur dann gelingen, wenn die am Arbeits-
schutz Beteiligten mit Experten anderer Disziplinen (z. B. Konstruktion, Gebäudetechnik)
kommunizieren. Ein Projektmodell kann daher sehr effizient aus arbeitsschutztechnischen
Gründen hinterfragt werden, selbst wenn Sicherheitsexpertisen einiger Projektbeteiligter
nicht oder nur teilweise vorhanden sind.
19.9 Zusammenfassung
Literatur
Melzner, J, Teizer, J., Zhang, S., Bargstädt, H.-J. (2013b). „Objektorientierte sicherheitstechnische
Planung von Hochbauprojekten mit Hilfe von Bauwerksinformationsmodellen“, Der Bauinge-
nieur, Springer VDI Verlag, November 2013, 471–479.
Rajendran, S., Clarke, B. (2011). „Building Information Modeling Safety Benefits and Opportuni-
ties“, Professional Safety, ASEE, 44–51.
Schüler, T., Röbenack, K.-D., Steinmetzger, R. (2001). Untersuchung von Absturzunfällen bei Hoch-
bauarbeiten und Empfehlungen von Maßnahmen zu deren Verhütung, Forschung Fb 922 –
Schriftenreihe der Bundesanstalt für Arbeitsschutz und Arbeitsmedizin. Bremerhaven: Wirt-
schaftsverlag NW.
Siebert, S. Teizer, J. (2014). „Mobile 3D mapping for surveying earthwork projects using an Un-
manned Aerial Vehicle (UAV) system“, Automation in Construction, 41, 1–14.
Sulankivi, K., Zhang, S., Teizer, J., Eastman, C.M., Kiviniemi, M., Romo, I., Granholm, L. (2013).
„Utilization of BIM-based Automated Safety Checking in Construction Planning“, Proceedings
of the 19th International CIB World Building Congress, Brisbane Australia, 5–9.
Szymberski, R. (1997). „Construction project safety planning“, TAPPI Journal, 80(11), 69–74.
Teizer, J., Allread, B.S., Fullerton, C.E., Hinze, J. (2010). „Autonomous Pro-Active Real-time
Construction Worker and Equipment Operator Proximity Safety Alert System“, Automation in
Construction, Elsevier, 19(5), 630–640.
Teizer, J., Cheng, T., Fang, Y. (2013). „Location Tracking and Data Visualization Technology to
Advance Construction Ironworkers’ Education and Training in Safety and Productivity“, Auto-
mation in Construction, Elsevier, 35, 53–68.
Zhang, S., Teizer, J., Lee, J.-K., Eastman, C., and Venugopal, M. (2013). „Building Information
Modeling (BIM) and Safety: Automatic Safety Checking of Construction Models and Schedu-
les“, Automation in Construction, Elsevier, 29, 183–195.
Zhang, S., Sulankivi, K., Kiviniemi, M., Romo, I., Eastman, C.M., Teizer, J. (2015a). „BIM-based
Fall Hazard Identification and Prevention in Construction Safety Planning“, Journal of Safety
Science, Elsevier, 72, 31–45.
Zhang, S., Boukamp, F., Teizer, J. (2015b). „Ontology-Based Semantic Modeling of Construction
Safety Knowledge: Towards Automated Safety Planning for Job Hazard Analysis (JHA)“, Au-
tomation in Construction, Elsevier.
Wang, J., Zhang, S., Teizer, J. (2015). „Geotechnical and safety protective equipment planning using
range point cloud data and rule checking in building information modeling“, Automation in
Construction, Elsevier, 49, 250–261.
BIM-gestützte Prüfung von Normen und
Richtlinien 20
Cornelius Preidel, André Borrmann und Jakob Beetz
Zusammenfassung
Normen und Richtlinien dienen im Bauwesen der Vereinheitlichung von Anforde-
rungen und sichern auf diese Weise Technikstandards, um beispielsweise die Statik,
Betriebssicherheit, Materialqualität und nicht zuletzt die Sicherheit des Nutzers zu ga-
rantieren. Bislang handelt es sich bei der Überprüfung einer Gebäudeplanung hinsicht-
lich ihrer Konformität mit den Richtlinien zumeist um einen immer wiederkehrenden,
manuellen Kontrollprozess in der Planungsphase eines Bauwerks, welcher sich durch
hohe Fehleranfälligkeit, Arbeitsaufwand und Kosten auszeichnet. Mit der Einführung
und Entwicklung neuer digitaler Methoden wie dem Building Information Modeling
(BIM) und einheitlicher Datenstandards für Gebäudemodelle stehen dem Bauwesen
Technologien zur Verfügung, die einer Optimierung dieses Prozesses dienen können.
Während des BIM-Prozesses entsteht im Laufe der Planungsphase eines Bauwerks ein
digitales Gebäudemodell, welches sämtliche aktuellen Informationen für alle Projekt-
beteiligten über den gesamten Lebenszyklus des Gebäudes zur Verfügung stellt. Es
bietet sich an, diese bereits gebündelten Daten für eine automatisierte bzw. teilauto-
matisierte Überprüfung eines Modells auf Einhaltung von Normen und Richtlinien,
das sogenannte Automated Code Compliance Checking, zu verwenden und auf diese
Weise eine stetig hohe Planungsqualität zu garantieren.
20.1 Einleitung
Abb. 20.1 Auswahl typischer Darstellungsweisen von Vorschriften in einer Norm. Links Ausschnitt
einer Norm zur Barrierefreiheit, Norwegian Standard 11001-1.E:2009, rechts Einschränkungen für
ungeschützte Öffnungsflächen in Trennwänden. (Angelehnt an UK Fire Code Part B4)
20 BIM-gestützte Prüfung von Normen und Richtlinien 323
Black-Box
Eingabe Ausgabe
White-Box
Eingabe Ausgabe
Die Basis für die Durchführung einer automatisierten Konformitätsüberprüfung ist die
Übersetzung des Informationsgehalts einer Norm in eine von Maschinen interpretierbare
Sprache. An dieser Stelle können zwei grundlegend verschiedene Vorgehensweisen unter-
schieden werden:
Die deutlich einfachere Art der Übersetzung basiert auf der direkten Übertragung des
Überprüfungsprozesses in festimplementierte Programm-Routinen. Dieses bedeutet, dass
sich die Digitalisierung des Informationsgehalts der Norm auf die Lesbarkeit für die Ma-
schine konzentriert und der Handlungsspielraum des Anwenders weitestgehend außer
Acht gelassen wird. Das Ergebnis sind festgelegte Ablaufprozesse, deren Inhalt von dem
Anwender nicht einsehbar ist. Ein solcher Prozess, der lediglich die Eingabe- und Aus-
gabewerte, nicht aber den Verarbeitungsprozess für den Nutzer sichtbar macht, wird ge-
mäß der allgemeinen Systemtheorie als Black-Box-Methode bezeichnet (von Bertalanffy
1972). Der Vorteil dieser Vorgehensweise ist die verhältnismäßig geringe Fehleranfällig-
keit des Prozesses aufgrund der Geschlossenheit und des hohen Standardisierungsgrads
der einzelnen Elemente des Systems.
Im Gegensatz dazu sind in einer sogenannten White-Box-Methode, wie diese schema-
tisch in Abb. 20.3 dargestellt ist, sowohl die Elemente als auch die Prozess- und Zwischen-
schritte für den Anwender sicht- und nachvollziehbar. Grundstein für die Anwendung
dieser Methode ist die Lesbarkeit der digital abgebildeten Informationen für Mensch und
Maschine. Diese wird in der Regel durch eine Code Representation Language, also ein de-
finiertes System von Zeichen und Regeln, das sich für die Darstellung aller Elemente und
Zusammenhänge einer Norm eignet, erreicht. Damit sowohl die Lesbarkeit für Mensch
als auch Maschine gegeben ist, kommt insbesondere der Schnittstelle zwischen diesen,
der sogenannten Mensch-Maschine-Kommunikation, eine hohe Bedeutung zu. Ziel ist es,
dass nicht einfach Informationen, sondern insbesondere auch die Semantik eines Regel-
werkes erfasst werden kann und gleichzeitig der Anwender zu jedem Zeitpunkt in der
Lage ist, die Bedeutung der gespeicherten Informationen zu verstehen.
Die Entwicklung und Umsetzung eines solchen Systems ist deutlich aufwendiger als
die standardisierte Implementierung des Überprüfungsprozesses, jedoch bringt diese einen
20 BIM-gestützte Prüfung von Normen und Richtlinien 325
In den vergangenen Jahrzehnten sind eine Vielzahl von Forschungsansätzen und Software-
lösungen für das Automated Code Compliance Checking vorgestellt worden. In Abb. 20.4
ist eine zeitliche Abfolge ausgewählter Entwicklungen in diesem Bereich dargestellt. Die
Vielzahl dieser Ansätze zeigt auf, welche anhaltende Bedeutung die automatisierte Kon-
formitätsüberprüfung über die vergangenen Jahrzehnte für das Bauwesen hat.
In den folgenden Abschnitten sollen ausgewählte Softwarelösungen, die aktuell in der
Baupraxis im Bereich der automatisierten Konformitätsüberprüfung zur Anwendung kom-
men, vorgestellt werden.
326 C. Preidel et al.
SPEX Fornax
BCAider DesignCheck
HITOS BERA
Abb. 20.4 Zeitliche Abfolge ausgewählter Forschungsansätze und Softwarelösungen zum Auto-
mated Code Compliance Checking nach Dimyadi und Amor (2013)
20.3.1 CORENET
Im Jahr 1995 wurde von der Regierungsbehörde Building and Construction Authority
(BCA) in Singapur die Entwicklung der CORENET-Plattform mit der Intention gestartet,
sämtliche Informationen eines Bauprojekts zentral zu speichern und die einzelnen Baupro-
zesse mithilfe von digitalen Werkzeugen zu optimieren. Eines dieser Instrumente ist die
Applikation CORENET BP-Expert, welche zum Ziel hatte, eine erste Konformitätsüber-
prüfung von digitalen, zweidimensionalen Zeichnungen in den Bereichen Barrierefreiheit
und Feuerschutz zu ermöglichen. Im Jahr 1998 wurde das Datenmodell der CORENET-
Plattform auf den offenen Datenmodellstandard IFC (ISO 16739:2013) umgestellt und
somit um eine dreidimensionale Konformitätsüberprüfung erweitert. Die aktuelle Version
dieses Tools wurde im Jahre 2002 unter dem Namen CORENET e-Plan Check veröffent-
licht und bietet die Konformitätsüberprüfung eines digitalen Gebäudemodells hinsichtlich
eines großen Teils der singapurischen Regelwerke im Bereich der Gebäudesteuerung, Bar-
rierefreiheit, Brandschutz und Umweltgesundheit (Dimyadi und Amor 2013).
Die Überprüfung von Modell und Regelwerken innerhalb von CORENET basiert auf
fest einprogrammierten Routinen und somit sind die Algorithmen und der Verarbeitungs-
prozess für den Anwender intransparent und nur aufwendig an veränderten Bedingungen
anpassbar. Der Gesamtprozess gliedert sich grundlegend in drei Phasen und orientiert sich
dabei an dem Informationsgehalt des zu überprüfenden Datenmodells. In einer ersten Pha-
se wird überprüft, welche Informationen direkt im Modell vorhanden sind und welche
Daten über Umwege, etwa durch Ableitungen expliziter Informationen aus implizit im
Modell „versteckten“ Angaben, bezogen werden müssen. Anschließend wird auf erwei-
terte, untergeordnete Informationsebenen des Modells zugegriffen, um diese nicht direkt
vorhandenen Informationen zu erhalten. Sollten auch auf dieser Ebene die benötigten In-
formationen nicht verfügbar sein, muss schließlich in einem letzten Schritt die fehlende
20 BIM-gestützte Prüfung von Normen und Richtlinien 327
Parallel zu den Entwicklungen in Singapur wurde im Jahr 1998 von dem norwegischen
Technologieunternehmen Jotne EPM Technology die Kollaborationsplattform Express
Data Manager (EDM) geschaffen. Diese basiert auf einer objektorientierten Datenbank,
welche mit der ISO-zertifizierten EXPRESS-Sprache (ISO 10303-11) arbeitet und dar-
auf ausgerichtet ist, Produktdatenmodelle verschiedener Ingenieurdisziplinen, die jedoch
vorrangig außerhalb des Bauwesens liegen, zu verwalten.
Die Datenmodellierungs-Sprache EXPRESS dient innerhalb des EDM dazu, ein ho-
hes Maß an Flexibilität im Umgang mit den komplexen Datenmodellen zu erreichen.
EXPRESS ist ein Teil des Standard for the exchange of product model data (STEP,
ISO 10303), einem weit verbreiteten Format für Produktdatenmodelle, und ermög-
licht dem EDM daher die Kompatibilität mit einer großen Anzahl von verschiedenen
Datenmodell-Formaten. Über ein integriertes Konvertierungsmodul, dem sogenannten
EDMmodelConverter, können die gespeicherten Datenmodelle mit einer geringen Feh-
leranfälligkeit auf andere Formate abgebildet werden. Das EDM-Datenbanksystem ist
somit insbesondere auch mit dem IFC-Datenformat kompatibel, welches ebenfalls auf
der EXPRESS-Sprache basiert. Die Offenheit und Flexibilität der EDM-Plattform stellt ein
wichtiges Entscheidungskriterium für die Bestrebungen externer Entwickler dar und wird
daher häufig als Grundlage für die Entwicklung weiterer Planungsinstrumente verwendet
(Ding et al. 2004).
328 C. Preidel et al.
Von dem Unternehmen Jotne EPM Technology selbst steht neben dem Datenkern der
EDM-Plattform bereits eine Vielzahl weiterer Module zur Verarbeitung der Daten zur
Verfügung. Im Bereich der Konformitätsüberprüfung ermöglicht das herstellereigene Mo-
dul EDMmodelChecker, Vorschriften mithilfe der EXPRESS-Sprache zu formulieren und
anschließend auf die Informationen eines gespeicherten Gebäudemodells anzuwenden.
Dabei muss der Anwender fundierte Programmiersprachenkenntnisse besitzen, um den
Informationsgehalt einer Norm abbilden und anschließend auch wieder lesen zu können
(Ding et al. 2004).
Der Solibri Model Checker (SMC) ist eine Java-basierte Plattform der finnischen Techno-
logiefirma Solibri, welche im Jahre 2000 ursprünglich als Qualitäts- und Validierungs-
werkzeug für IFC-Gebäudemodelle vorgestellt wurde. Innerhalb des SMC werden die
Daten eines IFC-Modells automatisch auf ein proprietäres, internes Datenmodell abge-
bildet und können anschließend weiterverarbeitet werden. Die Abbildung zwischen den
beiden Datenmodellen basiert auf fest implementierten Routinen und bringt so den Vor-
teil mit sich, dass das System in nur geringem Maße fehleranfällig für Inkonsistenzen
im Datenmodell ist. Daher hat sich der SMC in den vergangenen Jahren vermehrt zu
einem eigenständigen und verbreiteten Werkzeug für Konformitätsüberprüfungen entwi-
ckelt (Dimyadi und Amor 2013). In der aktuellen Version 9.5 bietet der SMC eine Vielzahl
grundlegender Funktionalitäten an, wie beispielsweise automatisierte Überprüfungen der
Gestaltungsplanung (siehe auch Abb. 20.5).
Die einzelnen Regeln innerhalb des SMC sind als feste Funktionen implementiert,
welche über eine proprietäre Programmierschnittstelle auf die Informationen des Da-
tenmodells zugreifen und diese weiterverarbeiten. Diese Schnittstelle steht jedoch nicht
öffentlich zur Verfügung und so ist eine externe Entwicklung lediglich in Zusammenar-
beit mit der Firma Solibri möglich (Eastman et al. 2009b).
Eine erfolgreiche Umsetzung eines solchen Planungsinstruments wurde von der US-
amerikanischen Regierungsbehörde US General Services Administration in enger Zusam-
menarbeit mit dem Georgia Institute of Technology in Form des Design Assessment Tool
entwickelt. Dieses ermöglicht auf Grundlage des SMC, Gebäudemodelle automatisiert
hinsichtlich ihrer Konformität mit dem US Courts Design Guide, einem Regelwerk, wel-
ches Raum-, Umwelt-, Sicherheits- und Gebäudetechnikanfordungen an Justizgebäude
stellt, zu überprüfen (Eastman 2009).
Wie die in Abschn. 20.3 vorgestellten Softwarelösungen gezeigt haben, kommen in der
Praxis bisher vorrangig geschlossene Systeme zum Einsatz, die einen gewissen Grad
der Fehlerfreiheit des Überprüfungsprozesses garantieren können, letztlich aber nur einen
sehr eingeschränkten Handlungsspielraum für die Anwendung bieten. Jedoch zeigen die
aktuell vorhandenen Lösungen im Bereich des Automated Code Compliance Checking
bereits auf, welche enorme Arbeitserleichterung und Effizienzsteigerung durch die Nut-
zung von BIM und die Umstellung der Normenprüfung auf einen automatisierten Prozess
möglich ist. So sind schon heute bereits grundlegende automatisierte Überprüfungen vor-
wiegend im geometrisch-topologischen Bereich wie beispielsweise dem Brandschutz und
der Fluchtwegeanalyse möglich. Aus diesem Grund handelt es sich um ein äußerst aktu-
elles Forschungsthema, in welchem es noch viele Fragestellungen zu lösen gilt.
Aktuelle Forschungsansätze konzentrieren sich vermehrt auf einen ganzheitlichen Lö-
sungsansatz, der vor allem die Beteiligung des Anwenders bei dem Übersetzungsprozess
und der Durchführung des Prozesses vermehrt in den Fokus rückt. Diese Ansätze verwen-
den als Mensch-Maschine-Schnittstelle zumeist eine Code Representation Language, wie
sie in Abschn. 20.2 vorgestellt wurde.
Ein bekannter Vertreter dieser Forschungsrichtung sind die sogenannten SMARTCo-
des, welche im Jahr 2006 von der International Code Council vorgestellt wurden. Die
SMARTCodes stellen im Prinzip ein Datenaustausch-Protokoll dar, mit dessen Hilfe die
gebräuchlichen Elemente eines Regelwerkes vereinheitlicht und anschließend in einer Bi-
bliothek zusammengefasst werden können. Zwar wurde die Entwicklung vonseiten der
ICC bereits im Jahre 2010 aufgrund der fehlenden Folgefinanzierung wieder eingestellt,
jedoch wurde das Projekt von den Firmen AEC3 und DigitalAlchemy übernommen und
weiterentwickelt (Dimyadi und Amor 2013).
Kern dieser SMARTCodes ist die sogenannte RASE-Syntax, welche den Inhalt einer
Vorschrift mittels der vier Kategorien Requirement (Anforderungen), Applicability (Gel-
330 C. Preidel et al.
Abb. 20.6 Formalisierung der Norwegischen Norm NS 11001-1:2009 gemäß der RASE-Syntax
Literatur
Beetz, J., van Leeuwen, J., & de Vries, B. (02 2009). IfcOWL: A case of transforming EXPRESS
schemas into ontologies. Artificial Intelligence for Engineering Design, Analysis and Manufac-
turing, Vol. 23, S. 89–101.
von Bertalanffy, L. (1972). The History and Status of General Systems Theory. In The Academy of
Management Journal, Vol. 15 No. 4 (S. 407–426).
Dimyadi, J., & Amor, R. (2013). Automated Building Code Compliance Checking – Where is it at?
Auckland, New Zealand: University of Auckland.
Ding, L., Drogemuller, R., Jupp, J., Rosenman, M., & Gero, J. (2004). Automated Code Checking.
CRC for Construction Innovation, Clients Driving Innovation International Conference, 25–
27 October. Surfers Paradise, Qld.
Eastman, C. (2009). Automated Assessment of Early Concept Designs. In R. Garber, Architectural
Design, Vol. 79 Issue 2 (S. 52–57). UK: John Wiley & Sons, Ltd.
Eastman, C., Lee, J., Jeong, Y., & Lee, J. (30. Juli 2009b). Automatic rule-based checking of building
designs. Automation in Construction, Vol. 18 Issue 8, S. 1011–1033.
Hjelseth, E., & Nisbet, N. (2011). Capturing normative constraints by use of the semantic mark-up
RASE methodology. Proceedings of the CIB. Sophia Antipolis, France.
Lee, J. K. (2010). Building Environment Rule and Analysis (BERA) Language. Georgia, USA:
Georgia Institute of Technology.
Xu, R., Solihin, W., & Huang, Z. (2004). Code Checking and Visualization of an Architecture De-
sign. IEEE Visualization 2004. Austin, USA: IEEE.
BIM für die Mengenermittlung
Jochen Hanff und Joachim Wörter
21
Zusammenfassung
Mengen spielen bei der Planung und Ausführung eines Bauprojekts eine zentrale Rolle
und müssen effizient, sicher und nachvollziehbar berechnet sowie ausgewertet werden
können. Die BIM-Methode kann für diesen Zweck sehr vorteilhaft verwendet werden.
Insbesondere die Sicherheit und Nachvollziehbarkeit kann im Vergleich zu konventio-
nellen Arbeitsweisen signifikant verbessert werden. Im Rahmen dieses Kapitels wird
eine Einführung in die modellbasierte Mengenermittlung gegeben. Es wird insbesonde-
re auf die Datenmodellierung und Anforderungen an digitale Bauwerksmodelle unter
Verwendung von intelligenten Bauobjekten eingegangen.
Ein zentraler Prozess bei der Kostenschätzung, Angebotsbearbeitung wie auch bei der
Durchführung eines Bauprojekts ist die Ermittlung der Mengen der auszuführenden Leis-
tungen. Das Mengengerüst eines Bauprojekts wird für unterschiedliche Aufgaben be-
nötigt. Neben der Kostenermittlung und Preiskalkulation ist hier auch als Beispiel die
Terminplanung zu nennen. Deshalb ist es von entscheidender Bedeutung, zuverlässig,
effizient und sicher Mengen aus einem digitalen Gebäudemodell ermitteln zu können
und diese in einer Form zu erhalten, die den Anforderungen und den anzuwendenden
Regelwerken entsprechen. Neben den Nettomengen für Plausibilitätskontrollen und in-
terne Kalkulation in einem Bauunternehmen gehören insbesondere in Deutschland auch
Jochen Hanff
ceapoint aec technologies GmbH, Max-Fiedler-Str. 6, 45128 Essen, Deutschland
e-mail: jochen.hanff@ceapoint.com
Joachim Wörter
BIB GmbH, In der Spöck 8, 77656 Offenburg, Deutschland
prüfbare Mengen dazu, die den Regeln der VOB (Vergabe- und Vertragsordnung für Bau-
leistungen) entsprechen. In anderen Ländern gibt es ähnliche Regeln.
Die im Bauwesen eingesetzten CAD-Systeme haben ihren Schwerpunkt in der Planung
eines Bauwerks mit entsprechenden Funktionen für die Konstruktion und Planausgabe.
Deshalb ist es notwendig, für die Berechnung von Mengengerüsten weitere Softwaresys-
teme einzusetzen, die die regelgerechte Ermittlung und Auswertung von Mengen ermögli-
chen und die Ergebnisse in ein Leistungsverzeichnis für die darauf folgenden Teilprozesse
wie Kalkulation, Ausschreibung und Abrechnung übernehmen.
Die Dateninhalte und Datenstrukturen, die für die Mengenermittlung erforderlich sind,
müssen gegenüber den Datenmodellen der zugrundeliegenden Modellierungssysteme
deutlich erweitert werden. Gerade Regeln für die Abrechnung von Bauleistungen wie die
in Deutschland in vielen Fällen anzuwendende VOB/C machen es notwendig, dass neben
der geometrischen Beschreibung der Bauteile weitere Objekte wie Öffnungen und Räume
im Bauwerksmodell enthalten sind. Weiterhin werden zusätzliche Eigenschaften erwartet.
Diese Eigenschaften beschreiben unter anderem Material, Gewerk oder auch die Lage
eines Bauteils.
Die Rechenregeln legen die Berechnungsgrundlagen und Abzugsregeln fest. So werden
Öffnungen in Bauteilen je nach ihrer Größe entweder der Fläche eines Bauteils hin-
zugerechnet oder abgezogen. Diese Rechenregeln sind aufgrund der bislang manuellen
Durchführung der Berechnung und Prüfung von Mengen auf die manuelle Arbeitsweise
angepasst und von diesen entscheidend geprägt.
Für solche Regeln werden die Öffnungen in einem Bauteil als geometrischer Körper
benötigt, sodass Flächen und Volumen berechnet werden können. Die Leistungen des Aus-
baus werden aus Bauteilen raumbezogen ermittelt. Das heißt, die Oberfläche und damit
auch die zu erbringende Leistung kann für ein Bauteil auf einer Seitenfläche eine andere
sein als auf einer anderen Seitenfläche. Dies setzt einen Raum als geometrisches Objekt
voraus, für den die Kontaktflächen zu angrenzenden Bauteilen berechnet werden kann.
Die Kontaktflächen zwischen einem Raum und einem Bauteil, wie zum Beispiel einer
Wand, bestimmen dann die Menge der zu erbringenden Leistung.
Ebenso sind die Beziehungen zwischen den Bauteilen erforderlich. Zu diesen Bezie-
hungen gehören Beziehungen wie „ist enthalten in“ (Fenster in Wand, Abb. 21.1), aber
auch Beziehungen, die sich zum Beispiel aus den Kontakten zwischen Bauteilen erge-
ben. Die Kontakte werden verwendet, um in Abhängigkeit von Eigenschaften wie dem
Material Leistungen zu berechnen.
Die Bauteile eines Bauwerksmodells werden geometrisch beschrieben. In der Regel
sind die Datenmodelle, die hier zur Anwendung kommen, Beschreibung der Oberfläche
mit einem Netz aus Dreiecken (siehe Kap. 2). Aus diesen geometrischen Körpern kön-
nen geometrische Eigenschaften wie Längen, Flächen und Volumen berechnet werden.
21 BIM für die Mengenermittlung 335
Voraussetzung ist die korrekte Geometrie und Topologie. Weiterhin werden Attribute der
Objekte ausgewertet. Das sind Attribute, die geometrische Eigenschaften wie zum Bei-
spiel die Länge einer Wand, aber auch alphanumerische Eigenschaften, wie das Material
eines Objekts, die Klassifizierung bezüglich der Lage (außen/innen) oder der Bauteiltyp
(Wand, Stütze, Treppe, Fenster). Je nachdem, wie gut das Modellierungswerkzeug an
die Domäne des Bauwesens angepasst ist, werden die benötigten Eigenschaften in aus-
reichendem Umfang geliefert oder können im Modellierungswerkzeug zusätzlich vom
Anwender eingegeben werden. Da nicht damit zu rechnen ist, dass alle erforderlichen
Attribute vorhanden sind, müssen auch zu einem späteren Zeitpunkt im System für die
Mengenermittlung die fehlenden Attribute im Modell ergänzt werden können.
Bei der Modellierung eines Bauwerks und der Berechnung der Mengen aus dem Bau-
werksmodell können unterschiedliche Strategien verwendet werden, die sich im Detai-
lierungsgrad des Bauwerksmodells unterscheiden. Das Spektrum reicht von der groben
Modellierung und der Ermittlung der Mengen und Kosten über Kennwerte bis hin zur
detaillierten Modellierung der einzelnen Teilleistungen als eigenständige 3D-Bauteile.
Das 3D-Bauwerksmodell kann sehr grob sein, das heißt es besteht im Wesentlichen nur
aus Abschnitten, Räumen und Zonen (Abb. 21.2). Diesen räumlichen Abschnitten wer-
den Raumtypen zugeordnet, die die Leistungen als Kennwert abhängig vom Rauminhalt
oder von Boden-, Wand- und Deckenflächen bestimmen. Aus diesen Abschnitten können
Mengengerüste und Kosten aufgrund von Kenngrößen ermittelt werden. Insbesondere in
frühen Planungsphasen, in denen das Bauvorhaben noch nicht detailliert spezifiziert ist,
können mit überschaubarem Modellierungsaufwand Aussagen zu Mengen und Kosten ge-
troffen werden.
336 J. Hanff und J. Wörter
Genauer, aber auch aufwendiger in der Modellierung, ist die Abbildung aller Leistun-
gen jeweils mit einem Objekt bzw. einer Menge von Objekten im Bauwerksmodell
(Abb. 21.3). Diese Modellierungsstrategie bildet zum Beispiel einen Decken- und Fuß-
bodenaufbau mit all seinen Schichten ab. Der Vorteil dieser Modellierungsmethode liegt
in der anschaulichen Visualisierung der zu erbringenden Leistungen. Der Nachteil liegt
jedoch im deutlich erhöhten Aufwand bei der Erstellung des 3D-Modells.
21 BIM für die Mengenermittlung 337
In der Praxis wird in den meisten Fällen ein Mittelweg zwischen den beiden oben genann-
ten Strategien gewählt. Abhängig ist der Detailierungsgrad auch von weiteren Anwen-
dungen für das 3D-Modell. Wird das Modell ausschließlich für die Mengenermittlung
erstellt, wird das Modell i. d. R. geometrisch weniger detailliert modelliert und die Mo-
dellierung in der Art vorgenommen, die in Abhängigkeit vom verwendeten CAD-System
am schnellsten zu einer geforderten Genauigkeit bei der Mengenermittlung führt. Wird
das Modell auch für weitere Zwecke wie zum Beispiel der Veranschaulichung von Plä-
nen erstellt, wird der geometrische Detaillierungsgrad erhöht. Des Weiteren kommt es
durchaus vor, dass man auf die Modellerstellung nur bedingt Einfluss nehmen kann. Be-
kommt man ein Bauwerksmodell von Dritten zur Verfügung gestellt, ist eine Vorgabe
der Detaillierung nicht vollständig steuerbar. Ein für die modellbasierte Mengenermitt-
lung eingesetztes System muss alle diese Modellierungsstrategien unterstützen, da der
Detaillierungsgrad sich aus Randbedingungen ergibt, die nicht immer beeinflusst werden
können. Dies trifft insbesondere zu, wenn unternehmensübergreifend Informationen in
338 J. Hanff und J. Wörter
Form von Modellen ausgetauscht werden und man deshalb mit einem Modell arbeiten
muss, das vorgegeben ist.
Um eine effiziente Ermittlung der Mengen und Beschreibung der Leistungen zu errei-
chen, ist eine umfangreiche Datenbank mit Beschreibungen und Berechnungsformeln für
Bauleistungen ein wichtiger Bestandteil für eine modellbasierte Mengenermittlung und
Kalkulation. Diese sogenannte Content-Datenbank stellt die Basis für eine bauteil- bzw.
gebäudemodellorientierte Mengenermittlung dar. Schon in der frühen Phase der Projekt-
entwicklung stellt die Content-Datenbank archiviertes Wissen über die Beschreibung und
Abrechnung von Bauleistungen als sogenannte Content-Elemente zur Verfügung. Diese
Beschreibungen von Leistungen sind mit Kalkulationsansätzen für Lohn, Material, Gerät
und Sonstiges hinterlegt und können direkt aus dem Archiv übernommen werden oder
werden vom Anwender an den konkreten Einzelfall angepasst.
Die Content-Elemente stellen weiterhin Rechenregeln für die Berechnung und norm-
gerechte Abrechnung zur Verfügung. Mit den Content-Elementen werden Abrechnungs-
mengen ohne zusätzliches Eingreifen des Anwenders berechnet. Dennoch können jeweils
projektbezogen Änderungen in den Regelwerken vorgenommen werden. Die in Deutsch-
land übliche Berücksichtigung der VOB-Regeln wird auf diese Weise durchgeführt. Das
gleiche gilt für Auswertungen nach DIN 276 oder anderen Kostennormen. Die erfor-
derlichen Attribute für die Gruppierung und die Auswertung sind entsprechend in den
Leistungsbeschreibungen enthalten.
Damit wesentliche Leistungen nicht unberücksichtigt bleiben, werden in der Content-
Datenbank zusammengehörige Leistungen bzw. Content-Elemente in Arbeitspakete ge-
bündelt. Diese Arbeitspakete, auch Bau-Objekte (Bau-OBjekt/BOB) genannt, enthalten
wiederum eigene Regeln für das Aufmaß und Eigenschaften, die sie dann auf die da-
zugehörigen Teilleistungen (BOB-Details) vererben können. Somit ist ein Bau-Objekt
ein Teilleistungsverzeichnis inklusive Aufmaß-Regeln für ein konkretes Konstruktions-
element. Dabei werden alle Gewerke in einem BOB zusammengefasst, die auch später
zur Ausführung kommen.
(intelligentes Bau-Objekt, Abb. 21.3). Mit diesem Objekt werden die Fenster gleicher
Größe gesammelt und anschließend ermittelt das iBOB-Modell automatisiert die erfor-
derlichen Texte für das Leistungsverzeichnis.
Zur Steigerung der Effizienz bei der Mengenberechnung ist in den meisten Fällen die
Verwendung von iBOBs zweckmäßig. Ansonsten entsteht ein erheblicher Aufwand, der
als Argument gegen die modellbasierte Mengenermittlung im Speziellen und BIM im
Allgemeinen angeführt wird.
Als Beispiel für das Prinzip der Leistungsermittlung mit iBOBs soll hier eine Ver-
blendfassade dienen. Das iBOB enthält die zur Herstellung der Fassade erforderlichen
Positionen. Eine Fensteröffnung in der Außenwand ist in der Lage, Abzüge gemäß VOB
zu berechnen und aktiviert zusätzliche Positionen für die Ausbildung im Sturzbereich, der
Laibungen und im Bereich der Fensterbank/Rollschicht. Alle diese zusätzlichen Positio-
nen werden i. d. R. nicht gezeichnet, sondern aus den Informationen über die Bauteile, ihre
Geometrie und ihre Beziehungen untereinander abgeleitet und berechnet.
Üblicherweise versteht man unter 5D die Verbindung des 3D-Modells mit den Baukos-
ten. Je nach Verfahrensanweisungen innerhalb eines Unternehmens versucht man, die
340 J. Hanff und J. Wörter
Sind alle Bauteile bemustert, kann auf dieser Grundlage ein Raum- bzw. Projektbuch
erstellt werden. Es entsteht ein hierarchisch geordnetes Gebäudemodell, das anzeigt, in
welchem Bauabschnitt und Stockwerk welche Räume und Konstruktionselemente enthal-
ten sind. In den Rohbau- sowie den Ausbauräumen werden die bemusterten Bauobjekte
gespeichert und die Mengen der enthaltenen Positionen errechnet. Die VOB-Prüfung er-
folgt automatisch. Fehlen im ursprünglichen Modell Informationen oder Bauteile, kann
das Raum-/Projektbuch zu jedem Zeitpunkt manuell um zusätzliche Bauobjekte und Posi-
tionen ergänzt werden. Auf diesem Weg findet eine nicht gezeichnete Baugrube dennoch
ihren Weg in die Mengenermittlung. Die manuell ergänzten Positionen vermischen sich
im Leitungsverzeichnis mit den Positionen aus dem Gebäudemodell.
In einem 3D-Modell sind i. d. R. keine oder nur wenige Informationen über die Bau-
stelleneinrichtung oder z. B. über die Berechnung von Baunebenkosten enthalten. Die
Ermittlung dieser Kosten wird von projektbezogenen Bauobjekten durchgeführt. Diese
Interpretieren alle zuvor entstandenen Informationen wie z. B. Kosten nach DIN 276, Flä-
chen nach DIN 277 etc. und leiten hiervon die erforderlichen Zusatzinformationen ab.
21 BIM für die Mengenermittlung 341
21.8 Leistungsverzeichnis
Mengengerüste spielen bei der Planung und Ausführung eines Bauprojekts eine zentrale
Rolle. Mengen müssen effizient, sicher und nachvollziehbar berechnet und ausgewertet
werden können. Die BIM-Methode kann für diesen Zweck vorteilhaft sein. Insbesonde-
re die Sicherheit und Nachvollziehbarkeit können im Vergleich zu den konventionellen
Arbeitsweisen signifikant verbessert werden. Zu beachten ist jedoch, dass neben den Bau-
elementen für die Konstruktion weitere Elemente wie Öffnungen und Räume vorhanden
sein müssen. Weiterhin ist zu beachten, dass die Beziehungen zwischen Bauteilen, insbe-
sondere die Kontaktflächen zwischen Bauteilen und Räumen, ermittelt werden müssen.
Um die Effizienz bei der Berechnung der Mengen und der Ermittlung der daraus ab-
geleiteten Leistungen zu erhöhen, ist eine Datenbank mit Leistungsbeschreibungen und
Rechenregeln notwendig. Mit den Elementen dieser Datenbank wird die Kette von der
Konstruktion mit CAD über die Berechnung der Mengen bis hin zum Leistungsverzeich-
nis und Kalkulation des Preises für das Bauwerk geschlossen. Somit ist die modellbasierte
Mengenermittlung ein wichtiger Baustein für die Anwendung der BIM-Methode.
Das konventionelle Vorgehen bei der Berechnung und Dokumentation von Mengen
ist heute geprägt durch das händische Berechnen und Prüfen von Mengen und wird den
Vorteilen der Verarbeitung mit einem Rechner nicht gerecht. Betrachtet man die Entwick-
lung in anderen Bereichen, wie zum Beispiel in der statischen Berechnung des Tragwerks,
so stellt man fest, dass die zahlreichen Berechnungsmethoden, die für eine schnelle und
einfache händische Berechnung optimiert waren, zugunsten einer einheitlichen und dem
Computer gerechten Berechnungsverfahren, nämlich der Methode der Finiten Elemente,
an Bedeutung verloren haben. Um die Prüfung der Ergebnisse zu gewährleisten, werden
hier die Erstellung und die Prüfung einer Berechnung mit unterschiedlichen Programmen
durchgeführt. Ein ähnliches Vorgehen ist auch im Bereich der Berechnung von Mengen
vorstellbar und ist für die Anwendung der BIM-Methode und insbesondere der modellba-
sierten Mengenermittlung zweckmäßig.
Bauwerksvermessung für BIM
Jörg Blankenbach1
22
Zusammenfassung
Das Aufmaß von Bauwerken ist ein zentraler Bestandteil für die Dokumentation und
Planung im Bestand. Im Kontext von BIM werden jedoch neue Anforderungen an die
Bauaufnahme gestellt. Waren die Ergebnisse des Aufmaßes bislang zumeist digitale
2D-CAD-Zeichnungen für die Darstellung von Grundrissen, Schnitten und Ansichten,
werden für BIM virtuelle dreidimensionale Bauwerksmodelle mit volumenelementori-
entierter Objektmodellierung inklusive deren Semantik und Beziehungen sowie ggf.
beschreibender Eigenschaften benötigt. Der ganzheitliche BIM-Ansatz zur Dokumen-
tation von Bauwerken hat damit auch Auswirkungen auf den Vermessungsworkflow
sowie die Verarbeitung und Modellierung der Daten. Die Grundlage für das Aufmaß
stellen dabei geodätische Vermessungsmethoden mit Einzelpunkt basierenden Verfah-
ren (elektronisches Handaufmaß, Tachymetrie) sowie flächenhaft erfassende Verfah-
ren (Photogrammetrie, Laserscanning) in Kombination mit entsprechender Erfassungs-
software dar. Auch neuere Entwicklungen im Bereich der Erfassungssysteme (UAVs,
Multisensor- und Mappingsysteme) basieren auf diesen grundlegenden Methoden.
22.1 Übersicht
1
Unterstützt durch Dr.-Ing. R. Schwermann, RWTH Aachen sowie MSc. S. Siebert (Aibotix
GmbH) (Abschn. 22.5.4).
Jörg Blankenbach
RWTH Aachen Geodätisches Institut und Lehrstuhl für Bauinformatik & Geoinformationssysteme,
Mies-van-der-Rohe-Str. 1, 52074 Aachen, Deutschland
e-mail: blankenbach@gia.rwth-aachen.de
spezifischen Software hat dazu geführt, dass in der aktuellen Praxis folgende Verfahren
bei der Bauwerksvermessung eingesetzt werden:
1. Elektronisches Handaufmaß,
2. Tachymetrie,
3. Photogrammetrie,
4. Laserscanning.
Im weiteren Verlauf dieses Kapitels werden die genannten Verfahren näher erläutert.
Allen gemein ist die Tatsache, dass sie ein mathematisches Referenzsystem benötigen,
das den übergeordneten Bezugsrahmen für die geometrische Dokumentation der Bau-
werksbestandteile bereitstellt. Auf die wichtigsten Kriterien hierbei wird daher zunächst
eingegangen.
22.2 Koordinatensystem
Die Geometrie von Bauwerken kann universell und konsistent durch mathematische Koor-
dinaten beschrieben werden. Eine Bauwerksvermessung beginnt daher mit der Definition
eines geeigneten Koordinatensystems, das den Bezugsrahmen (Referenzsystem) für al-
le Vermessungs- und Dokumentationsvorgänge darstellt. In den meisten Fällen wird ein
lokales Koordinatensystem definiert, dessen Ausrichtung sich vorzugsweise an den Haupt-
achsen des Bauwerks orientiert. Liegen die Koordinatenachsen parallel bzw. orthogonal
beispielsweise zur dominierenden Flurachse des Bauwerks, erleichtert dies später vie-
le konstruktive Zeichenvorgänge. Neben den Lagekoordinaten (X, Y) wird die Höhe H
als dritte Koordinate (Z-Wert) verwendet, um die Bauwerkserfassung und -dokumenta-
tion vollständig dreidimensional durchführen zu können. Die Benutzung von geodäti-
schen Landeskoordinaten (Gauß-Krüger oder UTM) als Referenzsystem war bislang in
der Praxis wegen der im Allgemeinen willkürlichen Ausrichtung in Relation zum Gebäu-
de weniger gebräuchlich. Auch die parametrische Geometriemodellierung in BIM spricht
für die Verwendung eines lokalen Systems in Bezug zum Baukörper für die Vermessung
und Primärmodellierung. Durch die Designation von BIM als zentrale und durchgängige
Bauwerksdatenbank sollte der Bezug zum amtlichen Planungskoordinatensystem jedoch
gegeben sein. Durch Einführung identischer Punkte in beiden Koordinatensystemen (Lan-
dessystem, lokales System) ist eine Umrechnung durch Koordinatentransformation jedoch
möglich.
Die Realisierung des Koordinatensystems vor Ort erfolgt durch die Vermarkung von
Festpunkten (FP), die entweder vorab oder simultan mit der fortschreitenden Bauerfas-
sung eingemessen und im räumlichen Bezugssystem koordiniert werden. Die FP dienen
sowohl als Standorte für die Vermessungsinstrumente als auch als Anschlusspunkte (AP)
bzw. Passpunkte (PP) für Stationierungs- und Orientierungsvorgänge. Ihre Positionen sind
346 J. Blankenbach
so auszuwählen, dass damit das Aufmaß problemlos gelingt und zugleich die Dauer-
haftigkeit nach Möglichkeit gewährleistet ist. Die Fest- und Anschlusspunkte werden
sowohl außerhalb des Gebäudes, also meistens im umgebenden Gelände, als auch innen
auf Böden, Wänden und ggf. Decken platziert. Für die Verdichtung des Festpunktnetzes
im Innenraum sind die Laibungen der Mauerwerksöffnungen (Türen, Fenster) günstige
Standorte, da sie von zwei Seiten gut beobachtbar sind.
Abbildung 22.1 zeigt das schematische Beispiel eines Festpunktnetzes für die Bauauf-
nahme eines Gebäudes. Begonnen wird mit den Außenpunkten, die das Objekt ringförmig
umschließen. Hiervon ausgehend werden weitere Festpunkte in das Gebäude übertragen,
die die Basis für weitere Verdichtungen bilden. Bei mehreren Stockwerken ist das Prinzip
analog für jede Etage anzuwenden. Die geodätische Festpunktbestimmung erfolgt anhand
von klassischen Einzelpunktverfahren wie etwa durch Polygonierung oder Schnittverfah-
ren (z. B. Bogenschlag).
Den größten Aufwand verlangt die Messung von Strecken- und Richtungsnetzen mit
anschließender Ausgleichung; allerdings liefert diese auch die genauesten Koordinaten,
wobei Fehler mit größtmöglicher Wahrscheinlichkeit aufgedeckt werden können. Der bes-
te Instrumentenstandort für das Aufmaß der maßgebenden Bauwerkspunkte stellt sich
oftmals erst während der laufenden Vermessungsarbeiten heraus. Bei diesen Punkten un-
terbleibt in der Regel die Vermarkung und die Standortbestimmung geschieht durch Freie
Stationierung. Für weitere Details zu den vorstehend genannten Punktbestimmungsver-
fahren sei auf die geodätische Fachliteratur verwiesen (z. B. Witte und Sparla 2011).
22 Bauwerksvermessung für BIM 347
Das elektronische Handaufmaß beruht auf der Kombination von elektro-optischen Stre-
ckenmessungen, mobilen Computern und spezieller Software. Es unterscheidet sich in-
strumentell und verfahrenstechnisch von dem früher üblichen klassischen Handaufmaß,
das gekennzeichnet war durch Maßband/Zollstock, Lot, Rechtwinkelprisma und Flucht-
stäbe sowie Orthogonal- und Einbindeverfahren als vorherrschende vermessungstechni-
sche Methode. Das moderne Handaufmaß verwendet bei der Streckenmessung gewöhn-
lich Laserdistanzmesser im Einmannverfahren, wobei die anzumessenden Punkte mit ei-
nem sichtbaren Laserstrahl angezielt werden. Die Messwerte werden heutzutage direkt
über eine Schnittstelle an den mitgeführten mobilen Computer (Tablet, Laptop) per Kabel
oder Bluetooth übertragen und in der Aufmaßsoftware weiterverarbeitet. Die Aufmaß-
software kann ein eigenständiges Programm oder eine Zusatzapplikation in einem CAD-
System sein. Bei Letzterem stehen dem Operateur die umfangreichen CAD-Funktionali-
täten für die grafische Dokumentation der Vermessungsergebnisse zur Verfügung, die zur
Effektivitätssteigerung durch viele, auf das Bauaufmaß abgestimmten, Spezialfunktionen
erweitert sind.
Gemessen werden ausschließlich – zumeist horizontale, vertikale und diagonale – Stre-
cken, weshalb diese Methode auch ohne vermessungstechnische Fachkenntnisse ange-
wendet werden kann. Methodisch gesehen wird beim elektronischen Handaufmaß das
Bauwerk zunächst gedanklich in die vorhandenen Raumeinheiten als Basiselemente zer-
legt, deren geometrische Eigenschaften unabhängig voneinander erfasst werden. Jeder
Raum wird also im ersten Schritt als eigenständige Zelle für sich vermessen. Für die Ge-
samtdimensionierung eines rechteckigen Standardraumes im Grundriss genügen somit in
den meisten Fällen drei horizontale Strecken für Länge, Breite und Diagonale, wobei letz-
tere im Regelfall der Kontrolle auf Rechtwinkligkeit dient (Abb. 22.2). Hierauf aufbauend
werden die Mauerwerksöffnungen, also vor allem Fenster und Türen, sowie Aussparun-
gen, Durchbrüche und Vorsprünge durch weitere Streckenmessungen bestimmt und über
die Aufmaßsoftware in der Zeichnung festgehalten. Soll ein dreidimensionales Aufmaß
stattfinden, wird durch entsprechende Streckenmessungen in der Vertikalen die dritte Di-
mension analog erfasst.
Die unmittelbare Verbindung zum Referenzsystem findet wie bei den anderen Aufmes-
sungsverfahren (Tachymetrie, Photogrammetrie und Laserscanning) beim Handaufmaß
nicht statt. Deshalb müssen die zunächst unabhängig bestimmten Raumeinheiten, die in
sich gesehen vollständig geometrisch definiert sind, zu einem Ganzen aggregiert werden,
sodass schließlich das Gebäude in seiner geometrischen Ausprägung vollständig repräsen-
tiert ist. Dies geschieht regelmäßig anhand der gemeinsamen Wandöffnungen (Fenster und
Türen) und den gemessenen Wand- bzw. Laibungstiefen, über die die einzelnen Raum-
einheiten lagerichtig zusammengefügt werden. Für diesen Vorgang stellt die Software
entsprechende Funktionen zur Verfügung, die einen hierarchischen Aufbau in Räume,
Raumgruppen, Geschosse und Gesamtbauwerk unterstützen.
348 J. Blankenbach
Einige Aufmaßsysteme gehen einen etwas anderen Weg; sie untergliedern den zuvor
beschriebenen Workflow in die beiden Schritte Grobstrukturierung und Feindimensio-
nierung. Bei der Grobstrukturierung werden die Räume im Prinzip skizzenhaft anhand
von geschätzten Maßen erfasst, aus der sich die Raumeinheiten und Gebäudestruktur
geometrisch nur grob ergeben. Begleitet wird dieser Schritt durch die Definition von (geo-
metrische) Bedingungen wie beispielsweise Parallelitäten und Rechtwinkligkeiten, sodass
implizit der strukturelle Gebäudeaufbau mit allen Beziehungen bereits vorgegeben ist. Im
zweiten Schritt findet dann die Feindimensionierung statt, indem die Streckenmessungen
eingeführt werden und die bisher nur grob skizzierten Raumeinheiten nach und nach ihre
exakten Dimensionen erhalten. Die Grobskizze verwandelt sich im Ergebnis also schritt-
weise zu der finalen, geometrisch exakten Gebäudezeichnung.
In Abhängigkeit von der Aufmaßsoftware wird die Gebäudezeichnung im einfachsten
Fall als Drahtmodell erstellt, also im Wesentlichen anhand von CAD-Basiselementen wie
Linien und Bögen. Für die 3D-Bauwerksmodellierung existieren Systeme, in denen direkt
oder indirekt Flächen- oder Volumenmodelle erzeugt werden, wobei gegebenenfalls mit
parametrischer Dimensionierung gearbeitet wird. Korrekturen in der Geometrie können
dann sehr einfach durch Anpassung der Parameter umgesetzt werden. Vereinzelte neue-
re Aufmaßsysteme besitzen darüber hinaus Funktionalitäten, die direkt oder indirekt auf
BIM ausgerichtet sind, wie die objektorientierte Bauteilbildung (z. B. SiteMaster BIM2 )
oder eine Schnittstelle für die gleichzeitige Erfassung von nicht-geometrischen Daten, in-
dem zum Beispiel Dialoge für die Eingabe der Sachinformationen bereitgestellt werden
(z. B. On-Site Survey3 ). Das Handaufmaß ist für diesen Arbeitsschritt prädestiniert, weil
der Bearbeiter vor Ort und mit größtmöglicher Nähe zum Objekt agiert.
2
http://www.graebert-isurvey.com/.
3
http://www.maxmess-software.de.
22 Bauwerksvermessung für BIM 349
Der größte Nachteil des Handaufmaßes besteht in der verhältnismäßig geringen Abso-
lutgenauigkeit. Jede Raumeinheit besitzt zwar für sich gesehen eine völlig ausreichende
Nachbarschaftsgenauigkeit, aber durch das einfache Aggregieren der Räume über Türen
und Fenster, also ohne wirkliche Einbindung eines übergeordneten Referenzsystems, be-
sitzen Punkte zwischen Anfang und Ende des Bauwerks nur Dezimetergenauigkeit. Aus
diesem Grund sollte das Handaufmaß in der Bauvermessung nur als Ergänzungsverfahren
eingesetzt werden.
22.4 Tachymetrie
Die Tachymetrie besitzt in der Bauwerksvermessung nach wie vor eine große Bedeutung.
Standardmäßig werden hierbei moderne Tachymeterinstrumente mit elektro-optischer Di-
stanzmessung eingesetzt. Die Messung erfolgt entweder zu Reflektorprismen, die auf die
anzumessenden Punkte direkt oder exzentrisch aufgehalten werden, oder – seit einigen
Jahren zählt dies zum technologischen Standard – die Gebäudepunkte werden reflek-
torlos angemessen. Hierbei kann ähnlich wie beim Handlaserdistanzmesser mit einem
sichtbaren Laserstrahl gearbeitet werden. Besonderes Augenmerk muss allerdings bei der
Messung von Ecken und Kanten auf das reflektierte Signal gelegt werden, denn Teilreflek-
tionen können die Distanzmessung verfälschen. Weiterhin können auch die angemessene
Oberfläche (Farbe, Struktur, Rauigkeit) sowie der Auftreffwinkel das Ergebnis und die
Reichweite der Distanzmessung beeinflussen (siehe z. B. Möser et al. 2012). Die Ein-
führung der reflektorlosen Messung bedeutet in der Bauvermessung eine deutliche Ver-
einfachung, beschleunigt den Messvorgang und erübrigt die zweite Person am Prisma.
Primäre Messelemente sind Horizontalrichtung (Hz), Vertikalwinkel (V) und Schrägstre-
cke (s), also 3D-Polarkoordinaten, mit denen Punkte dreidimensional bestimmt sind. Die
Umrechnung der primären Messwerte in äquivalente Größen wie Horizontalstrecke (e),
Höhendifferenz (dH) oder lokale kartesische Koordinaten kann bereits im Instrument
erfolgen. Die Messdaten werden meist auf eine Speicherkarte geschrieben bzw. online
über Kabel oder Bluetooth an einen Mobilcomputer mit entsprechender Aufmaßsoftware
übertragen. Aufmaßsoftware für die Tachymetrie besitzt grundsätzlich ähnliche Funk-
tionalitäten wie jene für das Handaufmaß (vgl. Abschn. 22.3), sind jedoch (zusätzlich)
mit Schnittstellen zu Tachymeterinstrumenten ausgestattet (z. B. TachyCad4, Vitas5 ). Mo-
derne Tachymeter verfügen darüber hinaus intern über eine Vielzahl an Programmen,
die typische vermessungstechnische Berechnungsvorgänge (Bogenschlag, Freie Stationie-
rung, Zentrierungen usw.) ermöglichen.
Als Instrumentenstandorte während der Erfassungsarbeiten werden entweder die
zuvor eingerichteten Festpunkte oder die Methode der „Freien Stationierung“ benutzt
(s. Abb. 22.3). Die frei gewählten Standorte werden dabei vor Ort so ausgesucht, dass
4
http://kubit.de/index.php.
5
http://www.vitruvius.de/.
350 J. Blankenbach
die Aufmessung der Gebäudepunkte flexibel und effektiv durchgeführt werden kann.
Damit der freie Standort, der nicht notwendigerweise vermarkt wird, koordinatenmäßig
berechnet werden kann, müssen Anschlussmessungen zu mindestens zwei bekannten
Festpunkten erfolgen. Anschluss- und Erfassungsmessungen werden zumeist kombi-
niert durchgeführt. Hierbei f