Zum Inhalt springen
AMA SYSTEMS

Profinet-Diagnose mit TIA Portal

Geprüft von Alexandru Andronic (Siemens SITRAIN)·Stand:

Nachts um zwei, die Anlage steht: Ein Kommunikationsproblem liegt vor, meist ist ein PROFINET-Teilnehmer nicht mehr erreichbar. Je nach CPU und Kommunikationsschnittstelle wird der Diagnosezustand über ERROR-, BF- oder MAINT-LEDs signalisiert. Wer jetzt blind Kabel tauscht oder auf Verdacht Baugruppen wechselt, verliert wertvolle Produktionszeit.

Das TIA Portal bietet eine klare Methodik, um PROFINET-Störungen vom unklaren Sammelalarm bis zum betroffenen Netzwerksegment herunterzubrechen. Dieser Leitfaden zeigt den effizienten Weg durch die Netzsicht, den Diagnosepuffer und die Port-Eigenschaften.

Der direkte Weg zum Fehler: Systematische Diagnose

Wenn ein Teilnehmer ausfällt, ist die Projektierungssicht im TIA Portal der erste Anlaufpunkt. Das Ziel ist es, den fehlerhaften Knotenpunkt einzugrenzen, bevor der Schaltschrank geöffnet wird.

  1. Erreichbare Teilnehmer (Accessible devices) aufrufen: Zeigt die über die ausgewählte PG/PC-Schnittstelle auffindbaren Geräte auf DCP-Ebene. Fehlt hier ein Gerät, kann das an einer falschen Schnittstelle, einer Netzwerksegmentierung, fehlender Spannungsversorgung oder abweichender Namens-/IP-Konfiguration liegen.
  2. Online verbinden: Das Projekt mit der CPU verbinden. Das TIA Portal gleicht nun das Offline-Projekt mit dem Ist-Zustand ab.
  3. Netzsicht / Gerätesicht öffnen: In der Netz-Topologie erscheinen Status-Symbole an den einzelnen Teilnehmern. Das hilft, den betroffenen Knoten einzugrenzen.
  4. Diagnosepuffer der CPU prüfen: Hier finden sich die genauen Zeitstempel und Event-IDs zum Ausfall. Ereignisbezogene Ausfälle können im Anwenderprogramm zudem über Organisationsbausteine wie OB82/OB86 verarbeitet werden.
  5. Topologiesicht prüfen: Wurden die Ports im Projekt fest verschaltet, kann die Online-Topologiesicht (LLDP) helfen, eine fehlende Nachbarschaft oder einen abgerissenen Link-Abschnitt zu lokalisieren.

Status-Symbole in der Netzsicht richtig deuten

Die Symbole in der Online-Ansicht des TIA Portals geben die Richtung der Fehlersuche vor. Die genaue Interpretation erfolgt über Tooltips, den Diagnosepuffer oder die gerätespezifische Diagnose.

TIA Portal Status-Symbole und erste Maßnahmen
Symbol / AnzeigeBedeutungErste Maßnahme
Rotes KreuzTeilnehmer ausgefallen / nicht erreichbarSpannungsversorgung des Knotens messen, Buskabel zum Vorgänger prüfen.
Grüner / gelber SchraubenschlüsselWartungsbedarf (required) / Wartungsanforderung (demanded)Im erweiterten PROFINET-Wartungskonzept prüfen: Gerätesicht öffnen und konkrete Ursache (z. B. gezogenes Submodul, Verschleißgrenze) auslesen.
Ausrufezeichen auf gelbem GrundWarnung / Diagnosealarm anstehendKanaldiagnose öffnen (z. B. Drahtbruch am Sensor oder Kurzschluss am Ausgang).
Graues FragezeichenUnbekanntes Gerät / InkompatibilitätGesteckte Artikelnummer und Firmware-Version mit der Projektierung abgleichen.
Grüner HakenBaugruppe logisch fehlerfreiKein Handlungsbedarf auf Baugruppenebene laut aktueller Systemdiagnose.

Häufige Ursachenklassen und ihre Eingrenzung

Der IO-Controller ordnet ein PROFINET IO-Device beim Hochlauf primär über dessen projektierten Gerätenamen zu. Stimmen die Konfigurationen nicht überein, läuft der Bus nicht fehlerfrei an.

