14.Apr.2009

Feldgeräte-Engineering
Die Vorteile von FDT/DTM am Beispiel Feldbus-Gateway

Als Alternative zu proprietären Softwarelösungen erschließen sich gerätespezifische DTMs sowie die FDT-Frame-Applikationen mehr und mehr den Markt der Fabrikautomation. Beispiel Feldbus-Gateway: Neben einer flexiblen Konfiguration tragen die genannten Technologien hier wesentlich dazu bei, die Entwicklungs- und Pflegekosten zu senken.

DTM für Gateways zwischen Busprotokollen

Hilscher

Stehen DTMs für Gateways zwischen verschiedenen Busprotokollen zur Verfügung, so lässt sich ein Feldgerät unabhängig von der Art des Kommunikationsweges ansprechen und zentral konfigurieren.

FDT/DTM ist ein herstellerübergreifendes Konzept, welches die Parametrierung von Feldgeräten verschiedener Hersteller mit nur einem Programm ermöglicht. Ein DTM (Device Type Manager) ist im Prinzip ein Treiber, der alle gerätespezifischen Funktionen (Parametrierung, Diagnose, Wartung) sowie die grafische Bedienoberfläche inklusive einem Hilfesystem für ein bestimmtes Feldgerät oder eine Gerätefamilie umfasst. Ein DTM wird als Programm auf dem PC installiert, lässt sich aber nur aus einem Container - einer so genannten Frame-Applikation - starten. Damit alle DTMs von verschiedenen Herstellern in jedem Container korrekt funktionieren, müssen die Schnittstellen zum umgebenden System sowie zu anderen DTMs klar definiert sein. Diese Schnittstellendefinition wird FDT (Field Device Tool) genannt.

Am Beispiel der Feldbus-Gateway- Familie „netTAP 100" lassen sich die Vorzüge der FDT/DTM-Technologie in punkto Konfiguration aufzeigen. Das genannte Gateway-System verbindet zwei beliebige Kommunikationsschnittstellen miteinander, darunter die wichtigsten Feldbus-Systeme wie ASInterface, CC-Link, CANopen, Devicenet und Profibus sowie ethernetbasierte Systeme wie Ethercat, Ethernet/IP, Modbus- TCP, Powerlink, Profinet und Sercos III. Durch die unterschiedlichen Master- und Slave-Funktionalitäten entstehen allein über 400 mögliche Kombinationen. Damit nicht genug: Unter Berücksichtigung von einfachen seriellen Protokollen über RS232-, RS422- oder RS485-Schnittstellen kommt man leicht auf über 1000 verschiedenen Varianten. Eine solche Gerätevielfalt ist wirtschaftlich nur projektspezifisch oder über einen modularen Ansatz zu realisieren. Im Bereich der Firmware oder Hardware ist diese Vorgehensweise Stand der Technik. Was die Software angeht, ist der Aufbau eines Geräte-DTM aus einzelnen DTM-Modulen hingegen ein neuer Lösungsansatz.

Da im Hause Hilscher bereits eine Vielzahl an Kommunikations- und Slave-DTMs für diverse Kommunikationsbaugruppen vorhanden war, schien es sinnvoll, diese für die Konfiguration und Diagnose der beiden Gateway- Schnittstellen einzusetzen. Dazu musste eine Lösung gefunden werden, diese DTMs voneinander unabhängig und vor allem unverändert einzusetzen. DTMs bieten standardmäßig fest definierte Schnittstellen, benötigen allerdings für die Kommunikation dazwischen immer die Infrastruktur eines FDT-Containers. Der neue Lösungsansatz besteht darin, den netTAPDTM nach außen als einen „normalen" DTM wirken zu lassen, während er in seinem Inneren selber als FDT-Container arbeitet, in den sich DTMs unverändert einbinden lassen.

Die funktionale Ebene des Gateway - im Wesentlichen das Mappen (Zuordnen) der Daten zwischen den beiden Protokollen - ist ebenfalls als DTM realisiert. Durch den internen FDT-Container können dessen drei DTMs miteinander kommunizieren, während sie über ihre „DTMSchale" nach außen hin wie ein Geräte- DTM erscheinen. Damit kann die DTMKomponente des Gateway wie jede andere DTM-Komponente in den unterschiedlichsten FDT-Frameworks zum Einsatz kommen. Eine solche Struktur erlaubt letztlich das einfache Austauschen der Konfigurationsfunktionen entsprechend der Gateway-Schnittstellen und realisiert so die geforderte Modularität auch auf der Konfigurationsebene des Gateway.