FDT in der Fabrikautomation (Teil 2 von 8)

Datenaustausch über alle Netzwerkebenen und Protokolle

Einfaches Zusammenspiel von Software- und Automatisierungskomponenten
FDT bietet eine bewährte Architektur für den Datenaustausch zwischen Software- und Automatisierungskomponenten, unabhängig von den Netzwerkebenen oder Protokollen, über die kommuniziert wird. Auch Punkt-zu-Punkt-Verbindungen und herstellerspezifische Protokolle werden unterstützt. Dieser zweite Beitrag unserer Serie zu FDT beschreibt die Kommunikationsprinzipen und zeigt anhand von Beispielen, wie diese in der Praxis angewendet werden.

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.

Seiten: 1 2Auf einer Seite lesen

FDT Group
http://www.fdtgroup.org

Das könnte Sie auch Interessieren

Weitere Beiträge

Bild: SEW-Eurodrive GmbH & Co KG
Bild: SEW-Eurodrive GmbH & Co KG
Starterset ermöglicht flexible und hygienische Abfüllprozesse

Starterset ermöglicht flexible und hygienische Abfüllprozesse

Ständig wechselnde Konsumententrends, kleinere Chargen sowie Nachhaltigkeit sind wichtige Themen, welche auch die Getränkeindustrie vor Herausforderungen stellen. Ein flexibler und modularer Fertigungsprozess ist gefragt – beispielsweise beim Abfüllen von Getränken in Bechern. Mit dem Starterset 637 bietet SEW-Eurodrive für den aseptischen Bereich eine ganzheitliche, schnell einsetzbare und flexible Automatisierungslösung, die diesen Anforderungen begegnet – und zusätzlich die hohen hygienischen Standards der Getränkeindustrie erfüllt.

mehr lesen
Bild: ©TarikVision/stock.adobe.com
Bild: ©TarikVision/stock.adobe.com
Herausforderungen meistern, Chancen erkennen

Herausforderungen meistern, Chancen erkennen

Bis vor wenigen Jahren war das Thema Nachhaltigkeit in der Industrie vornehmlich für jene relevant, die sich auf diesem Gebiet als Vorreiter etablieren wollten. Mit der Vorlage des Green Deal durch die EU-Kommission im
Dezember 2019 sowie dem Beschluss eines Gesetzes auf Bundesebene Mitte 2021 hat sich dies geändert.
Unternehmen müssen zukünftig einen Nachweis über den CO2-Fußabdruck ihrer Produkte erbringen. Die
Herausforderungen dieser komplexen Aufgabe, über die IW Consult aus Köln im Auftrag des Vereins Eclass eine Studie erstellt hat, beschreibt Teil 1 der zweiteligen Artikelserie.

mehr lesen