Als Dachverband der Maschinen- und Anlagenhersteller hat sich der VDMA der Aufgabe angenommen, Basisdefinitionen und eine einheitliches Referenzarchitektur für Condition Monitoring zu erarbeiten und die Ergebnisse im Einheitsblatt 24582 veröffentlicht. Letzteres soll die Basis für die Erstellung von Kommunikationsprofilen und weitere normativer Arbeit schaffen. Da die Referenzarchitektur nicht spezifisch auf einzelne Zieltechnologien festgeschrieben wurde und demzufolge eine breite Anwendung auch über die Fabrikautomation hinaus erlaubt, ist jedoch auch die Umsetzung der Definitionen und ihre Übertragung in die jeweiligen Zieltechnologien erforderlich. Diesen Prozess hat die Normungsgruppe im VDMA auf drei Ebenen angestoßen:

• Die Feldbusebene, auf der entsprechende Profile zu implementieren sind.
• Die Funktionsebene, für die Bibliotheken der Funktionsbausteine verfügbar gemacht werden müssen.
• Die Kommunikation oberhalb der Steuerungsebene, die im Sinne der Datenübergabe in ERP oder MES Systeme zu standardisieren ist.

Hierbei ist zu beachten, dass für die Zieltechnologien unterschiedliche Festlegungen getroffen wurden, die bei der Umsetzung zu berücksichtigen sind. Entscheidend dabei ist, dass die Intention nicht darin besteht, existierende Festlegungen zu ändern, sondern diese vielmehr zu nutzen und weiter zu spezialisieren. Weiterhin ist zu untersuchen, in welchen Ebenen der Automatisierungsarchitektur die Zieltechnologien zum Einsatz kommen. Dies ist in Bezug auf die Bereitstellung der Eingangswerte und Parameter sowie für die Verteilung der Ausgangswerte und des Ampelstatus relevant. Hie­raus ergeben sich Kommunikationsbeziehungen zwischen den Blöcken.

Diese Überlegungen adressieren somit die im Einheitsblatt referenzierte Automatisierungssicht. So ist es beispiels­weise denkbar, dass ein Block zur Tempe­raturüberwachung direkt in einer Komponente implementiert ist oder aber als separates feldbusvernetztes Gerät an eine Steuerung angebunden ist. Schließlich kann der Sensor auch über die überlagerte IT-Infrastruktur angeschlossen sein. In den genannten Fällen ergeben sich also unterschiedliche Kommunika­tionswege und die Aggregationsblöcke der Applikationssicht müssen entsprechend implementiert werden.

Was nun die konkrete Umsetzung in den unterschiedlichen Zieltechnologien betrifft, hat sich der VDMA-Arbeitskreis darauf verständigt, zunächst mit der Profibus Nutzerorganisationen, mit der PLCopen und mit der OPC Foundation zusammenzuarbeiten. Damit lassen sich die typischen Ebenen der Automati­sierungspyramide abdecken und die Blöcke in Feldgeräten, in Steuerungen und in OPC(-UA)-Servern implementieren. Weitere Nutzerorganisationen sollen ebenfalls angesprochen werden.

Die Aktivitäten der PNO

Zur Umsetzung bei der Profibus Nutzerorganisation wurde eine Arbeitsgruppe gebildet, die die Übertragung der Funk­tionsbausteine des Einheitsblatts auf Profinet IO zum Ziel hat.

Die Übersicht der Applikationsprofile für Profibus und Profinet IO. Das Profil für Condition Monitoring soll als Common Application Profile ausgeführt werden und so als Baustein in andere Profile integrierbar sein.

© Profibus International

Dies beinhaltet die kommunikationstechnische Abbildung der Schnittstellen des Condition-Monitoring-Blocks und der entsprechenden Datenstrukturen unter Berücksichtigung der existierenden Spezifikationen wie der Guideline für Datentypen, für die Geräte-Identifikation (I&M-Functions) oder die Diagnose-Guideline. Weiterhin werden die Blöcke als Elemente im Profinet-IO-Gerätemodell positioniert. Es werden also Regeln spezifiziert, wie die Blöcke auf Submodule abgebildet werden und über welche Indizes der Zugriff auf Ampelstatus, Statuswort, Blockparameter, Identifikation etc. erfolgt. Schlussendlich sind entsprechende Konstrukte für die Gerätebeschreibungen (zum Beispiel GSDML) zu definieren.

