Technik erklärt

SPS-Programm Struktur — Best Practices für wartbare Logik

Wie SPS-Programme so aufgebaut werden, dass sie nicht nur laufen, sondern auch später noch verstanden, erweitert und diagnostiziert werden können.

Start → Artikel → SPS-Programm Struktur

Von Daniel M. Hochwieser

Viele SPS-Programme funktionieren anfangs irgendwie — bis die erste größere Änderung kommt, eine Störung schneller eingegrenzt werden muss oder jemand anderes das Projekt übernehmen soll. Dann zeigt sich, ob die Logik nur „zum Laufen gebracht“ wurde oder ob sie wirklich sauber strukturiert ist.

Gute SPS-Programmstruktur ist kein akademischer Luxus. Sie entscheidet darüber, wie gut eine Anlage wartbar bleibt, wie schnell Fehler gefunden werden und wie sicher spätere Erweiterungen möglich sind.

Anzeige

1) Warum Struktur in SPS-Projekten so wichtig ist

In kleinen Testprojekten fällt schlechte Struktur oft kaum auf. In realen Anlagen dagegen sammeln sich schnell:

Ohne klare Struktur wird aus Logik schnell ein Geflecht von Bedingungen, das zwar vielleicht heute noch läuft, aber morgen niemand mehr sauber ändern will.

Grundlage: SPS programmieren lernen · Was ist eine SPS?

2) Das Ziel ist nicht „kompakt“, sondern nachvollziehbar

Ein häufiger Fehler ist die Vorstellung, gute SPS-Programme müssten möglichst kurz oder clever sein. In der Praxis ist oft das Gegenteil richtig:

Ein etwas längeres, aber sauberes Programm ist in industriellen Projekten oft deutlich wertvoller als eine kurze, schwer lesbare Lösung.

3) Ein bewährter Grundaufbau für SPS-Programme

In vielen Projekten hat sich eine klare Trennung in Funktionsbereiche bewährt. Ein praktisches Muster sieht so aus:

Signale aufbereiten

Eingänge filtern, plausibilisieren, skalieren und auf stabile interne Signale bringen.

Freigaben bilden

Alle Bedingungen bündeln, die für einen sicheren Ablauf erfüllt sein müssen.

Zustände / Sequenzen

Abläufe in klare Schritte oder Betriebszustände aufteilen.

Ausgänge ansteuern

Aktoren möglichst gesammelt und nachvollziehbar setzen.

Diese Trennung ist nicht die einzige mögliche Struktur, aber sie schafft Ordnung und reduziert Seiteneffekte.

4) Signale zuerst intern sauber machen

Rohsignale aus der Anlage sollten nicht ungefiltert an jeder Stelle im Programm verwendet werden. Besser ist es, zuerst stabile interne Zustände oder Hilfssignale zu bilden.

Wer das nicht trennt, baut Diagnoseprobleme direkt in die Logik ein. Dann ist später oft unklar, ob das Problem im Sensor, in der Auswertung oder in der eigentlichen Funktion liegt.

Passend dazu: Sensoren und Aktoren · Störungsdiagnose — Denkmodell

5) Freigaben und Verriegelungen zentral statt verstreut

Eine der wichtigsten Best Practices ist: Freigaben nicht überall einzeln prüfen, sondern zentral bilden.

Typische Freigabebedingungen sind zum Beispiel:

Wenn diese Bedingungen an fünf Stellen einzeln eingebaut werden, wird das Projekt schnell inkonsistent. Besser ist ein klar benanntes internes Freigabebit oder ein sauber strukturierter Block.

6) Zustände und Sequenzen klar modellieren

Größere Abläufe sollten nicht aus verstreuten Einzelfall-Abfragen bestehen. Wartbarer ist meist ein Zustands- oder Schrittmodell:

Damit wird der Ablauf nicht nur klarer, sondern auch leichter testbar. Gerade in der Inbetriebnahme hilft ein sauberer Zustandsaufbau enorm.

7) Diagnose von Anfang an mitbauen

Viele Projekte sind logisch gerade noch lesbar, aber diagnostisch schwach. Das rächt sich spätestens bei Störungen.

Gute Struktur bedeutet auch:

Eine Anlage, die zwar läuft, aber im Fehlerfall nichts erklärt, ist kein gut strukturiertes Projekt.

Weiterführend: SCADA und HMI · TIA Portal typische Fehler

8) Bausteine nach Funktion statt nach Zufall gliedern

Funktionsbausteine sollten ein erkennbares Ziel haben. Schlechte Projekte entstehen oft, wenn Bausteine eher historisch als logisch wachsen.

Bewährte Gliederung kann zum Beispiel sein:

Wichtig ist weniger das konkrete Schema als die Frage: Erkennt ein anderer Leser schnell, wo welche Funktion zu finden ist?

9) Namen so wählen, dass sie später noch helfen

Schlechte Variablennamen und kryptische Abkürzungen machen selbst saubere Logik unnötig schwer verständlich. Gute Benennung ist deshalb Teil der Programmstruktur.

Gerade bei HMI, Diagnose und Teamarbeit spart das später viel Zeit.

10) Sprache bewusst wählen: KOP, FUP oder ST?

Gute Struktur hängt nicht nur vom Inhalt, sondern auch von der Darstellungsform ab. Manche Logik ist in KOP leicht verständlich, andere wird in FUP klarer und manche Teile lassen sich in ST deutlich besser ausdrücken.

Wichtig ist, die Sprache nicht nach persönlicher Vorliebe allein zu wählen, sondern nach Wartbarkeit, Teamverständnis und Funktionscharakter.

Siehe auch: SPS-Programmiersprachen erklärt · TIA Portal erklärt

11) Typische Strukturfehler in SPS-Projekten

Das Ergebnis ist fast immer gleich: Änderungen werden riskanter, Fehlersuche dauert länger und Vertrauen in das Projekt sinkt.

12) Fazit

Gute SPS-Programmstruktur bedeutet nicht, möglichst elegant oder kompakt zu wirken. Sie bedeutet, dass die Logik auch unter Druck, im Fehlerfall und nach Monaten noch verständlich, erweiterbar und diagnostizierbar bleibt.

Wer Programme sauber gliedert, Freigaben bündelt, Zustände klar modelliert und Diagnose von Anfang an mitdenkt, baut nicht nur bessere Software — sondern robustere Anlagen.

Weiterführend

Stand: