Eine Störung im vernetzten System Ende zu Ende eingrenzen

Wenn der Bildschirm grün zeigt, aber die Kiste stehen bleibt

Die Nordlicht Abfülltechnik GmbH füllt Reinigungsmittel in Mehrwegbehälter. Am Ende der Linie erkennt die Lichtschranke LS-17, ob ein Behälter die Prüfposition erreicht. Eine lokale Steuerung übergibt das Ereignis an das Edge-Gateway EG-2. Das Gateway veröffentlicht den Zustand an eine Anwendung, die den Auftrag protokolliert und das Freigabesignal für den Ausschleuser anfordert.

Seit 14:18 Uhr tritt ein Fehler auf: Ein Behälter steht vor der Lichtschranke, die Bedienoberfläche zeigt aber weiterhin “Prüfposition frei”. Der Ausschleuser bewegt sich deshalb nicht. Die Anlage wurde nach der betrieblichen Vorgabe in einen sicheren Halt versetzt. Andere Linien arbeiten weiter.

Das ist keine reine Netzwerkstörung. Mehrere technische Welten greifen ineinander:

• Der Sensor nimmt einen physischen Zustand auf.
• Die lokale Steuerung verarbeitet das elektrische Signal.
• Das Edge-Gateway verbindet die lokale Betriebstechnik mit dem Datennetz.
• Ein Nachrichtendienst transportiert die Information.
• Die Anwendung ordnet sie einem Auftrag zu und zeigt einen Zustand an.
• Der Aktor setzt eine freigegebene Aktion in Bewegung um.

Die Grundidee dieser Lektion lautet: Du diagnostizierst den vollständigen Signalweg, indem du für jeden Übergang einen erwarteten Zustand und einen beobachtbaren Befund festlegst. So findest du nicht nur eine auffällige Stelle. Du belegst, an welchem Übergang die Information verloren geht oder verändert wird.

Du solltest bereits wissen, welche Aufgaben IP-Adresse, Switch und Gateway in einem Netzwerk übernehmen. Die allgemeine Diagnose von Link, IP-Konfiguration, Routing und Namensauflösung behandelt die Lektion “Netzwerkfehler mit Befunden systematisch diagnostizieren”. Die Plausibilität einzelner Messwerte und Ersatzwertstrategien gehören zur Lektion “Fehlerhafte Sensordaten erkennen und sicher behandeln”. Hier verbindest du beide Seiten zu einer Ende-zu-Ende-Diagnose.

Zerlege den Signalweg in Übergänge

Ein Systembild hilft nur, wenn es zu prüfbaren Fragen führt. Für die Linie von Nordlicht sind sechs Übergänge relevant.

Für jeden Übergang stellst du dieselben vier Fragen:

1. Was kommt hinein? Zum Beispiel ein elektrischer Eingang oder eine Nachricht.
2. Was soll herauskommen? Zum Beispiel der logische Zustand belegt.
3. Wo kann ich das beobachten? Zum Beispiel in der Steuerungsdiagnose oder im Gateway-Protokoll.
4. Welche Kennung verbindet die Beobachtung mit den anderen Stufen? Zum Beispiel Sensor-ID, Auftrags-ID oder Zeitstempel.

Diese Aufteilung grenzt die Suche besser ein als eine lange Werkzeugliste. Wenn die Steuerung den Sensorzustand korrekt sieht, brauchst du die physische Erfassung zunächst nicht weiter zu untersuchen. Wenn das Gateway das Ereignis protokolliert, aber der Nachrichtendienst es nicht annimmt, liegt die nächste Frage am Ausgang des Gateways oder am Übergang zum Dienst.

Verbinde Beobachtungen über Zustände und Zeit

Eine Uhrzeit allein reicht nicht immer. Uhren können abweichen, Protokolle können unterschiedliche Zeitzonen verwenden und Nachrichten können gepuffert werden. Verbinde Ereignisse deshalb über mehrere Merkmale:

• Komponentenkennung: etwa LS-17 oder EG-2,
• fachliche Kennung: etwa Behälter B-8841 oder Auftrag A-2407,
• Zustand: etwa frei, belegt, angenommen oder verworfen,
• Zeitstempel mit Zeitzone: damit die zeitliche Reihenfolge vergleichbar bleibt,
• Sequenz- oder Ereignisnummer: wenn das System eine solche Nummer führt.

Für den Fehler um 14:18 Uhr liegen folgende gekürzte Ausgaben vor. Die Werte stammen aus dem neu erstellten Beispielszenario.

Lokale Steuerung, Linie 2
14:18:06.182+02:00  input=LS-17  raw=1  state=BELEGT  sequence=5812

Edge-Gateway EG-2
14:18:06.224+02:00  source=LS-17  state=BELEGT  sequence=5812
14:18:06.229+02:00  publish topic=linie/2/pruefposition result=REJECTED reason=SCHEMA

Nachrichtendienst
14:18:06.230+02:00  client=EG-2  topic=linie/2/pruefposition result=REJECTED

Auftragsanwendung
14:18:07.010+02:00  container=B-8841  station=LS-17  displayed_state=FREI

Die Ereignisnummer 5812 verbindet Steuerung und Gateway. Der Sensorzustand kommt damit bis zum Gateway. Der nächste Übergang scheitert: Gateway und Nachrichtendienst dokumentieren die Ablehnung derselben Veröffentlichung. Die Anwendung behält folgerichtig ihren vorherigen Zustand. Eine Störung im allgemeinen IP-Netz ist dadurch noch nicht unmöglich, aber für dieses Ereignis deutlich weniger plausibel. Der Dienst hat die Verbindung angenommen und eine fachliche Ablehnung mit dem Grund SCHEMA protokolliert.

