VERIFYING CONFIGURATION PARAMETER CHANGES IN AN ELEVATOR SAFETY SYSTEM

Abstract

A method of verifying configuration parameter changes in an elevator safety system includes detecting (100) a change in one or more of the configuration parameters stored in the memory; putting (102) the elevator system into an out-of-service mode; carrying out (104) a functional test of the elevator safety system to verify an appropriate safety action; and then putting (108) the elevator system back into an in-service mode.

Claims

1. A method of verifying configuration parameter changes in an elevator safety system (53), the elevator safety system (53) comprising: one or more safety nodes (42a-d, 44, 46, 48a-b), each arranged to monitor an input received from an associated safety sensor in an elevator system (20); a memory storing configuration parameters and a processor (52) with access to the memory; the processor (52) being arranged to access a stored configuration parameter of relevance to an input received at a safety node (42a-d, 44, 46, 48a-b) and to evaluate the input with reference to the configuration parameter; and the processor (52) being arranged to output an actuation signal (60,62) for one or more safety actions based on the evaluation of the input; the method comprising: putting the elevator system (20) into an out-of-service mode in response to detecting a change in one or more of the configuration parameters stored in the memory; in the out-of-service mode, carrying out a functional test of the elevator safety system (53) by moving an empty elevator car (22) under predetermined conditions and verifying that the processor (52) outputs an actuation signal (60,62) for an appropriate safety action under these predetermined conditions; and then putting the elevator system (20) back into an in-service mode.

2. The method of claim 1, comprising: automatically carrying out the one or more functional tests of the elevator safety system (53) and/or automatically verifying that the processor (52) outputs an actuation signal (60,62) for an appropriate safety action.

3. The method of claim 1, comprising: remotely verifying that the processor outputs an actuation signal for an appropriate safety action under these predetermined conditions.

4. The method of claim 1, comprising: sending an instruction from a remote computing device (70) to the elevator safety system (53) to put the elevator system (20) back into an in-service mode.

5. The method of claim 1, comprising: carrying out a plurality of functional tests of the elevator safety system (53), by moving an empty elevator car (22) in each functional test under predetermined conditions that are particular to each functional test.

6. The method of claim 1, comprising: upon completion of the functional test(s) of the elevator safety system (53) and upon verifying that the processor (52) outputs an actuation signal (60,62) for an appropriate safety action for each functional test, automatically putting the elevator system (20) back into an in-service mode.

7. The method of claim 1, comprising: carrying out a functional test of the elevator safety system (53) by moving an empty elevator car (22) downwards and checking that the processor (52) outputs an actuation signal for an appropriate safety action of a safety gear (28) or rope brake.

8. The method of claim 1, comprising one or more of: carrying out a functional test of the elevator safety system (53) by moving an empty elevator car (22) upwards and checking that the processor (52) outputs an actuation signal for an appropriate safety action of slowing down the elevator car when it approaches an upper terminal in a hoistway of the elevator system; carrying out a functional test of the elevator safety system (53) by moving an empty elevator car (22) upwards/downwards and checking that the processor (52) outputs an actuation signal for an appropriate safety action of stopping the elevator car when it passes a final limit in a hoistway of the elevator system; carrying out a functional test of the elevator safety system (53) by moving an empty elevator car (22) upwards and checking that the processor (52) outputs an actuation signal for an appropriate safety action relating to overspeed detection for an elevator car; carrying out a functional test of the elevator safety system (53) by moving an empty elevator car (22) upwards/downwards from a landing and checking that the processor (52) outputs an actuation signal for an appropriate safety action of preventing unintended car movement at a landing; carrying out a functional test of the elevator safety system (53) by moving an empty elevator car (22) upwards/downwards and checking that the processor (52) outputs an actuation signal for an appropriate safety action of designating an elevator car as a firefighter elevator car; carrying out a functional test of the elevator safety system (53) by moving an empty elevator car (22) upwards/downwards and checking that the processor (52) outputs an actuation signal for an appropriate safety action of locking or unlocking elevator car rear doors.

9. The method of claim 1, comprising: detecting a manual change in one or more of the configuration parameters stored in the memory.

10. The method of claim 1, comprising: detecting an automatic change in one or more of the configuration parameters stored in the memory.

11. The method of claim 1, comprising: detecting a change in one or more of the configuration parameters stored in the memory as a result of software running at the processor having been updated or replaced.

