The CANopen application profile for lifts CiA-417

CAN has been used in lift control applications for many years. In 2002 several mid-size companies decided to move to a standard higher layer protocol (CANopen) to allow for “plug-and-play” compatibility of devices, which would enable a lift manufacturer to buy devices from several smaller companies instead of just one large company. This allows several mid-size companies with specialized products to compete with large companies that offer the complete lift system. The result of the standardization efforts is the CANopen application for lifts (CiA DSP 417), which enables the building of any lift application with 254 floors and eight parallel lifts.

The CANopen Special Interest Group (SIG) Lift is a technical working-group of the CAN in Automation (CiA) international users’ and manufacturers’ group that specified the CANopen application profile for lifts (CiA DSP 417).

The CANopen Special Marketing Group Lift promotes the application profile for lift control systems.

CiA DSP 417 provides for the building of a lift application with a maximum of 254 floors and eight parallel lifts, which should be sufficient for any type of standard building. The application profile defines device functions that are required to build a lift control system as well as the communication between these devices. To achieve this the application profile identifies any device that is required to build a lift control system. Additionally, it is required that such a device can not be separated into several physical devices, this device is called virtual device. A physical device can be built by combining several virtual devices. It is left to the manufacturer of physical devices to decide which functionality and which virtual devices they want to integrate into their physical device. The system builder has to take care that all virtual devices are present in his system. This allows the possibility for the device manufacturer to decide his physical device functionality based on market requirements, which may change with time. But the virtual devices will not change as they are always required in such applications. This approach also allows to use gateways transparently since it is possible to place gateways at any desired position in the system to separate physical networks. The gateway then looks to the network as it represents a complete set of virtual devices. This allows flexible network sizing.

The application profile also defines the communication relationship of the virtual devices, meaning the definition of the content (mapping parameter) and the behavior (communication parameter) of the Process Data Objects (PDO). This definition is different from the normal defaults in the CANopen specification. That is so, because the CANopen specification is made with an unknown system in mind. Normally, only the system integrator knows the system and he has to define the communication relationship in his system. In this application profile the system is known, which allows the definition of the communication relationship as well. As the communication relationship between the virtual devices is known specific PDOs can be defined for a specific relationship. That allows to pre-define CAN identifiers based on their purpose. But as the CAN identifiers are already defined by their purpose there is no more relation between the CANopen node-ID of a device and its CAN identifiers. That means, in such a system the CANopen node-ID will be irrelevant. The end user just has to guarantee that the CANopen node-ID for any device is unique, but the number itself does not matter. Additionally, this is another requirement to support gateways in the system transparently. The application profile lift control system consist of the following virtual devices:

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

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.