CANopen Spezifikation für Aufzugsteuerungssysteme

Quelle: CAN Newsletter Special Lift 2005 (www.can-cia.org/newsletter/) von Holger Zeltwanger, CAN in Automation (www.can-cia.org/lift)

Der CAN-Bus wird seit vielen Jahren auch von den großen Firmen der Aufzugsindustrie verwendet. Im Jahr 2002 haben sich mehrere mittelständische Firmen entschieden, sich einem auf einem höheren Layer genormten Protokoll, basierend auf CAN, zuzuwenden. Sie entschieden CANopen als Basis für diesen Standard zu nehmen. Das Ziel war eine Art von "plug and play"-Steuerungssystem für jede Standard-Aufzuganwedung. Das Ergebnis dieser Standardisierungsarbeit ist das CANopen-Applikationsprofil für Aufzugsteuerungssysteme CiA 417. Mit diesem Standard ist es möglich, eine Aufzuggruppe von acht Aufzügen mit bis zu 254 Etagen zu errichten.

Im Oktober 2003 wurden die ersten Prototypen dieser CANopen-Steuerungssysteme auf der Messe Interlift in Deutschland vorgeführt. Ein Prototyp eines Aufzugsystems befand sich auf dem Mitgliederstand der CiA, zusammengesetzt aus kompatiblen Komponenten verschiedener Hersteller. Zwischen der Aufzugsteuerung, der Türsteuerung, Tableaus, Displays und anderen Geräten fand die Kommunikation und der Datenaustausch über das CANopen-Netzwerk statt. Für die Aufzugbauer ist es ein großer Vorteil solche Standardprodukte zu verwenden, die mit dem CANopen-Lift Applikationsprofil versehen sind. Sie können einfach zusammengesteckt werden und das Steuerungssystem arbeitet mit nur einem minimalen Aufwand an Konfiguration.

Dies ist besonders interessant für alle kleineren und mittleren Hersteller von Aufzugsteuerungen. Sie sind nicht abhängig von speziellen Komponenten- oder Steuerungslieferanten. Eine vielfältige Auswahl ist ein wichtiger Kernpunkt, um ein Maximum an Flexibilität und funktionalen Optionen zu sichern.

CANopen-Grundlagen

CANopen ist eine Anzahl von Netzwerkprotokoll-Spezifikationen, die auf dem Controller Area Network (CAN) basieren, welches in den meisten modernen PKW vorhanden ist. Die CAN-Steuerungschips, die in großen Stückzahlen verkauft werden (ca. 300 Mio pro Jahr), sind zu angemessenen Preisen verfügbar. Deshalb haben mehrere der großen Aufzugbauer seit Mitte der 90er Jahre die CAN-basierenden Netzwerke genutzt.

Jedoch ist CAN nur ein »Link Layer Protokoll«. Bei der menschlichen Kommunikation würde man es einen Zeichensatz nennen, so wie das lateinische ABC. Um sich mit Menschen zu unterhalten braucht man aber eine gemeinsame Sprache, die aus Grammatik und Wörtern besteht. In der Netzwerktechnologie nennt man das »Application Layer« und »Application Profile«. Der »Application Layer« definiert, wie die Kommunikationsprotokolle angewendet werden (vergleichbar mit der Grammatik bei der Sprache) und das »Application Profile« definiert alle Parameter und Signale. Die CANopen-Protokolle sind in dem europäischen Standard EN 50325 spezifiziert.

Das CANopen-Lift-Profil

Die in der CiA organisierte CANopen Special Interest Group (SIG) Lift entwickelte die Spezifikation CiA 417, welche die Kommunikation im multiplen Aufzugsteuerungssystem beschreibt. Die auf der Interlift ausstellenden Firmen zeigten Prototypen von Tableaus, Antrieben, Türen, Steuerungen usw. mit dem entsprechenden CANopen-Lift-Standard. Die CANopen-Spezifikation ist für CiA-Mitglieder frei verfügbar und kann ohne Lizenzgebühren in eigenen Produkten verwendet werden. Die Spezifikation beschreibt die Standard-Kommunikation eines Steuerungssystems für bis zu acht Aufzügen mit jeweils bis zu je 254 Etagen. Die Standardkommunikation kann per Konfiguration verändert werden. Das Applikationsprofil Lift definiert sogenannte virtuelle Geräte. Ein physikalisches Gerät kann mehrere virtuelle Geräte enthalten. Jedoch kann ein virtuelles Gerät nicht in verschiedene physikalische CANopen-Geräte aufgeteilt werden. Die folgenden virtuellen Geräte sind bisher spezifiziert:

• Antriebssteuerung
• Rufsteuerung
• Displaysteuerung
• Kabinentürsteuerung
• Kabinenantrieb
• Schachtkopierung
• Kabinentür
• Lichtschranken
• Kabinentableaus
• Kabinendisplay
• Sensoren
• Lastmessgerät
• Ruftaster
• Tableau Anzeigen

Alle diese virtuellen Geräte enthalten verschieden zwingend erforderliche und optionale Funktionen. Zum Beispiel überträgt die Türsteuerung das Steuerwort an die Kabinentür mit dem Befehl, die Tür in vordefinierter Weise zu öffnen oder zu schließen. Die Tür antwortet mit seinem Statuswort über das CANopen-Netzwerk an das Steuersystem. Die Kabinentürsteuerung erhält dabei ebenso die Statusinformation der Lichtschranke oder des Lichtgitters über das Netzwerk.

Das Konzept des virtuellen Gerätes ermöglicht die Einführung von anwendertranparenten Gateways (Knoten). CANopen Netzwerke sind begrnezt auf 127 Geräten in einem Netzwerk (aktuell verfügbare CAN transceiver können sogar auf weniger begrenzt sein). Gateways können diese Beschränkung überwinden. Der Knoten kann bis zu 254 virtuelle Geräte einsetzen, auf jeder Seite eine Darstellung zu der anderen Schnittstelle. Der Gebrauch von Gateways löst auch das Problem von zu hoher Busbelastung.

Die virtuellen Gerätedefinitionen für Kabinenantriebe (Bewegungssteuerung) und Schachtauflösung (Wertgeber) folgen den typischen CANopen Geräteprofil für Bewegungssteuerungeen (CiA DSP 402) und Wertgebern (CiA DS 406). Jedoch verwenden sie in den lift control applications unterschiedliche/andere Objektwörterbuch Einträge. Das ist, weil das Application Profil genau das selbe Objektwöterbuch in allen physikalischen Geräten verwendet. Zusätzlich ist jede PDO-Kommunikation in anderer Weise vordefiniert als die typischen Geräteprofile. Das lift application profile definiert die PDO-Kommunikation zwischen den Geräten. Eine simple master/slave-Kommunikation ist nich spezifiziert. Beispielsweise erhalten die Türsteuerung und die Kabinensteuerung die Information der Schachtauflösung. Der Vorteil dieses Application Profils ist für Konstrukteure von Aufzugsystemen, dass sie sich nicht um die Details der Kommunikation kümmern müssen. Alles ist vordefiniert durch das lift application profile. Falls aber ein anderer Ablauf gefordert ist, können Systemkonstrukteure die zu ändernde Funktion konfigurieren. Die Spezifikation ist offen für diese Art der kundenspezifischen Ansprüche. Werkzeuge höchsten Niveaus, die die Details des lift application profile einfügen, stehen für dies Zwecke zur Verfügung.