Die FDT-Technologie hat ihren Ursprung in der Prozessautomatisierung. Aufgrund der Feldbus-Vielfalt, die in der Fabrikautomation herrscht, ist diese Technologie aber gerade auch in diesem Umfeld für das standardisierte Gerätemanagement von Nutzen. Denn die hier üblichen SPS-Programmiersysteme – wie zum Beispiel Codesys – können bei Verwendung von FDT eine deutlich bessere Geräte-Integra­tion bereitstellen.

Für die Implementierung der FDT-Schnittstellen in einer FDT-Applikation – auch FDT-Rahmenapplikation beziehungsweise Frame Application genannt – steht eine Software-Komponente zur Verfügung, die sogenannte ‚Frame Common Component‘. Diese Komponente, welche über die Firma M&M Software erhältlich und von der FDT Group zertifiziert ist, dient als Basiskomponente. Ihr Einsatz stellt letztlich die spezifikationskonforme Implementierung sicher und verbessert die Interoperabilität mit den verschiedenen DTMs.

Die ‚Frame Common Component‘ enthält alle Schnittstellen gemäß der FDT-Spezifikation die notwendig sind, um eine FDT-Applikation zu entwickeln. Eine solche Applikation kann die unterschiedlichsten Anwendungen abdecken, zum Beispiel ein Stand-alone-Tool für die Gerätekonfiguration, ein Diagnosetool oder ein Asset-Management-Tool.

Bild 1: Die Architektur einer FDT-Applika­tion: Kapselung von Funktionen in Kom­ponenten sowie deren Schnittstellen.

© Schneider Electric

In Bild 1 ist die FDT-Applikation durch den äußeren Rahmen dargestellt. Hierin sind alle Funktionen der jeweiligen Applikation implementiert. Der innere Teil zeigt die Basiskomponente (fdtContainer component). Zwischen der Applikation und der Basiskomponente befinden sich die Schnittstellen, welche die beiden Elemente verbinden. Die Pfeilrichtung zeigt dabei an, ob der Schnittstellenaufruf zur Basiskomponente oder zur Applikation hin erfolgt.

Im unteren Teil der Applikation ist der Datenbank-Adapter (DBAdaptor) zu sehen. Er bildet die Adaptionsschicht zur applikationsspezifischen Datenbank. Die im Datenbank-Adapter gezeigten Funktionen (zum Beispiel ‚Project Record‘ oder ‚DTM Instance Data‘) sind Platzhalter für die Ausprogrammierung der Datenbankzugriffe.

Die Basiskomponente selbst enthält Funktionen für die Verwaltung der DTMs (DTM Catalog) sowie das Applikationsprojekt (FrameProject). Zum Projekt gehören die Anlagentopologie, die dazugehörigen DTMs (DTM List) und ein Proxy. Dieser Proxy löst abstrakte Aufrufe online in einzelne FDT-Funk­tionsaufrufe auf – zum Beispiel ‚gehe online‘. Der instanziierte DTM selbst läuft in der Komponente DTMContainer.

Das Plug-in-Konzept von Codesys

Bild 2: Ausschnitt aus der Codesys-Architektur mit den FDT-Komponenten. Bei anderen Feld­bussen ist eine äquivalente Struktur vorgesehen.

© Schneider Electric

Codesys ist eine Software-Suite für die Automatisierungstechnik. Basis hierfür ist das IEC-61131-3-Programmiertool. Es erlaubt die Integration zusätzlicher Funktionen durch maßgeschneiderte Plug-Ins wie etwa neue Menüs, Editoren und so weiter. Auch die FDT-Basiskomponente wird mit diesem Mechanismus in das Programmiertool eingebettet. Bild 2 zeigt einen Ausschnitt aus der Codesys-Architektur mit den FDT-Komponenten. Parallel dazu ist die Projektstruktur zu sehen, wie sie in Codesys dargestellt wird (Codesys Device Tree). Das ‚FDT-Integration Plug-in‘ enthält die FDT-Basiskomponente, um ein FDT-Projekt mit den dazugehörigen DTMs zu verwalten.

