Das CANopen Applikationsprofil für Aufzüge CiA-417

CAN wird schon seit vielen Jahren in Aufzügen eingesetzt. Im Jahr 2002 haben verschiedene mittelständische Unternehmen beschlossen, zukünftig ein standardisiertes höheres Protokoll (CANopen) einzusetzen, um “plug-and-play”-fähige Geräte anbieten zu können, die es einem Aufzugbauer ermöglichen zueinander kompatible Geräte von verschiedenen kleineren Firmen zu beziehen, statt alles von einem großen Anbieter kaufen zu müssen. Dies setzt verschiedene mittelständische Unternehmen in die Lage, mit ihren spezialisierten Produkten mit größeren Firmen, die komplette Aufzüge anbieten, in den Wettbewerb zu treten. Das Ergebnis der Standardisierung ist das CANopen Applikationsprofil, das die Anwendung einer 8er-Gruppe von Aufzügen beschreibt, mit jeweils bis zu 254 Etagen.

Die CANopen Special Interest Group (SIG) Lift ist eine technische Arbeitsgruppe der CAN in Automation (CiA) die das CANopen Applikationsprofil CiA DSP 417 ausgearbeitet hat.

Die CANopen Special Marketing Group Lift promotet das Applikationsprofil für Aufzüge.

CiA-417 unterstützt den Bau von Aufzügen mit jeweils bis zu 254 Haltestellen, 4 Türen je Etage und Realisierungen von Einzelaufzügen bis zur 8er-Gruppen, was für die meisten Anwendungsfälle typischer Gebäude ausreichend ist. Im Applikationsprofil sind die Funktionen definiert, die nötig sind um eine Aufzugssteuerung zu bauen und die Kommunikation zwischen allen Geräten. Um das zu ermöglichen, beschreibt das Applikationsprofil alle Geräte, die nötig sind, um ein Steuerungssystem für Aufzüge zu bauen. Diese Geräte werden als virtuelle Geräte beschrieben. Bei diesen ist zu beachten, dass ein virtuelles Gerät nicht in mehrere physikalische Geräte verteilt werden kann. Ein pysikalisches Gerät jedoch kann mehrere virtuelle Geräte beinhalten. Es ist den Herstellern physikalischer Geräte überlassen, welche virtuellen Geräte sie mit welchem Funktionsumfang in ihre physikalischen Geräte integrieren. Der jenige, der dann ein System zusammenstellt, muss nur darauf achten, dass alle benötigten virtuellen Geräte in dem Gesamtsystem vorhanden sind. Dies ermöglicht dem Gerätehersteller die Funktionalität für sein physikalisches Gerät festzulegen, basierend auf den Erfordernissen des Marktes, die sich ja ändern können. Die virtuellen Geräte müssen dabei nicht verändert werden, da sie in dieser Anwendung immer benötigt werden. Dieser Ansatz erlaubt ebenfalls den Einsatz transparenter Gateways, sodass es möglich ist, diese jeweils so im System zu platzieren, dass an benötigten Positionen separate physikalische Netzwerke gebildet werden können. In diesem Fall erscheint das Gateways so im Netzwerk, als würde es alle virtuellen Geräte des Teilnetzwerkes beinhalten. Dies erlaubt einen sehr flexiblen Aufbau von komplexen Netzwerken.

Das Applikationsprofil definiert auch Beziehungen bei der Kommunikation zwischen den virtuellen Geräten, das heißt, die Definitionen des Inhalts (mapping parameter) und das Verhalten (communication parameter) der Prozess Daten Objekte (PDO). Diese Definitionen unterscheiden sich von normalen Standard-CANopen-Spezifikationen. Das kommt daher, dass die Definitionen erfolgen, ohne ein spezielles Gerät zu betrachen. Normalerweise kennt nur der Systemdesigner das System und er hat alle Beziehungen der Kommunikation der einzelnen Geräte festzulegen. In diesem Applikationsprofil jedoch, ist das System bekannt, was die zusätzliche Festlegung der Kommunikationsbeziehungen erlaubte. Wie aus den Kommunikationsbeziehungen zwischen virtuellen Geräten bekannt ist, können für PDOs spezielle Beziehungen definiert werden. Das ermöglicht die Vorgabe von CAN-Identifierern abhängig von ihrem Einsatzzeck. Da die CAN-Identifierern schon definiert sind, besteht notwendige Beziehung mehr zwischen den CAN-Identifierern und der Node-ID. Das heißt, dass in einem solchen System die CANopen Node-ID irrelevant ist. Der Endenwender muss nur sicher stellen, dass jede Node-ID im Netzwerk einmalig vergeben ist, jedoch der Wert der Node-ID selbst spielt keine Rolle mehr. Dies ist auch eine Notwendigkeit für den Einsatz transparenter Gateways. Das Applikationsprofil CANopen Lift control (DSP 417) beinhaltet die folgenden virtuellen Geräte:

