Ihr Wegweiser für
industrielle Netzwerke

Profibus-DPV1

Die in der Profibus-Norm IEC 61158 vorgesehenen Funktionserweiterungen zu Profibus-DP, kurz DPV1 genannt, ergänzen die zyklischen Kommunikationsfunktionen des Profibus-DP um die Möglichkeit der azyklischen Bedarfsdatenübertragung.

Azyklische Bedarfsdatenübertragung

Die Notwendigkeit für die azyklische Bedarfsdatenübertragung besteht für alle solche Slave-Geräte, die über viele verschiedene Parameter oder Optionen verfügen, die während des laufenden Betriebs verändert oder optimiert werden müssen. Typische Beispiele hierfür sind die Einstell- und Optimierungsparameter eines Antriebs wie Grenzwerte für Drehzahl oder Drehmoment, Betriebsart oder die Fehlerliste. Die azyklischen Dienste werden zeitlich parallel und zusätzlich zur zyklischen Prozessdatenübertragung mit niedriger Priorität abgewickelt. Hierdurch soll der zeitliche Einfluss auf die hochpriore zyklische Prozessdatenübertragung möglichst klein gehalten werden.

Schaubild

Was bei anderen Bussystemen wie Interbus (Parameterkanal) und DeviceNet (Explicit Messaging) schon sehr früh zum Standardfunktionsumfang gehörte, wurde beim Profibus erst mit der Funktionserweiterung DPV1 eingeführt.

Die DPV1-Funktionen bestehen im Wesentlichen aus den neuen Diensten „Read“ und „Write“ mit denen der Master auf beliebige Datenblöcke im Profibus-Slave lesend oder schreibend zugreifen kann. Zusätzlich wurden ein Initiate- und Abort-Dienst für die Verbindungsverwaltung, ein Data-Transport-Dienst zum Austausch großer Datenmengen und der Alarm- und Status-Dienst zur Übertragung von Alarmmeldungen neu definiert.

Zweiklassengesellschaft

Profibus-DPV1 unterscheidet zwei verschiedene Masterklassen. Als Klasse-1-Master (DPM1) wird das Automatisierungssystem (SPS) bezeichnet, das hauptsächlich die zyklische Prozessdatenverarbeitung mit Profibus-DP-Standardfunktionen durchführt, und die DPV1-Funktionen optional nutzen kann. Der neu hinzugekommene Klasse-2-Master (DPM2) ist typischerweise ein Engineeringtool, das ausschließlich azyklische Bedarfsdatenübertragung durchführt. Der Protokollablauf der DPV1 Funktionen auf dem Bus richtet sich danach, ob ein Klasse-1-Master oder ein Klasse-2-Master die Funktion initiiert.

Beispiel Read-Dienst

Anhand eines Read-Dienstes lässt sich der Ablauf einer DPV1-Kommunikation am einfachsten beschreiben. Zunächst überträgt der Master den Read-Funktionsaufruf an den Slave. Im Aufruf (Request) gibt der Master an, welche Daten (Parameter) er lesen möchte.

Schaubild

Da der Slave für die Bereitstellung der angeforderten Daten in der Regel einige Millisekunden Zeit benötigt, bestätigt er dem Master zunächst nur den Empfang des Dienstaufrufes ohne die angeforderten Daten. Der Master kann nun seine zyklische Prozessdatenverarbeitung fortsetzen und wird durch die lange Bearbeitungszeit beim Slave nicht unnötig verzögert. In den folgenden Buszyklen fragt der Master beim Slave durch sogenannte Poll-Telegramme immer wieder an, ob die angeforderten Daten nun bereitstehen. Benötigt der Slave noch mehr Zeit, sendet er als Antwort auf das Poll-Telegramm eine Kurzquittierung. Hat der Slave die angeforderten Daten aufbereitet, dann werden diese anstelle der Kurzquittierung direkt als Antwort auf das Poll-Telegramm übertragen. Durch die Aufteilung des Read-Dienstes in mehrere Interaktionen zwischen Master und Slave ergibt sich der Vorteil, dass die zyklische Prozessdatenverarbeitung nur wenig verzögert wird und auch Slaves mit geringer Rechenleistung die Möglichkeit zur Realisierung der DPV1-Kommunikationsfunktionen haben. Die Bedarfsdatenübertragung ist sowohl zwischen Klasse-1-Master und Slave als auch zwischen Klasse-2-Master und Slave möglich. Im Falle des Klasse-2-Masters muss vor der Ausführung des ersten Read- oder Write-Dienstes noch eine sogenannte C2-Verbindung über einen Initiate-Dienst aufgebaut werden.

Adressierung der Bedarfsdaten

Die Adressierung der Bedarfsdaten erfolgt modulbezogen über die Angaben "Slot", "Index" und "Length". Die Daten und Parameter werden als den Modulen eines Slaves zugehörig betrachtet und können mit Hilfe von Slot-Nummer und Index adressiert werden. Die Slot-Nummer adressiert dabei das Modul (beim Antrieb eine Achse) und der Index die einem Modul (Achse) zugeordneten Parameter. Jeder Datenblock kann dabei bis zu 240 Byte groß sein. Durch die zusätzliche Längenangabe im Read- bzw. Write-Request ist es möglich, nur Teile eines Parameters zu lesen bzw. zu schreiben. Wenn der Zugriff auf die Daten erfolgreich war, antwortet der Slave positiv andernfalls kann er mit einer negativen Response das aufgetretene Problem genau klassifizieren. Um die Zugriffe auf Parameter und Optionen herstellerübergreifend zu standardisieren, werden die Indexnummern und die Datentypen in den Profibus-Profilen festgelegt.