Offene Ökosysteme, Cyber Resilience und KI: Automatisierung wird zur Gemeinschaftsaufgabe

Rund 80 Teilnehmer kamen am 29. und 30. September zum PLCnext Community Summit 2026 bei Yaskawa in Hattersheim zusammen. Rund 20 Community-Partner präsentierten ihre Lösungen und Anwendungen. Zwei Tage lang ging es um offene Automatisierung, Software, Engineering, Cybersecurity und Künstliche Intelligenz – aber mindestens ebenso sehr um die Frage, wie Zusammenarbeit in der Automatisierung künftig funktionieren muss.

Dass die Themen gut gewählt waren, zeigte nicht zuletzt das Executive Roundtable mit Tobias Unger, General Manager European Technology Center bei Yaskawa Europe, Helmut Deichert, Head of Product Line Controls bei Festo, und Dr. Tobias Frank, Vice President Automation Systems bei Phoenix Contact. Im Mittelpunkt standen Open Ecosystems und Interoperabilität, die Auswirkungen des Cyber Resilience Act (CRA) sowie die Frage, welche Rolle KI künftig im Engineering und im laufenden Betrieb von Maschinen spielen kann. Genau diese drei Themen waren auch im Vorfeld als Schwerpunkte des diesjährigen Summits angekündigt worden.

Dabei wurde schnell deutlich: So unterschiedlich die Themen auf den ersten Blick erscheinen mögen, sie hängen eng miteinander zusammen. Offene Plattformen schaffen die Grundlage für den Austausch von Daten und Software. Die zunehmende Vernetzung stellt gleichzeitig neue Anforderungen an Cybersecurity und Lifecycle-Management. Und KI wiederum benötigt genau diese Daten, Schnittstellen und Kontextinformationen, um in industriellen Anwendungen echten Mehrwert zu schaffen.

Ökosystem statt Insellösung

Die Ausgangsthese des Roundtables war eindeutig: Offene Ökosysteme entwickeln sich zunehmend zu einem strategischen Faktor für die industrielle Automatisierung. Denn Maschinen- und Anlagenbauer müssen neue Funktionalitäten immer schneller integrieren können, ohne gleichzeitig Entwicklungs- und Integrationskosten immer weiter in die Höhe zu treiben.

Das funktioniert nur, wenn Steuerungen, Antriebe, Software und Services nicht als voneinander isolierte Welten betrachtet werden. Standardisierte Schnittstellen und offene Architekturen sollen dafür sorgen, dass Unternehmen ihre eigenen Kernkompetenzen einbringen können, ohne Basistechnologien immer wieder neu entwickeln zu müssen.

Genau hier setzt die Zusammenarbeit von Phoenix Contact, Festo und Yaskawa an. PLCnext Technology dient längst nicht mehr ausschließlich Phoenix Contact als technologische Basis. Festo nutzt die Technologie für seine offene Automatisierungsplattform AX Controls. Sie soll klassische Steuerungstechnik mit modernen Softwaretechnologien verbinden und unter anderem SPS-Programmierung nach IEC 61131-3 sowie moderne Programmiersprachen wie Python unterstützen. Yaskawa wiederum bringt seine Kompetenzen aus Motion Control, Robotik und Antriebstechnik in das Ökosystem ein. Die PLCnext Community beschreibt die gemeinsame technologische Basis ausdrücklich als Möglichkeit, Hardware, Software und das Domänenwissen unterschiedlicher Partner zusammenzuführen.

Für Yaskawa war der Schritt hin zu einer gemeinsamen Plattform auch eine Konsequenz aus der eigenen Historie. Durch unterschiedliche Entwicklungen und Akquisitionen waren über die Jahre mehrere Steuerungswelten im Unternehmen entstanden. Diese dauerhaft parallel weiterzuentwickeln, war keine attraktive Perspektive. „Wir wollten eine gemeinsame, zukunftsfähige Plattform. Entscheidend war für uns dabei nicht nur die Technologie selbst, sondern auch das Umfeld und der Community-Gedanke“, erläuterte Tobias Unger beim Roundtable sinngemäß die damalige Entscheidung.

