Die Automatisierungspyramide ist in der operativen Praxis noch sehr präsent und kann sich mit ihren Vorzügen des deterministischen Verhaltens und der damit vorhandenen Beherrschbarkeit großer, eng gekoppelter Systeme behaupten. Doch nach und nach rücken die mehrwertbestimmenden Aufgaben des Condition Monitorings und die abgeleiteten Optimierungsstrategien (M+O) in den Fokus. Dies erfordert einen Zugriff auf Sensor- und Aktuatorendaten der sowohl hinsichtlich der Dynamik (Häufigkeit der Datenaktualisierung) als auch der Zugänglichkeit für die Spezialisten des Mess- oder Stellprinzips oder des verfahenstechnischen Prozessschrittes ausgelegt sein muss.
Heutige Leitsysteme würden dafür einen Engineeringprozess benötigen, der wegen der vorhanden Hierarchie vom Sensor über die Steuerung bis zum Leitsystem Eingriffe erfordern würde. Dieser hohe Aufwand macht aber mitunter den potenziellen Nutzen der M+O-Funktionen zunichte bzw. wird aufgrund der Tatsache, ein lauffähiges System zu verändern, nicht vorgenommen. Diese Situation zeigt die etwas starren und geschlossenen Strukturen der Leitsysteme. Hier setzt das Namur-Open-Architecture- (NOA-)Konzept an. Es soll Lösungen aufzeigen, wie M+O-Anwendungen prototypisch, zeitlich begrenzt oder beständig, aber auf jeden Fall ohne Engineeringprozess für das bestehende Leitsystem vorgenommen werden können. Die Namur hat zu Beginn des Jahres 2016 innerhalb des Arbeitskreises 2.8 „Automatisierungsnetzwerke und -dienste“ mit der Konzeptionierung einer offenen Systemstruktur, der Namur Open Architecture, begonnen.
Bewährte Architektur erweitern
Die Zielsetzung der Namur Open Architecture wird in einem Artikel von Mitarbeitern des Arbeitskreises wie folgt beschrieben: „Ziel ist es, die bestehenden Automatisierungsstrukturen so zu erweitern, dass eine flexible Umsetzung von Industrie 4.0 in der Prozessindustrie sowohl für Neu- als auch für Bestandsanlagen möglich wird. Für diese Erweiterung gelten folgende Anforderungen:
- Die neuen Methoden sollen optional und additiv zur bewährten Automatisierungsarchitektur einsetzbar sein. Sie sollen diese also nicht ersetzen, sondern erweitern.
- NOA soll auf bestehenden Standards aufsetzen und dadurch offen und unabhängig von einzelnen Anbietern sein
- NOA darf die Verfügbarkeit und die Sicherheit der bestehenden Automatisierung nicht einschränken oder gefährden
- NOA soll schnelle und kostengünstige Implementierungen ermöglichen
- NOA soll auf verschiedenen Ebenen an die Automatisierungspyramide andocken können, also wahlweise auf Feld-, Prozessleit- oder Betriebsleitebene
Technische Lösung
Bild 1 zeigt die wesentlichen Komponenten des NOA-Konzepts. Die 34 Parameter der NE 131 (auch als Core-Parameter bekannt) sind in der ersten Version ausgewählt und sollen von allen Geräten (Parameterauswahl je nach Gerätettyp) konfigurierungsfrei zur Verfügung stehen. Eine beliebige M+O-Anwendung kann also mit diesen Parametern aus allen Geräten arbeiten. Die Parameter können in Profibus-PA-, Hart- oder FF-Geräten liegen. Durch die Unterschiede dieser drei Systeme heißen die Parameter unterschiedlich und sind auch mit unterschiedlichen Zugriffsmechanismen zugänglich. Damit für die Anwendung diese technologische Schicht verdeckt bleibt, bekommen alle Core-Parameter einen eindeutigen Identifier (ID). Diese ID referenziert eine Parameterbeschreibung, in der Name, Datentyp, Maßeinheit, erlaubter Wertebereich und weitere Attribute hinterlegt sind. Dabei wird das gleiche Prinzip verwendet wie bei den Merkmalbeschreibungen von IEC 61987 bzw. eCl@ss (ehemals Prolist). Die Parameterbeschreibung ist in IEC 61360–1 standardisiert. Die Anwendungen müssen diese ID kennen und finden die entsprechenden Parameter unabhängig vom verwendeten Kommunikationssystem. Dieses Prinzip findet auch in den Arbeiten der Plattform I4.0 Anwendung und beruht auf dem Merkmalkonzept.
Der Zugriff auf die Parameter benötigt eine einheitliche Schnittstelle. Dafür wurde als eine Option OPC UA ausgewählt. Die Parameter sind darin mit ihren IDs und Werten entsprechend des Standards hinterlegt. Mithilfe der OPC-UA-Services „Browse“ oder „Query“ können alle IDs gefunden und dann je nach Anforderung der Anwendung die Parameterwerte ausgelesen werden. Schreibvorgänge sind aus Sicherheitsgründen nicht vorgesehen. Die Nutzung des FDI-Informationsmodells für die Umsetzung in NOA ist prinzipiell vorgesehen.
Umsetzung für Profibus PA
Ein naheliegender Lösungsansatz für diesen zweiten Kommunikationskanal ist es, bestehende Netze zu nutzen. Profibus PA bietet in der bereits installierten Umsetzung einen solchen Kanal in Form von Lesezugriffen vom Master Klasse 2. Die im Labor erprobte Lösung sieht einen Zugang zum Profibus-PA-Segment mit Buskoppler (zur Wandlung der eigensicheren auf die RS485-Physik) oder über Remote IO vor (Bild 2). Bei beiden Lösungen wird der Profibus Master Klasse 2 in einen OPC-UA-Server integriert. Der Master holt die gewünschten Daten mittels Read-Dienst aus dem Profibus-PA-Gerät und legt die Parameter in der in NOA definierten Form (Syntax) in den OPC-UA-Server ab. Durch diese standardisierte Ablage können Anwendungen mit OPC-UA-Client-Funktionalität gerätetyp- und geräteherstellerunabhängig die Parameter auffinden und für die Anwendungen nutzen. Dies gilt sowohl für dynamisch verändernde Prozessgrößen wie Druck und Temperatur, als auch für geräte- und einbauortidentifizierende Parameter wie Herstellername, Geräteversion und TAG (PLT-Stellen-Nummer). Prinzipiell stehen bei Profibus PA alle im Gerät azyklisch lesbaren Parameter, nicht nur die NE-131-Core-Parameter, zur Verfügung. In äquivalenter Weise funktioniert dies auch mit Profinet, da auch hier azyklische Dienste im Protokoll verankert sind. Dies kommt zum Tragen, wenn Geräte mit dem PA-Profil V4.0 für Profinet verfügbar sind oder durch den Einsatz entsprechender Profinet/Profibus-PA-Koppler.
In der Praxis
Wie oben beschrieben ist die existierende Profibus-PA-Installation ohne Veränderung in der Lage, das NOA-Konzept umzusetzen. Für Profibus PA kann auch schon auf die installierte Basis zugegriffen werden. Mit speziellen Remote-IOs, den DP/PA-Links (z. B. von der Firma Siemens) besteht bereits heute eine effiziente Zugriffsmöglichkeit. Neu hinzu kommt eine OPC-UA-Infrastruktur mit OPC-UA-Servern, die auf der einen Seite Zugang zu den Profibus-PA-Segmenten haben und auf der anderen Seite eine Ethernet/TCP/IP-Installation für den Zugang der OPC-UA-Clients. Funkbasierte Lösungen sind dafür ebenfalls denkbar. Es ist zu erwarten, dass die seit kurzer Zeit diskutierten Edge Gateways die OPC-UA-Server aufnehmen.
Suchwort: cav0617profibus
Autor Prof. Dr. Christian Diedrich
ifak, Mitglied im Beirat der Profbus Nutzerorganisation
Autor: Tizian Schröder
Institut für Automatisierungstechnik, Otto-von-Guericke-Universität Magdeburg
