CANopen Spezifikation für Aufzugsteuerungssysteme

Aus CANopen-Lift
Version vom 23. Oktober 2007, 15:53 Uhr von Joerg.Hellmich (Diskussion | Beiträge)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Zur Navigation springen Zur Suche springen

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 anwendungstranparenten Gateways. CANopen-Netzwerke sind begrenzt auf 127 Geräte in einem Netzwerk (aktuell verfügbare CAN-Transceiver können sogar auf weniger begrenzt sein). Gateways können diese Beschränkung überwinden. So kann der Knoten bis zu 254 virtuelle Geräte transparent an jeder Schnittstelle darstellen. Der Gebrauch von Gateways löst auch das Problem einer zu hohen Busbelastung.

Die virtuellen Gerätedefinitionen für den Hauptantrieb und die Schachtauflösung folgen dem typischen CANopen-Geräteprofil für Antriebssteuerungen (CiA 402) und Wertgeber (CiA 406). Abweichend von den Geräteprofilen werden im Applikationsprofil andere Objektverzeichniseinträge verwendet. Dies ist erforderlich, weil das Applikationsprofil ein einheitliches Objektverzeichnis in allen physikalischen Geräten verwendet. Zusätzlich ist jede PDO-Kommunikation vordiefiniert, anders als bei den Geräteprofilen. Das Applikationsprofil Lift definiert die PDO-Kommunikation zwischen den Geräten. Eine simple Master/Slave-Kommunikation ist nicht spezifiziert. Beispielsweise erhalten die Steuerung und der Hauptantrieb gleichberechtigt die Information der Schachtauflösung. Der Vorteil dieses Applikationsprofils für Konstrukteure von Aufzügen ist, dass sie sich nicht um die Details der Kommunikation kümmern müssen. Alles ist vordefiniert durch das Applikationsprofil. Falls jedoch ein anderer Ablauf gefordert ist, können die zu ändernde Funktion durch Systemkonstrukteure einfach konfiguriert werden. Die Spezifikation ist offen für kundenspezifische Ansprüche. Sehr hochwertige Werkzeuge, die die Besonderheiten des Applikationsprofils beinhalten, stehen für diese Zwecke zur Verfügung.