Prozessautomatisierung Konzept zur Zusammenführung von EDDL und FDT

Redakteur: Dr. Jörg Kempf

Michael Kessler, Leiter des Geschäftsfeldes Komponenten und Technologie im Geschäftsbereich Prozessautomation bei Pepperl+Fuchs in Mannheim:

Anbieter zum Thema

Prof. Klaus Bender, Daniel Großmann

Prof. Dr.-Ing. Klaus Bender ist Inhaber des Lehrstuhls für Informationstechnik im Maschinenwesen (itm) der TU-München sowie Vorstand der Profibus-Nutzerorganisation e.V.; D. Großmann ist wissenschaftliche Mitarbeiter am itm.

Seit einigen Jahren konkurrieren die beiden Technologien EDDL und FDT um die Gunst von Leitsystem- und Geräteherstellern und Anwendern. Beide Technologien besitzen unterschiedliche Schwerpunkte, weisen aber auch ein hohes Maß an Überlappung auf. Und genau diese Überlappung führt zur derzeitigen Situation, in der die Technologien am Markt konkurrieren statt sich zu ergänzen.

Warum also nicht „EDDL und FDT“? Diese Frage wurde am Lehrstuhl für Informationstechnik im Maschinenwesen (itm) der TU München aufgegriffen und ein Konzept entwickelt, das die Vorteile der beiden Technologien EDDL und FDT in einer einzigen durchgängigen Lösung zusammenführt. Technologische Basis dieses Konzeptes ist die neue OPC Unified Architecture (UA), die im Juli 2006 von der OPC Foundation freigeben wurde.

Wer kann was?

Die FDT-Technologie spezifiziert als offener Standard die Schnittstellen zwischen der gerätespezifischen Bedienfunktion, dem so genannten Device Type Manager (DTM), und dem geräteunabhängigen Engineering System, dem FDT-Frame. Da ein DTM nur diese Schnittstellen-Spezifikation erfüllen muss, hat ein Gerätehersteller größtmögliche Freiheit bei der Gestaltung der Bedienfunktionalität, der Implementierung der DTM-Software-Komponenten sowie der Auswahl der Programmiersprache. So kann auch die Bedienung sehr komplexer Geräte mit diesem Standard sehr gut realisiert werden. Ein wesentlicher Nachteil der FDT-Technologie ist die enge Bindung der vom Gerätehersteller gelieferten DTM-Software-Komponenten an die Microsoft Windows-Plattform.

Im Gegensatz dazu definiert die ebenfalls offene und standardisierte EDDL-Technologie eine eigene Sprache, mit welcher die Gerätehersteller textbasierte Beschreibungen (Electronic Device Description, EDD) ihrer Geräte erstellen – sozusagen ein digitales Datenblatt. Der Sprachumfang ist gegenüber Standard-Programmiersprachen begrenzt und speziell auf die Gerätebeschreibung zugeschnitten. Dies ermöglicht eine einfache und effiziente Erstellung von EDD-Gerätebeschreibungen, die in einem geräteneutralen offenen Engineering-System von einem EDD-spezifischen Interpreter verarbeitet werden. Eine solche EDD ist deshalb unabhängig von Betriebssystemen sowie Rechnerplattformen, besitzt ein einheitliches, durch die EDDL vorgegebenes Bedienkonzept und zeichnet sich aufgrund der Interpretation durch eine hohe Robustheit aus. Für sehr komplexe Geräte führt der begrenzte Funktionsumfang der Sprache EDDL zu störenden Einschränkungen.

Was passiert nun?

Der Lehrstuhl für Informationstechnik im Maschinenwesen (itm) an der TU München hat nun ein integrierendes Konzept erarbeitet, welches das Beste beider Technologien in eine durchgängige Client-Server-Architektur integriert. Zur Definition einer solchen Client-Server-Architektur wurde ein entsprechendes Geräte-Bedienmodell mit vier Schichten abgeleitet:

Data-Model: Hier werden die Daten, die vom Gerät zu Engineering-Zwecken veröffentlicht werden, abgebildet. Dies umfasst auch Metainformation wie Einheit, Wertebereich oder Grenzen.

State-Model: Hier werden Abhängigkeiten zwischen den Elementen des Data-Models und des Gerätezustandes abgebildet, um die Konsistenz sicher zu stellen.

Diese beiden Schichten werden zum Device Information Model (DIM) zusammengefasst und beschreiben im Wesentlichen die Datenschnittstelle des Gerätes bezüglich Struktur und Verhalten. Die weiteren Schichten sind:

Advanced User Functions: Hier sind höherwertige Benutzerunterstützungs-Funktionen wie automatische Berechnung von Linearisierungstabellen aus 3D-Tankgeometrien untergebracht.

Graphical User Interface (GUI): Das GUI bildet die Schnittstelle zum Benutzer.

Diese beiden Schichten bilden ebenfalls eine Einheit und werden zum Device Operation Model (DOM) zusammengefasst. Verglichen mit der Gerätefirmware lässt sich feststellen, dass das DIM eine 1-zu-1-Abbildung der von der Firmware zu Bedienzwecken veröffentlichten Gerätedaten ist. Das DOM hingegen greift auf die Datenelemente des DIM für einen jeweiligen Bedienzweck zu.

Technologische Basis für das neue Konzept ist die neue OPC Unified Architecture. Basis für die Beschreibung des DIM ist EDDL, da die Sprache alle notwendigen Elemente zur Abbildung des DIM enthält. Gleichzeitig bieten Plattformunabhängigkeit und interpreterbasierte Ausführung ein hohes Maß an Technologieunabhängigkeit und Robustheit.

