Relative system response elevator dispatcher system using "artificial intelligence" to vary bonuses and penalties

Call distribution system for an elevator

The present invention relates to a group controller transmitter for an elevator system having a group of elevator cars to provide service to multiple floor levels of a building from which floor calls can be made, the group controller transmitter including a signal processing device responsive to car status signals to provide a signal to the cars for each registered floor call. the sum of the factors indicating the extent to which assigning any floor call to said basket is in accordance with the overall system response model applicable to the baskets, with responders identifying different sequences for sending the car to respond to the floor call, and relative system response factors being weighted in response to other factors to represent an increase in expected basket time respond to a floor call when tracking one transmission order relative to another transmission order, and assigning each floor call to the car with the lowest sum of relative system response factors for such a floor call, so that the call is assigned to the car in a transmission order that provides an improved overall system response compared to the fastest response to registered floor calls.

This application is a partial continuation of application 893 025 entitled Queued elevator transmission system using peak traffic forecasting filed on 20 June 1989, the explanation of which is attached with reference.

This application also relates to some of the same subject matter as the pending applications listed below owned by the transferee of this application, the explanations of which are also incorporated herein by reference:

Application of Joseph Bittar 07/192 436 entitled Weighted Relative System Response Elevator Car Assignment System With Variable Bonuses And Penalties filed 11.5. 1988 and on the basis of which the 1989 patent was granted; mixed

An application of this inventor entitled ‘Artificial Intelligence’ Based Crowd Sensing System For Elevator Car Assignment filed on the same day as this application (OT-859).

The invention relates to elevator systems and the transmission of cars in an elevator system. More particularly, the invention relates to assigning floor calls to a selected one of a group of elevators that jointly serve the floor levels of a building based on a weighted evaluation of relative system responses (RSR).

These RSR assessments include factors that take into account the system's operating options according to a multi-desired operating model, with assignments based on a relative balance between these factors essentially determining bonuses and fines for baskets using a computer algorithm to determine which baskets to assign to each floor call.

More specifically, the invention relates to the transmission of baskets based on a transmission algorithm with variable bonuses and fines using artificial intelligence methods based on real-time and historical traffic forecasts of the number of people behind floor calls, to anticipate the expected number of incoming and outgoing passengers at en-route stops and the expected car load on the floor call floor, and then adjusts the RSR bonuses and penalties based on the information to distribute the car loads and stops more evenly.

In an elevator system that uses relative system response evaluation (RSR evaluation) to assign elevator cars to floor calls, the travel time of the car to the corresponding floor call is expressed in terms of various time-related fines. The fines are added together and added to the various fines that impose undesirable policy options. Bonuses are given for desired operating situations, and these are deducted from the amount of the fine, resulting in an RSR value. These values ​​are calculated for each car and for each given floor call, and the car with the lowest RSR value is assigned to respond to the floor call. The fines and bonuses selected for the different time delays and action options are either fixed or changed based on, for example, the average waiting time for floor calls over the past five (5) minutes and the time elapsed since the current floor call was registered.

The above models handle all floor calls in the same way, regardless of the number of people waiting behind the floor call. They handle all bodies in the same way, regardless of the current load on the body, unless the body is fully loaded. They only take into account the current load of the car, but not the expected load of the car when the car reaches the floor call layer. As a result, the assignment of the basket assigned in one operating cycle is often removed later because the basket becomes full later, and another basket is assigned. Often the indicated basket does not have sufficient capacity. Thus, when it stops and picks up people, some people get out of the ride and then have to issue a floor call, resulting in increased waiting time and user annoyance. An extra basket must be sent there, which increases the basket • <1

4. .

and reduce the processing capacity of the system. Although more than one basket is required to serve a large number of people waiting, previous RSR systems still show only one basket, resulting in delayed service and long waiting times for a large number of people.

When the cars stop at the route floors, the passenger changeover time depends on the number of people getting in and out of the car. When using a fixed car stop penalty, delays due to route stops are only partially penalized. Route stops with a large number of passengers produce a high probability that the baskets are delayed, that the baskets become full before they reach the floor call layer, and that the baskets make additional basket command stops due to basket commands given in the route call layers. These are detrimental to the operation of the system because they often cause reassignment to the floor call, but are not properly punished.

Heavily loaded baskets often stop to pick up one or two people. This increases the service time for a large number of people. Previous RSR systems do not distribute car loads and car stops as efficiently as would be possible due to a lack of information on the number of people behind floor calls and the expected numbers of people leaving the car and getting on the car at route stops, and thus the expected car load when the car reaches the floor call layer.

For general background information on RSR display systems for elevator cars using either fixed or variable bonuses and fines, reference is further made to U.S. Patent No. 4,363,381 to the assignee, issued to Joseph Bittar on December 14, respectively. 1982, as well as the aforementioned application 07/192 436. These approaches

