Embed Size (px)
Citation preview
Chair of Computational Modelling and Simulation
Chair of Architectural Informatics
Gruppe N
ZHS Boathouse
ZHS Boathouse Chair of Computational Modeling and Simulation | Prof. Dr.-Ing. André Borrmann Chair of Architectural Informatics | Prof. Dr.-Ing. Frank Petzold Assistants: Katrin Jahr, Benedict Rechenberg Gruppe N Auer, Daniel Tragwerksentwurf, Statik, Projektkoordination (BPMN), Bericht Esser, Sebastian IFC-Exporter-Tool, Modellierung, Clash- Detection Sichen, Dong Renderings, Skizzen, Poster, Raumkonzept Speiser, Kilian Modellierung, Mengenermittlung, Planerstellung Alle gezeigten Abbildungen, Pläne, Screenshots und weitere Dateien sind im Anhang zu finden.
Inhaltsverzeichnis
1 Architektonisches Konzept .......................................... 1
1.1 Aufgabenstellung ............................................... 1
1.2 Struktur und Gebäudewirkung ........................... 1
1.3 Beschreibung des Raumkonzepts ..................... 1
1.4 Skizzen .............................................................. 2
2 Ansichten des Building Information Models ............... 3
2.1 Grundriss ........................................................... 3
2.2 Ansichten ........................................................... 4
2.3 Schnitte ............................................................. 8
3 Architektonischer Entwurf .......................................... 11
4 Process Management Map .......................................... 15
5 Statik ............................................................................. 17
5.1 Lastabtrag........................................................ 17
5.2 Vordimensionierung ......................................... 19
5.3 Änderungen am statischen System ................. 20
5.4 Modellierung des Primärträgers....................... 20
5.5 Positionsplan für statische Berechnungen ....... 21
5.6 Lastannahmen ................................................. 22
5.7 Datenschnittstelle Autodesk Revit 2017 – SOFiSTiK Structural Desktop 2016 ................. 24
5.8 SOFiSTiK......................................................... 25
5.9 Validierung der Rechenergebnisse ................. 28
5.10 Fazit Statische Berechnung ............................. 30
6 Mengenermittlung ....................................................... 31
6.1 Software und Datenaustausch ........................ 31
6.2 Validierung mit Bauteillisten ............................ 33
6.3 Fazit Mengenermittlung ................................... 36
7 Generelle Probleme in der BIM-Umgebung ............... 37
7.1 Fehlende Lokalisierung ................................... 37
7.2 Versionsunterschiede des Zentralmodells in Abhängigkeit der Projektöffnungsweise .......... 37
7.3 E-Mail Spam bei Öffnen über BIM 360 ............ 38
8 Modellüberprüfung und Umgang mit den IFC-Daten 39
8.1 Modellanalyse ................................................. 39
8.2 Fehlerkommunikation ...................................... 39
8.3 Überprüfung der IFC-Export-Ergebnisse ......... 40
9 Softwareentwicklung Revit-ParaMap ......................... 42
9.1 Motivation und Problemstellung ...................... 42
9.2 Programmfunktionen ....................................... 42
9.3 Graphische Oberfläche.................................... 42
9.4 Anwendungsbeispiele ..................................... 44
9.5 Fazit Datenaustausch und Revit-ParaMap ...... 45
10 Fazit Gesamtprojekt .............................................. 46
N
1
1 Architektonisches Konzept
1.1 Aufgabenstellung
Das vorliegende Projekt behandelt den Entwurf eines Bootshauses, welches auf dem Gelände des zentralen Hochschulsports (ZHS) am Starnberger See entstehen soll. Neben Parkflächen für mindestens sechs Boote soll ein Werkstattbereich geschaffen werden, der ausreichend Platz für Bau und Wartung der Boote zur Verfügung stellt. Das Grundstück des ZHS befindet sich am „Unteren Seeweg 5“ in 82319 Starnberg und bietet direkten Zugang zur Seefläche. Dieser Standort zeichnet sich neben der guten Anbindung an die Landeshauptstadt München vor allem durch seinen Ausblick auf die Bayrischen Alpen aus.
Die Ausarbeitung dieses Entwurfs erfolgte als interdisziplinäres Projekt eines Architekturstudenten sowie dreier Studenten des Bauingenieurwesens. Aus diesem Grund beinhaltet diese Broschüre neben gestalterischen Merkmalen auch zahlreiche ingenieurmäßige Fragestellungen und entsprechende Lösungsvorschläge.
1.2 Struktur und Gebäudewirkung
Die geplante Gebäudestruktur orientiert sich an einer Fischgräte. Die dominante Tragstruktur aus weißem Sichtbeton und den damit betonten Primärträgern stellt dabei das Skelett dar. Die Fassade soll ähnlich einer glänzenden Fischhaut gestaltet werden. Neben diesen Merkmalen wird eine schlichte Außenwirkung des Gebäudes angestrebt, um sich in die Silhouette der see-nahen Bebauung zwar sichtbar und als Blickfang, aber nicht zu aufdringlich einzufügen. Darin begründet sich die einfache, aber dennoch formschöne Gestaltung aus rechteckigen Fassaden-Elementen, in der sich Metall-Flächen mit großen Glasflächen abwechseln.
1.3 Beschreibung des Raumkonzepts
Die Raumaufteilung gliedert sich in zwei Bereiche. Der Parkbereich bietet Platz für sechs Boote, die mit einer Hebebühne aus dem Wasser gehoben werden und mit einer fahrbaren Plattform in die nebenstehende Werkstatthalle transportiert werden können. Die Werkstatt bietet ausreichend Platz für den Bau und die Wartung der Boote. Abbildung 1: Lageplan "Unterer Seeweg 5,
Starnberg"
N
2
Abbildung 2: Vorentwurf Skizzen Ansicht
1.4 Skizzen
N
3
2 Ansichten des Building Information Models
2.1 Grundriss
Abbildung 3: Grundriss A101
N
4 Abbildung 4: Ansicht Nord. A301
2.2 Ansichten
2.2.1 Nord
N
5 Abbildung 5: Ansicht Ost. A301
2.2.2 Ost
N
6 Abbildung 6: Ansicht Süd. A302
2.2.3 Süd
N
7 Abbildung 7: Ansicht West. A302
2.2.4 West
N
8 Abbildung 8: Schnitt Workshop. A201
2.3 Schnitte
2.3.1 Workshop
N
9
Abbildung 9: Schnitt Anlegestelle. A202
2.3.2 Anlegestelle
N
10 Abbildung 10: Schnitt Anlegestelle. A202
N
11
Abbildung 11: Rendering, gesehen von der seeabgewandten Seite
3 Architektonischer Entwurf
N
12
Abbildung 12: Rendering, Hebebühnenkonstruktion
N
13
Abbildung 13: Rendering, Werkstattbereich
N
14
Abbildung 14: Rendering, Vogelperspektive.
N
15
4 Process Management Map
Vorliegende grafische Darstellung orientiert sich am Workflow einer Tragwerksplanung, bei dem der Ingenieur und Architekt im Idealfall bereits von Anfang an miteinander zusammenarbeiten und iterativ ein Konzept entwickeln. Nach Abschluss der Konzeptentwicklung begann die gemeinsame Arbeit am BIM–Projekt, welches von allen Projektbeteiligten auf der Cloudplattform Autodesk BIM 360 Team abgerufen und im Rahmen ihrer Berechtigungen bearbeitet werden konnte. Referenzdateien wie PDF-Dokumente, Präsentationen oder Berichte, die nicht direkt zum BIM-Modell an sich gehören, wurden bei über den Cloud-Dienst Dropbox mit einer klar definierten Ordnerstruktur geteilt. Wie Abbildung 15 zu entnehmen ist, bildete BIM 360 Team die zentrale Arbeitsplattform aller Akteure, wobei je nach Bedarf das BIM-Modell in Downstream-Applikationen (SOFiSTiK, RIB iTWO, Solibri Model Checker) exportiert werden konnte. Dabei wurden die Schnittstellen des SOFiSTiK-Plugins sowie der cpixml-Export für RIB iTWO genutzt. Für die Modellüberprüfung in Solibri stellte das IFC-Format den richtigen Ansatz dar.
Nach Abschluss der statischen Berechnungen und Anpassung einiger Tragwerkselemente konnten die davon abhängigen Prozesse der Mengenermittlung und Visualisierung gestartet werden. Aufgrund einer Vorbemessung waren nur geringe Anpassungen am Tragwerk notwendig. Der Prozess der Modellprüfung wurde periodisch unter Einbezug der im Rahmen des Projektes entwickelten Software „Revit-ParaMap“ durchgeführt. Die Software-Entwicklung stellte einen parallel verlaufenden Prozess dar, da die Ergebnisse nicht für den Arbeitsfortschritt der anderen Projektbeteiligten notwendig war, da eine händische Generierung der entsprechenden Dateien für den Revit-IFC-Export zu jedem Zeitpunkt möglich war. Um den Prozessfortschritt zu überwachen, wurden wöchentliche Treffen durchgeführt, die zur Klärung von Problemen und der Absprache des weiteren Vorgehens genutzt wurden. So konnte der zu Beginn angedachte Prozessablaufplan in weiten Teilen in die Praxis umgesetzt werden.
N
16
Abbildung 15: Process Management Map.
N
17
Abbildung 18: Sekundärträger mit Belastung aus Dach.
Abbildung 17: Primärträger mit Belastung aus Eigengewicht und Last aus Sekundärträgern, Neigungen vernachlässigt.
5 Statik
Es handelt sich um ein aus Primär- und Sekundärträgern bestehendes Rahmentragwerk, welches sich für Hallen bewährt hat. Die 6 doppelt gevouteten Stahlbetonprimärträger mit Abmessungen von bmean/hmean = 30/90 cm bilden mit den Stahlbetonstützen der Abmessung b/h = 60/60 cm ein Rahmentragwerk mit der Höhe von h = 11.70 m und einer Spannweite von l = 14.80 m. Zur Gewährleistung des flächigen Lastabtrags sind zwischen den 6 Primärträgern jeweils 5 Stahlprofil-Sekundärträger der Spannweite 8.00 m eingebaut, welche eine maßgebende Einzugsfläche orthogonal zur Spannrichtung von 3.50 m besitzen. Aufgrund ausreichend großer Fundamente werden die dem Wasser abgewandten Stützen als eingespannt angenommen, die Stützen am Wasser sind als Pendelstützen zu betrachten. Für Stahlbauteile wird die Stahlgüte S235 gewählt, für die Betonbauteile wird die Festigkeitsklasse C25/30 festgelegt. Die in den Seitenwänden verbauten Stahlträger besitzen lediglich konstruktiven Charakter für den Abschluss der Fassade, welche aus Kapazitätsgründen an den Stahlbetonstützen befestigt werden. Die Bodenplatte wird vom Rahmentragwerk vollständig entkoppelt und könnte aus dem Berechnungsmodell ausgegliedert werden. Aus Gründen der Validierung wurde auf die Verwendung von Flächenelementen verzichtet.
5.1 Lastabtrag
Die auf das Dach wirkenden Schnee- und Windlasten werden unter Berücksichtigung der Einzugsflächen als Ersatzlasten auf die Sekundärträger aufgebracht. Von den Sekundärträgern wird die Last auf die Primärträger und von dort über Biegung auf die Stützen weitergeleitet, welche die Lasten über Druck und Biegung in die Fundamente abtragen. Die an den Fassaden angreifenden Windlasten wurden als Ersatzlasten auf die vertikalen Stützen aufgebracht und werden über Biegung abgetragen.
N
18
Abbildung 19: Erster Tragwerksentwurf, mit Raster. Ohne Stützen im Parkbereich, in blau für Architekten zu gestaltende Fassadenflächen.
N
19
Abbildung 20: Ersatzsystem des Primärträgers für Vordimensionierung
5.2 Vordimensionierung
Zur Abschätzung der notwendigen statischen Nutzhöhe existiert im Stahlbetonbau folgende Entwurfsformel, welche normale (oben) und erhöhte Anforderungen (unten) berücksichtigt. Diese können aus der Begrenzung der Biegeschlankheit nach DIN EN 1992-1-1+NA, 7.4.2 abgeleitet werden.
erf d =
[
l
K∙35=
15.00
1.30∙35
l2
K2∙150=
15.002
1.302∙150
=0.33 m
0.89 m
K = 1.30 ist dabei der Beiwert für das statische Ersatzsystem, also eines einseitig eingespannten Einfeldträgers. l = 15.00 m ist die Länge des Primärträgers im Rahmen der Vordimensionierung. Da die Abschätzung lastunabhängig erfolgt und aufgrund des Abstandes von 8.00 m nicht mit normalen Anforderungen zu rechnen ist, wird die Bauteilhöhe h = d+d1 = 0.60 m als Mittelwert der beiden Abschätzungen gewählt.
Zur Vordimensionierung der Sekundärträger wird das einwirkende Moment in Feldmitte des Einfeldträgers berechnet und aus Stahlprofiltabellen ein geeignetes Profil gewählt.
MEd=[γG∙ (g
k,roof+g
k,beam) +γQ∙(wk+sk)] ∙l2
8=
=[1.35∙(1.00+1.05)+1.50∙(7.00+6.30)]∙82
8=182 kNm
Das Profil HEA 340 mit MRd = 394.8 kNm wird in erster Näherung gewählt. Dies wird durch die sehr vereinfachte elastisch-elastische Nachweisführung sowie fehlenden Tragfähigkeitsreserven des Einfeldträgers und dem nicht betrachteten Mitwirken der Stahlprofile bei der Aussteifung in Dachebene begründet. Der normative Ursprung der oben zugrunde gelegten Lasten wird im folgenden Kapitel erklärt.
N
20
5.3 Änderungen am statischen System
Im Laufe des Projektes ergaben sich folgende wesentliche Änderungen hinsichtlich des statischen Systems. - Das statische System der Sekundärträger
(Abbildung 21) wurde von Einfeldträgern auf beidseitig eingespannte Träger geändert, um
- für die Aussteifung eine Scheibentragwirkung des Daches zu erzeugen. - für eine gleichmäßigere Auslastung der Träger zu sorgen, da das Einspannmoment die Belastung in Feldmitte reduziert.
- Unterzüge im Bereich der Boote wurden aufgrund
sehr hoher Belastung (≥ 500 kN) und ungünstiger Spannweite (≥ 8 m) und damit hoher Belastung aus trapezförmigen Momentenverlauf (≥ 4 MNm) zu Gunsten der Stahlbetonstützen verworfen, um Lasten günstiger in den Baugrund übertragen zu können. Siehe Abbildung 23.
- Im Zuge der Tragwerksoptimierung wurde der
Primärträger doppelt angevoutet, um schlanker zu wirken. Diese Maßnahme hatte jedoch keinen Einfluss auf die Tragfähigkeit des Balkens, da weder die Betondruckzone noch die statische Nutzhöhe zwischen Bewehrung und Betondruckzone verändert wurden.
5.4 Modellierung des Primärträgers
Zur Modellierung der doppelten Voutung des Primärträgers wurden mehrere Modellierungs-Varianten getestet. - Verwendung einer adaptiven Familie: Der
Umgang mit dieser Familienvorlage erfordert viel Geschick und Gefühl für Abhängigkeiten zwischen Linien und anderen Bauteilen. Leider ist die Definition des Berechnungsmodells in adaptiven Familien sehr komplex, sodass diese Lösung verworfen wurde.
- Modellierung der Trägergeometrie mit Autodesk Dynamo: Dieser Revit-Aufsatz bietet die Möglichkeit, graphenbasierte Programmierung zu verwenden. Hierbei gelang die Modellierung und Parametrisierung des Trägers, dennoch sind auch hier Probleme mit dem Berechnungsmodell aufgetreten.
- Verwendung einer Balken-Familien-Vorlage: Die
doppelte Voutung kann durch Anfangs- und Endquerschnitt definiert werden, die über den Befehl Verschmelzung zum gewünschten Ergebnis führten.
Der Dynamo-Code ist im digitalen Anhang zu finden.
N
21
Abbildung 21: Änderung des Sekundärträgersystems, z.B D3-E3
5.5 Positionsplan für statische Berechnungen
- Die Achsen in Richtung der Primärträger besitzen die Buchstaben Ⓐ, Ⓑ, Ⓒ, Ⓓ, Ⓔ und Ⓕ.
- Hingegen werden die Achsen in Richtung der
Sekundärträger als ①, ②, ③, ④, ⑤ bezeichnet.
Soll ein bestimmter Träger angesprochen werden, wird dieser über seine Endknoten gekennzeichnet, z.B A5-B5 für den Träger links unten im Positionsplan. Soll eine ganze Achse angesprochen werden, geschieht dies über die Achsenbezeichnung, z.B 2-2 oder B-B.
Abbildung 22: Positionsplan – Trägerraster.
8.00 8.00 8.00 8.00 8.00
3.5
0
14.8
0
Abbildung 23: Ersetzen des Unterzugs in A5-D5 durch Stützen, Änderung der Stützweite von 9m auf 8m in Entwurf
N
22
5.6 Lastannahmen
5.6.1 Schnee
Gemäß der DIN EN 1991-1-3:2010-12 und DIN EN 1991-1-4/NA:2010-12 berechnet sich die Schneelast für das Bootshaus in Schneelastzone 2 auf Höhe von 585 m. ü NN zu:
sk= max [
0.85
0.25+1.91∙ (585+140
760)
2= 2.00kN
m2
Bezugnehmend auf den Positionsplan ergibt sich mit der Einzugslänge, d.h. dem Abstand zweier Sekundärträger von e = 3.50 m eine umgerechnete Linienlast von sk = 7.00 kN/m auf einen Sekundärträger. Aufgrund der gleichmäßig verteilten Belastung wird der oben berechnete Linienlast auf alle Sekundärträger aufgebracht.
5.6.2 Wind
Windlasten sind in DIN EN 1991-1-4:2010-12 und DlN EN 1991-1-4/NA:2010-12 geregelt. Es wird das vereinfachte Verfahren für Bauwerke bis 25 m Höhe angewandt. Das Bootshaus am Starnberger See befindet sich in der Windlastzone 2. Da das Gebäude direkt an eine große Wasserfläche angegrenzt, werden auf der
sicheren Seite die Basiswerte für Küstenlage angesetzt. Für h ≥ 10 m darf der vereinfachte Geschwindigkeitsdruck qp zu 1.00 kN/m² angenommen werden. Analog den Schneelasten wurden die Windlasten mit Einzugsflächen umgerechnet und auf das abtragende Bauteil als Ersatzlast angesetzt. Dies hätte durch die Anwendung eines Lastverteilungselementes in SOFiSTiK vermieden werden können. Die Lasteinzugsfläche auf dem Dach beträgt es = 3.50 m, dies entspricht dem Abstand der Sekundärträger. Auf den angeströmten Seitenflächen beträgt der Abstand zwischen den Stützen ep = 8.00 m. Aus Gründen der Übersichtlichkeit und späteren Validierung wurden für die verbleibenden Anströmrichtungen keine neuen Lastfälle über „Berechnung“→ „Lastfälle“ hinzugefügt. Die Außendruckbeiwerte für Gebäude mit vertikalen Wänden und rechteckigem Grundriss ergeben sich gemäß folgender Tabelle. Es sei angemerkt, dass diese bereits interpoliert wurden. Um die verschiedenen Belastungen auf das Dach zu modellieren, eignet sich das Sekundärträgersystem sehr gut, da die verschiedenen Normflächen (F, G, H, I) den einzelnen Trägern ausreichend genau zugeordnet werden können.
N
23
Der für das System günstig wirkende seitliche Sog (A, B) wurde auf der sicheren Seite liegend vernachlässigt. C muss gemäß Norm für die gegebene Geometrie nicht angesetzt werden.
cpe,10 wk = cpe,10∙qp∙e [kN/m] Bauteil
A -1.20 -
B -0.80 -
C -0.50 aufgrund e ≥ d keine C - Fläche
D +0.77 =0.77∙8.00 = 6.15 Stützen, Luv
E -0.44 =0.44∙8.00 = 3.49 Stützen, Lee
F -1.80 =1.80∙3.50 = 6.26 A5B5, E5F5
G -1.20 =1.20∙3.50 = 4.17 B5C5, C5D5 D5E5
H -0.70 =0.70∙3.50 = 2.44 4-4,3-3,2-2
I -0.60 =0.60∙3.50 = 2.10 1-1
5.6.3 Verkehrslasten
Der Ansatz der Nutzlast für das betrachtete Bauwerk ergibt sich nach DIN EN 1991-1-1/NA, Tab. 6.1 DE aufgrund der Einordnung in Kategorie E1.1 zu qk = 5.00 kN/m². Die Last wird als gleichmäßig verteilte Flächenlast auf die Bodenplatte angesetzt. Durch die Entkopplung der Bodenplatte vom restlichen Tragwerk hat diese keine Auswirkungen auf das Rahmentragwerk. Die Bodenplatte könnte somit hinsichtlich der Berechnung des Dachtragwerks vernachlässigt werden, d.h. aus dem Berechnungsmodell ausgegliedert werden.
5.6.4 Eigengewicht
Eigengewichtslasten der tragenden Bauteile müssen im Rahmen der statischen Berechnung nicht ermittelt werden, da dies automatisch durch SOFiSTiK erfolgt. Für nichttragend angenommene Bauteile (z.B Dachaufbau) muss das Gewicht per Hand ermittelt und auf das Tragwerk aufgebracht werden. Es ergibt sich bei Annahme des Dacheigengewichts von 0.25 kN/m² und einer Einzugslänge der Sekundärträger von 3.50 m eine zusätzliche Last von gut 1.00 kN/m auf die Stahlprofile.
N
24
5.7 Datenschnittstelle Autodesk Revit 2017 – SOFiSTiK Structural Desktop 2016
5.7.1 Vergabe der Auflagerbedingungen
Nachdem die Auflagersymbole als Familie in das Zentralmodell geladen und zugewiesen wurden, konnten diese vergeben werden. Dies funktionierte auch weitestgehend problemlos, jedoch ist zu bemängeln, dass bei Vergabe (benutzerdefinierter) Auflagerbedingungen oftmals nicht klar ist, auf welches Koordinatensystem die Eingabe bezogen wird, wenn Freiheitsgrade bei „Translation in“ und „Drehung um“ definiert werden sollen. Eine dauerhaft visuelle Unterstützung wäre wünschenswert, da ein temporär eingeblendetes Koordinatensystem1 ohne Achsenbeschriftungen wenig hilfreich ist.
5.7.2 Vergabe der Lasten
Das Arbeiten mit „Abhängigen Linienlasten“ und Zuordnung zu „Einzellastfällen“ funktionierte problemlos. Das Eingeben der Lasten bringt einen verhältnismäßig hohen Zeitaufwand mit sich und wird dabei sehr schnell unübersichtlich, wenn auf einen Stab mehrere Lasten unterschiedlicher Größe einwirken, da diese nicht wie bei anderen Stabwerksprogrammen üblich übereinandergesetzt werden, sondern aufeinander dargestellt werden. Dies stellt bei ungefähr gleichen Lasten ein Usability-Problem dar, da diese später nur noch schwer
1 vgl. „RVT_ALB1.png“,“RVT_ALB2“.png
auszuwählen sind.2 Außerdem besteht auch hier das Problem des fehlenden Koordinatensystems.
5.7.3 Reparieren des Berechnungsmodells
Folgendes Kapitel greift etwas vor und setzt eine erste fehlgeschlagene Berechnung in SOFiSTiK voraus. SOFiSTiK brach die Rechnung mit Hinweis auf ein kinematisches System ab, die angegebene Knoten gehörten zu den Endknoten der Sekundärträger. Dies ließ zuerst vermuten, dass sich der Sekundärträger, der hier noch als gelenkig gelagerter Einfeldträger modelliert war, um seine eigene lokale x-Achse drehen konnte. Nachdem auch benutzerdefinierte Auflager keine Abhilfe schufen, fiel auf, dass die Knoten und Systemlinien im Revit-Berechnungsmodell auf den ersten Blick miteinander verbunden waren, Bei näherem Heranzoomen stellte sich allerdings heraus, dass es einen kleinen, kaum sichtbaren Abstand zwischen Systemlinie und Knoten gab und diese somit gar nicht gekoppelt waren. Die Sekundärträger wiesen demnach für SOFiSTiK keine Auflagerbedingungen auf. Alle Knoten der Sekundärträger mussten manuell an die Systemlinie der Primärträger verschoben werden.
5.7.4 Export nach SSD2016
Es bestand das Problem, dass sich ein auf dem Server liegendes Zentralmodell nicht nach SSD exportieren ließ. Es musste eine lokale Kopie des
2 vgl. „RVT_LOAD1.png“, „RVT_LOAD2.png”
N
25
Zentralmodells erzeugt werden, was einerseits der Grundidee von BIM widerspricht, da Änderungen in der lokalen Kopie wieder manuell in das Zentralmodell eingepflegt werden müssen, um Versionskonflikte zu vermeiden. Wird mit lokalen Kopien des Zentralmodells gearbeitet, ist es wichtig, dass diese während des Speicherns vom Zentralmodell gelöst werden. Dies führte zu Beginn zu zahlreichen Fehlermeldungen, die im Laufe des Projekts aber vermieden werden konnten.
5.8 SOFiSTiK
5.8.1 Import nach SSD2016
Nachdem das korrigierte, belastete und lokal abgespeicherte Zentralmodell nach SSD2016 exportiert werden konnte, wurde überprüft, ob alle Auflagerbedingungen, Lasten, Querschnitte und Materialien richtig aus Revit übernommen wurden. Dies war nicht der Fall, da in SOFiSTiK für Stahlbauteile den Betonstahl B500B (EC2) statt S235 für die Sekundärträger und C24/29 anstatt C25/30 als Betongüte für die Primärträger verwendet wurde. Dies wurde manuell in SOFiSTiK korrigiert. Alle Elemente befinden sich im Gültigkeitsbereich der Bernoulli – Hypothese, demnach wurden Stabelemente beim Meshing verwendet.
5.8.2 Definition der Lastfallkombinationen
Die Verkehrslast (LF2) wirkt nur auf die Bodenplatte und wurde vernachlässigt. Die Lastfälle Eigengewicht G (LF1), Wind W (LF3) und Schnee S (LF4) wurden richtig übernommen.
Im Projektbrowser lässt sich der Task „Lastfälle kombinieren“ anlegen und Lastfälle komfortabel mit Teilsicherheits- und Kombinationsbeiwerten versehen. Für den Grenzzustand der Tragfähigkeit ergeben sich folgende 2 Lastfallkombinationen. LF 1001
γG∙G + γQ∙W + γQ∙ψ0∙S = 1.35G + 1.50W +
(1.50∙0.5)S
= 1.35G + 1.50W + 0.75S
LF 1002
γG∙G + γQ∙ψ0∙W + γQ∙S=1.35G + (1.50∙0.6)W + 1.50S
= 1.35G + 0.90W + 1.50S
N
26 Abbildung 24: Berechnungsmodell, Lasten ausgeblendet. Hintere Stützen eingespannt, vorne gelenkig.
Für den Grenzzustand der Gebrauchstauglichkeit ergibt sich der LF1003 zu
G + W + S=1.00G + 1.00W + 1.00S.
Teilsicherheits- und Kombinationsbeiwerte sind in DIN EN 1990/NA, Tab. 1.2(A)-(C) und DIN EN 1990/NA, Tab. NA. 1.1 geregelt.
5.8.3 Berechnung
Zum Schluss sind noch die Tasks „Berechnung Einzellastfälle“, „Lastfälle kombinieren“ und „Berechnung der kombinierten Lastfälle“ zu erstellen. Es ist darauf zu achten, diese in einer chronologisch sinnvollen Reihenfolge im Reiter anzuordnen. Abschließend kann die Berechnung gestartet werden.
N
27
Abbildung 25: Verformungsfigur Lastfall Eigengewicht G.
Abbildung 26: Verformungsfigur Lastfall Schnee S.
Abbildung 27: Verformungsfigur Lastfall Wind W.
N
28
5.9 Validierung der Rechenergebnisse
5.9.1 Qualitative Validierung der Verformungen der Einzellastfälle
Um vorab grobe Fehler ausschließen zu können, eignet sich ein Abgleich der Verformungsfiguren der Einzellastfälle Eigengewicht, Wind und Schnee mit dem Ingenieurverständnis. Es sei auf die 3 *.gif – Dateien im Anhang verwiesen, welche die Verformungen animieren.3 Unter Eigengewicht G biegt sich der Primärträger nach unten durch und die Auslastung der Betondruckzone am oberen Rand in Feldmitte ist gut erkennbar. Die Stützen am Wasser biegen sich aufgrund ihrer Neigung und des sich damit einstellenden P∆ - Effektes nach vorne. Die Einspannungen erzwingen an den Stützen eine Tangente mit der Systemlinie. Unter Schneelast S stellen sich ähnliche Verformungen wie bei Lastfall G ein. Zusätzlich ist die erhöhte Durchbiegung der Sekundärträger aufgrund der höheren Schneebelastung erkennbar. Ebenso lässt sich der Effekt der beidseitigen Einspannung der Sekundärträger in zwei Aspekten gut erkennen. Zum einen erkennt man die horizontale Tangente der Sekundärträger in den Innenfeldern des
3 vgl. „SOFiSTiK_WIND.gif“, „SOFiSTiK_SNOW.gif“,
„SOFiSTiK_DEAD.gif“,
Mehrfeldträgersystems über den Primärträgern sehr gut. Zum anderen entsteht durch die Einspannung an den äußeren Primärträgern eine Exzentrizität, welche diese tordiert. Dieser Effekt tritt an den inneren Primärträgern nicht auf, da diese eine beidseitige Exzentrizität erfahren. Ebenso erfüllt die Verformungen unter der Windlast W die Erwartungen. Das Gebäude verformt sich in Richtung der Anströmrichtung. Die Durchbiegung der eingespannten, konstruktiven Fassadenriegel ergibt sich zu einer S-Welle, welche sich aus Kompatibilität mit der Stützenverformung ergeben muss. Die Einspannung der Stützen ist wieder erkennbar.
5.9.2 Quantitative Validierung der FEM - Resultate
5.9.3 Normalkraftverlauf
Der ersten Präsentation ist zu entnehmen, dass damals im Rahmen einer überschlägigen Vorbemessung eine Kraft am Stützenkopf von 500 kN veranschlagt wurde. Betrachtet man den Normalkraftverlauf der SOFiSTiK – Berechnung, ergeben sich Lasten von ungefähr 500 kN am oberen Stützenkopf mit deutlich weniger als 10% Abweichung. Die Differenzen lassen sich mit damals fehlenden Annahmen hinsichtlich Abmessungen und Einzugsflächen, fehlenden Lastfallkombinationen und
N
29
Abbildung 28: Querkraftanalogie.
der Wahl eines einseitig eingespannten Ersatzsystems, welches die Drehfedersteifigkeit der Stütze nicht abbilden konnte, begründen.4
5.9.4 Momentenverlauf My
Für die beidseitig eingespannten Sekundärträger in Achse A5-B5 ergibt sich gemäß SOFiSTiK ein Biegemoment von 51.8 kNm. Für den maßgebenden LF 1002 ergibt sich eine Linienbelastung von
γG ∙ G + γQ ∙ ψ0 ∙ W + γQ∙S =
=1.35∙(1.00 + 1.05) + 0.90∙(6.30) + 1.50∙(7.00)
=18.93 kN/m
Für einen beidseitig eingespannten Träger ergibt sich das Moment in Feldmitte zu
ql2
24=
18.93∙82
24= 50.5 kNm ≅ 51.8 kNm.
5.9.5 Querkraftverlauf Vz
Wie zu erwarten, ist ein linearer Querkraftverlauf durch Eigengewicht des Primärträgers mit Sprüngen aus den Einzellasteinleitungen der wind- und schneebelasteten Sekundärträger aufgetreten.5 Der
4 vgl. „N.xps“
Nulldurchgang in Achse 3-3 korrespondiert mit dem Momentenmaximum. Betrachtet man erneut den Sekundärträger in Achse A5-B5, leitet dieser gemäß SOFiSTiK eine Einzellast von 79.0 kN in den Primärträger B-B ein. Dies sollte mit untenstehender Berechnung korrespondieren.
ql
2=
18.93∙8
2=75.75 kN ≅ 79.00 kN
5.9.6 Torsionsmoment Mx
Der Torsionsmomentenverlauf6 kann mittels der Querkraftanalogie validiert werden. Der Verlauf ist qualitativ analog einem beidseitig eingespanntem Träger mit Einzellasteinleitungen an den Orten der Anschlüsse der Sekundärträger. Die Größe der Torsionsmomenteneinleitung ist von der Ausführung Anschluss und dessen Ausmitte abhängig.
5vgl. „Vz.xps“ 6 vgl. „Mx.xps“
N
30
5.9.7 Durchbiegungen
Die maßgebende Durchbiegung ergibt sich zu 11.9 mm im Bereich der Sekundärträger. Verglichen mit dem empfohlenen Grenzwert von l/500 = 16 mm liefert dies ein akzeptables Ergebnis.
5.9.8 Ausnutzungsgrade
Im maßgebenden Lastfall beträgt der Ausnutzungsgrad 78%, wobei erkenntlich ist, dass sich dieser vorwiegend auf die Stahlträger bezieht. Im Stahlbau kann durch Vergleich von Einwirkungsschnittgrößen und Interaktionen mit Widerständen sehr gut in Ausnutzungsgraden gerechnet werden. Im Stahlbetonbau hingegen wird dem Beton stets eine volle Ausnutzung am oberen Rand der Betondruckzone zur wirtschaftlichen Bemessung unterstellt und es gibt per se keinen Ausnutzungsgrad, da in diesem Fall mehr Bewehrungsstahl eingelegt wird, um die Betondruckzone zu entlasten.
5.10 Fazit Statische Berechnung
Der Großteil der FEM – Berechnungen liefert sinnvolle und nachvollziehbare Ergebnisse, welche mit etwas Aufwand durch Handrechnung validierbar sind. Aufgrund einer Vorbemessung mussten nur geringfügige Änderungen vorgenommen werden.
Dennoch sind einige Aspekte schwer nachzuvollziehen. Obwohl die seeseitigen Stützen in Revit als Pendelstützen und dementsprechende Auflager definiert sind, nehmen sie ein Biegemoment auf, welches nicht der Größe eines Biegemoments entspricht, was vorhanden wäre, wenn die Stütze komplett eingespannt berechnet werden würde. Ein möglicher Ansatz zur Erklärung wäre, dass die Kraft auf der Stütze exzentrisch einwirkt und somit ähnlich dem Torsionsmoment ein Moment durch Ausmitte erzeugt, die Größe der Exzentrizität ist Berechnungsmodell jedoch nicht bekannt.
N
31
6 Mengenermittlung
6.1 Software und Datenaustausch
Zur Erstellung eines Leistungsverzeichnisses werden zunächst die Mengen aller Strukturobjekte ermittelt. Um ein möglichst anschauliches Ergebnis präsentieren zu können, werden diese in Unterkategorien gruppiert. Für die Mengenermittlung wird die Software RIB iTWO verwendet. iTWO bietet mehrere Möglichkeiten zum Datenaustausch. Der Austausch soll gemäß den Anforderungen des BIM Arbeitsprozesses in einem gemeinsamen Dateiformat durchgeführt werden – meist wird IFC gewählt. Da allerdings die Schnittstelle zwischen Revit und iTWO durch ein eigenes Plugin über das Dateiformat cpixml geschlossen wird, wird auch in diesem Projekt eine Datei dieses Formates für die Mengenabfrage verwendet. Dadurch soll der Gefahr des Datenverlustes präventiv entgegengewirkt werden. Etwas näher werden die Fassaden betrachtet. Revit ermöglicht es nicht, Standard-Wände in geneigte Fassadensysteme umzuwandeln. Daher wurden diese auf Grundlage einer geneigten Fläche im Modell als Fassadensysteme modelliert. Ein Fassadensystem ist ein Bauteil, welches aus einem Fassadenraster, Pfosten und Elementen besteht. Wände und Dächer können nicht als solches erstellt werden. Bauteile dieser Kategorien werden als Dach oder Wand erstellt und anschließend mit Fassadenelementen
ausgestattet. Daher finden sich im Modell Glasfassaden in Form von Wänden sowie in Form von Fassadensystemen wieder. Aus architektonischer Sicht ergibt sich daraus kein Unterschied. Allerdings liegt vermutlich hier der Fehler, dass es in iTWO nicht möglich ist, die Fläche der Verglasungselemente zu bestimmen. Als Ergebnis wird Null zurückgegeben. Dies galt sowohl beim Filtern nach den einzelnen Fassadenelementen als auch bei Auswählen der gesamten Wandsysteme. Aus diesem Grund wird direkt auf Werte zugegriffen, welche von Revit übergeben werden. Im Fall der Verglasung kann mit der Abfrage "QTO(Typ:="\$Fläche")" die Fläche aller Verglasungselemente aus Revit ohne geometrische Berechnung übernommen werden. Dieses Vorgehen wird auch in anderen Kategorien angewendet. Die Ergebnisse der Mengenermittlung sind auf der folgenden Seite dargestellt.
N
32
Schlüssel Bezeichnung Menge Einheit
1 Stahlbetonarbeiten
1.10 Gründung
1.10.10 Bodenplatte
1.10.10.10 Beton inkl. Bewehrung 146,922 m³
1.10.10.20 Schalung 39,908 m²
1.10.20 Stützenfundamente
1.10.20.10 Beton inkl. Bewehrung 52,200 m³
1.10.20.20 Schalung 100,800 m²
1.20 Wände
1.20.10 Beton inkl. Bewehrung 65,090 m³
1.20.20 Schalung 445,196 m²
1.30 Stützen
1.30.10 Beton inkl. Bewehrung 50,310 m³
1.30.20 Schalung 335,346 m²
1.40 Träger
1.40.10 Beton inkl. Bewehrung 33,198 m³
1.40.20 Schalung 237,804 m²
2 Stahlbauarbeiten
2.10 HEA340 200,000 m
2.20 HEB200 226,379 m
Schlüssel Bezeichnung Menge Einheit
3 Dächer
3.10 Titandacheindeckung
verzinkt
593,684 m²
4 Fenster + Türen
4.10 Fenster
4.10.10 Dachfenster 12 Stck.
4.10.20 Verglasung 30,648 m²
4.20 Türen
4.20.10 Rolltore 3 Stck.
4.20.20 Drehflügel 2-flüglig
Stahlzarge
1 Stck.
4.20.30 Drehflügel 1-flüglig
Glas
2 Stck.
5 Fassaden
5.10 Metallpaneele 503,379 m²
5.20 Verglasung 361,109 m²
5.30 Pfosten + Riegel inkl.
Dachfenster
913,695 m
N
33
Abbildung 29: Bodenplatte, Stützenfundamente.
6.2 Validierung mit Bauteillisten
Beim Berechnen der Mengen können viele Fehler auftreten. Mit großer Sorgfalt wurde kontrolliert, ob in jeder Untergruppe die für die Berechnung relevanten Elemente herangezogen werden. Um eine weitere Validierung der Werte durchführen zu können, eignen sich Bauteillisten in Revit. Diese entsprechen einer weiteren Ansicht des Modells in die sämtlichen Bauteile einer bestimmten Kategorie aufgelistet sind. Durch Filtern, Sortieren und Formatieren können diese auf individuelle Bedürfnisse angepasst werden. Allerdings ist der Benutzer dahingehend eingeschränkt, dass er nur auf vorhandene Parameter zurückgreifen kann. Außerdem muss Vorsicht geboten sein, da in diesen Listen auch das Modell geändert werden kann. Im Folgenden werden nun die in Revit ermittelten Mengen mit den oben bestimmten Werten verglichen. Dazu werden einige Kategorien herangezogen. Es wird festgestellt, dass kaum Abweichungen vorliegen und diese in den meisten Fällen auf Rundungsfehler zurückzuführen sind.
6.2.1 Bodenplatte und Fundamente
Autodesk Revit
RIB iTWO
Stahlbetonvolumen Bodenplatte
146,92 146,92 m³
Stahlbetonvolumen Einzelfundamente
52,20 52,20 m³
N
34
Abbildung 30: Träger und Stützen.
Abbildung 31: Wände.
6.2.2 Stützen und Träger
Autodesk Revit
RIB iTWO
Stahlbetonvolumen Stützen
50,29 50,31 m³
Stahlbetonvolumen Träger
33,20 33,20 m³
HEB200 - Profile 226,38 226,38 m
HEA340 - Profile 200,00 200,00 m
6.2.3 Wände
Autodesk Revit
RIB iTWO
Stahlbetonvolumen Wände
65,09 65,09 m³
N
35
Abbildung 32: Fassadenelemente. Abbildung 33: Dach.
6.2.4 Fassade
Autodesk Revit
RIB iTWO
Fläche Verglasungselemente
371,74 391,76 m2
Fläche Metallpaneele 503,38 503,38 m2
Länge Pfostenelemente
913,67 913,70 m
6.2.5 Dach
Autodesk Revit
RIB iTWO
Fläche Dacheindeckung
593,68 593,68 m2
N
36 Abbildung 34: Screenshot Revit.
6.3 Fazit Mengenermittlung
Wie bereits dargestellt, werden durch beide Berechnungsmethoden nahezu gleiche Ergebnisse erzielt. RIB iTWO bietet den großen Vorteil, dass verschiedene Berechnungen an den Objekten durchgeführt werden können. Autodesk Revit hingegen ermöglicht nur den Zugriff auf vorbestimmte Parameter. Über die Parameter können auch in Revit verschiedene Berechnungen durchgeführt werden, was am Beispiel der Familien der Tragwerksstützen im Folgenden erläutert wird. In der Abbildung ist zu erkennen, dass der Parameter „Schalungsfläche“ zur Familie hinzugefügt wurde. Dabei handelt es sich um einen "geteilten" Parameter. Dadurch kann auch außerhalb der Familie auf die Variable zugegriffen werden. In der unten markierten Formel ist die Berechnung der erforderlichen Schalungsfläche hinterlegt.
Da es sich um einen geteilten Parameter handelt, kann dieser nun auch zu der Bauteilliste der Fundamente hinzugefügt werden. In der entsprechenden Spalte wird der Wert dieser Variable übernommen. Es ist zu erkennen, dass die Formel für jeden Typen der Familien angewendet wird. Allerdings wird in dieser Bauteilliste auch ein Nachteil von Revit ersichtlich. Bei der Stahlbetonbodenplatte handelt es sich um eine Systemfamilie. Diese kann nicht bearbeitet werden. Somit kann auch der Parameter „Schalungsfläche“ nicht hinzugefügt werden.
N
37
Abbildung 35: Lokalisierungsprobleme.
7 Generelle Probleme in der BIM-Umgebung
7.1 Fehlende Lokalisierung
Es bestand das Problem, dass Familien keine Lokalisierung besitzen. Verwendet Person X Autodesk Revit mit chinesischem Sprachpaket und verwendet eine vordefinierte Familie, wird allen anderen beteiligten Personen dieses Bauteil nicht mit deutschen Namen angezeigt, sondern mit der chinesischen Bezeichnung. Dieses Verhalten ist für Familien und Parameter, die der Nutzer selbst erstellt hat, naheliegend. Es wäre dennoch wünschenswert, dass Standard-Familien eine Sprachlokalisierung aufweisen würden. Beheben ließ sich das Problem durch Bereitstellung der Familien im deutschen Sprachpaket für alle Projektteilnehmer. Alle Funktionen, die nicht direkt mit Familien in Zusammenhang stehen, konnten in ihrer Sprache nicht angepasst werden. Dazu gehört zum Beispiel die standardmäßige Benennung von neu generierten Ansichten oder Renderings. Dieses Problem konnte durch entsprechende Kommunikation über den Autodesk-internen Communicator angegangen werden, wenngleich es nicht gelungen ist, alle Daten im Projekt auf eine Sprache zu bringen.
7.2 Versionsunterschiede des Zentralmodells in Abhängigkeit der Projektöffnungsweise
In einem frühen Projektstadium wurde festgestellt, dass Versionsunterschiede im Zentralmodell bestehen, wenn man die gleiche Datei auf verschiedene Arten öffnet. Öffnet man das Projekt in Revit über „Öffnen“, bekommt man den aktuellsten Stand der Datei, die sich in der Cloud befindet. Öffnet man hingegen per Doppelklick die gleiche Projektdatei im BIM 360 – Ordner, bekommt man eine nicht aktuelle Datei – obwohl alle Änderungen an das Zentralmodell synchronisiert wurden. Die Lösung dieses Problems liegt in der Funktion „veröffentlichen“. Erst damit wird auch die Revit-Datei
N
38
Abbildung 36: 66 Emails bei Änderungen am Projekt.
im BIM-360-Ordner aktualisiert und kann über die Ordnerstruktur erreicht werden. Es sei angemerkt, dass der „veröffentlichen“-Button nur über ein Untermenü erreichbar ist und eine andere Positionierung in der Revit-Oberfläche sinnvoll wäre. Die Unterscheidung in Synchronisieren und Veröffentlichen ist im Hinblick auf größere Arbeitsgruppen dennoch sinnvoll. Wünschenswert wäre darüber hinaus eine noch detailliertere Versionskontrolle im BIM 360 Team, wie man sie zum Beispiel von den Commit-Nachrichten von Git-Repositorien kennt. Dies würde manche Fehlersuche oder das Ausbessern von Modellierungs-Fehlern deutlich beschleunigen können, wenn klar wäre, an welchen Bauteilen Änderungen vorgenommen wurden.
7.3 E-Mail Spam bei Öffnen über BIM 360
Öffnet eine am Projekt beteiligte Person das Projekt über den BIM 360 – Ordner und nicht über Revit direkt, wird den anderen Projektbeteiligten eine große Anzahl an E-Mails zugestellt, dass die Personen bestimmte Projektdateien geteilt haben. Dies muss über die Einstellungen von BIM360 Team abgestellt werden.
N
39
Abbildung 37: Clash-Detection in SMC. Abbildung 38: BIMCollab BCF Manager for Revit.
8 Modellüberprüfung und Umgang mit den IFC-Daten
8.1 Modellanalyse
Die Modellüberprüfung wurde mit Solibri Model Checker durchgeführt. In den Regelsets zur Geometrie-Überprüfung ergaben sich lediglich zwei Probleme, die auf die doppelte Modellierung einzelner Elemente zurückzuführen ist (1x Dachfläche, 1x Anrampung für die Boote). Weitere Fehler konnten in den Geometrie-Regelsets nicht festgestellt werden, was auf eine hohe Qualität der Modelldaten schließen lässt. Die Anrampung wurde im Verlauf des Projekts durch Hebebühnen ersetzt. Weitere erkannte Fehler in den geprüften Regelsets konnten aufgrund der angestrebten Modellierungsgenauigkeit als "akzeptiert" markiert werden.
8.2 Fehlerkommunikation
Aufgrund der geringen Anzahl an detektierten Fehlern wurde darauf verzichtet, eine zweite Plattform zur Fehlerkommunikation zu eröffnen. Alle Probleme konnten entweder durch Treffen mit allen Projektbeteiligten oder über den A360-Communicator besprochen und beseitigt werden. Da Autodesk Revit nicht über eine native Schnittstelle für BCF-Daten verfügt, wurde im Rahmen dieses Projektes nach Möglichkeiten gesucht, diese trotzdem im Revit-Projekt darstellen zu können, um Fehler in der Modellierung direkt am Revit-Modell zu visualisieren. Hierfür wurde die Plugin-Lösung von BIMCollab getestet.
N
40
Dieses Plugin bietet die Möglichkeit, neue Tasks zu erstellen oder bestehende BCF-Dateien zu öffnen. Im vorliegenden Falle wurde die bestehende Datei, die mit dem Solibri Model Checker erstellt wurde, eingelesen. Der Import funktionierte ohne Probleme. Leider muss beim Wechseln zu einem anderen Fehlerbericht immer die vom Plugin erzeugte 3D-Ansicht geschlossen werden, um den nächsten Task darstellen zu können. Auch die Darstellung der konkreten Informationen einer Aufgabe ist schwierig beziehungsweise in der getesteten Version nicht vorhanden, was den Nutzen des Plugins deutlich mindert. Möglicherweise ist eine besseres Nutzer-Erlebnis zu erzielen, wenn man neben dem Revit-Plugin zusätzlich die BIMCollab-Cloud nutzt, um die Fehlerkommunikation abzuwickeln.
8.3 Überprüfung der IFC-Export-Ergebnisse
Zur weiteren Validierung und dem Umgang mit benutzerdefinierten PropertySets in verschiedenen Plattformen wurde ein Upload der IFC-Daten auf die Plattform BIMPlus durchgeführt. Hier zeigte sich, dass nicht jedes Programm/jede Plattform IFC-Daten in gleicher Weise behandelt. Folgende Bildschirmausschnitte zeigen ein und dieselbe IFC-Datei, links im Solibri Model Viewer, rechts nach dem erfolgreichen Import in BIMPlus.
Abbildung 39: Validation mittels verschiedener Software.
N
41
Da unter anderem die StB-Stützen auf der Seeseite nicht im Viewer von BIMplus dargestellt wurden, ergab sich die Vermutung, dass es ein Problem mit der Interpretation der benutzerdefinierten PropertySets gibt. Daher wurde eine weitere IFC-Datei aus dem Revit-Projekt exportiert, allerdings mit den Standardeinstellungen „IFC4 – ReferenceView“. Hier zeigte sich das gleiche Ergebnis: Öffnet man die Datei in Solibri Model Checker/Viewer, werden alle Elemente im 3D-Viewer richtig dargestellt und auch die zu erwartenden PropertySets werden für jedes Bauteil richtig angezeigt (Abbildung 40 - Oben). Öffnet man die ReferenceView-Datei nun wiederum mit BIMplus, zeigt sich das gleiche fehlerhafte Ergebnis wie zuvor (Abbildung 40 - Mitte). Um eine dritte Möglichkeit zur Validierung der IFC-Daten heranzuziehen, wurde das Programm progressTrack genutzt, welches derzeit am Lehrstuhl CMS unter der Leitung von Herrn Alex Braun entwickelt wird. Das Darstellungsergebnis nach dem Import ist in Abbildung 40 – Unten zu sehen. Auch hier werden sowohl die IFC-Datei mit eigenen PropertySets als auch mit CommonPropertySets richtig dargestellt. Dies lässt vermuten, dass sich die fehlerhafte Darstellung in BIMplus nicht auf fehlerhafte IFC-Daten, sondern auf ein Problem auf Seiten von BIM-plus zurückführen lässt.
Abbildung 40: Fehlerfindung mittels Nutzung verschiedener IFC-Viewer.
N
42
Abbildung 41: Screenshot IFC – File.
9 Softwareentwicklung Revit-ParaMap
9.1 Motivation und Problemstellung
Bereits zu Beginn des Projekts wurde klar, dass die Modellierung eigener Familien notwendig werden könnte oder zusätzliche Parameter an Bauteile angehängt werden sollen. Um diese Parameter aus dem Revit-Projekt in eine IFC-Datei exportieren zu können, können benutzerdefinierte IFC-PropertySets erstellt werden. Die Zuordnung der Revit-Parameter an den korrespondieren IFC-Parameter erfolgt mit einem *.txt-File, dessen händische Konfiguration und Darstellung fehleranfällig sein kann. Aus diesem Grunde wurde im Rahmen des BIM-Kurses „Revit-ParaMap“ entwickelt, das dem Nutzer das Erstellen und Bearbeiten der *.txt-Datei zur Zuordnung der Parameter erleichtern soll.
9.2 Programmfunktionen
Folgende Funktionen und Anforderungen wurden zu Beginn definiert: - Einlesen bestehender PropertySet-Dateien
- Darstellen und Bearbeiten einzelner PropertySets und deren zugehörigen Properties
- Exportieren der Daten in Revit-lesbare *.txt-Files - Vorschlag möglicher Datentypen - Verknüpfung der Projektparameter aus Revit in
das Tool
9.3 Graphische Oberfläche
Die Implementierung basiert auf der Programmiersprache C# in Kombination mit Funktionen der WPF-Programmierung. Die Programmoberfläche orientiert sich an der zu erzeugenden *.txt-Datei und gliedert sich in zwei Hauptbereiche auf: Links werden die PropertySets erstellt und in einer Listenansicht angezeigt, rechts können Properties erstellt werden, die die Übersetzung der Revit-Parameter in die IFC-Parameter regeln.
N
43
Neben dem Import bestehender PropertySet-Dateien können bei Bedarf „gemeinsam genutzte Parameter“ aus dem Revit-Projekt in Revit-ParaMap eingelesen werden. Diese werden nach erfolgreichem Import als Auto-Vervollständigung in einem Popup-Menü unter dem Textfeld „Revit-Parameter“ bereitgestellt. Weiterhin steht eine Auswahlmaske für die Instance-Tags der PropertySets zur Verfügung, welche festlegen, für welche Bauteiltypen welche PropertySets exportiert werden sollen.
Abbildung 42: Screenshot GUI - Revit-ParaMap.
Abbildung 43: Feature Auto-Vervollständigung. (Zoom)
N
44
9.4 Anwendungsbeispiele
Zu Testzwecken wurden fast alle Bauteile im Revit-Projekt mit einem IfcExportAs-Tag belegt. Exemplarisch wird die Verwendung einiger Parameter an den Rolltoren gezeigt.
Zur Modellierung dieser Bauteile wurde ein Fassadensystem so modifiziert, dass das komplette Element nur aus Riegeln besteht. Um für die weitere Verarbeitung trotzdem erkenntlich zu machen, dass es sich um ein Rolltor handelt, wurde ein benutzerdefiniertes PropertySet aus Revit in das IFC-File exportiert.
Abbildung 44: Anwendungsbeispiel Revit-ParaMap.
N
45
9.5 Fazit Datenaustausch und Revit-ParaMap
Mit Revit-ParaMap wurde eine übersichtliche, aber dennoch leistungsstarke Erweiterung für den benutzerdefinierten Revit-IFC-Export erschaffen, die an vielen Stellen zur Anwendung kommen kann: - Verfeinerung der Semantik-Informationen für
Standard-Bauteile (z.B. Entwicklung eigener Familien, die nicht über Standard-Bauteile in Revit abgedeckt werden können)
- Parameter-Definitionen für die Filtervergabe in Downstream-Programmen (z.B. Vor-Gruppierung verschiedener Wände, die im Rahmen der Mengenermittlung eine eigene LV-Position bilden)
- Einbindung produktspezifischer Informationen in Modelle mit sehr hohem Detailierungsgrad (z.B. Herstellerinformationen von elektronischen Einbauteilen, Wartungsintervalle für Sonderausstattungen, …)
Der IFC-Datenaustausch zwischen verschiedenen Projektteilnehmern und vor allem die im IFC-gespeicherten Informationen werden in den kommenden Jahren eine immer größere Bedeutung erhalten.
Der aktuelle Entwicklungsstand von Revit-ParaMap ergänzt den Export von Revit-Projekten in IFC-Dateien Dennoch wäre auch die Erweiterung auf andere Nutzungs-Szenarien denkbar. Beispielsweise könnte die Rückgabe der in ParaMap eingegebenen Informationen an eine Revit-Projektdatei einen weiteren Entwicklungsschritt darstellen. Dies würde dem Auftraggeber ermöglichen, bereits zu Beginn projektrelevante Zusatz-Informationen und Eigenschaften zu definieren, die anschließend den Ingenieuren und Architekten direkt in ihren Modellierungs-Werkzeugen bereitgestellt werden können.
N
46
10 Fazit Gesamtprojekt
Im Rückblick kann der hier beschriebene Entwurf eines Bootshauses auf dem ZHS-Gelände am Starnberger See als erfolgreich durchgeführtes BIM-Projekt angesehen werden. Positiven Effekt hatte sicherlich die sehr frühe Zusammenarbeit zwischen Architekt und Ingenieuren, da so ein Modellansatz gefunden werden konnte, dass einerseits die gewünschten architektonischen Aspekte abdeckt und auf der anderen Seite für die statischen Berechnungen eine lösbare Struktur darstellt. So konnte eine sehr geradlinige Erstellung der Modelldaten in Revit durchgeführt werden, da nur kleinere Änderungen in Oberflächen oder Querschnitten durchgeführt werden mussten. Die Zusammenarbeit auf Basis der A360-Cloudplattform hat sich für das vorliegende Projekt als richtige Entscheidung herausgestellt, da alle Prozesse der Modellierung an einem Modell durchgeführt werden konnten und die Gewerke Architektur, Statik und Mengenermittlung durchgehend die aktuellste Version des Modells für ihre Aufgaben nutzen konnten. Die Einführung verschiedener Bearbeitungsbereiche hatte positiven Effekt, erfordert aber hohe Disziplin aller Beteiligten, um neu erstellte Bauteile auch in den richtigen Bearbeitungsbereich zu gruppieren. Dies führte vereinzelt zu Problemen, konnte aber zumeist sehr zeitnah gelöst werden.
Dennoch haben sich auch im Verlauf des Projektes einige Aspekte aufgetan, die in größeren Vorhaben zu massiven Problemen und Verzögerungen hätten führen können. Zu Projektbeginn wäre eine Einigung auf eine einheitliche Sprache und Benennung von Bauteilen oder Ansichten im Revit-Projekt sinnvoll gewesen (siehe unter anderem 7.1 Lokalisierung). Eine Dokumentation über getätigte Änderungen im Revit-Projekt ist derzeit noch nicht software-seitig verfügbar, hier wäre an manchen Stellen eine noch stärkere Kommunikation hilfreich gewesen. Die Software-Entwicklung von Revit-ParaMap wurde wie in der Prozessplanung dargestellt als begleitender Prozess durchgeführt. Dieser Tatsache ist es auch geschuldet, dass die neu erschaffenen Funktionen nur im begrenzten Umfang in der Zusammenarbeit innerhalb des Teams genutzt wurden. Die IFC-Schnittstelle wurde lediglich für die Modellüberprüfung in Solibri verwendet, der Export in SOFiSTiK für die statischen Berechnungen erfolgte über das SOFiSTiK-Plugin für Revit, die Übergabe an RIB iTWO zur Mengenermittlung wurde über das cpixml-Format realisiert. Abschließend lässt sich der Projektteil der Software-Entwicklung ebenso als erfolgreichen Beitrag werten, auch weil dieser am Ende andere Gruppen unterstützen konnte.
