Vor-Ort-Fallsammlung

Keine „So macht man es"-Anleitung, sondern eine Aufzeichnung von „So ist es passiert und so wurde es gelöst". Von Februar bis September 2026 wurden hier ausschließlich tatsächlich vor Ort aufgetretene und gelöste Fälle aufgenommen.

So lesen Sie dieses Dokument

Allgemeine Abläufe und grundlegende Bedienung finden Sie hier nicht. Dafür sind Problembehandlung und Technische Problembehandlung maßgeblich.

Hier gibt es nur drei Zeilen: Symptom → Ursache → Maßnahme. Suchen Sie nach etwas, das Ihrem aktuellen Symptom ähnelt, und nutzen Sie es als Kandidat für die Ursache. Die verbleibenden Zahlen sind reines Fachwissen wie Protokollstandards oder Standardwerte von Bibliotheken; IP-Adressen, Hostnamen und Kundennamen wurden entfernt.

---

1. Installation vor Ort · Netzwerk

Ping auf die PLC funktioniert nicht, kein Datenaustausch möglich

• Symptom Nach der Installation vor Ort keine Kommunikation mit der PLC. Ping ohne Antwort.
• Ursache Die PLC-IP und die dem Edge-PC zuzuweisende IP wurden nicht unterschieden.
• Maßnahme Stellen Sie die Edge-PC-IP auf denselben Adressbereich · einen anderen Host · dieselbe Maske wie die PLC ein. Füllen Sie vor der Anfahrt beide IPs in der Tabelle aus und prüfen Sie, ob sie unterschiedlich sind.
• Kontrolle Fallen beide Kommunikationswege gleichzeitig aus, sollte zuerst ein IP-Konflikt vermutet werden. Grenzen Sie in der Reihenfolge ping → Port → read ein.

Mitsubishi-Port unbekannt, Ingenieur wartet nur

• Symptom Arbeit stockt, weil der MC-Protokoll-Port nicht bekannt ist.
• Ursache Bei Mitsubishi gibt es keinen offiziellen festen Port. Es ist der Wert, der in den „Open-Einstellungen" von GX Works festgelegt wird.
• Maßnahme Bitten Sie den Ingenieur gezielt um vier Angaben — ① Bildschirm der Open-Einstellungen ② Protokoll, Open-Methode, eigener Port ③ ob die Einstellung für das MC-Protokoll vorgesehen ist ④ Einschränkung der erlaubten Zugriffs-IPs. Fragen Sie nicht pauschal „Wie lauten die Kommunikationseinstellungen".
• Hinweis Übliche Werte sind eingebautes Ethernet 1025 · Modul 2001, 5001/5002 sind reserviert. 5007 ist ein Standardwert der Bibliothek, kein Mitsubishi-Standardwert.

Ping und Port funktionieren, aber Werte werden nicht gelesen

• Symptom Verbindung steht, aber Speicherwerte kommen nicht an.
• Ursache Problem mit den Speicheradressen des PLC-DB-Blocks.
• Maßnahme Bitten Sie den PLC-Ingenieur, die Adresswerte des DB-Blocks zu prüfen. Stimmen die Adressen und gibt es keine Probleme bei den Verbindungsoptionen, ist durch Vor-Ort-Daten belegt, dass auf Edge-Seite kein Scan-Problem vorliegt. Ab diesem Punkt ist es PLC-seitig zu beheben.

Bei geschlossener Schranktür wird die Kommunikation instabil

• Symptom Bei geschlossener Schranktür wird das Netzwerk sehr instabil, bei offener Tür ist es gut.
• Ursache In einem dicken Schrank waren Edge-PC, LTE-Router und sogar die Antenne alle untergebracht.
• Maßnahme Installieren Sie die Antenne außerhalb des Schranks. Die Bohrposition legt der Elektroraum-Verantwortliche fest. Bei Außeninstallation ist Silikonabdichtung an der Verbindungsstelle Pflicht — das verhindert mangelhafte Befestigung.

Bei der Begehung wurden Prüfpunkte übersehen, dadurch Stillstand vor Ort

• Symptom Trotz vermeintlicher Vorbereitung tauchen vor Ort ständig neue Variablen auf.
• Maßnahme Legen Sie die 6 Punkte der Begehung fest — Schrankaufbau/Gehäusetyp / PLC-Modell und Zustand / Art der Netzwerkkommunikation / Ping-Status der AP-Zone / Installationsort des Edge-PC / Antennenposition. Das Gehäuse besteht aus Edge-Mini-PC + LTE-Router + 2-fach-Steckdosenleiste, die Position des Netzteil-Adapters muss unbedingt berücksichtigt werden.

Anzahl der zu installierenden Edge-PCs konnte nicht festgelegt werden

