HK1117487B - Method of collision prevention in hoistway with two elevator cars - Google Patents

Description

Method for preventing collision in elevator shaft with two cages

Technical Field

The present invention relates to a method of avoiding a collision of two cars traveling in the same hoistway in a number of ways, including assigning cars to avoid a collision by one or more means, such as reducing speed, acceleration, deceleration, delaying the start of a car, braking a car at a non-designated floor, or reversing a car to ensure that the other car reaches its destination, in response to a potential collision in time; the safety device is activated by operating the brake of one or more of the cars, or in the event of an impending collision of one or more of the cars.

Background

In order to provide maximum service with minimal impact on the available space, it is known to provide more than one car to operate independently in the same hoistway. In some systems, call assignment is quite rudimentary, and while there is no problem with preventing potential collisions of cars, these systems do not add significant service because many calls are undesignable. Examples are shown, for example, in U.S.5419414, U.S.6360849 and U.S. 2003/0164267.

In order to maximize the utilization of more than one car for a single hoistway run, additional control systems are required to ensure that the cars do not collide, which can significantly improve the single car ride capacity.

Disclosure of Invention

The objects of the present invention include: providing a mode of operation in which more than one car is operated in a single hoistway without risk of collision between cars; the operation capability of the elevator car is improved by operating two elevator cars in the same elevator shaft.

By means of the invention, a call command from an entrance floor to a destination floor is assigned to one of a plurality of cars traveling in the same hoistway in such a way that a collision that may occur between the cars is avoided.

Further, with the present invention, cars traveling in the same hoistway check each new call to determine if the call would result in a potential collision and, if a collision is likely, call reassignment.

In addition, according to the invention, cars traveling in the same hoistway exchange information and determine when a potential collision is imminent, taking action to reduce the probability of a collision, e.g., reduce speed, acceleration, or deceleration; braking one or both cars; reversing one or two cars; or to keep one car stopped at the landing.

Still according to the invention, the approach of a collision represented by cars within a first distance of each other can be avoided by one or both of the cars braking, and in the case of a closer distance, by activating one or both of the car safeties.

Further features and advantages of the present invention will become apparent from the detailed description of exemplary embodiments thereof as illustrated in the accompanying drawings.

Drawings

Fig. 1 is a partial perspective view of a hoistway having a plurality of cars, with a simplified block diagram of the present invention.

Fig. 2 is a flow chart showing a procedure performed to designate a car according to the present invention.

FIG. 3 is a flow chart of checking incoming commands to determine potential collisions.

FIGS. 4A-4C are partial flow diagrams of an exemplary verification process of the present invention.

Fig. 5 is a flow chart showing the detection and procedure of avoiding collisions between cars.

Detailed Description

Fig. 1 shows an elevator system 8 having a hoistway 9, including an upper car 10 and a lower car 11, both of which travel in the hoistway 9. A durable steel coding strip, such as stainless steel strip 14 with a hole code thereon, is provided in the hoistway. The belt 14 extends through both fixed ends 16, 17 of the hoistway. Each car has conventional safety gear 18, 19 which is operated in a conventional manner by guide rails (not shown in the figures).

Two belt readers are provided on each car, an upper (U) belt reader 20 and a lower (L) belt reader 21 are provided on the upper car 10, and upper and lower belt readers 22, 23 are provided on the lower car 11. Each belt reader and its associated line 29-32 provide position information 35-38 of the upper and lower cars to redundant processors 41, 42 and to an upper car controller 45 and a lower car controller 46. The processors 41, 42 may operate the brakes and braking systems 49, 50 of each car motor, or engage the safeties of the upper and lower cars no matter how close the cars are to each other, consistent with that described below in fig. 5.

The group controller 52 is used to assign call tasks as described below with respect to fig. 2. In this embodiment, call services made at any floor are assumed, including the destination floor that the caller wishes to reach. Therefore, any possibility of a collision between cars, including the origination floor, referred to herein as "F" (i.e., the floor from which the call originated) and the destination floor, referred to herein as "D", must be considered. It is noted that U generally refers to the upper car, but it is obvious here that it can also refer to the position of the upper car. "L" generally refers to the lower car, but it will be clear from the context herein that it may also refer to the position of the lower car.

As shown in fig. 2, fig. 2 illustrates the procedure performed to adjust the operating strategy of the present invention based on the assigned call instruction, which in this embodiment is accomplished by the group controller 52. For example, the dispatcher's subroutine may be initiated through entry point 55, with the first step 56 being to reset the floor counter F to 0. Then step 58 increments the floor counter and a test 59 is used to determine if there is a call at the specified floor. If not, return to step 58, the counter F is incremented again, and then the verification 59 is repeated. When a call is placed on a given floor, a test 62 is entered to determine if the call is from an upper floor. If from the upper floor, a test 64 determines if the floor is at or above the upper car U. If so, then the call is from above and there is no problem assigning the call to the upper car via step 65. Step 66 will then set a flag indicating that a new call at floor F is assigned to the upper car.

