CANopen Spezifikation für Aufzugsteuerungssysteme

Aus CANopen-Lift
Version vom 2. September 2007, 17:20 Uhr von Joerg.Hellmich (Diskussion | Beiträge) (Die Seite wurde neu angelegt: ''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 viele...)
(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 von den großen Aufzugsbaufirmen in Aufzügen verwendet. In Jahr 2002 haben sich mehrere mittelständische Firmen entschieden, sich einem auf höherer Ebene bewegenden 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 application profile für Aufzugsteuerungssysteme CiA DSP 417. Mit dem Einsatz dieses Standards ist es möglich, eine Aufzuganwendung mit maximal 254 Etagen und acht parallelen Aufzügen einzubauen.

In Oktober 2003 wurden die ersten Prototypen der CANopen Steuerungssysteme auf der Messe Interlift in Deutschland vorgeführt. Ein Prototyp eines Aufzugsystems war auf dem Mitgliederstand der CiA, installiert aus Komponenten verschiedener Hersteller. Die Aufzugsteuerung, die Türsteuerung, Tableaus, Displays und andere Ausstattung: Kommunikation und Datenaustausch waren alle über das CANopen Netzwerk integriert. Für die Konstrukteure des Aufzugssysteme ist es ein großer Vorteil Standardprodukte zu kaufen, die mit der CANopen lift application profile Spezifikation versehen sind, sie zusammen zu stecken, und das Steuerungssystem arbeitet mit nur einem minimalen Aufwand zum Konfigurieren.

Dieses 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.

[bearbeiten] CANopen basics

CANopen ist eine Menge 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 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.

[bearbeiten] Das CANopen Lift profile

CiA's CANopen Special Interest Group (SIG) Lift entwickelte die DSP 417 Spezifikation, die 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 eingefügt werden. Die Spezifikation beschreibt die Standard Kommunikation eines Steuerungssystems für bis zu acht Aufzügen mit bis zu je 254 Etagen. Die Standardkommunikation kann per Konfiguration verändert werden. Das lift application profile definier 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 übertragen werden. Die folgenden virtuellen Geräte sind spezifiziert:

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

Alle diese virtuellen Einrichtungen enthalten zwingende Funktionen so wie optionale Wünsche. 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. Und die Tür antwortet mit seinem Statuswort über das CANopen Netzwerk an das Steuersystem. Die Kabinentürsteuerung erhält ebenso die Statusinformation der Lichtschranke ü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.