Kollisions-
prüfung.
Tausend Kollisionen zu finden ist leicht. Schwierig ist, daraus zwanzig Entscheidungen mit Verantwortlichem und Termin zu machen.
Jede Kollision wird einmal bezahlt.
Im Modell kostet sie eine verschobene Linie. Auf der Baustelle: Rückbau, neues Bauteil bestellen, warten.
Zwei Objekte, ein Ort.
Eine Kollision ist ein Paar von Elementen, die sich durchdringen oder einander näher kommen als erlaubt.
Harte, weiche und zeitliche Kollisionen.
Sie durchdringen sich, kommen sich zu nahe oder kollidieren zeitlich. Dazu ein vierter Fall: dasselbe Objekt doppelt.
Eine Zahl entscheidet, was kollidiert.
Bei harten Kollisionen die Mindestdurchdringung, die zählt. Bei weichen der geforderte Freiabstand. Ein Wort, zwei Bedeutungen.
Was nicht modelliert ist, kollidiert nicht.
Dämmung, Wartung, Türaufschlag, Montage. Ist dieser Raum kein Volumen, schützt ihn keine Prüfung.
Prüfen braucht ein reifes Modell.
Generische Boxen erzeugen Kollisionen, die es nicht gibt, und übersehen echte. Jede Phase hat ihren Grad und ihre Prüfung.
Nicht alles gegen alles.
Eine Matrix legt fest, welche Disziplinen gegeneinander geprüft werden, mit welcher Prüfart und welcher Toleranz.
Tausende Kollisionen, wenige echte.
Bis zu sechs von zehn Treffern sind keine Probleme: gewollt berührende Bauteile, Duplikate und unbereinigte Modelle.
Ein Problem, hundert Kollisionen.
Ein falsch geführter Kanal kollidiert mit jedem Träger, den er kreuzt. Gruppiert wird nach Element, Geschoss, Zone oder System, entschieden wird einmal.
Es weicht aus, wer kann.
Großes, Dauerhaftes und alles mit Gefälle hat Vorrang. Flexibles weicht aus. Wer das vorab vereinbart, erspart sich den Streit um jede Kollision.
Eine Kollision ist keine Aufgabe.
Zum Issue wird sie erst mit Ansicht, Elementen, Zuständigkeit, Termin und Status. So wandert sie zwischen den Teams.
Föderieren, prüfen, entscheiden, wiederholen.
Ein fester Zyklus mit Besprechung: prüfen, gruppieren, zuweisen, im Ursprungsmodell korrigieren und erneut prüfen.
Jedem Team sein Container.
Die Norm sagt nicht, wie geprüft wird. Sie sagt, wie das Modell aufgeteilt wird, wer welchen Teil liefert und wer das Ganze koordiniert.
3D-Koordination ist bereits Pflicht.
Der Plan BIM der spanischen Zentralverwaltung definiert sie als Erkennen und Lösen von Kollisionen und schreibt sie stufenweise vor.
Es reisen die Issues, nicht das Modell.
BCF ist ein offenes Format, um Modelle zu kommentieren: Ansicht, Screenshot und markierte Elemente. Das Modell bleibt, wo es ist.
Ein ZIP mit einem Ordner pro Thema.
Jedes Issue hat sein Datenblatt, seine Ansichten und seine Screenshots. Die Wurzel legt fest, welche Status und Typen zulässig sind.
2.1 gibt weiter den Ton an.
3.0 ordnet Status und Typen und trennt die Authentifizierung ab. Viele Werkzeuge lesen aber nur 2.1: Die Version wird im BIM-Abwicklungsplan festgelegt.
22 Zeichen, die sich nicht ändern dürfen.
Das Issue markiert Elemente über ihre IFC-Kennung. Wird das Element gelöscht und neu erstellt, zeigt das Issue ins Leere.
Vier Prüfarten, fünf Status.
Der De-facto-Standard zum Föderieren. Die Toleranz ändert je nach Prüfart ihre Bedeutung, und ohne Add-in gibt es keinen BCF-Export.
Zur Selbstkontrolle.
Vergleicht Kategorien des Modells und eines verknüpften Modells. Ohne Toleranz, ohne Regeln, ohne gespeicherte Prüfungen: nützlich vor der Abgabe, nicht zum Koordinieren.
- Harte Durchdringungen
- HTML-Bericht
Die Kollision als Regel.
Es gibt keine Prüftaste: Es gibt parametrisierte Regeln auf dem IFC, mit Toleranzen je Bauteil und einer Matrix, die in Excel bearbeitet wird.
Fast alle erkennen etwas.
Sie dienen dazu, das eigene Modell vor der Abgabe zu bereinigen. Unterschiedlich sind Namen, Toleranzen und BCF-Unterstützung.
Prüfen ohne das Ursprungsprogramm.
IFC-Viewer und offene Werkzeuge gleichen Modelle beliebiger Herkunft ab, gruppieren und exportieren BCF.
Prüfen beim Veröffentlichen.
In der Cloud startet die Prüfung von selbst, sobald eine neue Version eintrifft. Man gewinnt Beständigkeit und verliert Feinsteuerung.
Die einen prüfen, die anderen verwalten.
Manche Plattformen berechnen Kollisionen, andere nehmen nur Issues entgegen. Sprechen sollten alle BCF.
Vom Viewer ins Modell und zurück.
Der Koordinator markiert das Issue im Koordinationsmodell. Der Autor öffnet es in seinem Programm, das per GlobalId zu den Elementen springt, korrigiert und antwortet.
Keine Dateien zu verschicken.
Mit der API liest und schreibt jedes Programm die Issues auf demselben Server. Keine BCF-Versionen, die per E-Mail kursieren.
Was auf der anderen Seite nicht ankommt.
Jedes Programm versteht BCF auf seine Weise. Vor der ersten Besprechung testen Sie einen Hin- und Rückweg mit den echten Programmen des Projekts.
Erst muss das Modell taugen.
Prüfen auf einem unbereinigten Modell erzeugt Rauschen. Fünf Vorabprüfungen, automatisierbar mit einer IDS.
- Gleiche gemeinsame Koordinaten
- Einheiten und GlobalId stabil
- Keine Duplikate
- Systeme und Klassifikation ausgefüllt
- Dämmung und Freiräume modelliert
Die Kurve muss fallen.
Offene Issues je Disziplin und mittlere Zeit bis zum Schließen, Woche für Woche. Die Gesamtzahl der Kollisionen misst nur das Rauschen.
„Gelöst“ heißt nicht „korrigiert“.
Eine Kollision verschwindet, wenn sie korrigiert wird, aber auch, wenn das Element gelöscht wird oder sich die Auswahl der Prüfung ändert. Jemand muss hinsehen.
Vom eigenen Modell zum Koordinationsmodell.
Jede Stufe hat ihr Werkzeug. Ein früh gefundener Fehler wandert nicht zu den anderen.