Profibus bleibt eines der am weitesten verbreiteten Feldbusprotokolle in der industriellen Automatisierung, indem Sensoren, Aktoren, Antriebe und Steuerungen über ein einziges digitales Netzwerk miteinander verbunden werden. Wenn ein Profibus-Netzwerk Fehler hat – sei es durch Kabeldegradation, Geräteausfall oder Konfigurationsfehler – ist die schnelle Diagnose der Ursache entscheidend, um Ausfallzeiten zu minimieren. Diagnosemeldungen sind das leistungsfähigste Werkzeug, das den Technikern zur Verfügung steht, da sie direkte, strukturierte Informationen über den Zustand jedes Geräts im Segment liefern. Dieser Artikel erklärt, wie man Profibus Diagnosemeldungen interpretiert und nutzt, um Netzwerkprobleme schnell zu erkennen und zu lösen, über die grundlegende Fehlersuche hinaus zu einem systematischen, datengesteuerten Ansatz.

Verstehen von Profibus Diagnostic Messages

Diagnosemeldungen in Profibus werden sowohl von Mastern als auch von Slaves generiert, im Rahmen des normalen zyklischen Datenaustauschs übertragen oder können azyklisch über DPV1-Dienste angefordert werden, die detaillierte Statusinformationen, Fehlercodes und gerätespezifische Diagnosen enthalten. Der Schlüssel ist, dass sie über alle Profibus-Geräte standardisiert sind, so dass ein Techniker, der mit dem Format vertraut ist, die gleichen Diagnosedaten auf einem Siemens-Master, einer Mitsubishi-SPS oder einem Diagnosetool eines Drittanbieters interpretieren kann.

Profibus DP (Decentralized Periphery) verwendet eine Master-Slave-Architektur. Der Master (normalerweise eine SPS oder DCS) befragt jeden Slave zyklisch. Jeder Slave antwortet mit seinen Eingangsdaten und setzt, wenn ein Diagnoseereignis aufgetreten ist, ein Diagnosebit im Antworttelegramm. Der Master kann dann den vollständigen Diagnosepuffer von diesem Slave anfordern. Für Profibus PA (Process Automation) gelten die gleichen Diagnoseprinzipien, obwohl die physikalische Schicht unterschiedlich ist (MBP oder FISCO).

Die Diagnostische Telegrammstruktur

Ein Profibus-Diagnosetelegramm besteht aus mehreren Bytes, die in IEC 61158 und EN 50170 definiert sind. Die ersten beiden Bytes geben die Standard-Diagnosedatenlänge und den Stationsstatus an. Das Stationsstatusbyte (Byte 1) enthält Flags wie:

  • Bit 0 – Master Lock: Setzt ein, wenn der Slave noch nicht von seinem Master parametriert ist.
  • Bit 1 – Parameter Request: Gibt an, dass der Slave Parameterdaten vom Master benötigt.
  • Bit 2 – Not Ready: Der Slave ist nicht bereit, Benutzerdaten auszutauschen.
  • Bit 3 – Configuration Fault: Die aktuelle Konfiguration des Slaves entspricht nicht der Erwartung des Masters.
  • Bit 4 – Externe Diagnose: Der Slave hat einen externen Fehler (z.B. einen Sensorfehler), der über eine separate Diagnoseanforderung gelesen werden muss.
  • Bit 5 – Slave wird nicht unterstützt: Der Slave-Typ wird vom Master nicht unterstützt.
  • Bit 6 – Kein Datenaustausch: Der Slave wurde vom Master nicht angesprochen.
  • Bit 7 – Slave deaktiviert: Der Master hat den Slave deaktiviert.

Das Telegramm enthält nach dem Stationsstatus die herstellerspezifischen Diagnosedaten (auch modulspezifische oder kanalspezifische Diagnose genannt) und die textbasierte Diagnose, sofern in der GSD-Datei definiert. Die GSD-Datei (General Station Description) definiert für jedes Gerät, welche Diagnosebits welche Fehlermeldungen abbilden. Ohne die GSD-Datei können die Rohbytes auf einen Fehler hinweisen, die genaue Bedeutung kann jedoch mehrdeutig sein.

Gemeinsame Diagnosebotschaften und ihre Interpretationen

Während jeder Gerätehersteller benutzerdefinierte Diagnosecodes definieren kann, sind viele Fehlermuster universell. Wenn man diese Muster erkennt, kann ein Techniker innerhalb von Minuten von "das Netzwerk ist fehlerhaft" zu "der Kodierer an der Station 12 hat einen Drahtbruch auf Kanal 3" wechseln.

