Condition-Monitoring- und Diagnosesysteme verzeichnen nicht ohne Grund eine steigende Nachfrage: Sie unterstützen die Betreiber dabei, bevorstehende Anlagenausfälle rechtzeitig zu erkennen und deren Ursachen vorausschauend zu beheben. Dadurch kann effiziente Wartung mit zuverlässig planbaren Stillstandzeiten erreicht werden und es lässt sich zudem eine höhere Energie-Effizienz durch Verringerung ungeplanter Leerlaufzeiten erzielen. Kurzum: Die aus Condition-Monitoring-Systemen gewonnenen Aussagen sind in der betrieblichen Umsetzung die Basis für neue Wartungs- und Instandhaltungskonzepte und liefern valide Maschineninformationen für die übergeordneten Informationssysteme. Technologie-Anbieter aus den Bereichen elektrischer, pneumatischer und hy­draulischer Antriebstechnik, aus der Förder-, Schmier- und Lagertechnik bieten – jeweils für ihre Technologie – seit geraumer Zeit derartige Lösungen an und entwickeln diese rasant weiter. – Ein paar praktische Beispiele:

... und hier ein Greifsystem mit integrierter Condition-Monitoring-Funktion – der dort angebrachte Vakuum-Ejektor verfügt über eine integrierte Wartungs­prüfung um mögliche Leckagen zu vermeiden.

© VDMA

Rein aus technologischer Sicht ist das Thema Condition Monitoring also bereits weit entwickelt. Die Maschinenbauer sehen sich nun mit der Herausforderung konfrontiert, aus diesen Systemen ein für ihre Maschine oder Anlage relevantes Maschinendiagnosesystem zu erstellen und in die Automatisierungskonzeption zu integrieren. Aus technologischer Sicht ist dies die Kernkompetenz von Technologielieferanten und Maschinenbauern: Prozess- und qualitätsrelevante Größen werden interpretiert und überwacht, das Bewegungsverhalten der Aktuatoren wird auf Fehlerbilder analysiert, Parameter für langfristige Ausfälle werden ermittelt und modellgestützte Diagnose in Feldgeräten untergebracht.

So weit so gut – aus automatisierungstechnischer Sicht steckt dieses Gebiet bisher allerdings noch in den Kinder­schuhen: Denn in der Realität muss die Konzeption eines Maschinendiagnosesystems für jede Applikation neu konzipiert und programmiert werden. Dies liegt daran, dass unterschiedliche Hersteller nicht nur unterschiedliche Datenprotokolle und Übertragungsmechanismen verwenden, sondern auch unterschiedliche informationstechnische Konzepte verfolgen. Erfahrungen aus konkret umgesetzten Projekten der Vergangenheit – sei es in Verpackungsmaschinen, in der Automobil-Endmontage oder im Bereich der Werkzeugmaschinen – belegen es: Immer wenn Condition-Monitoring-Funktionen unterschiedlicher Technologien und Hersteller zu einem Konzept zusammengestellt werden mussten, stiegen Komplexität und Integrationskosten. Der Grund hierfür ist das Problem der heutigen heterogenen Landschaft:

■ Die Zusammenführung unterschiedlicher Systeme verursacht hohe Komplexität.
■ Es entsteht hoher Aufwand für das Engineering, da es keine übergeordneten Inbetriebnahme-Tools gibt.
■ Die Form der Nutzdaten und deren Inhalte sind unterschiedlich: Die Vereinheitlichung der Diagnosedaten und Statusmeldungen muss aufwendig durch den Integrator erfolgen.
■ Die letzte Strecke zum Nutzer fehlt: Die Informationen müssen immer bis zu den Systemen durchgereicht werden, an denen die unterschiedlichen Nutzergruppen diese abfragen. Eine Differenzierung nach Benutzergruppen erfordert unterschiedliche Bereitstellung über das Netz, über LEDs, über Operator-Panels oder über Mailserver. Zusätzlich müssen die Nutzdaten an MES- oder ERP-Systeme übergeben werden.

