Analog der Fertigungsindustrie, die sich mit immer kleiner werdenden Losgrößen bei immer höherer Individualisierung der Produkte konfrontiert sieht, muss sich die Prozesstechnik künftig auch auf stark schwankende beziehungsweise schwer kalkulierbare Absatzmengen einstellen. Um dies hanhaben zu können, ist die Modularisierung von verfahrenstechnischen Anlagen der zukünftige, vielversprechende Ansatz. Will heißen: Einzelne Module realisieren einen definierten Teilschritt des Produktionsprozesses und können je nach Bedarf zusammengestellt oder ausgetauscht werden. Die dadurch modular aufgebaute verfahrenstechnische Produktionsanlage erfordert konsequenterweise ebenfalls eine modulare Automation.

DIMA kapselt die Komplexität und Funktionalität des Moduls, indem das Anlagenmodul durch das MTP beschrieben wird – eine elektronische Beschreibung ­seiner sämtlichen Eigenschaften.

© Wago Kontakttechnik

Bei einem herkömmlichen, starren Leitsystem ist der Tausch eines Anlagenmoduls immer mit einem hohen Programmieraufwand verbunden, da jedes Modul im Leitsystem individuell manuell integriert werden muss. Um dies zu minimieren, wäre als Grundvo­raussetzung eine Standardschnittstelle zwischen der Modulebene und der übergeordneten Leitebene notwendig. Da­rauf basierend wären technologische und organisatorische Voraussetzungen zu schaffen, damit sich die Engineering-Abläufe derart umgestalten lassen, dass der Aufwand während der Integration eines Moduls in eine Gesamtanlage ­minimiert wird: Dazu müsste das An­lagenmodul so viel Eigenintelligenz ­besitzen, dass es seinen verfahrenstechnischen Prozess selbstständig abarbeiten kann. Ein Hersteller kann dieses Modul dann herstellen, noch bevor die Gesamtanlage geplant und gebaut wird. Das würde bedeuten, dass ein Großteil des Engineering bereits durch den Lieferanten des Moduls vorweggenommen wird. Das Modul selbst repräsentiert sich dann an den Schnittstellen zur Leit­ebene über einen definierten Standard – sowohl offline beim Engineering als auch online im Betrieb.

Soviel zur Theorie! Was die derzeitige Praxis betrifft, muss man allerdings feststellen, dass etablierte Prozessleitsysteme für ein verteiltes Engineering und den flexiblen Betrieb modularer Anlagen nicht gut vorbereitet sind. Denn sie besitzen üblicherweise keine offenen Schnittstellen zur Integration modularer, verfahrenstechnischer Module für die Visualisierung, Prozedursteuerung, Alarme und Diagnose. An­gesichts dieses Mankos hat Wago zusammen mit der Technischen Universität Dresden und der Helmut-Schmidt-Universität Hamburg in einem gemeinsamen Projekt eine neue Methodik für die Automation modularer verfahrenstechnischer Produktionsanlagen erarbeitet. Dieser Ansatz, genannt DIMA (Dezentrale Intelligenz für modulare Anlagen), geht von dem Grundverständnis aus, Aktivitäten aus dem An­lagen-Engineering in das Modul-En­gineering zu verlegen. Damit zerlegt sich der ursprüngliche Engineering-Prozess in zwei voneinander getrennte Prozesse: einen in Verantwortung des ­Modulherstellers und einen in Verantwortung des Anlagenbetreibers.

Der dienstbasierte Ansatz

Das Modul stellt dem übergeordneten Prozessleitsystem seine verfahrenstechnische Funktion als Dienstleistung zur Verfügung. Die Kommunikation zwischen Modul und Leitsystem erfolgt dabei dienstebasiert. Dazu muss ein Modul folgende Grundfunktionalitäten des Prozessleitsystems unterstützen oder teilweise selbst übernehmen:

• Bedienen und Beobachten (BuB)
• Melden und Protokollieren
• Steuern und Überwachen

