Aufzüge werden immer komplexer. Immer mehr elektronische Geräte werden in Aufzügen verbaut, um die steigenden Ansprüche an Funktionalität, aktuellem Normenwerk und Sicherheitsanforderungen erfüllen zu können.
In elektronischen Geräten arbeiten Embedded Mikroprozessoren, die in Abhängigkeit ihrer Eingangssignale oder anhand von Sensordaten, Ausgangssignale oder Nachrichten erzeugen. Art und Zeitpunkt der Signale werden auf Grund von Algorithmen der internen Firmware erzeugt und bestimmen somit die Funktionalität der Baugruppe. Je mehr Informationen über das Gesamtsystem zur Verfügung stehen, um so breiter ist die Basis, auf der Entscheidungen gefällt werden können. Damit die elektronischen Baugruppen in einem System zusammenarbeiten und interne Informationen oder Kommandos austauschen können, müssen Sie über einen Feldbus miteinander vernetzt werden.
Nach einer ausführlichen Analyse der einzelnen Bus-Systeme haben sich viele europäische Komponentenhersteller für den CAN-Bus als Feldbus für den Aufzug entschieden. Hauptkriterien sind die Echtzeitfähigkeit, Sicherheit, Geschwindigkeit sowie die Lizenzfreiheit, Herstellerunabhängigkeit, Preis und Verbreitung.
Basierend auf dem CAN-Bus wurde für die standardisierte Kommunikation eine gemeinsame Sprache entwickelt mit der Bezeichnung CANopen Lift oder CANopen CiA 417.
Das Applikationsprofil beschreibt eine Applikation mit dem folgenden Umfang:
Alle Geräte werden als ‚virtuelle Geräte‘ definiert, die innerhalb dieser Applikation verwendet werden können. Die Funktionen der ‚virtuellen Geräte‘ wurden beschrieben und alle Nachrichten, die diese Geräte produzieren oder empfangen können, definiert.
Somit wird zum einen gewährt, dass die Komponenten am Bus möglichst kompatibel sind und ein Maximum an Plug-and-Play erreicht wird und zum anderen bleibt den Komponentenherstellern und dem Aufzugbauer eine sehr grosse Flexibilität für individuelle Alleinstellungsmerkmale. Die Normung bezieht sich ausschliesslich auf die Kommunikation der Komponenten auf dem Systembus. Sie beschreibt nicht die Funktionalität des Gerätes. Dies bleibt weiterhin Know-how des Herstellers.
Virtuelle Geräte sind abstrakte Softwareobjekte, die ein reelles Gerät repräsentieren (z. B. einen Absolutwertgeber oder ein Türsteuergerät). Das Konzept der virtuellen Geräte wird verwendet, um verschiedene Gerätetypen der gleichen Geräteklasse auf ein gemeinsames Interface abzubilden.
In Applikationsprofilen gibt es in der Regel keine Master/Slave-Kommunikation bezüglich der Prozessdatenobjekte. Im CANopen-Applikationsprofil für Aufzugsteuerungen CiA 417 sind direkt PDO-Verbindungen zwischen der Lifttür und der Türsteuerung definiert.
Bei Applikationsprofilen werden meistens nur virtuelle Geräte spezifiziert. Dadurch kann der Gerätehersteller entscheiden, welche virtuellen Geräte er in ein physikalisches Gerät implementiert.
Ein grosses Problem bei Bussystemen war in der Vergangenheit die Diagnosefähigkeit. Hier bieten sich durch das Applikationsprofil vielfältige Möglichkeiten.
Steht für die Diagnose und Konfiguration einer Anlage ein Laptop zur Verfügung, ergeben sich viele sehr komfortable Möglichkeiten. Dadurch, dass die Kommunikation und die Parametersätze aller Geräte standardisiert sind, ist es möglich, mit einer einzigen Software alle Geräte eines Aufzugs zu parametrieren. Ein solches universelles Konfigurationstool ist die Software CANwizard®, die schon von mehreren Herstellern eingesetzt wird.
Software ist nie frei von Fehlern und die Funktionalität einer Baugruppe wird heute durch die interne Firmware bestimmt. Somit ergibt sich häufig die Notwendigkeit, in eine Baugruppe ein Softwareupdate einzuspielen.
Der CANwizard® ermöglicht es, über ein standardisiertes Verfahren bei einer oder mehreren Baugruppen herstellerunabhängig ein Softwareupdate durchzuführen.
Zu Beginn der Normierungsarbeiten waren einige organisatorische Fragen zu klären. Ziel war es, einen weltweit gültigen Standard zu definieren, der allen offensteht und durch keinen Hersteller oder Verband dominiert werden kann. Das Gremium soll sich durch aktive Normungsarbeit und Erfahrung auszeichnen und bei der Arbeit Unterstützung leisten können.
All diese Bedingungen wurden durch die Organisation CAN in Automation (CiA) erfüllt. Die herstellerunabhängige Non-Profit-Organisation hat in Nürnberg ihr Headoffice und weltweit auf den wichtigsten Märkten Niederlassungen.
Die CiA übernimmt die Normungsarbeit, organisiert Schulungen rund um das Thema CANopen, zertifiziert Geräte, informiert auf Messen und vieles mehr.
Zweimal jährlich treffen sich die Mitglieder der SIG Lift zur Erweiterung der Spezifikation und besprechen neue Funktionen, die zukünftig einfliessen sollen.
Dieser Artikel ist ein Auszug aus Standardisierte Vernetzung von Aufzugskomponenten auf der Grundlage der CiA-417 Lift Control
Von Jörg Hellmich, ELFIN Technology GmbH
Aus unserer Arbeit mit CiA 417 ist CANoopEn entstanden – ein quelloffener CANopen-Stack in modernem C++, veröffentlicht unter der Apache-Lizenz 2.0. Er unterstützt neben CiA 301 auch das Lift-Applikationsprofil CiA 417. Dokumentation, Quellcode und lauffähige Beispielprojekte sind frei verfügbar.