12. An elevator system (20) comprising: an elevator car (22) moving along a hoistway (34); an elevator controller (40), configured to control operation of the elevator car (22); and an elevator safety system (53) comprising: one or more safety nodes (42a-d, 44, 46, 48a-b), each arranged to monitor an input received from an associated safety sensor in the elevator system (20); a memory storing configuration parameters and a processor (52) with access to the memory; the processor (52) being arranged to access a stored configuration parameter of relevance to an input received at a safety node (42a-d, 44, 46, 48a-b) and to evaluate the input with reference to the configuration parameter; and the processor (52) being arranged to output an actuation signal (60,62) for one or more safety actions based on the evaluation of the input; wherein, during a process of verifying configuration parameter changes in the elevator safety system (53): the elevator controller (40) is configured to put the elevator system (20) into an out-of-service mode in response to detecting a change in one or more of the configuration parameters stored in the memory; in the out-of-service mode, the elevator controller (40) is configured to carry out a functional test of the elevator safety system (53) by moving an empty elevator car (22) under predetermined conditions and verifying that the processor (52) outputs an actuation signal (60,62) for an appropriate safety action under these predetermined conditions; and the elevator controller (40) or the elevator safety system (53) is then configured to put the elevator system back into an in-service mode.

13. The elevator system (20) of claim 12, wherein the elevator safety system (53) is arranged to verify that the processor (52) outputs an actuation signal (60,62) for an appropriate safety action.

14. The elevator system (20) of claim 12, wherein the elevator safety system (53) comprises a communicative connection with a remote computing device (70) and the remote computing device (70) is arranged to: verify that the processor (52) outputs an actuation signal (60,62) for an appropriate safety action; and/or send an instruction to the elevator safety system (53) to put the elevator system back into an in-service mode.

Description

DRAWING DESCRIPTION

[0047] An illustrative example of this disclosure will now be described with reference to the accompanying drawings, in which:

[0048] FIG. 1 is a schematic view of an elevator system according to an example of the present disclosure; and

[0049] FIG. 2 is a flow diagram for an exemplary method of verifying configuration parameter changes in an elevator safety system.

DETAILED DESCRIPTION

[0050] As shown in FIG. 1, an elevator system 20 comprises an elevator car 22 that moves in a hoistway 34 between various floors of a building. The elevator car 22 is suspended in the hoistway 34 by a tension member 26 (e.g. one or more ropes or belts). The other end of the tension member 26 is connected to a counterweight 24. However, it will be appreciated that in other examples the elevator system may be ropeless.

[0051] During an in-service mode, the elevator car 22 travels up and down in the hoistway 34 to transport passengers and/or cargo between floors of the building. The elevator car 22 is driven by a drive system 30 comprising a drive motor 32 and a motor brake 36. The tension member 26 passes over a drive sheave (not shown) that is driven to rotate by the drive motor 32 and slowed by the motor brake 36. Normal operation of the drive system 30 is controlled by an elevator controller 40. The elevator car 22 has a safety gear 28 that can be triggered to bring the elevator car 22 to an immediate standstill. Although not shown, the counterweight 24 may also include such a safety gear.

[0052] The elevator system 20 also comprises an absolute position determination system 50 configured to determine the absolute position and velocity of the elevator car 22 in the hoistway 34. In this example, the absolute position determination system 50 is configured to output a measurement of the absolute position and velocity of the elevator car 22 to the elevator controller 40. The absolute position determination system 50 can include a coded tape (not shown) extending at least part of the way along the hoistway 34 and at least one sensor (not shown) mounted on the elevator car 22 and arranged to read the coded tape to determine the absolute position and velocity of the elevator car 22 as it moves along the hoistway 34.

[0053] The elevator system 20 also comprises an elevator safety system 53, including a safety controller 52 connected to a data bus 54. The safety controller 52 may be a node as defined in the relevant Programmable Electronic System in Safety Related Applications for Lifts (PESSRAL) standard(s). The safety controller 52 communicates over the data bus 54 with a plurality of safety nodes 42a-d, 44, 46, 48a-b. The data bus 54 may be a CAN bus, and is represented in FIG. 1 with a dashed line.

[0054] The safety controller 52 of the elevator safety system 53 has a communicative connection with a remote computing device 70. It can be seen that the remote computing device 70 is outside the elevator system 20, and typically outside the building where the elevator system 20 is located. For example, the remote computing device 70 may be a cloud-based server (such as a building management server). The remote computing device 70 can be used to remotely verify functional tests that are carried out during an out-of-service mode. The remote computing device 70 can also send an instruction to the elevator safety system 53 when it is deemed appropriate to put the elevator system 20 back into an in-service mode.