Die zur Integration erforderliche Information über das Modul wird bei diesem Ansatz in einem Informationsträger – dem neu geschaffenen Module Type Package (MTP) gespeichert. Zum Aufbau der Anlage werden mehrere Module kombiniert. Dadurch entsteht die Notwendigkeit, die von den Mo­dulen angebotenen Dienste in eine für die Herstellung des gewünschten Produktes erforderliche Folge zu bringen. Dazu ist es wiederum notwendig, die aktuellen Zustände der Module, beispielsweise 'startend', 'laufend' oder 'gestoppt', zu kennen. Diese Information wird durch die dezentrale Intelligenz eines jeden Moduls er­mittelt und über eine Kommunikationsschnittstelle zugänglich gemacht. Entscheidend dabei ist, dass die Definition der Zustände Hersteller- und Modul-unabhängig und somit einheitlich über alle Module hinweg geschehen muss!

Unabhängig vom Charakteristikum des Prozesses sind in modularen Anlagen Modul-übergreifende Verriegelungen und Regelungen erforderlich. Diese stellen hohe Anforderungen an die Echtzeit-Fähigkeit. Da die Steuerungen der Module vom Modulhersteller programmiert, die Regelungs- und Verriegelungsbedingungen aber erst während der Auswahl und Integration der Module spezifiziert werden, kann eine Kopfsteuerung notwendig werden. Deren Programm überwacht die Modul-übergreifenden Verriegelungen, koordiniert die Datenweiterleitung für Modul-übergreifende Regelungen und stellt darüber hinaus das anlagenweite Notaus-Konzept sicher.

Die Darstellung der Bedienbilder muss Hersteller-unabhängig geschehen. Dazu werden die Beschreibungen der Bedienbilder übertragen und deren Elemente im Zielsystem mit einer Bibliothek im HMI der Anlage erzeugt.

© Wago Kontakttechnik

Auch das Bedienbild eines Moduls wird beim modularen Ansatz durch den Modulhersteller angefertigt. Dieser kennt die in industriellen Anlagenprojekten meist projektspezifisch verwendete Bedienbildbibliothek des übergeordneten (Scada-)Systems zu diesem Zeitpunkt jedoch noch nicht. Die Modul-spezifischen Bedienbilder, die im übergeordneten System der Gesamtanlage erscheinen, können somit erst während des Gesamtanlagen-Engineering erzeugt werden. Damit sich diese in Bedienbilder mit Projekt­einheitlichen Bedienbildelementen übersetzen lassen, müssen sie in einer darstellungsunabhängigen Beschreibungsform vorliegen. Die Layout- und Rolleninformationen sind darum durch einen Algorithmus zugänglich, der die Projekt­abhängigen Elemente in der gewünschten Darstellung und Lage auf das Bedienbild setzt und mit den Kommunikationsva­riablen der Module verknüpft.

Um das Bedienbildelement mit den Variablen des Softwarecodes der Modulsteuerung datentechnisch verknüpfen zu können, muss ebenfalls ein zuvor abgestimmter Informationsraum vorliegen. Dazu arbeitet der Namur-AK 2.9.1 aktuell an einer Bibliothek. Ziel ist, die darzustellende Information durch eine harmonisierte eindeutige Merkmals-Kennung zu beschreiben, um so in allen beteiligten Automatisierungssystemen die gleichen Bedienbildinformationen darzustellen.

Die Beschreibung von Modulen

Um zu gewährleisten, dass die Dienste des Moduls wunschgemäß ausgeführt werden, ist es notwendig, den Diensten Parameter mitzugeben. Zudem muss die Ausführung des Dienstes überwacht werden. Beides übernimmt wiederum das übergeordnete Leitsystem. Dazu ist – in Analogie zur Geräte-Integration – das Fähigkeitsprofil des Moduls in das Prozessleitsystem zu integrieren. Dies umfasst zum einen die Beschreibung des Bearbeitungsverfahrens, wie beispielsweise Temperieren oder Vermischen, und zusätzliche Attribute, die das Bearbeitungsverfahren näher spezifizieren. Zum anderen enthält die Beschreibung des Fähigkeitsprofils einen Zugang zum Zustandsmodell, das zum einen der Überwachung des Moduls dient, zum anderen eine Möglichkeit für den Anlagenbediener darstellt, Einfluss zu nehmen. Letzteres wird mit Hilfe von HMI-Funktionalitäten umgesetzt.

