Das Konstruieren im Baugruppenkontext ist eigentlich die natürlichste Konstruktionsmethode für komplexere Produkte, denn am Ende landet ja eh jedes Teil in einer Baugruppe – warum also nicht gleich in diesem Kontext konstruieren? Das sogenannte Top-Down-Design hat allerdings einige Risiken für die CAD-Daten, so dass im Alltag doch eher vom Teil zur Baugruppe hin – also Bottom-Up – konstruiert wird. Onshape meldet heute, dass man einen Durchbruch geschafft und mit seiner Implementierung des „In Place Editing“ eine sehr sichere Variante der Top-Down-Konstruktion entwickelt hat.
Der Konstrukteur hat sich – oder wurde – seit langer Zeit darauf abgerichtet, möglichst wenige Referenzen zwischen verschiedenen Features in einem Modell zu setzen, externe Geometriereferenzen werden allgemein als gefährlich angesehen. Jedes Bauteil ist an sich autark, in der Baugruppe werden die Bauteile lediglich zum Platzieren verknüpft. So wird definiert, dass eine Bohrung und eine Achse konzentrisch sind, um beispielsweise ein Rad auf der Achse zu fixieren.
Allerdings ist es verpönt und in manchen CAD-Systemen sogar defaultmäßig abgeschaltet, die Radien von Bohrung und Achse miteinander zu verknüpfen. Warum? Weil solche externen Geometriereferenzen sehr empfindlich sind, beispielsweise wenn eines der Teile verändert wird und das Referenzfeature, beispielsweise eine Fläche, verschwindet. Eine böse Falle sind auch Bewegungen. Referenziert man zwischen zwei Bauteilen, die zueinander beweglich sind, verändert sich die Bauteilgeometrie beim Verändern der Platzierung der Teile zueinander.
Dabei ist das Top-Down-Konstruieren eigentlich sehr intuitiv – im verlinkten Video zeigt Neil Cooke, wie die Aussparungen von Kupplungs- und Bremszylinder eines Auto-Pedalwerks die Referenz für die Aussparungen in der Grundplatte bilden. Das ist logisch, denn die Aussparungen sind ja genau für diese Zylinder notwendig, also spiegelt die Referenz den logischen Zusammenhang wider.
Cooke hebt mehrmals darauf ab, dass andere CAD-Systeme in diesem Bereich viel schwächer sind und deshalb Top-Down-Design selten genutzt wird. Das ist nicht ganz richtig, denn Top-Down-Design ist eigentlich kein reines CAD-Thema, sondern eine Frage der Datenverwaltung. Ein Datenverwaltungssystem muss allerdings sehr tief in die CAD-Daten hineinwirken können, um die externen Referenzen vor Änderungen schützen zu können – das ist für externe, nicht vom CAD-Hersteller stammende PDM-Systeme kaum denkbar. Zudem arbeiten die meisten Verwaltungssysteme nach wie vor mit Dateien, die in einer Datenbank gespeichert werden, der Aufwand, in diese Dateien hineinzusehen, ist sehr hoch.
Die übliche Datenhaltung sieht ja so aus: Einzelteildateien beinhalten alle Informationen zum jeweiligen Teil, hinzu kommen Baugruppendateien, die neben der Information, welche Teile in der Baugruppe enthalten sind, die Verknüpfungen zwischen diesen Teilen enthalten. Bei Verknüpfungen ist das kein Problem, denn das Teil in der Bauteildatei ist ja immer gültig und komplett definiert. Wenn geometrische Referenzen zwischen Teilen ins Spiel kommen, sind Bauteildateien nie vollständig, weil sie ja immer Geometrieinformationen aus anderen Bauteilen brauchen.
Wo speichert man diese Infos? In der Baugruppendatei? Dann muss das CAD-System jedes Mal eine Vielzahl von Dateien öffnen. Beim Öffnen der Bauteildatei A braucht es Infos auf der Baugruppendatei, die wiederum Informationen aus Bauteildatei B braucht, um die Frage beantworten zu können, wie groß denn ein bestimmtes, referenziertes Maß sein soll – denn dieses kann ja wiederum von anderen Parametern in Datei B abhängig sein. Dass das bald und oft in Katastrophen hineinführt, ist – glaube ich – schnell klar.
Onshape mit seiner cloudbasierten Speicherhaltung arbeitet da – wie übrigens auch die 3DExperience von Dassault Systèmes – anders: Onshape speichert jeden einzelnen Modellierschritt in seiner Datenbank, Geometriefeatures und deren Referenzen aller Teile liegen gleichberechtigt nebeneinander in der Datenbank, statt hierarchisch in Dateien gegliedert zu sein. Onshape kennt also technisch keinen Unterschied zwischen internen und externen Referenzen. Es arbeitet beim Öffnen eines Modells – grob gesprochen – einfach alle Bearbeitungsschritte nacheinander erneut ab.
Hinzu kommt die Branching/Merging-Technologie in Onshape: Startet man eine In-Place-Editing-Session, speichert das System einen Snapshot des aktuellen Modells. Dieser Snapshot ist nichts anderes als ein Merker, der dem System sagt, dass beispielsweise Verschiebungen von referenzierten Kanten nach diesem Marker nicht in die Berechnung der Referenz einfließen dürfen. Man sieht das sehr schön im Video, wenn Cooke den Anschlag für das Gaspedal auf das Pedal referenziert. Wird das Pedal später bewegt, verändert sich der Anschlag nicht, weil das System weiß, welche Stellung des Pedals für die Referenz gültig ist. Da nicht nur das Verzweigen, sondern auch das Zusammenführen in Onshape sozusagen ein Teil der Onshape-DNA ist, ist es jederzeit möglich, den Snapshot zu aktualisieren.
Der Artikel ist recht technisch geworden, zeigt aber sehr explizit, wie die moderne, datenbankbasierte Architektur von Onshape viele vermeintliche Grundprobleme des „CAD-Wesens“ nicht einfach löst, sondern von vorn herein umgeht. Der Verzicht auf Dateien mag sich im ersten Moment seltsam anfühlen, weil man nichts mehr hat, was man abspeichern könnte – auf der anderen Seite sehen wir immer stärker, welche Vorteile diese Architektur bietet. Onshape hat CAD sicher nicht neu erfunden – In-Place-Editing können auch andere – zeigt hier jedoch wieder einmal, wie diese Funktionalitäten in einer Datenbankarchitektur – ich vermeide gerade das Wort „Cloud“ absichtlich, denn diese Architektur lässt sich natürlich auch auf lokalen Servern umsetzen – viel einfacher und sicherer umgesetzt werden können.
