Eine kleine Anpassung am SPS‑Programm, ein zusätzlicher Sensor oder eine minimale Ablaufänderung und plötzlich steht die Anlage.

Die Fehlersuche dauert Stunden, niemand möchte das Programm anfassen, und selbst erfahrene Instandhalter arbeiten sich mühsam durch lange Netzwerke und unklare Merker.

In der Praxis liegt die Ursache für solche Stillstände selten an der Hardware. Viel häufiger sind es unübersichtliche SPS‑Programme, die über Jahre hinweg erweitert, angepasst und unter Zeitdruck verändert wurden. Was ursprünglich funktionierte, wird zunehmend schwer wartbar, mit direkten Folgen für Verfügbarkeit und Kosten.

Dieser Artikel zeigt, warum schlecht strukturierte SPS‑Programme ein erhebliches Stillstands Risiko darstellen. Woran man sie erkennt und wie eine saubere Strukturierung dabei hilft, Anlagen stabil und wartbar zu halten.

Warum unübersichtliche SPS‑Programme zu Stillständen führen

Unübersichtliche SPS‑Programme entstehen selten aus mangelnder Fachkenntnis. In den meisten Fällen sind sie das Ergebnis von Zeitdruck, häufigen Erweiterungen und wechselnden Bearbeitern.

Ein zentraler Punkt ist die fehlende Vorhersehbarkeit von Änderungen. Wird eine Kleinigkeit angepasst, ist oft nicht klar, welche Programmteile davon indirekt betroffen sind. Mit der Folge, dass sich Fehler an völlig unerwarteten Stellen zeigen. Das kann so weit gehen, dass sich Mitarbeiter nicht mehr zutrauen Änderungen an der Anlage vorzunehmen, aus Angst einen unvorhersehbaren Stillstand auszulösen.

Hinzu kommt die erschwerte Fehlersuche im Störfall. Ohne klare Strukturierung kostet es wertvolle Zeit relevante Signale und Bedingungen überhaupt zu finden. Währenddessen steht die Anlage still oder läuft nur eingeschränkt.

Ein weiteres Risiko ist die Abhängigkeit von einzelnen Personen. Häufig kennt nur noch ein Mitarbeiter die „Logik hinter dem Programm“. Fällt diese Person aus oder steht nicht zur Verfügung, wird jede Änderung zum Risiko. Externe Unterstützung bei der SPS-Programmierung ist zwar möglich, benötigt aber unnötig viel Einarbeitungszeit.

All diese Punkte haben eines gemeinsam:

Nicht die Komplexität der Anlage führt zu Stillständen, sondern die fehlende Struktur im SPS‑Programm. Je unübersichtlicher der Code, desto höher das Risiko, dass aus kleinen Maßnahmen große Produktionsprobleme entstehen.

Typische Ursachen unübersichtlicher SPS‑Programme

Unübersichtliche SPS‑Programme entstehen selten bewusst. In nahezu allen Projekten sind sie das Ergebnis organisatorischer und zeitlicher Rahmenbedingungen oder mangelnder Erfahrung. Die folgenden Ursachen treten in der Praxis besonders häufig auf.

Fehlende oder unzureichende Modularisierung des SPS-Programms

Es gibt tatsächlich SPS-Programme von laufenden Produktionsanlagen, in denen ein Großteil des Codes im OB1 geschrieben ist. Wenn der Code nun außerdem nicht in sinnvolle Netzwerke bzw. Regionen mit aussagekräftigen Kommentaren gegliedert ist, dann ist das Chaos perfekt.

Solche Programme bringen bei jeder Änderung oder Fehlersuche unnötig lange Stillstandszeiten der Anlage mit sich. Die Suche nach der richtigen Stelle im Code dauert viel länger als die Änderung und der anschließende Testlauf.

Unklare Variablen Namen

Oft werden Namen für Variablen (z.B. Ein- und Ausgänge) nach „Gefühl“ vergeben.

Typisches Beispiel:

Eine Anlage hat ein Transportband in U-Form mit mehreren Bearbeitungsstationen. Es sind Sensoren sowohl links, rechts, vor und nach den Bearbeitungsstationen vom Transportband vorhanden. Diese Sensoren werden dann z.B. mit „E_Band_1_rechts_vorn“ oder „E_Band_2_links_hinten“ bezeichnet.