Auf der Clientseite wird im sog. Device Engineering Framework – vergleichbar mit der FDT-Frameapplication – über das DOM die Bedienung des Gerätes ermöglicht. Hier liegt der Fokus auf den Bedien-Abläufen, die während der Gerätebedienung durchlaufen werden. Weiterreichende Funktionalität und GUIs werden gemäß dem FDT-Konzept vom Gerätehersteller programmiert. So wird die Flexibilität von FDT, welche die freie Programmierung bietet, in das neuartige Konzept integriert.

„Der Siemens Bereich Automation and Drives (A&D) ist mit PCS7 sowohl Lieferant von Leitsystemen als auch von Geräten etwa für die Feldebene. Für uns ist eine einheitliche Beschreibungstechnologie von entscheidender Bedeutung, schließlich zieht die Unterstützung mehrerer Technologien einen enormen Aufwand bei Implementierung und Tests nach sich. Daher setzen wir auf eine Technologie und unterstützen deshalb ausschließlich die Geräteeinbindung über Beschreibungssprachen (EDD, GSD). Der Vorschlag von Hr. Prof. Bender ist hier eine konsequente Weiterentwicklung. FDD-UA hat für uns als Gerätelieferant eigentlich nur Vorteile. Wir können unsere Geräte weiterhin mit EDDL beschreiben und falls notwendig zusätzlich Oberflächenteile als Zusatz programmieren. Dadurch verlieren wir nicht die Vorteile von EDD, haben aber für die Ausnahmefälle eine einfache, standardisierte Erweiterungsmöglichkeit.

Für uns als Leitsystemhersteller ist eine neue Technologie zuerst einmal ein zusätzlicher Implementierungsaufwand. Unsere Engineeringtools müssten diese neue Technologie unterstützen. Aber auch hier können und wollen wir die Augen vor der Zukunft nicht verschließen. Eine saubere Trennung von Server- und Client-Funktionalität käme unseren Gerätetools im Leitsystem vor allem bei der Anbindung von MES-Applikationen zu Gute. Hier hat OPC-UA gute Vorarbeit geleistet und wir haben diese Definitionen mit unterstützt und vorangetrieben. Deshalb bietet FDD-UA für zukünftige Leitsysteme eine gute Möglichkeit, Geräte in eine solche Umgebung einzubinden.

Ein weiterer wichtiger Punkt aus unserer Sicht ist die Unabhängigkeit von einem Betriebssystem. Dies ist bei der vorgestellten Lösung sowohl für die Beschreibungssprache EDDL als auch für die Schnittstellentechnologie OPC-UA gegeben. Alles in allem ist der Vorschlag eine gute Möglichkeit, die heutigen Welten zu vereinheitlichen.“

„Die FDD UA-Idee adressiert einen wichtigen Punkt, der uns Geräteherstellern zu schaffen macht. Im Bereich Geräteintegration stehen sich zurzeit zwei Technologien gegenüber, die nicht nur technisch beide ihre Vor- und Nachteile haben, sondern deren Vertreter sich leider teilweise heftig in den Haaren liegen. Es wäre ideal für uns und vor allem auch für unsere Kunden, wenn es eine Technologie gäbe, welche die Vorteile von EDDL und FDT vereinen würde und dabei die jeweiligen Nachteile, soweit überhaupt möglich, vermeidet. Wir sind froh, dass sich Herr Professor Bender dies zum Ziel gemacht hat. Es besteht allerdings die Gefahr, dass das Konzept, wie es sich uns heute darstellt, einige Probleme, die FDT lösen kann, nicht ausreichend adressiert. Ich halte hier besonders die ausschließliche Nutzung von EDD für die Beschreibung des DIM für kritisch. Die EDDL unterstützt heute nur drei Kommunikationsprotokolle während sich mit FDT beliebige Protokolle in beliebigen Kombinationen implementieren lassen. So etwas kann natürlich in der EDD-Sprachdefinition nachgerüstet werden, dauert aber naturgemäß seine Zeit.

Die Nutzung plattformunabhängiger Schnittstellen, die einen Kernpunkt des neuen Konzeptes darstellt, ist ein sinnvolles Ziel. Allerdings ist es wichtig zu thematisieren, dass jede Schnittstelle heute auf irgendeiner Plattform implementiert sein muss, und sei es auch nur der EDD Interpreter. Ich will damit sagen, dass jedes neue Konzept zu seiner tatsächlich vorhandenen Plattformabhängigkeit (und nicht nur Windows ist eine Plattform) stehen sollte. Das öffnet den Weg, mit dieser Problematik sinnvoll umzugehen.

Die größte Herausforderung wird es sicher sein, alle Mitspieler, die ja nicht unwesentlich in ihre jeweiligen Technologien investiert haben und die es zu schützen gilt, ins Boot zu holen. Wenn das nicht klappt, werden wir erleben, wie z.B. FDT eine „betriebssystemunabhängige“ Schnittstelle definiert und EDD noch mehr Funktionen in den Sprachumfang aufnimmt, um alle Funktionen im DOM abzubilden. Das Resultat wäre eine dritte Integrationsmethode und keine Vereinheitlichung. Eine dritte Baustelle statt eines Migrationspfades – das wünschen wir uns ganz bestimmt nicht!“

(ID:195016)