Die Kommunikations­kette in der klassischen Automatisierungs­pyramide.

© Weidmüller

Bis dato führen hierarchisch organisierte Automatisierungssysteme aufgrund der Informationsverdichtung entlang der Kommunikationskette häufig zu einem Verlust von Informationen, die nicht unmittelbar für die direkte Prozesssteuerung notwendig sind. Ergo sind relevante Informationen eines Produktionssystems und seiner Teilsysteme zur Beschreibung des aktuellen Zustandes oft nicht verfügbar.

Ein Beispiel sind Diagnose-Informationen, die häufig vereinfacht als Sammelfehlermeldung zur Verfügung gestellt werden. Zudem sind Informationen häufig herstellerspezifisch und ohne Semantik beschrieben. Wichtige Status-In­formationen zur Diagnose einer Anlage, die Rückschlüsse über Fehler-Art und -Ursache ermöglichen, bleiben so auf derFeldebene verborgen; eine vorbeugende Wartungsstrategie umzusetzen, ist schwierig. Im Fehlerfall gilt es daher, die Vorort-Signalisierungen der Komponenten zur Anzeige des Funktionszustandes zu interpretieren. Aber: Da diese häufig ebenfalls herstellerspezifisch realisiert sind, ist selbst für Komponenten des gleichen Typs eine einfache Übersicht über deren Funktionszustand ohne Handbuch nur schwer ermittelbar.

Informationsmodell aller kritischen Komponenten eines Netzwerks: Mehrere Komponenten eines Produktionsmoduls – drei ACT20C-Signalwandler – sind vernetzt.

© Weidmüller

Eine hohe Durchgängigkeit wird zudem erreicht, wenn das dabei verwendete Protokoll vorhandene Kommunikations-Infrastrukturen nutzen kann und so zum Beispiel der Zugang zu einer „Enterprise Cloud“ als übergeordneter Kommunikationsebene möglich wird. Als funktionsunterstützende Komponente bildet deshalb der Signalwandler „ACT20C“ von Weidmüller die Zustandsinformation auf einen Gerätestatus (gemäß Namur) ab und bietet ihn zusammen mit dem Prozesswert am Ethernet via Modbus TCP an.

Für eine differenzierte Zustandsbeschreibung sind neben einem normierten Status allerdings weitere Informationen und Parameter einer Komponente notwendig: Dies können statistische Daten sein, die die Komponente während der Laufzeit speichert, oder auch Parameter, mit denen das Verhalten der Komponente an die Anforderungen der Anwendung angepasst wird.

Um mehrere Gerätemodelle und deren Zustandsinformationen in einem Informationsmodell zusammenzufassen und übergeordneten Ebenen in der Automatisierungsebene zur Verfügung zu stellen, bietet sich eine Schnittstellen-Ebene an, die Informationen verstärkt anwendungsorientiert modelliert und von den darunter liegenden Kommunikationsmechanismen abstrahiert.

Das Informationsmodell des Netzwerkes: Abbildung der ACT20C-Gerätemodelle und des zugehörigen Netzwerkes auf ein „Unified Data Model“. Die Anbindung an das übergeordnete Netzwerk erfolgt mittels OPC-UA-Service-Modul.

© Weidmüller

Im vorliegenden Szenario dient das Informationsmodell von OPC UA als Basis für die Modellierung funktionsunterstützender Komponenten. Dieses Modell verwendet bereits normierte ­Zustandsinformationen für die Verfügbarkeit einzelner Komponenten nach Namur.

Um für den Bereich eines Produktionsmoduls einen differenzierten „Sammelstatus“ zu erhalten, lassen sich die darin enthaltenen kritischen und funktional zusammenhörigen Komponenten über ein gemeinsames Netzwerk verbinden. Wird nun für eine Komponente des Netzwerks eine Funktionsbeeinträchtigung erkannt, bedeutet dies zugleich eine Beeinträchtigung der übergeordneten Funktion des Produktionsmoduls.

Aus den jeweiligen Zustandsinformationen der Komponenten lässt sich deshalb ein neuer aggregierter Funktionszustand erzeugen, der den funktionalen Zustand dieses Bereiches des Produktionsmoduls und der darin enthaltenen Komponenten repräsentiert. Der aggregierte Zustand kann somit dem Netzwerk angeheftet werden. Hierzu wird das Netzwerk-Objekt des OPC-UA-Modells um einen entsprechenden Funktionsstatus nach Namur erweitert.

Die automatische Selbst­konfiguration

Der Aufbau des Informationsmodells im OPC-UA-Server wurde vorliegend im Rahmen einer automatischen Selbstkonfiguration realisiert. Eine Selbstkonfiguration reduziert den Aufwand für Projektierung und Inbetriebnahme. Gleichzeitig ermöglicht sie eine automatische Anpassung des Informationsmodells an Änderungen des automatisierungstechnischen Aufbaus innerhalb des Produktionsmoduls.

Vor- und Nachteile der Handhabung von Gerätebeschreibungen (Legende: Handhabung „+“: einfach/ „o“: mittel/ „–“: komplex)

© Weidmüller

