Die Integration in Sercos

Bild 1: Protokollablauf der azyklischen Übertragung: Dargestellt ist ein fehlerfreier Ablauf einer Anfrage über die Sercos-Parameter bis zum Sub-Bus-Teilnehmer und zurück.

© Bosch Rexroth

Die Spezifikation der zyklischen Übertragung beinhaltet zum einen das ­Mapping der zyklischen Daten, wobei die Daten der einzelnen IO-Link-Devices transparent in die zyklischen Daten von Sercos gemappt werden. Dabei wird genau vorgegeben, wie die Daten mit passendem Wort-Alignment übertragen werden. Zum anderen kann mittels des ‚process data qualifier‘ die ‚Gültigkeit der Daten‘ signalisiert beziehungsweise von der überlagerten Steuerung vorgegeben werden. Des Weiteren ist das Verhalten bei Kommunikationsfehlern spezifiziert, wenn etwa ein Sub-Bus-Teilnehmer ausfällt und nicht mehr an der IO-Link-Kommunikation teilnimmt. Hierauf lässt sich mittels Ersatzwerten in den zyklischen ­Daten zur überlagerten Steuerung reagieren. Weiterhin ist in Sercos die ­Reaktion zum IO-Link-Device im Falle eines Kommunikationsausfalls im Sercos einstellbar. Die Übertragung azyk­lischer Daten bei IO-Link – der so genannte ‚On-Request Data Exchange mittels ISDU-Übertragung‘ – ist mit einem einfachen Sub-Bus-Protokoll in Sercos abgebildet. Hierdurch kann auf jeden IO-Link-Parameter – beschrieben durch Index und Subindex – zugegriffen werden. In diesem Fall wird auf eine Zwei-Ebenen-Transportschicht aufgebaut: Schicht 1 ist ein Sub-Bus-unabhängiger Transport, die Schicht 2 der Sub-Bus-abhängige Protokoll-Inhalt. Die Abwicklung des Sub-Bus-unabhängigen Transportanteils erfolgt durch ein Tunnelprotokoll, das auf drei Sercos-Parametern (IDNs) aufsetzt. Parameter-Anfragen laufen in Form eines Request/Confirmation-Verfahrens ab. Bild 1 verdeutlicht dies anhand einer fehlerfrei ablaufenden Anfrage. Daneben sind die entsprechenden Fehler­behandlungen, Anfrage-Abbrüche und Timeout-Behandlungen im Sub-Bus-Tunnelprotokoll spezifiziert.

Bild 2: Aufbau des Sub-Bus-Tunnel-Telegramms: Hier kommt das bei Ethernet-­Protokollen bewährte 'Zwiebelschalen'-Modell zur Anwendung, bei dem Protokollschichten ineinander gekapselt werden.

© Bosch Rexroth

Bild 2 zeigt den Aufbau eines Anfrage-Telegramms (Sub-Bus Tunnel PDU). Hier ist ersichtlich, dass mit einem Protokoll-Ablauf sowohl Einzel-, als auch Summenanfragen möglich sind (durch mehrere Command PDUs). Letztere sind sogar an verschiedene Teilnehmer adressierbar, so dass sich beispielsweise alle elektronischen Typenschilder ‚in einem Rutsch‘ auslesen lassen. Durch Summenanfragen an einen einzelnen Teilnehmer kann zudem die gesamte Parametrierung des Teilnehmers aus einem SPS-Programm der überlagerten Steuerung heraus mit einem Vorgang optimiert abgewickelt werden.

Der Ablauf einer Parameterübertragung wird durch Telegramme (Command PDUs) abgebildet. Dieser ver­allgemeinerte Sub-Bus-Tunnel gilt grundsätzlich auch für weitere zu spezifizierende Tunnelprotokolle, wie zum Beispiel AS-i, CAN oder auch Profibus, und ermöglicht dadurch gleichartige Implementierungen auf den Steuerungen. Die Schicht 1 beinhaltet somit die Telegrammstrukturen bis zur Command SDU (Request/Confirmation/Error). Der IO-Link-spezifische Transportanteil (Schicht 2 der Integration) setzt auf der Ebene Command SDU auf. Beispielhaft ist ein Anforderungstelegramm in Bild 3 dargestellt.

Bild 3: Device Command Request SDU: In den Feldern 'Index' und 'Subindex' wird der zu lesende/schreibende IO-Link-Parameter ausgewählt.

© Bosch Rexroth

Innerhalb der jeweiligen Data-Object-Datenfelder der IO-Link-Devices werden die Parameterdateninhalte zum/vom Gerät übertragen. Die Meldung von Fehlern bezüglich der Datenübertragung sowohl des IO-Link-Masters, als auch der IO-Link-Devices erfolgt über entsprechende Error-Code-Datenfelder. Zur Geräte-Identifikation werden beim Anlauf die Identifikations­daten aller Devices ausgelesen und in einem eigenen Sercos-Parameter abgelegt. Dies beinhaltet die Werte der ­VendorID, der DeviceID und der FunctionID. Hierdurch kann eine einfache Überprüfung beispielsweise durch ein SPS-Programm erfolgen.