Stationsdiagnose (Bit-Level)

  • Konfigurationsfehler (Bit 3 des Stationsstatus): Die tatsächliche Konfiguration des Slaves unterscheidet sich von der des Masters, die während des Starts gespeichert wurde. Dies tritt häufig auf, wenn ein Modul durch einen anderen Typ ersetzt wird oder wenn die Geräteadresse geändert wird, ohne den Master zu aktualisieren.
  • Externe Diagnose (Bit 4): Der Slave hat ein Problem, das er kommunizieren möchte. Der Master muss dann eine azyklische Lesefunktion (DPV1) durchführen, um die erweiterten Diagnosedaten abzurufen. Hier liegen die nützlichsten Informationen.
  • Not Ready (Bit 2): Das Gerät ist eingeschaltet, aber noch nicht initialisiert.

Modul / Slot Diagnose

In modularen I/O-Stationen stellt jeder Slot ein physikalisches oder logisches Modul dar. Diagnosedaten können angeben, welcher Slot einen Fehler aufweist.

  • Slot X – Kurzschluss oder Überlastung – typischerweise auf einem Ausgabemodul.
  • Slot X – Wire break – für Stromschleifen oder 4-20 mA-Eingänge.
  • Slot X – Sensorversorgung fehlt – die interne Leistung des Moduls für Sensoren ist nicht vorhanden.

Kanaldiagnose

Bei diskreten I/O-Nachrichten können Diagnosenachrichten einen bestimmten Kanal (Bit) auf einem Modul lokalisieren, beispielsweise "Channel 3 - Unterspannung" oder "Channel 7 - Parameterzuweisungsfehler". Die GSD-Datei bildet die Diagnosebytes auf menschenlesbare Zeichenfolgen ab. Ohne diese Zuordnung muss der Techniker die Bytewerte mit dem Gerätehandbuch vergleichen.

Kommunikationsfehler

  • Bus Off-Line oder Busausfall: Dies ist keine Gerätediagnose, sondern ein Master-Level-Fehler. Der Master meldet, dass er die Kommunikation mit allen Slaves verloren hat oder dass das Netzwerk elektrisch unterbrochen ist. Häufige Ursachen: fehlender Terminator, falsch angeschlossene Abschirmung oder ein totaler Kabelausfall.
  • Time-out / keine Antwort der Station: Spezifisch für ein Gerät. Der Master erwartet eine Antwort innerhalb des konfigurierten Timeouts, erhält aber keine Antwort. Dies könnte auf einen fehlerhaften Transceiver, eine falsche Baudrate oder das Ausschalten des Geräts zurückzuführen sein.
  • Doppeladressen: Der Master erkennt zwei Geräte, die auf dieselbe Profibus-Adresse reagieren. Dies geschieht normalerweise während der Inbetriebnahme, wenn Adressschalter falsch eingestellt sind.

Praktische Schritte zur effektiven Verwendung von Diagnosenachrichten

Die Bedeutung der Nachrichten zu kennen, ist nur die halbe Miete. Der folgende Schritt-für-Schritt-Prozess hilft Ihnen dabei, aus den Diagnoserohdaten einen konkreten Aktionsplan zu machen.

1. Diagnosedaten in Echtzeit überwachen

Die meisten Profibus-Master (Siemens S7‐300/400/1200/1500, Rockwell ControlLogix mit Profibus-Schnittstelle usw.) stellen einen Diagnosepuffer bereit. Verwenden Sie die Engineering-Software (z. B. TIA Portal, Schritt 7 oder Tools von Drittanbietern wie Procentec ProfiTrace oder Softings PROFIBUS Diagnostic Suite), um Diagnosetelegramme live anzuzeigen. Setzen Sie den Master so ein, dass er einen Alarm auslöst, wenn ein Slave das Bit „Externe Diagnose einstellt. Dies stellt sicher, dass Sie sofort benachrichtigt werden, wenn ein Gerät einen Fehler meldet.

2. Muster im Zeitverlauf identifizieren