Bei der Profibus Nutzerorganisation existieren Common Application Pro­files, die Funktionen mit Querschnittscharakter definieren und die bei der Geräteentwicklung als „Baukasten“ nutzbar sind, wenn entsprechende Funktionen in die Geräte zu implementieren sind. So wird eine übergreifende Vereinheitlichung von Funktionen erreicht. Es ist beabsichtigt, für Condition Monitoring solch ein Common Application Profile zu erstellen, das dann beispielsweise in Antrieben, Pumpen oder Remote-I/Os mit Condition-Monitoring-Funktionen genutzt wird. Weiterhin soll die Arbeitsgruppe eine Abbildung des Einheitsblatts auf IO-Link mit vornehmen. 

Die Aktivitäten der PLCopen

Im Kapitel 5 des Einheitsblattes sind 36 Condition-Monitoring-Funktionen für alle Technologien der Fertigungsautomation bereits normkonform in Form des Funktionsbausteins formuliert. Um diese für die praktische Anwendung verfügbar zu machen beziehungsweise sie in eine steuerungsunabhängige Bi­bliothek zu überführen, wurde mit der PLCopen Kontakt aufgenommen. In der Antriebstechnik hat die PLCopen diesen Weg bereits vorexerziert.

Die Abbildung auf PLCopen erfordert zunächst die Erstellung eines IEC-61131-konformen Templates für den definierten Funktionsblock und zielt anschließend auf die Erstellung von Function-Blocks in IEC 61131 ab. Diese können dann in spezifischen Bibliotheken zur Verfügung gestellt werden. Ähnlich zu Antriebsblöcken lassen sich so domänen- beziehungsweise technologiespezifische Blöcke erstellen (etwa für die im Einheitsblatt dargestellten Gebiete Antriebstechnik, Dichtungstechnik, Kühl- und Schmierstofftechnik, Hydraulik und Pneumatik) und bei der SPS-Programmierung leicht integrieren. Aggregatsfunktionen zur Abbildung der Applikationssicht sind ebenfalls auf einer SPS implementierbar – hier sind allgemeine Bibliotheken vorstellbar.

Die Aktivitäten der OPC Foundation

Ein wesentlicher Aspekt bei der Konzipierung des Einheitsblatts war die einheitliche Bereitstellung der CM-Informationen aus der Feld- und Automatisierungsebene für die Leitebene und die Unternehmens-IT. Damit sind neben einer einheitlichen Visualisierung von Maschinen- und Komponentenzuständen insbesondere Prozesse im Manufacturing-Execution-System und im ERP-System – etwa Wartungsprozesse – leichter und einheitlich anbindbar.

Die vereinheitlichte Ampel-Zuordnung der Farben und Schwellwerte zu den im Einheitsblatt definierten Zuständen.

© TU Dresden

Die Schnittstelle zur Leitebene und zur Unternehmens-IT wird derzeit wesentlich durch OPC geprägt. Während das klassische OPC vordergründig Transportfunktionen realisiert und die Abbildung von Ampelstatus und Ausgangs­daten zur Visualisierung erlaubt, sind die Möglichkeiten bei OPC UA deutlich vielfältiger. So lassen sich in einem OPC-UA-Server Verarbeitungsfunktionen realisieren – und damit sind Condition-Monitoring-Blöcke in einem solchen Server implementierbar. Bei der Umsetzung des Einheitsblatts wird daher die Realisierung eines Informationsmodells angestrebt, das die Schnittstellen der Blöcke als Properties und DataVariables eines generischen Basisblocks vorsieht. Der Block selbst beinhaltet die allgemeingültigen Teile wie Statusbildung und Blocksteuerung. Im objektorientierten Ansatz, der bei OPC UA verfolgt wird, lassen sich daraus spezialisierte Blöcke ableiten. Hier sind ebenfalls wiederverwendbare Bibliotheken vorstellbar.