Die in Bild 2 dargestellte Architektur zeigt die Integration am Beispiel von CANopen-Geräten. Es ist möglich, sowohl Geräte mit als auch ohne DTM zu verwenden. Der CANopen-Master wird durch einen DTM repräsentiert, mit dem der CANopen-Feldbus konfiguriert wird. Des Weiteren ist er die Kommunikationsschnittstelle zu den CANopen-Geräten. Hierzu dient das Interface ‚IFdtCommunication‘, über das ein ­Geräte-DTM den Datenaustausch mit seinem Gerät durchführt (DTM für ­Slave 2). Der CANopen-Master-DTM konvertiert die Daten vom Geräte-DTM in protokollspezifische Nachrichten – in diesem Fall CANopen – und sendet ­diese an das Gerät. Die Antwort vom Gerät wird entsprechend in umgekehrter Reihenfolge verarbeitet.

Die Geräteverwaltung

Bild 3: Beispiel eines DTM im Codesys-Tool ‚SO-Machine‘ von Schneider Electric. Der DTM für einen Servoantrieb verfügt über vielfältige Funktionen – wie etwa das dargestellte Oszilloskop für die Untersuchung/Beobachtung von Antriebsparametern.

© Schneider Electric

Die Geräteverwaltung erlaubt das Mischen von Komponenten, die aufgrund ihrer Einfachheit keinen expliziten DTM benötigen, mit Geräten mit höherer Funktionalität, welche sich mittels des DTMs in vollem Umfang nutzen lassen. Für alle Geräte existieren in Codesys eine allgemeine XML-Gerätebeschreibung sowie die dazugehörige Feldbus-Gerätedatei (zum Beispiel EDS bei CANopen). Die Gerätebeschreibung enthält alle Informationen zum Gerät, dessen Parameter und Kommunikationsmöglichkeiten.

Kommt ein Gerät mit DTM zur Verwendung, so wird der DTM aus dem DTM-Katalog in das Projekt übernommen und die dazugehörige XML-Beschreibung automatisch generiert. Die benötigten Daten erhält das System über die IDtm-Schnittstelle. Unter anderem werden auf diese Weise Angaben zum Hersteller, zum Gerätetyp und zu den Versionsdaten bereitgestellt. Ein Beispiel für ein Gerät mit umfangreicher Funktionalität sind etwa Frequenzumrichter. Hier ist es sinnvoll, für jede Gerätefamilie einen DTM bereitzustellen, der das komplette Spektrum einer Geräteserie abdeckt.

Die Feldbus-Konfiguration

Der CANopen-Master-Configurator ermöglicht die komfortable Konfiguration des Feldbusses. Hierzu gehören Parameter für den Feldbus selbst wie etwa Baudrate oder Heartbeat (Überwachungszeit). Dieser DTM vergibt zudem die Adressen für die Geräte (Node-ID) und führt das Mapping von PDOs (ProcessDataObjects) durch. Letzteres stellt den Bezug her zwischen den PDOs und den Applikationsobjekten im Objektverzeichnis. Diese Daten tauscht der Master-Configurator mit den Geräte-DTMs über die IDtm-Schnittstelle (SetParameters) aus. Der Master-Configurator bekommt ebenfalls mitgeteilt, wenn Daten durch den Geräte-DTM geändert werden. Diese Änderungen kann er dann über die Schnittstelle abfragen (GetParameters). Nach Abschluss der Konfiguration prüft der Master-Configurator die Konsistenz der Daten des CANopen-Systems.

Die CANopen-Daten werden auf den Master sowie auf die Geräte runtergeladen und zur Laufzeit für den Systemhochlauf, die Einstellung der Feldbus-Parameter sowie den Datenaustausch genutzt.

Die Prozessdaten-Generierung

Prozessdaten sind die Daten, die zur Laufzeit am Feldbus zwischen der SPS und den Slaves übertragen werden. Die Beschreibung der Prozessdaten, deren Definition mittels der Geräte-DTMs erfolgt, wird an einer entsprechenden Schnittstelle (Process Channels) bereit­gestellt. In diesem Fall werden nicht die Informationen aus der EDS (Electronic Devicve Description) verwendet, da ­deren Informationen hierfür nicht ausreichen. Dieses Vorgehen ist insbesondere bei modularen Geräten hilfreich, deren Konfiguration variabel ist. Für diese Prozessdaten werden die PDOs (Process Data Objects) automatisch ge­neriert. Im Geräte-DTM können den Prozessdaten existierende Variablen zugeordnet beziehungsweise neue definiert werden. Das SPS-Tool erhält die Variablen vom Geräte-DTM und stellt sie letztlich dem SPS-Programm zur Verfügung, über welches sie dann direkt vom SPS-Programmierer zur weiteren Verarbeitung verwendbar sind.

