SPS-Dokumentation: Was hineingehört, was bei der Übergabe zählt

1.Warum SPS-Dokumentation fast immer fehlt

Kaum ein Automatisierungsprojekt scheitert an fehlender Dokumentation. Es scheitert später – bei der ersten Erweiterung, beim ersten Störfall nach Feierabend, beim ersten Wechsel des zuständigen Programmierers.

Der Grund ist selten Nachlässigkeit. Er ist strukturell: Dokumentation entsteht am Ende eines Projekts, und am Ende eines Projekts ist der Termindruck am größten. Die Anlage läuft, die Abnahme steht an, und die Frage „Ist die Doku fertig?" konkurriert mit der Frage „Läuft die Linie?". Die Antwort ist absehbar.

Das Ergebnis sehe ich bei fast jedem Retrofit: Ein TIA-Portal-Projekt ohne Kommentare, eine Symbolliste mit Merker_47, ein Schaltplan von 2009 und ein Betriebshandbuch, das eine Anlage beschreibt, die seit drei Umbauten nicht mehr existiert.

2.Die drei Ebenen der SPS-Dokumentation

Eine brauchbare Dokumentation besteht aus drei Ebenen, die unterschiedliche Fragen beantworten. Wer nur eine davon liefert, hat nicht dokumentiert – er hat Material abgegeben.

2.1.Ebene 1: Im Code – warum etwas so ist

Diese Ebene beantwortet die Frage, die kein Schaltplan beantwortet: Warum steht das da?

Der Code selbst zeigt bereits, was passiert. Ein Kommentar, der das wiederholt, ist wertlos:

// ❌ Sagt nichts, was der Code nicht schon sagt
bMotorRun := TRUE;  // Motor einschalten

Wertvoll wird ein Kommentar, wenn er den Grund festhält – besonders bei allem, was willkürlich aussieht:

// ✅ Hält fest, warum diese Zahl diese Zahl ist
// 2 s Verzögerung: Hydraulikdruck muss vor dem Anlauf stehen,
// sonst schlägt die Rückmeldung fehl (Anforderung REQ-HYD-012,
// Messprotokoll IBN 2026-03-14)
tDelayStart(IN := bStartRequest, PT := T#2S);
qxMotorStart := tDelayStart.Q;

Die Faustregel: Jede Konstante, die nicht selbsterklärend ist, braucht eine Quelle. Woher kommt die 2 Sekunden? Wer hat den Grenzwert 78,5 °C festgelegt? Ohne diese Angabe traut sich in fünf Jahren niemand, den Wert anzufassen – und die Anlage bleibt auf einem Parameter stehen, den niemand mehr versteht.

Für jeden Funktionsbaustein gehört ein Kopf mit Zweck, Version und Änderungshistorie:

(*
  Name:        FB_MotorControl
  Version:     1.2.0
  Autor:       David Prybisch
  Letzte Änd.: 2026-03-14

  Zweck:
    Standardisierte Motorsteuerung mit Anlaufverzögerung,
    Rückmeldungsüberwachung und Störungsspeicherung.

  Schnittstelle:
    IN  : bStartRequest, bFeedbackRunning, tTimeoutFeedback
    OUT : qxMotorStart, qxFault, wStatusNamur

  Nicht enthalten:
    Keine Drehzahlregelung – dafür FB_DriveControl verwenden.

  Historie:
    v1.2.0  2026-03-14  Timeout-Überwachung ergänzt
    v1.1.0  2025-10-15  NAMUR-NE-107-Alarmintegration
    v1.0.0  2025-09-01  Erstversion
*)

Der Abschnitt „Nicht enthalten" wird fast immer weggelassen und ist einer der nützlichsten. Er verhindert, dass jemand einen Baustein für etwas verwendet, wofür er nie gedacht war.

2.2.Ebene 2: Im Projekt – wie das Ganze zusammenhängt

Diese Ebene beantwortet: Wie greifen die Teile ineinander?

• Bausteinübersicht mit einem Satz je Baustein. Keine Romane – ein Satz, der sagt, wofür er zuständig ist. Aus TIA Portal lässt sich die Struktur exportieren; der Satz kommt von Hand dazu.
• Symbol- und Variablentabelle, vollständig kommentiert. Das ist der Teil, dessen Fehlen später am meisten weh tut: Ein Online-Abzug ohne Symbolik ist praktisch unlesbar.
• Betriebsartenkonzept: Hand, Automatik, Einrichten, Störung – und die erlaubten Übergänge dazwischen. Am besten als Zustandsdiagramm, nicht als Fließtext.
• Schnittstellenbeschreibung: Welche Daten gehen zur Visualisierung, zum überlagerten System, zum Nachbaraggregat? Bei OPC UA gehört die Namensraum-Struktur dazu.
• Alarmliste mit Nummer, Text, Ursache und – wichtiger als alles andere – Behebungshinweis. Ein Alarm „Störung Antrieb 3" ohne Hinweis, was zu tun ist, ist ein halber Alarm.

2.3.Ebene 3: Die Anlagenakte – was den Betreiber betrifft

Diese Ebene beantwortet: Was muss der Betrieb wissen, ohne TIA Portal zu öffnen?

• Hardwarekonfiguration: CPU-Typ, Firmwarestand, Baugruppen mit Bestellnummern, Adressbelegung, Netzwerktopologie mit IP-Adressen und PROFINET-Gerätenamen.
• Sicherheitsdokumentation: Bei Failsafe-Programmen der Nachweis nach EN ISO 13849 beziehungsweise IEC 62061 – Sicherheitsfunktionen, erreichter Performance Level, F-Parameter, Prüfprotokolle. Das ist keine Kür, sondern Teil der CE-Konformität.
• Backup-Stände: Archiviertes Projekt mit Datum, Anlagenzustand und Verantwortlichem. Ein Backup ohne Datum ist Datenmüll.
• Wiederanlaufbeschreibung: Was ist nach Spannungsausfall zu tun? Diese eine Seite wird häufiger gelesen als der gesamte Rest.

3.Übergabe-Checkliste zum Abhaken

Wenn eine Anlage übergeben wird, entscheidet diese Liste darüber, ob der Betreiber morgen selbst arbeiten kann. Ich gehe sie bei jeder Inbetriebnahme durch:

4.Dokumentation aktuell halten

Eine Dokumentation, die nur zur Abnahme stimmt, ist eine Momentaufnahme. Damit sie mitwächst, braucht es zwei Dinge – und beide sind organisatorisch, nicht technisch.

Erstens: Versionierung. Jede Änderung am Projekt bekommt einen Stand und einen Grund. Wer TIA Openness einsetzt, kann Projekte in ein textbasiertes Format exportieren und damit tatsächlich in Git versionieren – dann ist die Änderungshistorie kein gepflegter Kommentarblock mehr, sondern ergibt sich aus den Commits.

Zweitens: Änderungen dokumentieren, solange man noch weiß, warum. Die Nachtschicht-Änderung, die „nur mal schnell" gemacht wurde, ist der klassische Anfang einer Doku-Divergenz. Ein datierter Zweizeiler im Baustein-Kopf kostet zwei Minuten und rettet den nächsten Kollegen.

Ein praktischer Zwischenschritt: Der Online-/Offline-Vergleich im TIA Portal zeigt, ob die Anlage noch dem dokumentierten Stand entspricht. Wer ihn vor jedem größeren Eingriff einmal laufen lässt, findet undokumentierte Änderungen, bevor sie zum Problem werden.

5.Wenn nur noch ein Online-Abzug existiert

Der häufigste Fall in der Praxis – und der Grund, warum Retrofit-Projekte teurer werden als geplant: Das Originalprojekt ist verschwunden. Was bleibt, ist ein Abzug aus der laufenden CPU, ohne Symbolik, ohne Kommentare, mit absoluten Adressen.

Das ist kein hoffnungsloser Fall, aber ein aufwendiger. Das Vorgehen, das sich bei mir bewährt hat:

1. Abzug sichern, bevor irgendetwas anderes passiert. Ein zweites Backup auf getrenntem Medium. Der Zustand, den Sie vorfinden, ist unter Umständen die einzige verbliebene Quelle.
2. Peripherie zuerst. Ein- und Ausgänge lassen sich über Schaltplan, Klemmenplan und die Anlage selbst zuordnen. Das ist mühsam, aber eindeutig – und der Anker für alles Weitere.
3. Von den Aktoren rückwärts. Nehmen Sie einen Ausgang, verfolgen Sie über Querverweise, welche Bedingungen ihn setzen. So entsteht Baustein für Baustein ein Bild der Logik.
4. Benennen, sobald verstanden. Jede erkannte Variable bekommt sofort einen sprechenden Namen und einen Kommentar mit dem Beleg. Wer das aufschiebt, macht die Arbeit zweimal.
5. Gegen die Anlage prüfen. Was Sie zu verstehen glauben, muss sich im Betrieb bestätigen. Beobachtungstabellen zeigen, ob Ihre Annahme trägt.

Das Ergebnis einer solchen Rekonstruktion ist mehr als ein lesbares Projekt: Es ist die Grundlage dafür, dass die nächste Erweiterung wieder kalkulierbar wird.

6.Fazit

SPS-Dokumentation ist keine Fleißaufgabe am Projektende, sondern die Bedingung dafür, dass eine Anlage über ihren Lebenszyklus wartbar bleibt. Drei Dinge tragen den größten Teil des Nutzens:

• Kommentare, die das Warum festhalten – besonders bei Zahlen, die willkürlich aussehen.
• Eine vollständige, kommentierte Symbolik – der Unterschied zwischen einem lesbaren und einem toten Projekt.
• Eine Alarmliste mit Behebungshinweisen – das Dokument, das im Störfall tatsächlich gelesen wird.

Wer diese drei Punkte konsequent bedient, hat mehr erreicht als mit einem 200-seitigen Handbuch, das niemand öffnet.

7.Weiterführende Artikel

• SPS-Programmierung: 8 Best Practices für sauberen, wartbaren Code – die Grundlagen, auf denen jede Dokumentation aufbaut
• Fehlersuche in SPS-Programmen: systematisch eingrenzen – wo sich gute Dokumentation im Störfall auszahlt
• Die 5 SPS-Programmiersprachen nach IEC 61131-3 – welche Sprache welche Dokumentationslast erzeugt