Kann KI Maschinensoftware selbst entwickeln, testen und debuggen?

Maschinensoftware entsteht normalerweise in getrennten Schritten. Ein Automatisierungsingenieur liest Anforderungen, schreibt SPS-Code, konfiguriert Motion, baut das Projekt und testet Teile der Lösung. Später trifft die Software auf die Mechanik. Erst dann werden manche Annahmen hinter dem Programm von der realen Maschine geprüft.

KI kann mehr dieser Schritte verbinden. Bei neexo können wir einem Engineering-Agenten bereits heute weit mehr als eine Quellcodedatei zugänglich machen. Er kann mit bestehender Maschinensoftware, Unternehmensarchitektur und Softwarebibliotheken, PackML, Motion, HMI, I/O, technischer Dokumentation und Informationen über die zu steuernde Maschine arbeiten. Er kann das Projekt bauen, nach Compilerfehlern weiterarbeiten, gegen eine virtuelle Maschine laufen, Traces analysieren und das Ergebnis in der nächsten Iteration verwenden.

Ein normaler Coding-Assistent kann einen Funktionsbaustein erklären, Structured Text vorschlagen oder bei einem Compilerfehler helfen. Das ist nützlich, doch die Maschine existiert nicht nur im Code. Eine Sequenz kann korrekt programmiert und trotzdem falsch für die Mechanik sein. Ein Motion-Profil kann korrekt konfiguriert sein und trotzdem zu wenig Zeit für den nächsten Prozess lassen. Ein Signal kann in der SPS korrekt behandelt werden, obwohl die Elektrodokumentation eine andere Absicht beschreibt. Eine Fehlerwiederherstellung kann im normalen Test funktionieren und scheitern, wenn die nachgelagerte Station stillsteht.

Erhält der Agent zusätzlich mechanischen und elektrischen Kontext, kann er Software und reales System zusammenführen. Informationen fließen in beide Richtungen: Anforderungen und technische Daten, Implementierung, Build, virtueller Test, Messungen und Traces, Analyse, Änderung und erneuter Test. Nach der physischen Inbetriebnahme können Daten der realen Maschine in denselben Prozess einfließen.

Ja, wenn der Agent eine klare Softwarearchitektur und die notwendigen Werkzeuge erhält. SPS-Software bei einem Maschinenbauer beginnt selten bei null. Es gibt vorhandene Prinzipien für Struktur, Benennung, Maschinenmodule, Betriebsarten, Alarme, Diagnose, HMI und Motion. Viele Unternehmen besitzen außerdem Softwarebibliotheken oder frühere Projekte, die zeigen, wie eine gute Lösung aufgebaut ist.

Damit hat der Agent einen deutlich besseren Ausgangspunkt als eine allgemeine Aufforderung, SPS-Code zu schreiben. Die Aufgabe kann stattdessen lauten, eine neue Transferstation nach dem bestehenden Maschinenstandard des Unternehmens zu implementieren.

Der Agent kann mit Zuständen und Übergängen, PackML-Integration, Verhalten im Automatik- und Handbetrieb, Interlocks, Alarmen und HMI-Status arbeiten. Enthält die Station Servoachsen, kann dieselbe Aufgabe Freigabe, Referenzfahrt, Positionierung, Grenzwerte, Fehlerzustände und die Motion-Funktionen der Projektarchitektur umfassen.

Er kann die Station außerdem in die umgebende Maschine integrieren. Wann darf die vorgelagerte Station ein Produkt übergeben? Wann ist die nachgelagerte Station bereit? Was passiert, wenn ein Produkt fehlt? Wie kehrt das Modul nach einem Stopp in einen bekannten Zustand zurück?

Das setzt gute Standards voraus. Eine unstrukturierte Codebasis wird nicht automatisch zu guter Maschinensoftware, nur weil KI darauf zugreifen kann. Wiederverwendbare Architektur, klare Schnittstellen und konsistente Prinzipien werden wertvoller, wenn Menschen und Agenten im selben Projekt arbeiten.

Die erste Rückkopplung ist einfach. Der Agent ändert das Projekt und baut es. Scheitert der Build, erhält er die Compiler-Ausgabe, findet die Ursache, nimmt eine Änderung vor und baut erneut.