II is examined in more detail below in the section entitled RSR Assignments of Previous Approaches.

In contrast to the prior art approaches found, the invention advantageously uses an artificial intelligence methodology to collect traffic data and predict traffic levels at all floors of a building at all times of the working day based on historical and real-time traffic forecasts. It calculates passenger departure numbers at car command stops and incoming numbers at floor call stops. It uses these quantities and the current load of the car to anticipate the load of the car and the capacity reserve when the car arrives at a particular floor call stop. These predictions and other factors are then used to appropriately modify RSR fines and bonuses to assign each floor call to one or more baskets.

As part of the strategy of the invention in accurately forecasting traffic demand at all times of the working day, it is to use simple exponential smoothing and / or linear exponential smoothing. It should be noted that some of the general prediction or prediction methods of the invention are discussed in general (but not in connection with elevators or in any other analogous manner thereto) in Forecasting Methods and Applications, Spyros Makridakis and Steven C. Wheelwright (John Wiley & Sons, Inc., 1978), especially in Section 3.3: Single Exponential Smoothing and in Section 3.6: Linear Exponential Smoothing.

More specifically, a group controller transmitter according to the invention comprising a signal processing device is characterized in that the signal processing device further comprises: a signal processing device

- provide additional signals for measuring and collecting passenger traffic data in the building, covering at least the active part of the working day and including information on:

- number of passengers boarding the car, - number of floor call stops made, - number of passengers leaving the car, and - number of car command stops made on each floor upwards and downwards,

- anticipate the number of passengers waiting behind floor calls as a function of this information for at least a short period of time before a particular floor call to be addressed occurs, and

- assign a particular floor call to at least one of the baskets based on at least the expected number of passengers waiting behind the floor call and the expected car load when the car reaches the floor call floor; and a variable bonus and penalty setting device associated with said signal processing device and modifying certain bonuses and penalties for weighted relative response factors for each car based on the expected number of passengers waiting behind the floor call, the expected car load when the car reaches the floor call floor, and the projected number of passengers embarking and disembarking at any route stop as estimated by the signal processing device; the amounts of bonuses and fines imposed on the car bodies change when the estimated number of waiting passengers and the estimated car load on the arrival of the car on the floor call floor change; when a special floor call is assigned to the selected car by said variable bonus and fine setting device, thereby providing an improved overall system response to all floor calls when passenger traffic varies.

The invention and its preferred algorithms originated from the need to distribute car loads and car stops evenly to minimize service time and passenger waiting time and to improve handling capacity. This division is achieved, for example, by knowing the number of people behind the floor call, the expected numbers of people leaving and getting on the car at different car stops, and the current measured load of the car by means of traffic forecasting.

Using this information, the car load is calculated when the car reaches the floor call layer, and the resulting remaining capacity reserve is estimated as a result. This capacity reserve is matched to the projected number of people waiting in the floor call floor. Any incompatibility between the predicted capacity reserve and the predicted number of people waiting for a floor call is then used to allow or deny the car responding to the floor call using a floor call mismatch penalty.

The residence times on the different floors are calculated using the predicted load on the car and the number of people leaving and getting on the car. The basket command stop penalty and the floor call stop penalty are changed as a function of the delay time and the number of people waiting behind the floor call. Car stops on a floor call or car command are thus penalized based on the expected passenger changeover time and the expected number of people waiting behind the floor call to be assigned, so that when a large number of people are waiting, a car with fewer route stops is selected.

Stopping a heavily loaded basket to pick up a few people increases service time for a large number of people. Therefore, this is punished, for example, by using a car load penalty that changes in proportion to the number of people in the car but decreases as a function of the number of people waiting behind the floor call.

These fines are included in the RSR calculations.

The resulting RSR value is thus affected by the car load in the floor call layer, the number of people waiting in the floor call floor, and the number of people entering and leaving the car at route stops. All of these values ​​are obtained using a traffic forecasting methodology based on artificial intelligence.

The resulting improved RSR algorithm thus responds more sensitively to traffic situations and distributes car loads and stops more efficiently, resulting in shorter wait and service times and higher processing capacity.

Information about the past operation of the system is stored in a historical and real-time database, and the stored information is used for future forecasts.

The invention thus transmits elevator cars to be transmitted based on a transmission algorithm with variable bonuses and fines that uses artificial intelligence methods based on history and real-time traffic forecasts for the number of people behind floor calls, to anticipate the expected number of passengers embarking and disembarking at en-route stops and the expected car load at the floor call floor, and to change RSR bonuses and penalties based on this information to distribute car loads and stops more evenly.

Exemplary approaches and other related RSR methods used to accomplish the above are described in more detail below.

The invention can be applied to practice in a wide variety of elevator systems using known technology in light of the principles of the invention, which will be discussed in more detail hereinafter.

