SPS-Software modernisieren, ohne die ganze Maschine neu zu programmieren

Die zentrale Frage ist, wie die nächste Softwareänderung verlässlich gelingen kann, ohne die ganze Maschine zu gefährden. Ein schwer wartbares System kostet bei jeder Erweiterung Zeit. Eine vollständige Neuentwicklung ohne Testbasis kann dagegen neue Fehler und Stillstände verursachen. Vergleichen Sie beide Risiken, bevor Sie den Umfang festlegen.

Zuerst sollten Risiken und geschäftliche Ziele geklärt werden, nicht das Alter oder der Stil des SPS-Codes. Wenn Bewegungen, Prozesse und Steuerungshardware bewährt und unterstützt sind, kann eine schrittweise Migration mehr Wert erhalten als ein vollständige Neuentwicklung. Fehlender Support oder nicht mehr überprüfbare kritische Schnittstellen können dagegen eine größere Ablösung erforderlich machen.

Definieren Sie konkrete Verbesserungen: Variantenhandling, Diagnose, Wiederanlauf, Testbarkeit oder Wartbarkeit. Jede braucht einen beobachtbaren Akzeptanztest. Neue Software ohne dokumentierte Ausgangsbasis kann alte Fehler lediglich in einem neuen Programmierstil reproduzieren.

Lassen Sie Ihr Team zunächst benennen, wo Änderungen wirklich Zeit verlieren: Verstehen des Altprogramms, Variantentests, Inbetriebnahme, Fehlerdiagnose oder Wiederanlauf. Eine kurze Bestandsaufnahme mit drei reproduzierbaren Problemszenarien ist für diese Entscheidung hilfreicher als die Anzahl der Codezeilen.

Verfolgen Sie einen vollständigen Ablauf: von Stopped über Reset und Start bis zur Produktion, dann Stop und Wiederanlauf nach einem Fehler. Welche Funktion besitzt die Befehlszuständigkeit? Welche Signale geben Bewegungen frei? Welche Meldungen sind nur Diagnose und welche sind echte Verriegelungen?

Halten Sie eine überprüfbare Baseline fest: Zustandsverläufe, Zykluszeiten, I/O-Mapping, Variantenszenarien und reproduzierbare Fehler. Ohne diese Grundlage lässt sich nach einem Umbau kaum beweisen, dass das Verhalten unverändert geblieben ist.

Ein Pilot braucht ein klares Ergebnis. Beispielsweise meldet die Auslaufstation das tatsächliche Ende ihres Resets, statt dass die Gesamtmaschine dem Bediener zu früh Bereitschaft anzeigt.

Beschreiben Sie vor dem Refactoring einen Schnittstellenvertrag. Wer fordert Start und Stop an? Was bedeutet Ready? Wann wird StateComplete gemeldet? Wie werden Fehler weitergegeben und unter welchen Bedingungen darf Reset ausgeführt werden? Bewährte Funktionsblöcke können zunächst hinter einem schlanken Adapter bestehen bleiben.

Ein Adapter braucht eindeutige Verantwortung. Alte und neue Steuerung dürfen nicht gleichzeitig Befehle an dieselben Aktoren ausgeben. Während eines Übergangs kann man Diagnosewerte passiv vergleichen; die Befehlsgewalt muss dagegen kontrolliert und getestet umgestellt werden.

Wenn der Adapter sämtliche alten BOOL-Signale in einer zweiten Ablaufsteuerung dupliziert, verbessert er die Architektur nicht. Die Schnittstelle soll vereinfachen, nicht neue Parallelzustände schaffen.

PackML bietet eine gemeinsame Sprache für Maschinen- und Unit-Zustände, Betriebsarten und Befehle. So können übergeordnete Steuerung, HMI und Module Stopped, Resetting, Idle, Starting, Execute oder Aborting einheitlich interpretieren. Nicht jeder Sensor und jede Achse braucht deshalb ein komplettes PackML-Modell.

Die Grundlagen finden Sie bei OMAC und im ISA-TR88.00.02-2022 Wählen Sie das passende Zustandsmodell und die benötigten Zustände bewusst. Parent/Child-Hierarchie und Adapter sind praktische Architekturentscheidungen, keine Anforderungen an jeden internen Funktionsbaustein.

Bei einer vorhandenen Maschine kann zuerst die externe Zustands-Schnittstelle standardisiert werden. Der Parent wartet beispielsweise in Resetting, bis alle beteiligten Child-Module tatsächlich abgeschlossen haben. Das HMI kann dann zeigen, welche Station noch wartet.

PackML ist keine funktionale Sicherheit. Der Zustand Aborting ersetzt keinen Not-Halt und ein virtueller Test ersetzt weder die Risikobeurteilung noch die physische Prüfung der erforderlichen Sicherheitsfunktionen.

