ELEVATOR SYSTEM AND METHOD FOR RESTORING OPERATION OF AN ELEVATOR CAR

Abstract

An elevator system includes an elevator car, an elevator controller, a safety controller and a plurality of safety contacts connected to the safety controller, wherein the plurality of safety contacts monitor the elevator system. The safety controller is configured to receive individual status information from each of the plurality of safety contacts and to prevent movement of the elevator car when the individual status information received from one of the plurality of safety contacts indicates an unsafe condition of the elevator system. The safety controller is configured to connect to a remote computing device, to receive first authentication information from the remote computing device, and to authenticate the remote computing device if the first authentication information meets an authentication condition. If the remote computing device is authenticated, to permit the remote computing device to override the safety controller to enable movement of the elevator car.

Claims

1. An elevator system (20), comprising: an elevator car (22); an elevator controller (40), configured to control operation of the elevator car (22); and a safety controller (52) and a plurality of safety contacts connected to the safety controller (52), wherein the plurality of safety contacts monitor the elevator system (20), wherein the safety controller (52) is configured to receive individual status information from each of the plurality of safety contacts and to prevent movement of the elevator car (22) when the individual status information received from one of the plurality of safety contacts indicates an unsafe condition of the elevator system (20); wherein the safety controller (52) is configured to connect to a remote computing device (64), to receive first authentication information (500) from the remote computing device (64), and to authenticate the remote computing device (64) if the first authentication information (500) meets an authentication condition; and if the remote computing device (64) is authenticated, to permit the remote computing device (64) to override the safety controller (52) to enable movement of the elevator car (22).

2. The elevator system (20) of claim 1, wherein the safety controller (52) is configured to receive an override command from the remote computing device (64) before enabling movement of the elevator car (22).

3. The elevator system (20) of claim 1, wherein the elevator controller (40) is configured to connect to the remote computing device (64), to receive second authentication information (600) from the remote computing device (64), and to authenticate the remote computing device (64) if the second authentication information (600) meets an authentication condition.

4. The elevator system of claim 3, wherein the elevator controller (40) is configured to receive an action command from the remote computing device (64) and to control operation of the elevator car (22) to carry out an action in response to the action command following authentication.

5. The elevator system of claim 3, wherein the elevator controller (40) is configured to receive the individual status information received from the safety contact that has indicated an unsafe condition and to send the individual status information to the remote computing device (64) following authentication.

6. The elevator system of claim 1, wherein the elevator system further comprises a position determination system (50) arranged to provide elevator car position information to the elevator controller (40) and/or safety controller (52), wherein the elevator controller (40) and/or safety controller (52) is configured to send the elevator car position information to the remote computing device (64) following authentication.

7. A remote control system comprising the elevator system of claim 1 and further comprising: a remote computing device (64) on which is stored first authentication information (500), wherein the remote computing device is located remotely from the elevator system (20) and configured to connect to the elevator system (20) via a communications network.

8. The remote control system of claim 7, wherein second authentication information (600) is stored on the remote computing device (64), the remote computing device (64) being configured to be authenticated by the elevator controller (40) using the second authentication information (600).

9. The remote control system of claim 7, wherein the remote computing device (64) is configured to asymmetrically encrypt the first authentication information (500).

10. A method of restoring operation of an elevator car (22) in an elevator system (20), when a safety controller (52) is preventing movement of the elevator car (22) since the individual status information from one of a plurality of safety contacts, received by the safety controller (52), indicates an unsafe condition of the elevator system (20), wherein an elevator controller (40) controls operation of the elevator car (20); the method comprising: the safety controller (52) establishing a connection with a remote computing device; the remote computing device (64) sending first authentication information (500) to the safety controller (52); the safety controller (52) checking whether the first authentication information (500) meets an authentication condition; and if the first authentication information (500) meets the authentication condition, authenticating the remote computing device (64); and if the remote computing device (64) is authenticated, permitting the remote computing device (64) to override the safety controller (52) to enable movement of the elevator car (22).

11. The method of claim 10, further comprising: the remote computing device (64) sending an override command to the safety controller (52); and the safety controller (52) receiving the override command before enabling movement of the elevator car (22).

12. The method of claim 10, further comprising: the remote computing device (64) sending second authentication information (600) to the elevator controller (40); the elevator controller (40) checking whether the second authentication information (600) meets an authentication condition; and if the second authentication information meets the authentication condition, authenticating the remote computing device (64).

