Störung im Produktionsnetz: In 5 Schritten von „geht nicht“ zur Ursache

Bevor du anfängst: drei Fragen

Die ersten zwei Minuten entscheiden oft über die nächsten zwei Stunden. Kläre deshalb, bevor du irgendetwas anfasst:

• Was genau geht nicht? „HMI zeigt keine Werte“ ist etwas anderes als „HMI ist nicht erreichbar“. Lass dir das Symptom zeigen oder beschreibe es selbst präzise.
• Seit wann, und was hat sich geändert? Umbau, Gerätetausch, Firmware-Update, neues Notebook, Wartung durch einen Dienstleister: Die letzte Änderung ist die wahrscheinlichste Ursache.
• Wie groß ist der Kreis? Ein Gerät, eine Zelle, eine ganze Linie? Betrifft es mehrere Geräte am selben Switch, liegt die Ursache eher dort als in jedem einzelnen Gerät.

Und: Sicherheit vor Tempo. Ein Netzwerkkabel an einer laufenden Anlage zu ziehen kann eine Maschine in einen Fehlerzustand bringen. Stimme Eingriffe mit der Produktion ab.

Schritt 1: Physik – Strom, Kabel, Stecker

Der unspektakulärste Schritt löst erstaunlich viele Störungen. Prüfe:

• Hat das Gerät Spannung, und zeigt es einen normalen Betriebszustand?
• Steckt der Stecker richtig, ist die Verriegelung intakt? In Maschinen werden Leitungen bewegt, gequetscht oder durch Vibration gelockert.
• Ist das Kabel beschädigt, zu lang oder neben Leistungskabeln verlegt? Ein Kabeltester zeigt Unterbrechungen und vertauschte Adern.
• Stimmen Medium und Port zusammen, etwa Kupfer gegen Glasfaser oder der richtige SFP-Typ?

Ein Gegentest mit einem bekannt guten Patchkabel oder einem anderen Port ist schnell gemacht und schließt eine ganze Fehlerklasse aus. Bei Glasfaser prüfst du mit dem Glasfaser-Dämpfungsbudget in meinen Online-Tools, ob die Strecke rechnerisch genug Reserve hat.

Schritt 2: Link – Port, Geschwindigkeit, VLAN

Wenn die Physik stimmt, geht es um die Verbindung zwischen Gerät und Switch. Die Link-LED ist der erste Hinweis, aber nicht der letzte. Auf einem verwalteten Switch siehst du mehr:

• Port-Status: Ist der Port administrativ aktiv, oder wurde er abgeschaltet, etwa durch eine Port-Security-Funktion?
• Geschwindigkeit und Duplex: Passen beide Seiten zusammen? Unterschiedliche Einstellungen führen oft nicht zum Totalausfall, sondern zu sporadischen Aussetzern.
• Fehlerzähler: Steigende Zähler für CRC- oder Eingangsfehler deuten auf Kabel, Stecker oder Störeinflüsse hin.
• VLAN: Ist der Port dem richtigen VLAN zugeordnet? Nach einem Gerätetausch landet ein Gerät leicht im falschen Segment.

Hier zahlt sich Dokumentation aus. Wenn du weißt, welches Gerät an welchem Port hängt und in welchem VLAN es sein soll, ist der Abgleich eine Sache von Minuten. Genau dafür ist OT SwitchPort gedacht.

Schritt 3: IP – Adresse, Maske, Gateway

Ein aktiver Link heißt noch nicht, dass Geräte sich verstehen. Auf IP-Ebene sind die häufigsten Ursachen:

• Falsche Adresse oder Maske: Liegt das Gerät tatsächlich im erwarteten Subnetz? Eine falsche Maske kann dazu führen, dass ein Gerät Partner im eigenen Netz für entfernt hält oder umgekehrt.
• Fehlendes oder falsches Gateway: Kommunikation innerhalb der Zelle funktioniert, über Netzgrenzen hinweg nicht.
• Doppelte IP-Adresse: Verbindungen funktionieren mal und mal nicht. Ein Blick in die ARP-Tabelle zeigt, ob sich die MAC-Adresse zu einer IP ändert. ARP ist das Protokoll, das in Ethernet-Netzen IP-Adressen den Hardware-Adressen zuordnet.
• Keine Adresse vom DHCP: Zeigt ein Gerät eine Adresse aus 169.254.0.0/16, hat es sich nach RFC 3927 selbst eine Link-Local-Adresse gegeben, meist weil kein DHCP-Server geantwortet hat.

