Von der SPS-zentrierten Steuerung zur softwaredefinierten Automatisierung
Die industrielle Automatisierung entwickelt sich über das traditionelle Modell dedizierter SPS, Mikrocontroller und Maschinen mit festgelegten Funktionen hinaus. Moderne Systeme kombinieren zunehmend SPS-basierte Steuerungen mit leistungsfähigen MPUs und SoCs, um HMI, maschinelles Sehen, Edge-Analysen, Konnektivität, digitale Zwillinge und KI-Workloads zu verarbeiten.
Diese Entwicklung macht herkömmliche Steuerungsarchitekturen nicht überflüssig. Stattdessen entsteht eine mehrschichtige Architektur, in der SPS weiterhin die deterministische Steuerung auf Feldebene übernehmen können, während leistungsfähigere Computerplattformen übergeordnete, analytische und Visualisierungsfunktionen sowie KI-Funktionen ausführen.
Aus technischer Sicht geht es nicht einfach darum, zusätzliche Rechenkapazität bereitzustellen. Die eigentliche Herausforderung besteht darin sicherzustellen, dass diese zusätzlichen Workloads das Zeitverhalten, die Verfügbarkeit oder die Integrität etablierter Steuerungsfunktionen nicht beeinträchtigen können.
Physical AI führt zu einer neuen Herausforderung in der Automatisierung
Die Einführung von Physical AI stellt höhere Anforderungen an die Systemarchitektur, da von KI generierte Informationen physische Anlagen und betriebliche Entscheidungen beeinflussen können.
Ein KI-Modell kann einen anormalen Maschinenzustand erkennen, eine visuelle Anomalie feststellen, die vorausschauende Inspektion unterstützen oder einen bedienerbezogenen Zustand identifizieren. Ein KI-Inferenzergebnis ist jedoch nur ein Teil der vollständigen Automatisierungskette.
Das System muss weiterhin Sensordaten erfassen, das KI-Modell ausführen, den Betriebskontext validieren, vordefinierte Steuerungsrichtlinien anwenden und den daraus resultierenden Zustand an die entsprechende Anwendung oder den Bediener übermitteln.
Meiner Ansicht nach sollte industrielle KI daher als Workload zur Entscheidungsunterstützung oder für kontrollierte Reaktionen und nicht als isolierte Intelligenzebene betrachtet werden. Die umgebende Automatisierungsplattform bestimmt, ob KI-Informationen innerhalb der erforderlichen Zeit- und Sicherheitsgrenzen verarbeitet und entsprechende Aktionen ausgelöst werden können.
Gemischte Kritikalitätsstufen bei Workloads erfordern echte Isolation
Moderne Multicore-Prozessoren ermöglichen die Konsolidierung von Funktionen, für die zuvor separate Hardwareplattformen erforderlich waren. Ein einziges Computersystem kann heute echtzeitkritische Steuerungen, HMI-Dienste, Netzwerke, Diagnose, Ereignisprotokollierung, maschinelles Sehen, Analysen und KI-Inferenz beherbergen.
Diese Workloads haben nicht identische Anforderungen.
Eine echtzeitkritische Steuerungsaufgabe kann eine strikt einzuhaltende Ausführungsfrist haben. Ein HMI kann unterschiedliche Zeitverhalten tolerieren, während ein KI-Inferenzprozess erhebliche CPU-Ressourcen benötigen kann. Netzwerkdienste führen außerdem externe Kommunikationspfade ein, die keinen uneingeschränkten Zugriff auf kritische Ressourcen haben sollten.
Folglich entsteht allein dadurch, dass mehrere Anwendungen auf einem Mehrkernprozessor platziert werden, nicht automatisch eine robuste Architektur.
Die Betriebsumgebung muss Mechanismen für zeitliche Trennung, Speicherschutz, Ressourcensteuerung und Fehlerisolierung bereitstellen.
Hardwarekonsolidierung ist nicht gleichbedeutend mit Resilienz
Die Konsolidierung von Hardware kann die Anzahl der Rechenplattformen reduzieren, die Verkabelung vereinfachen und die Integration verbessern. Sie schafft jedoch auch einen potenziellen gemeinsamen Ausfallpunkt.
Wenn unabhängige Workloads denselben Prozessor und dieselbe Betriebsumgebung nutzen, könnten ein fehlerhafter Treiber, eine außer Kontrolle geratene Anwendung, ein Speicherfehler oder ein kompromittierter Dienst andere Funktionen beeinträchtigen, sofern die Softwarearchitektur keine geeigneten Grenzen festlegt.
Dies ist eine der wichtigsten Überlegungen bei der Modernisierung veralteter Automatisierungssysteme.
Das Ziel sollte nicht einfach darin bestehen, mehr Funktionen auf weniger Prozessoren zu verlagern. Ziel sollte es sein, Workloads zu konsolidieren, ohne unzumutbare Abhängigkeiten zwischen ihnen zu schaffen.
Das Betriebssystem wird zu einer Durchsetzungsebene
In einer softwaredefinierten Automatisierungsarchitektur ist das Betriebssystem nicht mehr nur eine Plattform, auf der Anwendungen ausgeführt werden.
Sie bestimmt, wie Prozesse eingeplant werden, wie der Speicher geschützt wird, wie auf Hardwareressourcen zugegriffen wird und wie einzelne Dienste miteinander interagieren. Diese Mechanismen beeinflussen unmittelbar die Fähigkeit des Systems, den Betrieb aufrechtzuerhalten, wenn eine einzelne Komponente ausfällt.
Eine robuste Architektur sollte daher in der Lage sein, einen ausgefallenen Dienst zu isolieren und ihn, sofern es das Systemdesign zulässt, wiederherzustellen, ohne unabhängige Anwendungen neu zu starten.
Dieser Ansatz ist besonders für Industriesysteme relevant, bei denen ein vollständiger Systemneustart Steuerungs-, Visualisierungs-, Kommunikations- oder Produktionsabläufe unterbrechen kann.
Warum die Mikrokernel-Architektur wichtig ist
Ein herkömmliches monolithisches Betriebssystem platziert typischerweise viele Dienste, Treiber, Dateisysteme und Netzwerkkomponenten in einer Umgebung mit weitreichenden Kernelberechtigungen.
Ein Mikrokernel verfolgt einen anderen Architekturansatz. Er hält eine kleinere Anzahl grundlegender Funktionen im Kernel, während viele Treiber, Protokollstapel, Dateisysteme und Systemdienste als separate Prozesse in geschützten Adressräumen ausgeführt werden können.
Für die industrielle Automatisierung kann diese Architektur mehrere nützliche Eigenschaften bieten:
- Fehlerisolierung: Ein fehlerhafter Treiber oder Dienst kann von unabhängigen Prozessen isoliert werden.
- Kontrollierte Wiederherstellung: Einzelne Dienste können neu gestartet werden, ohne dass zwangsläufig das gesamte System neu gestartet werden muss.
- Weniger privilegierter Code: Weniger Komponenten müssen mit den höchsten Systemberechtigungen ausgeführt werden.
- Speicherisolierung: Geschützte Adressräume helfen zu verhindern, dass eine Anwendung direkt in eine andere eingreift.
- Unterstützung gemischter Kritikalitäten: Echtzeit-Steuerungsaufgaben können neben HMI-, Netzwerk-, Analyse- und KI-Workloads ausgeführt werden.
- Wartung über den Lebenszyklus: Modulare Dienste können die Wartung und Aktualisierungen auf Komponentenebene vereinfachen.
Ein Mikrokernel beseitigt weder Softwarefehler noch Cybersicherheitslücken. Sein Wert liegt darin, architektonische Grenzen zu schaffen, die die Folgen einzelner Ausfälle oder Kompromittierungen begrenzen können.
Determinismus in Echtzeit bleibt eine grundlegende Anforderung
Die Modernisierung der Industrie darf nicht zulassen, dass Anforderungen an KI und Hochleistungsrechnen die Anforderungen an deterministische Steuerung in den Hintergrund drängen.
Bei Steuerungsanwendungen geht es nicht einfach darum, wie viel Rechenleistung verfügbar ist. Das System muss außerdem ein vorhersehbares Scheduling-Verhalten und begrenzte Antwortzeiten für Funktionen mit definierten zeitlichen Anforderungen bieten.
Dies ist besonders wichtig, wenn KI- oder Analyse-Workloads erhebliche Rechenressourcen beanspruchen.
Meiner Einschätzung nach besteht die praktische Architektur daher nicht in einer „KI, die die Steuerung ersetzt“, sondern vielmehr in einer deterministischen Steuerung, die unter kontrollierten Ressourcengrenzen neben übergeordneter Intelligenz arbeitet.
Cybersicherheit muss sich über den gesamten Produktlebenszyklus erstrecken
Technische Isolation ist nur ein Teil der Cyberresilienz.
Hersteller von Industrieanlagen benötigen außerdem Prozesse zur Identifizierung von Softwarekomponenten, zur Überwachung von Schwachstellen, zur Validierung von Aktualisierungen, zur Kontrolle der Softwarebereitstellung und zur Wartung von Produkten während ihrer gesamten Betriebsdauer.
Die Normenreihe ISA/IEC 62443 bietet einen lebenszyklusorientierten Rahmen, der speziell für industrielle Automatisierungs- und Steuerungssysteme relevant ist. Andere Normen, darunter ISO/SAE 21434, zeigen, wie sich ein strukturiertes Risikomanagement für Cybersicherheit von der Entwicklung über Betrieb und Wartung bis hin zur Außerbetriebnahme erstrecken kann.
Der europäische Cyber Resilience Act erhöht zudem die Bedeutung des Cybersicherheitsmanagements über den gesamten Lebenszyklus für Produkte in seinem Geltungsbereich.
Für Hersteller von Industrieanlagen bedeutet dies, dass Cybersicherheit vernünftigerweise nicht als Zertifizierungsaktivität in der letzten Phase behandelt werden kann. Softwarezusammenstellung, Reaktion auf Schwachstellen, Aktualisierungsmechanismen, Lieferantenmanagement und Produktwartung müssen während der Systementwicklung berücksichtigt werden.
Sicherheitsarchitektur sollte die Wiederherstellung unterstützen, nicht nur die Prävention
Traditionelle Diskussionen über Cybersicherheit konzentrieren sich häufig auf die Verhinderung unbefugten Zugriffs. Industrielle Resilienz erfordert eine umfassendere Perspektive.
Eine kompromittierte oder fehlerhafte Komponente kann trotz präventiver Kontrollen weiterhin auftreten. Die Architektur muss daher die Fähigkeit der Komponente begrenzen, kritische Funktionen zu beeinträchtigen, und einen definierten Wiederherstellungsweg bereitstellen.
Daraus ergeben sich drei sich ergänzende technische Ziele:
- Verhindern Sie unbefugtes oder unbeabsichtigtes Verhalten.
- Eindämmen Sie Ausfälle und kompromittierte Komponenten.
- Wiederherstellen Sie betroffene Dienste, während der Betrieb unbeeinträchtigter Funktionen aufrechterhalten wird.
Für die industrielle Automatisierung ist diese Kombination praxisnäher, als sich ausschließlich auf Prävention zu verlassen.
QNX als grundlegende Echtzeitplattform
QNX bietet eine auf einem Echtzeit-Mikrokernel basierende Betriebssystemarchitektur für Systeme, in denen eine vorhersehbare Ausführung, Prozessisolierung und kontrollierter Ressourcenzugriff wichtig sind.
In einer Architektur für die industrielle Automatisierung kann QNX die grundlegende Ausführungsumgebung für Anwendungen, Treiber, Protokollstacks und Dateisysteme bereitstellen, die in geschützten Adressräumen betrieben werden. Prioritätsbasiertes Scheduling kann Rechenlasten mit unterschiedlichen zeitlichen Anforderungen unterstützen.
Diese Architektur kann die SPS-basierte Steuerung ergänzen, anstatt sie zu ersetzen.
Ein praxisnahes System kann SPSen für die etablierte Steuerung auf Feldebene beibehalten und gleichzeitig MPU- oder SoC-basierte Computerplattformen mit einem Echtzeitbetriebssystem für HMI, maschinelles Sehen, Konnektivität, Analytik, Überwachungsfunktionen und KI-bezogene Rechenlasten einsetzen.
Eine praxisorientierte Architektur für die Modernisierung der Industrie
Ein modernes Industriesystem kann daher als mehrere zusammenwirkende Ebenen betrachtet werden:
- Feldebene: Sensoren, Aktoren, Antriebe und andere physische Geräte.
- Steuerungsebene: SPSen und Steuerungen, die deterministische Automatisierung ausführen.
- Rechenebene: MPU-/SoC-Plattformen, die zusätzliche Rechenkapazität bereitstellen.
- Intelligenzebene: Maschinelles Sehen, Analytik, KI-Inferenz und andere Rechenlasten.
- Überwachungsebene: HMI, Diagnose, Ereignisverwaltung und betriebliche Anwendungen.
- Konnektivitätsebene: Industrielle Netzwerke und externe Kommunikationsdienste.
- Grundlegende Softwareebene: Echtzeitbetriebssystem, Isolierung, Scheduling, Ressourcenverwaltung und Wiederherstellungsmechanismen.
Die zentrale technische Anforderung besteht darin, die Grenzen zwischen diesen Ebenen zu definieren, anstatt die gesamte Computerumgebung als einen undifferenzierten Anwendungsbereich zu behandeln.
Die Modernisierung sollte bestehende Investitionen in die Steuerung bewahren
Industrielle Anlagen bleiben oft viele Jahre in Betrieb. Die etablierte SPS-basierte Steuerung nur deshalb zu ersetzen, weil neue Rechenfunktionen verfügbar sind, ist technisch oder wirtschaftlich nicht immer gerechtfertigt.
Eine praktikablere Modernisierungsstrategie besteht darin, bewährte Steuerungsfunktionen beizubehalten und sie um zusätzliche Rechenressourcen zu ergänzen.
Plattformen auf MPU- und SoC-Basis können die für moderne HMI, KI, Analytik, Visualisierung und Konnektivität erforderliche Rechenleistung bereitstellen, während bestehende SPS weiterhin deterministische Steuerungsaufgaben übernehmen.
Dieser Ansatz ermöglicht es Herstellern, neue Funktionen einzuführen, ohne etablierte Steuerungsarchitekturen unnötig zu beeinträchtigen.
Meine Perspektive als Ingenieur: Robustheit beginnt mit der Architektur
Die wichtigste Erkenntnis aus diesem Wandel ist, dass Robustheit nicht nachträglich hinzugefügt werden kann, wenn das System bereits konsolidiert wurde.
Wenn Steuerung, Netzwerk, HMI, Analytik und KI gemeinsame Rechenressourcen nutzen, müssen Isolierungs- und Wiederherstellungsmechanismen bereits Bestandteil der ursprünglichen Architektur sein.
Ein leistungsfähiger Prozessor allein schafft noch kein robustes Automatisierungssystem. Ebenso macht ein KI-Modell ein Automatisierungssystem nicht intelligent, wenn die umgebende Plattform nicht in der Lage ist, Daten zu erfassen, das Modell auszuführen, seine Ausgabe zu validieren, vordefinierte Richtlinien durchzusetzen und innerhalb der erforderlichen betrieblichen Grenzen zu reagieren.
Die nächste Generation der industriellen Automatisierung wird daher nicht nur von höherer Rechenleistung abhängen, sondern davon, wie effektiv die Softwarearchitektur die Interaktion zwischen den Workloads steuert.
Fazit
Die industrielle Automatisierung tritt in eine Architektur ein, in der SPS, leistungsfähige Prozessoren, KI, Konnektivität und softwaredefinierte Funktionen zunehmend zusammenwirken.
Dies eröffnet erhebliche Möglichkeiten für die Modernisierung, führt aber auch neue Abhängigkeiten und Fehlerzustände ein.
Eine robuste Architektur muss deterministische Ausführung, Prozessisolierung, Speicherschutz, kontrollierten Ressourcenzugriff, Fehlerbegrenzung, das Management des Cybersicherheitslebenszyklus und definierte Wiederherstellungsmechanismen miteinander verbinden.
Echtzeitbetriebssysteme auf Microkernel-Basis wie QNX stellen einen architektonischen Ansatz für diese Anforderungen dar. Zusammen mit bestehenden SPS- und Steuerungstechnologien eingesetzt, können solche Plattformen die erforderliche Softwaregrundlage für die Integration moderner Rechenlasten bereitstellen und zugleich klare Grenzen für kritische Automatisierungsfunktionen wahren.