• Symptom Begehung abgeschlossen, aber die Geräteanzahl steht nicht fest.
• Ursache Die Anzahl der zu erfassenden Tags war nicht gesichert. Erst mit Tag-Anzahl und Erfassungsintervall lässt sich die Last pro Gerät und damit die Anzahl festlegen, aber es gab keine Liste, und auch der Installationsort war begrenzt, was eine Nachinstallation erschwerte. Es wurde 1:1-Zuordnung angenommen, der Kunde verlangte jedoch 1:N.
• Maßnahme Holen Sie vor der Begehung zuerst ① die Liste und Anzahl der PLC-Tags je Betriebsstätte ② das Formular für Installationsinformationen (PLC/SCADA · IP/PORT · Protokoll) ③ den Plan für den Netzwerkaufbau neuer Abschnitte ein.

PLC hat keinen Ethernet-Port oder es wird ein Umweg über den SCADA-PC verlangt

• Symptom Die Annahme einer direkten Ethernet-TCP-Verbindung trifft nicht zu. Forderungen wie „Kann man es nicht einfach vom an die PLC angeschlossenen PC holen", oder eine Struktur, bei der mehrere PLCs nur in der DB des SCADA-PC aufgezeichnet werden.
• Maßnahme Prüfen Sie bei der Begehung unbedingt ob die PLC einen Ethernet-Port hat / ob ein Umweg über SCADA nötig ist / Art und Aufzeichnungsweise der SCADA-DB, um die Erfassungsmethode vorab festzulegen.

Nach Anschluss eines Testwerkzeugs brach die Erfassung ein

• Symptom Nach Verbindung mit einem Prüfwerkzeug wird die bestehende Erfassung abgelehnt oder gestört.
• Ursache Eine zweite TCP-Verbindung wurde zu einem Gerät mit nur einem Verbindungsslot wie MELSEC geöffnet.
• Maßnahme Drei Dinge sind untersagt.
  1. Keine zweite Verbindung zu einer PLC, die bereits erfasst wird — die betreffende OPC zuerst anhalten.
  2. Kein write — ein einzelnes Werkzeugargument löst bereits ein write aus.
  3. Kein Probe-Timeout von 1 Sekunde — die gemessene Accept-Verzögerung des Geräts beträgt rund 2,6 Sekunden. Setzen Sie 3–5 Sekunden an.

---

2. Boot · Start

Nach dem Boot antworten alle Endpunkte nicht + Logs voller Ping-Retry-Einträge

• Symptom Alle Anfragen laufen in ein Timeout (code=000).
• Ursache Es handelt sich um dev.mode=EDGE, wobei der Web-Port der externen Plattform ausgefallen war und dadurch das Booten blockiert wurde.
• Maßnahme Auf dev.mode=STANDALONE umstellen und neu starten, nach Wiederherstellung der externen Seite zurücksetzen. Prüfen Sie auch server.host.

Web-Oberfläche fällt alle 3–4 Minuten aus

• Symptom Die Web-Oberfläche stirbt periodisch und kommt wieder.
• Ursache Keine Verbindung zur Plattform. Gelingt die Verbindung nicht, gerät der Web-Kontext alle 3–4 Minuten in eine Reload-Schleife. Nach erfolgter Verbindung stoppt dies. Es ist kein Problem der Web-Oberfläche selbst.
• Maßnahme Die Wiederherstellung der Plattformverbindung ist die Grundursache.

Nach Änderung des Authentifizierungsschlüssels endlose NPE-Flut

• Symptom Im Log häufen sich unaufhörlich dm is null-NPEs, alle DB-bezogenen Funktionen fallen aus.
• Ursache Ist der Schlüssel falsch, schlägt die Initialisierung des API-Clients mit 403 hart fehl, wodurch DatalakeManager nicht initialisiert wird und die DB-Schicht zusammenbricht. Bei korrektem Schlüssel greift der Fallback.
• Maßnahme Auf den ursprünglichen Schlüssel zurücksetzen und neu starten. Kontrolle über die Zeile DataSource initialized — ready im Boot-Log.

---

3. Unterbrechung der Plattform-Uplink-Übertragung

Erfassung und Web auf der Edge-Seite normal, aber keine Daten kommen bei der Plattform an

Dies ist die am häufigsten angetroffene Form.

• Symptom Vor-Ort-Erfassung und Web sind unauffällig, nur die Uplink-Übertragung steht still. Der Web-Port zeigt über 100 TIME-WAIT-Einträge.

• Ursache Nach einer kurzen Leitungsunterbrechung fehlen im MQTT-Reconnect-CONNECT die Zugangsdaten, die Plattform lehnt ab und es kommt zu einer endlosen Reconnect-Schleife. Da die Zugangsdaten nur im initialen Startpfad eingetragen werden, kann die App sich nach einer Unterbrechung nicht selbst erholen.

