The standardized network for lift control systems

by Jörg Hellmich (Böhnke + Partner GmbH)

In general, lifts are becoming more complex. An increasing number of electronic devices are installed in lift control systems so as to be able to satisfy both rising demands in regard to functionality and the requirements set forth in current standards and safety specifications. Embedded microprocessors respond to input signals or sensor data and thus generate output signals or messages, which are determined on the basis of algorithms written in the internal firmware. To make it possible for the electronic devices to work together and exchange internal information or commands they will have to be connected with each other by means of serial networks. Controller Are Network (CAN), originally developed for in-vehicle networking, meets the equirements of the lift industry regarding reliability and robustness. By using the principle of prioritized messages, several units can each start sending a message through a transmission medium. The CAN identifier, a prefix to the message, is used to determine, which message has the highest priority. The message with the highest priority will be sent without delay. Lower priority messages will be postponed. Thus real-time communications are possible.

PlugFest 2010

Many European device manufacturers have decided on the CAN technology to be used in lifts (elevators) to develop a joint language for standardized communication. The primary criteria to be satisfied are the ability to function in real-time, safety, speed, freedom of licensing requirements, autonomy from any given manufacturer, price and widespread use. But the standardization of the low-level communication protocol is not sufficient for interoperability and exchangeability of devices. Also the application layer protocol and the content of the messages need to be standardized.

Therefore, several companies started in 2001 the standardization of higher-layer protocols and profiles for the lift industry within the nonprofit CAN in Automation (CiA) international users’ and manufacturers’ group. Based on CANopen (EN 50325-4/ CiA 301) the CiA 417 application profile for lift control systems was developed. In October 2003, the first prototypes were exhibited at the Interlift. In the meantime, the CiA 417 specification has been reviewed and has been released as version 2.0 beginning of this year.

For up to 254 landings

floor indicator

The CiA 417 profile has some limitations: It supports lift group controller with up to eight elevators, 254 landings, and four doors per lift car. Associated with the profile are various specifications and supplementary recommendations, such as for plug connectors or for the colors of the wires. This insures on the one hand that the devices using the CAN network are as compatible as possible and that maximum plug-and-play capability will be achieved. On the other hand, the device manufacturers and lift engineers enjoy great flexibility in designing individual and unique features. Standardization is referenced exclusively to the communications among components attached to the system bus.

All the functions that can be used within the application are defined as “virtual devices”. These virtual devices are abstract software objects that represent a real-world device (e.g. an absolute value transmitter or a door controller). The concept of virtual devices is used to depict various types of devices, all in the same class of devices, on a common interface. In application profiles there are, as a rule, no master/slave communications in regard to the process data objects (PDO). The normal case is that only virtual devices are specified in application profiles. This lets the equipment manufacturer decide which virtual device is to be implemented in a physical device. This makes it possible to assemble widely varying systems, the topologies of which are not determined by the application profile, since bridges and gateways can quite easily be developed. The lift manufacturer, for instance, can use separate CANopen networks for car control and for the control panels inside the hoist-way.

Diagnostics

In comparison to the past, this application profile offers a wide variety of possibilities to carry out diagnostics work. Firstly, one can naturally equip each device with a status LED or a display. The disadvantage here is, however, that an integrated display involves costs and the technician has to be present on site in order to read the information shown in the display.

Furthermore, one can use the “virtual console” defined in CANopen-Lift. The virtual console defines a procedure a device uses to apply the content of its own display to the system bus and how this data can be displayed by other devices. Moreover, it is possible, with the help of a control command, to navigate through the menus from other units. Thus not only the content of the frequency inverter display can be depicted in the controls. Additionally, the menu of each individual device can be shown at every other device equipped with a display.

If a laptop is available for diagnosis and configuration work, it is possible, with a single software program, to parameterize all the devices in an elevator, as the communications and the parameters sets for all the devices are standardized. One configuration tool of this type is the “CANwizard” software.

Once the laptop has been joined with the system bus the CANwizard scans the bus and reads out the parameters for all the devices connected to it. If the operator has the proper authorization, then the parameters can be changed and written back into the device.

Additionally, a complete image of the elevator can be archived. This can be used to configure lifts of a similar design, to facilitate configuration of a replacement part or to detect manipulations in parameters.

The CANwizard makes it possible to execute a software update, for one or more assemblies, regardless of which manufacturer built the units.

Thanks to the standardization of the process and the fault messages in the bus, a single tool can be used to diagnose all the components and the system as a whole. All the process messages – such as “Low-priority hallway call in floor 8 at door A of lift 1” – can be depicted in plain text, in real time, and stored in a log file together with a time stamp. Thus the technician, working from just a single location, can obtain status information on all the devices and the entire process.

An electronic data log is associated with each CANopen device and is stored in EDS (electronic data sheet) files. These files describe, in a standardized text format, both the most important parameters for the device as well as physical parameters. Configuration tools can read EDS files and, with their help, can also communicate with previously unknown devices and possibly parameterize them. CANwizard provides an EDS library containing the EDS files for all the known CANopen-Lift devices.

CANwizard is not associated with any manufacturer but available to every engineer and developer of CANopen devices. It is not desirable that competitors have access to internal know-how concerning certain functions. That is why CANwizard is fitted with an interface to accept add-ons that expand the program’s functions to reflect current standards and the functions of devices on the market. The developers of CANwizard build confidence in their products by communicating openly with users. That includes providing a continuously updated history of the software, accessible for every user, and providing information on expansions of functions and corrections of errors.

In an age when the Internet is ubiquitous, it is quite natural to offer remote diagnosis. This works as soon as the lift is linked to the Internet via a suitable gateway to CANopen-based control systems.

Interoperability

The objective of the standardization was to define a specification valid around the world, one that was available for use by everyone and one that could not be dominated by any single manufacturer or professional association. The committee members were also supposed to have a background in active standardization work and experience in such efforts. They were to share insights and lend support in the work.

All these conditions were satisfied by the impartial, CiA organization. CiA takes responsibility for standardization work, organizes training sessions on CANopen, certifies devices, disseminates information at trade fairs and does much more. Work for lifts is done in two areas within CiA. The “Special Interest Group (SIG) Lift” is made up of developers who define new functions, work out the protocol, test and certify devices.

The “Marketing Group (MG) Lift” provides information about the protocol and the devices on the market, drafts brochures and flyers and organizes trade fair presentations and road shows. The MG Lift also supervised the building of a demonstration unit to show the functionality of the profile and the assemblies. In addition, the CiA independent website at www.canopen-lift.org maintains an open Wiki, where recommendations for new products, application notes and new functions can be discussed.

To check device interoperability, several meetings a year are held in the framework of SIG Lift (plugfests), in which – using checklists – the compatibility of devices in relationship to the standard and their functionality with other devices are examined. Elaborate and difficult stress tests are also conducted at the plug-fests. These inspect, for example, the behavior of devices at maximum permissible bus lengths or at maximum bus loading.

In case someone buys a new software version with minor change in between plug-fests, Böhnke + Partner connected several control systems with the Internet. After installing the appropriate driver, any manufacturer can connect a CANopen-Lift lift device – via the Internet – with these controls and examine the functionality of the assemblies.

Perspectives

We believe that in the future all devices will be fitted with standardized bus connectors. These devices can be analyzed and parameterized using all-purpose diagnostics tools.

Standardized networking in and among elevators also simplifies linkage to the building control center and to remote diagnosis capabilities via the Internet.

The capability to access many internal parameters in the individual devices gives rise to many new functions that, without this standard, would be very complex or not feasible at all.

Elevator safety is increased since redundancies arise and devices can monitor each other. In Pessral, for example, the safety-critical sensors and limit switches are replaced with electronic assemblies that offer far greater functionality and thus enhance elevator safety. If these systems are supposed to trade information, then they will have to be interconnected with a safe, non-proprietary bus. “CANopen Safety” makes available a standard used around the world.

Weblinks

• www.boehnkepartner.de
• CAN in Automation (CiA)