Elevators are becoming increasingly complex. More and more electronic devices are being installed in elevators to meet the increasing demands for functionality, current standards and safety requirements.
Embedded microprocessors work in electronic devices, which generate output signals or messages depending on their input signals or based on sensor data. Type and timing of the signals are generated based on algorithms of the internal firmware and thus determine the functionality of the assembly. The more information about the overall system is available, the broader the basis on which decisions can be made. In order for the electronic modules to work together in a system and exchange internal information or commands, they must be networked with each other via a field bus.
After a detailed analysis of the individual bus systems, many European component manufacturers have chosen the CAN bus as the field bus for the elevator. The main criteria are real-time capability, safety, speed as well as freedom from licensing, manufacturer independence, price and distribution.
Based on the CAN bus, a common language has been developed for standardized communication called CANopen Lift or CANopen CiA 417.
The application profile describes an application with the following scope:
All devices are defined as ‘virtual devices’ that can be used within this application. The functions of the ‘virtual devices’ are described and all messages that these devices can produce or receive are defined.
This ensures on the one hand that the components on the bus are as compatible as possible and that a maximum of plug-and-play is achieved, and on the other hand it leaves the component manufacturers and the elevator manufacturer with a very high degree of flexibility for individual unique selling points. The standardization refers exclusively to the communication of the components on the system bus. It does not describe the functionality of the device. This remains know-how of the manufacturer.
Virtual devices are abstract software objects that represent a real device (e.g. an absolute value encoder or a door control device). The concept of virtual devices is used to map different device types of the same device class to a common interface.
In application profiles there is usually no master/slave communication regarding the process data objects. In the CANopen application profile for elevator controllers CiA 417 direct PDO connections between the lift door and the door controller are defined.
With application profiles usually only virtual devices are specified. This allows the device manufacturer to decide which virtual devices to implement in a physical device.
A major problem with bus systems in the past was the diagnostic capability. The application profile offers a wide range of possibilities here.
If a laptop is available for the diagnosis and configuration of a system, there are many very convenient possibilities. Because the communication and parameter sets of all devices are standardized, it is possible to parameterize all devices of an elevator with a single software. One such universal configuration tool is the CANwizard® software, which is already used by several manufacturers.
Software is never free of errors and the functionality of an assembly is nowadays determined by the internal firmware. Therefore, it is often necessary to install a software update into an assembly.
CANwizard® enables a manufacturer-independent software update to be performed on one or more assemblies using a standardized procedure.
At the beginning of the standardization work, some organizational questions had to be clarified. The aim was to define a worldwide standard that is open to everyone and cannot be dominated by any manufacturer or association. The committee should be characterized by active standardization work and experience and should be able to provide support in its work.
All these conditions were fulfilled by the organization CAN in Automation (CiA). The manufacturer-independent non-profit organization has its head office in Nuremberg and branches in the most important markets worldwide.
The CiA is responsible for standardization work, organizes training courses on CANopen, certifies devices, provides information at trade fairs and much more.
SIG Lift members meet twice a year to expand the specification and discuss new functions to be incorporated in the future.
This article is an excerpt from Standardisierte Vernetzung von Aufzugskomponenten auf der Grundlage der CiA-417 Lift Control
From Jörg Hellmich, ELFIN Technology GmbH
Our work with CiA 417 led to CANoopEn, an open source CANopen stack in modern C++, released under the Apache License 2.0. Besides CiA 301 it also supports the CiA 417 lift application profile. Documentation, source code and ready-to-build samples are freely available.