Über die Referenzen, die im OPC-UA-Informationsmodell verfügbar sind, sind zudem die funktionalen Relationen zwischen den Blöcken (die Automatisierungssicht) beschreibbar; und zwar für die Blöcke, die im Server selbst implementiert sind, und für Proxies, die zum Beispiel Blöcke in den unterlagerten Steuerungen oder in Feldgeräten repräsentieren. Damit ist eine Applika­tionskonfiguration wiederum leicht möglich. Ein solches vereinheitlichtes Informationsmodell für Condition Monitoring kann durch die OPC Founda­tion als Companion-Standard zur Verfügung gestellt werden.

Die Herausforderungen an die Hersteller

Wenn die Intention der Standardisierung für Nutzer greifbar werden soll, müssen die von den Normungsgremien ausgearbeiteten Standards in Geräten implementiert werden. In Bezug auf das konkret vorliegende VDMA-Einheitsblatt kann dies sukzessive in Schritten erfolgen.

Wie bereits erwähnt, gibt es bereits viele Implementierungen von Condition Monitoring auf der Feldebene. Wenn diese auch alle dasselbe Ziel haben, nämlich Statusinformationen und deren Interpretation über die relevante Technologie zu liefern, so ist die Implementierung doch immer unterschiedlich. Im Rahmen der nächsten Updates oder der Entwicklung von neuen Gerätegenera­tionen könnten bereits die vorliegenden Grundfestlegungen des Einheitsblattes umgesetzt werden.

Einheitliche Statusmeldungen

Nahezu alle bekannten CM-Geräte liefern Statusmeldungen in Form von Ampeln. Die Bedeutung der Farben interpretieren die Hersteller bislang jedoch unterschiedlich. Auch wird teilweise Zusatzinformation über das Blinken einer Farbe codiert. Das VDMA-Einheitsblatt hat nun Zustände definiert und diese mit Farben assoziiert, die der visuellen Unterstützung von Systembenutzern in Condition Monitoring Systemen dienen:

• Gut (Grün)
• Warnung (Gelb)
• kritischer Zustand (Orange)
• Defekt/Fehler (Rot)

Dadurch ist nun die Chance vorhanden, diese über alle Hersteller zu vereinheitlichen.

Einheitliche Verwendung von Funktionsbausteinen

Der größte Hebel aus der Referenzarchitektur stellt die Verwendung des Bausteinkonzeptes in allen Ebenen des Automatisierungssystems dar. Es sorgt in erster Linie für die klare Vereinbarung und Definition von Ein- und Ausgangswerten (wie etwa der erwähnten Statusinformation über die Ampel). Im zweiten Schritt ermöglicht es aber auch die Einbindung der Condition-Monitoring-Funktionen in den Betriebszustand der Anlage. So können und dürfen beispielsweise während des Anfahrbetriebs keine Trendanalysen durchgeführt werden. Und während des Einrichtbetriebs machen Condition-Monitoring-Aussagen ohnehin keinen Sinn.

Als dritten – und für den Benutzer wesentlichen – Vorteil ermöglicht das Bausteinkonzept die Kombination von CM-Funktionen unterschiedlicher Hersteller in einer Anlage. Auch für die Techno­logiehersteller und Lieferanten von Condition-Monitoring-Komponenten bietet das Bausteinkonzept einen wichtigen Vorteil: Die technologiespezifische Interpretation und Auswertung der Daten kann in einem Funktionsbaustein gekapselt werden und muss nicht offengelegt werden. Dies gilt sogar dann, wenn der Funktionsbaustein in einer übergeordneten Steuerung abläuft. Mit anderen Worten: Firmenspezifisches Wissen wird geschützt, Alleinstellungsmerkmale können die Produkte des Herstellers aufwerten und zum Nutzen der Kunden dennoch im offenen Gesamtsystem integriert werden. Weitere Vorteile sind Identifikation aller CM-Funktionen und die Kommunikation des Zustands der CM-Funktion selbst.

Aggregation der Status­informationen

