Debugging als Zusammenspiel von System und Instinkt

Die Inbetriebnahme läuft, die Produktion steht in den Startlöchern – und plötzlich verweigert die SPS den RUN-Modus. Keine klare Meldung, keine Codeänderung, aber Stillstand. In solchen Momenten zeigt sich, was Automatisierung wirklich ist: Debugging ist nicht „Programm prüfen“, sondern das schnelle Verstehen eines mechatronischen Gesamtsystems.

Mehr als Code: Warum Automatisierungs-Debugging so anspruchsvoll ist

Moderne Anlagen sind ein Verbund aus Mechanik, Elektrik, Antrieben, Feldbus, Safety und Steuerungslogik. Viele Störungen entstehen außerhalb des SPS-Programms: Sensorik liefert unplausible Signale, Rückmeldungen bleiben aus, Spannungsversorgung kippt, Parametergrenzen werden erreicht. 

In vielen Fällen steckt der Auslöser in der Peripherie – Sensor, Aktor, Versorgung oder Parametrierung. Wer nur im Code sucht, sieht oft nicht, was das System tatsächlich „erlebt“. Deshalb umfasst Debugging in der Praxis auch Dinge, die man nicht im Lastenheft sieht: Verdrahtungsfehler erkennen, elektrische Grenzfälle messen oder mechanische Klemmstellen finden.

„Als SPS-Programmierer sind wir primär Ingenieure, die Probleme lösen“, sagt Adin Softic, Abteilungsleiter bei Masterwerk. „Wir werden nicht nur geholt, um etwas nach Plan umzusetzen – sondern um zum richtigen finalen Ergebnis zu kommen. Und Herausforderungen auf dem Weg dorthin sind normal.“

Kompakte Expertenteams: Weniger Köpfe, mehr Wirkung

Gerade im Krisenmodus gewinnt selten das größte Team – sondern das richtige Setup: wenige Personen mit klaren Rollen (Automatisierung, Elektrik, Mechanik), die Messung, Hypothese und Test ohne Reibungsverluste zusammenbringen.

„Sag mir, was du brauchst – ich messe es dir sofort“, ist in solchen Situationen mehr wert als jede zusätzliche Abstimmungsrunde. Dazu kommt der menschliche Faktor: Wer ruhig bleibt, sauber kommuniziert und den Raum für klare Entscheidungen hält, verkürzt Stillstände messbar.

Intuition ist dabei kein „Bauchgefühl“ im luftleeren Raum, sondern trainiertes Mustererkennen: Man erkennt typische Fehlerbilder – und prüft sie dann konsequent. Ein Junior liest oft länger im Code, ein Senior sucht schneller die Messung, die eine Hypothese wirklich falsifiziert.

Fall 1: Die stumme Steuerung – SPS will nicht in RUN

Kurz vor Produktionsstart einer Fertigungslinie weigerte sich die SPS, in RUN zu wechseln. Keine neue Version, die Anlage hatte zuvor bereits gearbeitet. Klassische Schritte (Diagnosepuffer, Safety-Status, Bus-Teilnehmer, Spannungsversorgung) lieferten keinen eindeutigen Hinweis.

Der Durchbruch kam über systematische Isolation: Programmteile wurden sukzessive deaktiviert, sodass nur Teilfunktionen liefen. Von „oben nach unten“ wurde der problematische Pfad eingegrenzt – bis eine einzelne Funktion übrig blieb. Überraschend: ein Standardbaustein des Herstellers für die Kommunikation zum übergeordneten System. Das Verhalten passte weniger zu einem Logikfehler als zu einem Zustandsproblem: ein interner Speichermechanismus hatte sich „verhakt“. Nach gezieltem Reset der betroffenen Instanz-/Speicherzustände lief die Anlage wieder stabil. Gesamtdauer: rund eineinhalb Stunden.

„Ohne die Bereitschaft, über den eigenen Code hinauszudenken, hätten wir tagelang gesucht“, so Babajic. Lehre: Black Boxes (Herstellerbausteine, Drives, Bus-Teilnehmer) sind Teil des Systems – und müssen als Hypothese erlaubt sein, wenn die Symptome dazu passen.

Fall 2: Das Fahrzeug, das sich selbst abschaltete

Ein fahrerloses Transportsystem zeigte sporadische Ausfälle: Bremsung, Abschaltung, Antriebe in Störung. Softwareseitig war nichts Reproduzierbares zu finden, Einzeltests bestanden. Die übliche Falle: Man optimiert Sequenzen, obwohl die Ursache physikalisch ist.

Ein Kollege wechselte die Ebene und schaute auf Strom- und Spannungsverläufe im Betrieb. Ergebnis: Das Fahrzeug arbeitete nahe an der Leistungsgrenze. Bei einer bestimmten Aktion – dem Absenken über die Hub-Einheit – wurde Energie regenerativ zurückgespeist.

Der kurzzeitige Spannungsanstieg überschritt Grenzwerte, Schutzabschaltungen griffen, das Bordnetz wurde instabil. Die Lösung lag nicht in einem Softwarefix, sondern in der Stabilisierung des Energiepfads (Dimensionierung/Pufferung) und einer passenden Parametrierung der Antriebe, damit Rekuperation nicht zur Abschaltung führt.

„Der Moment, in dem wir die Kurve gesehen haben, war’s“, sagt der Kollege. Lehre: Wenn Fehler nur bei bestimmten Bewegungen auftreten, lohnt sich der Blick auf Physik und Energie – nicht nur auf Logik und Sequenzen.

Was das für Einkauf und Produktion bedeutet

Stillstand kostet – direkt durch Produktionsausfall und indirekt durch Folgeschäden (Termine, Qualität, Eskalationen). Für Einkauf und Produktion ist Debugging-Kompetenz deshalb ein echter TCO-Faktor: Testbarkeit, transparente Diagnosen, saubere Schnittstellen, robuste Komponenten und erreichbarer Support entscheiden darüber, wie schnell eine Anlage wieder stabil läuft. Bei der Partnerwahl lohnt sich der Blick auf Praxisnachweise: Wer kann konkrete Fälle erklären – inklusive Irrwegen, Messungen und einer nachvollziehbaren, wiederholbaren Vorgehensweise?