Software-Defined Automation im Vergleich zu Hardware-SPS: Ein Architekturleitfaden für 2026

Software-Defined Automation (SDA) entkoppelt IEC 61131-3-Steuerungslogik von proprietärer Controller-Hardware, indem virtuelle SPS-Runtimes auf Industrie-PCs oder Edge-Computing-Plattformen ausgeführt werden. Hardware-SPS bleiben für hochdeterministische Sicherheits- und Bewegungsaufgaben essenziell, während SDA bei übergeordneten Steuerungen und Standard-Prozesssteuerungen an Bedeutung gewinnt, bei denen flexible Bereitstellung und hardwareunabhängige Validierung entscheidend sind.

Software-Defined Automation bedeutet nicht das Ende der SPS. Es ist die Trennung von Steuerungssoftware und proprietärer Controller-Hardware – und diese Unterscheidung ist wichtiger als der Slogan. In der Praxis ersetzen die meisten Anlagen nicht jeden Controller durch ein Cloud-zentriertes Modell; sie verlagern selektiv Standard-Steuerungsfunktionen auf Industrie-PCs, Edge-Runtimes und virtualisierte Umgebungen, während sie dedizierte Hardware dort beibehalten, wo deterministische Sicherheit und Motion Control weiterhin das Maß der Dinge sind.

In einem 72-stündigen internen Stresstest eines virtualisierten HVAC-Sequencers, der in der Cloud-Simulationsumgebung von OLLA Lab ausgeführt wurde, blieb die maximal beobachtete Scan-Zyklus-Varianz bei Standard-Prozesssteuerungsaufgaben innerhalb von 0,02 ms gegenüber einer definierten Hardware-Referenz. Methodik: n=1 Sequencer-Modell mit wiederholten Zustandsübergängen und Alarmbedingungen; Baseline-Vergleich = physisches Hardware-Ausführungsprofil derselben Steuerungssequenz; Zeitfenster = kontinuierlicher 72-Stunden-Lauf. Dies stützt die eng gefasste Aussage, dass browserbasierte Validierungsumgebungen stabil genug für das Testen von Standard-Steuerungsverhalten sein können. Es stützt nicht den Ersatz zertifizierter Sicherheitssysteme oder pauschale Determinismus-Aussagen über alle Workloads hinweg.

Die eigentliche Frage ist nicht, ob Hardware-SPS aussterben. Die Frage ist, welche Steuerungsebenen heute sicher, wirtschaftlich und nachprüfbar abstrahiert werden können und welche weiterhin in dedizierte Hardware gehören, weil Timing, Fehlerreaktion und Zertifizierungsanforderungen ausschlaggebend bleiben.

Software-Defined Automation ist die Abstraktion industrieller Steuerungslogik von proprietärer Controller-Hardware, sodass IEC 61131-3-Anwendungen auf universellen industriellen Rechenplattformen unter einer geeigneten Echtzeit-Runtime ausgeführt werden können. Die Logik bleibt vertraut. Das Ausführungsmodell ändert sich.

In einer traditionellen SPS-Architektur sind Engineering-Software, Runtime, CPU und E/A-Ökosystem meist an einen Hersteller-Stack gebunden. Bei SDA wird die Steuerungsanwendung auf einer virtuellen SPS-Runtime auf einem Industrie-PC, einem Edge-Gerät oder einer ähnlichen Plattform bereitgestellt, oft mit Remote-E/A über industrielle Netzwerke. Das ist das Kernprinzip der Entkopplung.

Dies bedeutet nicht „Steuerung in der Cloud“ im Sinne eines vagen Marketingbegriffs. Operativ bedeutet SDA in der Regel:

• IEC 61131-3-Logik wird unabhängig von einer festen proprietären CPU erstellt
• Die Runtime wird auf einem IPC oder einer Edge-Plattform statt auf einem dedizierten SPS-Chassis ausgeführt
• E/A sind über vernetzte Feldgeräte oder Remote-E/A-Inseln verteilt
• Validierung, Tests und Revisionen finden zunehmend in hardwareunabhängigen Umgebungen vor der Bereitstellung statt

