Standardized networking for elevator components based on CiA-417 Lift Control
by Jörg Hellmich, Böhnke + Partner GmbH (www.boehnkepartner.de, now c/o elfin.de)
Technical systems are, in general, becoming ever more complex. Electronic systems – usually equipped with tiny embedded microprocessors – are implementing new functions, increasing convenience or improving system safety and reliability. Responding to signals made provided by sensors or arriving at inputs, these processors employ the algorithms written in the internal firmware to determine what the assembly actually does. The more information available about the system, the broader the basis upon which decisions can be made.
In order for the electronic assemblies in a system to interact with each other properly and exchange internal information or commands, they have to be connected one with another by way of a field bus. Various types of field bus, with differing properties, are used in the automation industry.
A number of proprietary buses are used in the elevator industry along with the standardized CANopen-Lift field bus (as per the CiA-417 application profile).
This article introduces the basic structure, the properties and the advantages of the latter in comparison with proprietary systems and provides an insight into the organizational structure of the developer community behind the system.
This is followed by a description of functions that become possible only with open networking among components built by different manufacturers. Finally, perspectives for coming developments will be described.
Elevators are becoming ever more complex. More and more electronic devices are being installed in elevators 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 are usually hard at work inside these electronic devices. Responding to input signals or sensor data, these microprocessors generate output signals or messages. The nature of the signals and when they are emitted are determined on the basis of algorithms written in the internal firmware. Thos algorithms determine which functions the assembly carries out. The more information is available in regard to the system as a whole, the broader the basis upon which decisions can be made.
To make it possible for the electronic assemblies in a system to work together and exchange internal information or commands they will have to be connected with each other by way of a field bus.
Pursuant to the adoption of the EN 81 standard, all newly installed or modernized elevators must have a telephone connection for emergency calls. This line is, however, usually reserved exclusively for use by the emergency calling device. Thus, for example, a door control device cannot use the telephone connection already on hand to send along malfunction reports or maintenance information. The emergency call unit could, indeed, transmit such communications but it knows nothing about the internal fault in the door control device.
A technician will learn about the malfunctioning device only when a passenger – possibly one who is trapped – calls in a complaint. The technician must then go immediately to the site and troubleshoot the elevator there.
This situation would be improved if the door controller and the emergency call unit were able to communicate with each other.
Communication [Latin: communicare] sharing, notifying, allowing participation, doing something together, joining
Interruptions in communication
During communication activities an encoded message with a defined character set is transported through a certain medium from a sender to a receiver; this is followed by encoded feedback to the sender. Communication transpires within a certain context.
A variety of external influences can interfere with communication. This makes it necessary to integrate mechanisms that can recognize a message error and, if necessary cause that message to be sent again.
Elements in communication
In order to be able to communicate with each other, we require:
- a verbal or nonverbal language or protocol
- a transmission medium or communication channel
- communication rules
- perhaps a discussion leader/moderator/master
Types of communication
Depending on the number of elements participating in communications, one differentiates among the following communication types.
One device or participant sends messages and at least one participant receives the messages and emits a response.
Two participants send encoded messages to each other.
Many participants send messages to each other. This latter type of communication, among humans, has proven to be impractical since too many messages would be disrupted.
Multi-master communications are possible in technical systems without the messages being corrupted. The principle of prioritized messages will be used here, for instance.
In this type of communication several units can each start sending a message through a transmission medium. An identifier included as a prefix to the message is used to determine which message has the highest priority. The message with the highest priority will be sent, right after the identifi er, without delay. Lower-priority messages will be postponed.
This procedure prevents message corruption. Real-time communications are possible.
Technology in the elevator
Survey of various bus systems
To enable electronic devices in an elevator to communicate with each other, a field bus will have to be provided to connect them.
There are currently several field bus systems – with varying technical properties – being used widely in the industry. Thus there are low-bandwidth systems that can transmit just a few messages over great distances. Others, with great bandwidth, can transmit large volumes of data across short distances. Depending on the needs of the system in which a field bus system is to be employed, the designer will select the field bus with the best properties for the particular application.
|Vehicles, robots, machines
|Internet, building automation, production systems
Advantages and disadvantages
After an extensive analysis of the various systems, many European components manufacturers have decided on the CAN concept as the field bus to be used in elevators.
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.
Basing on the CAN bus, a joint language was developed for standardized communication. The designations CANopen-Lift and CANopen CiA-417 are used.
The CANopen-Lift application profile
Work on the application profile commenced in 2001. In the summer of 2003 Version 1.0 was adopted and in October of that same year prototypes of the first products were to be seen at the Interlift.
The application profile is designated CANopen-Lift or CiA 417 V2.0. The profile describes an application with
- a group of eight elevators,
- 254 landings
- and 4 doors per car.
Moreover, all the devices that can be used within this application are defined as “virtual devices”. The functions of the “virtual devices” are then described, along with all the messages these devices can generate and/or receive.
Associated with the profile are various regulations and supplementary recommendations. Thus, for instance, various plug connectors are recommended for use with elevator components. Pin assignment for the plugs is, however, prescribed and mandatory. It is also recommended that the device interfaces be equipped with a status indicator LED. If an LED is present, then its blinking patterns are standardized to signify various status reports.
There are also recommendations for the colors of the conductors used in the bus line, for the structure of the topology for networking the components, for the assignment of node IDs, for the baud rate or auto-baud functions, software updating procedures in the components and much, much more.
This insures on the one hand that the components using the bus are as compatible as possible and that maximum plug-and-play capability will be achieved. On the other hand, the component manufacturers and elevator engineers enjoy great flexibility in designing individual and unique features. Standardization is referenced exclusively to the communications among components attached to the system bus. The functions of the devices are not described. This continues to be within the domain of the manufacturer’s know-how.
The principle of virtual devices
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 CiA-417 CANopen application profi le for elevator controls, for example, defines direct PDO connections that link the elevator door and the door controls.
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. Here is an example to further illustrate the principle behind the virtual devices. Two manufacturers of position sensors equip their devices with a CANopen-Lift interface. One manufacturer’s system is a rotary encoder that incrementally resolves a change in angle. If the circumference of the driving gear, sprocket or sheave is known, then the change in position can be calculated. The second manufacturer develops a linear encoder in which the lag time of a pulse is used to determine directly the distance to a reference point.
Both manufacturers implement a virtual device, the “position unit”, in their encoders and thus both units impress the same information on the bus: the position of the car, its velocity and, as an option, its acceleration, as well.
From the viewpoint of the overall elevator system, how position is determined is of no importance. The controls, the frequency inverter, diagnostics tools and displays need only know the position and velocity values for the car.
The virtual devices principle yields a number of advantages. For one thing, a rotary encoder can be substituted for a linear encoder should the latter not be available for delivery or if technical considerations require this change. Additionally, other devices need know nothing about the nature or technical properties of the encoder. They can nonetheless access and use the position information. A display manufacturer, for instance, will program the display so that the position information from a virtual device – the “position unit” – will be shown. If virtual a device of this type is present in the elevator, then the position data can be shown without the display manufacturer ever having to see the encoder.
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 elevator manufacturer, for instance, can use separate CANopen networks for car control and for the control panels inside the hoist-way.
One major problem associated with bus systems in the past was the capability to carry out diagnostics work. Here the application profile offers a wide variety of possibilities.
Firstly, one can naturally equip each device with a status LED or a display, as is typical for conventional systems. The disadvantage here is, however, that an integrated display involves costs and the technician has to be present on site, at the device, 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, as is possible in the DCP protocol. Additionally, the menu of each individual device can be shown at every other device equipped with a display. This need not necessarily be an elevator component. This technology also makes it possible to show the menu on a cell phone that accesses the CAN bus via Bluetooth, for instance. It may also be shown using diagnostics software running on a laptop.
If the technician has a laptop, then there are far better diagnostic possibilities. Since the parameter sets are standardized, all the devices connected to the bus can be parameterized with a single, uniform tool.
Diagnoses with a laptop
If a laptop is available for diagnosis and configuration work, then there are many and very convenient options to choose from.
Given the fact that the communications and the parameters sets for all the devices are standardized, it is possible, with a single software program, to parameterize all the devices in an elevator. One universal-use configuration tool of this type is the “CANwizard®” software, which is already being used by many manufacturers.
Once the laptop has been joined with the system bus by way of an adapter available on the commercial market, 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, including all the parameters, can be archived. The parameter data records in storage can be used to configure lifts of a similar design or to facilitate configuration of a replacement part. Additionally, the parameter data records can be used by a system’s operator or by a certified surveillance agency to detect manipulations in parameters. This makes it simple to determine whether any relevant parameters have been changed after commissioning and acceptance.
Programs are never entirely error-free and today the functions of any given assembly are determined by internal firmware. This frequently makes it necessary to update the software in an assembly.
The CANwizard® makes it possible to execute a software update, using a standardized procedure, for one or more assemblies, regardless of which manufacturer built the units. This can be used with modern LCD displays, for example, to change the depiction to match current needs, and that can be done with just a few mouse clicks. It would also be possible to update audio files in annunciator modules.
One major problem with technical systems networked using a proprietary bus system is the extent to which it supports diagnostics activities. The technician on site has to rely on the status reports issued by a just few assemblies.
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 elevator 1” or “Limit switch A, elevator 1, open” or “Position 18.2356 m, velocity 0.832 m/s, acceleration 0 m/s” – 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. Elevator functions taking place sequentially can be examined using plain text or graphs. This is an option that would not be possible without a standardized procedure.
Management functions for EDS files
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 such as the baud rates the device supports. 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. Additional devices can be added using an import function.
No software program can ever take account of every conceivable function and particularly in the case of software not associated with a given manufacturer it is not desirable that competitors have access to internal know-how concerning certain functions. That is why it has become customary to equip programs with interfaces to accept add-ons that expand the program’s functions.
CANwizard® is fitted with an interface like this and lets manufacturers write their own add-ons in order to parameterize their own devices.
Staying up to date
It is very important to be able to regularly modify the scope of a diagnostics tool’s functions to reflect current standards and the functions of devices on the market. A continuous development process for CANwizard® ensures this. Employing an online update function, users can be sure they always have the latest version of the software.
A major release for the software is issued when each new version of the standard is published. It takes account of changes in the standard.
The developers of tools intended to work with devices made by any of a number of manufacturers has to build confidence in their products. One vital factor here is 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.
Not associated with any manufacturer
CANwizard® is available to every engineer and developer of CANopen devices and is also employed by universities and manufacturers in production process.
In an age when the Internet is ubiquitous, it quite natural to offer this functionality not just on site, at the elevator, but also at remote locations.
If the elevator is linked to the Internet via a suitable gateway, then all the functions can be executed remotely as soon as the PC is connected with the Internet and authorization has been verified.
Some organizational questions had to be clarified when standardization work commenced. The objective was to define a standard 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 CAN in Automation (CiA) organization. This impartial, non-profit organization has its head offices in Nürnberg and locations in the most important markets around the world.
The CiA takes responsibility for standardization work, organizes training sessions on CANopen, certifies devices, disseminates information at trade fairs and does much, much more.
Work for elevators is done in two areas within CiA. The “Special Interest Group Lift” (SIG Lift) is made up of developers who define new functions, work out the protocol, and test and certify devices.
The “Marketing Group Lift” provides information about the protocol and the devices on the market. It was under the supervision of the MG Lift that a demonstration unit was built to show the functionality of the profile and the assemblies. Additionally, MG Lift drafts brochures and flyers and organizes trade fair presentations and road shows.
In order to standardize a non-proprietary protocol in this fastmoving world, and always keeping that protocol up to date, it is necessary for the following conditions to be fulfilled for standardization work:
Several platforms are available in the Internet intended to achieve this. On the one hand the CiA makes a content management system available on its Web site, by way of which the members can exchange information, both internally and externally.
On the other hand, the Web site at www.CANopen-Lift.org maintains an open Wiki where recommendations for new products, application notes and new functions can be discussed.
The members of SIG Lift meet twice a year to expand the specifications and – usually in a lively exchange of information – to discuss new functions that are to be included in the specifications in the future.
So much for the theory involved in preparing a standard. But at some point it is necessary to develop the corresponding devices and examine interoperability.
To check device interoperability, regular meetings are held in the framework of SIG Lift (Plug Fests), in which – using checklists – the compatibility of devices in relationship to the standard and their functionality with other devices are examined. If a device successfully satisfies all the items in a checklist, then this is something like a certificate as per the standard at that particular point in time.
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. These tests are very elaborate and it would be quite difficult for any individual manufacturer to conduct them.
The Plug Fests are held several times a year, but one would not want to wait until the next Plug Fest to market a new software version with only a minor change.
That is why Böhnke + Partner connected several control systems, via a gateway, with the Internet. After installing the appropriate driver, any manufacturer can connect a CANopen-Lift elevator device – via the Internet – with these controls and examine the functionality of the assemblies.
Where are these standardized specifications for inter-component communications in an elevator likely to lead us? 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. As of 2005 PESSRAL (Programmable Electronic System in Safety Related Applications) has been an annex to EN 81 1/2. In PESSRAL 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.
Again and again new field bus systems appear on the market while others disappear. Systems based on fiber optics or radio technologies might well come on the scene in the future. At present some larger manufactures are attempting to render Ethernet-based systems suitable for real-time use and to establish them as field bus systems. These systems are not compatible with each other and are usually forced onto the market only by a single, mighty manufacturer. The most “open” system is Powerlink, which can run on standard Ethernet hardware. Here, again, there are still many problems to be solved. Once the hardware and message transport layers have been clarified, the parameter sets for devices and applications will still have to be defined. There is an agreement between Powerlink and “CAN in Automation” that the object dictionary for devices and applications may also be used for Powerlink. Anyone who already uses CANopen-Lift today is fully equipped for the future.
A further simplification arises almost coincidentally from standardization. Many elevator and component manufacturers use different designations or names for the same thing. Defining messages and parameter sets encourages the use of uniform terminology. Operating levels and menu prompts in devices made by different manufacturers are becoming more similar. Service technicians on site and the employees at certified surveillance agencies thus find it easier to deal with differing systems.
The following is a brief listing of sources that may be used to delve further into the subject:
- BÖHNKE + PARTNER GmbH www.boehnkepartner.de
- CAN in Automation Organization www.can-cia.org
- CANopen-Lift-Wiki www.CANopen-Lift.org
- Configuration software www.CANwizard.de
- Information on Powerlink de.wikipedia.org/wiki/Ethernet_Powerlink