Struktur eines MTP: Neben State Based Control und HMI lassen sich weitere Aspekte hinzufügen. Dies ermöglicht eine technische und technologische Erweiterung.

© Wago Kontakttechnik

Im Rahmen der ersten Vorstellung der DIMA-Methodik wurde die Überwachungs- und Parametrierfunktionalität als Teil der Prozedur- und Koordinierungssteuerung durch ein Batch-System verrichtet und die Bedien- und Beobachtungsfunktionalität durch ein Scada-System. In diese Systeme müssen die MTPs als Funktionsbeschreibungen der Module integriert werden. Die zu beschreibenden Funktionen liegen außerhalb des Anwendungsbereichs von heute gängigen Gerätebeschreibungsdateien (GSD, DD, EDD, FDT/DTM, FDI). Insbesondere für Alarme und Archivierung fehlen standardisierte Beschreibungsmittel heute gänzlich. Aus diesem Grund war es nötig, bestehende Geräte-Integrationskonzepte um diese Anteile zu erweitern und so eine neue Definition für die Beschreibung von verfahrenstechnischen Modulen zu schaffen. In diesem Modulbeschreibungsmodell wird die Information abgelegt, die zur Anwender-unabhängigen Integration in ein Scada- und Batch-System notwendig ist. Dies umfasst bei Nutzung der OPC-Technologie folgende Informationen:

• Generische und Zielsystem-unabhängige Beschreibung des Modulbedienbildes;
• Bedienbildelemente mit vereinheitlichter Schnittstelle und Beschreibung des darzustellenden Informationsumfangs;
• OPC-Tag-Bezeichnungen der Bedienbildelemente und veröffentlichten Dienste mit vereinheitlichter Schnittstelle gemäß des Zustandsmodells der DIN EN 61512;
• OPC-Server-Bezeichnungen und OPC-Tag-Bezeichnungen der Dienstparameter.

Eine MTP-Schnittstelle, die das Einlesen des Informationsträgers in ein Leitsystem ermöglicht, ist derzeit noch nicht vorhanden. Weil die Namur  allerdings von einer breiten Akzeptanz der MTP-Schnittstelle bei den Systemanbietern ausgeht, arbeitet sie derzeit zusammen mit dem ZVEI an der Weiterentwicklung der DIMA-Methodik und verbunden damit am finalen Abschluss der MTP-Spezifikation.

Was steckt hinter dem MTP?

Was sind nun im Detail die Kernelemente des 'Module Type Package'? Um diese Frage zu beantworten, sind zunächst ein paar wichtige Randbedingungen zu nennen, die bei der ­Entwicklung des MTP zu berücksichtigen waren: So sollten die Informationsmodelle so weit möglich Technolo-gie-unabhängig spezifiziert werden können. Beispielsweise muss eine I/O-Variable unabhängig von den Einschränkungen der Kommunikationstechnologie identifiziert und benannt werden können. Die Abbildung auf die kommunikationsmittelspezifische Adressierung ist dementsprechend in einem Technologie-abhän-gigen Anteil zu kapseln.

Eine weitere Vorgabe: Das integrierende System muss das MTP einlesen und die notwendigen Objekte im eigenen Datenhaushalt automatisch erzeugen können. Das MTP-Format muss sich daher einfach auf syntaktische Richtigkeit und Vollständigkeit prüfen lassen. Auch beim Prüfen und Einlesen sind Datentypen, Strukturen und Kennzeichnungssysteme, die einen händischen Eingriff erfordern, kontraproduktiv.

Ein MTP repräsentiert immer die aktuelle Instanz eines Moduls, die sich unter anderem durch das Automatisierungsprojekt ergibt. Nach Integration eines Moduls in ein Leitsystem besteht kein Zugriff auf den Automatisierungscode des Moduls. Es sind nur noch Änderungen etwa der Kommunikations­adresse (zum Beispiel IP-Adresse) möglich. Beim Abkoppeln des Moduls muss die Eindeutigkeit zwischen MTP und Modul gewährleistet werden. Hier ist es vorstellbar, dass das Modul durch den organg des Abkoppelns in den Aus­lieferungszustand zurückgesetzt wird. Die Lebenszyklus-Information kann dabei im Modul abgespeichert werden.