• Maßnahme Ein Neustart der Web-App stellt die Session wieder her. Zur Verhinderung eines Wiederauftretens siehe den Watchdog unten.

• Kontrolle Das Erkennungsmuster ist: „Der Web-Port der Plattform ist offen, aber es gibt keine MQTT-Session."

  nc -z -w2 <플랫폼IP> <웹포트> && echo ROUTE_OK
  ss -tan | grep -c "ESTAB.*<플랫폼IP>:<MQTT포트>"   # 1 정상 / 0 끊김

Kurze Unterbrechung dauert nur Sekunden, aber Uplink-Ausfall über Tage

• Symptom 7 Sekunden Unterbrechung führen zu 3 Stunden Ausfall, eine einzige Unterbrechung zu 11 Tagen Ausfall.
• Ursache Wie oben. Da Web, PLC-Erfassung und Leitung alle normal waren, bemerkte es niemand.
• Maßnahme Automatische Wiederherstellung (Watchdog) ausrollen. Die Dauer der Unterbrechung und die Dauer des Ausfalls stehen in keinem Zusammenhang, behandeln Sie daher zuerst Geräte ohne Überwachung.

Statt der Plattform wurde fortlaufend in der Edge gesucht, obwohl dort nichts gespeichert wurde

• Symptom Uplink funktioniert, aber auf der Plattform bleiben keine Daten erhalten.
• Ursache Es lag nicht an der Edge, sondern am Speicherpfad der Plattform. Eine Topic-Erfassung vor dem Broker bestätigte, dass die Edge-Veröffentlichung normal war; der eigentliche Blockierungspunkt war, dass die Plattform-Speicherinitialisierung wegen eines DB-Query-Timeouts dauerhaft nicht initialisiert wurde.
• Maßnahme Plattform-Server neu starten. Die endgültige Wiederherstellung erforderte das gleichzeitige Beheben mehrerer Ursachen — fehlende Broker-Authentifizierungsdatei + Tag-description null + angehaltener Plattform-Speicherpuffer.
• Kontrolle Erfolgreiches Laden wird nicht an der SSTable-Erzeugung, sondern am tatsächlichen Vorhandensein des Ziel-Tags festgemacht. Es gab bereits Fälle, in denen nur die Erzeugung geprüft und fälschlich als bestanden gewertet wurde.

Aufbau der automatischen Watchdog-Wiederherstellung

• Symptom Uplink-Unterbrechungen wurden nur wiederhergestellt, wenn sie von Menschen bemerkt wurden.
• Maßnahme Drei Watchdog-Arten werden jeweils als eigenständige Dienste bereitgestellt — Leitung (nur Log) · Anlagennetz (nur Log) · Plattform-Session (Neustart der Web-App). Da auch bei Ausfall eines Dienstes die anderen weiterlaufen müssen, werden sie nicht zusammengelegt.
• Entscheidung Mustererkennung nach 4 aufeinanderfolgenden 30-Sekunden-Intervallen (ca. 2 Minuten) → Neustart → 15 Minuten Sperre gegen erneutes Auslösen.
• Ergebnis Bei 6 ausgerollten Geräten 0 Fehlalarme. Tatsächliche Wiederherstellung: Unterbrechung 05:27 → Auslösung 05:39 → Wiederherstellung 05:40.

Watchdog installiert, aber keine automatische Wiederherstellung

• Symptom 11 Tage Ausfall, ohne dass der Watchdog irgendeine Aktion zeigte.
• Ursache Er lief im reinen Beobachtungsmodus (DRY_RUN=1). would restart hinterließ nur 1.013 Protokolleinträge. Die Erkennung war korrekt, dies war der einzige Fehlerpunkt.
• Maßnahme Beobachtungsmodus ausrollen → an einem Gerät den tatsächlichen Neustart verifizieren → im normalen Zustand auf den Ausführungsmodus umschalten. Wird im unterbrochenen Zustand umgeschaltet, löst sofort ein Neustart aus.

Manueller Neustartbefehl tötet seine eigene Shell

• Symptom Nach Ausführung des Neustartbefehls stirbt die Shell sofort, Web-App 3 Minuten 34 Sekunden down.
• Ursache Die Kommandozeile von pkill -9 -ef tomcat enthielt „tomcat" und matchte sich dadurch selbst. Der nachfolgend angehängte startup wurde nicht ausgeführt.
• Maßnahme kill und startup als separate Ausführungen trennen. Für die Statusprüfung eckige Klammern wie in pgrep -f 'catalina[.]startup' verwenden, um Selbstmatching zu vermeiden.
• Achtung restart.sh enthält am Ende einen Log-Tail und blockiert bei Aufruf aus Automatisierung.

PLC ist normal, aber Watchdog meldet Dienst DOWN

