Mehrsekündigen Stillstand einer Industriekamera-Verbindung eingrenzen

Überblick

Diese Fallstudie behandelt die Steuerung einer Industriekamera, bei der die Kommunikation im Normalbetrieb funktionierte, aber gelegentlich für einige Sekunden aussetzte. Weil das Problem sowohl wie ein Stillstand in der Anwendung als auch wie ein Netzwerkproblem wirken konnte, musste zunächst getrennt betrachtet werden, was tatsächlich wartete.

Symptome

• Die Kommunikation setzte selten und nur für einige Sekunden aus.
• UI und gesamter Prozess wirkten nicht vollständig blockiert.
• Bei einer Anlagensteuerung hat selbst ein mehrsekündiger Stillstand erhebliche Auswirkungen vor Ort.

Einschränkungen

• Das Problem trat selten auf; aus den Protokollen allein waren die Auslösebedingungen schwer zu erkennen.
• Kamera-SDK, Netzwerkkarte, Switch und Anwendungsimplementierung konnten jeweils die Ursache sein.
• Die Eingrenzung musste erfolgen, ohne Bedingungen nahe der Produktionskonfiguration zu zerstören.

Was wir beobachtet haben

• Um anwendungsinterne Stillstandsursachen zuerst auszuschließen, prüften wir Verarbeitungsverzögerungen und Ausnahmen.
• In Paketmitschnitten beobachteten wir Retransmission und die Zeitabstände.
• Wir verglichen TCP-Optionen und die Form der Wiederholungswartezeit mit dem Symptom.

Wie wir eingegrenzt haben

Wir prüften, ob der Kommunikationsstillstand nicht als „die Anwendung steht“, sondern als Warten auf eine Wiederholung nach Paketverlust behandelt werden konnte. Das Ergebnis war: Nicht ein Deadlock der Anwendung, sondern die im Vordergrund sichtbare Wartezeit auf TCP-Seite erklärte die Struktur des Aussetzers.

Wie wir verbessert haben

• Wir bestimmten, ob die Einstellungen für Zeitstempel nach RFC 1323 unter den vorliegenden Bedingungen wirksam sein konnten.
• Wir passten die Konfiguration so an, dass sich die Wiederholungswartezeit verkürzen ließ.
• Wir ordneten Beobachtungsschritte und Kriterien zur Eingrenzung, damit künftig auch auf Wire-Ebene geprüft werden kann.

Mit welchen Services diese Fallstudie verbunden ist

Diese Fallstudie verbindet die Fehleruntersuchung und Ursachenanalyse – mit der sich schwer reproduzierbare Kommunikationsaussetzer anhand von Evidenz eingrenzen lassen – mit der Windows-App-Entwicklung, die Kommunikations- und Überwachungsdesign auf der Anwendungsseite überprüft.

Verwandte Artikel

Kontakt aufnehmen

Wenn diese Seite zu Ihrer Situation passt, schildern Sie uns den aktuellen Kontext und die benötigte Unterstützung.