Eine einzelne "Konfigurationsfehler" beim Start kann eine einmalige Fehlanpassung sein, die korrigiert wird. Eine wiederkehrende "Externe Diagnose"-Nachricht des gleichen Slaves alle paar Minuten deutet jedoch auf einen intermittierenden Fehler hin. Die Zeitstempel werden aufgezeichnet und mit Prozessereignissen korreliert (z. B. ein Motorstart, ein Ventilzyklus). Viele fortschrittliche Diagnosetools können Daten in einer CSV-Datei für eine spätere Analyse protokollieren. Suchen Sie nach Mustern wie:

  • Fehler, die nur während bestimmter Produktionsverschiebungen auftreten.
  • Fehler, die gleichzeitig auf mehreren Slaves auftreten – dies deutet auf ein physikalisches Schichtproblem (Rauschen, Erdung) hin.
  • Fehler, die im Laufe der Zeit von einem einzelnen Slave zu mehreren Slaves eskalieren – oft ein ausfallendes Gerät, das übermäßige Paketfehler erzeugt und das gesamte Segment betrifft.

3. Die Quelle mithilfe des Diagnosepuffers bestimmen

Wenn eine Diagnosenachricht eintrifft, extrahieren Sie die folgenden Informationen aus dem Telegramm:

  • Sklavenadresse (0-125).
  • Station status byte – schnell identifizieren, ob es sich um eine Konfiguration, ein externes Problem oder ein Bereitschaftsproblem handelt.
  • Diagnostische Länge – gibt an, wie viele zusätzliche Bytes folgen.
  • Moduldiagnose – Bytes, die anzeigen, welcher Slot/Kanal betroffen ist.

Wenn die Diagnosedaten herstellerspezifisch sind, müssen Sie möglicherweise das Gerätehandbuch einsehen oder die GSD-Datei in das Diagnosetool laden. Viele moderne Tools analysieren die GSD automatisch und zeigen die Nachricht im Klartext an. Beispielsweise kann eine Siemens-Station ET 200S "Modul 4: Kurzschluss am Ausgang Y0" melden.

4. Physische Verbindungen prüfen

Diagnosemeldungen reduzieren häufig den Suchbereich auf ein bestimmtes Gerät oder Kabelsegment. Einmal identifiziert, prüfen Sie die Steckverbinder, Sub-D-Steckverbinder und die Verdrahtung physisch. Verwenden Sie einen Profibus-Kabeltester (z. B. Procentec ProfiHub oder ein einfaches Oszilloskop), um die Signalqualität zu überprüfen. Überprüfen Sie:

  • lose oder korrodierte Kontakte.
  • Unsachgemäßer Abschluss – das Profibus-Segment muss genau zwei 220-Ohm-Abschlusswiderstände haben, einen an jedem physikalischen Ende.
  • Streukapazität - übermäßige oder unsachgemäße Kabeltypen können Signalflanken verschlechtern.
  • Erdschleifen – Schilde sollten an genau einem Punkt pro Segment mit PE verbunden sein.

5. Beheben und Verifizieren

Nach der Reparatur (Modul austauschen, Stecker anziehen, Adresse neu programmieren), Diagnosespeicher im Master löschen und Bus mehrere Minuten lang beobachten. Überprüfen, ob die Diagnosemeldung nicht mehr erscheint und der Slave zum normalen Datenaustausch zurückkehrt. Problem und Lösung in einem Protokoll für zukünftige Referenz dokumentieren.

Erweiterte Diagnosefunktionen: DPV1 und Alarme

Profibus DP Version 1 (DPV1) führte eine azyklische Kommunikation ein, die es dem Master ermöglicht, Diagnosedaten bei Bedarf zu lesen, ohne den zyklischen Datentransfer zu unterbrechen, was für Hochleistungsanwendungen unerlässlich ist, da der Slave weiterhin Prozessdaten senden kann, während der Master detaillierte Diagnosen liest.

Alarmbehandlung

DPV1 unterstützt auch Alarmmeldungen wie Pull/Plug-Alarme (ein Modul wird entfernt oder eingefügt), Statusalarme (Gerätezustandsänderungen) und Update-Alarme (z. B. Firmware-Upgrade vollständig), die vom Slave mit Zeitstempel versehen und in die Warteschlange gestellt werden. Der Master kann die Alarmwarteschlange lesen, indem er eine DPV1-Leseanforderung an den entsprechenden Slot/Subslot sendet. Das Verständnis der Alarmsequenz ermöglicht es einem Techniker, die chronologische Reihenfolge der Ereignisse während eines Fehlers zu rekonstruieren.

GSD File Integration