T. Unger beschreibt den grundlegenden Wandel in der Automatisierung so: „Unternehmen können mit der Vielfalt der Technologien in immer kürzerer Zeit kaum noch alleine mithalten.“ Daraus entstehe ein Paradigmenwechsel von Konkurrenten hin zu Kooperationspartnern.

Offen – aber nicht ohne eigenes Know-how

Interessant war beim Roundtable die Diskussion darüber, was „offen“ in diesem Zusammenhang eigentlich bedeutet. Denn eine gemeinsame Plattform heißt keineswegs, dass Festo, Yaskawa und Phoenix Contact ihr gesamtes Know-how miteinander teilen. Die Unternehmen verfolgen mit ihren jeweiligen Produkten eigene Marktstrategien. Gemeinsam entwickelt beziehungsweise genutzt werden vor allem diejenigen Basistechnologien, bei denen eine mehrfache Implementierung kaum Differenzierung schafft. Das spezifische Applikationswissen, Motion-Know-how oder anderes Intellectual Property verbleibt beim jeweiligen Unternehmen.

Auch die Sorge vor einem neuen Vendor-Lock-in kam zur Sprache. T. Unger sieht die Partnerschaft gerade nicht als Austausch der einen Abhängigkeit gegen eine andere. „Wir profitieren von schnelleren Entwicklungszyklen und gemeinsamen Basistechnologien, statt alles mehrfach selbst entwickeln zu müssen“, fasst er den Ansatz sinngemäß zusammen. Dass dabei dennoch eigenes Know-how geschützt werden kann, hat Unger auch an anderer Stelle hervorgehoben: Die Integration bestehender Systeme biete Vorteile hinsichtlich Investitionssicherheit und Kosten; gleichzeitig blieben maßgeschneiderte Lösungen möglich, mit denen Yaskawa das eigene Know-how sichern und Kunden Wettbewerbsvorteile verschaffen könne.

Ein größerer Markt für Automatisierungssoftware

Für Helmut Deichert liegt ein entscheidender Vorteil eines solchen Ökosystems darin, dass nicht nur drei große Automatisierungsanbieter auf einer gemeinsamen technologischen Grundlage arbeiten. Entscheidend ist vielmehr der Markt, der sich darum herum entwickeln kann. „Das Ökosystem wird dadurch größer. Gerade für Softwareanbieter entsteht ein Markt, auf dem sie ihre Lösungen für deutlich mehr Anwender bereitstellen können“, brachte H. Deichert den Gedanken beim Summit sinngemäß auf den Punkt.

Hier kommt dem PLCnext Store eine wichtige Rolle zu. Kommunikations-, Visualisierungs-, VPN-, Condition-Monitoring- oder andere Softwarefunktionen können als Apps bereitgestellt werden. Der Maschinenbauer muss eine solche Funktion dann nicht zwangsläufig selbst entwickeln, sondern kann auf vorhandene Lösungen des Ökosystems zurückgreifen. Entwickler und Technologiepartner können Apps, Libraries und komplette Lösungen zur Verfügung stellen, die sich in Automatisierungsprojekte integrieren lassen.

Die Vorstellung dahinter ähnelt in Teilen der App-Welt aus der IT – allerdings unter industriellen Randbedingungen. Ein Anwender könnte sich beispielsweise für eine bestimmte Visualisierung entscheiden, später eine VPN-Funktion für den Fernzugriff ergänzen und schließlich noch eine Anwendung für Condition Monitoring oder Predictive Maintenance hinzufügen. Voraussetzung dafür sind einheitliche Informationsmodelle und Schnittstellen. Denn der eigentliche Vorteil entsteht erst dann, wenn aus jeder zusätzlichen Softwarefunktion nicht wieder ein eigenes Integrationsprojekt wird.

H. Deichert beschreibt diesen Gedanken in einer bereits veröffentlichten Aussage treffend: „Mit einer offenen Architektur kann man beides haben: Software von verschiedenen Anbietern und gleichzeitig nahtlose Konnektivität.“ Dadurch eröffne sich für Kunden ein wesentlich breiteres Lösungsspektrum. Der Effekt könnte weit über eine komfortablere Softwareinstallation hinausgehen. Ein größerer gemeinsamer Markt macht die Entwicklung spezialisierter Software für Drittanbieter wirtschaftlich interessanter. Gleichzeitig steigt die Wahrscheinlichkeit, dass für eine konkrete Aufgabenstellung bereits eine Lösung vorhanden ist.