• Symptom Session ist aktiv, trotzdem 1.422 Fehlalarme.
• Ursache ① Das Erkennungsmuster übersah die IPv6-mapped-Schreibweise ([::ffff:<PLC_IP>]:<PLC포트>). ② Der als Fallback genutzte nc wurde vom Gerät mit nur einer Session abgelehnt.
• Maßnahme ① Muster so anpassen, dass beide Formen (mit und ohne eckige Klammern) erkannt werden. ② Reihenfolge der Entscheidung ändern auf ss ESTAB passiv zuerst, nur wenn nicht vorhanden nc.

Nach Watchdog-Neustart 2 Minuten Erfassungsunterbrechung

• Symptom Bei Änderung der Watchdog-Konfiguration beendet sich auch die Web-App.
• Ursache Die vom Watchdog gestartete Web-App ist in dieselbe cgroup wie der Watchdog-Dienst eingegliedert und stirbt mit ihm.
• Maßnahme Nach 90 Sekunden erfolgt automatische Neuerkennung und Neustart (Selbstheilung), dennoch entsteht eine Unterbrechung von 2 Minuten. Änderungen an der Watchdog-Konfiguration nur außerhalb des Produktionsbetriebs vornehmen.

Diagnosekanal zeigt wiederholt 401

• Symptom Diagnoseport dauerhaft SYN-SENT, im Log erscheint alle 2–3 Sekunden ein 401 der Diagnoseauthentifizierung.
• Ursache Es handelt sich um ein plattformseitiges Problem; die 401 entstehen, weil der Diagnose-Sender wegen eines Versionsunterschieds keinen Schlüssel mitsendet, und treten auch bei normal funktionierender Kombination genauso auf.
• Maßnahme Ein Edge-Neustart löst dies nicht, daher aus den Watchdog-Triggern ausschließen. Ob die Anbindung normal funktioniert, wird daran festgemacht, ob innerhalb von 60 Sekunden tatsächliche Tag-Daten eintreffen.

---

4. Stabilität der PLC-Erfassung

Jede kurze Kommunikationsschwankung führt zu wiederholtem Stopp/Neustart der Erfassung

• Symptom Bei vorübergehenden Kommunikationsschwankungen stoppt die Erfassung und verbindet sich immer wieder neu.

• Ursache Ein einziger fehlgeschlagener ping stoppte sofort den Collector.

• Maßnahme Die Kulanz liegt beim Stoppen und bei der Wiederherstellung. Die NOT_COLLECT-Entscheidung selbst hat keine Kulanz.

  Was	Wert
  ping-Intervall · ICMP-Timeout	5 Sekunden · 800 ms
  Nach wie vielen aufeinanderfolgenden ping-Fehlversuchen wird der Collector gestoppt (bei Erfolg Reset)	3 Versuche
  Fenster, in dem ein kürzlich erfolgreicher Lesevorgang den ping überspringt	15 Sekunden oder Erfassungsintervall ×3, je nachdem, was länger ist
  Wann auf NOT_COLLECT gesetzt wird	Keine Kulanz — in jedem Zyklus mit auch nur einem Fehler oder ganz ohne empfangene Werte, sofort in diesem Zyklus
  Wie lange NOT_COLLECT anhalten muss, bevor eine Wiederherstellung (Neuverbindung) angefordert wird	Mehr als 60 Sekunden

  Nicht über Konfiguration änderbar

  Alle obigen Werte, einschließlich ping 3-mal und Wiederherstellung nach 60 Sekunden, sind im Code fest verankerte Konstanten. In app.properties existiert kein entsprechender Schlüssel — eine Änderung erfordert eine Produktänderung. In älteren Unterlagen findet sich fälschlich die Darstellung als Konfigurationsschlüssel.

  Zugleich wurde der tagspezifische Retry abgeschafft. Bei Verbindungsabbruch scheitern alle Tags gleichzeitig, sodass Retries nur den Scan verzögern. Stattdessen wurde ein Lesetimeout pro Tag eingeführt, damit die Verzögerung eines einzelnen Tags nicht den gesamten Scan blockiert.

  Für Verbindungsfehler gilt ein Reconnect-Backoff pro Verbindung (2026-10-01). Ab 1 Sekunde wird die Wartezeit jeweils verdoppelt, bis maximal 60 Sekunden, bevor neu verbunden wird. Ein erfolgreicher Verbindungsaufbau oder eine geänderte IP bzw. ein geänderter Port lösen ohne Wartezeit sofort einen neuen Versuch aus.

• Ergebnis Eine kurze Schwankung kann kurz als NOT_COLLECT auf dem Bildschirm erscheinen. Sie stoppt den Collector dennoch nicht und löst keine Neuverbindung aus — der Collector wird erst nach 3 ping-Fehlversuchen in Folge gestoppt, und eine Wiederherstellung wird nur angefordert, wenn NOT_COLLECT länger als 60 Sekunden anhält.

