Europe 
Türkiye 
United Kingdom 
Global 
Anmeldung mit meinem Xometry-Konto 
Wir haben mit Kyrall-Mitbegründer Osama Atwi darüber gesprochen, wie sich native parametrische CAD-Modelle generieren lassen, die Ingenieure in Onshape weiterbearbeiten können. Zudem erklärte er, wie Kyrall DfM-Prüfungen (Design zur Herstellbarkeit) für die generierten Bauteile handhabt und welche drei konkreten Anwendungsfälle in frühen Pilotprojekten bereits echten Mehrwert bieten.
Manuelle Arbeit führt zu fragmentierten Abläufen
Welches Problem lösen Sie?
Es ist zweigeteilt. Die Art und Weise, wie wir mechanische Bauteile konstruieren, ist sehr manuell geprägt. Gleichzeitig ist der gesamte Konstruktionsbereich fragmentiert in Konstruktion, Simulation und Fertigung. Es geht also um die manuelle Arbeit in jeder dieser Phasen und die fehlende Verbindung dazwischen.
Worin besteht diese fehlende Verbindung?
Die Formate, die wir in den einzelnen Bereichen nutzen, sind komplett voneinander getrennt. Wenn man eine Konstruktion abschließt und das Bauteil als STEP- oder STL-Datei exportiert, geht in diesem Format ein Großteil der Konstruktionsabsicht verloren. Die Konstruktionsabsicht umfasst die Reihe von Entscheidungen, die ein Ingenieur trifft, um ein Bauteil auf eine bestimmte Weise zu konstruieren, sowie die dabei befolgte Reihenfolge. Das lässt sich nur schwer erfassen, da es meist nicht explizit dokumentiert ist und auch nicht im Dateiformat gespeichert wird.
Führt man eine Simulation durch, ist es schwierig, die Ergebnisse wieder in den Konstruktionskreislauf einzuspeisen. Geht es an die Fertigung, fehlen oft viele Informationen, die man benötigt, um für ein bestimmtes Verfahren zu konstruieren. Daher muss der Entwurf überarbeitet werden, damit er zur Methode passt. Eine native parametrische Datei ist besser als STEP oder STL. Sie erfasst zumindest die Schritte, die beim Aufbau des Bauteils befolgt wurden, spiegelt aber immer noch nicht die gesamte Konstruktionsabsicht wider.
Und die andere Hälfte des Problems war die manuelle Arbeit.
Wenn wir uns auf CAD konzentrieren, ist das so, als wollte man ein Feld von Hand pflügen, weil der Traktor noch nicht erfunden wurde. Ein großer Teil der CAD-Arbeit besteht, wenn man das eigentliche Engineering abzieht, nur aus Klicken in einer Software. Man erstellt eine Skizze, zeichnet einen Kreis, extrudiert ihn, verrundet die Kanten und fügt eine Bohrung hinzu. Diese Schritte kosten Zeit, und es dauert Jahre, sie zu erlernen, aber das ist kein echtes Engineering. Genau diese manuelle Arbeit sollte unserer Meinung nach automatisiert werden.
Bedeutet Engineering also, dass ich mir das Bauteil ausdenke, und ist die Übertragung dieser Vision in den Computer nur manuelle Arbeit, die es so nicht geben sollte?
Wenn es einen Weg gibt, mein gesamtes Wissen direkt in ein 3D-Modell zu übersetzen, dann ist das ein Weg, den manuellen Schritt zu automatisieren, ohne das Engineering an sich zu automatisieren. Viele glauben, das Ziel sei es, die Arbeit von Ingenieuren überflüssig zu machen. Das Gegenteil ist der Fall. Es geht darum, sie von dem mühsamen manuellen Teil zu befreien, damit sie sich auf das konzentrieren können, was wirklich zählt: die Funktion, die Anforderungen, das Bauteil, das sie konstruieren.
Wir setzen CAD oft mit Engineering gleich, weil es die Umgebung ist, in der wir arbeiten, das Greifbare, das unsere Arbeit repräsentiert. Das ist, als würde man ein ganzes Gemälde mit der Kunst selbst gleichsetzen. Aber der Rahmen des Gemäldes ist keine Kunst. Wenn es eine andere Möglichkeit gibt, Engineering darzustellen und dabei die manuelle Arbeit zu beseitigen, können wir das ebenfalls als Engineering betrachten.
Was ist Engineering dann?
Auf einer höheren Ebene ist es Problemlösung. Konkreter gesagt: Es bedeutet, das über Jahre erworbene Wissen, gepaart mit neuen Informationen und den verfügbaren Werkzeugen, zu nutzen, um ein sehr spezifisches Problem innerhalb festgelegter Einschränkungen und Anforderungen zu lösen. In der Luft- und Raumfahrt heißt das, ein Flugzeug zu konstruieren, das fliegt und sicher ist. Der gleiche Ansatz gilt für die Automobilbranche, die Robotik & Automatisierung und den klassischen Maschinenbau.
Wo sind Sie auf dieses Problem gestoßen oder wann ist es Ihnen aufgefallen?
Bei meiner Arbeit als Ingenieur haben wir viele kleine Drohnen konstruiert. Jedes neue Projekt bedeutete, mehr oder weniger bei null anzufangen, da kaum etwas wiederverwendbar war. Also begann ich, Software-Tools fest zu programmieren, um die Konstruktion eines Drohnenrahmens zu automatisieren. Irgendwann reichte dafür ein Knopfdruck. Allerdings musste ich das für einen ganz bestimmten Rahmen hartcodieren. Eine andere Konfiguration bedeutete, einen neuen Konfigurator von Grund auf neu zu entwickeln. Die vorhandenen Werkzeuge waren für diese Art der Automatisierung nicht ausgelegt.
Punkte im Raum durch ein Skript ersetzen
Wie will Kyrall dieses Problem für die Industrie lösen?
Im Kern bewegen wir uns auf das zu, was wir die Kompilierbarkeit von 3D-Modellen nennen. Wir wollen 3D-Modelle im Grunde wie Code behandeln. Das löst das Fragmentierungsproblem, da man ein einziges Format erhält, das durch die gesamte Engineering-Pipeline fließt. Zudem vereinfacht es die Generierung.
Anstatt Punkte im luftleeren Raum zu generieren, um ein Modell aufzubauen, generieren wir ein Skript, und dieses Skript erstellt dann das 3D-Modell. Wir können es auf Fehler prüfen, Merkmale extrahieren und Metadaten einbetten, die in nachgelagerten Prozessen wie der Simulation und anderen Tools verwendet werden. Der Benutzer interagiert jedoch nie direkt mit dem Code. Dieser bleibt im Hintergrund und wird bearbeitet und aktualisiert, während der Entwurf reift. CAD-Bauteile sind im Grunde bereits Code, aber das Potenzial dieses Codes wird nicht voll ausgeschöpft.
Bedeutet das, dass Sie ein eigenes CAD-System entwickeln?
Nicht wirklich. Wir bauen unsere eigene Infrastruktur und unsere eigenen Formate auf, aber unser Ansatz lautet nicht: „Werfen Sie alles weg, was Sie haben, und nutzen Sie unser Tool.“ Es ist ein eigenständiges System, das sich in die bereits genutzten Lösungen integriert. Aktuell können wir in Onshape lesen und schreiben. Wir können auch CATIA, NX, SolidWorks und Creo einlesen und arbeiten daran, diese Formate auch schreiben zu können.
Führen Sie mich durch den Prozess der Bauteilgenerierung mit Kyrall.
Das hängt davon ab, wie man arbeitet. Manche haben technische Zeichnungen oder Skizzen, die das Bauteil beschreiben. Andere beschreiben es einfach in Textform. Wieder andere haben eine präzise Beschreibung, etwa eine Excel-Tabelle mit den genauen Verbindungspunkten und Abmessungen, und wir konstruieren das Bauteil daraus parametrisch. Einige nutzen es als Reverse-Engineering-Tool, um ein Bauteil anhand von Zeichnungen parametrisch nachzubilden.
Sobald ein Bauteil generiert ist, kann man es per Texteingabe weiterbearbeiten oder einen Teil einer Baugruppe markieren und nur diesen anpassen. Wenn Leute an KI denken, gehen sie oft davon aus, dass sie halluziniert oder dass die Änderung eines Teils gleich alles andere mit verändert. Wir haben das System so aufgebaut, dass man isoliert nur eine einzige Sache ändern kann. Und da alles parametrisiert ist, ändert man einfach eine Zahl. Soll der L-Winkel etwas länger sein? Zahl ändern, Eingabetaste drücken, und in weniger als einer Sekunde ist alles aktualisiert.
Wie erstellen Sie Bauteile, die tatsächlich den Richtlinien für die Herstellbarkeit entsprechen?
Wir integrieren derzeit Prüfungen für das Design zur Herstellbarkeit (DfM). Dabei konzentrieren wir uns zunächst auf das 3-Achs-Fräsen sowie den FDM-, SLA- und SLS-Druck und weiten dies später auf die Blechbearbeitung und andere Verfahren aus. Jedes Bauteil kann in das DfM-Tool eingespeist werden. Der Benutzer wählt die Fertigungsmethode, und das Bauteil wird so angepasst, dass es die Prüfungen besteht.
Wir unterteilen diese Anforderungen in statisch und dynamisch. Statische Anforderungen müssen zwingend erfüllt sein, damit das Bauteil mit der jeweiligen Methode überhaupt gefertigt werden kann. Wenn ich eine Platte fräse, darf eine Tasche keine scharfen Innenecken haben; diese müssen verrundet sein. Eine dynamische Anforderung ist subjektiver, etwa die Frage, ob ein bestimmter Radius auf einer bestimmten Maschine den Kauf eines neuen Werkzeugkopfs erfordert. Die Prüfungen selbst basieren auf festen Regeln. Die Integration entlang der Pipeline erfolgt jedoch KI-basiert, da der Prozess nie vollständig deterministisch ist.
Wenn ein Bauteil gegen eine Konstruktionsregel verstößt, erscheint eine Pop-up-Empfehlung. Ein einfaches Beispiel ist der Mindestabstand einer Bohrung zur Plattenkante, der normalerweise das 1,5-fache des Bohrungsdurchmessers beträgt. Sitzt eine Bohrung zu nah am Rand, markiert das Tool dies. Diese Regeln können branchen- und benutzerspezifisch feinabgestimmt werden.
Drei Hauptanwendungsfälle
Einige Unternehmen in diesem Bereich werben mit dem Slogan „Beschreibe ein Turbinentriebwerk, und es kommt fix und fertig heraus.“ Wie sieht die Realität aus?
Es gibt viel Lärm um dieses Thema. Und Text-to-CAD ist ein schlechter Begriff. Er erweckt den Eindruck, man tippt ein „Konstruiere mir ein Düsentriebwerk“, drückt auf Enter und heraus kommt ein fertiges Triebwerk.
Das haben wir aus erster Hand erlebt. Wir haben das Tool Testern gegeben, die erfahrene Maschinenbauingenieure waren. Sie gaben genau solche Prompts ein und waren dann enttäuscht, dass es nicht funktionierte. Wir fragten dann: Glauben Sie wirklich, dass Sie mal eben so einen kompletten Kampfjet konstruieren können? Warum gäbe es all die Unternehmen, die Kampfjets entwerfen, wenn das so einfach möglich wäre? Es war zum Teil unser eigener Fehler, weil wir die Erwartungen falsch gemanagt haben.
Wer glaubt, dass solche Tools bald ein Düsentriebwerk anhand eines einfachen Prompts konstruieren, weiß nicht, wie Düsentriebwerke eigentlich entwickelt werden. Engineering ist nicht nur 3D-Modellierung. Es umfasst die Berechnung des Bauteils, das Design zur Herstellbarkeit (DfM), Simulation, das Management von Anforderungen und Tests.
Es klingt, als hätten Sie aus Ihren Fehlern gelernt. Wie arbeiten Sie heute mit Kunden zusammen?
Anstatt ihnen das Tool in die Hand zu drücken und zu sagen „Legt los“ – denn das Erste, was sie tun würden, ist, etwas Unmögliches zu verlangen – gehen wir zu ihnen, analysieren ihre Prozesse und Engpässe und erarbeiten dann einen Vorschlag. Wir konzentrieren uns stark auf praxisnahe Projekte direkt beim Kunden. Manchmal stellen wir fest, dass sie gar kein Problem haben, das wir lösen können. Das sagen wir ihnen auch ganz offen und ziehen weiter. Es ist gefährlich, eine Technologie um jeden Preis durchdrücken zu wollen. Man braucht sie schlichtweg nicht überall.
Wofür nutzen die Kunden Kyrall dann?
Ein Bereich ist die Konzeptentwicklung in der Luftfahrt. Wer eine neue Drohne konstruiert, möchte verschiedene Konfigurationen durchspielen. Das ist heute noch sehr viel Handarbeit. Mit unserem Tool lassen sich diese Iterationen in Minuten statt in Wochen durchführen, da man den Entwurf einmal erstellt und anschließend jeden beliebigen Parameter anpassen kann.
Ein weiterer Anwendungsfall ist die Generierung von Assets. Wenn man an Baugruppen arbeitet, braucht man oft einen Servomotor, einen Steckverbinder oder eine Halterung. Heute sucht man danach online und findet meistens nicht genau das, was man braucht. Niemand hat Lust, einen Servomotor komplett neu zu konstruieren, nur um ihn in eine Baugruppe einzufügen. Ein einfaches Modell kostet vielleicht anderthalb Stunden, und bei einer größeren Baugruppe summieren sich diese Zeiten schnell auf viele Stunden im Monat.
Der dritte Fall ist das Konstruieren für Nicht-Konstrukteure – also Personen, die zwar technisch versiert sind, aber in einem anderen Fachgebiet arbeiten und auf die Schnelle ein PCB-Gehäuse oder eine Motorhalterung aus dem 3D-Drucker benötigen. Heute müssen diese Leute entweder selbst CAD lernen oder den Maschinenbauingenieur stören. Das haben wir während der Testphase sehr oft gehört: Maschinenbauer, die uns baten, den Kollegen das Tool zu geben, damit sie nicht ständig wegen solcher Kleinigkeiten zu ihnen kommen.
Wer ist denn eigentlich die genaue Zielgruppe?
Diese drei Beispiele decken fast jeden ab, von nicht-technischem Personal über Junioren bis hin zu erfahrenen Ingenieuren. Wo genau der größte Mehrwert entsteht, wird sich noch zeigen. Aktuell scheint er sich jedoch über die gesamte Engineering-Pipeline zu verteilen.
Was ist mit Kunden aus Branchen, die keine Konstruktionsdaten an einen externen LLM-Anbieter senden dürfen?
Das ist für viele von ihnen eine große Sorge – und das völlig zu Recht. Wir trainieren unsere eigenen, kleineren Sprachmodelle, die lokal auf den Rechnern der Kunden laufen, ohne dass dafür eine riesige GPU-Infrastruktur erforderlich wäre. Die Daten verlassen deren Umgebung zu keinem Zeitpunkt.
Ein positiver Nebeneffekt: Sobald das System lokal gehostet wird, können wir das Modell anhand des kundeneigenen Archivs alter Konstruktionsdaten weiter feinabstimmen. Sie erhalten also nicht einfach das Modell, das alle anderen auch haben, sondern eines, in das ihre eigenen Konstruktionspraktiken eingeflossen sind. Es läuft On-Premise, wo sonst niemand Zugriff darauf hat. Wir sprechen mit Unternehmen, die 50 oder 100 Jahre alt sind, und ein Punkt, den sie immer wieder ansprechen, ist die riesige Menge an Bestandsdaten, die sie kaum nutzen, weil der Zugriff darauf extrem schwierig ist. Wir können diese Daten auslesen, konvertieren und das Modell damit verfeinern.
Verschiedene Stufen für jeden Nutzer
Was kostet das?
Wir verfolgen einen lizenzbasierten Ansatz, da die Branche daran gewöhnt ist. Vorerst ist es ein normales Abonnementmodell mit verschiedenen Abstufungen. Darüber hinaus haben wir ein separates Angebot für Enterprise-Kunden, die zusätzliches Fine-Tuning, lokales Hosting oder andere maßgeschneiderte Anpassungen benötigen.
Angenommen, ich habe einen 3D-Drucker und keinerlei Konstruktionserfahrung. Gibt es für mich auch eine Einstiegsmöglichkeit?
Für diesen Anwendungsfall liegt der Preis in einem Rahmen, den man von Konsumgütern erwartet – absolut machbar für Hobbyanwender. Wenn es rein um die Generierung geht, bewegt sich das im üblichen Rahmen eines Standard-Abonnements.
Gibt es vollständige Integrationen über Onshape hinaus?
Wie gesagt, wir lesen bereits die gängigsten CAD-Dateien ein. Wir arbeiten an Lese- und Schreibfunktionen, aber wann genau die Einführung stattfindet, steht noch nicht fest. Die Integration mit den meistgenutzten CAD-Programmen steht fest auf unserer Roadmap.
Ist Kyrall ausschließlich ein browserbasierter Editor?
Wir bieten es nicht nur als Browser-Tool an, sondern auch als API. Mit Programmier-Copiloten lassen sich in kürzester Zeit sehr spezifische Anwendungen auf Basis von Kyrall erstellen. Möchten Sie eine App, die eine STL-Datei eines Werkzeugs nimmt und eine Shadow-Box dafür erstellt? Oder eine App, die Vorrichtungen und Halterungen aus einem Bauteil generiert? So etwas können Sie über unsere API schnell entwickeln, ohne für jeden einzelnen Anwendungsfall eine spezielle Softwarelizenz erwerben zu müssen.
Eine Mischung aus Leidenschaft und Kritik bringt uns weiter
Es gibt bereits einige Namen in diesem Bereich. Wie viele Gewinner wird es am Ende geben?
Der Markt ist riesig, es wird also mehrere geben – ähnlich wie in der CAD-Welt, wo heute auch kein einzelnes CAD-Paket absolut dominiert. Wer am Ende gewinnt, hängt davon ab, wer sich von Anfang an darauf konzentriert, echte Probleme zu lösen, anstatt nur etwas zu entwickeln, das gut aussieht. Es ist ein schwieriger, konservativer Bereich, in dem es nur wenig Innovation gibt – und das aus gutem Grund. Mit diesen Werkzeugen werden Autos, Flugzeuge und Maschinen gebaut, die Menschen täglich nutzen. Die Messlatte für Sicherheit und Zuverlässigkeit liegt extrem hoch, und das sollte auch so bleiben.
Ich fand es schon immer amüsant, dass Ingenieure alles innovativ weiterentwickeln – nur nicht ihre eigenen Workflows.
Wenn Hardware-Ingenieure sich nach Software umsehen, haben sie extrem hohe Erwartungen. Hardware ist kompliziert, also gehen sie davon aus, dass Software einfach ist – was meistens nicht der Fall ist. Das ist einer der Gründe für die überzogenen Erwartungen. Dieser Widerstand ist auch nicht neu. Das gab es schon bei der Einführung von CAD. Damals hieß es, es sei zu langsam, zu fehleranfällig, man könne von Hand viel schneller zeichnen. Heute würde niemand mehr behaupten, CAD sei nicht besser als das, was es davor gab.
Der einfache Teil bei Software ist, dass man sie testen kann. Bei Hardware verbringt man vielleicht ein Jahr mit der CAD-Modellierung, dann werden die Teile gefertigt, in einer Fabrik montiert, die Anlage wird in Betrieb genommen – und erst dann erfährt man, ob man einen Fehler gemacht hat.
Genau. Wir haben monatelang eine Drohne konstruiert, gebaut und montiert. Dann geht man aufs Flugfeld, und sie stürzt nach zwei Sekunden ab. Man friert im Dezember morgens um acht auf dem Platz, liegt hinter dem Zeitplan und über dem Budget, wirft die Drohne in die Luft – und sie schlägt sofort wieder auf. Das Schlimmste, was einem Softwareentwickler passiert, ist meistens, dass fehlerhafter Code kompiliert wird, und heute wird das von einem KI-Coding-Tool repariert. Engineering ist hart. Wir haben früher immer gesagt: Der erste Flugtest ist immer ein Absturz. Wenn sie beim ersten Test fliegt, ist das ein Wunder. Das bedeutet nicht, dass Software einfach ist; es bedeutet nur, dass sie einfacher ist.
Wie viel des Interesses an KI-Tools ist einfach nur die Angst, etwas zu verpassen?
Das entspricht eigentlich nicht unserer Erfahrung. Meistens sind die Leute skeptisch, eben weil es sich um KI handelt. Sie befürchten Halluzinationen oder sehen darin eher Chatbots als ein echtes Engineering-Tool. Sie sind vorsichtig und stellen viele technische Fragen – wie es sich integrieren lässt, wie wir das Problem der Halluzinationen gelöst haben und was mit ihren Daten passiert. Und genau so sollte es auch sein. Wer dem Trend nur aus der Angst heraus folgt, etwas zu verpassen, wird die Technologie wahrscheinlich ohnehin bald wieder aufgeben.
Es ist gesund, sowohl Leidenschaft als auch Kritik oder sogar Ablehnung zu erfahren. Wenn alle nur Beifall klatschen, bekommt man kein ehrliches Feedback. Wenn alle nur meckern, kommt man nicht voran. Wir brauchen eine gute Mischung. Mehr Unternehmen müssen diese Technologien vorantreiben und bereit sein, Dinge schon in einem frühen Stadium zu testen. Denn wer will, dass das in drei oder vier Jahren funktioniert, muss heute damit anfangen. Die Art und Weise, wie wir Maschinen konstruieren, wird unweigerlich nicht dieselbe bleiben. Und die Unternehmen, die bereit sind, solche Werkzeuge auszuprobieren, werden den anderen deutlich voraus sein.
Wen sollte man in diesem Bereich außer Ihnen noch im Auge behalten?
Bench AI leistet hervorragende Arbeit bei der Aufbereitung von Modellen nach der Simulation, um diese wieder in den Konstruktionsprozess einzuspeisen. nTop macht viel im Bereich Design-Exploration. Und Synera ist führend bei agentenbasierten Workflows und Integrationen über verschiedene Tools hinweg.
Related Topics
Uliana Krayneva
Contact VED
2
1
Comment(0)