Fazit: Durch die Nutzung der FDT-Technologie in Codesys erhält der Programmierer umfangreiche Möglichkeiten für das Gerätemanagement. Die Funktionalität und Flexibilität übersteigen bei weitem das, was durch die Nutzung der üblichen Beschreibungsdateien (EDS, GSD) möglich ist. So lassen sich etwa die Geräte von unterschiedlichen Herstellern in der gleichen Art und Weise in ein Tool integrieren und es besteht über Feldbus-Hierarchien hinweg Zugriff auf die Geräte. Mit ihrer grafischen Bedienoberfläche stellen DTM einen einfachen Zugang zum jeweiligen Gerät her und bringen darüber hinaus gerätespezifische Diagnosefunktionen mit, die im Wartungsfall eine schnelle Fehlererkennung erlauben.

Autoren:
Nuno Barral ist Project Design Leader und Software-Architekt bei der Schneider Electric Automation;
Manfred Brill ist Innovation & Technology Senior Manager bei der Schneider Electric Automation.

Was ist die FDT-Technologie?

FDT standardisiert das Gerätemanagement für Feldgeräte in einem Werkzeug. Die Vereinheitlichung der Gerätever­waltung ist unabhängig vom Gerätehersteller und verwendeten Feldbus/Netzwerk. Damit lässt sich jedes Gerät in einem FDT-Tool durch standardisierte Schnittstellen konfigurieren, bedienen und instandhalten – und zwar unabhängig vom Hersteller, Typ oder Kommunikationspro­tokoll. Die drei Schlüsselelemente von FDT sind:

1. Die FDT-Schnittstelle – der Standard für das Gerätemanagement
   Die FDT-Schnittstelle ist die Spezifika­tion, die den standardisierten Datenaustausch zwischen Geräten und dem Leitsystem beziehungsweise den Engineering- und Asset-Management-Tools beschreibt.

2. Der DTM (Gerätetreiber)
   Der DTM (Device Type Manager) bietet eine einheitliche Struktur für den Zugriff auf die Geräteparameter, Konfiguration und Bedienung der Geräte sowie zur Störungs­diagnose. DTMs reichen von der einfachen grafischen Bedienoberfläche für die Parametrierung bis zur hochentwickelten Anwendung, die komplexe Echtzeit-Berechnungen für die Diagnose und Wartung beherrschen. DTMs werden in drei Kategorien unterteilt:
   
   Device-DTM:
   -  Wird vom Gerätehersteller mitgeliefert.
   -  Stellt die gesamte Logik und Parametrierung eines Gerätes dar.
   -  Schafft eine standardisierte Schnittstelle zur FDT-Rahmenapplikation.
   -  Lässt sich in jeder beliebigen FDT-Rahmen- applikation einsetzen.
   -  Basiert auf dem DTM-Styleguide.
   
   Comm-DTM:
   -  Stellt Kommunikationskomponenten wie PC-Netzwerk-Karten und Koppler dar.
   
   Gateway-DTM:
   -  Stellt Komponenten dar, die zwei unterschiedliche Netzwerke/Feldbusse verbinden.
    
3. Die FDT-Rahmenapplikation (Hostsystem)
   Bei der Rahmenapplikation (Frame Application) handelt es sich um ein Softwareprogramm, das Device-, Comm- und Gateway-DTMs von unterschiedlichen Herstellern und für verschiedene Netzwerke/Feldbusse integriert. Die Rahmenapplikation bietet:
   
   -  gemeinsame, einheitliche Umgebung
   -  Benutzerverwaltung   
   -  DTM-Verwaltung 
   -  Datenmanagement
   -  Netzwerk-Konfiguration
   -  Navigation