CANopen-Gateway zu AS-Interface

Das international genormte CANopen-Protokoll (EN50325-4) ist ein auf dem Controller Area Network (CAN) basierendes Kommunikationsprofil, das von CAN in Automation weiterentwickelt und gewartet wird. CAN­open wird wegen seiner vielen vorhandenen Freiheitsgrade bereits seit Jahren erfolgreich in verschiedensten Anwendungen eingesetzt, z.B. in der industriellen Automatisierung, in der Medizintechnik, als eingebettetes Netzwerk in Zügen, Schiffen, Flugzeugen, oder auch in Automaten. Eine große Auswahl an Software und Konfigurationswerkzeugen erleichtert die Implementierung des Protokolls. Ein CANopen-Gerät kann in drei folgende logische Teile aufgeteilt werden: die Kommunikationseinheit, das Objektverzeichnis und die Applikationseinheit. Die Kommunikationseinheit stellt alle Mechanismen und Kommunikationsobjekte zur Verfügung, um Daten entsprechend der CAN­open-Spezifikation über CAN zu transportieren. Hier erfolgen der Zugriff auf den CAN-Controller und auch die Abwicklung des CANopen-Protokolls. Die wichtigsten Bestandteile der Kommunikationseinheit sind Prozessdatenobjekte (PDOs: Übertragung von Echtzeitdaten bzw. Prozessdaten), Servicedatenobjekte (SDOs: Lese- und Schreibzugriffe auf Objektverzeichnis-Einträge) und die Zustandsmaschine (NMT: Steuerung des Gerätestatus, Überwachung der Teilnehmer) der Kommunikation. Die Applikationseinheit eines CANopen-Geräts beschreibt die eigentliche Funktion des Geräts in Bezug auf seine Prozessumgebung. Im Objektverzeichnis sind alle Objekte eines CAN­open-Geräts in standardisierter Weise beschrieben. Das Objektverzeichnis ist eine Sammlung aller Datenstrukturen, die einen Einfluss auf die Anwendung, die Kommunikation sowie die Zustandsmaschine eines Geräts haben. Alle Einträge sind klar durch einen Index (16Bit) und Subindex (8Bit) definiert und können gezielt gelesen oder geschrieben werden. Es beschreibt die komplette Funktionalität eines CAN­open-Teilnehmers mit Hilfe von Objekten und bildet die Schnittstelle zwischen der Kommunikations- und der Applikationseinheit. Das Profil CiA 446 spezifiziert die ­CANopen-Schnittstelle eines Gateways zu AS-Interface. AS-Interface ist ein international genormtes serielles Bussystem. Es ist besonders für die Kommunikation zwischen einer industriellen Steuerung und den einfachen Aktoren und Sensoren geeignet. Daher ist AS-Interface ein Single-Master-System, d.h. ein Master fragt zyklisch alle projektierten Slaves ab und tauscht mit ihnen die Ein- und Ausgangsdaten aus. Ein Telegramm besteht dabei aus 4Bit Nutzdaten. Der AS-Interface-Master kommuniziert mit den Teilnehmern mit einer konstanten Buszykluszeit. Jedem AS-Interface-Slave wird durch ein Programmiergerät eine eindeutige Adresse zugewiesen. Es können maximal 62 Teilnehmer an einen AS-Interface-Kreis angeschlossen werden. An ein logisches AS-Interface-Gateway können zwei AS-Interface-Master angeschlossen werden (zwei AS-Interface-Kreise mit insgesamt 124 Teilnehmern). Ein AS-Interface-Kreis (62 Teilnehmer) wird wegen der historischen Entwicklung des Busses in 31 A-Slaves und 31 B-Slaves aufgeteilt. CANopen-Gateway muss auf der AS-Interface-Seite die Master-Funktionalität implementieren. Im Gerätetyp-Parameter (Objekt 1000h) im Objektverzeichnis wird außer der Geräte-Profil-Nummer angegeben, welches AS-Interface-Master-Profil und welche spezifischen Funktionen (specific functions) implementiert sind (Bild 1). Zu den spezifischen Funktionen zählen beispielsweise AS-I-Doppelmaster. Dabei können die Einzel-Master mit dem Profil M0, M1 und M2 mit bis zu 31 Slaves (A-Slaves) in einem einzelnen AS-Interface-Kreis kommunizieren. Die Einzel-Mas­ter mit dem Profil M3 und M4 können bis zu 62 Slaves (A- und B-Slaves) unterstützen. Die Doppel-Master mit dem Profil M0, M1 und M2 unterstützen zwei AS-Interface-Kreise mit bis zu 31 Slaves (A-Slaves). Die Doppel-Master mit dem Profil M3 und M4 können bis zu 62 Slaves (A- und B-Slaves) in zwei AS-Interface-Kreisen unterstützen. Für die schnelle Kommunikation des Masters mit den AS-I-Slaves werden vordefinierte Prozessdatenobjekte (PDOs) verwendet. Welche PDOs mit digitalen Ein-/Ausgängen von welchem Master unterstützt werden und wie sie zusammengesetzt werden, ist aus Bild 3 und Bild 4 ersichtlich. Gateways nach CiA 446 können nur bedingt weitere \’logische\‘ CAN­open-Geräte implementieren, da sie bereits im ­ersten \’logischen\‘ Gerät die für die nächsten \’logischen\‘ Geräte reservierten PDOs optional verwenden. AS-Interface-Slaves können auch analoge Ein- oder Ausgänge unterstützen. Ein analoger Ein- oder Ausgang hat vier Kanäle mit einer Auflösung von jeweils 16Bit. Um analoge E/A-Signale in PDOs zu übertragen, wird für jedes Ein- oder Ausgangssignal ein separates TPDO beziehungsweise RPDO verwendet. So sind TPDO 9 bis TPDO 132 für alle analogen Eingangssignale und RPDO 9 bis RPDO 132 für alle analogen Ausgangssignale der beiden AS-Interface-Master optional implementiert. Im Objektverzeichnis sind Prozessdaten und Konfigurationsparameter für zwei AS-Interface-Master spezifiziert. Mittels der Objekte 619Eh und 619Fh (AS-I-Master-Flags für Kreis 1 und 2) kann man den aktuellen Status und die Fehlerzustände der beiden Master mitverfolgen. Der Status der angeschlossenen Slaves ist per SDO lesbarer Lis­ten dokumentiert: – List of active slaves (LAS): aktive AS-I-Slaves – List of detected slaves (LDS): angeschlossene AS-I-Slaves – List of peripheral faults (LPF): AS-I- Slaves mit Fehlern – List of projected slaves (LPS): Projektierte AS-I-Slaves Für jede Liste sind jeweils zwei Array-Objekte (eines für die Slaves vom ersten Kreis und ein zweites für die Slaves im zweiten Kreis) angelegt, wobei der Status von jedem Slave durch ein Bit repräsentiert wird. Mittels SDO-Zugriffe auf weitere Objekte kann die aktuelle Konfiguration der Slaves ausgelesen werden und die permanente Konfiguration gesetzt werden. Mit dem Master-Steuerwort (Index 61B0h und 61B1h für 1 bzw. Kreis 2) kann man den Master in unterschiedlichen Modi (Konfigurations-, gesicherter Laufzeit, Online- oder Offline-Modus) betreiben, die aktuelle Konfiguration speichern, automatische Adressierung und Datenaustausch erlauben. Die Mas­ter-Status-Bytes zeigen in den Objekten 61B2h und 61B3h an, ob die Master-Befehle richtig ausgeführt wurden. Um Daten azyklisch anzufragen, kann man in zwei Objekten (Read acyclic request) für die Kreise 1 und 2, den Slave und die Art der angefragten Daten spezifizieren. Die Antwort auf diese Anfrage, also die angefragten Daten, werden dann in zwei Objekte (Read acyclic response) für Kreis 1 und 2 geschrieben und sind von dort über SDO-Services lesbar. Die \’Read acyclic response\‘-Objekte besitzen die in Bild 2 dargestellte Struktur. Im Octet 1 (ein 8Bit-Wert) wird ein bestimmter Slave angegeben, nach dessen Daten angefragt wird. Der Inhalt der Daten wird im Feld \’Content type\‘ spezifiziert. Im Feld \’Number\‘ wird angegeben, wieviele Bytes des Parameter-Feldes gültig sind. Die angefragten Daten werden dann im Parameter-Feld zurückgegeben. Wie für die Lese-Funktion sind auch für die Schreib-Funktion zwei Objekte (je für einen Kreis) definiert. Mittels dieser Objekte (Write acyclic request), die ebenfalls die in Bild 2 dargestellte Struktur haben, kann man in den ausgewählten Slave einen Parameter schreiben. Ob dieser Parameter tatsächlich im Slave korrekt angekommen ist, kann man in den Objekten \’Write acyclic response\‘ verifizieren. Es handelt sich auf Anwendungsebene um bestätigte Lese- bzw. Schreibfunktionen.