The program returns to step 58 to increment the floor counter again and a test 59 determines in turn whether there is a call to the next floor. If so, the test 62 again determines whether the call is from above.

If the test 64 is negative, a series of tests 68-71 will be initiated unless any of the tests 68-70 is positive. A test 68 is used to determine if the floor is equal to or above the demand floor for the upper car (i.e., the highest stop floor now designated). If so, the call is assigned to the upper car. If not, a test 69 determines if the floor is equal to or higher than the required floor of the lower car plus 1. This indicates that the call below will not reach the pick floor F and thus the call can be assigned to the upper car. Otherwise, the entry test 70 determines that the destination floor D of the call is at or below the demand floor of the lower car. If so, the lower car is commanded to travel from the call floor F up to or beyond the destination floor of the call, via step 73. Step 74 then sets a flag indicating that a new call at floor F is assigned to the lower car. The test 71 determines that the destination floor of the call is at or below the demand floor of the upper car minus 1, indicating that the lower car can answer if the closest distance to the upper car at any time is not less than one floor. In this case, steps 73 and 74 assign the command to the lower car.

If in this particular embodiment all of the determinations of verifications 64, 68-71 are "no", a delay step 76 is initiated to allow the situation within the hoistway to change and then call instructions are reassigned through steps 64, 68-71. If desired, a more complex embodiment may be utilized in which the synchronized position of each car is taken into account; in this way, even if the demand floors of two cars overlap each other, the timed arrival procedure is sufficient to keep them a sufficient distance to avoid a collision. This can also be achieved in another way, but it can be very complicated and not as brief as now described.

When a call is in the down direction, a negative result of the determination of test 62 initiates a series of tests 78-82 and steps 83-87 similar to those described above, except that the downward direction from floor F to destination floor D is considered.

According to one aspect of the invention, once a call is assigned, such as by a group controller, each car controller 45, 46 exchanges information with each other to determine whether the call is properly assigned. That is, the likelihood that the assignment of a new call instruction will result in a collision outcome is determined.

Fig. 3 shows an example of a procedure scheduler for obtaining the operating strategy of the invention, which is jointly executed by the two car controllers 45, 46 and is initiated via an entry point 90. The first step is to set the floor counter F (which is different from F in fig. 2) to zero. Step 93 increments F to the first floor point. A test 95 then determines whether a flag is set to indicate a new assignment to the upper car from floor F. If so, step 96 resets the flag and a series of tests 97-100 are enabled to determine if the call floor F or call destination floor D is the lower car or its demand floor, or one floor below the lower car or its demand floor. If these conditions exist, a positive result is verified 97-100, and step 103 is initiated to indicate that the call instruction should be reassigned. If neither of these conditions exist, a negative result causes the program to return to step 93 to increment F and check whether the next floor raises a new command flag.

If the upper car has not set a flag, a test 105 is used to determine if the flag has been set to indicate that the call at floor F has been reassigned to the lower car. If so, an activation step 106 resets the flag and initiates a series of tests 109 and 112 to determine if floor F or destination floor D is an upper car or one floor above it. If these conditions exist, step 115 is initiated to indicate that the call at floor F should be reassigned to the lower car. If the call at floor F is not reassigned to either the upper or lower car, a negative result of the determination routine 95, 105 causes the routine to return to step 93 and check whether the next floor presents a new call flag.

Determining whether the call instruction is properly assigned can be accomplished in a number of ways, and the process illustrated in FIG. 3 is merely a specific example. In particular, if the strategy for assigning call instructions in the first place is more complex than that described in fig. 2, checking the appropriateness of the assignment of new instructions will be more complex than that shown in fig. 3. However, these various embodiments are within the scope of the present invention.

In addition to checking the assignment of new commands, each controller 45, 46 continuously checks the likelihood of a collision between the cars, an example of which is shown in fig. 4A-4C. In fig. 4A, a test 120 is used to determine if the demand floor of the upper car is at or below one floor below the demand floor of the lower car. If not, there is no further operation in FIG. 4A. But if the result of the determination of the verification 120 is positive, a pair of verifications 122, 123 is initiated to decide the next operation to proceed. If the upper car is traveling downward, a series of steps are used to adjust the acceleration, deceleration and maximum speed of the upper car to a minimum as shown in test 122. However, if the upper car is not traveling downward and the lower car is traveling upward, a series of steps 130 and 132 are initiated to adjust the acceleration, deceleration, and maximum speed of the lower car to a minimum. A similar procedure is performed with similar results in the case where the demand floor of the lower car is at or above one floor of the demand floor of the upper car.