Ein kompilierbares SPS-Projekt sagt noch nichts darüber aus, ob sich die Maschine richtig verhält. Deshalb kann der Agent in eine digitale Testumgebung weitergehen, in der die tatsächliche Maschinenlogik gegen ein Modell mit relevanter Mechanik, Sensoren, Aktoren, Produktfluss und Motion läuft.

Nehmen wir eine Transferstation als illustratives Beispiel. Sie übernimmt ein Produkt, positioniert es und gibt es weiter. Die normale Sequenz ist nur der Anfang. Der Agent kann außerdem testen, was passiert, wenn die nachgelagerte Station nicht bereit wird, ein Sensor später als erwartet schaltet, ein Produkt fehlt, eine Bewegung unterbrochen oder die Maschine mitten in einem Übergang gestoppt wird. Nach jeder Änderung können die relevanten Szenarien erneut laufen.

Ein Automatisierungsingenieur muss damit nicht mehr zwischen Implementierung und einer langen Reihe wiederholter Regressionstests wählen. Der Agent kann viel dieser Wiederholungsarbeit übernehmen, während der Ingenieur Architektur, Testabsicht und die Grenzen der Lösung festlegt. Test wird zu einem kontinuierlichen Teil der Entwicklung statt zu einer Aktivität, die erst kurz vor FAT volle Aufmerksamkeit erhält.

Die meisten Tests beginnen mit einer bekannten Erwartung. Wir wissen, dass ein Sensor ausfallen kann, also testen wir den Sensorausfall. Wir wissen, dass die nachgelagerte Station stoppen kann, also testen wir den Stopp. Ein früherer Fehler in der Wiederherstellung wird zum Regressionstest. Übrig bleiben Probleme, an die vorher niemand gedacht hat.

Kann der Agent Traces und Maschinendaten lesen, kann er einen Lauf auf Abweichungen untersuchen statt nur ein vorgegebenes Pass- oder Fail-Ergebnis zu prüfen. Ein Test kann bestehen, obwohl sich etwas Interessantes verändert hat.

Eine Achse braucht länger zum Beschleunigen. Das Drehmoment weicht vom Referenzlauf ab. Ein Programmzustand bleibt etwas länger aktiv. Eine Sequenz wartet häufiger auf eine bestimmte Signalabstimmung. Die Fehlerwiederherstellung nimmt einen anderen Weg durch das Programm. Keine dieser Beobachtungen ist automatisch ein Fehler. Es sind Hinweise, die der Agent untersuchen kann.

Er kann zur Softwareänderung zurückgehen, frühere Traces vergleichen, Motion-Parameter prüfen und untersuchen, ob die Abweichung mit anderen Teilen der Maschine zusammenhängt. Der Testplan bleibt notwendig, wird aber durch einen Agenten ergänzt, der Verhalten untersuchen kann, das vorher nicht explizit in den Testplan geschrieben wurde.

Eine der größten Grenzen eines reinen Code-Agenten ist, dass er die Erklärung naturgemäß in der Software sucht. Reale Maschinenprobleme halten sich nicht an diese Grenze.

Kommt eine Achse zu spät an, kann die Sequenz falsch sein. Ursache können aber auch das Motion-Profil, eine geänderte mechanische Last oder ein später eintreffendes Signal sein. Mit dem gesamten Kontext kann der Agent diese Möglichkeiten besser auseinanderhalten.

Stellen Sie sich vor, ein Trace zeigt, dass eine Bewegung nun länger dauert als in früheren Tests. Der Agent kann prüfen, ob sich der Startzeitpunkt aus der SPS geändert hat. Falls nicht, kann er Geschwindigkeits- und Drehmomentkurven vergleichen und die Messung anschließend mit der mechanischen Konfiguration und den relevanten Projektänderungen abgleichen.

KI kann nicht jeden physischen Fehler allein diagnostizieren. Sie kann aber Informationen zusammenführen, die normalerweise auf Automation, Mechanik, Elektrotechnik und Inbetriebnahme verteilt sind, und sie in derselben Untersuchung verwenden.

Vor der physischen Inbetriebnahme kann der Agent gegen die Simulation arbeiten. Danach lässt sich dieselbe Logik mit Traces und Messungen der realen Maschine ergänzen. Die Differenz zwischen erwartetem und beobachtetem Verhalten wird neuer Input für den Engineeringprozess. Die Simulation kann damit als Referenz für erwartetes Maschinenverhalten dienen, nicht nur als Testumgebung vor FAT.