Other significant features and advantages of the invention will be apparent from the complete description and claims, and

II

98621 from the accompanying drawings, which illustrate an exemplary embodiment of the invention.

Figure 1 is a simplified schematic block diagram, part omitted, of an exemplary elevator system to which the invention may be an integral part.

Figure 2 is a simplified schematic block diagram of an exemplary basket controller that may be used in the system of Figure 1 and in which the invention may be practiced.

Figures 3A and 3B together form a simple logic flow diagram for an exemplary algorithm for a methodology used to collect traffic data and predict traffic and the number of passengers embarking and disembarking on different floors in a preferred embodiment of the invention.

Figures 4A and 4B are general descriptions of matrix diagrams illustrating the collection of real-time data in tables used in an exemplary embodiment of the invention, showing the collection of upward passenger numbers and uplink floor call stops in different layers.

Figure 5 is a simplified logic flow diagram for an exemplary algorithm for the methodology used in the exemplary embodiment of the invention to calculate a layer call mismatch penalty.

Figure 6 is a simplified logic flow diagram for an exemplary algorithm for the methodology used in the exemplary embodiment of the invention to calculate variable car command stop and floor call stop fines.

Fig. 7 is a drawing illustrating a typical variation of the car load penalty used in the exemplary embodiment of the invention with respect to the car load and the number of people waiting behind a floor call.

For a detailed description of an exemplary embodiment of the invention, said Bittar U.S. Patent 4,363,381 and U.S. Patent 4,330,863, jointly owned by Donofio and Games, entitled Elevator Cab Load Measuring System, issued on 18 May. 1982, the explanations are incorporated herein by reference.

A preferred embodiment of the invention is an elevator control system using a microprocessor-based group controller transmitter, in which a signal processing device is used, communicating with elevator system cars to determine car states and responding to floor calls from multiple floors of a building served by cars under the control of a group controller to assign floor calls to baskets based on a weighted summation of multiple system response factors for each car for each call by factors assigning different car statuses related to the invitation, to whom the assignment is made by imposing bonuses and fines in a weighted sum. An exemplary elevator system and an exemplary car controller (in block diagram form) are shown in Figures 1 and 2 of Patent 4,363,381, respectively, and are described in detail in said patent.

It should be noted that Figures 1 and 2 of this application are substantially similar to those of Patent 4,363,381 and the aforementioned co-pending application 07 / 192,436. For the sake of brevity, the parts of Figures 1 and 2 are described only in outline and generally below, as was also done in the co-pending application, as any desired more detailed functional details can be found in Patent 4,363,381 and prior assignee patents.

Of the several exemplary elevator shafts shown in Fig. 1, only the elevator shaft A1 and the elevator shaft F 2 are illustrated, the others being omitted for simplicity. In each elevator shaft, the elevator car 3, 4 is controlled to move vertically on rails (not shown).

Each car is suspended on a steel rope 5, 6 which is driven in both directions or held fixed by a lift-driven pulley / motor / brake arrangement Ί, 8 and guided by a free handwheel 9, 10 in the assembly of the elevator shaft. The rope 5, 6 normally also supports a counterweight 11, 12, which is typically approximately equal to the weight of the car when it has half the permissible load.

Each car 3, 4 is connected by a suspension cable 13, 14 to a corresponding car guide 15, 16, which is typically located in the machine room at the end of the elevator shafts. As is known in the art, the basket guides 15, 16 control the operation and movement of the baskets.

In the case of multi-car elevator systems, it has long been common to use a group controller 17 that receives up and down floor calls from floor call buttons 18-20 on the floors of the building and allocates these calls to different cars and distributes the cars among the floors according to any of a variety of group operation modes.

The operating modes of the group operation can be controlled in part, for example, from the lobby control panel (LOB PNL) 21, which in multi-car elevator systems is normally connected to the group controller by suitable building installation wiring 22.

The car controls 15, 16 also control certain elevator shaft functions associated with the respective car, for example the lights of the up and down indicator buttons 23, 24 with one set of buttons 23 for each car 3 and a similar set of buttons 24 for each other car 4 with these indicator buttons pointing to the elevator shaft door. , with which the service in response to the ker12 call is available in the respective directions up or down.

The position of the car in the elevator shaft can be obtained from a primary position sensor (PPT) 25, 26. Such a sensor is driven by a suitable wheel 27, 28 guided by a steel strip 29, 30 connected at both ends to the car and passing over the free wheel 31, 32.

Similarly, although not necessary for the practice of the invention in an elevator system, a second location sensor (SPT) 33, 34 may be used to obtain detailed location information in each floor for more precise door control and verification of floor location information from the sensor PPT 25, 26. Or, if desired, in an elevator system in which the invention is practiced, switches for the inner door area and the outer door area of ​​the type known in the art can be used in the elevator shaft.