Offenheit bedeutet damit nicht, dass die Produkte der beteiligten Hersteller austauschbar oder identisch werden. Vielmehr soll eine gemeinsame technologische Basis den Raum vergrößern, in dem unterschiedliche Lösungen miteinander kombiniert werden können.

Cyber Resilience: Compliance allein reicht nicht

Beim zweiten großen Themenblock wurde es regulatorischer. Dr. Tobias Frank brachte die Diskussion mit einer zugespitzten These auf den Punkt: Der Cyber Resilience Act kann die Industrie compliant machen – aber nicht automatisch cyberresilient. Dahinter steckt eine wichtige Unterscheidung. Gesetzliche Anforderungen können Mindeststandards für Produkte definieren. Ob daraus eine tatsächlich widerstandsfähige Produktionsanlage entsteht, hängt jedoch vom Gesamtsystem ab – und damit von Komponentenherstellern, Maschinenbauern, Integratoren und Betreibern gleichermaßen.

Drei Aspekte standen in der Diskussion besonders im Vordergrund.

Erstens muss der Betreiber wissen, was er eigentlich schützen will und welche Folgen ein erfolgreicher Angriff hätte. Geht es in erster Linie um die Verfügbarkeit einer Maschine? Müssen Manipulationen von Produktionsdaten verhindert werden? Welche Systeme sind besonders kritisch? Und welche Angriffsszenarien sind für die konkrete Anwendung überhaupt relevant?

Zweitens endet Cybersecurity nicht mit der Inbetriebnahme einer Maschine. Genau darin unterscheidet sich die Cyber-Resilience-Betrachtung von vielen klassischen Safety-Konzepten. „Cyber Resilience ist keine einmalige Aufgabe“, betont H. Deichert. „Anders als bei Safety verändert sich die Bedrohungslage ständig. Der Schutz muss deshalb über den gesamten Lebenszyklus einer Maschine gewährleistet und an neue Bedrohungen angepasst werden.“

Und drittens müssen Security-Maßnahmen im industriellen Alltag praktikabel bleiben. Schutzmechanismen, die Mitarbeiter massiv bei ihrer täglichen Arbeit behindern, bergen die Gefahr, dass Umgehungslösungen entstehen – und damit möglicherweise neue Schwachstellen. Gerade der Lifecycle-Aspekt stellt die Automatisierungsbranche vor enorme Herausforderungen. Maschinen und Anlagen bleiben häufig zehn, 15 oder noch mehr Jahre im Einsatz. Cyberbedrohungen und bekannte Schwachstellen können sich dagegen innerhalb von Monaten oder sogar Tagen verändern.

Wer patcht eine Fabrik?

Besonders plastisch wurde die Problematik beim Thema Updates. Ein Softwarepatch auf einem Büro-PC ist eine Sache. Ein Firmware-Update an einer Steuerung, von der eine komplette Produktionslinie abhängt, eine andere. Hersteller müssen Sicherheitslücken schließen und Updates bereitstellen. Gleichzeitig darf ein Update nicht dazu führen, dass eine Anlage anschließend ungeplant stillsteht oder sich ihr validiertes Verhalten verändert.

Hinzu kommt die schiere Menge an Komponenten. Eine größere Maschine oder Anlage kann Produkte verschiedener Hersteller und zahlreiche Geräte mit jeweils unterschiedlichen Firmwareständen enthalten. „Bei einer Anlage mit Geräten verschiedener Hersteller kann man nicht jedes einzelne Gerät händisch daraufhin überprüfen, ob eine neue Firmware verfügbar ist“, machte Dr. Tobias Frank beim Roundtable deutlich. Dafür brauche es Formate und Automatismen, die einen Überblick über den Cybersecurity-Status der gesamten Installation schaffen.