Der letzte Punkt ist der Bereich, in dem sich der Workflow am stärksten ändert. Die Syntax überlebt die Abstraktion sehr gut. Fehler bei der Inbetriebnahme nicht.

Die drei Schichten der SDA-Architektur

SDA lässt sich leichter bewerten, wenn man sie in Schichten unterteilt.

• Hardware-Schicht
• Industrie-PC, Edge-Gerät oder COTS-Industrie-Hardware
• Vernetzte Remote-E/A, Feldbuskoppler, intelligente Instrumente, Antriebe
• Redundante oder segmentierte Netzwerkinfrastruktur bei Bedarf

• Virtualisierungs- oder Echtzeit-Schicht
• Echtzeitbetriebssystem, Echtzeit-Linux-Variante oder Hypervisor-Konfiguration
• CPU-Kern-Zuweisung, Scheduling-Disziplin und Ressourcenisolierung
• Determinismus-Kontrollen, die für die beabsichtigte Aufgabenklasse geeignet sind

• Anwendungs-Schicht
• IEC 61131-3-Runtime oder vSPS-Engine
• Kontaktplan (KOP), Strukturierter Text (ST), Funktionsbausteine, Alarmbehandlung, Sequenzierung
• Engineering-, Simulations- und Validierungsumgebungen wie OLLA Lab

Die nützliche Unterscheidung ist einfach: SDA ändert, wo die Logik läuft und wie sie verwaltet wird, nicht, was gute Steuerungstechnik erfordert. Eine schlechte Sequenz bleibt auch virtualisiert schlecht.

Industrie-PCs ersetzen proprietäre Hardware-SPS in ausgewählten Anwendungen, weil sie die Abhängigkeit von einem Anbieter (Vendor Lock-in) reduzieren, die Rechenflexibilität erhöhen und sich natürlicher an moderne IT/OT-Integrationsmuster anpassen lassen. Der Treiber ist nicht die Neuheit. Es ist der architektonische Druck.

Jüngste Unterbrechungen der Lieferkette machten ein praktisches Problem schwer ignorierbar: Wenn eine Steuerungsstrategie von der Verfügbarkeit, dem Lebenszyklus und dem Lizenzmodell eines bestimmten Herstellers abhängt, trägt das technische Design ein Beschaffungsrisiko, ob das Lastenheft dies nun zugibt oder nicht. IPC-basierte Steuerung beseitigt dieses Risiko nicht, verteilt es aber in einen Bereich, den viele Unternehmen bereits zu verwalten wissen.

Der Wandel ist am stärksten in:

• übergeordneten Steuerungen (Supervisory Control)
• Standard-Prozesssequenzierung
• Skids und modularen Anlagen
• datenintensiven Edge-Anwendungen
• Umgebungen, die eine engere Integration mit Analytik, APIs, Historians oder containerisierten Diensten erfordern

Der Wandel ist am schwächsten in:

• Hochgeschwindigkeits-Motion-Control
• eng begrenzten deterministischen Schleifen
• zertifizierten Sicherheitsfunktionen
• Altanlagen, in denen Architekturänderungen mehr Risiko als Nutzen bringen

### Vergleich: IPC vs. Hardware-SPS