13. The method of claim 11, further comprising: the remote computing device (64) sending an action command to the elevator controller (40); and the elevator controller (40) controlling operation of the elevator car (22) to carry out an action in response to the action command following authentication.

14. The method of claim 10, further comprising: the remote computing device (64) encrypting the first authentication information (500) using a public key (502) and the safety controller (52) decrypting the first authentication information (500) using a private key (504) stored on the safety controller (52).

15. The method of claim 10, further comprising: the remote computing device (52) sending the first authentication information (500) to the safety controller (52) over a wireless network.

Description

DRAWING DESCRIPTION

[0032] Certain preferred examples of this disclosure will now be described, by way of example only, with reference to the accompanying drawings, in which:

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

[0034] FIG. 2 is a schematic diagram showing a safety system and associated components, according to an example of the present disclosure;

[0035] FIG. 3 is a flow diagram showing a method of rescuing trapped passengers following an emergency stop of an elevator car, according to the prior art;

[0036] FIG. 4 is a flow diagram showing a method of rescuing trapped passengers following an emergency stop of an elevator car, according to the present disclosure; and

[0037] FIG. 5 is a schematic drawing representing an authentication request according to an example of the present disclosure.

DETAILED DESCRIPTION

[0038] As shown in FIG. 1, an elevator system 20 comprises an elevator car 22 that runs 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. The elevator car 22 and the counterweight 24 are moving components in the elevator system 20. However, it will be appreciated that in other examples the elevator system may be ropeless.

[0039] During normal operation, 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 braked by the motor brake 36. Normal operation of the drive system 30 is controlled by an elevator controller 40.