Asset-, Patch-, Versions- sowie Backup-and-Recovery-Management entwickeln sich damit zu integralen Bestandteilen moderner Automatisierungskonzepte. Im Idealfall lässt sich ein Update nicht nur zentral verwalten, sondern vor dem Einspielen auch testen oder simulieren. Dabei wird es keine einheitliche Antwort für alle Industrien geben. Eine kontinuierlich betriebene prozesstechnische Anlage stellt andere Anforderungen als eine Montagelinie, die während eines geplanten Wartungswochenendes heruntergefahren werden kann. Auch stark regulierte Industrien mit kontrollierten Softwareständen stehen vor anderen Herausforderungen als klassische Maschinenbauer.

Entscheidend wird deshalb sein, Schwachstelle, Risiko und konkreten Anwendungsfall zusammenzubringen. Nicht jede veröffentlichte Schwachstelle bedeutet für jede Maschine das gleiche Risiko. Der Hersteller muss informieren und geeignete Maßnahmen beziehungsweise Patches bereitstellen. Der Betreiber wiederum muss beurteilen können, welche Konsequenz eine Schwachstelle für seine konkrete Anlage hat. Cyber Resilience wird damit zwangsläufig zur Gemeinschaftsaufgabe entlang der Lieferkette.

Die Regulierung trifft auf lange Maschinenlebenszyklen

Erschwerend kommt hinzu, dass Hersteller und Maschinenbauer derzeit mit mehreren europäischen Regelwerken gleichzeitig umgehen müssen. Neben dem Cyber Resilience Act spielt unter anderem die neue Maschinenverordnung eine Rolle. Im Roundtable wurde deutlich, dass die Branche weniger die grundsätzliche Notwendigkeit höherer Cybersecurity-Standards infrage stellt als vielmehr deren praktische Umsetzung. Entwicklungszeiten für industrielle Komponenten sind lang, Maschinenlebenszyklen noch länger. Gleichzeitig müssen Normen, regulatorische Anforderungen, Zertifizierungen und Lieferketten zusammenpassen.

Für Maschinenbauer kommt eine weitere Besonderheit hinzu: Sie stehen zwischen Komponentenhersteller und Endkunde. Ein Security-Update für eine Steuerung oder einen Antrieb kann Auswirkungen auf die komplette Maschine haben. Damit wächst die Bedeutung eines durchgängigen Versions- und Änderungsmanagements. Genau deshalb dürften standardisierte und möglichst automatisierte Mechanismen für Asset-, Update- und Patch-Management künftig zu einem wichtigen Bestandteil industrieller Automatisierungsplattformen werden.

KI: Nicht das Modell allein entscheidet

Beim dritten Schwerpunkt des Roundtables, der Künstlichen Intelligenz, verschob sich die Diskussion von Plattformarchitektur und Regulierung hin zur nächsten Evolutionsstufe des Engineerings.

Bemerkenswert war dabei, dass Dr. T. Frank die Bedeutung einzelner Large Language Models relativierte. Für industrielle Anwendungen könnte langfristig weniger entscheidend sein, welches Modell verwendet wird, als vielmehr die Frage, welchen Kontext dieses Modell erhält. Genau hier liegen große Mengen bislang nur lose miteinander verbundener Informationen: Engineering-Projekte, Dokumentationen, aktuelle Steuerungsdaten, Zustandsinformationen aus der Maschine, Community-Wissen sowie unternehmenseigene Wissensdatenbanken.

Werden diese Informationen miteinander verbunden, könnte aus einem allgemeinen KI-Assistenten ein Assistent mit konkretem Maschinenwissen werden. Eine wichtige Rolle spielt dabei das Model Context Protocol, kurz MCP. Darüber lassen sich unterschiedliche Informationsquellen für KI-Anwendungen strukturiert verfügbar machen. Ein Engineering-Assistent könnte dann beispielsweise nicht nur ein SPS-Programm kennen, sondern zusätzlich Dokumentation, Engineering-Informationen, Maschinenzustand und aktuelle Prozessparameter in seine Analyse einbeziehen. Damit eröffnet sich eine Perspektive, die weit über reine Codegenerierung hinausgeht. KI könnte während des Engineerings unterstützen, im Betrieb bei der Analyse von Anomalien helfen und im Service Engineering-Wissen mit realen Zustandsdaten einer Maschine kombinieren.