Die Strukturierung des MTP

Das MTP ist im jetzigen Ausbau als zip-Format realisiert. An der MTP-Wurzel ist eine Manifest-Datei angelegt. Diese XML-Datei enthält die für das MTP relevanten Meta-Daten. Diese geben Auskunft über die Version der zugrundegelegten MTP-Spezifikation sowie über die eindeutige Seriennummer des MTP und beschreiben dessen funktionale Aspekte. Die Information, die in der Manifest-Datei zu den Aspekten abgelegt ist, beinhaltet Typ, Pfad zur entsprechenden Datei, Version und ein Flag, das anzeigt, ob der enthaltene Aspekt aktiv ist. Weiterhin enthält das Manifest vordefinierte Einträge für häufig genutzte Dateiarten, beispielsweise Bilder (Images), Zertifikate (Certificates), Hilfedateien (Help­files) und Handbücher (Manuals). Eine weitere wichtige Informationsklasse sind Angaben zur Kommunikation mit der dezentralen Recheneinheit des Moduls (SPS oder Embedded Controller).

Im Projekt DIMA wurden konkret zwei Integrationsaspekte untersucht – das Bedienen und Beobachten (hmi.xml) und die zustandsbasierte Prozessführung (control.xml). In beiden Fällen wurde zur Beschreibung der Kommunikation der gleiche Ansatz gewählt. Das heißt: Für jede Kommunikationstechnologie, die das Modul unterstützt, wird ein neues Element 'pconnection' eingefügt. Dieses Element beinhaltet die Definition der Kommunikationsparameter sowie die Beschreibung der einzelnen, für die Kommunikationstechnologie spezifischen Variablen 'pvalue'. Die logische Verbindung zwischen der Technologie-unabhängigen und Technologie-bezogenen Variablen wird über eine eindeutige ID 'pvid' des MTP hergestellt.

Der Aspekt Bedienen und Beobachten

Weil bei der Erstellung der modulspezifischen Bedienbilder unterschiedliche Engineering-Werkzeuge zum Einsatz kommen, muss das MTP diese Bedienbilder in einer neutralen Beschreibungsform abbilden. Weiterhin muss den ­spezifischen Darstellungsmöglichkeiten der Bedien- und Beobachtungssysteme sowie den Projekt-spezifischen Anforderungen an die Darstellung einzelner Elemente eines Bedienbildes Rechnung getragen werden. Und bei der Integration von Modulen unterschiedlicher Hersteller gilt es, eine einheitliche Darstellung der Bedienelemente auch über die Modulgrenzen hinweg zu gewährleisten. DIMA setzt darum auf eine rollenbasierte Beschreibung der einzelnen Bedienelemente.

Sowohl beim Modulhersteller (Sys A), der die Bedienbilder erstellt, als auch beim Modul-Betreiber (Sys B), der für das Bedien- und Beob­achtungssystem verantwortlich ist, müssen Bibliotheken zum Einsatz kommen, die um eine semantische ­Bedeutung der einzelnen Bedien­elemente ergänzt wurden. Dazu gilt es ein minimales Set an Elementen zu identifizieren, die zum Bedienen mehrerer Module notwendig sind. Hierzu bedarf es einzig der Abstimmung, welche Elemente (zum Beispiel Ventil, Antrieb, Messstelle) mit welchen Informationen (zum ­Beispiel Sollwert, Istwert) zu über­tragen sind. Die grafischen Darstellungen des Bedienelementes oder das Inter­aktionsverhalten müssen hingegen nicht harmonisiert werden. Dies ist und bleibt Differenzierungsmerkmal der Systeme, in die zu integrieren ist.

Um die geforderte Technologie-Unabhängigkeit zu wahren, werden die Beziehungen zwischen den Elementen eines Bedienbildes innerhalb des MTP mathematisch-abstrakt als Graph, ­bestehend aus Knoten und Kanten, ­beschrieben. Die x-/y-Koordinaten der Bedienbildelemente im Modul-En­gineeringsystem werden als Attribute an den Knoten mitgeführt und können vom Integrations-Engineering-System als Layouthinweise genutzt werden.