Jedes Profibus-Gerät wird mit einer GSD-Datei (GSDML- oder EDS-Format) ausgeliefert. Diese Datei enthält die Definition des Herstellers von Diagnosebytes, Alarmtypen und Parameterdaten. Das Laden der richtigen GSD-Datei in Ihr Diagnosetool ist nicht optional – es ist unerlässlich. Ohne sie arbeiten Sie mit rohen Hex-Werten. Mit ihr kann das Tool Nachrichten wie „Diagnostic: User-defined alarm, code 0x42 – Pressure sensor high anzeigen. Immer ein Archiv von GSD-Dateien für jede auf Ihrer Website verwendete Geräterevision aufbewahren.

Best Practices für Netzwerk-Problembehandlung mit Diagnose

Die Profibus-Diagnostik ist am effektivsten, wenn sie mit einer systematischen Wartungsstrategie kombiniert wird, um diese Praktiken umzusetzen, um die Häufigkeit und Schwere von Netzwerkproblemen zu verringern.

Regelmäßige Aktualisierung von Firmware- und GSD-Dateien

Gerätehersteller veröffentlichen häufig Firmware-Updates, die die Diagnosegenauigkeit verbessern und neue Alarmtypen hinzufügen. Ebenso können GSD-Dateien aktualisiert werden, um falsch zugeordnete Diagnosebits zu korrigieren. Überprüfen Sie die Website des Herstellers vierteljährlich und aktualisieren Sie Ihre Toolbibliotheken.

Pflegen Sie ein zentrales Diagnoseprotokoll

Erstellen Sie eine Datenbank oder Tabellenkalkulation, die jedes Diagnoseereignis einschließlich Zeitstempel, Slave-Adresse, Fehlercode und Auflösung aufzeichnet. Im Laufe der Zeit zeigt dieses Protokoll wiederkehrende Probleme auf, so dass Sie eine Ursachenanalyse durchführen können. Wenn beispielsweise derselbe Slave alle drei Monate "Externe Diagnose - Drahtbruch" anzeigt, kann der Terminalblock ermüdet sein und sollte präventiv ersetzt werden.

Zugpersonal für Dolmetschleistungen

Diagnosebotschaften sind nur dann sinnvoll, wenn die Menschen vor Ort sie lesen können. Investieren Sie in ein Training, das die Grundlagen von Profibus-Telegrammen abdeckt, wie man Diagnosewerkzeuge benutzt und die gängigsten Codes interpretiert. Kombinieren Sie dieses Training mit praktischen Übungen in einem Live-Profibus-Segment mit simulierten Fehlern. Dies zahlt sich in reduzierter mittlerer Reparaturzeit um ein Vielfaches aus.

Mithilfe der Diagnosehistorie können Geräte identifiziert werden, die mehr als ihren erwarteten Fehleranteil erzeugen. Ein Gerät, das wiederholt die Funktion „Externe Diagnose – Temperatur außerhalb des Bereichs setzt, könnte sich dem Ende seiner Lebensdauer nähern. Ein Austausch während eines geplanten Abschaltens verhindert einen ungeplanten Produktionsstopp.

Investieren Sie in Dedicated Diagnostic Hardware

Während der Diagnosepuffer des Masters hilfreich ist, bieten dedizierte Tools tiefere Einblicke. Ein Profibus-Analysator (z. B. ProfiTrace oder der Siemens Sort‐500) kann jedes Telegramm auf dem Bus erfassen und Telegrammwiederholungen, Fehlerrahmen und Signalqualität anzeigen. Diese Tools sind von unschätzbarem Wert für die Diagnose intermittierender physikalischer Fehlerschichten, die die zyklische Diagnose des Masters möglicherweise verfehlen.

Schlussfolgerung

Profibus Diagnosemeldungen sind nicht einfach Fehlerindikatoren, sondern strukturierte, standardisierte Daten, die einen Techniker direkt zur Ursache eines Netzwerkproblems führen können. Durch das Verständnis des Telegrammformats, die Interpretation gängiger Fehlercodes und einen methodischen Workflow zur Fehlerbehebung können Automatisierungsexperten die Diagnosezeit von Stunden auf Minuten reduzieren. In Kombination mit geeigneten Tools, regelmäßigen Schulungen und einem präventiven Wartungsprogramm wird die Diagnose zu einem strategischen Kapital für die Aufrechterhaltung der Hochverfügbarkeit in industriellen Netzwerken. Widerstehen Sie der Versuchung, das nächste Mal mit dem zufälligen Austausch von Hardware zu beginnen, sondern lesen Sie zuerst die Diagnosemeldungen. Sie sprechen direkt mit Ihnen.