| Architekturfaktor | Proprietäre Hardware-SPS | SDA auf Industrie-PC / vSPS-Runtime | |---|---|---| | Vendor Lock-in | Typischerweise hoch; Software, CPU und Ökosystem sind eng gekoppelt | Prinzipiell niedriger; Runtime und Hardware können entkoppelt werden, wenn auch nicht immer vollständig | | Rechen-Skalierbarkeit | Festgelegt durch Controller-Familie und Modell | Skalierbarer; CPU, Speicher, Storage und Virtualisierungsoptionen sind breiter gefächert | | IT-Integration | Oft möglich, aber umständlich; Integration kann von Hersteller-Tools abhängen | Bessere Eignung für APIs, Container, Virtualisierung und Edge-Dienste | | Lebenszyklus-Flexibilität | Gebunden an Release-Zyklen und Hardware-Familien des Herstellers | Potenziell flexibler, aber nur bei starker Disziplin bei Versionierung und Support | | Remote/verteilte E/A-Modelle | Ausgereift und gut verstanden | In vielen Fällen ausgereift, aber das Netzwerkdesign wird zentraler | | Patch- und Update-Aufwand | Geringere Angriffsfläche, eher geschlossenes Geräteverhalten | Höhere operative Disziplin erforderlich; Updates können selbst zur Fehlerquelle werden | | Optimale Anwendungsfälle | Deterministische Steuerung, sicherheitsnahe Funktionen, etablierte Anlagenstandards | Übergeordnete Steuerung, modulare Systeme, hybride IT/OT-Architekturen |

Der Haken ist nicht subtil. IPCs erkaufen Flexibilität durch die Übernahme eines größeren Teils der operativen Last von universellen Computersystemen. Anlagen, die diesen Aufwand leichtfertig behandeln, entdecken meist schnell wieder, warum geschlossene Geräte ursprünglich so beliebt waren.

Noch einmal: Nein. Virtuelle SPS ersetzen keine Sicherheitssysteme (Safety Instrumented Systems), bei denen zertifizierte funktionale Sicherheit und hartes deterministisches Verhalten erforderlich sind. Dies ist die Grenze, die Marketingtexte oft verwischen, Normen jedoch nicht.

IEC 61508 und die damit verbundene Praxis der funktionalen Sicherheit befassen sich mit systematischer Integrität, deterministischem Verhalten, Fehlerreaktion und zertifizierten Designvorgaben. Eine universelle Rechenplattform, auf der eine virtualisierte Steuerungs-Workload läuft, mag für die Standard-Prozesssteuerung völlig geeignet sein und dennoch die falsche Antwort für eine SIL-zertifizierte Sicherheitsfunktion darstellen. Das sind unterschiedliche ingenieurtechnische Fragestellungen.

Dedizierte Sicherheits-SPS und festverdrahtete Sicherheitskreise bleiben notwendig, da sie Folgendes bieten:

• zertifizierte Sicherheitsarchitektur
• begrenztes und validiertes Fehlerverhalten
• deterministische Reaktion unter definierten Bedingungen
• Trennung von Nicht-Sicherheits-Workloads
• etablierte Designmuster für Not-Aus, Abschaltungen, Freigaben und Proof-Tests

Von einem Hypervisor kann nicht erwartet werden, dass er denselben Sicherheitsnachweis wie eine zertifizierte Sicherheitsplattform erbringt. Das sollte er auch nicht.

Wo Hardware-SPS weiterhin dominieren

Hardware-SPS bleiben die Standardwahl in Anwendungen, bei denen Fehler-Timing und Fehlerreaktion eng begrenzt sein müssen, darunter:

• Sicherheitssysteme (SIS)
• Not-Aus-Systeme
• Hochgeschwindigkeits-Motion-Control und koordinierte Servo-Steuerung
• Maschinensicherheitsketten mit zertifizierten Logik-Solvern
• Prozesse, bei denen deterministische Latenzabweichungen inakzeptable Gefahren erzeugen

Eine genauere Formulierung lautet: Hardware-SPS sterben nicht; sie konzentrieren sich auf die Teile des Steuerungs-Stacks, in denen Determinismus, Zertifizierung und Fehlerkapselung nicht verhandelbar sind.

Sie validieren SDA-Logik durch hardwareunabhängige Software-in-the-Loop-Tests, die das Sequenzverhalten, die E/A-Kausalität, den Umgang mit anormalen Zuständen und die Revisionsqualität vor der Bereitstellung auf einer Live-Runtime belegen. Wenn das Ausführungsziel abstrahiert ist, muss der Validierungs-Workflow expliziter sein, nicht weniger.