In fig. 4B, a test 135 is used to determine if the target floor of the upper car is at or below the demand floor of the lower car by one floor. If so, a test 136 determines if the lower car is traveling upward; if so, a start step 138 stops the lower car at the floor it receives the call under control of its motor. Then step 139 changes the direction of travel of the lower car to downward and step 140 initiates the lower car travel. Step 138 and 140 include steps necessary for the reversal, delay and other operational procedures, which are conventional and will not be described in detail herein for the sake of brevity.

Steps similar to those identified in fig. 4B are performed by detecting the direction of the downward travel of the upper car and diverting it to correspond to test 135. Similar determinations and steps are performed by detecting that the target floor of the lower car is one floor below or above the current position of the upper car as a result of comparable determinations and steps. Fig. 4B is merely an example, and other verifications may be performed to divert one or both cars.

In fig. 4C, a test 143 is used to determine if the target floor of the lower car is at or above one floor below the upper car. If so, a test 145 determines if the lower car is moving. If so, then a test 146 is entered to determine if it is running in the up direction. If so, the lower car may receive a stop command as a result of step 148. If the lower car is not moving, a negative result of test 145 will set a flag to indicate that the lower car should wait. If it is running, if it is moving up, the test 146 causes a stop command to be issued at step 148. This may be a normal stop (although not pre-specified) caused by the motor slowing down rather than the brake. If the result of the determination of either test 143 or test 146 is negative, the lower car is not stopped or waited.

Other procedures than that described in fig. 4C may be used to determine the likelihood of a collision, such as determining other relationships to stop one or both cars or to wait for one car. The car can likewise be controlled in other ways in response to such a determination.

Fig. 4A-4C are illustrations of verifications and corresponding ones of these verifications operating one or both controllers to avoid a collision between two cars. In fig. 3 and 4A-4C, the safety difference between the cars is represented as two upstairs, such as the verification 97 in fig. 3 to determine that the call floor F is equal to or lower than one floor at the lower car position. However, one, three, or more floors may be used as a safety difference, in which case, for example, the verification may determine whether F is equal to or less than L + 2.

The processors 41, 42 of fig. 1 provide an independent, redundant detection of the approach to a collision to determine the activation of an automatic brake or the engagement of one or more car safeties. In this example, FIG. 5 presents a program for implementing the operational strategy of the present invention in the form of a flowchart-representing operational procedure. Fig. 5 shows the routines that may be performed by both processors 41, 42, but is merely an example of a condition where one or more car brakes or safeties are activated.

In FIG. 5, the collision routine is initiated through entry point 153 and in the course of the procedure thereafter repeats through other portions of the routine to detect an impending collision from start state 154. A first test 156 determines if the direction of the upper car is downward. If so, a test 157 determines if the distance between the cars is four floors. If so, step 160 activates the brake 49 of the upper car to stop the upper car. If the distance between the cars is not four floors, a test 162 is entered to determine if the spacing between the cars is less than three floors. If so, step 163 activates the upper car safety device 18. If the upper car is not moving downward, a negative result of test 156 causes steps 157-163 to be bypassed.

In fig. 5, a test 165 determines if the lower car is moving upward. If so, a test 166 determines if the distance between the cars is four floors. If so, step 168 activates the brake 50 of the lower car to stop the upper car. Otherwise, a test 170 determines if the spacing between cars is less than three floors. If so, step 171 activates the lower car safety device 19. If the lower car is not moving upwards, the start step 166 and 171 are bypassed.

The form of determination and typical values used, and the general relationship between the two, may be selected to suit any implementation of the invention when the brake or safety device is activated.

Claims (2)

1. A method of operating an elevator system (8) including a hoistway (9) having a plurality of cars (10, 11), each car having a controller (45, 46) for assigning elevator call commands to desired destination floors, said method characterized by:

assigning each call command to one of the cars (65, 66; 73, 74; 83, 84; 85, 86) in a manner that ensures that no cars will collide; and

continuously determining (157, 166) whether one of said cars is within a first distance of the other of said cars, thereby causing (160, 168) one or more of said cars to actuate a braking device in response, wherein said first distance is a distance within which braking of one or more of said cars can stop said cars; and the number of the first and second groups,

continuously determining (162, 170) whether one of the cars is within a second distance of the other of the cars that is less than the first distance, thereby causing (163, 171) safety devices of one or more of the cars to be engaged in response, wherein the second distance is the distance within which the safety devices of one or more of the cars are able to stop the car.

2. A method according to claim 1, wherein the step of continuously determining is performed in each of two independent processors (41, 42).