Interoperabilität ist gefordert

Dr. Thomas Bangemann

Die Integration von Identsystemen und Barcodelesern in Anwendungen erfolgt heute auf proprietäre Weise. Dafür werden die unterschiedlichsten Schnittstellen und Protokolle eingesetzt. Im Rahmen der IEC wird derzeit an der Ausarbeitung von Standards, zum Beispiel für die Luftschnittstelle, für Dateiformate und das Handling von Dateien, gearbeitet. Darüber hinaus ist die Einigung auf ein gemeinsames Kommunikationsprotokoll notwendig. Der Einsatz eines einheitlichen Kommunikationsprotokolls allein reicht jedoch nicht aus, um die Interoperabilität zwischen den Systemkomponenten zu gewährleisten. Optionale Eigenschaften sind einheitlich einzusetzen und Absprachen bezüglich Syntax und Semantik zu treffen. Auf applikativer Ebene werden diese Festlegungen in Profilen getroffen. Profibus ist ein industrielles Kommunikationssystem, das mit seinen in Abbildung 1 dargestellten Protokoll- und Profilvarianten den Anforderungen an den Einsatz in unterschiedlichen Branchen gerecht wird. Um auch die Integration von Identsystemen und Barcodelesern in die am Markt weit verbreitete Profibus-Technologie zu gewährleisten, wurde von der Profibus Nutzerorganisation (PNO) der Arbeitskreis „Identification Systems“ ins Leben gerufen.

Aktuelle Basis für die effektive Profibus-Kommunikation ist das Profiubus-DP-Protokoll. Profibus-DP wird meist für die Kommunikation zwischen einem zentralen Gerät (Mono-Master-System) und mehreren verteilten Ein-/Ausgabeeinheiten verwendet. Das bedeutet, dass ein Master-Gerät über den Bus mit den verteilten Peripheriegeräten vernetzt ist. Die in klassischer Architektur aufwändige Parallelverkabelung zwischen der SPS und den Geräten der dezentralen Peripherie wird durch eine serielle Busleitung ersetzt, über die ein zyklischer Prozessdatenaustausch erfolgt.

Profibus-DP ist der Überbegriff für die drei Protokollvarianten DP-V0, DP-V1 und DP-V2. Zunächst wurde DP-V0 für den rein zyklischen Datenverkehr entwickelt. Das rein zyklische DP-Protokoll (DP-V0) ist jedoch nur bedingt für Parametrierzwecke geeignet, da die Kodierung von Parameterinformationen in Nutzdatentelegrammen zu einem hohen Telegramm-Overhead führen würde. Ein Ausweg aus dieser Situation wurde durch die Entwicklung der Version DP-V1 realisiert. Mit DP-V1 ist es möglich, parallel zum zyklischen Prozessdatenaustausch azyklisch Telegramme zum gleichen oder einem anderen Master zu senden. DP-V2 ist eine Weiterentwicklung, die zum Beispiel Slave-Querverkehr, Isochron-Mode oder Download unterstützt. Darüber hinaus werden in so genannten Profilen Vereinbarungen zwischen Herstellern für Funktionalitäten oberhalb der Schicht 7 getroffen. Profile sind Festlegungen, die Feldgerätefunktionen, verbunden mit ihren Variablen und Parametern so beschreiben, dass auf diese Hersteller unabhängig über den Feldbus zugegriffen werden kann. Sie definieren weiterhin das zu nutzende Subset des Kommunikationsprotokolls. Ein solches Anwendungsprofil ist das Profil „Identification Systems“. Hinsichtlich der Rolle der miteinander kommunizierenden Geräte unterscheidet Profibus Master- und Slavestationen. Die Eigenschaft eines Gerätes zur Ausübung einer Master- oder Slavefunktion erhält ein Gerät durch Implementierung der jeweiligen Protokollteile (Abb. 2).

Interoperabilität und einfache Integrierbarkeit in Steuerungssysteme sind die grundlegenden Ziele der Profildefinition. Voraussetzung für die Interoperabilität der Systeme sind Absprachen über Kommunikationsgeschehen und Parameter. Die Einbindung in ein Steuerungsprogramm hängt in erster Linie von der Wahl der Programmiersprache ab.

