Open search
Advertisement

CAN Newsletter magazine

History and trends: CAN in elevators

In 2002, CiA members started to develop the CiA 417 profile for lift control systems. CANopen used in lifts became CANopen Lift. The goal was to agree to a common specification, which enables suppliers to design interoperable CAN-connectable devices for elevators.

(Source: Adobe Stock)

The complete article is published in the March issue of the CAN Newsletter magazine 2022. This is just an excerpt.

The history of elevators begun with human or animal powered hoists. Some early ones were even driven by water power. Modern elevators started in the 19th century: In 1852, Elisha Graves Otis introduced safety contrivance for elevators. The first electric-driven elevator was manufactured by Werner von Siemens in 1880. Nowadays, there are millions of elevators in operation. Most of them use electrical drives, the other ones are driven by hydraulics. Just in 2020, over one million units were installed and many others were retrofitted. Vertical transportation of human beings is very safe (some people state that elevators are the most reliable transportation technology) and very resource efficient in comparison with horizontal transportation.

Electric control systems for elevators are used for a long time. Beginning of the 90ties, Kone was one of the first companies using CAN networks to control elevators. Today most of the control systems for elevators make use of CAN networks. In the beginning, the CAN networks implemented proprietary higher-layer protocols. In 2002, some CAN in Automation (CiA) members started to develop a CAN-based application profile for lift control systems. The initiator was Joerg Hellmich working with Boehnke & Partner (now he is the Managing Director at Elfin). The profile is now known as CANopen Lift and it is specified in the CiA 417 document series.

CiA’s official CANopen Lift logo (Source: CiA)

CANopen Lift: Specifying virtual devices

The CiA 417 document series specifies an application profile based on the classic CANopen application layer (CiA 301). Application profiles describe the functional communication interfaces for the whole network. CiA 417 specifies the interfaces of functional entities called virtual devices. This includes call, car drive, and car door controllers as well as input panel, output panel, car drive, car position, load measuring, car door, light barrier, remote data transmission, and power-measuring units. A CANopen Lift device can implement one or multiple virtual devices. This allows very flexible network system designs. Usually, a CANopen Lift network system comprises two network segments connected via a transparent PDO bridge. This means, from a logical point of view it looks like a single seamless network.

All necessary PDOs for a single-shaft lift control system are specified; some of them are distributed in broadcast other peer-to-peer. For multi-shaft lift control systems, the communication between the controllers is manufacturer-specific. Nevertheless, each device can implement up to eight instances of the application profile, so it can be used in up to eight lift control systems.

As already mentioned above, the virtual device concept allows the design of PDO-transparent bridges. The virtual device definitions for the car drive unit (motion controller) and car position unit (encoder) follow the generic CANopen device profiles for motion controllers and encoders. However, in lift control applications different object dictionary entries are used. The CiA 417 specification comprises several parts: Part 1 describes general definitions (including additional error codes), Part 2 specifies virtual devices, Part 3 specifies PDOs, and Part 4 specifies application objects (process data and configuration parameters). All parts are available on CiA’s website.

2019, live in one of CiA’s CANopen Lift plugfests: On the left, CANopen Lift controller and units in one box connected to car drive units from other companies; On the right, CANopen Lift host controller tested on interoperability with drives and panels (Source: CiA)

As far as possible, the virtual device definitions are implementation-independent. The CANopen Lift specification enables system designers to select CiA 417 compliant devices from different suppliers and to integrate them into networks without huge efforts. For example, the car position unit can be implemented in traditional rotary encoders as well as sensors using other technologies to measure the position, such as ultrasound or magnetic tape. Usage of standardized interfaces allows the lift operator an open maintenance of the lift system. Software tools for implementation and diagnosis are available by different providers.

CANopen Lift is suitable for very small applications as well as for complex systems. Over the last ten years, the CiA 417 specification has been extended. It covers modern system requirements including pre-emptive maintenance and the link to cloud services. Since CiA 417 version 2.1.0, the boot-up and program download procedure is introduced. The CiA 814-1 application note provides the implementation hints for the CiA 417 compliant bootloader.