Für den Test eignet sich Ping, aber mit Vorsicht: Viele Steuerungen, Firewalls oder Hosts beantworten ICMP nicht. Ein fehlendes Echo ist also kein Beweis. Taucht die Adresse nach dem Ping in der ARP-Tabelle auf, ist das Gerät zumindest auf Schicht 2 erreichbar. Zum Nachrechnen von Netzgrenzen hilft der OT Subnet Calculator.

Schritt 4: Dienst – ist der Port erreichbar?

Antwortet das Gerät auf IP-Ebene, aber die Anwendung kommt trotzdem nicht durch, liegt das Problem oft beim Dienst oder dazwischen. Prüfe, ob der erwartete TCP-Port antwortet. Bekannte Beispiele aus dem IANA-Portregister: Modbus/TCP nutzt Port 502, OPC UA Port 4840, EtherNet/IP Port 44818 für Messaging und 2222 für I/O, die S7-Kommunikation läuft über ISO-TSAP auf Port 102.

• Port geschlossen: Der Dienst ist auf dem Gerät nicht aktiv, etwa weil eine Funktion deaktiviert wurde oder das Gerät nach einem Update andere Standardeinstellungen hat.
• Keine Antwort: Eine Firewall oder eine Zugriffsliste zwischen den Netzen filtert. Frage nach kürzlich geänderten Regeln.
• Verbindung wird abgewiesen: Der Dienst läuft, akzeptiert aber nur bestimmte Partner oder hat keine freien Verbindungen mehr.

Für die gezielte Prüfung typischer OT-Dienste an ausgewählten Adressen gibt es den OT Port Checker. Scanne in Produktionsnetzen nur mit Freigabe und so schmal wie möglich, denn manche ältere Geräte reagieren empfindlich auf unerwarteten Verkehr.

Schritt 5: Anwendung – Konfiguration und Projekt

Erst wenn die Verbindung bis zum Dienst steht, lohnt sich der Blick in die Anwendung. Typische Ursachen auf dieser Ebene:

• Falscher Gerätename, falsche Adresse oder falsche Slot-/Rack-Angabe in der Projektierung.
• Abweichende Projekt- oder Firmwarestände zwischen Engineering-Station, Steuerung und HMI.
• Abgelaufene Zertifikate oder geänderte Zugangsdaten, etwa bei verschlüsselten Verbindungen.
• Lizenz- oder Ressourcengrenzen, etwa die maximale Zahl gleichzeitiger Verbindungen.

Die Diagnosepuffer von Steuerungen und die Logs von HMI, SCADA oder Gateway sind hier die wichtigste Quelle. Lies sie, bevor du etwas neu lädst.

Was die Fehlersuche schneller macht

1. Eine Änderung zur Zeit: Sonst weißt du nicht, was geholfen hat.
2. Alles notieren: Uhrzeit, Prüfung, Ergebnis. Das hilft bei der Übergabe und bei der nächsten Störung.
3. Vergleichen: Ein baugleiches, funktionierendes Gerät ist die beste Referenz.
4. Dokumentation pflegen: Netzplan, Adressplan und Port-Belegung, die stimmen, sparen bei jeder Störung Zeit.
5. Nachbereiten: Ursache und Lösung festhalten und prüfen, ob die Störung durch Monitoring früher erkennbar gewesen wäre. Das BSI hat dazu Empfehlungen zu Monitoring und Anomalieerkennung in Produktionsnetzwerken veröffentlicht.

Eine kompakte Sammlung von Prüfpfaden findest du in OT Erste-Hilfe, Rechner und Nachschlagehilfen für den Alltag in der OT Toolbox.

Häufige Fragen zur Fehlersuche im Produktionsnetz

Quellen

• RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses
• RFC 826: An Ethernet Address Resolution Protocol (ARP)
• RFC 1918: Address Allocation for Private Internets
• IANA: Service Name and Transport Protocol Port Number Registry
• BSI: Empfehlungen für Betreiber von ICS (Monitoring, Fernwartung, Top 10 Bedrohungen)

Stand: 15. Oktober 2026.