Ziel der digitalen Modul-Beschreibungsform MTP ist es, bei der Integration von Anlagenmodulen unterschiedlicher Hersteller eine einheitliche Darstellung der Bedienelemente sicherzustellen.

Ziel der digitalen Modul-Beschreibungsform MTP ist es, bei der Integration von Anlagenmodulen unterschiedlicher Hersteller eine einheitliche Darstellung der Bedienelemente sicherzustellen. (Bild: Wago)

  • Weil Modulhersteller für ihre Anlagenmodule unterschiedliche Engineeringwerkzeuge nutzen, erhält der Anlagenbetreiber zur Visualisierung seiner Gesamtanlage ein Durcheinander modulspezifischer Bedienbilder.
  • Ziel der digitalen Modul-Beschreibungsform MTP ist es, bei der Integration von Anlagenmodulen unterschiedlicher Hersteller eine einheitliche Darstellung der Bedienelemente sicherzustellen.
  • Wie das künftig funktionieren kann, wurde auf der Namur-Hauptsitzung unter anderem von Wago an praktischen Beispielen gezeigt.

Anlagen müssen einen modularen Aufbau unterstützen! Dieser Gedanke, der unter anderem in der Verfahrenstechnik seinen Ursprung hat, hat sich in der Automatisierungstechnik fortgesetzt und mündete 2013 in der Namur-Empfehlung NE 148. Diese Empfehlung formuliert die Anforderungen für die Automatisierung modularer verfahrenstechnischer Anlagen. Mit dem Projekt Dima hat Wago gezeigt, wie sich die in der NE 148 formulierten Anforderungen technisch umsetzen lassen.

Basis des Lösungsansatzes ist die Beschreibung verschiedener Aspekte eines Anlagenmoduls in einer neuen digitalen Beschreibungsform – dem Module Type Package (MTP). Im Frühjahr 2015 hatte sich die Interessengemeinschaft Namur dazu entschieden, den Dima-Ansatz zu übernehmen und gemeinsam mit dem ZVEI weiterzuentwickeln. Ziel war es, das von Wago vorgestellte MTP weiter auszuarbeiten und zu spezifizieren. Diese Aufgabe ist groß, da nicht weniger benötigt wird als die digitale Beschreibung kompletter Anlagenteile. Um sie dennoch angehen zu können, haben die Arbeitskreise eine agile Vorgehensweise gewählt, für die das MTP in mehrere Aspekte unterteilt wurde:

  • Prozessführung,
  • Visualisierung/HMI sowie
  • Alarmmanagement und Diagnose.

Im Jahr 2016 bestand der Schwerpunkt der Aktivitäten in der inhaltlichen und strukturellen Ausgestaltung des Aspektes „Visualisierung/HMI“. Pünktlich zur vergangenen Hauptsitzung der Namur im November 2016 konnten die Ergebnisse der Arbeitskreise von Namur und ZVEI präsentiert werden. In zwei Workshops wurde unter anderem gezeigt, wie das MTP mithilfe des Engineeringtools e!Cockpit erzeugt und in die unterschiedlichen Leitsysteme der Firmen ABB, Siemens und Yokogawa eingelesen wird. Nicht zuletzt wurde hier der große Vorteil des Dima-Ansatzes deutlich, der in der Herstellerneutralität besteht. Nach dem Einlesen des MTP wurde das im e!Cockpit erzeugte Bedienbild im Leitsystem von Siemens anders dargestellt als in dem von ABB. Diese

Teil-4-Eroeffnungsvortrag-TA-13.pptx

Beim HMI-Engineering in Dima erfolgt einheitliches Bedienen und Beobachten unabhängig vom Quellsystem des Modulherstellers.Bild: Wago

zielsystemspezifische Anpassung stellt sicher, dass auch Bedienbilder unterschiedlicher Module im bekannten Look-and-Feel des genutzten Leitsystems dargestellt werden.

Bedienbild auf Basis des Namur-MTP beendet das Durcheinander

Eine nutzerfreundliche Mensch-Maschine-Schnittstelle ist Grundvoraussetzung für den wirtschaftlichen Betrieb einer Anlage. Weil Modulhersteller bei der Programmierung ihrer Anlagenmodule unterschiedliche Engineering-Werkzeuge nutzen, erhält der Anlagenbetreiber zur Visualisierung seiner Gesamtanlage ein Durcheinander modulspezifischer Bedienbilder. Ziel des MTP ist es, bei der Integration von Anlagenmodulen unterschiedlicher Hersteller eine einheitliche Darstellung der Bedien­elemente über die Modulgrenzen hinweg sicher­zustellen. Weil die Bedien­bilder in einer neutralen Beschreibungsform abgebildet sein müssen, nutzt das MTP eine rollenbasierte Beschreibung der einzelnen Bedienelemente: Sowohl bei der Bedienbildererstellung durch den Modulhersteller als auch beim Bedien- und Beobachtungsystem des Modulbetreibers werden Bibliotheken eingesetzt, die um eine semantische Bedeutung der einzelnen Bedienelemente ergänzt wurden. Dazu hat der Namur-Arbeitskreis ein Set an Elementen identifiziert, die zum Bedienen und Beobachten von Modulen notwendig sind und vorgeben, welche Elemente (wie beispielsweise Ventil, Antrieb oder Messstelle) mit welcher Information (Sollwert, Istwert, Ersatzwert, …)  übertragen werden müssen.

Beschreibung mittels AutomationML

Rollenbasiertes Bibliothekskonzept zur HMI-Integration. Ein minimales Set an Elementen gibt vor, welche Elemente mit welcher Information übertragen werden müssen. Bild: Wago