• input panel unit,
• output panel unit,
• call controller,
• car door unit,
• car door controller,
• light barrier unit,
• car drive unit,
• car drive controller,
• car position unit,
• load measuring unit, and
• sensor unit.

-- Übersetzung ist in Arbeit --

Any of these devices is responsible for a specific set of functionalities. For example an input panel unit is the device on every floor as well as in the car itself that receives the call requests from the user of the lift and transmits these call requests to the call controller. Such a call request includes information about the geographical position of the call (where it comes from and where it should go) and the type of the call (normal call, priority call like firefighter call). These calls collected by the call controller will be processed and an acknowledgement will be transmitted to the output panel unit (that is the light on the panel that you see when your call is accepted). As a result of the processing the call controller has to inform the car drive controller and the car door controller, which will result in the appropriate movement of the car and car doors as requested by the user. Besides the normal information path the call controller as well as the car door controller and car drive controller receives status information of the load measuring system and several sensor units. For example such a sensor unit will be a presence sensor that is able to detect any person in the car itself. Other types of sensors are smoke detectors, cullet detectors or any other based on which decisions are made when a certain floor is reached by the car or whether the car is able to move at all. Any of these virtual devices uses its own area of indices in the Object Dictionary or may share some objects. Such shared objects are of type read-only if the appropriate virtual device is the source of the information and read-write or write-only if the appropriate virtual device is the destination. By use of this concept it is possible to integrate gateways in the system at any desired position or leave them completely out.

Normally, the use of gateways depends on the type of the lift control system. For example, a small scale lift control system, like it can be found in residential houses, can be realized by using just one physical network without any gateway. As opposed to that, lift control systems with several parallel cars, like in an office, will be integrated by use of different physical networks, where any physical network is connected by a gateway transparently.

The well known mechanism in CANopen of shifting device profiles to support several device profiles within the very same physical device is used in the application profile to support the required up to eight parallel lifts.

This kind of definition is very much alike some of the already specified device profiles (some existing once are re-used, e.g. drive and motion control, position control). The difference in the specification of this application profile is the pre-defined communication relationship between the virtual devices. This means, that a device according to this application profile will no longer make use of the so-called pre-defined identifier set as defined in the CANopen specification DS 301. A device according to this device profile has to use specific identifiers for the specific functions.

The panel is the most sophisticated device in the lift control system. Because a panel is located on every floor and in the car as well, there may be several panels on the very same floor, which may have the same functionality or may allow additional functionalities. For example, it is very common in public buildings and hotels that not every floor can be reached by all cars. Just specific cars are allowed to enter a certain floor. This functionality has to be put into a panel unit. For that reason the panel unit is divided into two virtual devices, virtual input panel unit and virtual output panel unit. The panel transmits call requests (virtual input panel unit) and receives call acknowledgements (virtual output panel unit) based on the geographical address of the panel and the associated calls and based on the type of the call.

This working principle was decided upon because it allows a very flexible use of panels. It allows to use a panel that is normally found in the car itself to be placed outside of the car on the floor to allow destination calls. This is required for cargo lifts, because there is no one in the car to make a call request. It can also be used in future passenger lifts to allow optimization of car usage, for example in office buildings during rush hour. During building of the system, the panel just has to know where it is located in the system (at which floor and maybe for which car and for which door of the car it is responsible). Supported by an appropriate tool this should be very easy to configure even for unqualified service personnel. The service staff does not have to know anything about CAN or CANopen, they just have to connect their configuration tool to a panel and to set the appropriate data for that panel. The CANopen node-ID of that panel will be independent from the function and could be assigned by an automated service like the CANopen Layer Setting Services (LSS).

All the other virtual devices are defined by use of existing device profiles, like motion controller and position encoder, or are developed by using the same mechanisms as in existing device profiles, like door control, load measuring, etc.