The foregoing is a general description of an elevator system, and heretofore described as well as elevator systems known in the art as an exemplary elevator system in which the principles of the invention may be implemented as an integral part thereof.

All the functions of the elevator car itself can be controlled or connected to them by means of the carriage controller 35, 36 according to the invention, and it can provide a serial, time-multiplexed connection to the car controller and a direct wired connection to the car driver by means of a suspension cable 13, 14. For example, the trolley controller can monitor the car command buttons, the door open and close buttons and other buttons and switches in the car. It can also control the illumination of the buttons, which indicates basket commands, as well as control the floor indicator inside the basket, which indicates the approaching floor.

The carriage controller 35, 36 has an interface with load weighing sensors to provide weight information used to control the movement, operation and door functions of the car. For the load weighing data used in the invention, the system described in the above-mentioned patent 4,330,863 can be used.

An additional function of the carriage controller 35, 36 is to control the opening and closing of the door in accordance with the requirements imposed on it under conditions which have been determined to be safe.

The configuration of microcomputer systems such as those used in the implementation of basket controllers 15, 16, group controller 17, and carriage controllers 35, 36 can be selected from readily available components or families of components according to known technology as described in many commercial and technical publications. The software structures for implementing the invention, as well as the less significant features that may be explained herein, can be arranged in a wide variety of ways.

As noted above, the prior car assignment system, which based on the RSR approach and described in co-owned Patent 4,363,381, included an elevator control system in which floor calls were assigned to cars based on relative system response factors (RSR factors). and made it possible to assign baskets to invitations based on a relative approach rather than an absolute approach, and in doing so used specific preset values ​​to impose RSR bonuses and fines.

However, because the bonuses and fines were fixed and pre-selected, waiting times sometimes became long depending on the circumstances in the system. Thus, although the invention 4 363 381 was a substantial advance in the field, substantial improvements were still possible, and one such was achieved by the invention of the aforementioned co-pending application 07 / 192,436.

In that invention, bonuses and fines, instead of being preselected and fixed as in invention 4,363,381, were changed as a function of, for example, the average waiting time for immediately preceding floor calls and the time since the current floor call was registered, which could be used to measure building current traffic. One example of a time period for averaging that could be used was five (5) minutes, and a time period of this order was considered preferred.

In the operation of the system, the average waiting time of floor calls for the selected elapsed time period was estimated using, for example, the time at which the floor call was registered, as well as the response time to the floor call for each floor call and the total number of answered floor calls during the selected time period. The time elapsed since the floor call was registered was calculated from the time the floor call was registered until the time the basket call was assigned a basket. According to the invention, fines and bonuses were chosen to give priority to floor calls that remained registered to wait for assignment for a long time relative to the average waiting time for floor calls in the selected elapsed time period.

When a floor call remained registered for a long time waiting for an assignment compared to the average wait time of the selected elapsed time period, the floor call had a high priority and thus did not have to wait for, for example, baskets with an incoming car command stop or an adjacent stop. which were not parked or assigned less than the permitted number of floor calls. In these situations, bonuses and fines were thus changed by reducing them.

Il

When the time elapsed since the registration of the floor call was small compared to the average waiting time for the selected time period, the opposite situation was a fact, and bonuses and fines were changed by increasing them.

The dependency functions used to select bonuses and fines related, for example, to the time elapsed since the registration of the floor call and the average waiting time of the floor calls for the selected elapsed time period to increases and decreases in the values ​​of bonuses and penalties.

As a variation from the previous, bonuses and fines could be reduced and increased based on the difference between the currently elapsed floor call registration and the average waiting time for floor calls in the selected elapsed time period as a measure of current traffic intensity.

In the following, the artificial intelligence principles used in the invention and the application of the invention to the detailed exemplary embodiment will be considered first, and then the exemplary embodiment will be examined in more detail in connection with the drawings.

For example, between 6 a.m. and midnight, that is, throughout the active workday, traffic data is collected from all floors of the building in each direction for short intervals, such as one (1) minute interval, for the following:

- number of floor call stops that occurred,

- number of passengers boarding the bodies using body load measurements on the floors,

the number of car command stops that have occurred, and

- the number of passengers leaving the bodies, again using the measurements of the body load on the floors.

At the end of each time slot, data collected, for example, over the past three time slots, in terms of passenger numbers and number of car stops, are analyzed. If the data shows that car stops occurred on any floor and in any direction, for example, two (2) out of three (3) minutes elapsed, and on average more than, for example, two (2) passengers boarded each car or two (2) passengers left each car on that floor and in that direction for at least two (2) time slots, real-time forecasting is initiated for that layer and direction.