[0040] The elevator system 20 also comprises an absolute position measurement 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 measurement system 50 is configured to output a measurement of the absolute position and velocity of the elevator car 22 to the elevator controller 40. In other examples, the absolute position measurement system 50 may be connected to a safety controller 52 (described in more detail below), as well as or instead of its connection to the elevator controller 40. In such examples, the absolute position measurement system 50 can include a coded tape (not shown) extending at least part of the way along the hoistway 34 and two sensors (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 in the hoistway 34.

[0041] The elevator system 20 also comprises a safety system 53, including a safety controller 52 connected to a safety bus 54. As mentioned above, the absolute position measurement system 50 may also (or alternatively) be connected to a safety controller 52 over the safety bus 54, and may also (or alternatively) supply the position and velocity information to the safety controller 52.

[0042] 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 safety bus 54 with a plurality of bus nodes 42a-d, 44, 46, 48a-b. The safety bus 54 may be a CAN bus, and is represented in FIGS. 1 and 2 with a dashed line.

[0043] The bus nodes 42a-d, 44, 46, 48a-b are each associated with one of a plurality of safety contacts located throughout the elevator system 20. In the particular example as shown, there are four landing door nodes 42a-d, each corresponding to a respective set of landing doors of the elevator system 20. There is a pit switch node 44, which is associated with a safety contact in the pit of the elevator system 20. This safety contact may be opened by a maintenance person when they are working in the pit. There is an overspeed node 46, associated with an overspeed switch or safety contact which detects an overspeed condition of the elevator car, and opens if an overspeed is detected. The overspeed node 46 is connected to the absolute position measurement system 50. There are also two nodes, 48a, 48b, associated with the safety contacts of the elevator car 22. In particular, there is an elevator door node 48a, connected to a door sensor, and an emergency stop node 48b.

[0044] The safety system 53 is shown in greater detail in FIG. 2, together with associated components. It can be seen that each of the nodes 42a-d, 44, 46, 48a-b is connected to at least one of the safety contacts 41a-41h, as described above. The safety system 53 also includes an actuator node 56, connected to the safety bus 54. If required, the actuator node 56 can interrupt the supply of power to the drive system 30 to execute an emergency stop, as described below. It will be understood that the actuator node 56 in the safety system 53 is configured to interrupt operation of the drive system 30 (e.g. upon detection of an unsafe condition) independently of the elevator controller 40 being configured to control the drive system 30 during normal operating conditions. Actuator node 56 simply allows or prevents movement of the elevator car 22, but cannot be used to drive the elevator car 22 to a floor. It is the elevator controller 40 which issues a run command to the drive system 30.

[0045] The safety bus 54 also connects the safety controller 52 to a wireless communications gateway 60, by means of which the safety controller 52 can wirelessly connect with a server 62 and further with a remote computing device 64 connected to said server 62, as described below.

[0046] The safety bus 54 is also connected to the elevator controller 40, such that the elevator controller 40 receives individual status information from the safety system 53, indicating the status of each of the safety contacts 41a-41g, i.e. whether each safety contact is open or closed. Thus, the safety controller 52 monitors and evaluates the individual status of each safety contact, but this information is also provided to the elevator controller 40 to facilitate maintenance work, e.g. by displaying the status of the individual safety contacts, or the overall safety chain, on devices in the elevator system.

[0047] At any point during normal operation an emergency stop of the elevator car 22 may be triggered, based on information obtained from the various nodes connected to the safety bus 54. For instance, if a hoistway door is opened (as detected by nodes 42a-d), if a maintenance worker is present in the pit of the hoistway (as detected by node 44) or, the elevator car 22 travels too quickly (as detected by overspeed node 46) an emergency stop may be executed, e.g. by interrupting the supply of power to the drive system 30 using the actuator node 56. The loss of power triggers the 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.

[0048] Once the safety controller 52 has been triggered in this way, it is known for the elevator system to be configured such that the safety system 53 cannot then be overridden, and therefore movement of the elevator car restored, until a maintenance person attends the elevator system 20, in person, inspects the elevator system 20, and manually overrides the safety controller 52. In some cases passengers are inside the car when the emergency stop is carried out, and will therefore become trapped if the car is stopped between landings. Override of the safety controller 52, in order to allow the car to be moved to a landing, is required in order to rescue such trapped passengers.

[0049] Such a known prior art method of rescuing trapped passengers following an emergency stop of an elevator car is described with reference to FIG. 3.

[0050] The method is carried out between a passenger or passengers 200 (who are trapped in an elevator car following an emergency stop) and a maintenance person or mechanic 202, who attends the elevator system physically in person to carry out a manual override of a safety controller 252. The method is carried out by communications between these two parties, by means of an elevator controller 240, the safety controller 252, and an elevator service 204 (where the server 62 is hosted for communication with the elevator controller 240 and the safety controller 252).

[0051] Initially, at step 210, the passenger is using the elevator car during normal operation. Then a signal at one of the bus nodes causes the safety controller 252 to provide a signal to the elevator controller 240, at step 212, which prevents movement of the elevator car. This causes the elevator car to undergo an emergency stop, which results, at step 214, in passengers becoming trapped. Passengers 200 then sound an alarm within the elevator car, which causes an alarm signal to be sent to the elevator service 204 at step 216. This elevator service 204 then signals a mechanic 202 at step 218.

[0052] Then, at step 220, as a result of receiving the signal, the mechanic 202 visits the elevator system. Once present locally on site, the mechanic 202 requests elevator status details from the elevator controller 240 at step 222. In response, at step 224, the elevator controller 240 responds by providing the status details of the elevator system.

[0053] These status details allow the mechanic 202 to identify which of the safety contacts needs to be bypassed in order to enable movement of the elevator car. Then, at step 226, the mechanic 202 informs the passengers 200 of the rescue operation via a speaker in the car, by means of the elevator controller.

[0054] At step 228 the mechanic 202 manually bypasses the safety contact which has triggered the emergency stop, where the mechanic has determined that it is safe to do so, and, at step 230, manually activates an emergency electrical operation of the elevator car.

[0055] Once the safety chain is bypassed, the mechanic is then able to manually run the car in an up or down direction, at step 232, using manual controls of the elevator controller 240, until the car arrives at a landing of the elevator system, at step 234. Once the car arrives at a landing, the mechanic 202 terminates the manual run command, at step 236, and manually opens the landing doors of the elevator car, at step 238.

[0056] Once the elevator doors are opened the passengers are able to exit the elevator car, and are therefore rescued (at step 242). Once the rescue operation is complete, the mechanic 202 then removes the bypass of the safety contact, at step 244. This process is time consuming since it requires a mechanic to physically attend the elevator system, and also requires a large amount of manual intervention by the mechanic.

[0057] It is desirable that trapped passengers can be recovered as quickly and conveniently as possible, whilst also maintaining the safety and security of the elevator system. A method of rescuing trapped passengers following an emergency stop of an elevator car according to the present disclosure is shown in the flow diagram of FIG. 4.

[0058] The method is carried out between a passenger or passengers 300 (who are trapped in the elevator car 22 following an emergency stop) and a maintenance person or mechanic 302, who is using a remote computing device 64 (shown in FIG. 2). The method is carried out by communications between these two parties, by means of the elevator controller 40, the safety controller 52, and an elevator service 304.

[0059] Initially, at step 310, the passenger is using the elevator car during normal operation. Then a signal at one of the bus nodes causes the safety controller 52 to detect an unsafe condition and provide a signal to the actuator node 56 to interrupt the supply of power to the drive system 30, which prevents movement of the elevator car 22. Then, at step 312, the safety controller 52 will also notify the elevator controller 40 of the new status of the elevator system. The prevention of movement of the elevator car 22 causes the elevator car 22 to undergo an emergency stop. This results, at step 314, in passengers becoming trapped. Passengers 300 then sound an alarm within the elevator car 22, which causes an alarm signal to be sent to the elevator service 304 at step 316. This elevator service 304 then signals a mechanic, 302 at step 318.

[0060] At step 320, rather than physically attending the elevator system as in the prior art method described above, the mechanic 302 instead remotely accesses the elevator system, more specifically the safety controller 52 itself, as described below.

[0061] The remote computing device 64 first (or prior to the beginning of this method) establishes a data connection with an Otis server 62, as represented by the dashed line between the remote computing device 64 and the Otis server 62 in FIG. 2.

[0062] The Otis server 62 can communicate wirelessly, e.g. by means of respective antennae, with the gateway 60 which is connected to the safety bus 54 and therefore to the safety controller 52 and the elevator controller 40]. Thus the remote computing device 64 is able to communicate (e.g. exchange data and/or commands with) the safety controller 52, and the elevator controller 40.