Interessant ist dabei auch die Möglichkeit, unterschiedliche KI-Modelle für unterschiedliche Aufgaben einzusetzen. Nicht jede industrielle Anwendung benötigt ein großes High-End-Modell. Für klar umrissene Aufgaben könnten kleinere oder spezialisierte Modelle ausreichen – perspektivisch auch lokal beziehungsweise Edge-nah betrieben. Der entscheidende Wert entsteht dann weniger durch ein einzelnes KI-Modell als durch die Kombination aus Modell, qualitativ hochwertigen Daten, Engineering-Wissen und aktuellem Maschinenkontext.

„Copilot, nicht Autopilot“

Bei aller Dynamik der KI-Entwicklung zog Dr. T. Frank allerdings eine klare Grenze. „Wir sprechen vom Copiloten, nicht vom Autopiloten“, brachte er den aktuellen Ansatz auf eine kurze Formel. Wenn KI Code erzeugt oder Änderungen vorschlägt, die später das Verhalten einer Maschine beeinflussen, soll der Anwender zunächst weiterhin bewusst entscheiden, ob diese Änderung tatsächlich übernommen wird. Auch bei einem KI-Zugriff auf aktuelle Steuerungsinformationen sind klare Security-Grenzen notwendig.

Das dürfte allerdings nicht das letzte Wort sein. Dr. T. Frank geht davon aus, dass sich die Grenze zwischen Assistenz und Autonomie mit zunehmender Leistungsfähigkeit der Systeme verschieben wird. Softwareentwickler erleben bereits heute, wie KI wiederkehrende Programmieraufgaben übernimmt. Der Entwickler wird damit zunehmend zum Orchestrator und Supervisor, statt jede einzelne Zeile Code selbst zu schreiben.

Übertragen auf die industrielle Automatisierung entsteht daraus allerdings eine entscheidende Frage: Wie prüft man künftig Software, die zunehmend agentisch erzeugt wird?Wenn KI eines Tages große Teile einer Applikation erstellt, wird es kaum praktikabel sein, jeden erzeugten Code anschließend noch einmal vollständig manuell zu verifizieren. „Wir werden künftig so viel Code und Engineering-Leistung agentisch erzeugen, dass wir nicht mehr alles vollständig manuell überprüfen können“, skizziert Dr. T.  Frank sinngemäß die Entwicklung. Die Automatisierung der Entwicklung benötigt deshalb zwangsläufig auch eine Automatisierung der Prüfung.

Digitale Zwillinge werden zur Prüfinstanz

Damit erhalten Simulation und digitale Zwillinge eine zusätzliche Aufgabe. Sie dienen dann nicht mehr nur dazu, Maschinen früher virtuell in Betrieb zu nehmen oder Prozesse zu optimieren. Sie könnten zur automatisierten Prüfinstanz für KI-generierte Engineering-Ergebnisse werden.

Ein von einer KI erzeugtes Programm ließe sich zunächst gegen ein digitales Anlagenmodell testen. Kritische Zustände könnten gezielt simuliert und Grenzen vorgegeben werden, die eine KI nicht überschreiten darf. Interessanterweise führt die KI-Diskussion damit zurück zu einem sehr klassischen Prinzip der funktionalen Sicherheit: Bevor ein System autonom agieren darf, muss klar definiert sein, was auf keinen Fall passieren darf.

Bei Safety beginnt dies mit der Gefährdungsanalyse. Bei agentischer Automatisierung könnte künftig eine ähnliche Logik gelten. Der Anwender muss seine Schutzziele kennen, zulässige Zustände definieren und festlegen, in welchen Bereichen eine KI selbstständig handeln darf – und wo nicht.

KI macht sauberes Engineering damit keineswegs überflüssig. Im Gegenteil: Je autonomer Systeme werden, desto präziser müssen ihre Grenzen beschrieben und desto leistungsfähiger müssen die dazugehörigen Prüfmechanismen sein.

Die knappe Ressource heißt Engineering