Traffic for the next few, two (2), or three (3) time slots for that layer, direction, and type of traffic (car rises or exits) is then predicted, preferably using a linear exponential smoothing model. Both passenger numbers and number of stops (floor call stops and car command stops) are predicted in this way. Preferably, the traffic is also anticipated for a few time slots after the next time slot.

High traffic volumes may be due to normal traffic patterns on each business day or special events that occur on a particular day.

Real-time forecasting ceases when the total number of cars stopping on the floor in that direction and for that type of traffic is less than, for example, two (2) for four (4) consecutive time slots and when the average number of passengers embarking and disembarking is less than, for example, two (2). 0).

Whenever significant traffic levels are detected on a layer or in any direction and real-time traffic forecasting is performed, the collected real-time data for different time slots is stored in the historical data database when the real-time forecasting is stopped. The floor where the traffic was detected, the direction of the traffic and the type of traffic in terms of the quantities entering or leaving the baskets, as well as the number of floor call stops or basket command stops, are stored in the history database. The start and end times of the traffic and the day of the week are also stored in the history database.

Once a day, at midnight, the data stored in the history database during the day is compared with the data obtained from previous days. If the same traffic period is repeated on each business day, for example with a three (3) minute tolerance for start and end times and for example a fifteen percent (15%) tolerance for traffic volume variation during the first four and last four short periods, the past day data is stored in the normal traffic pattern file.

If the data is not repeated on all working days, but if the pattern is repeated on each same day of the week, for example with a tolerance of three (3) minutes for start and end times and a tolerance of fifteen percent (15%) for traffic volume variation during the first four and last four time periods, stored in a file of normal weekly patterns.

After the data collected during the day is thus analyzed and stored in the normal pattern file and the normal weekly pattern file, all the data in those files for the different layers, directions, and traffic types is used to predict traffic for the next day. For each floor, direction, and traffic type, the occurrences of past history patterns are identified one at a time. For each such occurrence, next-day traffic is predicted using data from the previous occurrence and data predicted at the last occurrence, and using an exponential smoothing model. All normal traffic patterns and normal weekly traffic patterns that are expected to occur the next day are thus forecast and stored in the forecast database based on the current day's history.

At the end of each data collection interval, the layers and directions where significant traffic was detected are identified. After real-time traffic for a significant traffic type is forecasted, the current day's history forecasting database is checked to see if historical traffic forecasting has been made for this floor and direction and for the same traffic type for the next time slot.

If so, then these two predicted values ​​are combined to obtain optimal predictions. These forecasts use equal weights for the history-based and real-time forecasts, and thus a weighting factor of half (0.5) is used for both. However, if at the beginning of the traffic period the real-time forecast differs from the historical forecast by more than, for example, twenty percent (20%) in, for example, four (4) six (6) one-minute intervals, the real-time forecast is weighted by three quarters (0.75) and the historical forecast quarter (0.25) to obtain a combined optimal forecast.

Real-time forecasts are made for the number of passengers embarking and disembarking, as well as the number of floor call and car command stops, for a period of three (3) or four (4) minutes from the end of the time period. History-based forecasting data for three or four minutes is obtained from a previously produced database. Thus, combined predictions of passenger numbers and basket stop numbers can also be made up to three or four minutes after the end of the current time period.

If historical forecasts have not been made for that floor in the same direction and for the same type of traffic for the next few time intervals, real-time forecast passenger numbers and basket stop times shall be used.

II amounts for the next three (3) or four (4) minutes as optimal predictions.

Using this predicted data, the number of passengers boarding and disembarking on the floor where there is significant traffic is then calculated. The number of passengers boarding in that floor and in that direction is calculated as the ratio of the total number of passengers boarding in that floor to the number of floor call stops in that floor and in that direction during that time interval. The number of passengers leaving the baskets is calculated as the ratio of the total number of passengers leaving the baskets on that floor and in that direction during that period to the number of car command stops in that floor and in that direction during that period.

The number of passengers boarding and disembarking for the next three (3) or four (4) minutes is then calculated once per minute for the floors and directions where significant traffic has been observed. If the traffic on any floor and direction is not significant, i.e. less than, for example, two (2) people board or disembark the car on average, the number of passengers boarding or disembarking will not be counted.

When a floor call is then received, the expected car load for each car in the floor call layer is calculated. The car load when the car reaches the floor call layer is equal to the current car load plus the sum of the number of passengers expected to ascend to the car at route stops already assigned to the car minus the sum of passenger numbers expected to leave the car at already registered car stop stops.

If, when calculating this car load, traffic at one of the floor call route stops or car command stops is not significant and thus unforeseen, it is assumed that only one (1) person will board the car at the floor call stop or only one (1) person will leave the car at the car command stop.

The calculated car load is used to calculate the capacity margin in the car in relation to the passengers. The expected number of passengers boarding the car on the floor call floor is compared to the capacity reserve. A fine, called a floor call mismatch penalty (HCM), is used to allow or deny a car responding to a floor call as follows.

