Die FDT-Technologie (= \’Field Device Tool\‘) basiert auf einer Spezifikation einer standardisierten Schnittstellendefinition, herausgegeben von der FDT Joint Interest Group, die eine herstellerübergreifende Parametrierung von Feldgeräten von einem PC aus ermöglicht. Der Zugriff auf die einzelnen Feldbusteilnehmer erfolgt aus einer einzigen Rahmenapplikation heraus, die sowohl die Topologie des Feldbusses verwaltet, als auch die Speicherung der Daten und Parameter der einzelnen Geräte übernimmt. Die eigentliche Konfiguration wird über gerätespezifische Plug-Ins vom Gerätehersteller vorgenommen. Diese Plug-Ins – sogenannte Device Type Manager (DTMs) – bringen neben einem eigenen Satz an Menükommandos auch ein User Interface mit, das nahtlos in die Oberfläche der Rahmenapplikation integriert werden kann. Auf dem Markt sind derzeit diverse Rahmenapplikationen erhältlich; ab der Version 3.4 wird auch CoDeSys die Einbettung von DTMs ermöglichen. Gerätekonfiguration mit proprietären Programmen Moderne Feldgeräte sind derart komplex, dass ihre Konfiguration in der Regel nicht direkt über das User Interface an der Hardware, sondern über eine dedizierte Software vom PC aus vorgenommen wird. Diese gerätespezifische Software vom Hersteller läuft meist als eigenständige Applikation und stellt ein eigenes User Interface zur Parametrierung, Datenspeicherung und Wartung zur Verfügung. Der Zugang zum Feldgerät erfolgt typischerweise nicht über den eigentlichen Feldbus, sondern über einen separaten Zugang z.B. via USB oder RS232/485. Werden Geräte verschiedener Hersteller in einer Anlage verschaltet, bedeutet das für den Applikateur oder Servicetechniker die Installation und das Erlernen verschiedenster proprietärer Programme sowie das Bereithalten der diversen Anschlusskabel. Da diese Programme isoliert laufen, ist ein Sichern der gesamten Konfiguration aller Geräte \’auf Knopfdruck\‘ nicht möglich. Gerätekonfiguration mit Feldbus-Editoren in CoDeSys Alternativ zu diesem herstellerspezifischen Ansatz ist im Fall von CoDeSys zusätzlich die Konfiguration der Feldgeräte über den Busmaster der SPS möglich. Dies wird durch feldbusspezifische Editoren in CoDeSys ermöglicht, die eine Offline-Parametrierung jedes Busteilnehmers erlauben. Diese so erstellten Parameter werden später beim Übertragen des SPS-Programms zusätzlich auf die Steuerung geladen. Beim Starten des Programms versendet der Busmaster dann Telegramme mit diesen Parametern an die einzelnen Teilnehmer. Dieser Ansatz bietet den Vorteil der direkten Nutzung des Feldbusanschlusses und einer zentralen Datenhaltung in der gleichen Projektdatei, die auch das SPS-Programm enthält. Ein weiterer Pluspunkt für den Endanwender: Nur ein Tool muss installiert und erlernt werden. Gerätekonfiguration mit FDT Die Konfiguration von Feldgeräten im FDT-Kontext ist wie die Zusammenführung obiger Ansätze: Es gibt nur eine Rahmenapplikation, in deren Projektdatei Parameter und Topologie gespeichert werden. Der Zugriff auf die Teilnehmer erfolgt über den Feldbus. Das User Interface zur Parametrierung kommt direkt vom jeweiligen Gerätehersteller in Form von DTMs, die als Plug-In in der Rahmenapplikation eingebettet sind. Setzt man CoDeSys als Rahmenapplikation ein, steht dem Anwender zusätzlich eine komplette Entwicklungsumgebung zur Erstellung IEC61131-basierter SPS-Programme zur Verfügung. Wird der verwendete Feldbus direkt von einem CoDeSys-internen Kommunikationskanal unterstützt, kann über ein einziges Kabel die Programmierung der SPS sowie die Online-Konfiguration der Busteilnehmer mittels DTM erfolgen. \’Online\‘ bedeutet in diesem Kontext, dass das DTM eine Kommunikation direkt mit dem Gerät herstellen kann, ohne dass zwingend ein Programm auf der SPS läuft. Pro und Contra Einige Vorteile der beschriebenen FDT-Lösung liegen in der zentralen Datenhaltung, dem Einsatz von maßgeschneiderten User Interfaces direkt vom Geräte-Hersteller und in der Mitnutzung der bestehenden Kommunikationsverbindung zur SPS und dem dort angeschlossenen Feldbus. Mit der zentralen Datenhaltung ist die Speicherung des SPS-Programms, der Feldbustopologie und der Geräteparameter per Knopfdruck in eine einzige Datei möglich. Das vereinfacht die Archivierung und den Austausch von Projekten. Gleichzeitig wird damit auch eine durchgängige Versionsverwaltung ermöglicht – das irrtümliche Laden von inkonsistenten Parametersätzen beim Einsatz isolierter Konfigurationstools ist damit als Fehlerquelle eliminiert. Da das DTM direkt vom Hersteller des Feldgerätes implementiert wird, hat dieser die Chance, dem Endanwender ein gefälliges und ergonomisches User Interface zur Verfügung zu stellen. Eine gute Bedienbarkeit des DTMs kann dem Applikateur oder Servicetechniker die Arbeit erleichtern und damit Zeit und Kosten sparen. Durch die gezielte Abstimmung auf den Gerätetyp und die Möglichkeit, online mit dem Gerät zu kommunizieren, kann ein DTM zahlreiche Funktionen anbieten, die über die reine Buskonfiguration hinausgehen. Denkbar sind hier z.B. Oszilloskop- oder Trendfunktionen genauso wie ein Aktualisieren der Firmware. Durch die gemeinsame Nutzung der Infrastruktur zur Kommunikation mit der SPS und dem Feldbus benötigt der Anwender nur noch ein Kabel. Über dieses können alle angeschlossenen Feldgeräte herstellerübergreifend parametriert werden – ein lästiges Umstecken der Verbindungskabel zwischen den einzelnen Geräten entfällt. Ein Kritikpunkt der FDT-Technologie besteht in der strikten Busausrichtung, die sich aus dem Aufbau der FDT-Spezifikation ergibt: Die eigentliche Spezifikation beschreibt die grundlegenden Schnittstellen, die zum Datenaustausch zwischen den DTMs und der Rahmenapplikation benötigt werden. Dieser Kern der Spezifikation wird durch zahlreiche sogenannte \’Annexe\‘ ergänzt, die ihrerseits die Datenstrukturen beschreiben, die mittels der Schnittstellen ausgetauscht werden sollen. Pro Feldbus gibt es solch einen Annex, der z.B. das Setzen der Knotennummer oder das Auslesen von Prozesskanälen beschreibt. Diese Prozesskanäle können, bei entsprechender Unterstützung durch die Rahmenapplikation, direkt Variablen in einem SPS-Programm zugewiesen werden. Um diese essentielle Funktionalität allen Anbietern von DTMs bereitstellen zu können, müsste eine Rahmenapplikation alle Annexe implementieren. Dies ist aufgrund der großen Anzahl von teils proprietären Annexen nicht möglich. Hier fehlt bislang eine Schnittstelle für die generische Beschreibung von Prozesskanälen, um busübergreifend die Verbindung zwischen SPS-Programm und DTM zu schaffen. Ein anderer möglicher Nachteil liegt in der Diversität der Bedienkonzepte. Da Gerätehersteller ihre DTMs nach ihren eigenen Vorstellungen implementieren, führt dies zwangsläufig zu einer bunten Landschaft an User Interfaces, die sich auf dem PC eines Anwenders tummeln. Diese User Interfaces mögen zwar die jeweiligen firmeninternen Richtlinien zur Ergonomie erfüllen, im Kontext einer Rahmenapplikation mit DTMs verschiedenster Hersteller besteht jedoch die Gefahr, dass ein exotisches Bedienkonzept und Grafikdesign den Endanwender überfordern und die Effizienz darunter leidet. Die FDT Joint Interest Group hat dieses Manko erkannt und einen \’Style Guide\‘ nachgelegt, der den Entwicklern von DTMs Richtlinien zur Bedienung und grafischen Gestaltung von DTMs an die Hand gibt. Die Realität zeigt leider, dass dieses Papier noch nicht alle Hersteller erreicht hat. Fazit Im Vergleich zur Gerätekonfiguration mit proprietären, isolierten Programmen ist der Einsatz von DTMs die bessere Alternative, da die zentrale Datenhaltung und die gemeinsame Nutzung der Kommunikationsverbindung einen deutlichen Mehrwert darstellt. Vergleicht man die DTM-gestützte Konfiguration mit der Parametrierung mittels Feldbus-Editoren in CoDeSys, liegt die FDT-Technologie nicht mehr klar vorne. Beide Ansätze vereinen die Vorteile der Speicherung aller Daten in einer einzigen Projektdatei mit dem zentralen Zugang zur SPS und dem Feldbus. Ob der Anwender die Arbeit mit den herstellerspezifischen User Interfaces der DTMs der Nutzung von generischen Feldbus-Editoren vorzieht, liegt sicher an persönlichen Vorlieben und Arbeitsweisen. Da mit der kommenden Version 3.4 von CoDeSys beide Lösungen parallel in einem Projekt nutzbar sein werden, kann der Endanwender hier selbst testen und entscheiden, welcher der Ansätze ihm eine effiziente Konfiguration von Feldgeräten ermöglicht.
CODESYS GmbH
