Die Kollisionsprüfung von festen und bewegten Bauteilen und Baugruppen anhand des 3D-Modells gehört zu den wichtigsten Aspekten des Konstruktionsprozesses. Damit lassen sich unerwünschte Abstände, Berührungen oder Durchdringungen rechtzeitig vor Fertigungsbeginn identifizieren und beseitigen. Natürlich findet dieses Prozedere mehrfach während der Produktentstehung statt.
Praktisch alle CAx-Systemanbieter haben hierfür ein Tool im Angebot, das mit einem guten Funktionsangebot aufwarten kann – so auch die CT CoreTechnologie GmbH mit Sitz in Mömbris bei Aschaffenburg. Das Modul zur Kollisionsprüfung ist bereits länger auf dem Markt. Wenn extrem große Datenmengen verarbeitet werden müssen, macht die verteilte Berechnung und eine spezielle Technologie zur optimierten Nachbarschaftssuche den Unterschied, wie uns Armin Brüning, einer der beiden Geschäftsführer des Systemanbieters, zu verstehen gibt. „Bei Anwendungsfällen wie dem Digital Mock-up eines Gesamtfahrzeugs, bei dem bis zu 50 000 Teile zusammengeführt werden, ist es für die meisten Tools nicht mehr möglich, akzeptabel kurze Antwortzeiten zu garantieren.“ Daher hat CT CoreTechnologie jetzt eine Lösung entwickelt, die auch derart große Datenmengen schnell analysiert.
Die Lösung nennt sich Collision Detection Manager. Die Kollisionsberechnung findet über den sogenannten Enterprise Batch Manager statt, wobei dieser das Job-Management übernimmt. Es sorgt dafür, dass mehrere CPU-Kerne und sogar mehrere Rechner gleichzeitig genutzt werden können – mit anderen Worten: die Lösung ist weitgehend parallelisiert, so dass in einem dreistufigen Prozess die einzelnen Berechnungen in Einzeljobs aufgeteilt werden. Als Input dient jedes beliebige am Markt verfügbare CAD-Format: zum Beispiel CATpart, .prt (Pro/ Engineer), .x_t (NX) und natürlich auch JT.
Des Weiteren ist eine Strukturdatei notwendig. Dies kann zum Beispiel eine CATproduct- für Catia, eine .asm-Datei für Pro/ Engineer oder .prt für NX sein. Der Collision Detection Manager akzeptiert zudem Textdateien in gängigen PLM-Formaten wie .csv, .xml oder .plmxml. In dieser Auflistung sind Angaben zur Baugruppenstruktur mit den einzelnen Dateinamen zu finden, Positionierungen im Raum und Zugehörigkeit zur übergeordneten Baugruppe und Angaben, wo die Daten im Netzwerk abgelegt sind. „Mit diesem Konzept lässt sich Collision Detection Manager relativ einfach an jedes beliebige PLM-System anbinden. Möglicherweise ist eine Spezialentwicklung in geringem Umfang notwendig, wenn die Strukturdatei ein etwas anderes Format aufweist, als wir es
zur Verarbeitung vorgesehen haben“, sagt Brüning.
Es wurde nicht vergessen, gleich auch noch umfangreiche Auswerte- und Analysetools mitzuentwickeln, die in Form von übersichtlichen webbasierten Listen und 3D-Model-len die Ergebnisse dynamisch anzeigen. Die Lösung ist zudem netzwerklauffähig, so dass jeder Anwender auf die Analyseprojekte, die in einer SQL-Datenbank abgelegt sind, über das Netzwerk zugreifen kann.
Gibt es eine besondere Intelligenz im Algorithmus, um möglichst schnell die Nachbarschaftsbeziehungen der Teile untereinander zu ermitteln? „Ganz genau“, sagt der Geschäftsführer und weist auf die Verwendung von Voxeln zur Extraktion der Nachbarschaftsbeziehungen hin. Der Begriff „Voxel“ – ein Kunstwort, zusammengesetzt aus „Volumetric“ und „Pixel“ – bezeichnet einen Datenpunkt einer 3D-Rastergrafik. Er entspricht einem Pixel in einem 2D-Bild. Wie bei Pixeln wird bei Voxeln üblicherweise die Position nicht explizit gespeichert, sondern implizit aus der Position zu anderen Voxeln hergeleitet. „Im Grunde genommen handelt es sich dabei um reine Integer-Informationen, was zu einem sehr schlanken Datenformat führt“, erklärt Brüning.
Zunächst wird also wie mit Legosteinen der betrachtete Kollisionsraum relativ präzise nachgebildet und auf dieser Basis die Nachbarschaftssuche durchgeführt. „Die Nachbarschaftssuche erfolgt somit sehr performant, weil wir eben nicht die sonst üblichen Bounding-Boxen verwenden“, sagt Brüning stolz. Bounding-Boxen sind Hüllkörper, die ein Bauteil komplett umschließen. Dieser Ansatz führt oftmals dazu, dass sich schnell eine sehr große Anzahl von Nachbarn und damit von potenziellen Kollisionspartnern ergibt, deren Relevanz sukzessive erst einmal wieder ausgeschlossen werden muss.
Bei Collision Detection Manager von CT CoreTechnolgie hat man also viel über eine gute Konturannäherung nachgedacht, um für den Ausgangspunkt der Analyse möglichst wenige potenzielle Kollisionspartner zu haben und damit eine schnellere Analyse zu ermöglichen. Übrigens lässt sich die Genauigkeit einstellen. Bei einem Fahrzeug ist zum Beispiel 5 mm Voxel-Kantenlänge ein guter Wert, bei einer Digitale-Fabrik-Anwendung empfiehlt Brüning 15 mm.
Die Kollisionspartner werden im Anschluss in einer Liste dokumentiert. Dann findet die genaue Berechnung von Berührungsflächen und Durchdringungen statt. In einer .ct-Datei schließlich werden die sich berührenden oder durchdringenden Körper gezeigt, das entsprechende Gebiet wird gerötet. Weitere Kollisionsinformationen sind per Mauszeiger abrufbar.
Um die Entscheidungsfindung möglichst schnell herbeizuführen, hat der Systemanbieter eine Vielzahl von Managementfunktionen implementiert. Wird eine Kollision nachge-wiesen, werden insgesamt drei Bilder vom Tatbestand erzeugt: je eines vom beteiligten Kollisionspartner und eines von der Kollision selbst. Diese JPGs sind abrufbar und können als Verhandlungsgrundlage genutzt werden. Per Drag & Drop kann man die Bilder in sogenannte Drop-Zones von 3D_Evolution ziehen, um sich das Ereignis detailliert anhand von 3D-Mo-dellen anzeigen zu lassen. Dabei können Schnitte gelegt oder aber die Situation genau vermessen werden, um die Kollision zu bewerten. Auch lassen sich Kommentare für den zuständigen Kollegen posten. Ist das relevante Teil zum Beispiel flexibel, so dass es sich bei der Kollision einfach wegbiegt, kann es mit dem Status „nicht relevant“ versehen werden.
Es lassen sich zudem alle Kollisionen bestimmter Paarungstypen anzeigen, sagen wir: „Zylinderkopf einschließlich 20 entsprechende Schraubentypen“. Somit lässt sich leicht erkennen, ob ein Kollisionstyp relevant ist oder nicht. Mit einem Klick kann ein Paarungstyp in eine sogenannte Drop Zone herübergezogen und damit für irrelevant erklärt werden.
Auf diese Weise ist eine umfassende Dokumentation möglich, mit der sich jederzeit nachvollziehen lässt, wie mit den einzelnen Kollisionen im Weiteren verfahren wurde. Wenn man so will, ist der Collision Detection Manager ein eigenständiges kompaktes PLM-System, das zu Recht als Stand-alone-Lösung konzipiert ist, weil es ja nur die Momentaufnahme eines bestimmten Entwicklungsstands dokumentiert.
Brüning gibt den Tipp, jene Teile im Vorfeld auszuschließen, von denen bereits bekannt ist, dass sie zu Kollisionen führen. „Es kostet einfach Zeit, diese zigtausend Kollisionen zu berechnen, die dann doch nicht relevant sind.“ Hierzu gehören zum Beispiel Verbindungselemente wie Schweißpunkte, die durch Kugeln angedeutet sind. Nicht relevante Dateien lassen sich über Listen ausschließen. Innerhalb der Listen können außer vollständigen Namen auch sogenannte „Wild-Cards“ verwendet werden, um Daten in die Liste der nicht relevanten Bauteile zu übernehmen. Gemäß der Vorschrift *Normteil* oder *DIN-M* werden beispielsweise alle Dateien, die in ihrem Namen entsprechende Texte führen, ausgeschlossen.
Systemarchitektur
Über Enterprise Batch Manager werden die Jobs definiert. Die Ergebnisse der Untersuchung werden wiederum auf einem Netzlaufwerk abgelegt, auf das alle Projekt- beteiligten zugreifen können. Dies kann über 3D_Evolution oder den 3D_Analyzer Viewer erfolgen. 3D_Analyzer kann die Collision-Detection-Manager-Projektdateien laden, weil es ebenfalls über eine integrierte SQL-Datenbank verfügt. Werden zum Beispiel zehn Lizenzen von 3D_Evolution zur Kollisionsüberprüfung für ein Gesamtfahrzeug genutzt, dauert es aufgrund der guten Skalierbarkeit der Lösung nur vier bis fünf Stunden, bis die Analyse abgeschlossen ist, meint Brüning.
Ausblick
Eine ähnliche Funktionsweise ist seit neuestem auch für den geometrischen Modellvergleich für große Datenmengen verfügbar. Bisher war der Modellvergleich in 3D_Evolution und in 3D_Analyzer auf Einzelteile und kompaktere Baugruppen beschränkt. Auch hier ermöglicht die Parallelisierung die performante Berechnung großer Modellstrukturen, die auf entsprechend mehr Hardware-Ressourcen verteilt werden. Ein ausgedehnter Modellvergleich ist zum Beispiel interessant, um bei unterschiedlichen Bauständen herauszufinden, ob eine erneute Crash-Berechnung notwendig ist, weil strukturtragende Bauteile modifiziert wurden.
BERNHARD D. VALNION