Ein paar Wochen nach der Inbetriebnahme und Produktionsstart kann niemand den Variablen den richtigen Sensor zuordnen. Denn bezieht sich nun „rechts“ und „hinten“ auf die Transportrichtung des Bandes oder vom Standort des HMI auf die Anlage gesehen?

Bei jeder Änderung oder Störungsbehebung geht die Suche nach dem richtigen Sensor wieder von vorne los.

Vermischung von Hand‑ und Automatik Funktionen

Ein häufiges Praxisproblem ist die fehlende Trennung von Betriebsarten. Handbedienung und Automatikabläufe greifen direkt ineinander. Dadurch kann sich die Anlage nach Störungen unvorhersehbar verhalten und der Bediener muss bestimmte Eingriffe „in der richtigen Reihenfolge“ ausführen, um die Anlage wieder in Betrieb zu setzen.

Im Störfall muss nachvollziehbar sein, welchen Zustand die Anlage hat und wie dieser behandelt werden muss.

Kommentare ohne echten Mehrwert

Kommentare sind oft vorhanden, helfen aber nicht weiter, weil sie nur offensichtliche Aktionen beschreiben oder veraltet sind.

Typisches Beispiel:

Auf einer Anlage werden über eine Rezeptverwaltung Teile mit verschiedenen Längen gefahren (z.B. 1m, 2m und 6m). In einer Schrittkette werden im Falle der 6m Teile mehrere Schritte übersprungen. Der Kommentar lautet: „bei 6m überspringen“. Was passiert nun, wenn ein neues 5m Teil eingefügt wird, müssen diese Schritte dann auch übersprungen werden?

Ein guter Kommentar nennt den Grund für das Überspringen der Schritte und beschreibt nicht den offensichtlichen Zustand.

Umbauten im laufenden Betrieb ohne strukturelle Nacharbeit

Bei laufender Produktion müssen Anpassungen schnell erfolgen. Es gilt meist Funktion vor Struktur und die Dokumentation wird verschoben.

Typischer Verlauf:

1. schnelle Anpassung unter Zeitdruck
2. Anlage läuft wieder
3. Neue Variablen oder Schritte bleiben ohne sinnvolle Namen oder Kommentare
4. nächste Anpassung wird noch schwieriger

Das Programm wird nach jeder dieser schnellen Änderungen unübersichtlicher und unnötig komplizierter.

Zwischenfazit

Keine dieser Ursachen ist ungewöhnlich.

Im Gegenteil sie spiegeln den realen Alltag in vielen Fabriken wider. Kritisch wird es erst dann, wenn diese Punkte dauerhaft bestehen bleiben. Denn dann wächst das Stillstands Risiko nicht sprunghaft, sondern kontinuierlich mit jeder Erweiterung.

Woran man ein schlecht strukturiertes SPS‑Programm erkennt

In vielen Projekten ist allen Beteiligten bewusst, dass das SPS‑Programm „nicht ideal“ aufgebaut ist. Schwieriger ist es objektiv zu bewerten, wann die Struktur tatsächlich zum Risiko wird. Die folgenden Anzeichen sind in der Praxis klare Warnsignale.

Kleine Änderungen haben große Auswirkungen

Wenn selbst einfache Anpassungen dazu führen, dass unerwartete Störungen auftreten, Abläufe an anderer Stelle nicht mehr funktionieren oder „Respekt vor dem Download“ von Änderungen herrscht. Dann ist das ein starkes Indiz dafür, dass der modulare Aufbau des Programms schlecht ist.

Die Fehlersuche dauert länger als der eigentliche Ausfall

Wenn viel Zeit benötigt wird, um relevante Programmstellen zu finden, mehrere Personen gleichzeitig im Code suchen oder im Störfall „auf Verdacht“ Signale manipuliert werden, dann ist das ein klares Warnzeichen.

In gut strukturierten Programmen ist in 15min klar, wo ein Fehler entsteht, warum der Zustand erreicht wurde und welcher Baustein verantwortlich ist.

Fehlt diese Transparenz, liegt das Problem meist nicht im Prozess, sondern im Programmaufbau.

Niemand fühlt sich zuständig

Typisch ist die Aussage: „Da sollte man besser nichts anfassen.“

