SPS-Code-Review: Best Practices für Industrieanlagen

Ein SPS-Code-Review prüft ein SPS-Programm systematisch auf Korrektheit, Sicherheit, Wartbarkeit und Performance. Anders als in der IT kann ein Logikfehler in der SPS physischen Schaden verursachen.

Wann ein Code-Review durchführen#

• Vor Inbetriebnahme eines neuen oder geänderten Systems
• Nach einer Migration auf eine andere SPS-Plattform
• Bei Übernahme eines undokumentierten Systems
• Nach einem sicherheitsrelevanten Vorfall
• Periodisch (jährlich bei sicherheitskritischen Anlagen)

Was prüfen (Prioritätsreihenfolge)#

1. Sicherheitslogik (Höchste Priorität)#

• Not-Aus-Kreise: Korrekt verdrahtet und programmiert? Alle gefährlichen Bewegungen gestoppt? Fail-Safe (Öffner/Active-Low)?
• Sicherheitsverriegelungen: Alle vorhanden? Keine Software-Überbrückung möglich?
• Schutzeinrichtungen: Schutztüren, Lichtvorhänge, Zweihandsteuerungen korrekt ausgewertet?
• Forcierte E/A: Force-Tabelle prüfen — dauerhaft forcierte Punkte? Häufige Quelle versteckter Sicherheitsumgehungen.

2. Anlauf- und Abschaltverhalten#

• Kaltstart: Alle Ausgänge in sicherem Zustand? Keine unerwarteten Bewegungen?
• Neustart nach Störung: Explizite Quittierung durch Bediener erforderlich?

3. Programmstruktur#

• Bausteinorganisation: Logisch strukturiert?
• Toter Code: Nie aufgerufene Bausteine? Unerreichbare Codeabschnitte?
• Duplikate: Gleiche Logik in mehreren Bausteinen kopiert statt parametrierten FB?

4. Datenhandling#

• Nicht initialisierte Variablen: Alle Merker und DB-Elemente beim Anlauf initialisiert?
• Überlappende Speicherzugriffe: Selbes Merkerwort aus mehreren Stellen beschrieben?

5. Timer und Zähler#

• Zeitwerte prozessgerecht? 100ms-Timer auf einem 5-Sekunden-Mechanikprozess = Copy-Paste-Verdacht.
• Rücksetzbare Timer: Haben speichernde Timer (SS) Rücksetzbedingungen?

Prüfliste#

Sicherheit:

• ☐ Not-Aus korrekt (Öffner, Active-Low)
• ☐ Alle Verriegelungen vorhanden
• ☐ Keine dauerhaft forcierten E/A
• ☐ Sicherer Anlaufzustand
• ☐ Quittierung nach Störung erforderlich

Struktur:

• ☐ Klare Bausteinorganisation
• ☐ Kein toter Code
• ☐ Sprechende Symbolnamen
• ☐ Netzwerk-/Bausteinkommentare vorhanden

Daten:

• ☐ Alle Variablen initialisiert
• ☐ Keine überlappenden Schreibzugriffe

Häufig gestellte Fragen#

Wer sollte das Review machen?

Jemand der den Code nicht geschrieben hat. Ein zweites Augenpaar findet Dinge die der Autor übersieht.

Wie lange dauert ein Review?

Mittleres Programm (50–100 Bausteine): 1–2 Tage. Sicherheitskritische Reviews können länger dauern.

---

Gepflegt von PLCcheck.ai. Letztes Update: März 2026. Keine Verbindung zu Siemens AG.