Fehlalarm des ICMP in der Überwachungsschicht stoppt funktionierende Erfassung

• Symptom Die Erfassung läuft, aber die Überwachung stoppt den Collector.
• Ursache Die Überwachungsschicht entschied nur anhand des ping-Ergebnisses.
• Maßnahme Umstellung des Überwachungskriteriums auf „Traffic ist der eigentliche Lebensbeweis". Ist das letzte read erfolgreich und aktuell, wird die Probe übersprungen.

Socket-Leck blockiert die PLC 50 Minuten lang vollständig

• Symptom Alle Verbindungen für Erfassung, Probe und Wiederherstellung werden abgelehnt.
• Ursache Beim Verwerfen des Treibers wurde ohne close weggeworfen, der Socket leckte, und da es sich um ein Gerät mit nur einem Slot handelte, belegte dieser Socket den Slot dauerhaft. connected=false ist nur ein logisches Flag, unabhängig vom TCP-Socket.
• Maßnahme Code, der den Treiber entfernt/ersetzt, muss zwingend mit close einhergehen.

Wegen Probe-Timeout öffnet sich die Wiederherstellung nie

• Symptom Obwohl der Slot frei ist, erfolgt keine Wiederherstellung.
• Ursache Die Accept-Verzögerung des Geräts liegt bei ca. 2,6 Sekunden, der Probe-Timeout bei 1 Sekunde, wodurch dies dauerhaft als Fehlschlag gewertet wurde.
• Maßnahme Timeout auf 4 Sekunden erhöhen. Beim Anschluss neuer Geräte den Verbindungsaufbau im Log tatsächlich messen und den Puffer verifizieren.

Vertrauen Sie nicht einer einzigen bestandenen Prüfung

Die drei obigen Fälle hatten beim gleichen Symptom drei übereinanderliegende Ursachen. Jedes Mal, wenn eine behoben wurde, hielt man es für „gelöst", aber die nächste Ursache blieb bestehen.

Störungen treten meist innerhalb der ersten Minute nach dem Booten auf. Beobachten Sie die ersten 3 Minuten intensiv, und vergeben Sie das Bestanden-Urteil erst, wenn Boot-Entscheidungsfenster + 15 Minuten unterbrechungsfrei + 0 Log-Einträge alle erfüllt sind.

Unklar, ob die Leitung die Ursache der Kommunikationsinstabilität ist

• Symptom Die Ursache für intermittierende Erfassungsfehler ließ sich nicht eingrenzen.
• Beobachtung In einem tatsächlichen Fall stieg die Verbindungsverzögerung auf das 6-fache des Durchschnitts (6.125 ms), danach brach die Verbindung über mehrere Tage immer wieder ab, und ohne Eingriff kam es zu automatischer Wiederherstellung und Fortsetzung der Erfassung. Der Verzögerungsanstieg ist ein Vorbote.
• Maßnahme Permanente Qualitätsüberwachung einrichten. 1-Sekunden-Pings in 10-Minuten-Blöcken zusammenfassen (Verlustrate · RTT min/durchschnitt/max), und bei Verlustrate ab 5 % gleichzeitig Interface-Fehlerzähler und Routing als Snapshot aufzeichnen. Bewertung: normal / Warnung 5 % / kritisch 10 %, Logs 15 Tage aufbewahren.

Paketverlustsituation konnte nicht reproduziert werden

• Symptom Das Vor-Ort-Symptom ließ sich firmenintern nicht nachstellen, Verifikation war blockiert.

• Maßnahme Mit tc/netem Verlust nur für die Kommunikation mit einer bestimmten PLC-IP erzeugen. SSH und andere Kommunikation bleiben unberührt.

  tc qdisc del dev <NIC> root 2>/dev/null            # 항상 먼저 제거
  tc qdisc add dev <NIC> root handle 1: htb default 30
  tc class add dev <NIC> parent 1: classid 1:1 htb rate 100mbit
  tc class add dev <NIC> parent 1:1 classid 1:10 htb rate 100mbit
  tc qdisc add dev <NIC> parent 1:10 handle 10: netem loss 5%
  tc filter add dev <NIC> protocol ip parent 1:0 prio 1 u32 match ip dst <PLC_IP> flowid 1:10
  tc qdisc del dev <NIC> root                        # 종료

Auslesen der Watchdog-Logs

Nur bei Statuswechsel entsteht ein Ereignisblock. Mit grep "EVENT" werden nur die Ereignisse betrachtet.