[0063] At step 322, the mechanic 302 transmits a request to the elevator controller 40, via the wireless data connection to the gateway 60, requesting information about the elevator system 40, for example including the position of the elevator car and/or the status of each individual safety contact connected to the safety controller 52. The information may also include a variety of other information which is useful for elevator maintenance, for example a derived safety status of the elevator system (e.g. operation mode, or blockage conditions etc.), and other safety-related information not based on the safety contacts, e.g. relating to brake behaviour.

[0064] In order to ensure that such status information is not transmitted to a third party who is not entitled to access the information, e.g. a hacker, the elevator controller 40 requires the remote computing device 64 to undergo, and successfully pass, an authentication process, so that the information is only transmitted to authorised parties. To start this process, at step 323, the elevator controller 40 transmits a signal back to the remote computing device 64 indicating to the mechanic 302 that authorisation is required.

[0065] Then, at step 325, the mechanic 302 responds by providing authentication information to the elevator controller, in a process which is described in greater detail with respect to FIG. 5. The elevator controller 40 checks this information, as described below, and, if authentication is successful, sends a response to the remote computing device 64 at step 324, indicating that authentication of the remote computing device 64 has been granted, and providing the requested status information to the mechanic 302.

[0066] Based on the received information the mechanic 302 is then able to make an informed decision as to whether override of the safety controller 52 is required, e.g. if the elevator car is located between landings and so must be moved to a landing in order to allow passengers to exit, and also whether overriding of the safety controller 52 is a safe decision. If the mechanic 302 decides that override of the safety controller 52 is required, the method then proceeds as described below.

[0067] At step 326, the mechanic 302 informs the passengers 300 of the rescue operation via a speaker in the car, by means of the elevator controller 40.

[0068] In order to move the elevator car, the safety controller 52 must be overridden. Previously, a bypass was carried out by a maintenance person locally present at the elevator system, as described above, and therefore conventional security, e.g. security guards present at building entrances, prevent access of unauthorised parties. In the present method, the safety system 52 is accessible remotely by means of a wireless connection. Therefore, in order to ensure that only an authorised person is able to override the safety controller 40, authentication of the remote computing device 64 used by the mechanic 302, to the safety controller 52 is required. The remote computing device 64 must authenticate to the safety controller 52, separately to the authentication to the elevator controller 40 which is described above.

