Startseite > Automation > Steuerungstechnik > Anlagenmodularisierung nach dem DIMA-Ansatz

Prozessautomatisierung

Anlagenmodularisierung nach dem DIMA-Ansatz

24. Juni 2015, 11:09 Uhr | Ulrich Hempen, Thomas Holm, Michael Obst

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 5

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 Beobachtungssystem verantwortlich ist, müssen Bibliotheken zum Einsatz kommen, die um eine semantische Bedeutung der einzelnen Bedienelemente 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 übertragen sind. Die grafischen Darstellungen des Bedienelementes oder das Interaktionsverhalten 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-Engineeringsystem 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.

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.