Gruppe	Signal	Bedeutung
LTE	CABLE_DISCONNECTED	physische Verbindung
LTE	ROUTER_DOWN	Router-Ping fehlgeschlagen
LTE	LTE_NO_RETURN_TRAFFIC	Senden vorhanden, Empfang 0 — Uplink-Trennung
LTE	LTE_SIGNAL_LOST	externer Ping fehlgeschlagen
PLC	LINK_DOWN · ARP_L2_ISSUE	Link · L2
PLC	PHYSICAL_LAYER_ISSUE	CRC-Anstieg — Kabel/Port-Physik
PLC	PLC_NO_RESPONSE · PLC_SERVICE_DOWN	keine Antwort · Port geschlossen

⚠ Manche NICs unterstützen rx_crc_errors nicht. CRC:+0 ist ein Fallback-Wert, nicht für physische Bewertungen verwenden.

---

5. Werte fehlen oder sind fehlerhaft

HMI-Anzeigewert und Edge-Erfassungswert stimmen nicht überein

• Ursache Der HMI-Wert kann ein bereits logisch verarbeiteter Wert sein.
• Maßnahme In 3 Stufen eingrenzen — PLC-Speicher-Originalwert → HMI-Panel (mit angewandter Logik) → Edge (Datentyp · Erfassungsintervall · Formel). Zuerst mit dem PLC-Original vergleichen, dann Typ, Intervall und Formel der Edge prüfen und abschließend vergleichen.

Zähler enthält gelegentlich merkwürdige Zwischenwerte

• Ursache Überschneidet sich während des PLC-Scan-Zyklus der Zählerzeitpunkt mit dem Lesezeitpunkt, wird ein Zwischenwert gelesen, bei dem die Konsistenz zwischen oberem und unterem Wort gebrochen ist. Dies ist kein Fehler, sondern eine Timing-Eigenschaft.

Tag-Adresse eingegeben, aber immer leerer Wert

• Ursache Bei JSON-artigen Adressen wurde die PATH-Modus-Notation ($.) ausgelassen, wodurch in den KEY-Modus gefallen wurde. Der KEY-Modus folgt keinem Pfad, sondern sucht exakt nach dem obersten Schlüsselnamen. Betrifft Kafka · MQTT · WebSocket, nicht HTTP.

• Maßnahme Drei Punkte prüfen.

  • Array-Indizes verwenden Punkt und Zahl (.0.); Klammernotation wird nicht unterstützt.
  • Feldnamen müssen bis auf Groß-/Kleinschreibung exakt stimmen (agvid fehlgeschlagen / agvId erfolgreich).
  • Wildcards und das vollständige Entfalten von Arrays werden nicht unterstützt.

  TOPIC:$.body.list.0.battery     ✅
  TOPIC:body.list[0].battery      ❌

Nur bestimmte Tags bleiben leer

• Ursache Ein Tippfehler im Feldnamen der Payload des sendenden Systems (status → stutaus). Bei Registrierung mit korrekter Schreibweise entsteht kein Fehler, nur leere Werte.
• Maßnahme Vor der Registrierung die tatsächlichen Feldnamen im Original der Payload visuell prüfen.
• Zusätzlich zu beachten Leere Zeichenketten werden gar nicht erst gespeichert (es entstehen Datenlücken in Zeiten ohne Alarm). JSON-null wird als String "null" gespeichert, daher scheitert das Parsing bei Registrierung als numerischer Typ.

Erfasste Anzahl ist weit geringer als die Anzahl veröffentlichter Nachrichten

• Ursache Das ist konstruktionsbedingt normal. Der Treiber überschreibt Nachrichten mit dem letzten Wert, und das Lesen ist kein Queue-Konsum, sondern ein Polling-Sample des letzten Werts. Ist der Broker-LAG 0, wird alles empfangen.
• Maßnahme Für vollständige Erfassung ist ein queuebasiertes Redesign nötig. Das ist eine Vertragsänderung.

Direkt nach der Registrierung strömen alte Daten herein, oder umgekehrt kommt nichts an

• Ursache Es handelt sich um die auto-offset-Richtung von Kafka (Standard latest). latest greift nur, wenn nach der Erstellung der Consumer-Gruppe veröffentlicht wird, während earliest im Moment der Registrierung alle bestehenden, aufgestauten Nachrichten auf einmal konsumiert. Abgesehen von diesen beiden Werten fällt es stillschweigend auf latest zurück.
• Achtung Dies gilt nur für Kafka. MQTT kennt kein Offset-Konzept — das vergleichbare Element ist clean-session.
• Maßnahme Die Verifikation erfolgt über Echtzeit-Veröffentlichung.

Datenextraktion liefert 0 Treffer, aber keine Fehlerlogs

• Ursache jar-Konflikt — eine neu gepackte JSON-Bibliothek kollidierte mit der Standardbibliothek, wodurch der benötigte Konstruktor fehlte.
• Maßnahme Durch das Standard-jar ersetzen, das kollidierende jar in ein Backup verschieben, Cache leeren und neu starten.
• Kontrolle Der Normalzustand ist ein stiller Erfolg. Läuft der Polling-Thread, ist der LAG 0 und stoppen die VALUE_NULL-Logs, ist alles normal. Es erscheint kein Erfolgslog.