Der Agent muss nicht nach jedem Compilerfehler oder fehlgeschlagenen Regressionstest einen Benutzer fragen. Ein großer Teil des Loops kann autonom laufen: Implementierung, Build, Test, Trace, Analyse, Änderung und Regressionstest.

Klare Grenzen bleiben notwendig, sobald Aktionen die physische Maschine beeinflussen oder wesentliche technische Annahmen verändern. Ein Agent kann zu dem Schluss kommen, dass ein Motion-Profil geändert werden sollte. Das ist etwas anderes, als das neue Profil automatisch auf eine Produktionsmaschine zu übertragen und die Achse zu bewegen.

Eine praktische Architektur verschiebt deshalb die Freigabepunkte. Menschen müssen nicht jede kleine Operation genehmigen. Freigabepunkte sind sinnvoller bei sicherheitsrelevantem Verhalten, Übertragung auf physische Hardware, neuen Bewegungsgrenzen und anderen Änderungen mit realen physischen Folgen.

Für die technische Leitung lautet die nützlichere Frage: Welche Aktionen darf der Agent selbst ausführen und verifizieren, und welche Änderungen benötigen fachliche Beurteilung oder eine Freigabe an der Maschine? Das ist konkreter als eine allgemeine Diskussion darüber, ob man KI vertraut.

Technische Dokumentation hat ein wiederkehrendes Problem: Sie wird oft nach der Arbeit geschrieben. Dann kann der Code zeigen, was die Lösung tut, erklärt aber selten vollständig, warum sie genau so entstanden ist.

Warum liegt dieses Interlock hier? Warum wurde dieses Motion-Profil gewählt? Welcher Test führte zur Änderung? Welche Alternativen wurden ausprobiert? Was zeigte der Trace?

War der Agent Teil des Engineering-Loops, existiert ein großer Teil dieser Informationen bereits. Er hat Anforderung, Implementierung, Build-Ergebnisse, Testszenarien, Traces, Änderungen und die anschließenden Regressionstests gesehen. Dadurch kann er die Entscheidung aus dem tatsächlich stattgefundenen Prozess dokumentieren.

Dokumentation kann Code und Parameter mit ihrer technischen Begründung verknüpfen. Sie kann erklären, welche Situation eine Änderung lösen sollte, welche Evidenz verwendet wurde und welche Tests danach liefen. Service versteht den Hintergrund, neue Ingenieure verstehen die Codeentscheidung, und das nächste Maschinenprojekt kann sowohl die Implementierung als auch die Testerfahrungen wiederverwenden.

Wenn Implementierung günstiger wird, gewinnen gute Anforderungen, Architektur, Randbedingungen und Testabsicht an Bedeutung. Der Agent muss wissen, was gute Software im jeweiligen Unternehmen bedeutet. Er braucht eine Maschinenarchitektur als Rahmen und muss zwischen einer unkritischen Softwareänderung und einer Änderung unterscheiden, die physische Validierung erfordert.

KI kann mehr der wiederkehrenden Arbeit zwischen diesen Entscheidungen übernehmen: Softwaremodule anlegen, Buildfehler beheben, Regressionstests ausführen, Traces vergleichen, Schnittstellen prüfen und Dokumentation aktuell halten. Das Ergebnis sollte nicht nur an eingesparten Programmierstunden gemessen werden. Interessanter ist, wie viel mehr Engineeringarbeit das Team innerhalb derselben Projektzeit leisten kann.

Starten Sie nicht mit der ganzen Maschine. Wählen Sie ein abgegrenztes Maschinenmodul mit realer SPS-Funktion, klaren Schnittstellen und digital testbarem Verhalten. Das kann ein Transfer, eine Prozessstation oder ein Motion-Modul sein. Geben Sie dem Agenten den bestehenden Standard und nur die Werkzeuge, die er wirklich benötigt. Lassen Sie ihn eine abgegrenzte Änderung implementieren, das Projekt bauen und einen bekannten Testsatz ausführen.

Danach kann der Loop um weitere Regressionstests, Traces, mechanischen und elektrischen Kontext und schließlich Feedback von der physischen Maschine erweitert werden. Ein Engineering-Agent sollte daran gemessen werden, ob er eine Änderung liefern kann, die sich kompilieren lässt, korrekt funktioniert, relevante Tests besteht und nachvollziehbar dokumentiert, warum die Lösung so aussieht.