Rollenbasiertes Bibliothekskonzept zur HMI-Integration. Ein minimales Set an Elementen gibt vor, welche Elemente mit welcher Information übertragen werden müssen. Bild: Wago

Für die Beschreibung der Bedienbilder hat der Arbeitskreis das xml-basierte Beschreibungsmittel AutomationML genutzt. Dieses Metamodell ist in der IEC 62714 spezifiziert und setzt sich aus den Modellen CAEX (Computer Aided Engineering Exchange), PLCopen XML und Collada zusammen. Für die Bedienbildbeschreibung wurde ausschließlich der Anteil CAEX genutzt. Jedes Bedienbild besteht aus einer AML-Datei, auf die aus dem Manifest des MTP verwiesen wird.

Das Root-Element (Elemente werden in AML als Internal Element bezeichnet) beinhaltet Informationen zum Bedienbild selbst, wie beispielsweise die Auflösung des Bedienbildes im Quellsystem. Die Ebenen unterhalb des Root-Elements symbolisieren die Elemente auf dem Bedienbild, also die Ventile, Motoren und Rohrleitungen. Damit diese Beschreibung eines Bedienbildes in ein Zielsystem eingelesen werden kann,  werden allerdings weitere Informationen benötigt:

  • Die Bedeutung des Elements; also was wird abgebildet? Beispielsweise: ein Ventil.
  • Die Lageinformation; also wo befindet sich das Element auf dem Bedienbild? Beispielsweise: x=180, y=803.
  • Die Größeninformation; also wie groß ist das Element? Beispielsweise: x=13, y=24.

Mittels dieser ergänzenden Informationen ist das Zielsystem dazu in der Lage, das eigene Bibliothekselement in entsprechender Größe auf definierter Position zu platzieren.

Bis zu diesem Schritt wird das Bedienbild lediglich statisch dargestellt und damit ohne die Möglichkeit, auf Sensoren und Aktuatoren im Modul zuzugreifen. Um dies ebenfalls zu ermöglichen, müssen die auf dem Bedienbild platzierten Elemente mit Variablen verbunden werden. Abhängig von der gewählten Kommunikationstechnologie werden die Variablen im Datenhaushalt des Zielsystems aus dem MTP entnommen und angelegt. Wird OPC UA als Kommunikationsprotokoll gewählt, werden pro Element mehrere OPC-Nodes (Ventil = 20 Variablen) angelegt. Da für die korrekte Verarbeitung auch die Information über die Bedeutung der Variable notwendig ist (beispielsweise: Sollwert oder Ersatzwert), muss im MTP auch diese Information modelliert werden.
Neben der Lageinformation wird auch die Information über die Verbindung von Bedienbildelementen im MTP modelliert. Das ist von Nutzen, wenn die Auflösung zwischen Quell- und Zielsystem sehr stark variiert und die einzelnen Bedienbildelemente für ihre Darstellung stark gestreckt oder gestaucht werden müssen. Eine gute Darstellung der Bedienbildelemente kann dann nur erzielt werden, wenn die Elemente auf dem Bedienbild neu angeordnet werden. Werden die Verbindungen zwischen Bedienelementen dabei nicht beachtet, kann sich beispielsweise ein Flansch schnell vom Behälter entfernen und dadurch ein Bedienbild generiert werden, das von der physischen Realität abweicht. Die Auswirkungen der daraus entstehenden Fehlbedienung können fatal sein. Die Information die über ein mittleres Bedienbild (20 Elemente) im MTP modelliert werden muss, kann so schnell zehntausend Zeilen erreichen.

Fazit: Mit der Spezifikation des MTP-Aspekts Visualisierung/HMI hat der Arbeitskreis von Namur und ZVEI die Anforderungen an die Bedienbildbeschreibung sowie die Anforderungen an die zugehörigen Variablen im MTP erarbeitet. Die Einhaltung der Spezifikation liegt nun beim Nutzer. Um diese umfangreichen und fehleranfälligen Prozesse des Anlegens eines Programmcodes und der Einhaltung aller Spezifikationen nicht dem Anwender und Ersteller des Modul-Engineerings zu überlassen, hat Wago eine Bibliothek entwickelt. Diese Bibliothek verfügt jeweils über einen Funktionsbaustein gemäß IEC 61131 und ein dazugehöriges Bedienbildelement. Mit Hilfe dieser Bibliothek kann der Programmcode des Moduls auf Equipmentebene entwickelt werden, ohne auf typische Funktionalitäten, wie beispielsweise Verriegelungen und Alarmmanagement verzichten zu müssen. Ein weiterer großer Vorteil dieser Bibliothek ist die OPC-UA-Konfiguration, die bereits in den Funktionsbausteinen vorbereitet ist. Mit nur einem Mausklick im Engineeringtool e!Cockpit können alle Variablen, die zur Kommunikation mit dem Leitsystem notwendig sind (mehrere Hundert an der Zahl) normgerecht in den OPC-UA-Server der SPS geladen werden. Der Mehraufwand, der durch die Dima-konforme Kommunikation unter Verwendung des MTP entsteht, kann dadurch deutlich minimiert werden. Anwender brauchen die ihnen bekannte Engineering-Umgebung nicht verlassen. Die Bibliothek von Wago befindet sich aktuell im Erprobungsstatus und wird derzeit in mehreren industriellen Pilotprojekten eingesetzt und weiter verbessert.

Homepage Wago

 

Sie möchten gerne weiterlesen?

Unternehmen

WAGO Kontakttechnik GmbH & Co. KG

Hansastraße 27
32423 Minden
Germany