[0069] In a first step 350 the mechanic 302 sends an override command to the safety controller 52, instructing the safety controller 52 to re-enable movement of the elevator car, i.e. to override the safety contact which was opened to trigger the emergency stop. The safety controller 52 then sends a response to the remote computing device 64, at step 352, indicating the mechanic 302 that authorisation is required.

[0070] Then, at step 354, the mechanic 302 responds by providing authentication information to the safety controller 52, in a process which is described in greater detail with respect to FIG. 5. The safety controller 52 checks this information, as described below, and, if authentication is successful, sends a response to the remote computing device 64 at step 356, indicating that authentication of the remote computing device 64 has been granted. The safety controller 52 then executes the override command, so that movement of the elevator car 22 is once again enabled, despite a safety contact being open, and sends a signal at step 358 to the remote computing device 64, indicating that the override command has been executed.

[0071] Movement of the elevator car 22 is therefore once again possible. The elevator car may automatically move itself to the nearest landing, without specific instruction from the mechanic 302. Alternatively, as shown in FIG. 4, at step 360 the mechanic may send an explicit run command to the elevator controller 40, instructing the elevator car to begin travelling up or down the hoistway. At step 362, the elevator controller 40 transmits a signal to the remote computing device 64, indicating that the run command is in execution, i.e. that the elevator car is being moved, and then transmits a further signal at step 334, indicating that the elevator car has arrived at a landing.

[0072] Once the mechanic 302 is aware that the elevator car is stopped at the landing, the mechanic 302 then issues a door open command from the remote computing device 64 to the elevator controller 40, at step 338 in response to which the elevator car doors are opened, and as a result the passengers are rescued, at step 342.

[0073] Once the passengers have successfully been rescued, the override of the safety controller 52 is no longer required, and is in fact undesirable for safety purposes. Therefore, at step 364, the safety controller 52 sends a signal to the remote computing device 64, indicating that the override command has been terminated, so that operation of the elevator car is once again prevented, until the safety contact(s) have been “closed” to restore a normal operating condition of the elevator system. Then, at step 366, the authorisation of the remote computing device 64 to the safety controller 52 is terminated. In future, if the same mechanic 302 using the same remote computing device 64 wishes to override the safety controller 52, a new authentication to the safety controller 52 will therefore be required.

[0074] The authentication process described above with reference to FIG. 4 is represented in more detail in the schematic drawing FIG. 5, which shows an authentication process between a remote computing device 64 and, respectively, a safety controller 52, and an elevator controller 40.

[0075] As seen on the left hand side of FIG. 5, the remote computing device 64 stores a first certificate 500, and a first public key 502. This first public key 502 may not be permanently stored on the remote computing device 64, but may be retrieved from elsewhere when required.

[0076] A trusted certificate authority is used to generate the certificate. To do so, firstly the remote computing device 64 sends a request, containing the first public key 502 and remote computing device credentials (e.g. credentials encrypted with the first public key 502), to a certificate authority. The certificate authority verifies the information in the request and “digitally signs” the certificate with a certificate authority private key (which the certificate authority guarantees cannot be hacked). This certificate 500 is then sent to the remote computing device 64, where it is stored.

[0077] The certificate 500 is sent to the safety controller 52. The safety controller 52 can then confirm the certificate authority's digital signature using the certificate authority's public key, and can also confirm that the remote computing device 64 is in possession of the first public key, using a private key 504, also referred to as a factory key, stored on the safety controller 52—specifically on a smart card chip 508, e.g. by decrypting the credentials. The validity of the decrypted certificate 500a is then checked, e.g. it is checked whether the certificate is signed by a trusted certificate authority.

[0078] If the certificate is deemed to be valid, then the remote computing device 64 is considered to be verified.

[0079] Similarly, for authenticating to the elevator controller 40, the remote computing device 64 stores a second certificate 600, generated in the same manner as described above using a second public key 602 stored on the remote computing device 64. The safety controller 52 can then confirm the certificate authority's digital signature using the certificate authority's public key, and can also confirm that the remote computing device 64 is in possession of the second public key 602 using a second private key 604, also referred to as a factory key, stored on the safety controller 52—specifically on a smart card chip 608. The validity of the decrypted certificate 600a is then checked, e.g. it is checked whether the certificate is signed by a trusted certificate authority.

[0080] The certificate authority (and therefore the certificate authority private and public keys) can be the same for both the first and second certificates 500, 600, or different certificate authorities could be used to generate each.

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