In der Diskussion wurde noch ein weiterer Aspekt deutlich, der offene Ökosysteme und KI unmittelbar miteinander verbindet: Entwicklungsressourcen werden knapper.

Es ergibt wenig Sinn, grundlegende Technologien, Kommunikationsschnittstellen oder standardisierte Funktionen bei jedem Hersteller immer wieder neu zu implementieren. Ressourcen sollten dort eingesetzt werden, wo tatsächlich neues und differenzierendes Know-how entsteht. Das ist letztlich die ökonomische Idee hinter einem offenen Ökosystem. Unternehmen teilen nicht ihre Kronjuwelen. Sie versuchen vielmehr, den Aufwand für diejenigen Technologien zu reduzieren, mit denen sich im Wettbewerb ohnehin kaum Differenzierung erzielen lässt.

Der Community-Gedanke reicht deshalb weit über Phoenix Contact, Festo und Yaskawa hinaus. Entwickler, Softwareanbieter, Systemintegratoren, Technologiepartner und Hochschulen sollen Lösungen und Know-how in das Ökosystem einbringen. Nach Angaben der PLCnext Community umfasst das Netzwerk mittlerweile mehr als 300 Partner; mehr als 140 Hochschulen nutzen PLCnext Technology.

Das erklärt auch die Bedeutung des PLCnext Stores. Wiederverwendbare Softwarekomponenten können Entwicklungsaufwand reduzieren und gleichzeitig einen Markt für spezialisierte Anbieter schaffen. Die Plattform wird damit zum Bindeglied zwischen klassischer Automatisierung und einer stärker softwareorientierten Entwicklungswelt.

Offenheit bekommt eine neue Bedeutung

Am Ende des Roundtables liefen die drei zunächst sehr unterschiedlichen Themen erstaunlich eng zusammen: Offene Ökosysteme sollen verhindern, dass knappe Entwicklungsressourcen immer wieder in dieselben Basistechnologien fließen. Cyber Resilience verlangt nach standardisierten Informationen und einer Zusammenarbeit über den gesamten Lebenszyklus von Maschinen und Anlagen. Und Künstliche Intelligenz entfaltet ihren größten Nutzen dann, wenn sie auf Informationen aus unterschiedlichen Systemen, Engineering-Werkzeugen und Wissensquellen zugreifen kann.

PLCnext Technology liefert dafür ein interessantes Anschauungsbeispiel. Phoenix Contact, Festo und Yaskawa verfolgen weiterhin ihre jeweils eigenen Kernkompetenzen und Geschäftsmodelle. Gleichzeitig nutzen sie eine gemeinsame technologische Grundlage und versuchen, darum herum ein größeres Ökosystem aus Hardware, Software, Apps und Partnerlösungen entstehen zu lassen.

Genau deshalb war der PLCnext Community Summit in Hattersheim mehr als eine Produktschau. Rund 80 Teilnehmer, etwa 20 ausstellende Community-Partner und zahlreiche Gespräche zwischen Herstellern, Entwicklern, Softwareanbietern, Integratoren und Anwendern machten sichtbar, was hinter dem Begriff „Community“ in der industriellen Automatisierung stehen kann. Die vielleicht wichtigste Botschaft der beiden Tage lautet deshalb: Offenheit ist längst nicht mehr nur eine technische Eigenschaft einer Schnittstelle. Sie wird zu einer Frage der Arbeitsteilung.

Welche Grundlagen entwickeln Unternehmen gemeinsam? Wo beginnen die eigenen Kernkompetenzen? Wie lassen sich Security und Software über lange Maschinenlebenszyklen beherrschen? Und wie können KI und Automatisierung helfen, die vorhandenen Engineering-Ressourcen effizienter einzusetzen?

Die Antworten darauf werden maßgeblich bestimmen, wie schnell sich die industrielle Automatisierung in den kommenden Jahren weiterentwickelt. Der PLCnext Community Summit zeigte jedenfalls: Die Zeiten, in denen ein einzelner Hersteller sämtliche Technologien einer Automatisierungswelt allein entwickeln und beherrschen wollte, dürften zunehmend der Vergangenheit angehören.