So verwandeln Sie PLC- und SCADA-Diagnosen in zuverlässige Instandhaltung, ohne die Steuerung zu beeinträchtigen.
Das Signal ist bereits in der Steuerungsebene vorhanden
Eine PLC läuft oft weiter, während sich ihr Zustand verschlechtert. Sehen Sie sich zunächst den Diagnoseverlauf an, nicht das Mimic. Kommunikationsunterbrechungen nehmen langsam zu. Ein Remote-I/O-Modul meldet sporadische Fehler. Auf der SCADA-Ebene wiederholen sich Aussetzer, bevor die Produktion überhaupt zum Stillstand kommt. Das sind Frühwarnungen, kein Rauschen. Moderne Steuerungen stellen diese Daten bereits bereit. Sie benötigen nicht immer ein neues Sensornetzwerk. Die Herausforderung besteht darin, jedem Signal ein sinnvolles Ziel zu geben. Dieses Ziel ist ein Instandhaltungsdatensatz, der einem realen Asset zugeordnet ist.
Schritt 1 — Echte Zustände der Steuerungsdiagnose erfassen
Prädiktive Logik muss Signale verwenden, die ein Gerät tatsächlich unterstützt. Gehen Sie nicht davon aus, dass jede PLC dieselben Zustandsdaten bereitstellt. Beobachten Sie bei einem Allen-Bradley ControlLogix (etwa einem Allen-Bradley ControlLogix Processor) oder einem CompactLogix-System die Fehlerzähler der EtherNet/IP-Ports auf Kommunikationskarten wie dem 1756 ControlLogix Communications Module. Erfassen Sie die Anzahl behebbarer Fehler pro Remote-Station als Trend. Fragen Sie bei einem über Modbus TCP erreichbaren Woodward-Controller (in Überwachungssystemen mit Woodward I/O modules) die Register für erforderliche Wartung und Lebensdauergrenzen ab. Einige Geräte melden interne Fehler oder eine ungewöhnliche Versorgungsspannung direkt.
-
Schritt 1 — Listen Sie jede Diagnose auf, die das Zielgerät tatsächlich bereitstellt.
-
Schritt 2 — Erfassen Sie die Zähler wöchentlich als Trend, da die Häufigkeit den Verschleiß besser erkennen lässt als ein einzelnes Ereignis.
-
Schritt 3 — Lösen Sie nur bei einem ansteigenden Verlauf oder einer bestimmten Dauer einen Alarm aus, nicht bei einem einzelnen kurzen Ausschlag.
-
Schritt 4 — Verknüpfen Sie jeden Zähler mit genau einem gekennzeichneten Asset, niemals mit einem generischen Rack.
Schritt 2 — Machen Sie nicht aus jedem Alarm einen Auftrag
SCADA beansprucht die Aufmerksamkeit der Bediener. Die Instandhaltung entscheidet, wer zum Werkzeug greift. Wer beides verwechselt, begräbt echten Verschleiß unter unnötigen Aufträgen. Ein Hochtemperaturalarm kann lediglich normales Produktionsverhalten anzeigen. Ein kurzer Aussetzer kann sich von selbst beheben. Qualifizieren Sie daher den Zustand, bevor Sie eine Arbeit anlegen. Wiederholung ist aussagekräftiger als ein einzelnes Ereignis. Die Dauer ist oft aussagekräftiger als die maximale Ausprägung. Eine langsame Drift unterhalb der Alarmschwelle kann dennoch einen Einsatz rechtfertigen. Trennen Sie außerdem die Quittierung vom Abschluss. Ein Bediener bestätigt, dass ein Fehler gesehen wurde. Das beweist nicht, dass die Anlage repariert wurde.
-
Schritt 1 — Fügen Sie eine Regel hinzu, die drei Wiederholungen innerhalb von sieben Tagen benötigt, bevor sie eine Arbeit auslöst.
-
Schritt 2 — Fügen Sie Kontext hinzu: das Asset, den Trend und frühere Reparaturen.
-
Schritt 3 — Schließen Sie den Auftrag erst, nachdem die Arbeit erledigt und dokumentiert wurde.
Die Reparaturhistorie schärft das Modell
Historian-Daten zeigen, was vor einem Fehler passiert ist. Die Instandhaltungshistorie zeigt, was geschah, nachdem jemand nachgesehen hatte. Angenommen, ein Kommunikationsfehler erzeugt immer wieder Aufträge. Jedes Mal finden die Techniker keinen Hardwaredefekt. Der Auslöser ist wahrscheinlich zu empfindlich eingestellt. Wenn jedoch dasselbe Ereignis stets mit dem Austausch eines Steckverbinders endet, sollten Sie diesem Muster vertrauen. Es verdient eine frühere Beachtung. Abgeschlossene Arbeiten trennen Symptom und Ursache. Ein scheinbarer I/O-Fehler kann auf ein Feldgerät zurückgehen, das die Stromversorgung verloren hat. Der Austausch des Moduls würde das falsche Asset reparieren. Die Abschlussnotiz bewahrt die tatsächliche Ursache für die nächste Schicht.
Integrieren Sie ohne zusätzliches Risiko
Ein CMMS darf nicht zu einem privilegierten Client des Steuerungssystems werden. Leiten Sie Diagnosedaten über eine Datenebene nach außen. Beziehen Sie den Trend aus SCADA oder einem Historian. Verwenden Sie OPC UA im Nur-Lese-Modus für standardisierte Zustands- und Diagnoseinformationen. Ein Integrationsdienst übergibt anschließend qualifizierte Ereignisse per API an die Instandhaltungsplattform. So bleibt der Instandhaltungsdatenverkehr von zeitkritischer Logik getrennt. Prädiktive Berechnungen müssen nicht in der Steuerung laufen. Schützen Sie außerdem das Netzwerk. Eine Instandhaltungsanwendung muss nur selten in den PLC-Speicher schreiben. Beschränken Sie ihren Zugriff auf das Lesen. Befolgen Sie den Änderungsmanagementprozess des Werks, bevor eine automatisierte Verbindung die Produktion erreicht. Korrigieren Sie schließlich Ihre Uhren. Ein SCADA-Ereignis, das mehrere Minuten von einem CMMS-Datensatz abweicht, macht die Rekonstruktion des Fehlers zunichte.
Fazit & Handlungsempfehlung
Prädiktive Instandhaltung belohnt Geduld und einen sauberen Datenfluss, nicht ausgeklügelte Dashboards. Erfassen Sie zunächst nur die Zustände, die Ihre Geräte tatsächlich bereitstellen. Qualifizieren Sie anschließend einen Zustand anhand von Wiederholung und Dauer, bevor Sie einen Auftrag anlegen. Lassen Sie außerdem eine verifizierte Reparaturhistorie Ihre Auslöser mit der Zeit verbessern. Lassen Sie das CMMS jedoch niemals in die Steuerungslogik schreiben oder das Änderungsmanagement umgehen. Bauen Sie daher einen Pfad mit Lesezugriff über Historian und OPC UA und synchronisieren Sie die Zeit. Betrachten Sie schließlich auch die Steuerungsinfrastruktur selbst als wartbare Ausrüstung. Beginnen Sie diese Woche mit einer kritischen EtherNet/IP-Verbindung. Beweisen Sie den Kreislauf durchgängig, bevor Sie ihn im gesamten Werk ausrollen.
Autor: Sun Yifei ist ein Ingenieur für industrielle Automatisierung mit mehr als 10 Jahren Erfahrung in PLC-, DCS- und Steuerungssystemen.
