Experiences with CANopen Lift networks
By Holger Zeltwanger, CAN in Automation (www.can-cia.org/lift)
Lift control applications increasingly use decentralized and distributed control systems. These control systems require communication networks that link the sub-controllers, the “intelligent” sensors and the actuators. The level of compatibility is an important issue, if you want to buy and use off-the-shelf products.
The IEC T(echnical) R(eport) 62390 defines compatibility levels for network interfaces. Particularly for low volume applications, it is necessary to use high compatibility levels for network interfaces to minimize integration effort and to save costs.
Contrary to that, however is the fact that standardization keeps technology at a standstill. In order to be flexible and future-proved, it should be possible to extend and enhance the interface definitions. Flexibility is one of the key features of a network technology used in lift control applications. Network technology
Controller Area Network (CAN), is a well-proven network technology. The physical layer (ISO 11898-2), as well as the data link layer (ISO 11898-1) are used in Millions of passenger cars and other control systems including embedded machine control, medical electronics, rail vehicles, and many more. CAN transceiver and CAN controller chips are available from more than 50 companies worldwide. The CAN controller chips are usually integrated in micro-controllers, which simplifies hardware design. The CAN data link layer protocol is robust and provides several built-in error detection mechanisms. The CANopen application layer protocol (EN 50325-4) was originally developed for embedded machine control applications. In 2004, about 1 Million CANopen devices were sold, which were used in applications such as off-highway vehicles, electronically controlled building doors, and embedded control systems.
The CANopen application layer provides communication services for real-time data transmission, for up- and downloading of configuration parameter and diagnostic information as well as for emergency messages. These standardized communication services use standardized protocols, e.g. PDO (process data object) protocol, SDO (service data object) protocols, EMCY (emergency) protocol.
The CANopen communication profile (EN 50325-4) defines the CANopen object dictionary. This dictionary is addressable by means of a 16-bit index and an 8-bit sub-index. This 24-bit addressing scheme overcomes the 11-bit CAN identifier limitation (2,048 addressable objects). The dictionary is the “heart” of each CANopen device.
It is the link between CANopen protocol stack and control application software. It is accessible from both sides: you may write to the object via the CAN network and the application software may read the object or vice versa. The communication profile area of the CANopen object dictionary contains all objects that define the network behavior. The CANopen device is modeled provides up to eight logical devices, which may be regarded as application one to application eight. In case of the lift control system, each application (logical device) represents a single lift control application. This is reflected by the structure of the CANopen profile area (objects 6000h to 9FFFh); it is virtually divided in eight sections of 800h indices.
The virtual devices represent device interfaces. In case of lift control system, this may be a panel, a car door controller, a sensor box, a call controller, etc. Only the number of objects limits the number of virtual devices. In total, you have 1,280 objects for all virtual devices, and each object may have up to 254 sub-objects, if the object type is array or record.
Using this model, you can also describe user-transparent gateways. The gateways may be CANopen-to-CANopen gateways or CANopen gateways to other network technologies. With this concept you also may hide proprietary bus systems.
Application profile
The CANopen Lift application profile (CiA 417) is based on this concept of logical and virtual devices. One of the most important challenging tasks of system design is the assignment and distribution of CAN identifiers to the CANopen communication objects (COB). The base frame format of the CAN data link layer protocol uses an 11-bit identifier that has to be distributed uniquely to the transmitted messages. This identifier defines the content of the data and its priority in the network. The CANopen Lift application profile pre-defines all COB. The CANopen application layer defines the CAN identifiers used for the SDOs, for Emergency messages, NMT (network management commands), heartbeat and boot-up messages. They derive from the CANopen physical device’s node-ID, which is assigned uniquely by the system designer. The CAN identifiers for the PDOs that transmit real-time data are specified by the CiA 417-3 standard. Each physical device compliant to this application profile provides one MPDO in DAM (Destination Address Mode) to be transmitted in broadcast (addr = 0) and up to 127 MPDOs in DAM mode to be received. Depending on the multiplexor (corresponding to index and sub-index of the CANopen object dictionary), the MPDO consumer enters the received data into its object dictionary or it ignores the received MPDO. The MPDO producer transmits all application objects of the physical device, which features a PDO mapping attribute of the value default. In addition, the MPDO may be used to transmit application featuring PDO mapping attributes with the value possible.
Some virtual devices additionally support PDOs with pre-defined mappings and pre-defined CAN-IDs. Other virtual devices support PDOs with pre-defined mappings and CAN-IDs derived from the assigned node-ID. Object dictionary entry indexes of PDO communication parameter and PDO mapping parameter given in this part of the application profile are mandatory. This may exclude some combinations of virtual devices in one physical device. The system designer may use other object dictionary entry indexes of PDO communication and mapping parameters. Note: In this case, the system designer is responsible for consistency of PDO parameters.
First experiences
Lift control systems based on CiA 417 have been installed since beginning of 2004. These control systems use just a subset of the defined virtual device interfaces. In one of these applications the call controller and car controller were installed within one control device. The corresponding input and output panels installed on the floors as well as the car-positioning unit are connected via CANopen networks. All other devices were linked via non-standardized interfaces. The lift control system used in Geneva, Switzerland comprises three lifts connected via CANopen. The gateways between the several CANopen networks are user-transparent meaning that the entire network system is logically one network. In another application in Lehrter railway station in Berlin, Germany, 36 single lift control systems are based on the CANopen Lift application profile. In total, more than 100 lift control systems based on CiA 417 have been installed. Sporadic failures occurred due to erroneous termination resistors.
Availability of CiA 417 products
The number of available products compliant to CiA 417 is still low: In particular, drive, car door, and emergency call units compliant to CiA 417 are not available off-the-shelf yet. They are, however, in the pipeline. The CANopen Lift application profile allows to design lift control applications with up to eight lift controllers each serving up to 254 floors. The concept of logical and virtual devices as well as user-transparent gateways simplifies the CAN-ID assignment and distribution. The experiences made in the first installations show that the concept covers the requirements. Additional functions (such as emergency calls) not defined in the first version of the CANopen lift specifications will be added in the revision.
Source: CAN Newsletter Special Lift 2005 (www.can-cia.org/newsletter)