Die Masterkonfiguration der IO-Link-Ports – die so genannte Portkonfiguration – entspricht der eines Feldbusses. IO-Link besitzt eine sehr schlanke beziehungsweise einfach gehaltene Portkonfiguration, zudem werden die meisten Einstellwerte durch die Sercos-Anlaufparametrierung erledigt. Jeder Port lässt sich auch zur Laufzeit umkonfigurieren, hierzu dienen entsprechende Telegramme. Für jeden Port ist weiterhin eine eigene Portdiagnose auslesbar, wie zum Beispiel die Port-Betriebsart, der Diagnosestatus mit Statuscode, die Geräte-Identifikationsdaten (VendorID, DeviceID,…), Data Storage Fehlercodes, die IO-Link-Revision und vieles mehr. Nicht zuletzt ist eine Gerätediagnose über die bekannten Sercos-Diagnosemechanismen vorhanden (auslesbare Diagnose, Diagnosespeicher, Fehler löschen etc.). Hierbei werden die bei IO-Link spezifizierten Diagnose-Codes, wie zum Beispiel Fehlernummern und Diagnoseklassen, 1:1 in Sercos abgebildet. Dadurch ergibt sich automatisch die Erweiterung der Diagnose für den Fall, dass bei IO-Link neue Diagnosecodes spezifiziert werden.

Die in IO-Link vorhandenen Funktionen für den Gerätetausch sind ebenfalls abgebildet: Der Data-Storage-Mechanismus der Devices erlaubt es, alle Parameterdaten eines Gerätes automatisiert im IO-Link-Gateway zu sichern. Fällt eine Komponente aus, so muss der Anwender das Gerät lediglich durch einen baugleichen Slave ersetzen. Das Gateway erkennt den neuen Teilnehmer automatisch und führt die Parametrierung beim folgenden Hochlauf aus, wobei keine erneute Parametrierung des Slaves notwendig ist. Auch bei einem Ausfall des Gateways ist ein Gerätetausch ohne Neukonfiguration möglich: Der Sercos-Master kann die Konfiguration des Gateways sichern, den Gerätetausch automatisiert erkennen und eigenständig die Neuparametrierung durchführen.

Funktionsbausteine für die SPS

Im Steuerungssystem MLC von Bosch Rexroth etwa sind mit Hilfe von Funktionsbausteinen (FB) unter anderem folgende SPS-Funktionen implementiert:

• azyklischer Parameterzugriff (IOL_CALL)
• Geräte-Identifikation
• Device-Diagnose, Port-Diagnose
• Kommando-Abarbeitung
• Port-Konfiguration
• Backup/Restore eines IO-Link-Device

Den grundlegenden Basis-Funktionsbaustein zum Lesen/Schreiben eines IO-Link-Parameters zeigt Bild 5. Dieser FB bedient das bereits erwähnte Tunnelprotokoll für die azyklische Übertragung. Mit Hilfe des Backup-FBs können alle Parameter eines IO-Link-Devices aus­gelesen und auf der SPS gespeichert werden, der Restore-FB dient für das ­Beschreiben der vorher gesicherten Parameter. Diese FBs sind beispielsweise dann wertvoll, wenn aus einem SPS-Inbetriebnahmeprogramm einer Serienmaschine automatisch alle IO-Link-Devices einer Maschine/Anlage nach dem ersten Einschalten erstmalig parametriert werden sollen. Das heißt, der Anwender erspart sich das aufwendige manuelle Laden der Parameter in die Geräte mittels einer Inbetriebnahme-Oberfläche beziehungsweise eines separaten Programms zum Beispiel über einen USB-Adapter. Der Diagnose-FB schließlich liest die Diagnose-Information aus einem Device aus, der Anwender muss folglich nur noch die Statusinformation (DeviceStatus/StateDetails) auswerten.

In Summe sind rund 15 Funktionsbausteine rund um die Integration von IO-Link in Sercos implementiert.

Beispiel Positionierantrieb

Am Beispiel des Positionierantriebes PSE3 von Halstrup-Walcher, der sowohl mit Sercos als auch mit IO-Link verfügbar ist, lässt sich der Vorteil der Sub-Bus-Intergration veranschaulichen. Der Antrieb mit Sercos benötigt drei M12-Stecker, bei IO-Link ist es lediglich ein M12-Stecker. Dies vereinfacht die Montage/Inbetriebnahme. Aufgrund der geringeren Anzahl notwendiger Stecker baut die Variante mit IO-Link 13 % kürzer – sprich 100 mm gegenüber 115 mm.

Bei der Performance punktet grundsätzlich Sercos: Sercos erlaubt Zykluszeiten von 1 ms gegenüber 8 ms bei IO-Link. Dies bedeutet, dass bei Sollwertvorgabe oder Auffrischraten von Ist- beziehungsweise Status-Werten Sercos zwar schneller ist; in Positionieranwendungen, für die der PSE3 geschaffen ist, wird sich dies in der Praxis jedoch selten auswirken.

Abschließend lässt sich festhalten: Die Spezifikation der Integration von Sub-Bussen in Sercos bietet sehr komfortable Möglichkeiten. Die Zweistufigkeit der Spezifikation erlaubt es, neben IO-Link auf einfache Weise andere Sub-Busse in gleicher Weise zu integrieren; für den Anwender ändert sich auf der Protokollschicht nur wenig. Die Unterstützung in Steuerungssystemen profitiert von dieser Architektur, da große Programmteile bei weiteren Sub-Bussen wiederverwendbar sind. Die Basis hierfür sind Standard-Sercos-Mechanismen, die heute jede Sercos-Steuerung beherrscht. Erste Implementierungen sind vorhanden und werden in Protoyp-Anwendungen bereits angewandt.

Autor:
Dr. Stephan Schultze ist bei Bosch Rexroth in der Entwicklung Automationssysteme Motion Logic Control tätig.