Lift Controllers Schinder
Elevator
Bus systems in lift technology are nothing new — but components used to be tied to manufacturer-specific protocols and could not be combined freely into a complete system. CANopen Lift (CiA 417) standardizes this communication on top of CANopen. For Janzhoff Aufzüge I developed the complete device software of a controller on that bus — from the bootloader and the firmware to the device description.
The device had to integrate as a CiA 417 device into a lift control system built by a different manufacturer — interoperability was not a bonus, it was the premise. On top of that came the constraints of an embedded system: a 16-bit microcontroller without an operating system, tight RAM and fixed timing requirements in the main loop.
Two requirements shaped the architecture in particular. First, the software had to be updatable in the field without a service engineer attaching a programming device. Second, in a service case it had to be possible to reconstruct what had happened on the bus and inside the device — over weeks, and across device boundaries.
Two-stage software architecture. Bootloader and firmware are separate programs with their own version identifiers in separate flash areas. The bootloader carries a purpose-written, minimal CANopen slave — just enough for network management and SDO transfer. It receives the new firmware via segmented SDO transfer over the CAN bus, validates it and only then jumps into it. An update needs neither a programming device nor opening the enclosure.
CANopen Lift in the firmware. The application identifies itself through object 1000h as a device of the CiA 417 lift profile. Process data, mapping and device identity are described in an EDS file according to CiA 306, which doubles as the interface document towards the control system manufacturer. A commercial CANopen slave stack handles the communication layer, complemented by heartbeat monitoring in both directions.
A common time base. The device’s real-time clock synchronizes to the time stamp the lift controller places on the bus. This makes log entries from different devices in the same installation comparable — the prerequisite for narrowing down a sporadic fault at all.
Diagnostics built in. Events are written with a time stamp to an SD card using a FAT file system and can be analysed at the desk. A test and diagnostics menu on the serial interface additionally shows states, inputs and outputs and the measured cycle time of the main loop live.
Systematic design. The behaviour of each functional block was modelled and documented as a state machine before a single line of code was written. The stateful parts are covered by unit tests.
Lift components from different manufacturers can now be combined freely instead of being tied to a proprietary bus. Configuration is stored on the module, jumpers are gone, and software updates run over the CAN bus — noticeably shortening commissioning and servicing.
Because every device logs its events on a synchronized time base, faults can be reconstructed across the entire installation afterwards instead of having to be reproduced on site.
The experience from this project went into CANoopEn, our open source CANopen stack in modern C++, which supports the CiA 417 lift application profile alongside CiA 301.