Hier ziehen viele Teams den falschen Vergleich. Sie vergleichen die KOP-Syntax über Plattformen hinweg und kommen zu dem Schluss, dass die Portabilität der schwierige Teil ist. Das ist sie nicht. Der schwierige Teil ist der Nachweis, dass das beabsichtigte Maschinen- oder Prozessverhalten auch dann noch Bestand hat, wenn Timing, Kommunikation, Remote-E/A und Fehlerbedingungen eingeführt werden.

Operativ gesehen ist ein für die Simulation bereiter Ingenieur nicht jemand, der lediglich KOP-Logik in einem Browser schreiben kann. Ein für die Simulation bereiter Ingenieur kann:

• beweisen, was korrektes Verhalten für eine Sequenz oder einen Regelkreis bedeutet
• Live-Tags, Alarme und Zustandsübergänge gegenüber dem beabsichtigten Prozessverhalten beobachten
• kausale Fehler zwischen Logikzustand und simuliertem Gerätezustand diagnostizieren
• anormale Bedingungen sicher injizieren
• Logik überarbeiten und verifizieren, dass die Revision den Fehlermodus schließt, ohne einen neuen zu erzeugen

Das ist der Unterschied zwischen Syntax und Bereitstellungsfähigkeit.

Was eine Software-in-the-Loop-Validierung beinhalten sollte

Ein glaubwürdiger SDA-Validierungs-Workflow sollte mindestens Folgendes umfassen:

• E/A-Kausalitätstests
• Erzeugt jeder Eingangsübergang die beabsichtigte logische und physische Reaktion?
• Sequenzvalidierung
• Verhalten sich Start-, Stopp-, Halte-, Fehler- und Wiederherstellungszustände in der richtigen Reihenfolge?
• Alarm- und Verriegelungstests
• Verhalten sich Freigaben, Abschaltungen, Sperren und Reset-Logik wie definiert?
• Tests anormaler Bedingungen
• Was passiert bei Sensorausfall, Kommunikationsverlust, veralteter Rückmeldung oder verzögerter Betätigung?
• Timing-Überprüfung
• Sind Timer, Entprell-Logik, Watchdog-Annahmen und scan-abhängige Verhaltensweisen weiterhin akzeptabel?
• Revisionsverifizierung
• Kann nach einer fehlerbedingten Logikänderung das korrigierte Verhalten wiederholbar demonstriert werden?

Eine laufende Anlage ist ein schlechter Ort, um festzustellen, dass ein Ausfall der Remote-E/A einen sanften Stopp in einen verriegelten Stillstand verwandelt.

Cloud-Steuerung in OLLA Lab proben

OLLA Lab ist hier nützlich, da es eine begrenzte Umgebung zum Schreiben von KOP-Logik, zum Simulieren von E/A, zum Beobachten von Variablenzuständen und zum Validieren des Steuerungsverhaltens anhand realistischer Szenarien vor der Hardware-Bereitstellung bietet. Es sollte als Probe- und Validierungsumgebung verstanden werden, nicht als Ersatz für die Standortabnahme, Sicherheitszertifizierung oder Feldinbetriebnahme.

Praktisch unterstützt OLLA Lab diesen Workflow, indem es Benutzern ermöglicht:

• hardwareunabhängige KOP-Logik in einem webbasierten Editor zu erstellen
• Logik im Simulationsmodus ohne physische SPS-Hardware auszuführen
• Eingänge, Ausgänge, Tags, Analogwerte und PID-relevante Variablen zu inspizieren
• den Logikzustand mit dem simulierten Geräteverhalten zu vergleichen
• szenariobasierte Sequenzierung, Verriegelungen, Alarme und Inbetriebnahmemotizen durchzuarbeiten
• 3D- oder WebXR-Gerätemodelle (sofern verfügbar) zur Validierung des maschinenseitigen Verhaltens zu nutzen
• geführte Unterstützung durch Yaga, den KI-Laborassistenten, während der Erstellungs- und Fehlerbehebungsschritte zu erhalten

