Legacy-SPS-Code refactoren: Von Spaghetti zu Struktur
Wie man unstrukturierten Legacy-SPS-Code in wartbare Struktur umwandelt. Spaghetti-Code erkennen, schrittweise refactoren, wann Neuschreiben statt Refactoring.
Legacy-SPS-Code refactoren: Von Spaghetti zu Struktur
"Spaghetti-Code" in SPSen: ein riesiger OB1 mit 500 Netzwerken, keine Unterprogramme, hunderte unbenannte Merker, Sprungbefehle in alle Richtungen, und 20 Jahre Modifikationen übereinander geschichtet.
Anzeichen für Spaghetti-Code
- Alles in OB1: Keine PBs, FBs oder FCs. Alle Logik in einem Block.
- Merker-Überflutung: Hunderte M-Bits ohne Dokumentation.
- Sprung-Spaghetti: SPB/SPA kreuz und quer durch den Baustein.
- Kopierter Code: Gleiche Logik 10× dupliziert mit anderen Adressen.
- Magische Zahlen: Zeitwerte und Sollwerte direkt im Code (KF +1234).
- Toter Code: Nie ausgeführte Netzwerke die noch da sind.
Regel #1: Nie ohne Test refactoren
- Backup erstellen (verifiziert — Online mit Offline vergleichen)
- Aktuelles Verhalten dokumentieren (Maschinenzyklus beobachten)
- Testplan erstellen (wie wird identisches Verhalten verifiziert?)
- Rollback planen (wie schnell Original wiederherstellen?)
Schritt 1: Funktionale Blöcke extrahieren
OB1-Abschnitte in eigene Bausteine auslagern:
| Funktion | Vorher (in OB1) | Nachher |
|---|---|---|
| Förderband | Netzwerk 10–25 | FC_Foerderband |
| Befüllung | Netzwerk 26–50 | FB_Befuellung |
| Sicherheit | Verstreut | FC_Sicherheit (erster Aufruf in OB1) |
Schritt 2: Merker durch strukturierte Daten ersetzen
Statt 50 Einzelmerker → globaler Datenbaustein mit sprechenden Namen:
DB_Maschine.Foerderband.Laeuft : BOOL
DB_Maschine.Befuellung.Sollwert : INT := 1500
Schritt 3: Sprung-Spaghetti eliminieren
SPB/SPBN/SPA-Muster durch IF/THEN/ELSE in SCL ersetzen.
Schritt 4: Wiederholte Logik parametrieren
Gleiche Logik 10× kopiert → ein parametrierter FB_Motor, 10× aufgerufen mit verschiedenen Parametern.
Schritt 5: Konstanten in Datenbausteine
Fest kodierte Werte (magische Zahlen) durch benannte Konstanten in Parameter-DB ersetzen.
Refactoring vs. Neuschreiben
| Situation | Empfehlung |
|---|---|
| Code funktioniert, aber schwer wartbar | Schrittweise refactoren |
| Grundlegende Designprobleme | Neu schreiben |
| Migration auf neue Plattform | Migration + Refactoring kombinieren |
| Niemand versteht den Code | Erst dokumentieren (PLCcheck Pro), dann entscheiden |
Goldene Regel: Bei ohnehin geplanter Migration ist Refactoring "kostenlos" — das gesamte Programm wird sowieso getestet.
Häufig gestellte Fragen
Wie refactoren ohne Produktionsstopp?
Offline refactoren. In PLCSIM testen. Während geplanter Wartung deployen. Original für sofortigen Rollback bereit halten.
Alles nach SCL konvertieren?
Nicht nötig. Einfache Bitlogik in KOP/FUP belassen. Komplexe AWL und Berechnungen nach SCL. Beste Sprache pro Aufgabe.
Gepflegt von PLCcheck.ai. Letztes Update: März 2026. Keine Verbindung zu Siemens AG.
Verwandte Artikel
SPS-Zykluszeit optimieren: Praktische Techniken
Praktische Techniken zur Reduzierung der SPS-Zykluszeit. Codestruktur, bedingte Ausführung, Datentyp-Auswahl, optimierte Datenbausteine, Interrupt-Architektur.
10 Min. Lesezeit
plc-programmingHäufige SPS-Programmierfehler und ihre Lösung
Die 10 häufigsten SPS-Programmierfehler in Industrieanlagen. Jeder Fehler mit Erklärung, realen Konsequenzen und Lösung.
12 Min. Lesezeit
plc-programmingSPS-Code-Review: Best Practices für Industrieanlagen
Wie Sie ein systematisches SPS-Code-Review in einer Industrieanlage durchführen. Was zu prüfen ist, wie priorisiert wird, typische Befunde und Prüfliste.
10 Min. Lesezeit
SPS-Code mit KI analysieren
PLCcheck Pro erklärt, dokumentiert, optimiert und migriert SPS-Code — automatisch.
PLCcheck Pro testen →Nicht verbunden mit Siemens AG. S5, S7, STEP 5, STEP 7 und TIA Portal sind Marken der Siemens AG.