Aufgrund der guten Einbindung in Open-Source-Editoren für die Beschreibungsvalidierung und der guten Unterstützung durch Graphen-theoretische Funktions- und Algorithmensammlungen fiel im Projekt die Wahl auf das XML-basierte Beschreibungsmittel GraphML. Jedes Bedienbild eines Moduls wird als einzelner Graph mit dem in der GraphML-Spezifikation definierten Element vom Typ 'graph' beschrieben. Die graph-Elemente der Bedienbilder sind Kind-Elemente des Sammel-Elements 'pictures', das sich direkt unterhalb des Wurzel-Elements HMI befindet.

Die Beschreibung der Bedienbilder wird im XML-Format trans­portiert. Zur genauen Identifikation trägt jedes Element eine eindeutige 'id'.

© Wago Kontakttechnik

Jedes Bedienbildelement wird durch das in GraphML spezifizierte XML-Element 'node' repräsentiert, jede Verbindung zwischen Faceplates (Rohrleitung, Wirklinie, Hierarchie) wird durch das Kanten-Element 'edge' beschrieben. Die Knoten-Elemente, die die Faceplates repräsentieren, werden schließlich durch diverse skalare Attribute näher bestimmt. Für die Beschreibung nicht-skalarer Elemente von Knoten sieht GraphML ein data-Element vor. In diesem Block werden die für den Knoten relevanten Prozessvariablen wie Istwert, Sollwerte, Grenzwerte als variable-Elemente aufgelistet. Jedes variable-Elemente muss wiederum mit diversen Attributen ­ausgezeichnet werden, etwa Hinweisen zur Auszeichnung von statischen Rohrleitungsklassen oder Variablen zur Visualisierung der dynamischen Routing-Information. Bereits mit den wenigen vorgestellten Datenelementen lässt sich ein Großteil der statischen und dynamischen Elemente verschiedener Arten von Bedienbildern beschreiben und im Look&Feel des ­Integrationssystems instanziieren.

Erste Erfahrungen mit DIMA

Die vorgestellte Methodik, welche auf zwei voneinander losgelösten ­Engineering-Prozessen basiert, wurde im Rahmen des Projektes prototypisch in die Engineering-Software e!Cockpit von Wago implementiert. Für das HMI wurde WinCC von Siemens eingesetzt und für die Prozedursteuerung das Tool Proficy-Batch von General Electric.

Mit den verfügbaren kommerziellen und Open-source-Libraries für XML und GraphML waren Export- und Importschnittstellen schnell realisiert, so dass sich das Entwicklerteam auf die werkzeugspezifischen Datenstrukturen und Application Programming Interfaces der Zielsysteme konzentrieren konnte. Je nach Aufbau und Offenheit fielen dafür unterschiedliche Aufwände an.

Resümierend lässt sich feststellen, dass sich die aufgezeigten Lösungs­ansätze letztendlich nur realisieren ­lassen, wenn die Werkzeuge der PLS-Ebene über offene Schnittstellen ver­fügen. Hier sind Interessenge­meinschaften und Verbände, wie Namur und GMA, ge­fordert, die Hersteller von Prozessleitsystemen in die Pflicht zu nehmen. Ein kritischer Punkt für die Akzeptanz ­dieses An­satzes ist dabei sicherlich die ein­malige Implementierung der MTP-Schnittstelle in die jeweiligen Engineering-Systeme.

Interview "Geschlossene Architekturen werden aufgetrennt"

Ulrich Hempen, Leiter Market Management Industrie & Prozess bei Wago: "Der Druck der Anwender wird das Zugpferd für DIMA sein."

© Wago Kontakttechnik

Mit DIMA beziehungsweise will Wago eine neue Methodik zur Automation modularer, verfahrenstechnischer Anlagen etablieren. Ulrich Hempen, Leiter Market Management Industrie & Prozess bei Wago, gibt Auskunft über den Status quo des Vorhabens.