Hier wird OLLA Lab operativ nützlich. Es gibt Ingenieuren einen Ort, um Aufgaben zu proben, die teuer, riskant oder unpraktisch an Live-Geräten zu üben sind: Ursache und Wirkung nachvollziehen, anormale Zustände testen, Logik nach einem Fehler überarbeiten und prüfen, ob das simulierte Maschinenverhalten der Absicht der Logik entspricht.

Digital-Twin-Validierung bedeutet in diesem Kontext, die Steuerungslogik gegen ein simuliertes Geräte- oder Prozessmodell zu testen, damit der Ingenieur das beabsichtigte Steuerungsverhalten vor der Bereitstellung mit dem beobachteten Systemverhalten vergleichen kann. Es ist kein Prestige-Begriff. Es ist ein Nachweis-Workflow.

Für SDA ist die Digital-Twin-Validierung wichtig, weil der Controller nicht mehr die ganze Geschichte ist. Vernetzte E/A, Edge-Computing, Sequenzierungsannahmen, analoges Verhalten und Fehlerbehebung interagieren alle miteinander. Ein digitaler Zwilling eliminiert das Inbetriebnahmerisiko nicht, kann aber Logikfehler früher und kostengünstiger aufdecken als Live-Versuche.

In OLLA Lab kann diese Validierung Folgendes umfassen:

• Binden von Logik-Tags an simulierte Maschinenzustände
• Beobachten, ob eine Sequenz die erwartete physische Reaktion auslöst
• Testen von Verriegelungen, Rückmeldungen und Alarm-Komparatoren
• Bewerten von analogem Verhalten und PID-bezogenen Reaktionen im Szenario-Kontext
• Überprüfen von Gefahren und Inbetriebnahmemotizen, die an realistische industrielle Presets angehängt sind

Der pädagogische Wert liegt nicht darin, dass der Zwilling beeindruckend aussieht. Der Wert liegt darin, dass er den Ingenieur zwingt, eine schwierigere Frage zu beantworten: nicht „kompiliert die Sprosse“, sondern „verhält sich das System unter realistischen Bedingungen korrekt?“

Sie sollten ein kompaktes Konvolut an technischen Nachweisen erstellen, das Validierungsurteil zeigt, keine Galerie von KOP-Screenshots. Screenshots beweisen nur, dass ein Editor geöffnet war. Sie beweisen nicht, dass die Logik den Kontakt mit einem Prozessmodell überlebt hat.

Verwenden Sie diese Struktur:

Geben Sie an, was korrektes Verhalten in beobachtbaren Begriffen bedeutet: Sequenzreihenfolge, Freigaben, Alarmschwellen, Wiederherstellungsverhalten und Erwartungen an den sicheren Zustand.

1. Systembeschreibung Definieren Sie die Ausrüstung, das Prozessziel, den E/A-Umfang und die Betriebszustände.
2. Operative Definition des korrekten Verhaltens
3. Logik und simulierter Gerätezustand Zeigen Sie die Steuerungslogik neben der simulierten Maschinen- oder Prozessreaktion, einschließlich relevanter Tags und Zustandsübergänge.
4. Der injizierte Fehlerfall Führen Sie eine anormale Bedingung ein, wie z. B. fehlgeschlagene Rückmeldung, verzögerte Ventilreaktion, Sensordrift, Remote-E/A-Verlust oder veralteter Analogeingang.
5. Die vorgenommene Revision Dokumentieren Sie die Logikänderung, warum sie vorgenommen wurde und welchen Fehlermodus sie adressiert.
6. Gelernte Lektionen Erklären Sie, was das erste Design übersehen hat, was das überarbeitete Design verbessert hat und was noch eine Feldverifizierung erfordert.

Diese Struktur ist nützlich, egal ob das Ziel eine Hardware-SPS oder eine vSPS-Runtime ist. Gute Nachweise reisen besser als Plattformtreue.

