SPS-Code ohne Dokumentation als Sicherheitsrisiko

Ein undokumentiertes SPS-Programm ist eine Haftungsfalle. Wenn niemand versteht was der Code tut, wird jeder Wartungseingriff zum Glücksspiel. Falsche Annahmen über Zeitwerte, Sicherheitsverriegelungen oder Ablauflogik können Maschinenschäden, Produktfehler oder Verletzungen verursachen. Dieser Artikel benennt die konkreten Risiken und was Normen wie IEC 62443 und die EU-Maschinenverordnung von Anlagenbetreibern erwarten.

Die vier Risiken undokumentierter SPS-Programme#

1. Betriebsrisiko: Unkontrollierte Änderungen#

Wenn ein Techniker ein Programm ändert, das er nicht vollständig versteht, sind die Folgen unvorhersehbar:

Zeitwert ändern ohne den Kontext zu kennen. Ein Timer, der "nur eine Verzögerung" zu sein scheint, kann tatsächlich eine kritische Sicherheitsverriegelung sein. Ihn von 5 auf 1 Sekunde zu verkürzen, weil "die Maschine zu langsam läuft", kann die Zeit eliminieren, die für einen Hydraulikdruckabbau, das Schließen einer Schutztür oder den Hochlauf eines Motors nötig ist.

Verriegelung überbrücken um "die Produktion wieder ans Laufen zu bringen." Wenn ein Sensor ausfällt und die Maschine stoppt, ist der Produktionsdruck enorm. Ein Techniker, der die Verriegelungslogik nicht versteht, überbrückt möglicherweise den Sensoreingang (forciert ihn auf TRUE), ohne zu wissen, dass der Sensor vor einer Kollision, einem Überlauf oder einer Quetschstelle schützt.

Copy-Paste-Fehler zwischen ähnlichen Maschinen. Eine Programmänderung funktioniert an Maschine A und wird auf Maschine B kopiert — aber Maschine B hat eine andere E/A-Belegung, andere Zeitwerte oder andere Sicherheitsanforderungen. Ohne Dokumentation sind diese Unterschiede unsichtbar.

Das sind keine theoretischen Risiken. Sie passieren in Industriebetrieben jede Woche.

2. Wissensrisiko: Einzelperson als Schwachstelle#

Wenn nur eine Person das SPS-Programm versteht, ist diese Person ein Single Point of Failure — für das gesamte Produktionssystem.

Ruhestand: Der Ingenieur, der das Programm vor 20 Jahren geschrieben hat, geht in Rente. Sein Wissen darüber warum bestimmte Logik existiert verschwindet dauerhaft.

Arbeitgeberwechsel: Ein Schlüsseltechniker wechselt die Firma. Der Nachfolger hat keinen Kontext für den bestehenden Code.

Krankheit oder Abwesenheit: Selbst ein zweiwöchiger Urlaub der einzigen Person, die ein kritisches System versteht, kann ein inakzeptables Risiko darstellen.

3. Cybersecurity-Risiko: Unbekannte Angriffsfläche#

Undokumentierter SPS-Code erzeugt blinde Flecken in der Cybersicherheit:

Keine Baseline für Änderungserkennung. Wenn Sie nicht wissen wie das Programm aussehen soll, können Sie unautorisierte Änderungen nicht erkennen.

Unbekannte Netzwerkexposition. Undokumentierte Kommunikationsbausteine können die SPS mit Netzwerken verbinden, von denen die IT-Abteilung nichts weiß. S5- und S7-300-Systeme haben oft MPI-, PROFIBUS- oder sogar Modem-Verbindungen, die vor Jahrzehnten konfiguriert und nie dokumentiert wurden.

Kein Patch-Management möglich. Firmware-Updates können nicht sicher bewertet werden, wenn unklar ist was das SPS-Programm tut.

Das 2022 entdeckte Pipedream-Malware-Toolkit, das speziell für SPS und SCADA-Systeme entwickelt wurde, zeigte, dass industrielle Steuerungssysteme aktive Angriffsziele sind.

4. Compliance-Risiko: Regulatorische Anforderungen#

