Stellen Sie sich einen Maschinenbauer vor, der die nächste Version einer Verpackungsmaschine vorbereitet. Ein Kunde benötigt andere Bedieneransichten, ein anderer wünscht sich zusätzliche Diagnosefunktionen, ein dritter verlangt eine Schnittstelle zu einer bestehenden Produktionslinie. Die Kernmaschine bleibt zwar erkennbar, doch die Softwareanforderungen gehen auseinander.
Die Frage ist nicht mehr nur, wie jede Maschine programmiert werden soll. Es geht vielmehr darum, wie diese Varianten entwickelt werden können, ohne für jede Konfiguration ein separates, zunehmend anfälliges Projekt zu führen, und wie die installierten Maschinen auch nach der Auslieferung weiterhin unterstützt werden können.
Unser früherer Artikel darüber, warum die industrielle Automatisierung zunehmend softwaredefiniert wird, beschrieb die allgemeine Richtung. Für Maschinenbauer zeigt sich die praktische Bedeutung in einem ganz alltäglichen Arbeitsablauf: dem Entwurf einer Maschinenfamilie, der Inbetriebnahme einzelner Maschinen, der Freigabe von Änderungen und deren Support noch Jahre später . Softwaredefinierte Automatisierung verändert die Organisation dieser Schritte. Sie beseitigt jedoch nicht die technischen Verpflichtungen, die mit einem physischen Prozess verbunden sind.
Eine Maschinenfamilie benötigt eine Softwarearchitektur
Viele OEMs verwenden bereits Steuerungscode, Visualisierungsobjekte und Kommunikationstreiber wieder. Die größere Veränderung besteht darin, diese Wiederverwendung als architektonische Entscheidung zu betrachten und nicht als eine Sammlung von Dateien, die von einem Projekt ins nächste kopiert werden.
Eine Maschinenfamilie kann gemeinsame Kernabläufe, Diagnosen und Datendefinitionen aufweisen, sich jedoch in Bezug auf E/A, Optionen, Schnittstellen oder kundenspezifisches Verhalten unterscheiden. Sind diese Unterschiede in der gesamten Anwendung verstreut, kann jede neue Variante zu einem neuen Zweig werden, der getestet und gewartet werden muss. Wenn gemeinsame Funktionen und maschinenspezifische Konfigurationen klar voneinander abgegrenzt sind, können Ingenieure erkennen, welche Änderungen zur Plattform gehören und welche zu einer einzelnen Maschine.
Dies erfordert kein einziges universelles Programm, sondern eine bewusst gestaltete Beziehung zwischen wiederverwendbaren Modulen, Konfiguration, Schnittstellen und der Hardware, auf der sie laufen. Eine neue Option kann dann als Änderung an einem definierten Teil der Architektur betrachtet werden, wobei ihre Abhängigkeiten und Tests bereits bekannt sind, bevor sie den Kundenstandort erreicht.
Der Nutzen ist potenziell erheblich für einen OEM, der mehrere verwandte Maschinen baut: Der Entwicklungsaufwand kann auf die Unterschiede konzentriert werden, die für die Anwendung von Bedeutung sind. Ebenso wichtig ist die Voraussetzung: Gemeinsame Software schafft gemeinsame Verantwortung. Eine Änderung an einem gemeinsamen Modul kann sich auf viele Konfigurationen auswirken, daher muss der OEM genau wissen, wo dieses Modul verwendet wird.
Wiederverwendbarer Code ist nicht automatisch portierbarer Code
„Hardwareunabhängigkeit“wird oft als Kurzform für softwaredefinierte Automatisierung verwendet. Dieser Begriff verdient eine genauere Betrachtung. Es besteht ein Unterschied zwischen der Wiederverwendung eines Software-Designs auf mehreren Maschinen in einer Umgebung und dem unveränderten Ausführen derselben Anwendung auf einer beliebigen Steuerung.
Die FAQ von PLCopen zur Portabilität nach IEC 61131-3 verdeutlicht diese Unterscheidung besonders anschaulich. Selbst wenn Steuerungen denselben Programmierstandard unterstützen, können E/A-Adressierung, unterstützte Funktionen, Task-Abtastraten und implementierungsspezifische Einschränkungen verhindern, dass ein Projekt direkt von der SPS eines Anbieters auf die eines anderen kopiert werden kann. Eine gemeinsame Sprache ist nützlich; sie garantiert jedoch für sich genommen noch keine gemeinsame Laufzeitumgebung.
Die praktische Konsequenz ist, dass ein OEM den Umfang der Portabilität definieren muss, bevor er diese verspricht. Eine gemeinsame Anwendungsstruktur kann die Wiederverwendung von Code innerhalb einer Maschinenfamilie erleichtern. Die Übertragung dieses Codes auf eine andere Laufzeitumgebung oder Steuerung erfordert jedoch weiterhin die Überprüfung der Hardware-Schnittstellen, des Ausführungsverhaltens und der unterstützten Funktionen. Dabei handelt es sich um unterschiedliche Aussagen, hinter denen unterschiedliche Testniveaus stehen.
Für einen Maschinenbauer ist die relevante Frage daher konkret: Welcher Teil der Software soll bei einer Änderung der Hardware wiederverwendbar bleiben? Das kann ein Diagnosemodul, ein Visualisierungskonzept, ein Datenmodell oder eine Steuerungsfunktion sein. Jedes davon weist unterschiedliche Abhängigkeiten auf. Es ist sinnvoller, diese frühzeitig aufzulisten, als davon auszugehen, dass Portabilität später gegeben ist, nur weil eine Komponente als „softwaredefiniert“ bezeichnet wurde.
Die Bereitstellung wird Teil der Maschinenentwicklung
Wenn Anwendungen unabhängiger konfiguriert und bereitgestellt werden können, sieht die Inbetriebnahme anders aus. Ein OEM kann eine getestete Basisversion für eine Maschinenfamilie erstellen und dann für jeden Auftrag die genehmigten Optionen anwenden. Das Entwicklungsteam muss wissen, welche Version installiert wurde, welche Konfiguration verwendet wurde und anhand welcher Hardware und Laufzeitumgebung sie validiert wurde.
Diese Aufzeichnungen sind nach der Auslieferung von Bedeutung. Ein Servicetechniker, der einen Fehler untersucht, muss einen Softwarefehler von einer standortspezifischen Konfigurationsänderung oder einer Hardwareabhängigkeit unterscheiden können. Der OEM benötigt zudem einen kontrollierten Weg, um eine getestete Verbesserung auf andere geeignete Maschinen zu übertragen, ohne davon auszugehen, dass alle Maschinen im Feld identisch sind.
Hier wird die softwaredefinierte Automatisierung zu einer Disziplin des Lebenszyklus. Das Release ist eine Version, die möglicherweise identifiziert, getestet, installiert, unterstützt und schließlich ersetzt werden muss. Für den OEM bedeutet dies, zu planen, wie Änderungen validiert werden und wie Serviceteams erkennen können, welche Maschinen für ein bestimmtes Update in Frage kommen.
Tatsächlich betont der NIST-Leitfaden zur Sicherheit der Betriebstechnik (Guide to Operational Technology Security), Abschnitt 6.2.11, S. 124–125, die Notwendigkeit, Patches auf betriebliche Auswirkungen zu testen, zu dokumentieren, wie und wann sie angewendet werden, und die Bereitstellung unter Berücksichtigung von Ausfällen der Betriebstechnik zu planen. Diese Grundsätze sind besonders relevant, wenn Softwareänderungen Steuerungsanwendungen oder die Maschinenverfügbarkeit beeinträchtigen könnten. Eine einfachere Verteilung sollte mit klareren Genehmigungs-, Test- und Wiederherstellungsverfahren einhergehen.
Flexible Bereitstellung stößt dennoch an physische Grenzen
Eine Maschine verfügt möglicherweise über Rechenressourcen, die zum Ausführen mehrerer Anwendungen ausreichen. Dies eröffnet die Möglichkeit, Visualisierung, Kommunikation, Datenverarbeitung und – in manchen Architekturen – auch die Steuerung auf einer gemeinsamen Plattform unterzubringen. Damit entsteht jedoch auch eine Frage, die sich nicht allein durch die Software-Paketierung beantworten lässt: Was passiert, wenn diese Workloads um Ressourcen konkurrieren oder wenn eine von ihnen ausfällt?
Die Dokumentation zu „Intel Edge Controls for Industrial“ ist hier aufschlussreich. Sie beschreibt Virtualisierung und Containerisierung für Workloads mit unterschiedlichen Kritikalitätsstufen, geht aber auch detailliert auf Echtzeit-Kernel, CPU-Isolierung und andere Maßnahmen ein, die zur Gewährleistung deterministischen Verhaltens eingesetzt werden. Die Notwendigkeit dieser Maßnahmen zeigt, warum die Ausführung einer Steuerungsanwendung als Software nur der Anfang der Entwurfsarbeit ist.
Ein OEM muss weiterhin Zeitabläufe, Fehlerverhalten, Verfügbarkeit, Sicherheitsanforderungen und die zu erwartenden Auswirkungen von Updates auf benachbarte Anwendungen bewerten. Einige Funktionen eignen sich möglicherweise für eine gemeinsam genutzte Rechenumgebung; andere verbleiben möglicherweise auf dedizierten Controllern. Softwaredefinierte Automatisierung bietet Ingenieuren mehr Platzierungsoptionen. Sie lässt diese Einschränkungen jedoch nicht verschwinden.
Schnittstellen, die eine Weiterentwicklung der Software ermöglichen
Selbst eine gut strukturierte Anwendung muss Informationen mit dem Rest der Maschine austauschen. Stabile Schnittstellen ermöglichen es einem OEM, eine Diagnose- oder Visualisierungsfunktion zu ändern, ohne jede damit verbundene Integration neu aufbauen zu müssen. Die OPC-UA-Übersicht und die Konzeptspezifikation zeigen einen Weg auf, wie die Struktur und der Austausch industrieller Informationen über Anwendungen und Geräte hinweg definiert werden können. Dabei handelt es sich um einen Interoperabilitätsmechanismus; die Verlagerung von ausführbarem Steuerungscode in eine andere Laufzeitumgebung bleibt eine separate Entwicklungsaufgabe.
Für die Wartung ist diese Unterscheidung nützlich. Eine Diagnoseanwendung kann unabhängig aktualisiert werden, wenn sie eine dokumentierte Maschinenschnittstelle ausliest und der OEM Änderungen an dieser Schnittstelle kontrolliert. Der Nutzen hängt von der Versionskompatibilität und von Tests ab, nicht einfach von der Wahl eines gemeinsamen Kommunikationsprotokolls.
Was sich für den Maschinenbauer ändert
Die praktischste Änderung für den Maschinenbauer ist eine Verlagerung dessen, was der OEM entwirft. Neben der mechanischen und elektrischen Architektur der Maschine muss er die Grenzen seiner Software definieren: Was kann über Varianten hinweg wiederverwendet werden, was gehört zu einer bestimmten Installation, wie werden Versionen nachverfolgt und welche Funktionen können sich ändern, ohne andere zu beeinträchtigen?
Dies kann zu modulareren Anwendungen, gemeinsam genutzten Entwicklungsressourcen und einem besser kontrollierten Release-Prozess führen. Außerdem können dadurch Abhängigkeiten sichtbar werden, die zuvor in einer Projektdatei verborgen waren. Das Ergebnis ist nicht automatisch Hardwareunabhängigkeit, in jedem Fall schnellere Updates oder ein Grund, jede Funktion zu konsolidieren. Es ist vielmehr die Chance, die Software-Weiterentwicklung zu einem bewussten Bestandteil des Maschinenentwurfs zu machen.
Für einen Maschinenbauer ist die entscheidende Frage einfach: Wenn diese Maschine geändert werden muss, welche Teile können weiterentwickelt werden und was muss erneut validiert werden, bevor sie wieder in Betrieb genommen wird? Eine glaubwürdige softwaredefinierte Architektur sollte es erleichtern, diese Frage während der gesamten Lebensdauer der Maschine zu beantworten.