If there is no significant traffic on the floor from which the floor call originates, then because only one (1) person is assumed to ascend to the floor on the floor call floor, the car can be selected for display if it is not fully loaded, i.e., does not exceed, for example, eighty percent (80%) capacity. Thus, if the calculated car load when the car reaches the floor call layer is less than eighty percent (80%), the HCM is set to zero. For example, if the calculated body load exceeds eighty percent (80%), HCM is set to 200. This approach differs from the 4,363,381 approach, which uses the current body load to allow or deny body identification and does not consider the number of passengers entering and leaving the body. in route stops and car command stops due to floor calls. This approach thus minimizes floor call reassignments due to the car becoming fully loaded at route stops.

The RSR sender of Patent 4,363,381 also does not use the estimated number of people waiting in the floor call layer to be assigned in the selection of the car.

Il

In the invention, on the other hand, if there is significant traffic in the floor from which the floor call originates, then after the car load in the floor call floor has been calculated, the car capacity margin is calculated with respect to the number of passengers. If the predicted number of passengers boarding in the floor call floor is less than or equal to (s) the length of the queue limiting one car and if the capacity capacity of the car is equal to or greater than (£) the average number of passengers boarding in the floor call floor, then the car is selectable to be assigned and the HCM is set to zero. . If the average number of passengers boarding the car on the floor call layer is less than (<) the length of the queue limiting one car, but the capacity capacity of the car is less than the average number of passengers boarding the floor on the floor call layer, then the car cannot be selected for allocation to the floor call layer. Therefore, the value for HCM is set to, for example, 200.

Stopping multiple baskets to pick up a small number of people is prevented. This improves body productivity by minimizing body downtime.

If the average number of passengers boarding the car in the floor call layer exceeds the length of the single car boundary queue, then if the car capacity reserve is less than the minimum pick-up limit for many cars, say two (2) people, the car is not selectable and its HCM is set to 200.

If, when the average number of passengers boarding the car in the floor call floor exceeds the length of the queue limiting one car, the car capacity reserve is equal to or greater than (£) the minimum pick-up limit for many cars, then the HCM fine is set to zero.

If, then, the capacity of the car is less than (<) the average number of passengers boarding the car in the floor call layer, the car will generate a requested second car (SCR) signal. If the basket with the lowest RSR does not throw the SCR signal at the ke98620, this basket responds to the floor call alone. If the car with the lowest RSR generates an SCR signal, the car with the next lowest RSR also responds to the layer call. The length of the constraint queue for one car and the minimum pick-up limit for multiple cars are functions of the current traffic density. For example, the system learns the values ​​and changes them once every five minutes.

When the first car responds to the floor call, then if it is not fully loaded when it closes the doors in the floor call floor, it generates an SCR signal cancellation message indicating that all waiting passengers have been picked up. The second basket that responds to that layer call due to the SCR signal then deletes itself from the assignment to that layer call.

The RSR sender of Patent 4,363,381 uses a fixed basket command stop fine and a floor call stop fine. Typical values ​​are ten (10) for a basket command stop penalty (CSP) and eleven (11) for a floor call stop penalty (HSP) ·

When traffic data is predicted and the car load is estimated at different car command stop and floor call stop layers, the remaining car capacity and expected boarding and departing passenger numbers are used to calculate the required door open time (car stop time on floor) using an appropriate mathematical model.

Thus, for each car command stop and floor call stop, the car command stop penalty is increased if the required car stop time exceeds, for example, one (1) second and the floor call stop time exceeds, for example, three (3.0) seconds. For example, for each two (2.0) second increment in stop time, the fine for the basket command stop and the floor call stop is increased by, for example, one. Thus, if a basket is expected to linger too long at en route stops because it omits or picks up large numbers of people, that basket will be fined appropriately.

In addition, the fine for the car command stop and the floor call stop is preferably changed as a function of the number of people waiting behind the floor call to be assigned.

This is done because with each route stop, there is an increased likelihood that the car will be delayed and become heavier loaded due to unexpected events. When the car makes route stops due to floor calls, these in turn can develop new car command stops in the future, thus further delaying the car. Both unexpected delays and loads can later result in the layer call being reassigned. Selecting a car with fewer route stops provides better reliability for the car to arrive at the floor call layer. Because good reliability and a low probability of re-assigning a layer call are desirable for long queues, basket stop fines increase with queue length. Thus, if more people wait behind a floor call, more route stops are fined, while small fines are used for short queues. This selects baskets with fewer route stops to serve long queues. This model produces a lower latency for a large number of people, resulting in a shorter average latency for the system.

The table below shows the typical increase in basket stop fines when the dwell time is one (1) second for a basket command stop and three (3.0) seconds for a floor call stop.