Wenn nur einzelne Personen Änderungen durchführen können oder wollen, entsteht eine gefährliche Abhängigkeit. Urlaub, Krankheit oder Personalwechsel werden dann schnell zum operativen Risiko. Ein wartbares SPS‑Programm darf nicht vom impliziten Wissen Einzelner leben.

Neue Mitarbeiter brauchen unverhältnismäßig lange zur Einarbeitung

Sollten neue Kollegen oder externe Dienstleister mehrere Tage benötigen, um Grundlogik zu verstehen. Sie ständig Rückfragen stellen müssen oder sich nur langsam an Änderungen heranwagen. Dann ist das selten ein Kompetenzproblem, sondern meist ein strukturelles Problem.

Ein sauber aufgebautes SPS‑Programm erklärt sich in großen Teilen selbst.

Zwischenfazit

Je mehr dieser Punkte zutreffen, desto größer ist die Wahrscheinlichkeit, dass die SPS‑Struktur selbst zum Verursacher des Stillstands wird. Spätestens dann sollte das Thema nicht mehr als „schönes Extra“, sondern als betriebliche Notwendigkeit betrachtet werden.

Wie eine saubere Strukturierung von SPS‑Programmen Stillstände reduziert

Eine klare und durchdachte Struktur im SPS‑Programm ist kein Selbstzweck. Sie sorgt vor allem dafür, dass Anlagen vorhersehbar reagieren, Störungen schneller analysiert werden können und Änderungen kontrolliert umsetzbar bleiben. Gerade bei Anpassungen im laufenden Betrieb ist das ein entscheidender Vorteil.

Im Kern geht es darum, Komplexität nicht zu vermeiden, sondern beherrschbar zu machen.

Aufteilung der Anlage in Funktionseinheiten

Die Basis für ein gut strukturiertes SPS ist die Aufteilung in Funktionseinheiten. Dabei sollten zwei Regeln befolgt werden.

1. Jeder Teil der Anlage, der im Automatikbetrieb unabhängig arbeiten kann/muss, ist eine eigene Funktionseinheit
2. Sich wiederholende Anlagenteile sind eigene Funktionseinheiten

Bei Störungen in einem bestimmten Teil der Anlage, lässt sich der zugehörige Code schnell und einfach finden.

Gliederung des Codes nach Aufgaben

Ein gut strukturiertes SPS‑Programm trennt die Bausteine zunächst in Gruppen. Diese können wie folgt aussehen:

• System
• Handbetrieb
• Visualisierung
• Automatik
• Grundstellung
• Hardware
• Sicherheit

Jeder Baustein hat eine klar definierte Aufgabe und wird einer dieser Gruppen zugeteilt. Dadurch kann die folgende Struktur entstehen:

• System
  • Typdaten
  • Stationsdaten
  • Betriebsarten Steuerung
  • Anzeige/Ampel
  • Etc.
• Handbetrieb
  • Funktionseinheit 1
  • Funktionseinheit 2
  • Etc.
• Visualisierung
  • HMI 1
  • HMI 2
  • Etc.
• Automatik
  • Ablauf Funktionseinheit 1
  • Ablauf Funktionseinheit 2
  • Etc.
• Grundstellung
  • Grundstellung Funktionseinheit 1
  • Grundstellung Funktionseinheit 2
  • Etc.
• Hardware
  • Ventile
  • Antriebe
  • Roboter
  • Etc.
• Sicherheit
  • Not Aus
  • Schutzkreis
  • Etc.

Statt „alles hängt zusammen“ entsteht ein System, das verständlich und kontrollierbar ist. Änderungen eines Bausteins betreffen nur den entsprechenden Bereich. Auftretende Fehler lassen sich deutlich schneller eingrenzen und diagnostizieren.

Einheitliche Namenskonventionen und Strukturen

Ein oft unterschätzter, aber sehr wirkungsvoller Punkt ist Konsistenz in der Namenskonvention. Aussagekräftige Signalnamen und eine klar definierte Struktur für Bausteine im gesamten Projekt sind ein Gamechanger für den langfristigen, störungsarmen Betrieb einer Anlage.

Neue Mitarbeiter finden sich so schneller zurecht, externe Unterstützung ist sofort arbeitsfähig und Missverständnisse werden reduziert. Dadurch spart man Zeit und Kosten.

