Lift control devices: modular and scalable

Small and medium-sized lift manufacturers do not produce all the necessary devices by themselves. They buy on the market products from third-party vendors and integrate these devices into the lift control system.

There are even lift suppliers, which do not produce any hardware, but just the lift application software. Standardization of communication interfaces help to reduce the system integration effort.

Since many years, the CANopen Lift community organized in the nonprofit CiA (CAN in Automation) association has developed several functional interfaces. They are described in the CiA 417 CANopen application profile for lift control systems. This modular system approach is also known as CANopen Lift.

EDS format is standardized

CANopen Lift devices may implement one or multiple of the specified functions. The device indicates the implemented functions by means of its Electronic Data Sheet (EDS). Of course, the EDS format is standardized, too. CiA 417 specifies to classes of functions, which are known as "virtual devices":

There are virtual controllers, which are programmable entities, and there are units, which have a pre-programmed configurable functionality. Nowadays, most of the available lift controllers provide the call controller, the car controller, and the car door controller in the same device. Of course, in the future they may be implemented in separate devices.

Since many years, the following basic building blocks have been standardized in CiA 417:
• Call controller: It manages the call requests from the input panel units and acknowledges them to the output panel units. It requests the car drive controller to move the car and requests the car door controller to open or close the doors.
• Input panel unit: It is installed as in-car call panel or as floor call panel. There are also general input devices (e.g. for key-switch or fire alarm).
• Output panel unit: It is installed as in-car display panel or as floor display panel. It could be also a generic output panel providing acoustic announcements.
• Car drive controller: It commands the car drive unit to move the car.
• Car drive unit: It moves the car upwards and downwards.
• Car position unit: It measures the position of the car. Optionally, it provides speed, acceleration, and jerk values. There may be four units in the lift control system.
• Car door controller: It commands to open and to close up to four car lift doors. It receives optionally data from the light-barrier unit.
• Car door unit: It opens or closes the car lift doors.
• Light barrier unit: It detects subjects and objects entering the protected area of the car doors.
• Load-measuring unit: It provides the current load of the car and indicates overload situations to the car drive controller.

In the last few years, the following functional entities have been added to the CiA 417 specification set:
• Power-measuring unit: It provides the measured power consumption. It can measure the overall or the device-individual power consumption.
• Remote data transmission unit: It features gateway functionality for remote control or remote diagnostics purposes.
• Access remote unit: It reads different media to allow access, e.g. chip and smart cars, RFID tags, bar codes, or fingerprints.
• Monitoring unit: It serves as condition monitoring as recommended in VDMA 24582.
• Position supervisor unit: It comprises the car position unit 1 and monitors speed, deceleration, door contacts, safety limit switches, and unintended car moves.

Simplified the system design

These standardized controller functions and virtual device units have simplified the system design. The high-degree of optional features allow designing scalable devices and control systems. This means the lift designer can use the same communication technology in simple as well as complex lift control systems. This reduces effort in training and the system integrator can gain experiences.

In addition, the lift control system can be tailored to the needed functions. Nevertheless, the lift control system can be extended and retrofit, when required. But some of the offered products do not provide all optional features. This means, the selection of products is not that easy. This is the trade-off or the price to pay for scalability. Interoperability classes would simplify this. But they are not yet introduced.

In order to proof the interoperability of CANopen Lift devices, the CANopen Lift community tests their products in so-called plugfests. In the past, CiA 417 suppliers met twice a year to prove that their devices operated with each other.

Holger Zeltwanger

can-cia.org