Beim Thema KI im Engineering überschlagen sich die Erwartungen. Was funktioniert heute tatsächlich schon gut?
Im Software-Engineering können wir grundsätzlich alle Phasen mit KI unterstützen. Was super funktioniert, ist das Erzeugen von Sourcecode, etwa in C#, Python oder Structured Text. Wir sehen das intern: Einzelne Tätigkeiten, für die man normalerweise zwei Tage braucht, sind in 15 Minuten gecodet. Damit ist natürlich nicht das komplette Entwicklungsprojekt erledigt. Auch Tests erzeugen, Fehler suchen oder sich Code erklären lassen funktioniert sehr gut. Ich sage meinen Entwicklern immer: Nutzt die KI wie einen Kollegen, mit dem ihr gemeinsam programmiert. Bei Spezialdomänen, zu denen wenig öffentliches Wissen existiert, lässt die Qualität allerdings nach. Und in der mechanischen oder elektrischen Konstruktion sind die Ergebnisse noch nicht so weit wie in der Softwareentwicklung.
Sie sehen den eigentlichen Fortschritt aber nicht im nächsten leistungsfähigeren Sprachmodell. Wo entsteht für Sie der industrielle Mehrwert?
Ich werde immer wieder gefragt: Baut ihr euer eigenes Modell? Aber ich glaube, es ist nicht das Modell, was entscheidet. Saubere Daten sind eine Grundvoraussetzung. Wenn das Modell und die Daten passen, habe ich damit heute aber noch keine wirkliche Differenzierung. Entscheidend ist, wie wir die Werkzeuge über den kompletten Lebenszyklus miteinander verbinden. Zunächst entsteht im Engineering das Automatisierungsprojekt. Dann läuft es auf der Maschine, und im Betrieb kommen Prozessdaten, Anomalieerkennung und Vorhersagen dazu. Jetzt wird es spannend: Wir bringen das alles miteinander in Kontext. Das Sprachmodell kennt nicht nur das Engineering, sondern bekommt auch Informationen über den aktuellen Zustand der Anlage. Es entsteht plötzlich Wissen über die Maschine. Nicht die einzelnen Bausteine sind der Gamechanger, sondern ihre Vernetzung.
Was bedeutet diese Rückkopplung aus der Produktion konkret – etwa, wenn eine Maschine unerwartet stehen bleibt?
Nehmen wir an, ein Programmierfehler führt nur in einer ganz bestimmten Prozesssituation zum Stillstand. Wer ausschließlich auf den Code schaut, sieht möglicherweise nicht, warum das passiert. Und wer nur die Prozessdaten betrachtet, kennt den Zusammenhang mit dem Programm nicht. Wir führen deshalb Informationen aus der Steuerung, dem Engineering und dem Machine Learning zusammen. Die KI kann sich Steuerungsdaten und Logfiles holen, nach erkannten Anomalien fragen und die Informationen mit dem Projekt verknüpfen. Dazu kommen Dokumentation, unser Hilfe-Center oder die PLCnext Community. Vielleicht gab es dort schon einen ähnlichen Fall. Auch interne Wissensdatenbanken des Kunden lassen sich einbeziehen. Aus dieser Kombination können Zusammenhänge sichtbar werden, die vorher nicht gemeinsam betrachtet wurden. Genau darin liegt für mich der differenzierende Teil: Die KI setzt die Informationen selbst miteinander in Verbindung.
Die Industrie diskutiert seit Jahren über Datendurchgängigkeit. Damit das auch für KI gilt: Braucht es hier ein spezielles neues Protokoll?
Dafür gibt es seit Ende 2024 das Model Context Protocol, vorgestellt von Anthropic. MCP ist zunächst eine Schnittstellendefinition. Sie hilft einem Sprachmodell, Werkzeuge und Informationsquellen zu nutzen, die es von sich aus nicht hat. Ein einfaches Beispiel: Eine KI kann eine E-Mail formulieren. Um sie zu versenden, braucht sie aber ein Werkzeug, das diese Funktion bereitstellt. Genauso gehen wir in der Automatisierung vor. Wir stellen über MCP Schnittstellen zum Engineering, zur Steuerung und zum Machine Learning bereit. Natürlich könnte ich Programmdateien, Logfiles und Informationen über den Feldbus auch händisch zusammensuchen und in einen Prompt packen. MCP hilft dem Modell, diese Informationen selbst einzusammeln und in einen Kontext zu setzen. Der Anwender muss also nicht mehr jeden einzelnen Informationsbaustein selbst zusammentragen. Welche Quellen und Funktionen zur Verfügung stehen, wird dabei ausdrücklich festgelegt.
Sie wollen Engineering und Produktionsbetrieb verknüpfen. Bieten Sie hierfür die Engineering-Software PLCnext Engineer und die Machine-Learning-Lösung MLnext an?
Mit PLCnext Engineer löse ich meine Automatisierungsaufgabe: Welche Feldbusteilnehmer und Ein- und Ausgänge habe ich? Was macht mein SPS-Programm? Welche Daten möchte ich speichern? MLnext hat dagegen zwei wesentliche Komponenten: Creation erzeugt das Machine-Learning-Modell, Execution führt es aus. Ich kann etwa Daten aus einem Zeitraum aufzeichnen, in dem meine Anlage im Idealzustand gelaufen ist. Daraus entsteht ein Modell, das anschließend überwacht, ob sie weiterhin im Normalzustand arbeitet. Die Ausführung kann auf einem Edge-Gerät oder einer Steuerung erfolgen. Die nächste Ausbaustufe ist Agentic Industrial AI: Wir implementieren in den jeweiligen Domänen Schnittstellen, damit ein Sprachmodell deren Informationen zusammenführen kann.
Viele Maschinenbauer haben aber weder Data Scientists noch große IT-Abteilungen. Wie niedrig ist die Einstiegshürde für die KI-Nutzung?
Wir wissen, dass unsere Kunden keine Data Scientists sind. Mit dieser Prämisse sind wir in die Entwicklung gegangen. Der Anwender sammelt seine Daten, beispielsweise in einer CSV-Datei. Seinen Prozess muss er natürlich kennen. Wenn er aus Erfahrung weiß, dass fünf Variablen entscheidend sind, wählt er diese aus und lässt ein Modell erzeugen. Im Hintergrund generieren wir unterschiedliche Modelle und testen sie automatisiert auf ihre Eignung. Dieses Verfahren heißt AutoML. Die dahinterliegende Data-Science-Komplexität bleibt für den Anwender verborgen. Am Ende erhält er eine Modelldatei, die er zur Ausführung bringen kann. Modellerstellung und -ausführung haben wir jeweils als App umgesetzt, mit einer Oberfläche, über die sich arbeiten lässt. Differenzieren wollen wir uns hier vor allem durch Einfachheit.
Wenn das Sprachmodell Einblick in das Engineering bekommt, steht auch das Know-how des Maschinenbauers auf dem Spiel. Wie schützen Sie dieses Wissen?
PLCnext ist Open by Design. Wir schreiben dem Kunden kein Modell vor. Bei der Auswahl geht es oft weniger um Leistung als um Datenschutz, geistiges Eigentum und Mandantentrennung. Ein Maschinenbauer hat vielleicht gerade wegen seines besseren Algorithmus einen Vorsprung. Dieses Wissen möchte er nicht unkontrolliert nach außen geben. Außerdem legt der Anwender fest, was das Modell sehen darf: Kritische Codebereiche oder Einstellungen können ausgeschlossen werden, auch über eine Unternehmensrichtlinie. Intern nutzen wir ebenfalls bestehende Modelle, ergänzt um Phoenix-Contact-spezifisches Know-how, etwa über Retrieval Augmented Generation oder zusätzlichen Kontext. Eigene Basismodelle trainieren wir dafür nicht.
Braucht jede Aufgabe das größte verfügbare Modell?
Nein, in vielen Anwendungen brauche ich kein Frontier-Modell. Deshalb können wir in bestimmten Kontexten zwei Modelle einbinden: Eines extrahiert Informationen aus Texten und übergibt sie als Kontext an ein leistungsfähigeres Modell für die Codeerzeugung. Auch den Tokenverbrauch müssen wir im Blick behalten. Ich glaube, dass spezialisierte Modelle wichtiger werden, die gegebenenfalls lokal im Unternehmen laufen. Entscheidend ist die Flexibilität bei der Auswahl. Unser Hebel liegt darin, Engineering, Laufzeit und Prozess intelligent zu verbinden.
Informationen zusammenführen ist das eine. Darf die KI daraus auch selbstständig Änderungen an der laufenden Maschine ableiten und ausführen?
Wir sprechen immer von Copiloten, nie von Autopiloten. Alles, was am Ende die Ausführung beeinflusst, hat bei uns einen Menschen dazwischen – Human in the loop. Wenn KI Code erzeugt, wollen wir eine bewusste Handlung des Anwenders, bevor dieser Code ins Projekt übernommen wird. Und über die MCP-Schnittstelle auf der Steuerung lassen wir nach heutigem Stand keinen Statuswechsel zu. Das Projekt wird darüber nicht verändert, ebenso wenig das I/O- oder Prozessabbild. Es ist eine unidirektionale Ausleitung der aktuellen Daten. Das ist eine wichtige Grenze: Informationen aus dem Betrieb für das Engineering nutzbar zu machen bedeutet nicht, der KI einen freien Durchgriff auf die Maschine zu geben. Die Fantasie, was man prinzipiell entwickeln kann, geht weit. Wir müssen aber mit der Technologie mitwachsen.
MCP erweitert die Handlungsmöglichkeiten einer KI erheblich. Wie verhindern Sie, dass daraus ein Sicherheitsrisiko wird?
Wenn man damit nicht bewusst und verantwortungsvoll umgeht, kann MCP aus Sicht der Security die Tür zur Hölle sein. Über einen Server lassen sich auch Funktionen bereitstellen, die Schaden anrichten. Deshalb brauchen wir klare Regeln: Welche Funktionen darf das Modell nutzen? Welche Informationen gebe ich ihm preis? Das muss der Anwender bewusst entscheiden. Intern haben wir eine fundierte Arbeitsanweisung für KI. Mein Rat an Kunden ist: Definiert zuerst, wie ihr damit arbeiten wollt. Da geht es um Haftung, Compliance und Sicherheit. Besondere Vorsicht ist bei der Build-Pipeline geboten, also bei den Abläufen rund um Continuous Integration und Continuous Deployment. Angriffe müssen nicht über den erzeugten Code kommen, sondern können die Software-Lieferkette treffen. Eine KI-Interaktion mit dieser Pipeline haben wir bei uns derzeit untersagt.
Wie prüfen Sie den erzeugten Code – gerade mit Blick auf funktionale Sicherheit?
Die Erzeugung von Safety-Code haben wir im Engineer zunächst ausgeschlossen. Aus meiner Sicht muss das nicht für immer so bleiben, wenn eine geeignete menschliche Kontrollinstanz vorhanden ist. Heute arbeiten wir mit menschlicher Sichtprüfung und Testfallerzeugung. Auch wenn ein Ingenieur selbst entwickelt, brauche ich schließlich Verifikation und Validation. Gleichzeitig glaube ich, dass sich die Autonomiegrenze der KI verschieben wird. Irgendwann erzeugen wir so viel Code oder Engineering-Leistung agentisch, dass Menschen das nicht mehr vollständig auf herkömmliche Weise überprüfen können. Das ist meine persönliche Einschätzung, aber die Frage müssen wir uns stellen: Wie verhindern wir dann Schadcode oder gefährliche Maschinenzustände? Vielleicht müssen wir bei den Prüfverfahren auch über die angestammten Methoden hinausdenken. Dass sich zwei KIs gegenseitig auf die Finger schauen, wäre eine Idee. Ob das eine gute ist, wird die Zukunft zeigen. Ausreichend wäre es jedenfalls nicht. KI-generierter Code muss grundsätzlich wie fremder oder neu eingebrachter Code behandelt werden. Entscheidend ist dabei nicht, ob ein Mensch jede einzelne Zeile geschrieben oder gelesen hat, sondern ob Anforderungen und erwartetes Verhalten eindeutig spezifiziert und anschließend reproduzierbar verifiziert werden können. Dafür brauchen wir einen mehrstufigen Qualitätssicherungsprozess: Der generierte Code muss gegen Anforderungen, Architekturregeln, Coding Guidelines und Security-Vorgaben geprüft sowie statisch analysiert, kompiliert und systematisch getestet werden. Automatisierte Unit-, Integrations- und Regressionstests werden dadurch noch wichtiger. Gleichzeitig brauchen wir eine durchgängige Traceability, von der ursprünglichen Anforderung beziehungsweise dem Prompt über den KI-generierten Vorschlag bis zur getesteten und freigegebenen Version. Hinzu kommen Versionsverwaltung, definierte Qualitätsgrenzen und bei kritischen Änderungen ein Vier-Augen-Prinzip. Gerade bei Safety-, Security- oder geschäftskritischen Funktionen bleibt zudem eine unabhängige fachliche Prüfung unverzichtbar. Die KI kann Code erzeugen und auch Tests dafür vorschlagen, aber sie darf sich am Ende nicht selbst die Abnahme erteilen.
Warum sind offene Ökosysteme für diesen Wandel so entscheidend?
Weil wir Innovationsgeschwindigkeit brauchen. Wir können in Europa zehnmal die gleiche Technologie implementieren. Dann ist jeder stolz darauf, sie selbst programmiert zu haben. China Speed ist ein echtes Thema, das aus meiner Sicht noch unterschätzt wird. Wir müssen unsere wertvollen Entwicklungsressourcen dort einsetzen, wo wir uns wirklich differenzieren. Bei gemeinsamen Grundlagen und standardisierten Schnittstellen sollten wir zusammenarbeiten. Das eigene Applikations-Know-how kann und soll jeder behalten. Und am Ende geht es für mich um mehr als ein schnelleres Engineering: Die Maschine soll nicht mehr nur ein Automatisierungssystem sein, sondern ein Wissens- oder Intelligenzsystem. Das entsteht durch die Integration von KI über den gesamten Lebenszyklus.