Mehrere regulatorische Rahmenwerke fordern dokumentierte Steuerungssysteme:

IEC 62443 (Industrielle Cybersicherheit): IEC 62443 definiert Reifegrade für industrielle Cybersicherheit. Auf Stufe 1 (Initial) werden Prozesse als "ad hoc und oft undokumentiert" beschrieben. Ab Stufe 2 (Managed) sind dokumentierte Prozesse Pflicht. Ein undokumentiertes SPS-Programm besteht nicht einmal die grundlegendste IEC 62443-Reifegradbeurteilung.

EU-Maschinenverordnung (2023/1230): Die neue EU-Maschinenverordnung (Nachfolgerin der Maschinenrichtlinie 2006/42/EG) fordert "Anweisungen und Informationen für die sichere Benutzung." Für Maschinen mit SPS-basierten Sicherheitsfunktionen schließt das die Dokumentation der Steuerungslogik ein.

ISO 13849 / IEC 62061 (Funktionale Sicherheit von Maschinen): Diese Normen fordern, dass sicherheitsbezogene Steuerungsfunktionen dokumentiert, validiert und gepflegt werden. Ein undokumentiertes SPS-Programm mit Sicherheitsverriegelungen kann die Konformität mit diesen Normen nicht nachweisen.

Versicherung und Haftung: Industrieversicherungen verlangen zunehmend Nachweise über Instandhaltungsmanagement — einschließlich Software-Wartung. Ein undokumentiertes Steuerungssystem kann den Versicherungsschutz im Schadensfall einschränken oder aufheben.

Die Mindestdokumentation#

Sie brauchen kein 200-seitiges Handbuch für jede SPS. Aber Sie brauchen mindestens:

1. Eine Symboltabelle mit aussagekräftigen Namen für jede verwendete E/A-Adresse
2. Netzwerk-Kommentare die den Zweck jedes Logikabschnitts erklären
3. Ein aktuelles Backup des SPS-Programms, verifiziert, an mindestens zwei Orten
4. Eine E/A-Liste mit Zuordnung von SPS-Adressen zu physischen Geräten
5. Ein Änderungsprotokoll mit Datum, Person und Grund jeder Modifikation

Diese Mindestdokumentation kann in 1–3 Tagen für ein typisches SPS-Programm erstellt werden (siehe unseren Dokumentationsleitfaden).

Was PLCcheck Pro für Sie tun kann#

• Rohen AWL/STL-Code hochladen → verständliche Erklärung jedes Bausteins
• Automatische E/A-Erkennung → jeder verwendete Ein-/Ausgang im Programm
• Sicherheitsrelevante Mustererkennung → identifiziert Verriegelungen, Not-Aus-Logik, Sicherheitstimer
• Sofortige Dokumentation → exportierbare Berichte für Auditoren, Geschäftsführung oder Instandhaltung

Jetzt Code hochladen →

Häufig gestellte Fragen#

Ist undokumentierter SPS-Code illegal?

Nicht direkt. Aber wenn eine sicherheitsrelevante Funktion undokumentiert ist und ein Unfall passiert, kann die fehlende Dokumentation als Nachweis für Fahrlässigkeit herangezogen werden. IEC 62443, ISO 13849 und die EU-Maschinenverordnung setzen klare Erwartungen an die Dokumentation.

Wer ist verantwortlich für die SPS-Dokumentation?

Der Anlagenbetreiber (Asset Owner) ist letztlich verantwortlich für die Wartung seiner Steuerungssysteme, einschließlich Dokumentation. Maschinenhersteller liefern die Erstdokumentation. Nach Änderungen liegt die Verantwortung bei demjenigen, der die Änderung vorgenommen hat.

Kann fehlende Dokumentation zu einem Audit-Befund führen?

Ja. IEC 62443-Audits, ISO-Audits, Versicherungsprüfungen und Kundenaudits fragen zunehmend nach Steuerungssystem-Dokumentation. "Wir haben keine Dokumentation" ist ein Befund, der Korrekturmaßnahmen, höhere Versicherungsprämien oder den Verlust von Kundenzertifizierungen nach sich ziehen kann.

---

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