Model-driven development of CANopen components

From CANopen-Lift
Jump to navigation Jump to search

Author: Ansgar Meroth - Heilbronn University - Max-Planck-Str. 39 - D-74081 Heilbronn

Introduction

CANopen for Lifts, specified in CiA 417, has reached a maturity that allows fast development cycles, short integration times and easy maintenance. This article shows the usage of model based development methods and hardware-in-the-loop (HIL) testing for lifts, following well-known schemes from automotive engineering and transforming them for lifts. This work is based upon the modeling of a lift system by Matlab/Simulink, which later will be used as a HIL test bench. The paper discusses how conformity tests and integration tests can be conducted in the proposed environment. Furthermore a demonstrator lift is presented that takes advantage of the proposed ideas.

The histories of elevators and vehicles share several noteworthy commonalities.Cars started at the end of the 19th and the beginning of the 20th century as mechanical systems with electromechanical components – mainly ignition. Steam-driven lifts started to be employed in 1850, and were driven by electrical engines by 1880. In the 1970s,electronic components entered both worlds, first replacing single electromechanical parts, and in the 1990s, networking started to spread out so that complex and expensive wiring could be replaced. The next development step, however – model-driven development and automated integration and testing is rather further developed in the automotive industry, driven by cost and safety requirements.

Integration of lift components

In 2002, CiA 417 for lift control systems was specified in order to interconnect lift components with a common open interface. Many virtual devices have been created that add up to a complete lift system, such as an input panel unit, an output panel unit, a call controller, a car door unit, a car door controller, a light barrier unit, a car drive unit, a car drive controller, a car position unit, a load measuring unit, and a sensor unit. As a consequence, system specifications, system integration and maintenance can be performed by independent suppliers (Hellmich & Prof. Dr.-Ing. Ansgar Meroth others). The common open interface helps reduce development life cycles and time to market, especially in light of the challenging requirements of IEC 61508, the basic functional safety standard (International Electrotechnical Commission (IEC), 1998). These requirements have implications on the developing process, which challenge the integration of lift components in several ways. (Gutmann, 2010). The development of safety critical systems usually follows the V-model as shown in Figure 1. This approach would theoretically require a long development time since all the specifications are made with a top-down-approach, in which the test cases for integration and verification are also elaborated. Consequently,system integration and verification is performed in a bottom-up-process. Using well known common interface specifications on subsystem and component level can reduce the development efforts considerably by taking advantage of offthe- shelf components and a parallel integration process on the subsystem level as shown in Figure 2.

Each new component can be tested against the CiA 417 specification and integrated into a system that follows the standard and uses CANopen messages as interface. There is, however, a practical drawback, which is the fact that lifts need to be highly customized and individual. In other words, integrating and testing a new component would require the presence of the entire remaining lift system.