<td>NUMBER OF PEOPLE IN FLOOR CALL</td><td> 2</td><td> 3</td><td> 4</td><td> 5</td><td> 6</td><td> 8</td><td> 10</td><td> 12</td><td> 12 +</td>

<td>CSB GROWTH</td><td> 0</td><td> 0</td><td> 1</td><td> 2</td><td> 3</td><td> 4</td><td> 5</td><td> 6</td><td> 8</td>

GROWTH OF HSP 001245 7 9 12

The increases in the fine change as a function of traffic intensity. In heavy traffic conditions, fewer stops are desired to serve floor calls with long queues; thus, fines increase faster as the queue length increases. Floor calls with short queues can then be served by baskets with more route stops.

When the number of people behind a floor call is predicted using the artificial intelligence methods of the invention and the car load is calculated when the car reaches the floor call layer, the car load penalty (CLP) is used to strain heavily loaded cars when the car command stop does not occur in the floor call layer. The fine is variable and increases in proportion to the number of people in the basket. The growth rate is high when the number of people waiting behind the floor call is small. When the number of people waiting behind the floor call is large, the car load penalty increases with the car load at a lower speed.

If the car has a car command stop that occurs in the floor call layer, the CLP is set to zero.

The change in the car load penalty (CLP) with the car load and the number of people behind the floor call can be expressed by a linear correlation model as follows:

CLP - a_cld (C_ld C_ldl) b_PHC · N_PHC where a_cld and b_PHC are correlation coefficients, C_ld is the car load when the car reaches the floor call layer, C_ldl the body load limit is set and N_PHC is the number of people waiting in the floor call floor. Variations for large a_cld and b_PHC are, for example, in the ranges from three-tenths to three (0.3 to 3.0) and half-and-a-half

II (0.5 - 1.5) and for large C_ldl four to twelve (4 12).

When the body load is less than C_ldl, there is no body load penalty. This limit depends on the number of people waiting behind the floor call.

As can be seen, the model prioritizes lightly loaded baskets when serving short queues.

The basket can only take as many people as there is room for capacity. Thus, linear equations should not be used if the number of people waiting behind a floor call exceeds the capacity margin. This is taken care of by restricting the pointing of the basket. Thus, if there is insufficient capacity margin, a floor call mismatch penalty (HCM) prevents the car from being assigned, or alternatively more than one car is assigned to respond to the floor call.

Thus, the car load penalty increases with the car load (C_ld) but decreases the number of people behind the floor call (N_PHC) and is used until the sum of Cid ⁺ OF_PHC approaching or reaching body capacity.

The CLP can thus be calculated using the above equation. The equation defines the quantities of a_cld, C_ldl and b_PHCvalues ​​and is used for N_PHC for different values, for example from one (1) to twelve (12). When N_PHC exceeds twelve (12), the twelve passenger equation is used.

As a specific example of the above and as an exemplary embodiment of the invention, the logic flowchart of Figures 3A and 3B illustrates an exemplary methodology for collecting traffic data, forecasting traffic, and calculating the number of passengers embarking and disembarking. In steps 3-1 and 3-2, traffic data is collected, for example, during a time frame appropriate for each one (1) minute interval, covering at least the entire active workday, e.g., 6 a.m. to midnight, number of passengers boarding, floor call stops, number of passengers leaving, and for the number of basket command stops that occurred on each floor in the up and down directions. For example, the collected data from the last one (1) hour is stored in a database, as generally shown in Figures 4A and 4B and in step 3-1.

In steps 3-3 to 3-4a, at the end of each minute, the data is analyzed to see if there have been up and down stops on any floor in, for example, two (2) of the three (3) time slots and if on average more than two (2) passengers have left each basket or climbed into each basket during those intervals. If so, then significant traffic is considered to have been assigned. For example, traffic for the next three (3) or four (4) minutes is then predicted in step 3-6 for that layer and direction using real-time data and a linear exponential smoothing model as generally described in Makridakis and Wheelwright, cited above, in particular Section 3.6. and applied to elevator transmission in the full description of the above-mentioned basic application. Thus, if traffic today fluctuates significantly from previous days ’traffic, this variation is immediately used in forecasts.

If this traffic pattern is repeated every day or every same day of the week on this layer, the data is stored in a history database and the data for each two (2) or three (3) minute interval is forecast the previous night for this day using, for example, a moving average method or more preferably a simple exponential smoothing model. which model is similarly described in general in the aforementioned publication of Makridakis and Wheelwright, in particular in section 3.3 thereof, as applied to the dispatch of elevators ii in the full description of the above-mentioned basic application.

If such a forecast is available, the historical and real-time forecasts are combined to obtain optimal forecasts, in step 310. Forecasts can combine both real-time forecasts and historical forecasts according to the following equation:

X = ax_B + bx_r where X is the combined prediction, x_B is a forecast based on historical data and x_r is a real-time forecast for the short term for a given stratum and a and b are the coefficients.

