Warum jeder Clash-Lauf mit einer Prüffrage statt mit einem Preset beginnen sollte

Eine Föderation für einen Bahnhof kann Gleise, Bahnsteige, Tragwerke, Entwässerung, Kabeltrassen, technische Ausrüstung und temporäre Bauzustände im selben räumlichen Kontext enthalten. Das bedeutet nicht, dass jedes Paket in jeden Clash-Lauf gehört.

Angenommen, die aktuelle Frage lautet, ob Kabeltrassen den Tragwerksbereich des Bahnsteigs durchdringen. Die relevanten Nachweise liegen an der Schnittstelle zwischen Bahnsteigtragwerk, Kabelpritschen, Versorgungstrassen und ausgewählter Ausrüstung. Ein Report voller Überschneidungen zwischen Gleis und Entwässerung oder mit temporären Bauzuständen macht diese Prüfung nicht gründlicher. Er erschwert es, die Entscheidung zu erkennen.

Ein sinnvoller Workflow folgt daher dieser Reihenfolge: Prüffrage, Klassifikation und Scope, Clash-Matrix, dann handlungsrelevante Issues. Die Frage klärt, warum die Prüfung existiert, bevor die Software festlegt, wie sie ausgeführt wird.

Ein gespeichertes Clash-Preset kann Modellgruppen, Toleranzen, Regeln, Filter und Ausschlüsse festhalten. Die Wiederverwendung dieser Einstellungen kann effizient sein, wenn der ursprüngliche Prüfzweck weiterhin gilt.

Das Preset kann jedoch nicht wissen, ob diese Einstellungen die heutige Planungsfrage beantworten. Eine für einen früheren Austausch vorbereitete Matrix kann inzwischen stabile Pakete enthalten, eine neu kritische Schnittstelle auslassen oder Toleranzen verwenden, die zu einer anderen Prüfphase gehören. Der Lauf kann technisch korrekt und dennoch operativ nutzlos sein.

Das Laden eines Presets sollte daher ein Bestätigungsschritt sein und nicht der Ausgangspunkt. Das Team muss zuerst bestätigen, dass die gespeicherte Logik weiterhin die Entscheidung abbildet, die sie unterstützen soll.

Bevor der Clash-Befehl geöffnet wird, sollte der Koordinator die Frage so formulieren, dass das Planungsteam sie beantworten kann. „Die Clash-Matrix des Bahnhofs ausführen“ ist eine Anweisung. „Kollidieren die Versorgungstrassen des Bahnsteigs mit Tragwerksbereichen?“ ist eine Prüffrage.

Diese Unterscheidung zwingt das Team zu benennen, was es bestätigen, verwerfen, schützen oder koordinieren will. Zugleich entsteht ein praktisches Kriterium für jedes später ergänzte Objekt und jede Regel: Hilft diese Einbeziehung dabei, die Frage zu beantworten?

Klassifikation ist die Brücke zwischen einer menschlichen Koordinationsfrage und einem maschinell ausführbaren Clash-Scope. Sie überführt die Projektsprache in Gruppen, die konsistent geprüft, isoliert, einbezogen oder ausgeschlossen werden können.

Für die Frage zu den Bahnsteigmedien könnte der zulässige Scope Bahnsteigtragwerke, Kabelpritschen, Versorgungstrassen und ausgewählte technische Ausrüstung umfassen. Gleise, Entwässerung außerhalb der Schnittstellenzone und temporäre Bauzustände können als Kontext sichtbar bleiben, ohne automatisch in die Prüfung einzugehen.

Damit wird das im Beitrag „Wann Klassifikation in der Bahnkoordination vor der Clash-Matrix stehen sollte“ erläuterte Prinzip weitergeführt: Das Team sollte entscheiden, welche Assets zur Prüfung gehören, bevor es die Matrix mit deren Vergleich beauftragt.

Die Klassifikation bestimmt, was zur Prüfung gehört. Die Clash-Matrix bestimmt, was womit geprüft werden soll. Diese beiden Entscheidungen getrennt zu behandeln, ist eine der einfachsten Möglichkeiten, einen BIM-Clash-Detection-Workflow zu verbessern.

Sobald der klassifizierte Scope belastbar ist, kann die Matrix die sinnvollen Beziehungen darin festlegen. Kabelpritschen müssen möglicherweise gegen Bahnsteigträger und Freiräume ausgewählter Ausrüstung geprüft werden, während zwei Mediengruppen unter Umständen gar keinen Hard-Clash-Test benötigen. Toleranz und Clash-Logik sollten dem Schnittstellenrisiko und der aktuellen Planungsentscheidung folgen, nicht einer generischen Vorlage.

Das Ziel der BIM-Clash-Detection ist nicht, die Zahl im Report zu maximieren. Es geht darum, Issues zu erkennen, die relevant, verständlich, zuweisbar und mit einer Entscheidung verknüpft sind. Ein kleinerer, gezielter Satz kann mehr Disziplin erfordern als ein großer generischer Lauf, weil jede Einbeziehung begründet werden muss.

Rauschen zu reduzieren bedeutet nicht, Probleme zu verbergen. Die breitere Föderation kann weiterhin anhand separater Fragen und kontrollierter Prüfungen untersucht werden. Der Unterschied besteht darin, dass sachfremde Überschneidungen nicht mehr innerhalb eines Meetings, eines Issue-Sets oder eines BIM-Clash-Reports um Aufmerksamkeit konkurrieren.

Das ist bei Infrastrukturprojekten wichtig, bei denen wiederkehrende Assets und lange Korridore die Zahl technisch korrekter Überschneidungen schnell vervielfachen können. Die Signalqualität entscheidet darüber, ob Teams das Ergebnis untersuchen oder dem Report nicht mehr vertrauen.

ExyViewer kann den Workflow unterstützen, ohne das dahinterstehende Koordinationsurteil zu ersetzen. Die sinnvolle Abfolge beginnt mit der Prüfung der IFC-Föderation und ihrer Eigenschaften. Anschließend machen Klassifikation, Sichtbarkeit und Modellisolierung die beabsichtigte Grenze eindeutig.

Clash-Beziehungen werden erst konfiguriert, nachdem diese Grenze verstanden ist. Die Ergebnisse können dann im Modellkontext geprüft werden, sodass das Team nur Issues kommuniziert oder exportiert, deren Zweck klar nachvollziehbar ist.

Die Definition der Prüffrage und die Kontrolle des Klassifikations-Scopes erfordern mehr Vorbereitung als das Laden eines gespeicherten Presets. Dabei können auch Meinungsverschiedenheiten über Paketverantwortung, Toleranzen oder die Kriterien für ein handlungsrelevantes Issue sichtbar werden.

Diese Vorbereitung ist sinnvolle Arbeit. Sie reduziert den nachgelagerten Prüfaufwand, wiederholte Issue-Diskussionen, Debatten über falsch-positive Ergebnisse und Koordinationsmüdigkeit. Presets bleiben wertvoll, aber nur, wenn das Team ihren bewahrten Zweck benennen und bestätigen kann, dass dieser Zweck für den aktuellen Modellaustausch weiterhin gilt.