All dies steigert den Aufwand für die Integration von Condition-Monitoring- und Diagnosesystemen, erhöht die Komplexität und treibt letztlich die Kosten unnötig in die Höhe. Angesichts dieser Tatsachen haben die Maschinenbauer für die Integration der Condition-Monitoring-Systeme unterschiedlicher Technologien klare Forderungen aufgestellt:

■ Einfache, standardisierte Parametrierung und Einbindung in die vorhandenen Automatisierungs- und Kommunikationskonzepte.
■ Einheitliche Daten- und Zustandsanzeigen.
■ Vereinfachte Datenauswertung durch Standardisierung.

Klar ist: Die Umsetzung der Forderungen ist über verschiedene Hersteller und Technologien nur möglich, wenn Standards entwickelt werden. Als Dachverband der Maschinen- und Anlagenhersteller hat sich daher der VDMA dieser Aufgabe angenommen. Nach intensiven Beratungen der Spezialisten wurde offensichtlich: Es fehlen Basisdefinitionen und ein einheitliches Architekturverständnis für Condition Monitoring. Deshalb hat sich die dafür ins Leben gerufene Arbeitsgruppe entschieden, zunächst die Ausarbeitung einer Referenzarchitektur für den Bereich von Condition Monitoring und Maschinendiagnose anzugehen, um damit die Basis für die Erstellung von Kommunikationsprofilen und weiterer normativer Arbeit zu schaffen. Das Ergebnis liegt mittlerweile mit dem Einheitsblatt VDMA 24582 vor.

Die Referenzarchitektur

Die im VDMA Einheitsblatt 24582 definierte Referenzarchitektur verfolgt einen flexiblen, allgemeingültigen Ansatz. Sie definiert einen grundlegenden Rahmen mit übergreifenden Schnittstellen, der in Bezug auf Algorithmen und Funktionen, aber auch auf eingesetzte Technologien weiter spezialisiert werden soll. Dabei wurden in der Arbeitsgruppe verschiedene Sichten identifiziert. Neben der Funktionssicht, bei der einzelne Funktionen für Condition Monitoring im Fokus stehen, sind dies die Applikationssicht, bei der die Verknüpfung der einzelnen Funktionen gemäß der kausalen Kette in der Anwendung verknüpft sind, und die Automatisierungssicht, die die Implementierung der Funktionen in den Komponenten des Automatisierungssystems betrachtet.

Der Kern des Einheitsblatts ist die Definition eines Funktionsbausteins, der auf Basis von Eingangsdaten den Algorithmus einer Aktualwert-Aufbereitung kapselt. Dabei können die Ergebnisse des Algorithmus als Ausgänge durch nachgeschaltete Blöcke weiter verarbeitet oder visualisiert werden.

Aufbau des einheitlichen Funktionsblocks für Condition-Monitoring-Funktionen.

© VDMA

Die Statusbildung bewertet die Ausgänge und bildet auf Basis von Referenz- oder Schwellwerten ein vereinheitlichtes Statussignal, das typisch als Ampel dargestellt wird. Als Statuswerte sind definiert:

■ Gut
■ Warnung
■ Kritischer Zustand
■ Defekt/Fehler
■ Keine Zustandsaussage

Neben den Parametern zur Einstellung der Aktualwert-Aufbereitung kann der Block durch Setzen eines definierten Betriebsmodus weiter gesteuert werden (zum Beispiel manueller Betrieb, Teach-Mode, Rücksetzen). Eine einheitliche Identifikation stellt Auskunftsfunktionen über Blocktyp, Hersteller, Anlagenkennzeichen usw. zur Verfügung. Eine formalisierte Beschreibung der Schnittstellen ist im Einheitsblatt vorhanden und kann als Input für die Abbildung auf Datenstrukturen etwa für die Feldbus-Kommunikation dienen.