Die Selbstkonfiguration erfolgt durch einen speziell entwickelten Initialisierungs- und Konfigurationsmechanismus des OPC-UA-Servers. ­Hierzu wird zunächst das Netzwerk nach angeschlossenen Signalwandlern durchsucht und das zugehörige Gerätemodell, das direkt vom Signalwandler bereitgestellt wird, zur Konfiguration des OPC-UA-Servers verwendet. Das Gerätemodell beinhaltet Nutz- und Meta-Informationen über die Komponente sowie deren angebotene Dienste. Als Dienst wurde im Rahmen dieser Untersuchung zunächst der ­Datenzugriff mittels OPC UA mo­delliert.

Der direkte Zugriff auf die Gerätebeschreibung einer Komponente wird möglich, wenn die Gerätebeschreibung zum Beispiel auf der Komponente selbst gespeichert ist. Im Vergleich zu herkömmlichen Verfahren, bei denen eine passende und aktuelle Gerätebeschreibung für die Komponente vom Anwender häufig selbst beschafft, ausgewählt und zugeordnet werden muss, enthält diese Variante eine Reihe von Vorteilen. Beispielsweise erlaubt die Verfügbarkeit der Gerätebeschreibung direkt auf dem Gerät eine Offline-­Konfiguration nur dann, wenn die Gerätebeschreibungsdatei, zum Beispiel auf Basis einer eindeutigen Identifikationsnummer des Gerätes, vom Hersteller auch separat zur Verfügung gestellt wird und in das Konfigurationswerkzeug geladen werden kann. Aber: Durch die Verwendung einer ­direkt auf dem Gerät gespeicherten Gerätebeschreibung ist eine manuelle Auswahl und Zuordnung der Geräte­beschreibung zur vorhandenen Komponente überflüssig. Damit entfällt ebenfalls die Beschaffung einer passenden Gerätebeschreibung durch den Anwender.

Muss einmal ein Gerät ersetzt werden, ist für Geräte mit integrierter Geräte­beschreibung nur die Version der ­Gerätebeschreibung selbst be­ziehungsweise des darin beschriebenen Funk­tionsprofils das entscheidende Kom­patibilitätskriterium; auf die Überprüfung weiterer Versionsnummern (zum Beispiel Firmware) kann verzichtet werden.

Die Realisierung des ­Gerätemodells

m Rahmen der Untersuchungen wurde das Gerätemodell im Daten­austauschformat „JavaScript Object Notation“ (JSON) realisiert, was eine kompakte Abbildung der Geräte-­Information erlaubt. Der Aufbau des Netzwerk-Informationsmodells mit den darin angeschlossenen Sig­nalwandlern erfolgte mittels eines prototypisch implementierten OPC-UA-Servers auf einem Single-Chip-­Controller „Rasp­berry Pi“. Hierzu wurden die Gerätemodelle von den ­Signalwandlern über den erwähnten Initialisierungs- und Konfigurations-Mechanismus eingelesen und zu einem einheitlichen Informations­-modell (Unified Data Model) zusammen­gefasst. Hierbei wurden die Zustandsinformationen der einzelnen Signalwandler ­aggregiert und der ­resultierende Funktionszustand dem Netzwerk zugeordnet. Er repräsentiert den funktionalen Gesamtzustand ­dieses Bereiches des ­Produktionsmoduls mit den darin enthaltenen Komponenten.

Wird nun ein Signalwandler neu ­hinzugefügt oder durch einen ähn­lichen Wandler anderen Typs ersetzt, adaptiert sich das Informationsmodell im OPC-UA-Server automatisch an die neue Netzwerkstruktur des Pro-duktionsmoduls. Hierbei wird das neue Gerätemodell eingelesen und in das vorhandene Informationsmodell integriert. Die übergeordnete Zustandsinformation am Netzwerk berücksichtigt die neue Komponente und aktualisiert sich automatisch. Für benachbarte Produktionssysteme wird so eine mögliche Änderung des funktionalen Zustands innerhalb des Produktionsmoduls weiterhin sichtbar.

Für den Anwender handhabbar

Kommunikation, normierte Zustandsbeschreibungen und Selbstkonfiguration fungieren als ein Schlüssel, damit Systeme autonom Informationen weiterverarbeiten können und so trotz steigender Systemkomplexität für den ­Anwender handhabbar bleiben. Gleichzeitig eröffnet dieses Vorgehen einen Zugang sowohl zu verdichteter als auch zu detaillierter Zustandsinformation, was den Anwender bei der Umsetzung seiner Wartungsstrategien unterstützt. Künftig sind somit nicht nur selbst agierende Produktionsmodule denkbar, die Abweichungen diagnostizieren und kommunizieren – sie können auch ­notwendige Wartungsaktivitäten beauftragen und die erforderlichen Ersatzkomponenten direkt über das Internet bestellen.

Autoren: Georg Hilsch ist Produktmanager Analoge Signalwandler bei Weidmüller in Detmold; Felix Harring ist Werksstudent bei Weidmüller in Detmold und Dr. Markus Köster ist Technologie-Entwickler für Elektronik bei Weidmüller in Detmold.

SPS IPC Drives: Der Kongress

Vertiefende Informationen zum Thema liefert Georg Hilsch im Rahmen des begleitenden Kongresses zur Fachmesse SPS IPC Drives (25. bis 27. November) in Nürnberg. Der Vortrag ist Teil der Session 4a „Monitoring und Diagnose“ und findet am zweiten Messetag um 10 Uhr statt. Das vollständige Kongressprogramm steht auf der Website www.mesago.de/sps zum Download zur Verfügung.