[0055] The safety nodes 42a-d, 44, 46, 48a-b are each associated with a safety sensor located in the elevator system 20. In the particular example as shown, there are four safety nodes 42a-d for the landing doors, each corresponding to a safety sensor for the respective set of landing doors of the elevator system 20. There is a safety node 44 for the pit limit switch. There is a safety node 46 associated with a safety sensor for overspeed detection. The overspeed detection safety node 46 is connected to the absolute position determination system 50. There are also shown two safety nodes, 48a, 48b, associated with safety sensors of the elevator car 22. For example, there is an elevator car door safety node 48a and a safety node 48b for an emergency stop switch in the elevator car 22.

[0056] In this illustrated example, the safety controller 52 includes a memory storing configuration parameters and a processor with access to the memory. The processor is arranged to access a stored configuration parameter of relevance to an input received at a particular safety node 42a-d, 44, 46, 48a-b and to evaluate the input with reference to the configuration parameter. The safety controller 52 can then output an actuation signal 60, 62 for one or more safety actions based on the evaluation of the input

[0057] The safety controller 52 can output an actuation signal 60 to interrupt the supply of power to the drive system 30 to execute the safety action of an emergency stop. This actuation signal 60 can act independently of the elevator controller 40 being configured to control the drive system 30. The safety controller 52 simply allows or prevents movement of the elevator car 22, but cannot be used to move the elevator car 22 to a floor. It is the elevator controller 40 which issues a run command to the drive system 30, whether during normal operation in the in-service mode or when carrying out a functional test during the out-of-service mode.

[0058] In another example of a safety action, the safety controller 52 (e.g. acting as an electronic speed governor) can output an actuation signal 62 to trigger the safety gear 28 of the elevator car 22 when the elevator car speed is input to the overspeed detection safety node 46 and evaluated with reference to the rated speed.

[0059] In the in-service mode, an emergency stop of the elevator car 22 may be triggered based on an input received at any of the various safety nodes connected to the safety bus 54. For instance, if a landing door is opened (as detected by one of the safety nodes 42a-d), if a maintenance worker operates an emergency stop switch (as detected by safety node 48b), or the elevator car 22 travels too quickly (as detected by overspeed detection node 46), the safety action of an emergency stop may be actuated by the safety controller 52, for example by the actuation signal 60 interrupting the supply of power to the drive system 30. The loss of power triggers the motor brake 36 to engage and stops the motor 32 (i.e. removes any drive torque applied to the drive sheave). This brings the elevator car 22 (and the counterweight 24) quickly to a halt. However, this relies on the safety controller 52 correctly evaluating the input with reference to the stored configuration parameters, which may change during a software update or other configuration change.

[0060] During a process of verifying configuration parameter changes in the elevator safety system 53, the elevator controller 40 is configured to put the elevator system 20 into an out-of-service mode upon detecting any changes to the configuration parameters stored in the memory of the safety controller 52. Then the elevator controller 40 is configured to carry out a functional test of the elevator safety system 53 by moving the empty elevator car 22 under predetermined conditions and verifying that the safety controller 52 outputs an actuation signal 60, 62 for an appropriate safety action under these predetermined conditions. After completing the functional test(s), the elevator controller 40 or the elevator safety system 53 is then configured to put the elevator system 20 back into an in-service mode. This may be initiated automatically or upon receiving an instruction from the remote computing device 70.

[0061] There is illustrated in FIG. 2 an exemplary method of verifying configuration parameter changes in an elevator safety system, which may have the architecture seen in FIG. 1 or any other suitable architecture. The steps 100-108 take place sequentially in the following temporal order. A first step 100 comprises detecting a change in one or more of the configuration parameters stored in the memory. A second step 102 comprises putting the elevator system into an out-of-service mode. A third step 104 comprises carrying out a functional test of the elevator safety system to verify an appropriate safety action. Verification may take place automatically (e.g. by the elevator safety system 53 itself) or remotely (e.g. by the remote computing device 70). The functional test may involve moving an empty elevator car under predetermined conditions and verifying that the processor outputs an actuation signal for an appropriate safety action under these predetermined conditions. An optional fourth step 106 is to repeat the same functional test as necessary and/or carry out one or more further functional tests of the elevator safety system. Only once there is a positive verification outcome from step 104 (and step 106 where this applies) does the process continue to the final step 108 which comprises putting the elevator system back into an in-service mode.

[0062] It will be appreciated by those skilled in the art that the disclosure has been illustrated by describing one or more specific examples thereof, but is not limited to these examples; many variations and modifications are possible, within the scope of the accompanying claims.