Software Defined Automation lud am 29. September in die BMW Welt München ein (Quelle. Software Defined Automation)
Physical AI gehört derzeit zu den viel diskutierten Themen in der Industrie. Software Defined Automation stellt dabei eine grundlegende Frage in den Mittelpunkt: Worauf soll die künstliche Intelligenz eigentlich aufsetzen, wenn sie nicht nur Daten analysieren, sondern auf reale Produktionssysteme einwirken soll? Auf der Software Defined Factory 2026 in der BMW Welt München präsentierte das Unternehmen darauf seine Antwort: den „State Layer for Physical AI“.
Aus Sicht von SDA liegt eine zentrale Herausforderung in der heterogenen und historisch gewachsenen Automatisierungslandschaft. Nach Schätzung des Unternehmens sind weltweit mindestens 50 Mio. industrielle Steuerungen im Einsatz. Viele davon werden mit herstellerspezifischen Engineering-Werkzeugen verwaltet. Gleichzeitig fehlt häufig eine durchgängige Versionskontrolle für den auf den Steuerungen ausgeführten Code.
Soll- und Ist-Zustand zusammenführen
SDA setzt deshalb auf zwei Abstraktionsebenen. Zum einen sollen sich industrielle Steuerungen ähnlich wie Cloud-Instanzen ansprechen, sichern und bei Bedarf aus der Ferne auf einen früheren Stand zurücksetzen lassen. Zum anderen wird der Code aus den proprietären Formaten unterschiedlicher Hersteller extrahiert und in einem zentralen „System of Record“ normalisiert. Aktuell unterstützt SDA nach eigenen Angaben 13 Herstellerökosysteme, zehn davon befinden sich bereits im Produktivbetrieb.
Aus beiden Ebenen entsteht der von SDA als State Layer bezeichnete Ansatz. Er soll transparent machen, welcher Softwarestand auf einer Steuerung vorgesehen ist und welcher tatsächlich ausgeführt wird. Gerade für den Einsatz von KI in der Produktion ist diese Kenntnis entscheidend: Ein KI-Agent kann nur dann sinnvoll Änderungen vorschlagen, wenn ihm der aktuelle und der gewünschte Zustand der Anlage bekannt sind.
Wie das funktionieren kann, demonstrierte SDA in München an einer laufenden Maschine von SEW-Eurodrive. Ein KI-Agent verglich Soll- und Ist-Zustand, identifizierte eine Abweichung und schlug eine Änderung eines Parameters vor. Die Übertragung auf die Steuerung erfolgte jedoch nicht automatisch. Sie blieb eine explizite menschliche Aktion und wurde mit Nutzer und Zeitstempel protokolliert. „Human in the Loop“ ist damit nicht nur eine zusätzliche Sicherheitsmaßnahme, sondern Bestandteil der Architektur.
Abweichungen in der Praxis keine Seltenheit
Welche Bedeutung ein kontinuierlicher Soll-Ist-Vergleich haben kann, zeigten Anwenderbeispiele. Erik Stauvermann, Digital Transformation Manager bei Henkel, berichtete von einem kopierten Variablennamen, der eineinhalb Jahre unentdeckt blieb. Der Fehler habe je betroffener Maschine Kosten von rund 10.000 € sowie einen Aufwand von drei Wochen verursacht.
Auch die von SDA erfassten Daten zeigen, dass nicht dokumentierte Änderungen offenbar keine Ausnahme sind. Allein im August registrierte die Plattform in angeschlossenen Werken 4.164 Fälle, in denen auf einer Steuerung ein anderer Stand als die freigegebene Zielversion lief. Keine dieser Änderungen sei in einer Versionshistorie dokumentiert gewesen.
Sanmina berichtete wiederum über Auswirkungen auf die Verfügbarkeit. An einer Produktionslinie in Guadalajara sei die Ausfallzeit pro Vorfall von 40 min auf 5 min gesunken. Nach Angaben des Unternehmens wurde dabei ein zehnfacher Return on Investment erreicht. Gerade in regulierten Branchen kommt zusätzlich die lückenlose Nachvollziehbarkeit von Änderungen hinzu. Cytiva verwies beispielsweise auf die Notwendigkeit, jede Änderung innerhalb einer validierten Umgebung versioniert vorzuhalten.
Security wird zur Voraussetzung für KI
Mit zunehmender Softwareorientierung verändert sich nach Auffassung von SDA auch die Rolle der OT-Security. Sicherheit werde von einer nachgelagerten Compliance-Aufgabe zu einer Voraussetzung dafür, KI-Agenten überhaupt Eingriffe in Produktionssysteme zu ermöglichen. Denn nur wenn bekannt ist, welcher Code tatsächlich auf einer Steuerung läuft, lassen sich Abweichungen erkennen und Änderungen nachvollziehbar verantworten. Auch auf der Edge-Ebene stellt sich dabei die Frage, wer die Kontrolle über die installierte Software besitzt.
Fünf Erweiterungen für die SDA-Plattform
Neben dem State Layer kündigte SDA fünf Erweiterungen seiner Plattform an. Dazu gehört eine gemeinsam mit Autonomy Logic entwickelte OpenPLC-Integration. Sie soll es ermöglichen, OpenPLC-Steuerungen direkt im Browser zu programmieren, bereitzustellen und zu sichern. Zum Zeitpunkt der Veranstaltung befand sich die Integration in der Private Preview; die allgemeine Verfügbarkeit ist für Mitte Oktober vorgesehen.
Mit individuellen Images für IDE-as-a-Service können Engineering-Teams zudem komplette Entwicklungsumgebungen einschließlich IDE-Version, Bibliotheken und Lizenzen als persistente Cloud-Workstation nutzen. Ein neuer Octoplant-Import soll vorhandene Backup-Archive einschließlich ihrer Versionshistorie in SDA übernehmen.
Für abgeschottete Produktionsnetze bietet der Local Client eine Offline-Arbeitsmöglichkeit. Sobald wieder eine Verbindung verfügbar ist, werden die Daten synchronisiert. Mit Deployment Approvals führt SDA darüber hinaus ein Vier-Augen-Prinzip für Änderungen ein: Eine Änderung kann damit nicht allein auf Verantwortung eines einzelnen Anwenders auf eine Steuerung übertragen werden.
Offenheit statt neuer proprietärer Ebene
Für openautomation besonders interessant ist die Positionierung von SDA beim Thema Offenheit. CEO und Gründer Dr. Josef Waltl machte deutlich, dass der State Layer nicht zu einer neuen proprietären Schicht innerhalb der Automatisierungsarchitektur werden solle. Dafür seien stabile Schnittstellen, Zugänge für Software-Agenten sowie der Verzicht auf einen Daten-Lock-in notwendig.
Drittanbieter sollen ausdrücklich eigene Anwendungen auf Basis des State Layers entwickeln können. Passend dazu trat auf der Veranstaltung auch Thiago Alves, Gründer von Autonomy Logic und Initiator von OpenPLC, auf und warb für Open-Source-Software auf Steuerungsebene.
Damit adressiert SDA letztlich eine der entscheidenden Fragen auf dem Weg zur Software-definierten Fabrik: Wie lässt sich die historisch gewachsene, heterogene Automatisierungswelt so abstrahieren, dass Software und künftig auch KI herstellerübergreifend mit ihr arbeiten können, ohne die vorhandene installierte Basis ersetzen zu müssen? Der State Layer soll dafür die notwendige gemeinsame Zustands- und Verwaltungsebene schaffen. Als nächstes Ziel skizzierte Dr. J. Waltl eine Fabrik, die sich auf dieser Grundlage zumindest teilweise selbst optimieren kann.