Heute wird IEC 61131-3 als Programmiersprache für SPS’en genutzt. Bereits frühzeitig zeigten die Mitglieder des Arbeitskreises Interesse an einem standardisierten Funktionsbaustein, der auf die Profibus-Plattform DP-V1 aufsetzt und der auf unterschiedliche Steuerungen portierbar ist (Abb. 3). Es wurde beschlossen, einen Baustein (Arbeitstitel: Proxy Ident Baustein – PIB) zu definieren, der entsprechend IEC 61131-3 spezifiziert wird, eine definierte Schnittstelle zu den im Rahmen der PNO-Arbeiten definierten Kommunikations-Funktionsbausteinen (Comm-FB’s) sowie eine definierte Schnittstelle zur Anwendung hat. Dieser Baustein entkoppelt die Protokoll spezifischen Eigenschaften des Datentransfers von der Anwendung. Der Anwendungsprogrammierer kann sich somit auf die automatisierungstechnische Aufgabenstellung konzentrieren und muss kein Profibus-Spezialist sein.

Während bei anderen Profilen die Definition der Dateninhalte im Vordergrund steht, werden die Übertragung der Blockdaten (Dateien oder Teile von Dateien) sowie die Dateistruktur zunächst außer Acht gelassen. Die im Profil zu spezifizierenden Mittel beziehen sich in der ersten Profilversion auf Transportmechanismen für Datencontainer. Nach Übertragung und Zusammensetzung der einzelnen Datenblöcke wird der Datencontainer vom PIB an die Anwendung (das den PIB aufrufende Programm) übergeben. Es ist Aufgabe der Anwendung, diese Daten zu interpretieren. Nach Abschluss der IEC-Arbeiten kann in einer neuen Profilversion auf ISO/IEC 15692 Bezug genommen werden. So wird die Definition eines zweiten Standards parallel zu ISO/IEC 15692 vermieden. Bezüglich der Datenbereitstellung werden für den PIB folgende Funktionalitäten spezifiziert:

• Zerlegen und Zusammensetzen von Datenblöcken

• Flusskontrolle für die sequenzielle Übertragung der zerlegten Datenblöcke, Synchronisation nach einem Fehlerfall

• Behandlung von Übertragungsfehlern auf Anwendungsebene

• Identifikation des Ident-Kanals

Die Anforderungen von Transpondern an Automatisierungssysteme sind aus Sicht des Kommunikationsgeschehens eher untypisch. Die markierten Objekte werden von den Schreib-/Lesestationen (Interrogatoren) in relativ großen Zeitabständen (Sekunden bis Minuten) bearbeitet. Die dann zu verarbeitenden Daten können bis zu 32 kByte umfassen. Zur Gewährleistung einer großen Performance des Gesamtsystems erfordert diese Eigenschaft besondere Sorgfalt bei der Koordination der zyklischen und azyklischen Kommunikation. Demnach wird im zyklischen Betrieb lediglich ein kurzes Status- oder Quittungstelegramm (16 Bit) ausgetauscht, das im Wesentlichen über den Bearbeitungszustand eines Befehls im Interrogator berichtet. Die Befehle an sich sowie Befehlsantworten und Daten werden azyklisch in die Steuerung übertragen. Das Schreiben von Daten erfolgt entsprechend. Durch die zyklische Statusübertragung werden azyklische Dienste nur dann aufgerufen, wenn auch tatsächlich Daten vorliegen. Bei der Parametrierung der Buszyklen ist zu gewährleisten, dass in jedem Buszyklus eine Reservezeit für azyklischen Datenverkehr verbleibt. Durch diese Vorgehensweise ergeben sich eine Reihe von Vorteilen. Es erfolgt eine geringe Belastung des zyklischen Datenverkehrs (schnelle E/A-Baugruppen behalten ihre Reaktionszeiten, kurze Profibus-Zykluszeiten auch bei vielen Profibus-Slaves), optimaler Datendurchsatz und unnötiger zyklischer Datenverkehr wird vermieden.

Die hier beschriebenen Funktionen basieren auf der aktuellen Arbeitsversion des Ident-Profils. Es ist geplant, noch in diesem Jahr eine erste „Draft Version“ des Profildokumentes zu veröffentlichen. Das Profildokument wird dann als Profibus-Guideline „Profibus Ident Proxy Function Blocks acc. to IEC 61131-3“ (Order-No. 3.142) bei der PNO erscheinen.

Die Aktivitäten zur Profildefinition werden durch die Forderung nach standardisierten Anwendungsfunktionen und einheitlicher Handhabung auf einem bestimmten Anwendungsgebiet initiiert. Die Spezifikationen werden dann durch Firmenvertreter erarbeitet, die Experten für die jeweilige Aufgabenstellung sind.