Initially, a value of half (0.5) is used for a and b. If the real-time forecasts differ from the forecast based on historical data by more than, for example, twenty percent (20%) for several time intervals, the value of a is reduced and the value of b is increased, as previously stated.

If history-based forecasts are not available, the real-time forecast is used as the optimal forecast, as shown in steps 3-11.

As can be seen from the figure, the algorithm of Figures 3A and 3B also includes other detailed steps and features, but these are considered to be self-evident in view of the above.

Then, for each floor and direction for which significant traffic is predicted in step 3-12, the average number of people boarding the car is calculated, for example, as the ratio of the number of people boarding during the forecast time to the number of floor call stops during that time slot. The average number of people leaving the basket is calculated as the ratio of the number of people leaving the basket during the anticipated period in step 3-13 to the number of basket command stops during that period. These amounts are calculated for the next three or four minutes and stored in a database.

When a floor call is then received from the floor, the RSR value for each car is calculated taking into account the floor call unsuit penalty, car command stop and floor call stop fines, and car load penalty, all of which vary based on the expected .

The above is essentially identical to the original methodology of the co-pending application (OT-859).

An example methodology for calculating a floor call unsuit penalty is illustrated in the logic flowchart of Figure 5, where the car load on a floor call layer is calculated for a given car and floor call in step 5-1 by adding to the current car load the sum of passenger increments from the number of passengers at route stops.

If there is no predicted traffic in the current floor call layer in step 5-2, then if in step 5-3 the predicted car load is equal to or greater than, for example, eighty percent (80%) of the car capacity, then in step 5-5 the car floor unsuitable penalty (HCM) is set. a high value, for example 200, to prevent this basket from being assigned to the floor call. If this is not the case, that is, the predicted car load is less than eighty percent of the capacity, then in step 5-4, the floor call unsuit penalty is set to zero.

Il

On the other hand, if the current floor call layer has predicted traffic in step 5-2 and if the predicted number of people waiting behind the floor call is less than or equal to (s) the queue limiting one car, e.g., five (5), the logic branches to step 5-7. If, at this stage, the capacity capacity of the car is equal to or greater than (£) the length of the waiting queue, the HCM is set to zero in step 5-9, and otherwise it is set to 200 in step 5-8. If the queue length in step 5-6 exceeds the length of one car limiting queue, then if the car capacity margin exceeds the minimum pick limit of many cars, then the HCM is set to zero in step 5-11, and otherwise set to 200 in step 5-12 to prevent this car from being assigned to this floor call. . If necessary, namely, if the capacity of the car is less than the queue behind the floor call, then in step 5-14, another car (SCR signal) is requested when the RSR value is calculated.

As can be seen from the figure, the algorithm of Figure 5 also includes other detailed steps and features, but these are taken for granted.

Figure 6 illustrates an example methodology used to calculate variable car stop stops and floor call stop fines, using for each route stop in the program, in steps 6-1 and 6-2, the current car load and the expected number of passengers on the route decelerations the basket arrives at a standstill, the remaining capacity, when the departure of passengers has ended and the total number of changing passengers. The door opening time required in step 6-3 is calculated using these parameters and a suitable mathematical model based on observations made from reality.

In step 6-4, a fine is calculated for each car command stop (CSP) and floor call stop (HSP) in the car by adding additions to the nominal values ​​of these fines based on the number of people waiting behind the floor call (N_PHC), using, for example, the table above.

In steps 6-5, the fines thus calculated are further increased by, for example, one for each two (2) seconds of the dwell time, which exceeds a minimum of one (1) second with a basket command stop and a minimum of three (3) seconds with a floor call stop.

A typical change in the car load penalty with respect to the car load and the number of people waiting behind the floor call is illustrated for an exemplary car with a capacity of 1800 kg in the drawing of Figure 7, where N_PHC, i.e., the number of people waiting in a floor call, varies from one (1) to twelve (12) passengers. The drawing is based on the equation discussed above.

The fines calculated in this way are used in the RSR algorithm with other bonuses and fines to widow the final improved RSR values. The RSR algorithm of the above-referenced patent application 07/192 436 with variable bonuses and fines can be used improved in accordance with the present invention. Thus, using the artificial intelligence methodology of the invention, the predicted traffic can be used to change bonuses and fines and to calculate the resulting RSR values. When baskets are assigned to floor calls using this approach, basket stops and basket loads are more evenly distributed, resulting in better service.

Although the invention has been shown and described in terms of the exemplary detailed embodiments thereof, it should be apparent to those skilled in the art that various changes in form, detail, methodology, and / or approach may be made without departing from the spirit and scope of the invention.

Thus, when at least one embodiment of the invention is described by way of example, what is new and desired to be protected by a patent is defined in the following claims.