PROFINET Fehlerbilder und Eingrenzung
UrsachenklasseTypisches SymptomEingrenzung / Behebung
Gerätetausch ohne korrekte NamenszuweisungErsatzteil leuchtet grün (Link vorhanden), CPU meldet Teilnehmerausfall. Gerät auf DCP-Ebene sichtbar, ICMP-Ping auf IP schlägt jedoch fehl.Gerätenamen über 'Online & Diagnose' zuweisen. Der Name ist für die IO-Zuordnung entscheidend, die IP wird vom Controller zugewiesen. Automatische Namensvergabe erfordert eine projektierte und geladene Topologie, aktivierten 'Gerätetausch ohne Wechselmedium' und LLDP-Unterstützung.
Leitungsbruch / Stecker defektBei Linientopologie fallen mehrere Teilnehmer ab einem bestimmten Punkt aus.Letzten erreichbaren Port und ersten nicht erreichbaren Port identifizieren. Leitung oder Stecker dazwischen prüfen.
Schirmung / EMV-ProblemeCRC- oder Frame-Fehler, Link-Abbrüche (Flapping), Telegrammverluste oder Watchdog-Ausfälle.Schirmauflage an Switches und Peripherien prüfen. Potenzialausgleich messen. Die projektierte PROFINET-Updatezeit selbst erhöht sich durch EMV nicht dynamisch.
IP- / NamenskonfliktMehrere Teilnehmer melden Fehler, Netzwerkverhalten instabil.'Erreichbare Teilnehmer' prüfen. Doppelte IP-Adressen oder gleiche PROFINET-Namen auflösen.

Nachbarschaftserkennung (LLDP) und Portdiagnose

Das Link Layer Discovery Protocol (LLDP) ist ein zentrales Werkzeug bei der Fehlersuche. In der TIA Portal Gerätesicht des Nachbargeräts lassen sich unter 'Online & Diagnose' -> 'PROFINET-Schnittstelle' -> 'Ports' die physikalischen Zustände ablesen.

  • •Link-Status: Zeigt die physikalische elektrische Verbindung (Link Up / Link Down).
  • •Nachbar-Information: Zeigt an, welches Gerät am entsprechenden Port detektiert wird.
  • •Port-Statistik (Fehler / Errors): CRC-, Alignment-, Fragment- oder Linkfehler deuten stark auf Probleme mit dem Medium, dem Stecker, dem Port oder der EMV hin.
  • •Port-Statistik (Verworfene Pakete / Discards): Entstehen dagegen meist durch Queue-Überlauf, hohe Verkehrslast, Filterung oder Ressourcenengpässe im Switch/Device.

Verlauf, Gegenport, Linkereignisse und die physische Prüfung müssen bei der Portdiagnose gemeinsam bewertet werden.

Besonderheit: Fehlersichere Teilnehmer (F-Peripherie)

Passivierung von Sicherheitsbaugruppen

Bei einem PROFIsafe-Kommunikationsfehler wird die betroffene F-Peripherie passiviert und geht in den sicheren Zustand über.

Nach Beseitigung eines PROFIsafe-Kommunikationsfehlers ist immer eine manuelle Wiedereingliederung zwingend erforderlich. Ob bei Hardware- oder Kanalfehlern stattdessen eine automatische Wiedereingliederung erfolgen darf, hängt von den projektierten F-Parametern und der Sicherheitsbewertung ab.

Eine manuelle Quittierung erfolgt nach dem dokumentierten SIMATIC-Safety-Verfahren, sobald das Anforderungssignal ACK_REQ ansteht: über eine positive Flanke an der Variablen ACK_REI im betreffenden F-I/O-DB oder global über die Anweisung ACK_GL. Diese Flanke muss zwingend aus einer manuellen Bedienhandlung stammen - eine automatisch im Programm erzeugte Quittierung ist unzulässig. Am HMI sind hierfür sichere Bedienkonzepte, wie das Siemens-Muster ACK_OP, umzusetzen.

Häufige Fragen

Ich habe ein defektes PROFINET-Gerät getauscht, aber die CPU erkennt es nicht. Warum?

Ein IO-Device wird vom Controller primär über seinen PROFINET-Gerätenamen identifiziert, die IP-Adresse wird meist im Anschluss zugewiesen. Ein neues Ersatzteil benötigt exakt den Namen aus dem Projekt. Ein automatischer Tausch funktioniert nur, wenn die Topologie verschaltet und geladen ist, der Gerätetausch ohne Wechselmedium am Controller aktiviert ist, das Überschreiben der Gerätenamen erlaubt wird und das Gerät im Werkszustand ist.

Wie lese ich die Fehlerhistorie bei sporadischen PROFINET-Ausfällen aus?

Der Diagnosepuffer der CPU speichert Kommen- und Gehen-Ereignisse mit Zeitstempel. Systemfunktionen wie DeviceStates liefern hingegen nur den aktuellen Zustand des IO-Systems. Um eine dauerhafte Historie zu erzeugen, müssen ereignisbezogene Ausfälle (etwa über OB82/OB86) im Anwenderprogramm mit Zeitstempel abgefangen und in einem Datenbaustein gespeichert werden.

Woran erkenne ich, ob ein Netzwerkkabel oder der Switch-Port defekt ist?

Die Port-Statistiken in der TIA Portal Online-Diagnose liefern Anhaltspunkte. Steigen die Fehlerzähler (Errors wie CRC oder Alignment), ist oft das Medium oder die EMV-Schirmung schuld. Steigen nur die verworfenen Pakete (Discards), deutet das auf Überlastung oder Ressourcenengpässe am Switch hin.

Grundlagen & Quellen