In der Fabrikautomation haben sich mit der Zeit aus den verschiedensten Gründen unterschiedliche Feldbusse und Protokolle etabliert. Experten erwarten, dass Netzwerkstrukturen zukünftig flacher und größtenteils auf Ethernet basieren werden. Ganz verschwinden werden alle heutigen Kommunikationsstrukturen aber nicht, schon gar nicht über Nacht. Hersteller von Automatisierungskomponenten müssen daher heute und vermutlich auch morgen weiterhin verschiedene Kommunikationsarten für unterschiedliche Anwendungsfälle unterstützen, z.B. den Anschluss eines Inbetriebnahme-Tools über eine Service-Schnittstelle oder die Verbindung eines Engineering-Tools über ein Ethernet-Netzwerk.
Grundprinzip der FDT-Kommunikation
Kommunikationskomponenten wie z.B. PC-Einsteckkarten, Modems oder Gateways werden in FDT über Comm- und Gateway-DTMs (Device Type Managers) abgebildet. Wie die Device-DTMs für Sensoren und Aktoren, beinhalten solche DTMs auch spezifische Konfigurationslogik und Benutzeroberflächen, z.B. für die Einstellung von Kommunikationsparametern wie Baudraten, Timeouts usw. Zusätzlich beinhalten solche DTMs sogenannte Communication-Channels. Diese machen die protokollspezifischen Dienste über entsprechende FDT-Softwareschnittstellen verfügbar. Die Comm- und Gateway-DTMs können, genau wie Device-DTMs, in einem Softwaretool verwendet werden und integrieren somit über \’Plug & Play\‘ die Netzwerk- oder Feldbus-Unterstützung in das Tool. Abbildung 2 verdeutlicht dieses Prinzip für die Verbindung eines Antriebes über CANopen. Für den Antrieb selbst wird der vom Hersteller gelieferte Device-DTM im Tool gestartet und der entsprechende Comm-DTM für das verwendete CANopen-Modem. Der Device-DTM nutzt die vom Comm-DTM bereitgestellten Softwareschnittstellen, um mit dem Antrieb zu kommunizieren. In diesem Beispiel sind es CANopen SDO Lese- und Schreibbefehle. Wie die spezifischen Dienste eines Protokolls in FDT abgebildet werden, legen sogenannte FDT-Annex-Spezifikationen fest. Bild 3 zeigt die Verwendung des CANopen-Comm-DTMs im Inbetriebnahme-Tool SoMove von Schneider Electric. Die Comm-DTM-Benutzeroberfläche wird in einem eigenen Dialog angezeigt, wenn der Anwender \’Edit Connection\‘ in der Hauptansicht auswählt. In diesem Dialog kann der Anwender dann die CANopen-Kommunikationsparameter einstellen. Ansonsten tritt der Comm-DTM in diesem Tool visuell nicht weiter in Erscheinung.
Geschachtelte Kommunikation
Durch den Einsatz von Gateway-DTMs funktioniert das FDT-Kommunikationsprinzip auch über mehrere Ebenen, wie die Abbildung 4 am Beispiel der Kommunikation mit einem IO-Link-Sensor über Profibus zeigt. Der Device-DTM nutzt die vom Gateway-DTM bereitgestellten Softwareschnittstellen, um mit dem Sensor zu kommunizieren. In diesem Beispiel sind das IO-Link-Index/Sub-Index-Lese- und Schreibbefehle. Der Gateway-DTM erzeugt die entsprechenden Profibus-Lese- und Schreibbefehle und sendet diese über den überlagerten Comm-DTM an den zugehörigen Feldbus-Koppler. Der Koppler wandelt die Befehle zurück nach IO-Link und sendet diese an den Sensor. Der Gateway-DTM wird vom Hersteller des Kopplers geliefert und kennt daher die Übersetzungslogik. Sie kann beliebig komplex sein und ist im Gateway-DTM genau gegenläufig wie im Koppler programmiert, z.B. kann aus einem IO-Link-Befehl im Gateway-DTM auch eine Serie von Profibus-Befehlen erzeugt werden, die im Koppler dann wieder zu einem einzelnen Befehl zusammengebaut und dann versendet werden.
Herstellerspezifische Protokolle
Kommen Softwaretool und Automatisierungskomponente vom selben Hersteller, dann kommen oft proprietäre Kommunikationsprotokolle zum Einsatz. Eine SPS wird üblicherweise nicht über einen Feldbus programmiert. Auch diese Art der Kommunikation kann mit FDT realisiert werden, wie in Bild 4 dargestellt ist. In diesem Fall kommen der Comm-DTM und der DTM für die SPS vom selben Hersteller. Die Befehle, die zwischen den beiden DTMs verwendet werden, sind herstellerspezifisch. Es gibt keine Annex-Spezifikation von der FDT Group und daher kann diese Kommunikation auch nicht von DTMs anderer Hersteller verwendet werden. Warum macht die Verwendung von FDT hier überhaupt Sinn, speziell für die Abbildung einer SPS? Die Antwort darauf lautet: Die DTMs können nicht nur im eigenen Softwaretool, sondern auch in anderen Tools verwendet werden. Für eine SPS bedeutet dies, dass der entsprechende DTM nicht nur im eigenen Programmiertool verwendet werden kann, sondern z.B. auch in einfachen Inbetriebnahme- oder Diagnose-Tools. Darin werden dann nur die vom DTM bereitgestellten Diagnose-Benutzeroberflächen oder die Gateway-Kommunikation zu den angeschlossenen Sensoren/Aktoren verwendet. Die eigentlich SPS-Programmierfunktion ist üblicherweise nicht in einem solchen DTM enthalten.