Statusinformationen werden auf unterschiedlichen Ebenen benötigt. So ist in der übergeordneten Sicht auf die Maschinenhalle lediglich von Bedeutung, welche Maschinen mit Status „Gut“ bewertet werden, welche Warnungen anzeigen und welche in kritischem Zustand sind. Erhält das Wartungspersonal jedoch den Auftrag zur Überprüfung oder vorausschauenden Wartung einer Einzelmaschine, so sind solche Informationen wichtig, die Hinweise auf den Zustand der einzelnen Baugruppen oder Einzelkomponenten geben. Zustandsinforma­tionen müssen also nach vorgegebenen Regeln zusammengefasst und aggregiert werden.

Im VDMA-Einheitsblatt wurden grundlegende Regeln zur Aggregation von Statusinformationen über alle Ebenen definiert. Diese stellen ein neues funktionsorientiertes Ordnungsprinzip dar, das sowohl von den Herstellern der Geräte, aber besonders von den Ingenieuren der Maschinenbau-Unternehmen umgesetzt werden muss.

Implementierung in Engineering Systeme

Ziel einer einheitlichen und standardisierten Condition-Monitoring-Umgebung ist letztlich, Nutzen für die Betreiber und für die Hersteller von Maschinen und Anlagen zu schaffen. Nutzen entsteht durch die Verbesserung der Effizienz von Prozessen: Wenn ein Maschinenbauer in ein und demselben Engineering-Portal sowohl alle Automatisierungsfunktionen als auch alle CM-Funktionen entwerfen und konfigurieren kann, ist eine effiziente Arbeitsweise erreicht. Deshalb ist es auf lange Sicht notwendig, dass die Engineering-Systeme der marktführenden Automatisierungshersteller – wie zum Beispiel das TIA-Portal von Siemens – diese CM-Funktionen enthalten und die dazugehörigen Geräte in die Konfiguration aufgenommen werden können. Dies ist insbesondere dann wichtig, wenn diese Geräte von Drittanbietern angeboten werden.

Beispiel für intergr.Condition Monitoring im Umfeld der Vakuum-Technik: Der dargestellte Kompakt-Ejektor stellt zyklische Zustands­informationen für die Steuerungsebene und azyklische Predicitve-Maintenance-Informa­tionen f.d.Leitebene zur Verfügung.

© TU Dresden

Zusammenfassend lässt sich festhalten: Die Initiatoren der Standardisierung von Condition Monitoring hatten eine Vision: Auch für Condition-Monitoring-Funktionen sollte eine durchgängige Engineering-Kette geschaffen werden von der Konzeptionsphase einer Maschine bis zum Betrieb: Bereits in der Konzeptionsphase einer Maschine oder Anlage soll es einfach möglich sein, CM-Funktionen zu definieren, die Funktionen den Maschinenelementen zu­zuordnen und die dafür geeigneten Komponenten in das Projekt einzuziehen. In der Phase der Funktionsprogrammierung sollten die Funktionen schließlich einfach aus allgemeinen und herstellerspezifischen Bibliotheken ausgewählt und miteinander kombiniert werden können, Visualisierung und Auswertung sollen einfach definierbar sein und mit Werten der Condition-Monitoring-Funktionen versorgt werden können, und nicht zuletzt soll die Anbindungen an übergeordnete Systeme einfach erfolgen.

Auf dieser Basis ist das Potenzial von Condition-Monitoring-Systemen in der Betriebsphase optimal umsetzbar:

• Wartungseinsätze werden vom Zustand  der Maschine gesteuert und sind nur noch dann auszuführen, wenn sie notwendig sind.
• Der Austausch von verschlissenen Komponenten kann vorausschauend in Schichtpausen erfolgen – Noteinsätze und Maschinenstillstände sind so verhinderbar.
• Langfristig aufgezeichnete Daten können zur langfristigen Planung für Wartung und Instandhaltung genutzt werden.
• Maschinenhersteller können remote auf Daten der Komponenten zugreifen und das Wartungspersonal vor Ort unterstützen. Somit sind neue, effiziente Wartungs- und Instandhaltungskonzepte umsetzbar, Maschinen und Anlagen haben einen deutlichen Mehrwert.

Letztendlich sind damit bereits Grundzüge einer Architektur basierend auf autarken und kommunikationsfähigen „Cyberphysischen Systemen“ gelegt, wie sie heute im Rahmen der Diskussion um Industrie 4.0 erörtert werden.

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