Typausnahme tritt auf

• Symptom NumberFormatException oder Invalid tag data type.
• Ursache Bei der Registrierung wurden alle Typen pauschal als Integer eingetragen.
• Maßnahme Neu nach Werteart aufteilen — Double für Strom, Temperatur, Spannung, Gewicht, Geschwindigkeit, Koordinaten; String für Alarm, Status, Bereich, Richtung, Farbe; Integer für Batterie, Fehlercode. Edge-Tag-Typ und Plattform-Typ müssen übereinstimmen. Kommt der Wert als String, wird er bei korrekt deklariertem Typ trotzdem exakt geparst.

Metadaten geändert, aber keine Wirkung

• Ursache Es wurde kein Cache-Reload durchgeführt.
• Maßnahme Alle drei Stellen müssen erneut eingelesen werden — Plattform-Server, OPC-UA-Plugin und Edge. Fehlt auch nur eine, bricht die Konsistenz. Wird die OPC neu registriert und dadurch eine neue Tag-ID vergeben, die Tag-Rückstände auf der Plattform löschen und die OPC stoppen und neu starten, um neu zu synchronisieren.

Per REST registriert, aber der Treiber verbindet sich nicht einmal mit dem Broker

• Symptom Sieht aus wie „PLC-Verbindungs-Timeout", obwohl TCP normal ist und nicht einmal eine Consumer-Gruppe entsteht.
• Ursache Im Anfragekörper zur OPC-Erstellung fehlte ein Pflichtfeld, wodurch intern eine Ausnahme auftrat und der Adresskarten-Scan fehlschlug. Bei Registrierung über die Oberfläche füllt diese die Felder aus, daher tritt dies nur über den REST-Pfad auf.
• Maßnahme Alle acht Pflichtfelder ausfüllen — opc_id · opc_name · opc_type · site_id · opc_agent_ip · opc_agent_port · timecycle · async. Auch Adressschreibweise und Offset-Richtung prüfen.
• Was sich geändert hat Früher wurden bei PUT nicht angegebene Felder geleert, weshalb „Löschen und Neuanlegen" sicher war. Am 2026-07-20 wurde dies durch partielles Merge korrigiert — jetzt ändern sich nur die gesendeten Felder. Allerdings kann ein Feld dadurch nicht mehr durch null gelöscht werden.

Ping funktioniert, aber Erfassung bleibt bei 0

• Ursache Ping funktioniert, ARP ist normal, aber nur der TCP-Port war geschlossen. Der Fehlerzähler beim Lesen stand bei 4,8 Millionen, Erfolge bei 0.
• Maßnahme PLC-seitiger Kommunikationsport/Modul ist zuständig, der Watchdog kann dies nicht lösen. An den Anlagenverantwortlichen weiterleiten.

Abfrage des aktuellsten Werts liefert veraltete Daten

• Ursache SELECT * ... LIMIT 5 bedeutet Partitionsreihenfolge, wodurch alte Daten zuerst erscheinen. Die Echtzeiterfassung war normal.
• Maßnahme Prüfung über WHERE tag_id=... ORDER BY timestamp DESC.

---

6. Ressourcenerschöpfung · Logs

Alle 30 Tage brechen gleichzeitig alle möglichen Fehler aus

• Symptom Nach 30 Tagen Betrieb Fehlerexplosion an allen Fronten.

• Ursache Der Überwachungs-Timer versucht alle 10 Sekunden einen docker-Ping; fehlt docker, werden im Fehlerpfad 2 Dateideskriptoren nicht freigegeben. Die Ausnahme wird nicht geloggt, es häuft sich symptomlos an. Die Rechnung geht auf — 30,3 Tage geteilt durch 10 Sekunden ergibt 261.700 Durchläufe, mal 2 ergibt 523.400, gemessen wurden 523.690.

• Maßnahme Dieselbe docker-Version wie bei einem funktionierenden Vergleichsgerät fest installieren. Nach einem bloßen Neustart tritt das Problem nach 30 Tagen erneut auf.

• Kontrolle

  P=$(pgrep -f catalina.startup.Bootstrap | head -1)
  ls /proc/$P/fd | wc -l      # 정상 ~600, 누수 시 50만+
  wc -l < /proc/net/unix      # 정상 ~200, 누수 시 50만+
  ls /var/run/docker.sock     # 없으면 누수 진행 확정

Behandeln Sie sekundäre Symptome nicht als einzelne Bugs

Fehlschläge bei /proc/stat, Mount point not found, JMX-NPE, „Zu viele geöffnete Dateien", Queue-WAL-Ausnahme (Bereich mit Datenverlust) und Log-Explosion sind allesamt Folgen der Erschöpfung der Dateideskriptoren. Vor der Erschöpfung gab es 0 ERROR-Einträge im Log.

