Heute erzähle ich Ihnen, wie sich die Finite Elemente Analyse (FEA) im Laufe der Zeit entwickelt hat. Vor allem möchte ich hervorheben, warum die (aller)meisten FEA-Programme heute so funktionieren, wie sie funktionieren. Und schließlich möchte ich erläutern, warum ich der Meinung bin, dass ein Umdenken für die Anwender eine gute Idee ist.
Computer Aided Design (CAD)
Die FEA war nahezu von Anfang an an die Entwicklung der CAD-Systeme gebunden. Daher ist es zunächst wichtig, uns die Entwicklung des CAD anzuschauen.
In den Anfängen waren CAD-Programme einfache 2D-Skizzierwerkzeuge, ohne besondere Intelligenz.
1960 hat Ivan Sutherland im Rahmen seiner Doktorarbeit das erste moderne 2D-CAD-Programm entwickelt: SKETCHPAD. Für die damaligen Zeiten war das neue Programm eine Revolution. Die zwei wichtigsten, bahnbrechenden Alleinstellungsmerkmale von SKETCHPAD waren:
- Das automatische Lösen von komplexen geometrischen Zwangsbedingungen (bspw. senkrecht, parallel, kollinear, gleiche länge usw.)
- Objektorientierter Ansatz (einzelne Zeichnungen konnten wiederverwendet und zusammengesetzt werden, um größere Zeichnungen zu erstellen)
In nachfolgendem Video wird die beeindruckende Arbeitsweise mit SKETCHPAD demonstriert: Video abspielen
Es mussten 12 weitere Jahre bis zum ersten 3D-CAD-Programm im Jahre 1972 vergehen: SynthaVision. Das nächste Video zeigt einige mit SynthaVision erstellte Animationen. Für die damaligen Computer waren jedoch 3D-CAD-Programme zu ressourcen-intensiv. Eine Massenverbreitung konnte aus diesem Grund noch nicht stattfinden. Video abspielen
1978 wurde mit der Veröffentlichung von Unigraphics ein neuer Standard in der 3D-CAD-Modellierung gesetzt: Video abspielen
1985 ist Pro/Engineer von der Firma PTC erschienen. Trotz anfänglicher Kinderkrankheiten, eine echte Revolution! Pro/Engineer stellte alle bisherigen Systeme sofort in den Schatten. Nebenbei bemerkt: Pro/Engineer war das erste 3D-CAD-Programm, das die Konzepte von SKETCHPAD(!) konsequent in die 2D- und 3D-Welt umsetzte. Hier ist ein Demo-Video der damaligen Software-Version: Video abspielen
10 Jahre später – 1995 – ist SolidWorks erschienen. Es bot die meisten Funktionalitäten der bestehenden führenden CAD-Programme, kostete jedoch nur einen Bruchteil davon. Hier ist eine Demo aus dem Jahre 1995: Video abspielen
Der Erfolg von SolidWorks war so groß, dass die kleine Firma zwei Jahre später von Dassault Systemes aufgekauft wurde. Zum Schluss noch ein Demo-Video von SolidWorks aus 2007, das den Schwerpunkt auf Baugruppen-Modellierung legt: Video abspielen
Wenn Sie sich die o.g. alten Software-Demo-Videos angeschaut haben, haben Sie die Meilensteine der CAD-Entwicklung vermutlich bereits erkannt:
- Erst: 2D-Skizzen
- danach: 3D-Einzelteile
- viel später: 3D-Baugruppen
Ich möchte Sie aber auch auf etwas Anderes aufmerksam machen: Das Konzept der Baugruppen war schon 1960 (spätestens durch SKETCHPAD) bekannt. Trotz der offensichtlichen Vorteile der Baugruppenmodellierung hatte sich das 3D-CAD zuerst auf die Modellierung von Einzelteilen konzentriert! Erst 25 Jahre nach SKETCHPAD wurden die damaligen Konzepte aufgegriffen und in ein 3D-CAD-Programm umgesetzt. Das war auch einer der Hauptgründe, warum Pro/Engineer so erfolgreich wurde.
Finite Element Analyse (FEA)
Nun, dass wir einen Überblick der CAD-Entwicklung haben, möchte ich mich der FEA-Entwicklung widmen.
Die Basis der FEA ist die FEM (Finite Element Methode), die ihre Ursprünge in den 40er Jahren hat. Die erste kommerzielle FEA-Software wurde 1971 der Öffentlichkeit vorgestellt: NASTRAN.
Ursprünglich reichte die verfügbare Computerleistung nur für grobe Berechnungen von Einzelteilen.
Für die heutigen Computer sind große Baugruppen immer seltener ein Problem. Zumindest wird das von allen Herstellern von FEA-Software so behauptet. Für manche ist das auch richtig, für manche andere ist das vielleicht nur halb richtig. Im Gespräch mit Ingenieuren aus unterschiedlichen Maschinenbau-Firmen höre ich oft, dass größere CAD-Baugruppen zunächst zu Einzelteilen verschmolzen werden, bevor diese in die FEA-Umgebung importiert werden. Ich frage dann, wieso, und die Antworten sind oft: Zu viele Einzelteile führen zu vielen Kontakten, zu viele Kontakte können nicht mehr auf Richtigkeit überprüft werden. Oder auch, dass die FEA-Software die größeren Lücken zwischen den einzelnen Bauteilen nicht richtig schließen kann. Oder aber, dass Zukaufteile wie Wälzlager, Linearführungen und Kugelgewindetriebe nur zu stark vereinfacht oder gar nicht modelliert werden können. Diese wären nur einige Gründe und wir erkennen, dass bei Baugruppen und FEA der Teufel im Detail steckt.
Es sieht fast so aus, als wollten die großen FEA-Hersteller sich auf die Parallelisierung der Solver konzentrieren und weniger auf die vielen kleinen „Teufel“ schauen. Sie fokussieren sich darauf, immer mehr Millionen von Modellfreiheitsgraden noch schneller zu lösen (was grundsätzlich gut für Baugruppen ist), vernachlässigen aber die hunderten oder gar tausenden - an sich kleinen - Einzelbauteilen in den üblichen CAD-Baugruppen.
Als ich vor 20 Jahren mit der FEA angefangen habe, hatte ich gleich mit gesamten Maschinen in der Simulation zu tun. Das war ein Sprung ins kalte Wasser, aber es hat Spaß gemacht. Meine erste FE-Simulation war eine Lithographie-Maschine (Herstellung von TFT-Bildschirmen). Dann folgten Laserschneidemaschinen, Fräs- und Drehmaschinen usw.
Trotz meiner Freude an der Simulation, schlich sich bei mir bald eine Unzufriedenheit aufgrund der vielen sich wiederholenden Arbeitsschritte ein. Designänderungen an einzelnen CAD-Bauteilen führten zu einem überproportionalen Änderungsaufwand an der FE-Baugruppe. Musste eine neue Maschine simuliert werden, musste ich bei null anfangen, obwohl vielleicht 50% der neuen Maschine gleich zu der alten Maschine war. Diese Arbeitsweise ist heute noch immer der aktuelle Stand der Technik.
Warum ist das so?
Nun, verblüffenderweise hört der Gedanke der Baugruppe bei den FEA-Systemen völlig auf. Wird eine CAD-Baugruppe also in ein gewöhnliches FE-Programm eingelesen, wird zunächst einmal die Baugruppenstruktur aufgelöst. Man erhält einen Haufen einzelner Bauteile, ohne jegliche Reihenfolge, Struktur und Zugehörigkeit zueinander.
Als Nächstes werden die üblichen FE-Kontakte (die Verbindungen zwischen den einzelnen Bauteilen) automatisch definiert. Das ergibt einen weiteren Haufen hunderte, ja tausender Kontakte. Der Anwender soll dann diese unzähligen Kontakte auf Richtigkeit prüfen. Denn, nicht jeder automatisch definierte Kontakt ist auch ein echter Kontakt. Spätestens hier hört der Spaß auf.
Vermutlich ist das Ganze historisch gewachsen. Vor 1985 war die Idee der Baugruppen in den damaligen CAD-Lösungen ohnehin nicht präsent. Vermutlich haben die FEA-Entwickler einfach aus dem Grund ihre FE-Programme ohne den Gedanken der Baugruppe konzipiert. Es ist sicherlich auch richtig, dass früher die Computer-Ressourcen begrenzt waren und man deshalb sowieso höchstens einfache Modelle mit wenigen Bauteilen berechnen konnte. Ich habe noch eine weitere mögliche Erklärung dafür: Die FE-Simulation von Baugruppen ist erst durch die Entwicklung der Verbundkontakte möglich geworden. Zu dem Zeitpunkt waren die meisten heutigen FEA-Programme bereits entwickelt.
Meshparts
Und nun zurück zu meinen Anfangserfahrungen in der FEA. Vor ca. 15 Jahren habe ich realisiert, dass all diese Probleme durch eine konsequente Überführung des Baugruppen-Gedanken in die FE-Welt gelöst werden können. So ist die Idee von Meshparts geboren worden. Damals stand ich kurz vor dem Studienabschluss und hatte mich entschieden die Idee an einem Forschungsinstitut der Uni Stuttgart (ISW) zu entwickeln. Fünf Jahre später habe ich Meshparts gegründet. Das Ergebnis ist eine neuartige FEA-Software – Meshparts, die so Vieles anders macht als alle anderen aktuellen FEA-Programme, dass es den Zugriff auf den historischen Bogen der CAD- und FEA-Entwicklung braucht, um ihre Arbeitsweise richtig zu verstehen.
Meshparts war anfangs ein einfaches Konfigurations-Tool, mit dem man verschiedene einzelne FE-Modelle zu FE-Baugruppen automatisch zusammenfügen konnte. Es gab auch eine Möglichkeit das gleiche FE-Modell mehrfach zu instanzieren. Und man konnte die Positionen der Komponenten beliebig zueinander verschieben. Das Ganze ist Ende meines Studiums entstanden. Das Tool habe ich dann im Rahmen meiner Forschungsarbeit am Institut weiterentwickelt.
Gleichzeitig zu der Entwicklung des Tools habe ich geforscht, wie die üblichen Zukaufteile im Maschinenbau effizient und reproduzierbar modelliert werden können. Ich hatte nämlich auch die Idee, dass man all diese Zukaufteile in einer FE-Modellbibliothek organisieren kann. Die gleiche Idee war schon seit Jahrzehnten Standard in der CAD-Welt (Traceparts, CADENAS und Co.)
Nach der Zeit am Forschungsinstitut und während der ersten Jahre von Meshparts konnte ich mit dem bereits entwickelten Tool einige Kunden gewinnen und Umsatz generieren. Das war schön und gut und dieses Tool hat den damaligen Anwendern schon viel Arbeit erspart.
Anfang 2014 habe ich mich entschieden, aus dem Tool eine richtige FEA-Software zu machen. Die neue Entwicklung hat ein Jahr bis zum ersten Release gedauert. Genauso wie Pro/Engineer seinerzeit, litt auch das neue Meshparts an vielen Kinderkrankheiten. Der Grund: Wir mussten fast alles neu denken, neu entwickeln. Um ein wenig zu verstehen, warum Meshparts so viel anders ist, ein erster Hinweis: Das FE-Modell einer Baugruppe in Meshparts ist eine Datei, die nur wenige Kilobytes klein ist. Das gleiche FE-Modell in den anderen bekannten FE-Programmen würde mindestens eine Größenordnung größer sein.
Der Baugruppen-Gedanke
Die Modelle von Meshparts sind echte Baugruppen. Das bedeutet, die Modelle beinhalten nicht die Information ihrer Einzelteile, sondern nur einen Verweis auf die Einzelteile. Erst die Einzelteile beinhalten die eigentlichen FE-Netze (die ja viel Speicher brauchen).
Nun aber die erste wichtige Eigenschaft von Meshparts: Wird eine CAD-Baugruppe in Meshparts importiert, dann entstehen so viele Meshparts-Unterbaugruppen wie CAD-Unterbaugruppen. Und es entstehen so viele Meshparts-Teile wie CAD-Teile. Schließlich enthalten alle Meshparts-Baugruppen dieselbe Baugruppenstruktur, wie ihre entsprechenden CAD-Baugruppen. Daher nennen wir das Ergebnis eines CAD-Imports in Meshparts: "CAD-Zwilling".
Der Bibliotheks-Gedanke
Die zweite wichtige Eigenschaft von Meshparts ist die integrierte Online-Bibliothek. Das kann man sich ähnlich wie bei CADENAS, aber eben für FEA vorstellen. In Meshparts werden also keine Zukaufteile modelliert. Stattdessen werden die entsprechenden CAD-Modelle durch bereits vorhandene FE-Modelle ersetzt.
Wir haben schnell realisiert, dass das Wegfallen der Modellierung von Zukaufteilen riesige Vorteile mit sich bringt, von denen ich hier einige nennen möchte:
- Der Anwender muss kein FEA-Experte mehr sein, um das komplexe mechanische Verhalten der Zukaufteile modellieren zu können.
- Da immer wieder dieselben Zukaufteile in unterschiedlichen Modellen vorkommen, spart der Anwender doppelt, nein, vielfach Zeit.
- Die Reproduzierbarkeit der FE-Ergebnisse ist gesichert; eine nennenswerte Quelle für Abweichungen, manchmal auch Fehler, wird geschlossen, da bekanntlich Simulationsingenieure dazu neigen ihre Modelle mal so, mal anders zu modellieren.
Die FE-Modellbibliothek ist also eine super Arbeitserleichterung und, fast noch wichtiger, ein echter Qualitätsgewinn.
Part Mappings
Bald haben wir uns jedoch überlegt, dass auch das Ersetzen von Zukaufteilen ja im Prinzip auch eine lästige, sich wiederholende Arbeit ist. Eine Lösung musste her.
Mitte 2020 haben wir die "Part Mappings" eingeführt. Das muss man sich wie eine Tabelle mit zwei Spalten vorstellen. In der linken Spalte stehen Namen von Zukaufteilen (so wie die CAD-Dateinamen). In der rechten Spalte stehen die Pfade zu den FE-Modellen aus der Meshparts-Bibliothek. Diese Tabelle kann gleich zu Beginn für alle Teile angelegt werden oder mit jedem neuen manuellen Ersetzen automatisch erweitert. Meshparts merkt sich also Ihre Aktionen für später. Wird also eine neue CAD-Baugruppe importiert, müssen die CAD-Zukaufteile nicht mehr neu vernetzt werden; sie werden automatisch entsprechend der Part Mappings ersetzt.
Die Part Mappings waren ein logisches Weiterdenken des Bibliotheks-Gedankens. Dadurch bekommt der Anwender einen weiteren bedeutenden Effizienz-Schub. Aber auch damit gaben wir uns nicht zufrieden. Die restlichen Bauteile und Baugruppen waren dran. Um zu verstehen, warum uns da noch etwas in unserer Software fehlte, muss ich kurz die Arbeitsweise von Unternehmen mit PDM-Systemen erläutern.
Wenn ein CAD-Konstrukteur eine CAD-Baugruppe in seinem CAD-Programm öffnen möchte, dann wird diese Baugruppe zunächst aus dem PDM-System heruntergeladen und lokal abgespeichert. Jetzt könnte es sein, dass der Konstrukteur ein gewisses Bauteil konstruktiv ändern möchte. Das macht er mit den im CAD-Programm vorhandenen Funktionen. Wenn er fertig ist, lädt er die geänderte Baugruppe oder das Bauteil zurück ins PDM-System hoch. Dabei wird dem geänderten Bauteil eine Versionsnummer zugewiesen. Jedes Teil und jede Baugruppe im PDM-System verfügt über eine Versionsnummer. Die Dateinamen dagegen bleiben gleich. Wenn also eine CAD-Baugruppe aus dem PDM-System heruntergeladen wird, kann man nicht nur anhand der Dateinamen erkennen, ob es sich dabei um einen alten oder neuen Konstruktionsstand handelt.
Meshparts auf der anderen Seite versucht mit jedem neuen CAD-Import bereits importierte Modelle wiederzuverwenden. Das funktionierte bis vor kurzem nur anhand der Dateipfade und des Datei-Änderungsdatums. Wenn ein importiertes Teil nicht bereits im Importordner vorhanden war, dann wurde dieses Teil angelegt und vernetzt. War aber das Teil bereits im Importordner vorhanden, wurde das Änderungsdatum des FE-Teils mit dem Änderungsdatum des CAD-Teils verglichen. So konnte Meshparts entscheiden, ob das fertige Teil einfach direkt übernommen oder doch neu vernetzt werden soll, weil das entsprechende Teil sich ja geändert hat.
Nun hatten wir bei der beschriebenen Logik drei Probleme erkannt:
- Dadurch, dass der Konstrukteur die CAD-Baugruppen immer wieder aufs Neue aus dem PDM-System herunterlädt, war das Änderungsdatum der CAD-Dateien immer anders, auch wenn sie sich nicht wirklich änderten.
- Dazu kam noch, dass der Ordner sich auch noch ändern konnte, obwohl die Baugruppen gemeinsame Teile enthielten. Es entstanden Kopien von den gleichen Dateien in unterschiedlichen Ordnern.
- Und schließlich, können auch gleichnamige Bauteile trotzdem unterschiedliche Konstruktionsstände enthalten.
Aufgrund der drei oben genannten Probleme konnte Meshparts bis vor kurzem im besten Fall nur Zukaufteile wiederverwenden, nicht jedoch eigens konstruierte Bauteile oder Baugruppen. Und das, obwohl es technisch möglich gewesen wäre. Es ist nun mal so, dass die Arbeitsweise mit einem PDM-System ihre Eigenheiten hat.
Collection Directories
Die Lösung kam Ende 2020 in Form von "Collection Directories" oder "Sammelordnern".
Auch die Collection Directories kann man sich als eine Tabelle mit zwei Spalten vorstellen. Links stehen die Quellverzeichnisse, rechts die Zielverzeichnisse, sprich Sammelordner.
Wenn nun eine CAD-Baugruppe in Meshparts importiert wird, dann werden alle Dateien, die unter einem Quellverzeichnis liegen, in das Zielverzeichnis kopiert. Wenn jedoch gleichnamige Dateien bereits im Zielverzeichnis liegen, werden diese von dort übernommen. Damit lösen wir schon mal das erste und zweite Problem (siehe die obere Auflistung).
Nun wird beim Benutzen von Collection Directories die Überprüfung des Datei-Änderungsdatums nicht mehr durchgeführt. Das heißt, vorhandene Modelle werden unabhängig vom Änderungsdatum wiederverwendet.
Schließlich musste also das dritte Problem aus der oberen Auflistung gelöst werden. Hierfür haben wir eine einfache Anbindung zum PDM-System entwickelt, über die die Versionierung der importierten Dateien überprüft wird. Der Versionsname wird übernommen und ein gleichnamiges Verzeichnis für jede versionierte Komponente im Collection Directory angelegt. Die entsprechenden Meshparts-Modelle werden dann in diese Versions-Verzeichnisse automatisch abgelegt. Somit ersetzt die PDM-Anbindung und die Versionsnummer das Datei-Änderungsdatum. Ansonsten bleibt alles beim Alten.
Schlusswort
Schon von Anfang an waren wir bei der Entwicklung von Meshparts von einem alles überragenden Ziel geleitet, nämlich ein Maximum an Effizienz durch konsequente Automatisierung und Wiederverwendbarkeit zu erreichen.
Ich bin mir sicher, dass unser Ziel nicht zu erreichen wäre, wenn unsere Software nicht baugruppen-basiert wäre. Es ist für uns schön zu sehen, wie eine Optimierung zur nächsten führt und wie am Ende alles einen noch höheren Sinn ergibt.
Zum Schluss komme ich auf den Gedanken zurück, den ich eingangs äußerte: Ich finde, ein Umdenken der FEA-Anwender wäre eine gute Idee. Fragen Sie sich, warum Ihre FEA-Software keine Baugruppen kennt. Stellen Sie sich vor, wie anders Ihre Arbeit wäre, wenn Sie mit FE-Baugruppen arbeiten würden.