Kommentare mit echtem Mehrwert

Gute Kommentare sind nicht umfangreich, sondern zielgerichtet. Sie geben genau die Informationen, die im Störfall fehlen.

• Warum existiert dieser Programmteil?
• Welche Bedingungen sind entscheidend?
• Was darf verändert werden und was nicht?

Gute Kommentare ermöglichen schnellere Fehlersuchen und reduzieren das Auftreten neuer Störungen nach Programmanpassungen.

Zwischenfazit

Saubere SPS‑Strukturen führen nicht dazu, dass ein Programm „einfacher“ wird, sondern dass ein wachsender Code trotzdem beherrschbar bleibt.

Der entscheidende Unterschied zeigt sich im Alltag. Störungen werden schneller behoben und Änderungen sind planbar.

Und genau dadurch sinkt letztlich das, was im Betrieb am meisten kostet:

ungeplante Stillstände.

Wann externe Unterstützung bei der SPS‑Programmierung sinnvoll ist

In vielen Unternehmen wird versucht, Anpassungen und Optimierungen von SPS‑Programmen vollständig intern abzudecken. Das ist grundsätzlich sinnvoll, stößt jedoch in der Praxis häufig an Grenzen, insbesondere bei laufender Produktion.

Externe Unterstützung bei der SPS-Programmierung wird vor allem dann sinnvoll, wenn sich strukturelle Probleme wiederholt auf den Betrieb auswirken oder intern nicht mehr effizient bearbeitet werden können.

Häufige Warnzeichen aus der Praxis

• Wiederkehrende Stillstände ohne klare Ursache
• Änderungen werden zunehmend riskant
• Fehlende Kapazitäten im eigenen Team
• Abhängigkeit von Einzelpersonen

Vorteil externer Unterstützung

Ein externer Dienstleister bringt:

• einen neutralen Blick von außen
• Erfahrung aus vergleichbaren Projekten
• strukturierte Vorgehensweisen für Analyse und Umsetzung

Dabei geht es in der Praxis selten darum, bestehende SPS-Programme vollständig zu ersetzen. Stattdessen sollten sie gezielt stabilisiert und strukturiert werden. Dadurch verbessert sich die Wartbarkeit von Anlagen langfristig.

Außerdem können externe Spezialisten dabei helfen eigene Strukturen in SPS-Programmen aufzubauen, die dann deutlich einfacher erweitert werden können.

Einordnung

Externe Unterstützung ist kein Ersatz für internes Know‑how, sondern eine Ergänzung an den entscheidenden Stellen. Bei komplexen Problemen, strukturellen Schwächen oder begrenzten Ressourcen, sollte über externe Unterstützung nachgedacht werden.

Der größte Nutzen entsteht meist dann, wenn nicht erst bei akuten Stillständen reagiert wird.

Fazit: Struktur entscheidet über Stabilität nicht nur Technik

Unübersichtliche SPS‑Programme entstehen nicht über Nacht und sie sind selten das Ergebnis schlechter Arbeit. In den meisten Fällen spiegeln sie die Realität vieler Produktionsbetriebe wider:

• Zeitdruck
• laufende Anpassungen
• historisch gewachsene Anlagen

Wenn Störungen schwer nachvollziehbar werden, Änderungen unvorhersehbare Auswirkungen haben und wertvolle Zeit bei der Fehlersuche verloren geht. Dann wird deutlich, dass nicht die Anlage an ihre Grenzen stößt, sondern die Struktur des SPS-Programms.

Eine saubere und durchdachte Programmstruktur sorgt nicht dafür, dass eine Anlage „einfacher“ wird. Sie sorgt dafür, dass sie beherrschbar bleibt.

Der nächste Schritt

Wenn sich mehrere der beschriebenen Punkte in Ihren Anlagen wiederfinden, lohnt es sich, die bestehende Struktur gezielt zu hinterfragen. Häufig lassen sich bereits mit überschaubarem Aufwand deutliche Verbesserungen erzielen, insbesondere bei Stillstandszeiten und Wartbarkeit.

Wenn Sie Unterstützung bei der SPS Programmierung benötigen oder Ihre SPS‑Programme strukturell verbessern möchten, sprechen Sie mich gerne an.