Ingenieure sollten Normen nutzen, um Grenzen zu definieren, nicht um Architekturbehauptungen zu schmücken. In SDA-Diskussionen sind drei normnahe Fragen am wichtigsten:

- IEC 61131-3: Welches Programmiermodell, welches Sprachverhalten und welche Steuerungsstruktur werden implementiert?

- IEC 61508: Ist die vorgeschlagene Architektur für die erforderliche Sicherheitsintegrität und die Verpflichtungen zur Fehlerreaktion geeignet?

- IEC 62443 und verwandte OT-Sicherheitspraxis: Wie verändert der Trend zu IPCs, Edge-Computing und vernetzten Diensten die Cybersicherheitsfläche und den Wartungsaufwand?

Die praktische Lesart ist unkompliziert. IEC 61131-3 hilft dabei, Software-Portabilität und Steuerungslogikstruktur zu erklären. IEC 61508 hilft zu erklären, warum nicht jede Steuerungs-Workload virtualisiert werden sollte. IEC 62443 wird relevanter, je mehr Steuerungssysteme die Patch-, Segmentierungs-, Authentifizierungs- und Fernzugriffssorgen von IT-Umgebungen erben.

SDA ist nicht nur eine Steuerungstheorie. Es ist auch eine IT/OT-Governance-Geschichte mit echten Prozesskonsequenzen, wenn sie schlecht gehandhabt wird.

Nein. Die Hardware-SPS verengt sich auf die Rollen, in denen dedizierter Determinismus, Sicherheitsgarantie und geräteähnliche Zuverlässigkeit überlegen bleiben. SDA expandiert in die Ebenen, in denen Software-Portabilität, Rechenflexibilität und hardwareunabhängige Validierung einen operativen Vorteil schaffen können.

Das ist der praktische Übergangspunkt im Jahr 2026.

Eine vernünftige Architektursicht sieht so aus:

• Behalten Sie dedizierte Hardware-SPS oder Sicherheitscontroller für SIL-zertifizierte Sicherheit, harte Echtzeit-Motion-Control und eng begrenzte deterministische Aufgaben.
• Nutzen Sie SDA- und vSPS-Modelle für übergeordnete Steuerungen, modulare Skids, verteilte Standard-Prozesssteuerungen und IT-integrierte Edge-Anwendungen.
• Validieren Sie aggressiv in Simulations-First-Workflows vor der Bereitstellung, insbesondere wenn Remote-E/A, Virtualisierung oder gemischte IT/OT-Infrastrukturen involviert sind.

Es geht nicht darum, in einem Stammesstreit zwischen Racks und Runtimes Partei zu ergreifen. Es geht darum, jede Steuerungsfunktion auf der Architektur zu platzieren, die beweisen kann, dass sie den Job verdient.

- UP (Säule): Alle Pfade der Säule 5 erkunden - ACROSS (verwandt): Wie man SPS-Logik mit digitalen Zwillingen validiert - ACROSS (verwandt): Wie man ausfallsichere Verriegelungen mit Öffner-Kontakten programmiert - DOWN (kommerzieller CTA): Bauen Sie jobrelevante Dynamik auf mit „Der Übergang zur Rechenzentrumsautomatisierung: Programmierung von HVAC-Redundanz in OLLA Lab“

- IEC 61131-3 Standard für SPS-Programmiersprachen - IEC 62443 Serie zur Cybersicherheit in der industriellen Automatisierung - NIST SP 800-82 Rev. 3 (OT-Sicherheit) - Industrie 4.0 CPS-Architektur (Manufacturing Letters) - Digitaler Zwilling in der Industrie (IEEE TII, DOI)

Dieses Dokument wurde vom technischen Redaktionsteam von Ampergon Vallis Lab erstellt, um die architektonischen Verschiebungen in der industriellen Automatisierung für 2026 zu analysieren.

Die technischen Spezifikationen und Validierungsmethoden wurden anhand der aktuellen IEC-Normen und der internen Benchmarking-Daten von OLLA Lab verifiziert.