Threads und FDs steigen fortlaufend an, OOM tritt ein

• Ursache Endloses Reconnecting zu einem toten Ziel. Ist das Ziel per Ping erreichbar, aber der Protokoll-Port tot, versuchen Dutzende OPCs im Sekundentakt eine Neuverbindung und erzeugen bei jedem Versuch einen neuen Client. Gemessen wurden 2,25 Netto-Zuwächse pro Sekunde, 76 % aller laufenden Threads entfielen darauf. Bei einem anderen Gerät stieg die Treiber-Thread-Anzahl bis 40.900, es kam zu OOM, und die Erfassung stand 3 Tage still, ohne dass es wegen fehlender Beendigungslogs bemerkt wurde.
• Maßnahme Nicht genutzte OPCs müssen zwingend gestoppt werden. Fällt die PLC aus, tritt dasselbe Leck erneut auf — besondere Vorsicht bei dauerhaft laufenden Geräten.

Dasselbe Log sammelt sich zu Zehntausenden an

• Ursache Das Polling-Intervall ist hartcodiert, es gibt keine Abschaltoption.
• Maßnahme Patchen Sie nicht die Klasse, sondern fügen Sie in der Logging-Konfiguration einen WARN-Logger für das betreffende Paket hinzu, um es zu unterdrücken.

---

7. Deployment · Initialisierung

Es durften keine Installationsspuren auf Kundengeräten zurückbleiben

• Maßnahme Statt Dateien hochzuladen, wird das Skript über Standard-Input eingespeist.

  ssh <호스트> 'bash -s' < install.sh

  Auf dem Server entsteht dadurch keinerlei Installationsdatei.

• Kontrolle Keine Rückstände im temporären Verzeichnis, keine Backup-Dateien entstanden, und innerhalb von 24 Stunden sind neue Dateien nur die beabsichtigten Ergebnisse. Backup-Originale werden im lokalen Bericht aufbewahrt.

Einzeiliger Installationsbefehl liefert 404

• Ursache Der Verteilungspfad wurde umstrukturiert, die oberste Domain war anders.
• Weitere Stolperfallen
  • Symlinks führen zu 404 — Verweise werden mit Hardlinks gesetzt.
  • Bei Ausführung mit curl | bash stößt das read im Skript auf EOF und bricht alles ab. Lösung durch Verknüpfung des Terminals.
  • Ein Fehlschlag auf einer Stufe führte dazu, dass anschließende Firewall-, Tuning-, SSL- und Diensteregistrierungsschritte übersprungen wurden, weshalb diese Stufe als optional eingestuft wurde.

Box auf reines Betriebssystem zurückgesetzt

• Reihenfolge der Maßnahme Container-Löschung vor Engine-Deinstallation durchführen. Als Sicherung Nummer 0 prüfen, ob eine Neu-Einrichtungsquelle vorhanden ist, und bei Fehlen abbrechen.

Firewall auf keinen Fall anfassen

Wird die Firewall während einer Remote-Verbindung zurückgesetzt, bricht SSH ab und ist ohne Konsole nicht wiederherstellbar. Das Neu-Einrichtungsskript öffnet nur benötigte Ports, es schließt keine.

• Bewusst unberührt gelassen Hostname, Locale, Zeitzone, Nebenpakete. Diese werden bei der Neu-Einrichtung erneut gesetzt.

server.host geändert, aber Datenrichtung hat sich nicht geändert

• Ursache Dieses Gerät arbeitete im Pull-Modus. Die Plattform liest die Tag-Werte-API der Edge direkt aus. Eine Änderung des Push-Ziels der Edge ändert die Richtung nicht.
• Maßnahme Für den Empfang durch eine andere Plattform muss dort mit Edge-Adresse und -Schlüssel ein Pull konfiguriert werden.

Keine Anbindung wegen unterschiedlicher Edge-/Plattform-Generationen

• Symptom API server is not responding wiederholt sich endlos. Alle Ports sind offen, das Netzwerk ist also unschuldig.
• Ursache Die neue Plattform öffnet nur die neue API, die alte Edge rief jedoch hartcodiert den alten Pfad auf. Der Handshake muss vorausgehen, bevor die Veröffentlichung beginnt.
• Maßnahme Edge auf dieselbe Release wie die Plattform aktualisieren. Per Konfiguration ist das nicht lösbar — der Handshake ist einkompiliert.
• Token-Falle Speichern und Ausrollen sind unterschiedliche Vorgänge (in der Oberfläche muss „Ausrollen" gedrückt werden). Es ist eine Angabe erlaubter IPs erforderlich, und ein 200 bei öffentlichem Ping ist kein Nachweis der Authentifizierung.