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.
Feldbus Konfiguration – SPS-Magazin 9/2015
SPS Tool Integration – SPS-Magazin 10/2015
Feldbus & Geräte Diagnose – SPS-Magazin 11/2015 Im Zuge einer Smart-Factory-Potenzialanalyse für ihren Kunden KSB identifizierte die Managementberatung NEONEX Opti mierungschancen bei der Beschaffung der Lieferantendokumentation sowie der Erstellung von Unterlagen zur Qualitätsprüfung entlang der Supply-Chain. ‣ weiterlesen
Signifikante Ressourceneinsparung bei Pumpenhersteller KSB
NEONEX, Fabasoft Approve & KSB: „Win-win-win-Situation“ durch starke Partnerschaft
Signifikante Ressourceneinsparung bei Pumpenhersteller KSB
Deployment & Installation – SPS-Magazin 12/2015
OPC UA & AutomationML – SPS-Magazin 01/2016
Mobile, Cloud & IoT – SPS-Magazin 02/2016
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.
