-
The present invention relates to elevator systems and, more particularly, to improvements in dispatching elevators to predetermined landings following a loss of normal building power.
-
It is known to provide a source of emergency power for operating elevators when normal building power, typically supplied by feeders, fails. The emergency power is supplied, for example, by battery or by generators run by fueled engines. Usually, the emergency power supply is inadequate to provide power for all of the elevators in a particular group. Accordingly, elevators must be selected to run on emergency power, one or several at a time, depending upon the elevator capacity of the emergency power supply. When normal building power fails, it is likely that several of the elevator cars contain trapped passengers. Some of the known arrangements for emergency power elevator recovery have proven to be effective in reducing the time required for freeing trapped passengers. See, for example, commonly-owned U.S. Patent No. 4,379,499, issued April 12, 1983, Emergency Power Elevator Recovery and Service System, by Nowak, which is hereby incorporated by reference. Nevertheless, the present inventors believe that further reductions in the time required for freeing trapped passengers during the emergency power situations are achievable.
-
It is therefore an object of the present invention to reduce the time period required for freeing trapped passengers from an elevator car operating on emergency power.
-
According to one aspect of the present invention, there is provided a method for dispatching elevator cars, comprising: detecting emergency electrical power to one of a plurality of elevator cars; determining a master controller from a number of controllers for the plurality of elevator cars; ascertaining a load condition of each of the plurality of elevator cars, and then dispatching one elevator car having a highest load condition of the plurality of elevator cars to a predetermined landing.
-
According to another aspect of the present invention, there is provided an elevator system, comprising: a plurality of elevator cars, each car having a respective load; controllers associated with said elevator cars, said controllers being electrically interconnected for communication therebetween, each of said controllers including a means for detecting emergency electrical power, a means for determining a master controller from said controllers and a means for dispatching said elevator cars in a sequence which is dependent upon the respective load of each car.
-
The method of the present invention for dispatching elevator cars includes detecting emergency power to one of a plurality or group of elevator cars, determining a master controller for the plurality of cars, ascertaining a load condition of each of the plurality of cars, and then dispatching each of the elevator cars to a predetermined landing in a sequence which is dependent upon the load condition of each car. The present invention also includes an apparatus for accomplishing the method. The load condition (state) of each elevator car corresponds satisfactorily to the number of passengers, if any, trapped within the car. The car containing the highest load condition (i.e., highest number of trapped passengers) is deemed to have a highest priority, and is dispatched to the predetermined landing prior to dispatching any of the remaining cars. Thereafter, the remaining cars of the group are dispatched in a sequence which is dependent upon the load condition of each car. Thus, after dispatching the car with the highest load condition to the predetermined landing, the present invention dispatches a car having a next lowest load condition to the predetermined landing. The invention continues dispatching the cars sequentially according to load conditions until all on-line cars in the group have reached the predetermined landing-- typically, the lobby.
-
Thus, in the present invention elevator cars are dispatched during an emergency to a predetermined floor in a sequence which is dependent upon the load conditions of the cars.
-
Preferably, the present invention selects a master controller from a plurality of car controllers when emergency power is detected to at least one elevator car.
-
An embodiment of the invention will now be described by way of example only and with reference to the accompanying drawings, in which:
- Fig. 1 is a plan view of four elevators of an exemplary eight car group elevator system;
- Fig. 2 is a block schematic diagram of a control arrangement for the exemplary eight car elevator system, in which arrangement the present invention may be implemented; Fig. 2A is a block schematic diagram of a typical OCSS;
- Fig. 3 is a logic flow diagram of a priority load dispatch rescue operation according to the present invention;
- Fig. 4 is a logic flow diagram of a subroutine for determining a master controller;
- Fig. 5 is a logic flow diagram of a subroutine for collecting and storing passenger load information;
- Fig. 6 and Fig. 7 are logic flow diagrams of subroutines for selecting elevators for rescue; and
- Fig. 8 is a car load state priority table according to the present invention.
-
Fig. 1 shows four elevator cars 1-4 of an exemplary eight car group which serves a building having a plurality of floors. The building has a main floor--typically, a ground floor or lobby L. Each car contains a car operating panel 12 through which a passenger (not shown) makes a car call to indicate a destination floor. The passenger presses a button (not shown) on the panel 12 producing a car call signal CC which identifies the floor to which the passenger intends to travel. A hall call fixture 14 which initiates a hall call signal HC is provided on each of the floors to indicate the intended direction of travel by a passenger (not shown) on the floor. At the lobby L, there is a hall call fixture 16 which permits a passenger (not shown) to call a car to the lobby L. During normal operation of the group, various traffic parameter signals govern the dispatching of the elevator cars. Such parameter signals include, for example, car load condition signals LW, hall call signals HC, car call signals CC, etc. Various apparatus and methods for generating and processing the signals LW, HC, CC, etc., corresponding to car loads, hall calls, car calls, etc., for controlling elevator cars are well understood in the elevator and electronic computer arts. See, for example, commonly-owned: U.S. Patent No. 4,330,836, Elevator Cab Loading Measuring System, issued May 18, 1992, by Donofrio et al; and U.S. Patent No. 4,497,391, Modular Operational Elevator Control System, issued February 5, 1985, by Mendelsohn et al, which are hereby incorporated by reference. The '836 patent by Donofrio et al teaches apparatus for generating the signals LW.
-
The elevator cars 1-4 of Fig. 1 are operated under the control of an elevator group control system, such as that shown in Fig. 2. Fig. 2 shows an elevator group control system having an eight car group configuration. Associated with each car 1-4 (Fig. 2) and each car 5-8 (not shown) is a respective car controller (Fig. 2). Each car controller includes, for example, one operational control subsystem OCSS 101, one door control subsystem DCSS 111, one motion control subsystem MCSS 112 and one drive and brake subsystem DBSS 112A, all suitably electrically connected. The DCSS, MCSS and DBSS are under the control of the respective OCSS. Such a group control system is known, for example, from copending commonly-owned U.S. Patent No. 5202540, Two-Way Ring Communication System for Elevator Group Control, filed March 23, 1987, by Auer and Jurgen, which is hereby incorporated by reference. In Fig. 2; elevator dispatching is distributed to the separate car controllers, one per car. Each OCSS is a microcomputer subsystem, while each MCSS, DCSS and DBSS is a microprocessor-based subsystem suitably electrically coupled to and controlled by its respective OCSS. All OCSSs, and thus all car controllers, are operationally interconnected by means of two serial links 102,103 in a two-way ring communication system. For clarity, MCSS, DCSS and DBSS are shown only in relation to one OCSS; however, it is understood that there are eight sets of these subsystems, one set associated with each elevator car and each set of OCSS, MCSS, DCSS and DBSS forming a car controller.
-
The call buttons and lights are connected with remote stations 104 and a remote serial communication link 105 to the OCSS 101 by means of a switchover module SOM 106. The car buttons, lights and switches are connected through remote stations 107 and a serial link 108 to the OCSS 101. The car specific call features, such as car direction and position indicators, are connected to remote stations 109 and a remote serial link 110 to the OCSS 101. During normal operation of an elevator car (e.g., car 1), a car load measurement is periodically read by the respective door control subsystem DCSS 111, and a suitable signal LW is transmitted to the respective motion control subsystem MCSS 112 and also to the respective operational control subsystem OCSS 101.
-
The dispatching function for each elevator car is executed and controlled by the respective OCSS forming a part of the respective car controller. Each OCSS includes readily available hardware components such as a microprocessor, a volatile memory (e.g., Random Access Memory - RAM), a nonvolatile memory (e.g., Read Only Memory - ROM), various input and output ports, appropriate address, data and control buses, additional associated circuitry, optional external memory, and suitably stored software components such as a BIOS, an operating system, etc.-, all as is well understood by those skilled in the elevator and electronic computer arts. See, for example, Fig. 2A. Each OCSS typically also contains various computer programs for operating its respective car and for communicating with other OCSSs whether or not the cars are using emergency power. Such various programs are well known to those skilled in the art and will not be further described. See, for example, commonly-owned U.S. Patent No. 4,363,381, Relative System Response Elevator Call Assignments, issued Dec. 14, 1982, by Bittar, which is hereby incorporated by reference.
-
According to the present invention, the control system of Fig. 2 executes the routines shown in Figs. 3-7 and utilizes the car load state priority table of Fig. 8. Coding the routines and the table of Figs. 3-8, storing the routines and the table within each OCSS of Fig. 2 and otherwise implementing the present invention, are well within the skills of those in the elevator and computer arts in view of the instant disclosure.
-
Fig. 3 shows a logic flow diagram of the priority load dispatch operation according to the present invention. Each OCSS of the elevator control system shown in Fig. 2 suitably contains (e.g., in a ROM or an EPROM (not shown)) the routines of Figs. 3-7 and the car load state priority table of Fig. 8. The routine of Fig. 3 takes operational control of a respective elevator car if the OCSS detects emergency power being supplied to the car, step 200. Such detection is accomplished by well known means such as various interrogating routines taught in previously incorporated U.S. Patent No. 4,379,499, Nowak. If an OCSS detects emergency power, the OCSS executes a Determine EPO_MASTER Controller routine (Fig. 4) to determine or select a master controller (i.e., a group or master OCSS) from among the group of car controllers, step 300. Once determined, the master controller (master OCSS) controls all rescue dispatching operations of all controllers for all cars until the master controller determines that no elevator in the elevator group requires rescue, steps 500, 600.
-
The routine of Fig. 4 determines a master controller from among the group (e.g., eight) of car controllers, steps 300-318. Each OCSS of each car controller executes the routine of Fig. 4 until the master controller is determined. Thereafter, the master controller takes control of and supervises all operational control subsystems OCSS 101 of the group. To determine the master controller, each OCSS reads the status (i.e., on-line, off-line, etc.) of all cars through, e.g., a ring port such as an RS-232 serial port of an OCSS ring card (both not shown), step 302. A car is "on-line" if its OCSS is sending a valid status broadcast message on the two- way ring 102, 103. Off-line cars are handled by well known routines or methods which are not part of the present invention and will not be discussed.
-
Each of the cars 1-8 has a unique identification number--e.g., 1-8, respectively. Thus, the OCSS for the car 1 has a field CAR_ID=1. The car 2 has a field CAR_ID=2, etc. A group mask in RAM is then updated with all on-line ID bits corresponding to all identification numbers of all on-line cars, (e.g., 1-8), step 304. For example, if the car 1 is on-line, an address BIT(1) in RAM will contain a bit indicating that car 1 is on-line; if the car 2 is on-line, an address BIT(2) will contain a bit indicating that the car 2 is on-line, etc. A variable field I is set equal to 1 and a flag EPO_MASTER is reset (i.e., zero or false), step 306. A memory location (address) BIT(1) containing the identification information stored in the step 304 is examined to ascertain whether it stores information indicating that the car 1 is on-line, step 308. If the car 1 is on-line, BIT(l) = 1 is yes and a step 310 of the routine sets a field MASTER_CAR_ID equal to 1. A step 312 interrogates the field CAR_ID of this particular car.
-
For clarity, the remaining execution of the routines of Figs. 3-7 will be discussed hereinafter with particular reference to the routines as running in the OCSS 101 for the elevator car 1. Because the routine is being executed in the controller (specifically, the OCSS) for the car 1, the step 312 results in a yes and the routine proceeds to step 314 and sets EPO_MASTER to true (or 1). Thus, the car 1 controller is determined or selected as the master controller, step 314.
-
The master controller returns to the routine of Fig. 3 which then executes steps 400-420 to collect and store load status data from each car in the group into its volatile memory RAM (Fig. 5). In a step 500, the routine decides whether any elevator in the group requires rescue. "Load Status" LW and "Require Rescue Status" are sent to the master controller from each OCSS by well known techniques; e.g., each OCSS sends its operational mode (and all status information) as part of its conventional status broadcast message.
-
A "yes" in step 500 invokes a select elevator for rescue operation routine, steps 710-794, which is shown in more detail in Figs. 6 and 7.
-
A field RESCUE_CAR is reset (i.e., zero or false), step 710. LOAD is set equal to MAX_LOAD which is a maximum load value (e.g., 4) obtained from the table of Fig. 8 suitably stored within the OCSS, step 710. If RESCUE_CAR equals False in step 720, then the variable I is set equal to CAR_ID plus 1, step 730. For the controller of the car 1, I then equals 2 at this time. In step 740, a decision is made regarding whether the car 2 is ready for rescue. If yes, then a step 750 decides if the car 2 load status (stored by the step 420) is equal to LOAD (for example, 4 - Overloaded), see Fig. 8.
-
If car 2 is not overloaded, I is increased by 1, step 742. If none of the cars 3-8 in this example is Overloaded and I is greater than the maximum number of on-line cars in the group (e.g., 8), step 770, the OCSS for the car 1 executes the steps 780-794 in an appropriate order as clearly shown in Fig. 7.
-
For example, if the car 1 is ready for rescue (step 780) and not Overloaded (step 790), LOAD is set equal to a next lowest load value (e.g. 3 from the table of Fig. 8) in the step 794. If car 2 is Fully Loaded, a field RESCUE_CAR is set equal to 2 (step 760), and eventually the master OCSS 101 via link 102,103 causes (e.g., by means of a cause dispatch signal "CD2") the OCSS for the car 2 to generate a signal D2 (e.g., dispatch the car 2 to the lobby) which dispatches the car 2 to the ground floor, steps 720, 800. The master OCSS 101 commands the dispatching of each on-line car in a priority sequence which is dependent upon the load status of each car. For example, the cars are dispatched according to the table of values as set forth in Fig. 8. In other words, the cars 1-8 will be dispatched to the ground floor in the sequence (Highest load condition to Lowest, i.e., from Overloaded (if safety permits) to Anti-nuisance load, in that order). Any execution of the steps 790, 792 results in commanding the dispatch of the elevator car for the master controller before commanding the dispatch of any other car having an equal load condition. Of course, the master OCSS also suitably selects a number of cars to run on emergency power as appropriate.
-
After executing all routines of Figs. 3-8, the master controller returns control to other routines (not shown) for other elevator operations such as normal call dispatching.
-
While there has been shown and described what is at present considered the preferred embodiment of the present invention, it would be apparent to those skilled in the art that various changes and modifications may be made therein without departing from the scope of the present invention which shall be limited only by the appended claims.