Formuliere Hypothesen, die ein Test trennen kann

“Das Gateway ist kaputt” ist keine hilfreiche Hypothese. Die Aussage ist zu breit und sagt nicht, welches Ergebnis sie stützen würde. Aus dem Ablehnungsgrund SCHEMA lassen sich dagegen drei prüfbare Erklärungen ableiten:

1. Das Gateway sendet seit einer Änderung ein Feld in einem nicht erlaubten Format.
2. Der Nachrichtendienst verwendet eine neue Schemaversion, die das Gateway noch nicht unterstützt.
3. Die Protokollzeile gehört zu einem anderen Ereignis und wurde fälschlich mit dem Behälter verbunden.

Die dritte Erklärung wird durch die gemeinsame Quelle, Uhrzeit und Sequenznummer geschwächt. Zwischen den ersten beiden Hypothesen trennt ein Vergleich von aktiver Gateway-Konfiguration, gesendeter Nutzlast und freigegebener Schemaversion.

{
  "source": "LS-17",
  "sequence": 5812,
  "state": true,
  "observedAt": "2026-07-10T14:18:06.182+02:00"
}

Die freigegebene Schnittstellenbeschreibung erwartet für state den Textwert "occupied" oder "clear". Das Gateway sendet stattdessen den booleschen Wert true. Der Inhalt ist für einen Menschen nachvollziehbar, erfüllt aber den vereinbarten Datenvertrag nicht. Damit ist eine konkrete Abweichung belegt.

Plane den Test vom geringsten zum stärksten Eingriff

Ein guter Diagnoseschritt liefert möglichst viel Erkenntnis bei möglichst wenig Risiko. Im laufenden Betrieb bietet sich diese Reihenfolge an:

1. Vorhandene Anzeigen, Protokolle und Konfigurationen lesen.
2. Einen aufgezeichneten Datensatz außerhalb des Prozesspfads gegen das Schema validieren.
3. Eine freigegebene Testnachricht mit klarer Kennung über einen vorgesehenen Testweg senden.
4. Die Konfiguration kontrolliert ändern und die Änderung protokollieren.
5. Den ursprünglichen Ablauf in einem sicheren Anlagenzustand wiederholen.
6. Erst danach den Aktor unter den betrieblichen Schutzmaßnahmen prüfen, falls das Lernziel und die Freigabe das erfordern.

Für Nordlicht wird zunächst eine gespeicherte Nutzlast gegen die freigegebene Beschreibung geprüft. Der Fehler lässt sich außerhalb der Anlage reproduzieren. Danach wird in der Testumgebung des Nachrichtendienstes eine Nachricht mit "state": "occupied" angenommen. Diese beiden Befunde stützen die Hypothese eines falschen Feldformats.

Das Team spielt die bereits geprüfte Zuordnung auf EG-2 ein. Die Rückfallkonfiguration liegt bereit und die Änderung erhält eine eigene Vorgangsnummer. Erst danach folgt der freigegebene Funktionstest an der sicher stillgesetzten Linie.

14:42:10.104+02:00  Steuerung  LS-17=BELEGT sequence=5831
14:42:10.149+02:00  Gateway    state="occupied" sequence=5831 publish=ACCEPTED
14:42:10.173+02:00  Dienst     sequence=5831 delivered=YES
14:42:10.208+02:00  Anwendung  container=B-8849 displayed_state=BELEGT
14:42:12.006+02:00  Freigabe   actuator=AS-2 command=READY

Die gemeinsame Sequenznummer zeigt nun den vollständigen Weg. Der ursprüngliche Fehler ist nicht nur verschwunden. Die erwarteten Zustände sind an jedem Übergang sichtbar. Der Aktor wird erst nach der betrieblichen Freigabe separat bewegt. Die Lektion behauptet damit nicht, dass eine erfolgreiche Nachricht allein schon die mechanische Sicherheit der Anlage bestätigt.

Dokumentiere Befund statt Erzählung

Eine gute Befunddokumentation ermöglicht einer anderen Person, die Entscheidung nachzuvollziehen. Sie trennt Beobachtung, Schlussfolgerung und Änderung.

Vermeide Sätze wie “Gateway repariert”. Sie sagen weder, was falsch war, noch welcher Test die Wirkung gezeigt hat. Notiere auch verworfene Hypothesen knapp, wenn sie für eine spätere Störung wichtig sein können.

Übertrage das Vorgehen auf eine neue Anlage

Was du aus der Diagnose mitnimmst

Eine Ende-zu-Ende-Diagnose folgt nicht blind den Schichten eines allgemeinen Netzmodells. Sie folgt der beruflichen Wirkung: vom physischen Zustand über lokale Verarbeitung und Transport bis zur fachlichen Anzeige oder Aktion.

• Zerlege den Weg in beobachtbare Übergänge.
• Verbinde Protokolle über Kennungen, Zustände und vergleichbare Zeitstempel.
• Formuliere Hypothesen so, dass ein Test sie stützen oder schwächen kann.
• Beginne mit lesenden und vom Prozess getrennten Prüfungen.
• Ändere kontrolliert genau die Stelle, für die ein Soll-Ist-Unterschied belegt ist.
• Bestätige danach das ursprüngliche Verhalten über den vollständigen Signalweg.

Die Lektion grenzt sich bewusst von zwei Nachbarthemen ab. Eine allgemeine Netzwerkdiagnose untersucht Link, Adressierung, Routing, Namensauflösung und Dienste im Detail. Eine Sensor-Plausibilitätsprüfung bewertet, ob ein Messwert fachlich glaubwürdig ist. Hier hast du gelernt, Zustände und Ereignisse über mehrere technische Stufen hinweg zu einem belegten Befund zu verbinden.

Belegmatrix