Abstract:
An elevator system having multiple elevator cars efficiently assigns cars and communicates the car assignments to the potential passengers. A hallway intuitive user interface is readily adapted to installations having varying numbers of elevator cars with varying floor access by incorporating a graphical display that is rendered accordingly. Moreover, a combination of visual, textual and aural indications are given to the passenger that the destination entered is valid and assigned to a car. For those instances where a potential passenger fails to enter a destination correctly, the elevator system retains a traditional elevator control interface in the elevator car.

Description:
FIELD OF THE INVENTION  
         [0001]    The present invention relates, in general, to elevator systems having a plurality of elevator cars, and more particularly, to an elevator control system for receiving passenger calls and for displaying car assignments in response thereto.  
         BACKGROUND OF THE INVENTION  
         [0002]    Elevator systems often include a number of elevator cars that are assigned to pick up passengers in a coordinated fashion, thereby increasing the number of people that may be served. Typically, a passenger makes a hall call by depressing an up or a down button at the elevator waiting area. The elevator system assigns an available elevator to stop at that floor.  
           [0003]    Early designs suffered from having rudimentary car assignment protocols that did not adjust to peak usage times. For example, during a “peak up” period, such as at the beginning of the workday, many people wish to use the elevator system from the ground floor. There is the reverse situation during a “peak down” period. The elevator system was not responsive to the number of passengers waiting at any given floor nor to their desired destination. Consequently, passengers tended to crowd onto the first available car, which then had to stop at numerous floors. The next available car would then be less crowded, but may very well have to stop at some of the very same floor as the first car.  
           [0004]    Recently, elevator systems have incorporated hall calls that invite passengers to select a desired destination before entering an elevator call. With this information, the elevator control system may make destination pre-assignments that better utilize the available elevator cars. For example, the number of passengers and stops may be more evenly divided between cars. Inefficiencies are avoided such as two cars taking passengers between the same two floors.  
           [0005]    These known elevator destination protocols accepted a keypad input or a selected floor button input from the ground floor elevator waiting area. The elevator control system then assigned an elevator car based on proximity, passenger call wait time, availability and what other floors were already assigned to this and other cars. The passenger was then directed to the proper car, typically by a display by each respective elevator door listing the assigned destinations for that car.  
           [0006]    While these elevator systems that incorporate the known elevator destination protocol have been an advance over the more rudimentary assignment approaches, often passengers find these elevator systems inconvenient. Given the paradigm shift in how to use an elevator, many people fail to see the need for each rider to make a hall call for the desired destination. Instead, seeing that others have already made a hall call, some passengers at the elevator waiting area do not input their desired destination, choosing instead to enter the first available car. Alternatively, the passenger may select the wrong destination at the hall call or enter the wrong car. These known elevator systems are not flexible enough for passengers that prefer to operate the elevator in the traditional manner.  
           [0007]    These mistakes are made more prevalent by some destination protocols that only accept destination requests at the ground floor for peak up period optimization. Another reason for such mistakes is that such elevator systems tend to have simplistic displays of a list of car assignments, which a passenger may misunderstand as a hall call rather than a destination.  
           [0008]    These known elevator destination protocols are often constrained by the physical accessibility to the various elevator cars from the waiting area. Having not all of the elevators serve the same set of floors introduces difficulty, such as when one elevator serves fewer floors than the rest. Without knowledge of the passenger&#39;s desired destination, this car with limited service may inadvertently dispatched to pickup the passenger. To address this problem, often an extra set of hall call buttons are added for each set of elevator cars that serve the same subset of floors, relying upon the passengers to read signage directing them to the appropriate bank of elevators.  
           [0009]    Even with knowledge of passenger desired destination, other problems exist with elevators servicing different subsets of floors or being physically spaced apart from other elevators. Specifically, the known destination car assignment approaches communicate the car assignment in a nonintuitive fashion. A passenger may thus miss the assigned car by overlooking the car assignment. For instance, the car assignment may be displayed by an elevator that is not within view of the passenger.  
           [0010]    Consequently, a significant need exists for an elevator destination control that enhances passenger interaction, both by being flexible in accepting a desired destination and by communicating car assignments in a more intuitive manner.  
         BRIEF SUMMARY OF THE INVENTION  
         [0011]    The invention overcomes the above-noted and other deficiencies of the prior art by providing an elevator destination protocol control that receives a desired destination as part of the hall call for an elevator car. The control alerts the user that the desired destination is correctly requested and assigned to a specific car. In particular, a destination confirmation event is generated on a graphical hall call device that intuitively communicates with the user. Thereby, the efficient transport of users by destination protocol is enhanced through a less confusing user interface.  
           [0012]    In one aspect of the invention, a method and system are provided wherein a graphical hall call device displays elevator car accessibility on that floor along with assigned destinations for those accessible elevator cars. The graphical hall call device generates a destination confirmation event so that a user knows that his desired destination has been properly assigned.- Thereby, the user avoids an undue wait or frustration in instances wherein an invalid destination has been input or a validly input destination has been assigned without the user understanding he assignment.  
           [0013]    These and other objects and advantages of the present invention shall be made apparent from the accompanying drawings and the description thereof. 
       
    
    
     BRIEF DESCRIPTION OF THE FIGURES  
       [0014]    The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the invention, and, together with the general description of the invention given above, and the detailed description of the embodiments given below, serve to explain the principles of the present invention.  
         [0015]    [0015]FIG. 1 is a diagram of an elevator system including elevator predestination protocol control with hallway intuitive user interfaces and traditional in-car elevator controls.  
         [0016]    [0016]FIG. 2 is a block diagram of the elevator predestination protocol control of the elevator system of FIG. 1.  
         [0017]    [0017]FIG. 3 is a data flow diagram of the elevator predestination protocol control of FIG. 2.  
         [0018]    [0018]FIG. 4 is a flow diagram of the elevator predestination protocol control of FIG. 2.  
         [0019]    [0019]FIG. 5 is a diagram of the graphical hallway call device of the elevator system of FIG. 1.  
         [0020]    [0020]FIG. 6 is a planform diagram of an elevator waiting area.  
         [0021]    [0021]FIG. 7 is a graphical hallway call device displaying car assignments in relation to an oriented planform diagram for accessible elevator cars. 
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0022]    Turning to the Drawings, wherein like numerals denote like components throughout the several views, FIG. 1 depicts an elevator system  10  having multiple elevator cars  12 ,  14 ,  16 ,  18  in respective elevator shafts  22 ,  24 ,  26 ,  28 . The elevator system  10  advantageously enables predestination assignment of potential passengers in respective elevator waiting areas (Floor 1, 2, 3, 4, N), specifically by a graphical hallway call device  30 . Thereby, the elevator system  10  may assign an elevator car  12 - 18  in a manner that reduces the wait time for the potential passengers and avoids a disproportionate number of intermediate stops for current passengers.  
         [0023]    In addition to the advantages of predestination assignment, the elevator system  10  maintains a traditional elevator user interface  32  with up and down hall call buttons  34 ,  36 , which may provide a backup interface for instances wherein the elevator destination protocol control is not desired or available. The traditional elevator user interface  32  also includes an elevator car panel  38  in each elevator car  12 - 18 . Thus, passengers that inadvertently enter a car  12 - 18  without entering a desired destination beforehand may still select a floor, with the elevator system  10  being responsive thereto to reassign cars  12 - 18 . Alternatively, the elevator car panel  38  may be used when a graphical hall call device  30  is not available on the floor or is otherwise disabled.  
         [0024]    Each passenger receives additional visual and aural indications about the destination assignment of the cars by the graphical hallway call device  30  that reduces the likelihood, however, that the passenger would miss the assigned car. In particular, a keypad input  40  and a graphical display  42  on each graphical hallway call device  30  enable the elevator system  10  to be readily adapted to buildings with varying number of elevator cars having varying floor assignments. For instance, the elevator system  10  is responsive to one elevator car  18  having its elevator shaft  28  inaccessible on Floor 1 by omitting that car  18  from the graphical display  42  on Floor 1, while depicting this car  18  on the graphical displays  40  on other floors 2, 3, 4, N. Additional illustrations of the assistance to the passengers rendered by the graphical hallway call device  30  are described in more detail below, especially with regard to FIG. 5.  
         [0025]    [0025]FIG. 2 depicts a predestination elevator control  50  that optimizes elevator car assignments for the elevator system  10 . A group supervisory computer  52  receives traditional hall call user inputs  54  and/or predestination hall call inputs  56  and communicates these requests along with elevator car status (e.g., location, operability) via an RS-422 channel to an intelligence computer  58  that makes elevator car assignments in accordance with fuzzy logic control. The group supervisory computer  52  provides confirmation of elevator car assignment back to the traditional hall call user inputs  54  and/or predestination hall call user inputs  56 .  
         [0026]    In the illustrative version, a predestination protocol computer  60  advantageously is located on a lobby floor level of the building. An administrator control (e.g., key, code input) may be used to set the predestination elevator control  50  into a traditional mode wherein the traditional hall call user inputs  54  are active. Thereby, a floor 1 hall button device  62 , intermediate floor buttons  64 , up to a highest floor N hall button  66  are monitored by the group supervisory computer  52 .  
         [0027]    The predestination protocol computer  60  may also have its administrator control set to a predestination mode wherein a graphical hall call device on the first floor (“elevator controller #1”)  68  and any other graphical hall call devices (“elevator controller #N)  70  on other floors are active.  
         [0028]    It should be appreciated that the group supervisory computer  52  in some applications may continue to respond to the traditional hall call user inputs  54  when in predestination mode. Alternatively, the group supervisory computer  52  may ignore traditional inputs. As a further alternative, the predestination protocol computer  60  may set the mode differently for each floor. For instance, predestination mode may be applicable to the first floor that has a graphical hall call device but be in traditional mode on other floors.  
         [0029]    [0029]FIG. 3 depicts a software environment  72  for operating a predestination protocol computer  60  of FIG. 2. An input/output module  74  monitors for a manual input from a user (“floor button pushed”)  76  and passes this digital input data along with the originating floor to a main process  78 . The main process  78  provides confirmation that that the destination requested is valid, communicating this validity via a paint function data to a graphical screen  80 . The main process  78  conveys the digital input data (i.e., destination requested and originating floor) to a communication module  82 , which in turn relays this information to the group supervisor computer  52 . The communication module  82  in turn receives information from the group supervisory computer  52  to include communication status, car assignment data including assignment of any recently conveyed destination request, and location of the elevator cards, and conveys the same to the main process  78 .  
         [0030]    The main process  78  intuitively communicates the car assignment of destination request by painting it to the graphic screen  80  and/or by initiating audio cues from a sound card  84 . For instance, the sound card  84  may give a verbal confirmation for the visually impaired that a specific destination has been assigned to a specific car. The sound card  84  could also give verbal directions to an assigned car when it opens on the originating floor, telling the prospective riders that floors assigned to that car.  
         [0031]    [0031]FIG. 4 depicts an illustrative sequence of operation, or routine  100 , performed by the predestination protocol computer  60  for intuitively interacting with users of an elevator system. Initially, a determination is made as to whether a user input has been made to a graphical hall call device (block  102 ). If not, then a further determination has been made whether no input has been made for a period of time (e.g., 30 seconds) (block  104 ). If more than the period of time, then any data input to the graphical hall call device is cleared from the screen (block  106 ). This clearing prepares the screen for another user after having given sufficient time for the previous user to interact with the graphical hall call device. After either clearing the screen in block  106  or determining the time period has not expired in block  104 , processing returns to block  102  to monitor for new user inputs.  
         [0032]    If in block  102  a user input is detected, then the data is processed by the I/O module (block  108 ), such as by detecting a numeric sequence followed by an “enter” and by responding to any “clear” key entry. For instance, the processing may include filtering to prevent noise or other transient disturbances from being deemed a user input. The detected data is then sent to the main process from the I/O module (block  110 ).  
         [0033]    The detected data is then determined to be valid data or not (block  112 ). For instance, if the detected data does not correspond to a key entry, then processing returns to block  102  and the input is ignored. If however, the detected data is a valid data entry from a key, then a further determination is made as to whether the data is an enter key or button input (block  114 ). If not, a further determination is made as to whether the data is a clear key or button input (block  116 ). If not, the data is a data entry that may be a portion of a floor destination, and thus the main process directs that the data be painted on the screen so that the user can see the initial entry of data (block  118 ), and processing returns to block  102  for the user to complete the data entry. If in block  116  a clear entry is detected, then the main process directs that the screen be cleared of information data (block  120 ) and processing returns to block  102 .  
         [0034]    Returning to block  114 , if the data is determined to be an enter button, then a determination is made as to whether the full data entry painted on the screen designates a valid floor accessible from the point of origination of the floor data (block  122 ). If not, then the main process paints an invalid floor indication message on the screen (block  124 ) and processing returns to block  102 .  
         [0035]    If the requested destination floor is valid in block  122 , then the main process paints the requested destination floor data as registered on the screen (block  126 ) so that the user knows that the request is valid and has been received by the predestination protocol control. The registered destination floor data is sent to the communication module from the main process (block  128 ). The communication module thereafter relays the destination floor data to the GSP for assignment (block  130 ).  
         [0036]    In block  132 , elevator car assignment data from the GSP is received by the communication module. Then the communication module processes the received assignment data into a digital format (block  134 ). Then a determination is made as to whether the received assignment data is good data (e.g., not noise corrupted) (block  136 ). The determination may advantageously include comparing the received assignment data with previously received car assignments and with the requested destination data to see if the latest assignments have been suitably updated. If not, processing returns to block  130  to resubmit the destination request.  
         [0037]    If in block  136  the received data is deemed good, then the data is analyzed by the communication module for portions needed by the main process for interacting with the users (block  138 ). The analyzed portions are then communicated by the communication module to the main process (block  140 ), flagging in particular the car assigned to the most recent destination request. The main process in turn paints the car assignment data on the screen, designating in an intuitive fashion the requested destination by the user (block  142 ). The main process may further initiate a sound indication for the user to confirm the car assignment, which may include a verbal explanation of the car assignment (e.g., wave file) (block  144 ). Thereafter, processing returns to block  102  to await another user and to monitor changes in car assignments for display.  
         [0038]    It should be appreciated that intermittently or continuously the current locations and current destination assignments for the elevator cars is communicated from the GSP to the predestination protocol control so that this information can be updated on the screen so that a user may view the status of elevator cars with or without making a destination input.  
         [0039]    [0039]FIG. 5 depicts a graphical hall call device  200  that is providing intuitive feedback to a user so that predestination protocol for efficient use is achieved of the elevator system. Although dedicated floor keys may be incorporated into the device  200 , a keypad  202  advantageously allows for use in buildings having various ranges of floors. Specialized keys such as a “B” key  204  for basement designations may be included, as well as special function keys such as a “#” key  206  used by an administrator to access security and administrative configuration functions. A clear key  208  allows for inadvertent key entries to be cleared and an entry key  210  signals that a data entry has been completed by a user.  
         [0040]    A graphics display  212  is advantageously configured for a detected or preset elevator system configuration. For example, the graphic display on this floor may be accessible by three of four elevator cars serviced by the elevator system. On this floor, the fourth car is not accessible and thus its display has been omitted at  214 , whereas car assignments for Cars 1, 2, and 3 have been displayed respectively at  216 ,  218 ,  220 .  
         [0041]    When approaching the graphical hall call device  200 , a user may note the status of the predestination protocol control, such as “Status: Normal” or “Status: Error” indicating whether or not the predestination protocol system is operable. Also, a “SYSTEM DISABLED” or “SYSTEM ENABLED” may be displayed indicating whether an administrator has turned on or off the predestination protocol control. The user may also monitor the current location and/or car assignments for each car in their respective assignment boxes  216 - 220 . If not disabled, then the user inputs a desired floor with the keypad  202 , such as a numeral “21” appearing beside “DESTINATION FLOOR”.  
         [0042]    If the floor entered is invalid, then a message to this effect may appear across the top of the graphic display  212  and/or a characteristic tone or indication may be played over a speaker  222 . If, however, the requested destination floor is valid, then the request is relayed and the floor data boxed as at  224 , or another suitable indication given. Once the requested destination has been assigned to an elevator car, then the destination floor is added to the respective car assignment box, such as at  218 , a textual message explaining the assignment is displayed, such as at  226  (e.g., “Floor 21 assigned to Car 2”).  
         [0043]    [0043]FIG. 6 depicts an illustrative elevator waiting area  250  of an elevator system  252  having six elevator cars A-F and how a user may be intuitively assisted by a graphical hall call device  254 . In this scenario, car F is not accessible on floor 3 where the user is. Elevator car E is inoperative, although would typically service floor 3. Elevator cars A-D are operable and accessible on floor 3; however, elevator car A has an entry point not physically observable from the elevator waiting area  250 .  
         [0044]    [0044]FIG. 7 shows the illustrative graphical hall call device  254  in greater detail for this scenario, wherein the car assignment information is more fully explained to the user, including spatial information to direct the user to the appropriate car for instance, the user has input a destination of “21”, which has been assigned and communicated to the user. The user or other users monitoring the screen for their own destinations may note what predestination assignments have been made for cars A-D, may note that car E is inoperative. In addition, taking advantage of the graphical capabilities of the graphical hall call device  254 , indications may be made as to where the entry points physically are for each car by arranging the car assignment information in the same planform as the actual elevator cars. Moreover, the graphical hall call device may be configured to rotate the planform the correct horizontal angle to conform to the installation of the device  254 . The graphical hall call device  254  may further indicate which cars will be or are currently boarding on the floor, such as a visual and/or audio tone, like a flashing entry arrow  256 .  
         [0045]    The graphical hall call device  254  facilitates situations such as car A that is not visible by directing the user to its entry point, such as at arrows  258 .  
         [0046]    An advantage of having a graphical display and key pad data entry is that additional features may be readily accessible through a graphical hall call device. For instance, elevator monitoring system (EMS) functionality may be incorporated. Typically, an elevator control system interfaces with an EMS so that an administrator may override certain automated settings. Having access to such features may enhance the convenience of the EMS.  
         [0047]    Examples of what may become accessible once an administrator accesses EMS features include a command menu:  
         [0048]    Floor Lockout Command—Use this Command to prevent Car Calls and Hall Calls from being registered at selected floors;  
         [0049]    Car Call Lockout Command—Use this Command to prevent the registration of Car Calls to selected floors;  
         [0050]    Car Call Registration Command—Use this Command to register Car Calls in a particular elevator;  
         [0051]    Parking Operation Command—Use this Command to place the car into Parking Operation. This will cause the elevator to run to the designated parking floor where it will be removed from Normal Operation;  
         [0052]    Independent Operation Command—Use this Command to place the car into Independent Operation. During Independent Operation the elevator will respond to Car Calls only, and will not respond to Hall Calls. The elevator doors will open automatically when responding to a call, but need to be closed by applying constant pressure to the door close button or the car call registration button;  
         [0053]    VIP Operation Command—Use this Command to place the car into VIP Operation. During VIP Operation the elevator is sent to the VIP Floor where it will wait for the registration of a Car Call. The elevator will wait, for up to three minutes, with the doors open. The elevator will not respond to Hall Calls during this time. This Command can not be scheduled;  
         [0054]    Freight Operation—Use this Command to Start or Stop Freight Operation.  
         [0055]    Activating Freight Operation removes the elevator from group operation.  
         [0056]    The elevator then responds to Hall Calls registered from a separate group of Hall Buttons; and  
         [0057]    Security (Card Reader) Override—Use this Command to Start or Stop Security (Card Reader) Override Operation. Activating Security Override Operation overrides Card Reader Operation.  
         [0058]    The graphical display may advantageously be augmented with additional information when in EMS functions:  
         [0059]    Mode of Operation—Examples of modes of operation in order of priority: inspection, Fireman, Emergency Power, Seismic, Medical Emergency, Parking, Independent, VIP, Freight, Fully Automatic;  
         [0060]    Load Percentage—Displays the percentage load of the car with respect to the car&#39;s rated capacity;  
         [0061]    Direction—up, down or none;  
         [0062]    Position;  
         [0063]    Door Status—open, midway, 1 inch from fully closed, closed;  
         [0064]    Pending Car Calls;  
         [0065]    Pending Hall Calls;  
         [0066]    Floor Lockout Status; and  
         [0067]    Hall Call Communication Status.  
         [0068]    While the present invention has been illustrated by description of several embodiments and while the illustrative embodiments have been described in considerable detail, it is not the intention of the applicant to restrict or in any way limit the scope of the appended claims to such detail. Additional advantages and modifications may readily appear to those skilled in the art. For example, it should be appreciated by those skilled in the art having the benefit of the present disclosure that applications of the present invention may omit controls in some elevator waiting areas or in some elevator cars  12 - 18 .  
         [0069]    As another example, more than one graphical hall call device may be placed on a floor, especially to accommodate more passengers and larger or multiple elevator waiting area. Each device may advantageously tailor its displace, for instance orienting car assignment information to the physical layout relative to each device. In addition, a subset of the elevator cars may be displayed on each device, with text, automated voice, and/or graphical cues directing a passenger to the other device when entering a destination floor not served by that device.  
         [0070]    As another example, although mechanical push buttons are illustrated herein, graphical hall call devices may incorporate touch screen controls instead. A further advantage of such graphically depicted inputs are that the system may include readily configurable buttons with desired symbols and text appropriate for the installation. The predestination request may be processed nonetheless even if displayed on the other device.