In Condition-Monitoring-Applikationen werden Einzelinformationen, wie sie durch die Blöcke ermittelt werden, miteinander verknüpft, um eine aggregierte Information über den Zustand beispielsweise einer Maschine zu erstellen. Diese Aggregation folgt der funktionalen Hie­rarchie der Anwendung. Die Applikationssicht beantwortet daher die Frage, auf welche Teile einer Maschine sich die CM-Funktionen beziehen beziehungsweise welche nachfolgenden Anlagenteile von einem Fehler betroffen sind. Dies ist für den späteren Betrieb des Systems deshalb wesentlich, weil die Information aus dem System die Entscheidungsgrundlage für eventuelle Instandhaltungsmaßnahmen sein kann. Das Einheitsblatt definiert Aggregationsblöcke, wie die gewünschte Verknüpfung von Einzelinformationen entsprechend der funktionalen Hierarchie erreicht werden kann. Neben einfachen Aggregationsfunktionen mit binären Verknüpfungen sind auch komplexere Blöcke, zum Beispiel mit gewichteten Eingängen und spezifischen Verknüpfungsalgorithmen realisierbar.

Die Automatisierungssicht soll die Frage beantworten, wo und wie die in der Funktionssicht definierten Funktions­blöcke implementiert werden. Da­raus leiten sich Kommunikationsan­forderungen im verteilten Automatisierungssystem ab – hinsichtlich der Eingangs- und Ausgangsdaten der Blöcke, ihrer Parametrierung und bezüglich der Aggregationsfunktion.

Was die Automatisierungsarchitektur betrifft, werden im Einheitsblatt keine Einschränkungen vorgenommen. Die Blöcke sind so definiert, dass sie in Feldgeräten und in Steuerungen ebenso implementierbar sind, wie in einem OPC-Server, der wiederum Informationsquelle für „Manufacturing Execution Systems“ (MES) oder das ERP-System sein kann. Dies erfordert spezifische Umsetzungen der Blöcke, die dann etwa als Elemente in Bibliotheken angeboten werden können, was jedoch nicht im Fokus der Arbeiten im VDMA ist. Das Einheitsblatt wurde daher anderen Organisationen zur Verfügung gestellt, die die spezifische Abbildung durchführen.

Auf Basis des generischen Condition-Monitoring-Funktionsblocks wurde im Einheitsblatt zudem eine Reihe von Standardblöcken mit allgemein verwendbaren Funktionen wie Zähler, Zeitmesser, Minimal-, Maximal- und Mittelwertbildern oder FFT-Funktionen beschrieben. Weiterhin sind typische Blöcke aus verschiedenen Anwendungsgebieten dargestellt. Hierbei werden folgende Gebiete betrachtet:

■ Antriebstechnik
■ Dichtungstechnik
■ Kühl- und Schmierstofftechnik
■ Hydraulik
■ Pneumatik

Die Darstellung der Blöcke erfolgt aus der Nutzerperspektive, die für den generischen Condition-Monitoring-Block definierten Schnittstellen werden näher detailliert. Eine Festlegung auf spezifische Algorithmen ist wiederum nicht im Fokus des Einheitsblatts. Hier können Hersteller von Komponenten oder auch Dienstleister, die Bibliotheken von Condition-Monitoring-Funktionen anbieten, eigene spezialisierte Algorithmen implementieren. Sie nutzen hierzu die ver­einheitlichten Schnittstellen für Ampelstatus, Statuswort, Identifikation und Blocksteuerung bei der Implementierung und können so Bausteine anbieten, die mit wenig Engineering-Aufwand in einer Applikationssicht integrierbar sind. Das Konzept der Function Blocks erlaubt somit eine Wiederverwendung und schützt gleichzeitig das Know-how der Anbieter.

Bis hier lässt demnach festhalten: Eine einfache Anwendung von Condition Monitoring wird möglich sein, wenn auf der Feldbus-Ebene entsprechende Profile implementiert und wenn Bibliotheken der Funktionsbausteine verfügbar sind und die Kommunikation oberhalb der Steuerungsebene standardisiert ist.

Autoren: Prof. Dr. Martin Wollschlaeger ist Inhaber der Professur Prozesskommunikation an der Fakultät Informatik der TU Dresden und Albrecht Winter ist Leiter der Geschäftsfeldentwicklung bei J. Schmalz, Glatten, und Mit-Initiator des Arbeitskreises „Condition Monitoring“ beim VDMA.

In dem Artikel "Umsetzung des VDMA-Einheitsblattes 24582" zeigen die Autoren auf, welche Aktivitäten in den letztgenannten Bereichen bereits von der Normungsgruppe angestoßen wurde.