Stellen Sie sich eine Maschine mit drei Stationen vor. Der Einlauf liefert Teile, die Prozessstation bearbeitet sie und der Auslauf übernimmt sie. Die Anlage funktioniert, aber jede Station verwendet andere Reset- und Fehlersignale. Main zeigt gelegentlich Ready, obwohl der Auslauf seine Wiederherstellung noch nicht abgeschlossen hat.

Im ersten Schritt bleibt die bewährte Prozess- und Motion-Logik unverändert. Ein Zustandsadapter am Auslauf unterscheidet Resetting, Idle und Execute und meldet das tatsächliche Ende von Reset. Die übergeordnete Steuerung wartet auf diese Rückmeldung statt auf ein unscharfes Sammelbit.

Im zweiten Schritt erhält der Einlauf denselben Vertrag. Anschließend werden blockierter Auslauf und fehlendes Teil getestet. Bestehende Prozess- und Bewegungsverriegelungen bleiben bindend, bis eine gesonderte Änderung überprüft wurde.

Erst danach werden doppelte Kommandopfade in Main entfernt. Das HMI zeigt nun beispielsweise Warten auf Auslauf und den lokalen Grund. Dies ist ein Architekturbeispiel, keine dokumentierte Kundencase und kein Nachweis einer Zeitersparnis.

Ein Code-Review und ein erfolgreicher SPS-Build sind notwendig, beweisen aber kein korrektes Maschinenverhalten. Legen Sie deshalb einen kleinen Regressionstest mit normalen Abläufen und gezielten Fehlerszenarien an.

Wo sinnvoll, läuft die echte Steuerungslogik gegen ein virtuelles Maschinenmodell, einen Testumgebung oder einen geeigneten Controller-Prüfstand. Dort lassen sich Handshakes, Zeiten und Recovery wiederholen. Grenzen der Simulation müssen explizit sein: Mechanik, Prozessphysik, Feldbuszeiten, reale Antriebe und Sicherheitsfunktionen können sich anders verhalten.

Geben Sie einen Abschnitt erst frei, wenn die vereinbarten Kriterien erfüllt, neue HMI-Meldungen verständlich und ein versionierter Rückweg vorhanden sind. Halten Sie Softwarestand, Szenario, Soll- und Ist-Verhalten und offene Punkte fest. Relevante Prüfungen werden später an der realen Maschine wiederholt.

Beginnen Sie mit einer kurzen Bestands- und Risikoanalyse. Das Ergebnis ist kein pauschaler Komplettrewrite, sondern eine Liste der Schnittstellen, Risiken, möglichen Pilotmodule und nachvollziehbaren Erfolgsbedingungen. Definieren Sie ausdrücklich, was unverändert bleibt.

Im ersten Umsetzungsschritt führen Sie gemeinsame Diagnosen und einen Modulvertrag ein. Danach modernisieren Sie eine zweite Station einschließlich HMI-Diagnose. Erst wenn diese Bausteine nachweislich funktionieren, reduzieren Sie doppelte Logik im Supervisor und ergänzen automatisierte Regressionstests.

Schätzen Sie nach Modulgrenzen und Integrationsrisiken, nicht nach Anzahl der Codezeilen. Eine dokumentierte Maschine mit Testsystem unterscheidet sich grundlegend von einer nicht dokumentierten Anlage mit kritischen Abhängigkeiten. Solche Annahmen gehören in ein transparentes Angebot.

Ein guter Abschluss macht spätere Änderungen besser beschreibbar, testbar und rückrollbar. Er bedeutet nicht, dass die gesamte Bestandsmaschine über Nacht vollständig modular wird.

Ein Engineering-Partner sollte die Grenzen klar benennen: Was bleibt? Was wird geändert? Wer besitzt Befehle und Verriegelungen? Wie verhalten sich Fehler und Varianten? Und wie wird eine misslungene Freigabe wieder zurückgenommen?

Ein belastbares Angebot nennt ein Pilotmodul, die betroffenen SPS- und Runtimeversionen, Akzeptanztests und Tätigkeiten, die eine Sicherheitsprüfung oder Maschinenstillstand erfordern. Trennen Sie einen bekannten Festpreisabschnitt von Risiken, die erst nach der Analyse geschätzt werden können.

Wenn die Abläufe funktionieren, aber die Module schwer miteinander kooperieren, kann eine schrittweise Migration sinnvoll sein. Ist kritische Hardware hingegen nicht mehr unterstützt oder sind Schnittstellen nicht mehr beherrschbar, kann die Bewertung zu einem umfassenderen Ersatz führen.