Für Mehran Mestichan von MathWorks, der Stateflow entwickelt hat, steht fest, dass die Grundprinzipien des Engineering Designs erhalten bleiben, wenn KI Teil des Prozesses wird. Trotzdem müssen sich Ingenieure nach Überzeugung des Senior Director of Engineering auf grundlegende Änderungen einstellen: Anstatt den Entwurf selbst zu implementieren wird der Designer die Schleife für die Erstellung des Entwurfs kreieren, die dann von der KI ausgeführt wird. Entsprechend werden einige Fähigkeiten der Entwickler nicht mehr im bisher erforderlichen Umfang benötigt, während andere bislang nur gelegentlich genutzte Fähigkeiten in den Vordergrund rücken.
AEEmobility: Sie erwähnten anlässlich Ihres Vortrags im Rahmen der MathWorks AUTOMOTIVE CONFERENCE 2024 Europe zum Einsatz von KI im Engineering Design, dass sich die Prinzipien des Engineerings durch deren Einsatz nicht ändern. Was meinen Sie damit?
Mehran Mestchian: Für mich ist das Design die bewusste Gestaltung von Dingen, um sie in eine bevorzugte Form zu bringen, und Technik die Anwendung von Wissenschaft und Mathematik zur Lösung von Problemen. Beim technischen Design bringen wir diese beiden Aspekte zusammen.
Fügen wir nun KI dazu, ändert sich nur das Wie – also wie wir die Formgebung und die Problemlösung umsetzen – aber nicht das Warum.
Diese Definition lege ich immer wieder verschiedenen Ingenieursgruppen vor, um deren Gedanken dazu zu hören. Da gibt es sehr große Unterschiede, über die es sich lohnt, nachzudenken. Die Antwort auf die Frage, was Engineering Design ausmacht, ist auch eine persönliche Reise.
Technisches Design ist aber unabhängig davon ein zielorientierter Prozess, der den Menschen in den Mittelpunkt stellt.
Die Verwendung der Methode der abduktiven Entscheidungsfindung ist dabei von zentraler Bedeutung. D.h., der Entwickler muss auch bei unvollständigen Informationen seine Schlussfolgerungen ziehen. Diese Art des logischen Denkens ist für den Akt des Engineerings unabdingbar, bei dem tausende oder zehntausende Entscheidungen getroffen werden müssen. Diese Entscheidungsfindung beinhaltet Iterationen zur Problemlösung.
Die Festlegung der bevorzugten Form bzw. die Zielorientierung kann dabei nicht von der KI kommen. Die KI kann dabei helfen, die Ziele zu verfeinern und die Schleifen zu automatisieren. Die KI erhöht die Fähigkeit dieser Schleifen, ihre Arbeit zu erledigen, und gibt damit dem Entwickler vielleicht mehr Zeit, um über die Designziele nachzudenken.
Aber die grundlegenden Designprinzipien verändert der Einsatz von KI nicht.
Mehran Mestichan ist Senior Director of Engineering
von MathWorks und ist u.a. Entwickler des Tools Stateflow.
Es wird also Ihrer Überzeugung nach immer einen menschlichen Akteur brauchen?
Wie soll die KI entscheiden, was das Ziel der Design-Aufgabe ist? Ob Sie nun die Optimzation Toolbox in MATLAB oder eine KI oder einen generischen Algorithmus verwenden, bleibt es der menschliche Designer, der festlegt, was seine bevorzugte Lösung ist, indem er das Experiment bzw. die Entwicklungsschleife festlegt.
Die Entwicklungsschleife ist das eigentliche Ergebnis des Denkprozesses des Designers. Es ist dabei selbstverständlich möglich, dass auch die Schleife Entscheidungsfindung beinhaltet. Natürlich möchten wir uns das Leben einfach machen und Entscheidungen automatisieren und delegieren. Dagegen spricht nichts!
So lassen sich selbst sehr komplexe Probleme bewältigen: Teilen Sie das Problem gegebenenfalls in Tausende Schleifen auf, nutzen Sie dabei jede verfügbare Technik wie Optimierungsalgorithmen und andere mathematische Methoden inkl. KI und automatisieren Sie so viel wie möglich.
Anstatt also das Design selbst zu erstellen, entwirft der Entwickler die Schleife für die Erstellung des Designs. Dazu muss der Entiwckler zwar die Eckpunkte des vom ihm gewünschten Ergebnisses festlegen, braucht aber nicht mehr alle Details zu kennen. Er muss dann entscheiden, ob das Ergebnis nach Durchlaufen der Schleife gut genug ist oder nicht.
Das entspricht im Grunde den systematischen Ansätzen, die wir immer schon genutzt haben, um komplexe, kaum beherrschbare Probleme in Teilprobleme zu zerlegen, die wir dann lösen können.
Natürlich gibt es für jedes dieser Teilprobleme einschränkende bzw. einzuhaltende Randbedingungen. Üblicherweise kommt es dann technisch gesprochen zu einer Impedanz-Fehlanpassung: Die optimale Lösung einer Schleife ist nicht kompatibel mit einer optimalen Lösung einer anderen Schleife.
Bleibt das Problem der Zielkonflikte bei dem Teile-und-Herrsche-Ansatz, wie Sie ihn beim Einsatz von
KI vorschlagen, nicht bestehen?
Ich erwarte, dass wir mit den Fortschritten, die wir machen, KI und insbesondere generative KI nutzen können, um auch diese Verknüpfung der Designschleifen in gewissem Maße zu automatisieren. Das würde bedeuten, dass sich der Entwickler noch viel mehr auf das Warum und die Entwicklungsziele konzentrieren könnte.
Die Übersicht der KI-gestützten Tools im MathWorks-Portfolio zeigt: Deren Zahl nimmt rasant zu. © The MathWorks, Inc.
Inwieweit müssen sich die Fähigkeiten des Entwicklers ändern, sobald KIs Teil des Designprozesses werden?
Die Fähigkeiten der Ingenieure müssen sich mit dem Einsatz von KI im Engineering Design disruptiv ändern, aber anders als es die meisten Leute erwarten. Ich habe das mit einigen meiner Teams bereits exerziert. Das wurde anstrengend. Als Entwickler kann ich mich nicht mehr entspannt zurücklegen und sagen: „Sehen Sie, Chef, mein Code ist sehr effizient, Sie können meinen Lohn erhöhen“, oder „Ich habe so viel Zeit damit verbracht, dies zu optimieren“. Es geht zukünftig vielmehr um die Beschäftigung mit den Designzielen.
Dafür brauchen die Ingenieure aber nicht ganz neue Fähigkeiten erlernen. Es sind Stärken gefragt, die sie bereits als Entwickler besitzen, aber bisher nur gelegentlich genutzt haben.
Während meiner Zeit als Consultant bei Bosch Scintilla gehörte es einmal zu meinen Aufgaben, eine Ladezustandsanzeige für akkubetriebene 9,6-V-Bohrmaschinen zu entwickeln. Ich habe die Aufgabe im Kern mit einem Kalman-Filter gelöst. Den zu entwickeln, war einfach. Dann habe ich aber sechs Monate damit verbracht, Low-Level-Code zu schreiben, um eine Festkomma-Implementierung des Kalmanfilters zu erhalten.
Und als ich das getan hatte, war nur der Anfang geschafft, denn es gab all diese vielen Zustände, für die ich Lookup-Tabellen erzeugen musste, die das Verhalten der Batterie nachbildeten. Damit war die Arbeit immer noch nicht getan – ich musste das Ganze noch in den Mikrochip der Ladezustandsschätzung integrieren, der dafür natürlich zu klein war, sodass ich den Code in den Prozessor des Ladegeräts auslagern musste. Dafür musste ich wiederum ein Kommunikationsnetzwerk zwischen der Ladezustandsschätzung im Batteriepack und dem Ladegerät aufbauen.
Die entscheidende Frage: Wie viel davon war der innovative Anteil, der den Unterschied macht? Die KI kann uns helfen, mehr Zeit für die Ausarbeitung des Mehrwerts freizuschaufeln.
Was wäre Ihr Rat an Ingenieure, die sich auf die neue Art des Entwickelns einstellen wollen und erste Schritte gehen wollen? Womit sollten sie starten?
Wir brauchen Erfolgserlebnisse. Ich kann nicht sagen, wo diese als erstes auftauchen werden, aber typischerweise passiert das an den Rändern eines bestimmten Segments der Industrie. Der Erfolg wird dann für sich selbst sprechen und an vielen Stellen mutiert und nachgeahmt werden. So war das schon beim modellbasierten Design der Fall.
Als wir bei MathWorks zur Überzeugung gelangt waren, dass sich der Einsatz des Model-Based Designs im Engineering lohnen würde und wir mit MATLAB, Simulink, Stateflow und den Produktionscode-Generatoren auch die erforderlichen Tools beisammenhatten, sahen viele Entwickler das modellbasierte Design noch als aufwändigen zusätzlichen Schritt an und lehnten ihn ab. Aber einige Entwickler konnten wir überzeugen und die griffen das Thema auf und landeten dann damit einen Volltreffer.
Die erste europäische Firma, die das gemacht hat, war Mercedes-Benz. Die haben Model-Based Design unter der Leitung von Armin Müller bei der ESP-Entwicklung eingesetzt. Bei Toyota hat sich Akira Ohata und bei Ford Ken Butts für die neue Methode stark gemacht und damit Erfolge gefeiert.
Sie waren wohlgemerkt zu jener Zeit noch keine Ingenieure in leitender Funktion. Aber sie machten durch ihren Einsatz für das Model-Based Design einen Homerun!
Das ESP-Programm war ein Volltreffer. Das war das erste ADAS-System. Da haben sich manche gefragt, wie haben die das bei Mercedes Benz gemacht, vielleicht sollten wir bei uns etwas ändern.
Eine konkretere Antwort habe ich also auf Ihre berechtigte Frage leider auch nicht.
Aber es gibt Ingenieure, die KI schon heute nutzen. Wir werden daraus lernen, was wir übersehen haben, was eventuell falsch gemacht worden ist, und wir werden uns entsprechend anpassen. Das gehört einfach zur Inkubationszeit bzw. folgt dem Verlauf der oft zitierten Innovations-Adoptionskurve. Wo wir uns gerade auf dieser Kurve befinden, weiß ich auch nicht.
Die vier Hauptkateogieren im Kontext von KI-Modellen. © The MathWorks, Inc.
Das Potential von KI im Engineering scheint hoch zu sein. Es gibt aber in Deutschland und Europa Bedenken, dass wir beim Einsatz von AI in Tools und auch den Anwendungen hinterherhinken. Wie sehen Sie das?
Diese Frage zu beantworten, ist nicht einfach. Lassen sie mich das erklären. MathWorks beschäftigt sich seit dem Beginn der Ära des maschinellen Lernens mit KI. Die erste Toolbox für neuronale Netzwerke haben wir bereits im Oktober 1992 unter dem Namen Neural Network Toolbox vorgestellt. Jetzt heißt sie Deep Learning Toolbox.
Warum ich mich mit Ihrer Frage schwer tue, ob Europa oder Deutschland den Anschluss schon verloren hat, hat mit meiner persönlichen Sichtweise als MathWorks-Mitarbeiter zu tun.
MATLAB ist als vertrauenswürdige Umgebung für numerische Berechnungen bekannt. Leute verlassen sich seit Pentium-Zeiten darauf.
Wir stecken eine Menge Arbeit in den Bereich generative KI und andere Dinge. Die entscheidende Frage lautet: Wie können wir dabei sicherstellen, dass wir das Leistungsversprechen nicht verwässern?
Technik ist auf Präzision geeicht. In unserer Branche geht es um Genauigkeit, Qualität, Zuverlässigkeit, Safety und Security.
Die Präzision der KI-Antworten ist also entscheidend. LLMs betreiben aber Mathematik, die auf stochastischen Verfahren basiert und daher nicht besonders präzise sind. Anders gesagt: Die Antworten folgen der Normalverteilung. Wir brauchen also numerische Leitplanken, die durch Simulationen verifiziert werden.
Deshalb sage ich zu einem Teil meiner Teams, wenn ihr einen KI-Kopiloten benutzen wollt, tut das, aber stellt sicher, dass ihr den Code in Polyspace in Bezug auf die Softwarequalität mit Hilfe der statischen Analyse untersucht und testet.
Was muss noch getan werden, damit KI im Engineering Einzug halten kann?
Die Datensicherheit muss gewährleistet sein. Die Angriffsfläche von LLMs für Cyberangriffe ist riesig! Es gibt zahlreiche Möglichkeiten, ein LLM zu knacken. Beispielsweise mit Backdoor-Angriffen.
Es gibt vielfältige Wege, Daten zu korrumpieren, selbst wenn man das gar nicht beabsichtigt.
Wenn Sie also beobachten, dass KIs nur langsam im Engineering-Prozess auftauchen, dann liegt das daran, dass wir es mit einem technischen Bereich zu tun haben. Unsere Arbeit ist schwieriger. Leben Sie damit. Genießen Sie es. Es lohnt sich.
Einsatz von KI im Model Based Design. © The MathWorks, Inc.
Wie würden Sie die Stelle für einen zukünftigen Software System Engineer in der Automobilindustrie beschreiben?
Die Stellenausschreibung könnte in etwa wie folgt lauten. Wir sind ein deutsches Automobilunternehmen, führend im Einsatz von KI-Technologie in sicheren und zuverlässigen automobilen Systemen. Wir freuen uns auf einen Ingenieur, der mit dem dynamischen Kalibrierungs-Engineering von KI-Modellen in Automobilsystemen vertraut ist. Er oder sie sollte über fundierte Automobilsystemkenntnisse und Erfahrungen in der Verwendung von Data Science in diesem Umfeld verfügen.
Habe ich C-Programmierung gesagt? Nein. C++? Nein. Python, MATLAB? Nein. Ich gehe nämlich davon aus, dass die Software-Plattform, die Middleware, die das Unternehmen verwendet, stabil ist. Ein einziges Unternehmen kann nicht die finanziellen Mittel aufbringen, um Tausende von Ingenieuren dafür einzusetzen. Meinem Anzeigentext liegt also die Annahme zugrunde, dass der entsprechende Stack von anderen, darauf spezialisierten Unternehmen entwickelt und vermutlich weitgehend standardisiert wurde.
Worin liegt dann aber das Unterscheidungsmerkmal? Das Unterscheidungsmerkmal liegt in der Art und Weise, wie der OEM die Dynamik steuert, wie er das Gesamtsystem Auto gestaltet und wie effizient er das Design ändern kann.
All diese Dinge, die keine Programmierung erfordern, bzw. eine neue Art der Programmierung erfordern, sind das, was Andrej Karpathy zu seiner Zeit bei Tesla als Software 2.0 bezeichnet hat.
Auswirkung von KI auf Engineering Workflows. © The MathWorks, Inc.
Wenn man sich jedoch die modernen Arbeitsabläufe in der modellbasierten Kalibrierungstechnik anschaut, stellt man fest, dass die Grundprinzipien zwischen Software 2.0 und der Arbeit von Kalibrierungsingenieuren viele Gemeinsamkeiten aufweisen. Ich denke, es gibt eine enorme Menge an institutionellem Wissen in der modellbasierten Kalibrierungstechnik, das in Software 2.0 übersetzt und verallgemeinert werden kann! Aus diesem Grund bezeichne ich Arbeitsabläufe, die auf EdgeAI abzielen, manchmal als das Entwerfen und Kalibrieren „ausgefallener Lookup-Tabellen“.
Der Software-Ingenieur der Zukunft wird also weiterhin mit Software arbeiten, aber nicht so, wie wir es uns heute vorstellen – es könnte dem ähneln, was Kalibrierungsingenieure im Prinzip tun. Das ist meine Vorhersage, der wir uns derzeit asymptotisch nähern.
Wir müssen als Softwareingenieure lernen, wie wir Ziele systematisch in Unterziele und in Entwicklungsschleifen aufteilen, und dann herausfinden, wie wir diese Entwicklungsschleifen effektiv und effizient umsetzen können.
Ein letzter Blick in die noch etwas entferntere Zukunft: Wie wird sich das Engineerings durch Quantencomputing verändern?
Für mich steht nach einigen Überlegungen zum Quantencomputing fest, dass es sich um einen weiteren Zweig der Mathematik handelt, der es uns ermöglicht, Dinge zu tun, die zuvor unmöglich oder nicht praktikabel waren. Können wir schon absehen, wie das in 20 oder 30 Jahren praktisch aussieht? Eher nicht. Ich weiß jedenfalls nicht, wann der GPU-Moment für das Quantencomputing kommen wird und auch nicht, was ihn auslösen wird. Aber ich glaube fest daran, dass er kommen wird. (jr)
Steckbrief: Mehran Mestchian, Senior Director Design Automation, MathWorks
Mehran Mestchian ist Engineering Director im Bereich Automatisierung des Steuerungsdesigns bei MathWorks. Er trägt die Gesamtverantwortung für Modellierungssprachen und Verifizierungstechnologien. Mehran ist der ursprüngliche Autor von Stateflow.
Er hat an der Entwicklung zahlreicher Produkte zur Entwurfsautomatisierung mitgewirkt, darunter Simulink und die zugehörigen MATLAB- und Simulink-Codegenerierungs- sowie Verifikations- und Validierungsprodukte.
Bevor er 1993 zu MathWorks kam, arbeitete Mehran als Ingenieur für Echtzeitsysteme und Technologieberater in den Bereichen Industrie-, Automobil-, Pharma- und Kommunikationssysteme. Er erwarb seinen Master of Science in Kontrollsystemtechnik am Imperial College und seinen Bachelor of Science in Elektrotechnik am Queen Mary College, beide an der University of London.
