Umsetzung für PROFIBUS DP
PROFIBUS DP erlaubt Slaves unterschiedlicher Komplexität, wie einfache Ein- und Ausgabegeräte, Antriebe, programmierbare Geräte, etc. Am PROFIBUS DP unterscheiden sich diese Geräte jedoch nicht, jedes Gerät stellt seine Produktivdaten – ob diese nun direkt aus dem Prozess stammen oder ein Ergebnis einer (Vor)Verarbeitung darstellen – über seine EA-Schnittstelle zur Verfügung. Der Proxyansatz trägt für all diese Geräte.
Es gibt jedoch auch DP-Slaves, die aufgrund ihrer Komplexität Treiberbausteine auf dem zugehörigen Master erfordern. Dann wird dieser Treiberbaustein komponentisiert, um ihn im Rahmen von PROFnet einsetzen zu können.
Der DP-Slave wird über Proxyobjekte auf dessen DP-Master im PROFINET Sinne angesprochen. Diese Proxyobjekte integrieren den DP-Slave in die PROFINET-Welt. Am PROFIBUS DP läuft weiterhin das PROFIBUS DP Protokoll ohne jegliche Erweiterungen oder Änderungen.
Dies erlaubt eine homogene Einbindung der Slaves in PROFINET sowohl im Sinne der Runtime-Kommunikation als auch des Engineerings. Es ist einerseits möglich, jeden beliebigen DP-Slave in PROFINET einzubinden ohne Aufwand für dessen Hersteller hinsichtlich Softwareerweiterungen oder Hardwareumbau. Andererseits werden die spezifischen Eigenschaften von PROFIBUS DP, insbesondere dessen Echtzeitfähigkeit beibehalten.
Ein wesentlicher Vorteil der Modellierung besteht in der technologischen Ausbildung der DP Schnittstelle, d.h. der Eingangs- und Ausgangsdaten des DP-Slaves. Die technologische Ausbildung der Schnittstelle bietet Symbolik und Typsicherheit im Zugriff auf dessen Daten. Bei direkter Verwendung des PROFIBUS DP existiert nur eine flache Bytesicht auf die Schnittstelle, für die Verwendung dieser Schnittstelle ist Austausch und vor allem Lesen von Dokumentation erforderlich. Diese technologische Ausbildung wird durch die Komponentisierung des DP-Slave erreicht.
Komponentisierung bedeutet in diesem Kontext, aus einem DP-Slave eine im PROFINET Engineeringsystem einsetzbare Komponente zu erzeugen. Die konkrete Komponente wird dabei mittels XML (eXtensible Markup Language) beschrieben.
Für einen DP-Slave erfolgt dies durch Interpretation der Gerätebeschreibung (GSD-Datei) des Slaves in Zusammenarbeit mit dem Anwender. Der Anwender bildet die technologische Sicht auf den DP-Slave, d.h. versieht die einzelnen Elemente der Schnittstelle mit Namen und Datentyp.