CANopen Group Defines Communication Protocol
KEB drive takes advantage of vendor-neutral, plug-and-play standard.
by Dalen Miller and Colin Zauner
Reliable and safe operation of elevator systems requires interoperability between many interconnected devices. Throughout the entire lifecycle of the elevator system, if any device malfunctions or fails to operate as intended, the entire system is in jeopardy of a shutdown. This is especially true for modern elevator systems, which are equipped with many networked electronic devices. Interoperability of each networked device becomes a challenge when devices exchange information using different communication protocols.
With this challenge in mind, a technical group named “CANopen Special Interest Group Lift” within CAN in Automation (CiA) was formed to define a standard communication protocol to be used by all networked devices in the elevator control system. Such devices may be variable-frequency drives, car controllers, door controllers, input panels, display units, etc. The application profile CiA 417 for lift control was defined as the open standardized protocol for communication for devices in a CANopen elevator system. CiA 417 is based on the communication profile CANopen, which is commonly utilized in many industrial applications. The goal of creating a standard communication protocol is to create a vendor-neutral elevator system using plug-and-play components. This allows users the freedom to combine products from different producers without the worry of incompatibility issues. The benefits of creating a plug-and-play system include reduced cost and time in designing, installing and maintaining the elevator system.
The COMBIVERT F5 product family with CANopen Lift (CiA 417) operator has been developed for use in elevator applications. The CANopen Lift operator was built on an already-proven elevator program that includes a wide range of specially designed features to reduce installation times and provide high-performance ride quality without sacrificing safety.
Standard Open Protocol
CiA 417 defines a standard communication protocol to be used by all devices on the communication bus for elevator systems. Each device will communicate using the same set of rules when transmitting information. This means that the transmission of information to all devices on the bus will follow a common format and meaning. In addition, all information is transmitted and received using the same communication mechanism. CiA 417 defines all parameters, commands and services used by the elevator system. The cornerstone of CiA 417 is its unique object dictionary containing defined input/output settings, configuration settings and specific device identifiers, among other things. Using this common “language,” each device on the bus will understand all commands or status messages sent and received.
Furthermore, CAN (Controller Area Network) bus systems allow information to be exchanged to all devices at the same time (Figure 1). Each device then individually determines the importance of each message and decides how it should react. Devices on the CAN bus can be programmed to read and respond to error messages from other devices. For example, if the elevator drive enters an error state, the drive would send out a corresponding error description to all devices on the bus. The state of the drive will be universally known to all devices programmed to receive messages from the drive. Accessing status information on all devices can help reduce the time and cost spent on troubleshooting and resolving issues.
The heartbeat protocol is an additional specification that ensures reliable communication and fast handling of errors. Periodically, each device will send out a short message on the bus indicating to every other device it is connected. This message is known as the heartbeat. The heartbeat is used to confirm connection and status of each device on the bus. Each device should be programmed to monitor the heartbeat of other devices with which it needs to communicate; e.g., the drive and controller. If a device does not respond in a specific amount of time, the master device can take a specific action to reset the device or trigger an error. Devices are configured to receive a particular heartbeat from other devices; for example, the controller will produce a heartbeat, and the drive will receive it. If the drive does not receive the controller heartbeat after the specified time, it will make the programmed response.
CiA 417 allows the parameters from all devices to be accessed and adjusted, regardless of physical location, with any human machine interface (HMI). Remote access to any device is achieved through the virtual terminal. For example, the adjustment of a drive parameter may be very challenging if the elevator is machine room less (MRL) and the drive is mounted in the hoistway. This is simplified with the virtual terminal, as it would be possible to adjust drive parameters directly from a car controller. The virtual terminal uses virtual keyboard codes (Figure 2) and screen characters using ASCII codes according to the ISO 88915 standard for device parameterization and configuration. Each HMI using the same codes and sequences can be used as the screen of a remote device. If a wireless device is connected to the bus, it is also possible to remote connect using a smartphone and utilize it as an adjustment tool. The KEB operator interface includes the virtual terminal for universal access to all devices on the bus.
CANopen is a higher-level communication protocol built upon the CAN protocol. CANopen was initially designed for motion-oriented machine control systems. The underlying CAN protocol is the foundation of the networking hardware and defines the data-transfer procedure.
CAN bus systems are utilized in many different systems, including industrial and automotive applications. The high demand for CAN controller chips has created a high supply of them from various manufacturers at a cost-effective price.
Elevator control cabinets often contain many potential forms of electromagnetic interference (EMI). Troubleshooting EMI and corrupted data transfer can cause significant installation delays and come at a considerable financial loss. CAN controller chips have advanced error handling built in. CAN hardware can detect bit errors and prevent transmitters and receivers from transmitting invalid messages before further data transfer. Error-checking mechanisms include bit monitoring frame checking, acknowledgment checking and error confinement, among others. KEB CANopen Lift drives also integrate advanced features and diagnostics in the elevator application software.
KEB CANopen Lift Drives
CANopen can be utilized in the KEB drive with velocity control mode. This is similar to current implementations of velocity control using different types of serial communication but has the advantages provided by CAN communication already discussed. Many elevator controllers in the U.S. elevator market use serial communication, and this sort of application can easily be done with CANopen communication.
The KEB lift drive also has a position controller as part of the drive software. The position controller in the drive can be used in conjunction with a CAN encoder to determine precise position and movement of the elevator car. This information can be used for direct-to-floor position control. Not only does this provide an optimized speed profile, it also reduces the burden on the main controller central processing unit. The intensive task of calculating slowdown distances and determining deceleration or acceleration rates can be handled by the KEB drive for a smooth and precise approach to the floor with minimal leveling distance (Figure 3).
The benefits of using a standardized communication protocol in an elevator controller are clear. It allows for interoperability of all networked devices, reduces costs, and provides a vendor-neutral design that sacrifices neither ride quality nor safety. The CANopen Lift specification allows for many benefits that will only increase as time goes on.