In the first days of CANopen Lift, there were available just a very few car drive units compliant with CiA 417. But those days are gone, nowadays, there are several man ufacturers offering CANopen Lift electric inverters. Some companies providing CANopen Lift inverters are, in alphabetic order, for example Control Techniques, Fuji, Gefran, Liftequip, Yaskawa, and Ziehl-Abegg. Most of them have already participated in CANopen Lift plugfests organized by CAN in Automation. In these plugfests, the interoperability to CANopen Lift host controllers featuring car drive controller functionality is approved. One of the market-leading CANopen Lift controller suppliers is Boehnke & Partner. In the last years, the company alone has delivered already about 25 000 CANopen Lift based host controllers. The potential of CANopen Lift has been recognized and so further devices are currently being developed. Other lift controller providers include, for example in alphabetic order, Bucher Hydraulics (on page 39 of the CAN Newsletter magazine you will find an article from them), Elfin, Elgo, Intec, Kollmorgen, RST, Safeline, Sprinte, Thor Engineering, Weber, and of course, a range of others. The list of companies providing CANopen Lift capable products is a very long one.

A little throwback

In 2019, the CAN Newsletter reported about one of the biggest projects with a CANopen Lift control system almost done in Sweden. In the Globen Shopping mall 29 lifts use CANopen Lift controllers. In a special issue of the CAN Newsletter in 2013, the project Mora Hospital was described. The lifts were undergoing modernization as one of the elements in the streamlining of care at Mora Hospital. The CANopen Lift control system collects external calls and priority lift calls are freely programmable. The position of the car is indicated on the FD4-CAN floor displays connected to the CANopen Lift network. In the same CAN Newsletter issue, there are reports about CANopen Lift applications for public means of transport. KoĢˆlner Verkehrs-Betriebe (KVB) in Cologne (Germany) and the Metro in Brussels (Belgium) decided to equip their new lifts with controls, operating and display panels, and further assembly groups with CANopen technique. These examples proof, CANopen Lift can be found everywhere.

In the Globen Shopping mall 29 lifts use CANopen Lift controllers (Source: Hisselektronik)

CANopen Lift plugfests

As already mentioned above, many providers of CANopen Lift products test their devices on interoperability during plugfests organized by CiA. On request, the nonprofit association organizes plugfests for its members. This is done to detect system integration problems before the products are shipped to customers. CiA members implementing the CiA 417 profile in their CANopen Lift devices proof jointly that their products provide plug-and-play capability. CANopen Lift controller suppliers can provide a list of interoperable devices and CANopen Lift unit vendors can provide a list of interoperable controllers. This helps to simplify system integration. System designers get a better understanding of the problems occurring during component respectively device integration. The participants learn from each other, together they solve interoperability issues. They share their experiences regarding functionality of CAN components, CANopen devices, and CAN-based network systems. Last but not least, the results of plugfests are a valuable input for improving of the related CiA specifications. The CiA association is a neutral platform to maintain the CiA 417 application profile specification and to organize plugfests. It also provides supplier- and product-independent training and education services.

CANopen Lift today

The CiA special interest group (SIG) lift control (CANopen Lift) maintains the CiA 417 specification series. The SIG constantly improves functional description of the application and communication interface for specified CiA lift components and the lift host controller. Furthermore, SIG also introduces new application functions and new lift component specifications. The purpose is to provide highly-readable specifications for implementing interoperable CiA 417 devices for lift manufacturers and system designers. SIG lift control approves release of CiA 417 specification versions with key functionalities and even retains previous specification versions to become publicly available to widespread and improve acceptance of CANopen in the elevator markets. In April 2022, CiA provides a free-of-charge webinar regarding lift control.

If you would like to read the full article, you can download it free of charge or you download the entire magazine.

cw

Publish date
2022-03-07
Company

CAN Newsletter March 2022

Breadcrumb