Herr Hempen, zur letzten Namur-Sitzung hat Wago den Dima-Ansatz vorgestellt. Wie war die Resonanz darauf?

Die Resonanz auf das Konzept war ausgesprochen positiv. Die Reaktionen von Anwenderseite und auch von Herstellern haben gezeigt, dass es längst Zeit war für einen neuen modularen, offenen Automationsansatz und dass wir damit auf dem richtigen Weg sind. Die Namur hat dieses Konzept angenommen und entwickelt derzeit, auch mit Unterstützung des ZVEI-Arbeitskreises "Modulare Automation", darauf basierend eine für die Anforderungen aus der Prozesstechnik notwendige vollständige Methodik. Durch die – nicht zuletzt von den Anwendern getriebene – sehr gut funktionierende Zusammenarbeit der Namur mit dem ZVEI rechnen wir noch in diesem Jahr mit einer Finalisierung des MTP-Standards. Somit könnte die Umsetzungen ab Herbst gestartet werden, um in 2016 marktreife Produkte vorstellen zu können.  

Um die Idee von der modularen Prozessautomatisierung realisieren zu können, müssten sich die Marktteilnehmer auf einheitliche Standards einigen. So existieren Stand heute beispielsweise keine einheitliche Semantik und auch keine einheitliche Beschreibung von Prozessmodulen. Was macht Sie zuversichtlich, dass sich dies in absehbarer Zeit ändert?

Der Druck kommt von den Anwendern, da diese Prozessanlagen zukünftig auf Grund der Marktanforderungen modular aufbauen müssen. Anwenderdruck war immer der beste Nährboden auf dem sich Hersteller sehr schnell zur Erfüllung neuer Anforderungen geeinigt haben. Insofern sind wir zuversichtlich, mit DIMA beziehungsweise dem MTP einen Standard setzen zu können.

Um DIMA zum Erfolg zu führen, müssen insbesondere die großen Leitsystem-Hersteller mitziehen. Doch gerade für diese bedeutet ein modularer Ansatz wie Dima doch einen "Generalangriff" auf ihre mächtigen und allumfassenden Leitsysteme, wenn künftig viele Aufgaben bereits von den Modulherstellern erledigt werden. Warum sollten diese also mitziehen?

Sie ziehen mit. Im ZVEI-Arbeitskreis "Modulare Automation", sind die großen Leitsystemanbieter ja vertreten. Prozessleitsysteme sind in der Vergangenheit nie technologisch stehen geblieben sondern haben sich immer konform neuer Marktanforderungen weiterentwickelt. Natürlich bedeutet der jetzt folgende Schritt eine Öffnung der Prozessleitsysteme und Auftrennung der bisher geschlossenen Systemarchitektur, aber auch die PLS-Anbieter sehen darin auch eine große Chance.

Welchen Aufwand bringt die Implementierung beziehungsweise die Generierung eines MTP für den Modulhersteller mit sich?

Hempen: Die Generierung des MTP bedeutet für den Modulhersteller keine Mehrbelastung. Die Generierung fällt durch wenige Knopfdrücke bei der Erstellung der Modulprogrammierung ab. Der Modulhersteller hat durch DIMA eher den großen Vorteil, sein Modul in der Herstellung vollständig zu qualifizieren und gemäß seiner technischen Daten abzunehmen. Er liefert so ein in sich vollständig geprüftes und mit eigener Integrität versehenes Modul in die Anlage. Dies ist der vorteilhaftere Weg als ein Modul zu liefern, dessen Automation später von einem Projektierer im Leitsystem programmiert wird.

Wie gehen Sie mit Modulen um, die keine eigene Steuerungsintelligenz vorgesehen haben?

Die neue Methodik geht davon aus, dass ein Modul, welches einen verfahrenstechnischen Prozess durchführt, der zu regeln und oder zu steuern ist, mit einer programmierbaren Steuerungskomponente versehen ist. Ohne diese könnte das Modul nicht schon vom Hersteller für seine Aufgaben qualifiziert werden und hätte keine eigene Integrität. Dies war aber eines der sechs Kernelemente der DIMA-Entwicklung.